HTTP pipelining - Wikipedia

Jump to content

Search

Search

Donate

Create account

Log in

Personal tools

Donate

Create account

Log in

HTTP pipelining

12 languages

Català<br>Deutsch<br>فارسی<br>Français<br>Magyar<br>Italiano<br>日本語<br>한국어<br>Polski<br>Русский<br>Українська<br>中文

Edit links

From Wikipedia, the free encyclopedia

Computer communication technique

Time diagram of non-pipelined vs. pipelined connection<br>HTTP<br>Persistence

Compression

HTTPS

QUIC

Request methods<br>OPTIONS

GET

HEAD

POST

PUT

DELETE

TRACE

CONNECT

PATCH

Header fields<br>Cookie

ETag

Location

HTTP referer

DNT

X-Forwarded-For

Upgrade

Response status codes<br>301 Moved Permanently

302 Found

303 See Other

403 Forbidden

404 Not Found

451 Unavailable for Legal Reasons

Security access control methods<br>Basic access authentication

Digest access authentication

Security vulnerabilities<br>HTTP header injection

HTTP request smuggling

HTTP response splitting

HTTP parameter pollution

HTTP pipelining is a feature of HTTP/1.1 that allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses.[1] HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if the server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not support pipelining correctly, forcing most HTTP clients not to use HTTP pipelining.

The technique was superseded by multiplexing via HTTP/2,[2] which is supported by most modern browsers.[3]

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.

Motivation and limitations<br>[edit]

The pipelining of requests results in a dramatic improvement[4] in the loading times of HTML pages, especially over high latency connections such as satellite Internet connections. The speedup is less apparent on broadband connections, as the limitation of HTTP 1.1 still applies: the server must send its responses in the same order that the requests were received—so the entire connection remains first-in-first-out[1] and HOL blocking can occur.

The asynchronous operations of HTTP/2 and SPDY are solution for this.[5] By 2017 most browsers supported HTTP/2 by default which uses multiplexing instead.[2]

Non-idempotent requests such as POST should not be pipelined.[6] Read requests like GET and HEAD can always be pipelined. A sequence of other idempotent requests like PUT and DELETE can be pipelined or not depending on whether requests in the sequence depend on the effect of others.[1]

HTTP pipelining requires both the client and the server to support it. HTTP/1.1 conforming servers are required to produce valid responses to pipelined requests, but may not actually process requests concurrently.[7]

Most pipelining problems happen in HTTP intermediate nodes (hop-by-hop), i.e. in proxy servers, especially in transparent proxy servers (if one of them along the HTTP chain does not handle pipelined requests properly then nothing works as it should).[8]

Using pipelining with HTTP proxy servers is usually not recommended also because the HOL blocking problem may really slow down proxy server responses (as the server responses must be in the same order of the received requests).[1][9]

Example : if a client sends 4 pipelined GET requests to a proxy through a single connection and the first one is not in its cache then the proxy has to forward that request to the destination web server; if the following three requests are instead found in its cache, the proxy has to wait for the web server response, then it has to send it to the client and only then it can send the three cached responses too.

If instead a client opens 4 connections to a proxy and sends 1 GET request per connection (without using pipelining) the proxy can send the three cached responses to client in parallel before the response from server is received, decreasing the overall completion time (because requests are served in parallel with no head-of-line blocking problem).[10] The same advantage exists in HTTP/2 multiplexed streams.

Implementation status<br>[edit]

Pipelining was introduced in HTTP/1.1 and was not present in HTTP/1.0.[11]

Implementation in web browsers<br>[edit]

Of all the major browsers, only Opera had a fully working implementation that was enabled by default. In other browsers HTTP pipelining was disabled or not implemented.[5]

Internet Explorer 8 does not support pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.[9]

Internet Explorer 11 does not support pipelining.[12]

Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino) used to support pipelining; however, it was removed in Firefox 54.[13] When it was supported, pipelining was disabled by default to avoid issues with misbehaving servers.[14] If pipelining was enabled by the user, Mozilla browsers used some heuristics,...