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.
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
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 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.
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
In http transaction for request and response which scenario is occurred ?
client (web browser) open connection and send it's request and connection open (keep alive) until server accept and answer then close connection ?
client (web browser) open connection and send it's request then connection is closed and server accept and answer and reconnect and send response ?
in http1.0 and http1.1 this scenario is different ?
A server can't directly reconnect to a client. Hence, your scenario #2 is unlikely.
In other words, in the WEB world, "transactions" between a Client Browser and a WEB Server is always "Client Browser Initiated".
Of course, if we are talking about server-to-server communication over HTTP, it is a different story: you can make up your own rules here, provided you control at least one server ;-)
As for the difference between HTTP 1.0 and HTTTP 1.1, I don't know enough.
In both 1.0 and 1,1 connection is kept open until response is sent. Keep alive refers to what happens afterwards.
In HTTP 1.0 server closes the connection after sending the response. Unless client sends and server understands keep-alive header (which was not a part of HTTP 1.0 standard)
In HTTP 1.1 connection is kept open after the response unless client sends Connection: close header.
Details
The scenario is:
The client (browser) opens a connection to the web server and sends HTTP request
The server receives the request and sends back the response to the client (browser)
If keep alive is enabled, the connection will not be closed until the keep alive timeout expires. The idea of keep alive is to use the same TCP connect to send/receive multiple requests/responses.
Persistent connection / Keep alive was officially introduced in the HTTP 1.1 specification. keep-alive was not officially documented in the specification of HTTP 1.0, however, some implementation of HTTP 1.0 supported keep alive connections.
regarding scenario 2: The server never initiate connections with browsers, the browser initiate connections with the server and the server uses the same connection to send back responses.