HTTP keep-alive Detailed (GO)

HTTP Keep-alive Detailed

HTTP is a typical example of a request <-> response pattern in which a client sends a request message to the server to respond to this information. In the old HTTP version, each request will be created with a new client-to-server connection, send a request on this connection, and then receive the request. One of the great advantages of such a model is that it is simple, easy to understand and programmed to implement; it also has a big drawback that it is inefficient, so keep-alive is proposed to solve the problem of low efficiency.
The keep-alive feature makes the client-to-server connection persistent, and when a subsequent request to the server occurs, the Keep-alive feature avoids establishing or re-establishing the connection. Most Web servers on the market, including Iplanet, IIS, and Apache, support HTTP keep-alive. This feature is often useful for websites that provide static content. However, there is another problem with heavier sites: while retaining open connections for customers has some benefits, it also affects performance because the resources that could have been freed during the processing pause are still occupied. When the Web server and application server are running on the same machine, the Keep-alive feature has a particularly significant impact on resource utilization. This feature is a feature of HTTP 1.1 presets, and HTTP 1.0 plus Keep-aliveheader can also provide the persistent function of HTTP.
Keep-alive:timeout=5, max=100
Timeout: Expires 5 seconds (the parameter in the corresponding httpd.conf is: keepalivetimeout), Max is a maximum of 100 requests, forcing the connection to be disconnected
is a new connection in timeout time, and Max will automatically minus 1 until 0, forcing it to break. See the four figures below, and note the value of date (the time difference is within 5 seconds)!

http/1.0
In the http/1.0 version, there is no official standard to specify how keep-alive works, so it is actually attached to the http/1.0 protocol, and if the client browser supports Keep-alive, add a field to the HTTP request header Connection:keep-alive, when the server receives a request with connection:keep-alive attached, it also adds an identical field to the response header to use keep-alive. In this way, the HTTP connection between the client and the server is maintained, not disconnected (except for the time specified by keep-alive, unexpected power outages, etc.), and when the client sends another request, the established connection is used
http/1.1
In the http/1.1 version, the official keep-alive usage standard is somewhat different from the http/1.0 version, where all connections are maintained by default in HTTP1.1 unless indicated in the request header or response header to close: Connection:close, That's why the connection:keep-alive field doesn't make sense anymore. In addition, a new field keep-alive is added: Because this field does not describe in detail what is used to do, ignore it
Not reliable (unreliable)

HTTP is a stateless protocol, which means that each request is independent and keep-alive failed to change the result. In addition, Keep-alive does not guarantee that the connection between the client and the server must be active, as is the case in the HTTP1.1 version. The only guarantee is that when the connection is closed you can get a notification, so you should not let the program rely on keep-alive to maintain the connection characteristics, otherwise there will be unintended consequences

Keep-alive and Post

It is stated in the HTTP1.1 rules that there cannot be any characters behind a post message body, and that the standard may not be followed for a particular browser (such as placing a CRLF character behind the post message body). As far as I know, most browsers will automatically follow a CRLF character after the post message body, how to solve this problem? Depending on the instructions above, it is forbidden to use keep-alive in the POST request header, or the server automatically ignores the CRLF, and most of the servers are automatically ignored, but it is not possible to know whether a server will do this without testing.

Keep-alive implementation in Java--client

On the client side, Java abstracts the keep-alive, and the programmer shares away, and the HttpURLConnection class automatically implements Keep-alive, if the programmer does not intervene to manipulate keep-alive, Keep-alive is automatically implemented through an instance object of a HttpURLConnection class inside the client. That is, keep-alive in Java is implemented by a Java class library, but is not necessarily available in other class libraries.

Keep-alive implemented in Java--server side
On the server side, Java continues to abstract keep-alive, HttpServlet, HttpServletRequest, and HttpServletResponse classes automatically implement Keep-alive. In this case, some operations controlled by a third party are possible, such as whether the javawebserver,keep-alive mentioned in Keepaliveservlet is enabled by two factors, content length and output size, If the content length is part of the response (that is, the content needs to be output after the content length is output), then Keep-alive is enabled (with the client's support, of course), and if the content length is not set, the servlet will try to calculate the response buffer length to determine the length of the content. In the JavaSoft implementation, a 4KB buffer is used (the equivalent of the response mentioned above). That is, if the content length is not set and the returned data is more than 4KB, this is equivalent to the length of the content greater than the response length, not part of the response length, keep-alive will not be enabled.

HTTP keep-alive Detailed (GO)