HTTP |
---|
Request methods |
Header fields |
Response status codes |
Security access control methods |
Security vulnerabilities |
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. [1] 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, [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.
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.
Pipelining was introduced in HTTP/1.1 and was not present in HTTP/1.0. [11]
There have always been complaints about browsers, proxy servers, etc. not working well when using pipelined requests / responses, up to the point that for many years (at least till 2011) software developers, engineers, web experts, etc. tried to summarize the various kind of problems they noted, to fix things and to give advices about how to deal with pipelining on the Open Web. [8]
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]
Most HTTP proxies do not pipeline outgoing requests. [19]
Some HTTP proxies, including transparent HTTP proxies, may manage pipelined requests very badly (e.g. by mixing up the order of pipelined responses). [20]
Some versions of the Squid web proxy will pipeline up to two outgoing requests. This functionality has been disabled by default and needs to be manually enabled for "bandwidth management and access logging reasons". [21] Squid supports multiple requests from clients.
The Polipo proxy pipelines outgoing requests. [22]
Tempesta FW, an open source application delivery controller, [23] also pipelines requests to backend servers. [24]
The libwww library made by the World Wide Web Consortium (W3C), supports pipelining since version 5.1 released at 18 February 1997. [25]
Other application development libraries that support HTTP pipelining include:
System.Net.HttpWebRequest
. [27] QNetworkRequest
, introduced in 4.4. [28] Some other applications currently exploiting pipelining are:
Testing tools which support HTTP pipelining include:
The Gopher protocol is a communication protocol designed for distributing, searching, and retrieving documents in Internet Protocol networks. The design of the Gopher protocol and user interface is menu-driven, and presented an alternative to the World Wide Web in its early stages, but ultimately fell into disfavor, yielding to Hypertext Transfer Protocol (HTTP). The Gopher ecosystem is often regarded as the effective predecessor of the World Wide Web.
HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.
In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource. It improves privacy, security, and possibly performance in the process.
Squid is a caching and forwarding HTTP web proxy. It has a wide variety of uses, including speeding up a web server by caching repeated requests, caching World Wide Web (WWW), Domain Name System (DNS), and other network lookups for a group of people sharing network resources, and aiding security by filtering traffic. Although used for mainly HTTP and File Transfer Protocol (FTP), Squid includes limited support for several other protocols including Internet Gopher, Secure Sockets Layer (SSL), Transport Layer Security (TLS), and Hypertext Transfer Protocol Secure (HTTPS). Squid does not support the SOCKS protocol, unlike Privoxy, with which Squid can be used in order to provide SOCKS support.
Integrated Windows Authentication (IWA) is a term associated with Microsoft products that refers to the SPNEGO, Kerberos, and NTLMSSP authentication protocols with respect to SSPI functionality introduced with Microsoft Windows 2000 and included with later Windows NT-based operating systems. The term is used more commonly for the automatically authenticated connections between Microsoft Internet Information Services, Internet Explorer, and other Active Directory aware applications.
The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.
A proxy auto-config (PAC) file defines how web browsers and other user agents can automatically choose the appropriate proxy server for fetching a given URL.
HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.
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.
SPDY is an obsolete open-specification communication protocol developed for transporting web content. SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.
Polipo is a discontinued lightweight caching and forwarding web proxy server. It has a wide variety of uses, from aiding security by filtering traffic; to caching web, DNS and other computer network lookups for a group of people sharing network resources; to speeding up a web server by caching repeated requests. It can be configured to use on-disk cache and serve cached content when offline and perform various forms of content filtering.
WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.
Web performance refers to the speed in which web pages are downloaded and displayed on the user's web browser. Web performance optimization (WPO), or website optimization is the field of knowledge about increasing web performance.
HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The initial HTTP/2 specification was published as RFC 7540 on May 14, 2015.
HTTP/2 Server Push is an optional feature of the HTTP/2 and HTTP/3 network protocols that allows servers to send resources to a client before the client requests them. Server Push is a performance technique aimed at reducing latency by sending resources to a client preemptively before it knows they will be needed. In practice, Server Push frequently results in wasted bandwidth because the server rarely knows which resources are already loaded by the client and transmits the same resource multiple times, resulting in slowdowns if the resources being pushed compete for bandwidth with resources that were requested.
DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States. In May 2020, Chrome switched to DNS over HTTPS by default.
HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP, HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP.
{{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help){{cite journal}}
: Cite journal requires |journal=
(help)