HTTP keep-alive：修订间差异
| （未显示同一用户的7个中间版本） | |||
| 第1行： | 第1行： | ||
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection. | HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection. | ||
= Implementations | = Implementations = | ||
== HTTP 1.0 == | == HTTP 1.0 == | ||
HTTP1.0 通过在请求头中添加Connection: keep- | Under HTTP 1.0, connections should always be closed by the server after sending the response. | ||
Since at least late 1995, developers of popular products (browsers, web servers, etc.) using HTTP/1.0, started to add an '''unofficial''' extension (to the protocol) named "keep-alive" in order to allow the reuse of a connection for multiple requests/responses. | |||
If the client supports keep-alive, it adds an additional header to the request: | |||
<syntaxhighlight lang="HTTP"> | |||
Connection: keep-alive | |||
</syntaxhighlight> | |||
== HTTP 1.1 == | |||
HTTP1.0 通过在请求头中添加Connection: keep-alive启用长连接（非官方做法），而HTTP 1.1默认使用Keep-Alive机制（也叫持久化连接），可以使得多个HTTP请求共用一个底层的TCP连接。 | |||
正常情况下，客户端发送单个HTTP请求后，会发送RST报文主动断开连接： | 正常情况下，客户端发送单个HTTP请求后，会发送RST报文主动断开连接： | ||
| 第25行： | 第37行： | ||
[[Image:http-fin.png|600px|border]] | [[Image:http-fin.png|600px|border]] | ||
== HTTP 1.1 == | == Keepalive with chunked transfer encoding == | ||
Keepalive makes it difficult for the client to determine where one response ends and the next response begins, particularly during pipelined HTTP operation. This is a serious problem when '''Content-Length''' cannot be used due to streaming. To solve this problem, HTTP 1.1 introduced a chunked transfer coding that defines a last-chunk bit.The '''last-chunk''' bit is set at the end of each response so that the client knows where the next response begins. | |||
== Disadvantages == | |||
If the client does not close the connection when all of the data it needs has been received, the resources needed to keep the connection open on the server will be unavailable for other clients. How much this affects the server's availability and how long the resources are unavailable depend on the server's architecture and configuration. | |||
Also a race condition can occur where the client sends a request to the server at the same time that the server closes the TCP connection. A server should send a 408 Request Timeout status code to the client immediately before closing the connection. When a client receives the 408 status code, after having sent the request, it may open a new connection to the server and re-send the request. | |||
== HTTP 2.0 == | == HTTP 2.0 == | ||
2023年12月7日 (四) 11:38的最新版本
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.
Implementations
HTTP 1.0
Under HTTP 1.0, connections should always be closed by the server after sending the response.
Since at least late 1995, developers of popular products (browsers, web servers, etc.) using HTTP/1.0, started to add an unofficial extension (to the protocol) named "keep-alive" in order to allow the reuse of a connection for multiple requests/responses.
If the client supports keep-alive, it adds an additional header to the request:
Connection: keep-alive
HTTP 1.1
HTTP1.0 通过在请求头中添加Connection: keep-alive启用长连接（非官方做法），而HTTP 1.1默认使用Keep-Alive机制（也叫持久化连接），可以使得多个HTTP请求共用一个底层的TCP连接。 正常情况下，客户端发送单个HTTP请求后，会发送RST报文主动断开连接：
如果不启用Keep-Alive或者因某种原因没有生效（比如Go语言中没有读取完Body内容时，该连接无法复用），发送多个HTTP请求时会导致多次握手建立连接：
而启用Keep-Alive后，发送多次HTTP请求无需重新握手：
当客户端Keep-Alive超时时间小于服务器超时时间时，会发送Keep-Alive报文（ACK）:
当服务器Keep-Alive超时时间小于客户端超时时间时，则会主动发送FIN断开连接。再次发送数据时，需要重新握手建立连接：
Keepalive with chunked transfer encoding
Keepalive makes it difficult for the client to determine where one response ends and the next response begins, particularly during pipelined HTTP operation. This is a serious problem when Content-Length cannot be used due to streaming. To solve this problem, HTTP 1.1 introduced a chunked transfer coding that defines a last-chunk bit.The last-chunk bit is set at the end of each response so that the client knows where the next response begins.
Disadvantages
If the client does not close the connection when all of the data it needs has been received, the resources needed to keep the connection open on the server will be unavailable for other clients. How much this affects the server's availability and how long the resources are unavailable depend on the server's architecture and configuration.
Also a race condition can occur where the client sends a request to the server at the same time that the server closes the TCP connection. A server should send a 408 Request Timeout status code to the client immediately before closing the connection. When a client receives the 408 status code, after having sent the request, it may open a new connection to the server and re-send the request.