https://developer.mozilla.org/en-US/docs/Web/API/EventSource
The EventSource interface is web content's interface to server-sent events. An EventSource instance opens a persistent connection to an HTTP server, which sends events in text/event-stream format. The connection remains open until closed by calling EventSource.close().
From what I understand server-sent events require persistent HTTP connection (Connection: keep-alive) so similarly to keeping the connection alive like in case of web sockets.
If the connection is persistent, why server-sent events are unidirectional? Web socket connections are persistent as well.
In this case, what happens if I send a request to my HTTP service and I have persistent connection opened due to EventSource. Will it re-use HTTP connection opened by EventSource or open a new connection?
If it re-uses the connection opened by EventSource how is it considered unidirectional?
Might be trivial, but I had to ask because it is not clear. Because nothing mentions what happens to subsequent HTTP requests when there's existing connection opened by EventSource.
For example, it seems possible to me to implement centralized chat app using SSE:
User 1 sends message to User 2(by sending it to HTTP server). Server sends event to user 2 with a new message, user 2 sends another request to HTTP server with message for User 1, server sends event to user 1.
How is that not considered bi-directional?
Related:
What's the behavioral difference between HTTP Stay-Alive and Websockets?
SSE is unidirectional because when you open a SSE connection, only the server can send data to the client (browser, etc.). The client cannot send any data. SSE is a bit older than WebSockets, hence may be the difference between the unidirectional and bi-directional support between these two technos.
In your use-case, if you open a SSE connection (which is an HTTP connection), only the server will be able to send data. If you wish to send a request to your HTTP service, you will need to open a new "classical" HTTP connection. You will see your browser opening two HTTP connections: 1 for the SSE connection and 1 for the classical HTTP request (short live).
You can implement a chat with SSE. You can have a SSE connection (hence HTTP) to let the user receives the messages from the server. And you can use POST HTTP requests to enable the user to send his/her messages.
Note that most of the browsers can open around 6 HTTP/1.x connections to the same host. So, if you use 1 SSE connection, it will remain potentially 5 HTTP/1.x connections. This is only true with HTTP/1.x. With HTTP 2.x, the connections to the same host are multiplexed: so, in theory, you can send as many HTTP requests at the same time as you wish or you can open as many SSE connections as you wish and thus, by passing the limitation of the 6 connections.
You can have a look at this article (https://streamdata.io/blog/push-sse-vs-websockets/) and this video (https://www.youtube.com/watch?v=NDDp7BiSad4) to get an insight about this technology and whether it could fit your needs. They summarize pros & cons of both SSE and WebSockets.
Related
When speaking from a conceptual point of view, is it standard practice to mix WebSockets and HTTP requests when making a chat application (or any application that requires real-time communication between devices)?
Imagine a scenario with a client and a server in a chat app. What would be the best approach for connecting and sending data between the client and the server? Would it be using sockets for both sending and receiving or HTTP requests for sending (so the client would get a response and then know if the message was received), and then using WebSocket for only receiving new messages?
No this is not standard practice.
If you need real-time communication between client and server you normally just use a websocket connection and keep that one open. The client can send messages to the server and receive messages through the same connection.
Using HTTP requests for sending messages to the server and receiving new messages via websocket seems odd and just adds unnecessary complexity.
Now if your server has some endpoints to subscribe for real-time data e.g. a chat room and endpoints for getting information you don't necessary want to subscribe to e.g. information about a certain user, than you can use the appropriate protocol for each endpoint
I know that a http request first makes a 3 way handshake to establish connection. Followed by the request and response.
If a handshake is required for future requests then it is called non persistent connection.
The server can choose to keep the connection alive so that a handshake is not required untill a timeout value (persistent). This is called persistent connection. It saves time required by not requiring the 3 way handshake for each request.
My colleague mentions that http supports both persistent and non persistent. My understanding is that - tcp makes the connection. So persistence is controlled by tcp layer. Am I right?
May be not right. HTTP is higher layer than TCP and HTTP 1.0 will send close() when they finish tranportint some data streams. But in HTTP 1.1, the controller will not send close(), instead, it'll send keepalive/hearbeat to the other side for live. It is controlled by the application layer, in other words, by the HTTP itself.
One way HTTP can support a persistent connection is called Server-Sent-Events.
An alternative to HTTP for persistant connections is WebSocket. WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. WebSocket enables streams of messages on top of TCP. WebSocket is distinct from HTTP.
While I'm writing a service with grpc, I'm trying to compare http/2 with websocket by server side pushing mechanism.
I know for websocket, the client will send a request with Upgrade: WebSocket and Connection: Upgrade headers to server and establish the long-lived connection. Then server will send the data freely after the connection is established.
But for grpc, as it is routed upon http/2, from the wiki page, https://en.wikipedia.org/wiki/HTTP/2_Server_Push, it says the server would need to predict the potential requests the client would send, and send a PUSH_PROMISE frame as early as possible.
Here are my two questions:
Does it mean that the server would also need to receive a corresponding response(request) from client in response to this PUSH_PROMISE header to decide if client wants to receive or decline the certain push?
In Grpc, if I have a sever side streaming, say send a message every 1 second from server. Does it mean the server need to send a PUSH_PROMISE to client every 1 second or at least before every data frame that server pushes to client?
gRPC does not currently support/use PUSH_PROMISE.
Streaming RPCs in gRPC use HTTP/2 streams; the entire RPC is contained in a request/response in HTTP. The main difference is that HTTP/2 implementations generally allow such streams to be streaming and bidirectional (the client can send more in the request after reading part of the response), while in HTTP/1 that was hit-or-miss.
In gRPC the client will always initiate the RPC. But for server-streaming the server can then reply with multiple messages over time via the stream. This would be similar to the scenario you described with websockets.
My understanding regarding network model communication:
Application layer:
1. HTTP(Not Persistent or stateless): For exchanging messages like get, post, put etc. Here connection is made to webserver and disconnected after sending response. So server will not keep track of the previous requests.
2. Websockets(Persistent or statefull): For creating a communication channel that will be open to exchange data. Here we can keep track of the previous requests. Like we can know how many users are currently connected to our server.
Transport layer:
TCP(Persistant and Statefull): Will let the server know to which application to connect using port number. Both HTTP and web sockets will work upon this layer.
Considering working with HTTP and TCP:
I make a HTTP request from browser(application layer):
Connects to web server sends all files requested and also makes a TCP connection with the application(transport layer).
After sending response it's disconnected.
My confusion:
I got totally confused when I heard, read that TCP is Statefull and Persistant connection.
Q1. Now after step three is browser still connected to webserver because of TCP?
Q2. Is the context object we get in server side in c# code is the complete request packet with HTTP info, TCP info, function to invoke or controller to invoke in MVC etc?
Q3. If client and server are still connected with TCP. Then on next HTTP request does it will use the available TCP connection or will create new TCP and HTTP connection? Why can't it use previous TCP to communicate? Or TCP will be destroyed after HTTP? Or what's happening?
I just went through the specification of http 1.1 at http://www.w3.org/Protocols/rfc2616/rfc2616.html and came across a section about connections http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8 that says
" A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.
Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection. "
Then I also went through a section on http state management at https://www.rfc-editor.org/rfc/rfc2965 that says in its section 2 that
"Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests;"
A section about the need to have persistent connections in the RFC 2616 also said that prior to persistent connections every time a client wished to fetch a url it had to establish a new TCP connection for each and every new request.
Now my question is, if we have persistent connections in http/1.1 then as mentioned above a client does not need to make a new connection for every new request. It can send multiple requests over the same connection. So if the server knows that every subsequent request is coming over the same connection, would it not be obvious that the request is from the same client? And hence would this just not suffice to maintain the state and would this just nit be enough for the server to understand that the request was from the same client ? In this case then why is a separate state management mechanism required at all ?
Basically, yes, it would make sense, but HTTP persistent connections are used to eliminate administrative TCP/IP overhead of connection handling (e.g. connect/disconnect/reconnect, etc.). It is not meant to say anything about the state of the data moving across the connection, which is what you're talking about.
No. For instance, there might an intermediate (such as a proxy or a reverse proxy) in the request path that aggregates requests from multiple TCP connections.
See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-21.html#intermediaries.