HTTP keep-alive - 版本历史

Riguz：/* Keepalive with chunked transfer encoding */

2023-12-07T11:38:42Z

Keepalive with chunked transfer encoding

←上一版本		2023年12月7日 (四) 11:38的版本
第40行：		第40行：

	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.		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:36 Riguz

2023-12-07T11:36:46Z

←上一版本		2023年12月7日 (四) 11:36的版本
第37行：		第37行：
	[[Image:http-fin.png\|600px\|border]]		[[Image:http-fin.png\|600px\|border]]

	==		== 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.		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.

Riguz：/* HTTP 2.0 */

2023-12-07T11:36:12Z

HTTP 2.0

←上一版本		2023年12月7日 (四) 11:36的版本
第36行：		第36行：

	[[Image:http-fin.png\|600px\|border]]		[[Image:http-fin.png\|600px\|border]]

			==
			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.

	== HTTP 2.0 ==		== HTTP 2.0 ==

Riguz：/* HTTP 1.0 */

2023-12-07T11:34:03Z

HTTP 1.0

←上一版本		2023年12月7日 (四) 11:34的版本
第6行：		第6行：
	Under HTTP 1.0, connections should always be closed by the server after sending the response.		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.		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:		If the client supports keep-alive, it adds an additional header to the request:
第13行：		第13行：
	Connection: keep-alive		Connection: keep-alive
	</syntaxhighlight>		</syntaxhighlight>

	== HTTP 1.1 ==		== HTTP 1.1 ==

Riguz：/* Implementations */

2023-12-07T11:33:52Z

Implementations

←上一版本		2023年12月7日 (四) 11:33的版本
第2行：		第2行：

	= Implementations =		= 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:

			<syntaxhighlight lang="HTTP">
			Connection: keep-alive
			</syntaxhighlight>
	== HTTP 1.1 ==		== HTTP 1.1 ==

Riguz：/* Implementations = */

2023-12-07T01:56:30Z

Implementations =

←上一版本		2023年12月7日 (四) 01:56的版本
第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.1 ==		== HTTP 1.1 ==

Riguz：/* HTTP 1.1 */

2023-12-06T10:09:52Z

HTTP 1.1

←上一版本		2023年12月6日 (三) 10:09的版本
第24行：		第24行：

	[[Image:http-fin.png\|600px\|border]]		[[Image:http-fin.png\|600px\|border]]

	~~== HTTP 1.1 ==~~

	== HTTP 2.0 ==		== HTTP 2.0 ==

Riguz：/* HTTP 1.0 */

2023-12-06T10:09:46Z

HTTP 1.0

←上一版本		2023年12月6日 (三) 10:09的版本
第2行：		第2行：

	= Implementations ==		= Implementations ==
	== HTTP 1.0 ==		== HTTP 1.1 ==

	HTTP1.0 通过在请求头中添加Connection: keep-~~alive启用长连接，而HTTP~~ 1.1默认使用Keep-Alive机制（也叫持久化连接），可以使得多个HTTP请求共用一个底层的TCP连接。		HTTP1.0 通过在请求头中添加Connection: keep-alive启用长连接（非官方做法），而HTTP 1.1默认使用Keep-Alive机制（也叫持久化连接），可以使得多个HTTP请求共用一个底层的TCP连接。
	正常情况下，客户端发送单个HTTP请求后，会发送RST报文主动断开连接：		正常情况下，客户端发送单个HTTP请求后，会发送RST报文主动断开连接：

Riguz：/* HTTP 1.0 */

2023-12-06T10:07:57Z

HTTP 1.0

@@ 第3行： / 第3行： @@
 = Implementations ==
 == HTTP 1.0 ==
 == HTTP 1.1 ==

Riguz：Created page with "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 == == HTTP 1.1 == ==..."

2023-12-06T07:39:02Z

Created page with "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 == == HTTP 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.

= Implementations ==
== HTTP 1.0 ==

== HTTP 1.1 ==

== HTTP 2.0 ==

== See also ==

* [[HTTP/1.1]]
* [[HTTP/2]]

[[Category:Network]]
[[Category:HTTP]]
[[Category:Protocol]]
[[Category:RFC]]

HTTP keep-alive - 版本历史

Riguz：​/* Keepalive with chunked transfer encoding */

2023年12月7日 (四) 11:36 Riguz

Riguz：​/* HTTP 2.0 */

Riguz：​/* HTTP 1.0 */

Riguz：​/* Implementations */

Riguz：​/* Implementations = */

Riguz：​/* HTTP 1.1 */

Riguz：​/* HTTP 1.0 */

Riguz：​/* HTTP 1.0 */

Riguz：/* Keepalive with chunked transfer encoding */

Riguz：/* HTTP 2.0 */

Riguz：/* HTTP 1.0 */

Riguz：/* Implementations */

Riguz：/* Implementations = */

Riguz：/* HTTP 1.1 */

Riguz：/* HTTP 1.0 */

Riguz：/* HTTP 1.0 */