By default Connection Header is set to Keep-Alive in browers, to make it possible to keep connection open for further requests from browser.
When I make Connection header to close, what may be the difference ?
Will that affect any performance issue ?
(one addition: I am setting header from xmlhttprequest)
When you make requests with "Connection: keep-alive" the subsequent request to the server will use the same TCP connection. This is called HTTP persistent connection. This helps in reducing CPU load on the server side and improves latency/response time.
If a request is made with "Connection: close" this indicates that once the request has been made the server needs to close the connection. And so for each request a new TCP connection will be established.
By default HTTP 1.1 client/server uses keep-alive whereas HTTP 1.0 client/server doesn't support keep-alive by default.
It affects performance, because most expensive resources create a socket between two machines. So the client needs to establish a new connection in every request.
this article has graphically demonstrated what would happen in such a when the connection header is set to closed and also keep-alive.
It helped me understand it and I hope it helps you too.
The Benefits of Connection Keep Alive
Related
If we have a HTTP persistent connection, however one of the request takes a long time (say 30 seconds).
Assume client's timeout is 15 seconds.
Is client's reques-timeout respected when used over persistent connection ?
If yes, then does the connection break ?
Is there any way to avoid the entire connection from breaking, and instead just timing out on that one particular request ?
Client can specify timeout but it depends on the server configuration for using client timeout or its own timeout configuration. By default server side timeout configuration has more priority than client timeout configuration.
No
For having one particular request with different timeout config it's not possible on the same connection But, you can declare different http client config connection and use one of them for default and another one for request that need much more timeout value But they are not in the same keep-alive connection. Note, In the client side timeout configuration we have two different type of timeout
1- Open Connection Timeout 2- Read Response Timeout.
The first one is declared for open connection between server and client and the second one is declared for how much time client needs to get response for his request.
That depends of what client you are using and how the server is configured. The problem is more complicated... setting keep-alive in http won't avoid tcp timeouts at transport level, you need to set tcp timeout to keep-alive as well, but then server may not want to keep a connection for you as long as you would like to. For persistent connections it is better to use udp instead of tcp - it doesn't have such a strict flow control. Other thing is that HTTP/2 has no such a thing as keep-alive at all, as things are handled in totally different way than in HTTP/1. From the HTTP/2 RFC:
8.1.2.2. Connection-Specific Header Fields
HTTP/2 does not use the Connection header field to indicate
connection-specific header fields; in this protocol, connection-
specific metadata is conveyed by other means. An endpoint MUST NOT
generate an HTTP/2 message containing connection-specific header
fields; any message containing connection-specific header fields MUST
be treated as malformed (Section 8.1.2.6).
The only exception to this is the TE header field, which MAY be
present in an HTTP/2 request; when it is, it MUST NOT contain any
value other than "trailers".
This means that an intermediary transforming an HTTP/1.x message to
HTTP/2 will need to remove any header fields nominated by the
Connection header field, along with the Connection header field
itself. Such intermediaries SHOULD also remove other connection-
specific header fields, such as Keep-Alive, Proxy-Connection,
Transfer-Encoding, and Upgrade, even if they are not nominated by the
Connection header field.
When a server sent a keep-alive header to a client
Does it mean that every requests of this client ip will be benefited?
Does it mean that every requests of this client ip plus session will be benefited?
Put it into a situation.
After I browse a website and the server sent keep-alive to me. I open another browser and go to the same website. Will my second request connect without handshake?
I read the documentation but I could not find out the target. Please help me.
In HTTP 1.0, if both the client and server support keep alive then the connection will be persisted and multiple requests can use the same connection without handshaking each time, benefitting the session by slightly reducing request/response time.
In HTTP 1.1, connections are keep alive by default so this is the expected behaviour.
This happens within the session - another browser window would constitute another session, so there would be no connection sharing and therefore no benefit.
What exactly is the difference between long polling and http Keep-Alive??
Doesnt http Keep-Alive solve the issue that long-polling solves??
No. They're almost completely unrelated.
HTTP keepalive allows the client to keep a connection open, but idle, to allow it to make future requests a little bit more efficiently. The server cannot send data to a client over a keepalive connection, as no request is active.
Long polling is a mechanism where the server keeps a request (and thus a connection) active, but not sending data, to allow the server to send data to the client when it becomes available -- for instance, when an event occurs.
I am reading that Keep-Alives is meant for performance - so that no connections need to be recreated but just reuse the existing ones. What if there is a traffic spike, will new connections be created?
Additionally, if I don't turn on Keep-Alive and in a high traffic environment, will it eventually running out of connections/socket port on client side? because a new connection has to be created for each http/web request.
HTTP is a stateless protocol.
In HTTP 1.0 each request meant opening a new TCP connection.
That caused performance issues (e.g. have to re-do the 3-way handshake for each GET or POST) so the Keep-Alive Header was added to maintain the connection across requests and in HTTP1.1 the default is persistent connection.
This means that the connection is reused across requests.
I am not really familiar with IIS but if there is a configuration to close the connection after each HTTP response, it will have impact on the performance.
Concerning the running out of sockets/ports on the client side, that could occur if the client fires a huge amount of requests and a new TCP connection must be opened per HTTP request.
After a while the ports will be depleted
I have a HTTP client that sets the Connection header to the following value when I make a request:
Connection: close
However when the server sends a response, it is setting the header to Keep-Alive:
Connection: Keep-Alive
This seems intuitively wrong to me, and I am wondering how the client should handle such a response from the server? Also why would a server respond with Keep-Alive, when the client has asked for the connection to be closed, is this valid?
According to the HTTP RFC:
"HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,
Connection: close
in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete."
That's fine. You are telling the server you don't support persistent connections and it's telling you it does. Either party is completely valid in closing the connection - it's more of a message about what both supports rather then a YOU MUST CLOSE THIS CONNECTION command.
The client says I will close the connection when the current request/response is finished,or in other words , said you don't support persisten connections. That is, it doesn't tell the server to close the connection. The server replies that it supports persistent connections(keep-alive).
As you've told the server that you don't support persistent connection, you should close the connection when you've read the response.