"keep-alive" its there in HTTP. Some says it good should be used, but i am unable to get to any conclusion.
So please provide your input/answer/views so i can get some ground for this,
What it does?
Scenario where it should and should not be done?
How it can make AJAX application better ?
Risks DO's and DONT's if any?
Thank you all for inputs.
First off if your connection to the server is using HTTP/1.1 then you are most likely already using "keep-alive".
What is it? Logically HTTP is a connectionless protocol. That is each request/response to the server creates a new connection, does its business and drops the connection. However in HTTP/1.1 the default behaviour is to keep the connection open for use by subsequent requests to the server. The "keep-alive" header was added to HTTP/1.0 to allow this behaviour to be opted into, in HTTP/1.1 the server needs to opt-out by closing the connection itself and/or sending a "connection-close" header in response.
Why is it beneficial? Creating a connection especially one that needs to be authenticated can take some time. By re-using an existing connection the setup and authentication effort is much reduced.
How can it make your AJAX app better? You are probably already benefitting from it.
What are the risks? When making a connection through a shared appliance which may make a connection to the server in the clients behalf it is possible for other clients to re-use the connection, however that also makes it possible for other clients to use a connection that the server has authenticated for a different user.
It keeps the TCP socket to the client open, so you have not reestablish connection to send another HTTP request;
Keep-alive improves http performance when there are many requests in a row. It should not been used however if the requests are rare (server normally closes connection if there are no more requests coming from a client during some period of time).
Well, if your AJAX application sends a lot of requests to the server keep-alives improve its performance.
There is a risk of sockets depletion on server side, so server has rights to interrupt even keep-alive connections.
Really it boils down to questions of performance and resource.
Using a high(er) keep alive reduces latency on requests. This is particularly an issue if you are running over SSL where there additional handshakes to establish a connection.
OTOH, this will mean that there additional server processes.threads sitting idle, waiting for a subsequent request or the keep-alive to expire. This can hog memory and therefore slow down your server.
So you really need to play around and see what's acceptable in terms in browser performance vs server load.
Authentication (basic/digest/session based) is not relevant - it is the request which is authenticated - not the socket connection.
Note that the last time I did a fresh Apache install it came with a default setting of 5 seconds for the keep alive. This is ridiculously long for a non-ajax site.
C.
Related
I have not been able to get an answer to this anywhere online. I want to remove possible jitter from my nodejs server. I am using socket.io to create connections to node.
If a user goes to a specific part of my website, a connection is started. However, if the user refreshes the site too quickly and often, the connection is created very frequently, and issues arise with my server.
While I realized it's possible this could be solved a couple different ways, I am hoping a server solution is out there. Meaning, whenever a user connects, make sure the user is connected for at least 5 seconds. Then move on. Otherwise, disconnect the user. Thanks for any insight!
First off a little background. With a default configuration, when a socket.io connection starts, it first does 2-5 http connections and then once it has established the "logical" connection, it tries to establish a connection using the webSocket transport. If that is successful, then it keeps that webSocket connection as a long lasting connection and sends socket.io packets over it.
If the client refreshes in the middle of the transition to a webSocket connection, it creates a period of unknown state on the server where the server isn't sure if the user is just still in the middle of the transition to a lasting webSocket connection, if the user is gone entirely already, if the user is having some sort of connection issues or if the user is doing some refresh thing. You can easily end up with a situation where the server thinks there are multiple connections all from the same user in the process of being confirmed. It can be a bit messy if your server is sensitive to that kind of thing.
The quickest thing you can do is to force the connection process to go immediately to the webSocket transport. You can do that in the client by adding an options to your connection code:
let socket = io(yourURL, {transports: ["websocket"]});
You can also configure the server to only accept webSocket connections if you're try to protect against any other types of connections besides just from your own web pages.
This will then go through the usual webSocket connection which starts with a single http request that is then "upgraded" to the webSocket protocol. Once connection, one socket. The server will know right away, either the user is or isn't connected. And, once they've switched over to the webSocket protocol, the server will known immediately if the user hits refresh because the browser will close the webSocket immediately.
The "start with http first" feature in socket.io is largely present because in the early days of webSockets, there were some browsers that didn't yet support them and some network infrastructure (like corporate proxies) that didn't always support webSocket connections. The browser issue is completely gone now. All browsers in use support webSocket connections. I don't personally have any data on the corporate proxies issues, but I don't ever hear about any issues with people using webSockets these days so I don't think that's much of an issue any more either.
So, the above change will get you a quick, confirmed connection and get rid of the confusion around whether a user is or isn't connected early in the connection process.
Now, if you still have users who are messing things up by rapid refresh, you probably need to just implement some protection on your server for that. If you cookie each user that arrives on your server, you could create some middleware that would keep track of how many page requests in some recent time interval have come from the browser with this cookie and just return them an error page that explains they can't make requests that quickly. I would probably implement this at the web page level, not the webSocket level as that will give users better feedback to stop hitting refresh. If it's really a refresh you're trying to protect against and not general navigation on your site, then you can keep a record of a combination cookie and URL and if you see even two of those within a few seconds, then return the error page instead of the expected content. If you redirect to an error page, it forces a more conscious action to go back to the right page again before they can get to the content.
I am trying to understand this behavior where first network call takes more than double of subsequent ones. I know that DNS resolving will not take more than 5-50ms and it happens only in the initial call. Considering this info, there shouldn’t be much difference in time taken for the first call and subsequent calls.
I have tested this behavior with some famous URLs in separate incognito windows for each with cache disabled and attached a few screenshots to support my observation below. Can anyone help me understand this behavior?
Note: The readings are taken in full speed internet connection
Thanks in advance
After a few experiments, I found out that Content Download (browser request steps) part of the request is speeding up 1.5-2 times
This looks like a cause of TCP Slow Start algorithm
As it states:
modern browsers either open multiple connections simultaneously or reuse one connection for all files requested from a particular web server
That might be the reason for the first request to be slower than others
Also, #Vishal Vijay made a good addition:
Making initial connection handshake to the server is taking time (DNS Lookup + Initial connection + SSL). Browsers are creating Persistent Connections for HTTP requests and keep it open for some time. If any request came in for the same domain within that time, the browser will try to reuse the same connection for faster response.
In some cases it might be server-side cache mechanism causing subsequent request to process faster, but let's just talk about the browser-side stuffs.
When you hover on the waterfall 'blocks' you will get the time details:
Here is a quick reference for each of the phases (from Google Developers):
Queueing. The browser queues requests when:
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
Stalled. The request could be stalled for any of the reasons described in Queueing.
DNS Lookup. The browser is resolving the request's IP address.
Proxy negotiation. The browser is negotiating the request with a proxy server.
Request sent. The request is being sent.
ServiceWorker Preparation. The browser is starting up the service worker.
Request to ServiceWorker. The request is being sent to the service worker.
Waiting (TTFB). The browser is waiting for the first byte of a response. TTFB stands for Time To First Byte. This timing includes 1
round trip of latency and the time the server took to prepare the
response.
Content Download. The browser is receiving the response.
Receiving Push. The browser is receiving data for this response via HTTP/2 Server Push.
Reading Push. The browser is reading the local data previously received.
So what's difference between the first and subsequent requests in traditional HTTP/1.1 scenario?
DNS Lookup: It might take more time to resolve DNS for the first request. Subsequent requests will resolve a lot faster using browser DNS cache.
Waiting (TTFB): The first request have to establish TCP connecting to the server. Due to HTTP keep-alive mechanism, subsequent requests to the same server will reuse the existing TCP connection to prevent another TCP handshake, thus reducing three round-trip time compared the first request.
Content Download: Due to TCP slow start, the first request will need more time to download content. Since subsequent requests will reuse the TCP connection, when the TCP window scaled up, the content will be downloaded much faster than the first request.
Thus generally subsequent requests should be much faster than the first request. Actually this leads to a common network optimization strategy: Use as few domains as possible for your website.
HTTP/2 even introduces multiplexing to better reuse a single TCP connection. That's why HTTP/2 will give a performance boost in modern front end world, where we deploy tons of small assets on the CDN servers.
I would like to show a list of connected users without using Websockets.
I thought to use http header Connection:keep-alive
to get persistent connections.
Then, when clients leave the website, they would run a listener handler on beforeunload event in order to notice server that a client is going to leave the list.
But, how is server able to notify the rest of connected clients to update their lists? (remember, without using websockets, and if possible, without making clients asking any interval to server)
So using the Connection: keep-alive header means that the browser and server will carry out multiple http requests/responses over one tcp connection vs opening and closing a tcp connection for each http request. But this still doesn't allow the server to just push data whenever. For the server to respond with anything, the client still would need to make requests. So it isn't really related to real time push events.
and if possible, without making clients asking any interval to server
This isn't really possible. Like I said, a server cannot send data to a client over http unless the client first requested it.
So you either have to make interval requests for the user list
or
you can make it "simulate" pushing from the server with http long-polling.
The basic idea is that the server never "finishes" its response to a client request, but sends its response in chunks, when really those chunks would be treated on the client side as separate pieces of data. But this solution is hacky and has a lot of cons. Either way, http long-polling would more or less simulate pushing data real time.
I am building a small chat application for friends, but unsure about how to get information in a timely manner that is not as manual or as rudimentary as forcing a page refresh.
Currently, I am implementing this using simple AJAX, but this has the disadvantage of regularly hitting the server when a short timer elapses.
In researching long/short polling, I ran across HTML5 WebSockets. This seems easy to implement, but I'm not sure if there are some hidden disadvantages. For example, I think WebSockets is only supported by certain browsers. Are there other disadvantages to WebSockets that I should be aware of?
Since it seems like both technologies do the same thing, in what sorts of scenarios would one prefer to use one over the other? More specifically, has HTML5 WebSockets made AJAX long/short polling obsolete, or are there compelling reasons to prefer AJAX over WebSockets?
WebSockets is definitely the future now.
Long polling is a dirty workaround to prevent creating connections for each request like AJAX does - but long polling was created when WebSockets didn't exist. Now due to WebSockets,
long polling is going away no more.
WebRTC allows for peer-to-peer communication.
I recommend learning WebSockets.
Comparison:
of different communication techniques on the web
AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection.
Supported in all major browsers.
Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic.
support chart (full) | wikipedia
WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted.
support chart (very good) | wikipedia
WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required.
support chart (medium) | wikipedia
Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia
Advantages:
The main advantage of WebSockets server-side, is that it is not an HTTP request (after handshake), but a proper message based communication protocol. This enables you to achieve huge performance and architecture advantages. For example, in node.js, you can share the same memory for different socket connections, so they can each access shared variables. Therefore, you don't need to use a database as an exchange point in the middle (like with AJAX or Long Polling with a language like PHP).
You can store data in RAM, or even republish between sockets straight away.
Security considerations
People are often concerned about the security of WebSockets. The reality is that it makes little difference or even puts WebSockets as better option. First of all, with AJAX, there is a higher chance of MITM, as each request is a new TCP connection that is traversing through internet infrastructure. With WebSockets, once it's connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, which requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).
P.S.
Remember that WebSockets generally have a very different approach of logic for networking, more like real-time games had all this time, and not like http.
One contending technology you've omitted is Server-Sent Events / Event Source. What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? has a good discussion of all of these. Keep in mind that some of these are easier than others to integrate with on the server side.
For chat applications or any other application that is in constant conversation with the server, WebSockets are the best option. However, you can only use WebSockets with a server that supports them, so that may limit your ability to use them if you cannot install the required libraries. In which case, you would need to use Long Polling to obtain similar functionality.
XHR polling A Request is answered when the event occurs (could be straight away, or after a delay). Subsequent requests will need to made to receive further events.
The browser makes an asynchronous request of the server,
which may wait for data to be available before responding. The
response can contain encoded data (typically XML or JSON) or
Javascript to be executed by the client. At the end of the processing
of the response, the browser creates and sends another XHR, to await
the next event. Thus the browser always keeps a request outstanding
with the server, to be answered as each event occurs. Wikipedia
Server Sent Events Client sends request to server. Server sends new data to webpage at any time.
Traditionally, a web page has to send a request to the server to
receive new data; that is, the page requests data from the server.
With server-sent events, it's possible for a server to send new data
to a web page at any time, by pushing messages to the web page. These
incoming messages can be treated as Events + data inside the web page. Mozilla
WebSockets After the initial handshake (via HTTP protocol). Communication is done bidirectionally using the WebSocket protocol.
The handshake starts with an HTTP request/response, allowing servers
to handle HTTP connections as well as WebSocket connections on the
same port. Once the connection is established, communication switches
to a bidirectional binary protocol which does not conform to the HTTP
protocol. Wikipedia
I would like to know what kind of limitations there are in using websockets.
Websockets is just so.. powerful. I can't imagine that it is without disadvantages.
Say, what is the number of users that can simultaneously connect to a server (if I'm creating a game and users will connect to the game through WebSockets, what will limit the number of users able to connect at any one time?)
Also is it true that with each additional connection, the quality of the connections (speed and stuff like that) will decrease?
The advantages and disadvantages will of course depend on the specific use case, but I'll try to point out some differences between WebSocket and HTTP.
WebSocket is more complex than HTTP. You can establish an HTTP connection with a telnet client, but you probably cannot do the same with WS. Even if you ignored the handshake requirements (which include the use of the SHA1 hash function), you would then be unable to properly mask and frame the data to be sent, and the server would close the connection.
As Uwe said, WebSocket connections are intended to be more persistent than HTTP connections. If you only want to receive an update every 30 minutes, you will want to go with HTTP. If you want to receive updates every second, a WebSocket might be a better option, because establishing an HTTP connection takes a lot of time.
To establish an HTTP connection, you first have to establish a TCP connection (SYN, SYN/ACK, ACK), then send a GET request with a pretty big header, then finally receive the server's response (along with another big header).
With an open WebSocket you simply receive the response (no request needed), and it comes with a much smaller header: from two bytes for small frames, up to 10 bytes for ridiculously large frames (in the gigabyte range).
You need to weigh the two costs (keeping a connection open vs establishing a new connection) to decide between the two protocols.
Note: this answer is based on the current draft of the protocol (draft-ietf-hybi-thewebsocketprotocol-09). WebSocket is evolving rapidly, many implementations are still based on older drafts, and some details may change before it is finalized.
From what I read, this seems to be related to HTTP Server Push which I read that it is usually not recommended to use since it creates lots of connections on the server.
If I have to choose, I probably would always develop a client polling mechanism.