HTTP pipelining：修订间差异
无编辑摘要 |
无编辑摘要 |
||
| （未显示同一用户的8个中间版本） | |||
| 第1行： | 第1行： | ||
HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. | HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. | ||
HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, many legacy [[HTTP/1.1]] servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining. | HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, '''many legacy [[HTTP/1.1]] servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining'''. | ||
The technique was superseded by multiplexing via [[HTTP/2]], which is supported by most modern browsers. | The technique was superseded by '''multiplexing''' via [[HTTP/2]], which is supported by most modern browsers. | ||
In [[HTTP/3]], multiplexing is accomplished via [[QUIC]] which replaces [[TCP]]. This further reduces loading time, as there is no [[Head-of-line blocking]] even if some packets are lost. | |||
[[Image:Bonus1_H1_pipelining.png|600px|border]] | |||
Crucially however, this pipelining only applies to the requests from the browser. As the HTTP/1.1 specification says: | |||
<blockquote>A server MUST send its responses to those [pipelined] requests in the same order that the requests were received.</blockquote> | |||
As such, we see that actual multiplexing of response chunks is still not possible with HTTP/1.1 pipelining. Put differently: pipelining solves HOL blocking for requests, but not for responses. Sadly, it’s arguably the response HOL blocking that causes the most issues for Web performance. | |||
<ref>https://calendar.perfplanet.com/2020/head-of-line-blocking-in-quic-and-http-3-the-details/</ref> | |||
[[Category:Network]] | [[Category:Network]] | ||
2023年12月8日 (五) 07:21的最新版本
HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses.
HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining.
The technique was superseded by multiplexing via HTTP/2, which is supported by most modern browsers.
In HTTP/3, multiplexing is accomplished via QUIC which replaces TCP. This further reduces loading time, as there is no Head-of-line blocking even if some packets are lost.
Crucially however, this pipelining only applies to the requests from the browser. As the HTTP/1.1 specification says:
A server MUST send its responses to those [pipelined] requests in the same order that the requests were received.
As such, we see that actual multiplexing of response chunks is still not possible with HTTP/1.1 pipelining. Put differently: pipelining solves HOL blocking for requests, but not for responses. Sadly, it’s arguably the response HOL blocking that causes the most issues for Web performance. [1]