Editing HTTP (section)

=== Persistent connections ===
{{Main|HTTP persistent connection}}
In '''HTTP/0.9''', the TCP/IP connection is always closed after server response has been sent, so it is never persistent.

In '''HTTP/1.0''', as stated in RFC 1945, the TCP/IP connection should always be closed by server after a response has been sent.{{refn|group=note|Since late 1996, some developers of popular HTTP/1.0 browsers and servers (specially those who had planned support for HTTP/1.1 too), started to deploy (as an unofficial extension) a sort of keep-alive-mechanism (by using new HTTP headers) in order to keep the TCP/IP connection open for more than a request/response pair and so to speed up the exchange of multiple requests/responses.<ref name="HTTP-Persistent-Connections">{{Cite book|url=https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch04s05.html|title=HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections")|author1=David Gourley|author2=Brian Totty|author3=Marjorie Sayer|author4=Anshu Aggarwal|author5=Sailu Reddy|language=en|publisher=O'Reilly Media, inc.|isbn=9781565925090|year=2002|access-date=2021-10-18}}</ref>}}

In '''HTTP/1.1''' a keep-alive-mechanism was officially introduced so that a connection could be reused for more than one request/response. Such persistent connections reduce request [[Network latency|latency]] perceptibly because the client does not need to re-negotiate the [[Transmission Control Protocol#Connection establishment|TCP 3-Way-Handshake connection]] after the first request has been sent. Another positive side effect is that, in general, the connection becomes faster with time due to TCP's [[TCP congestion control#Slow start|slow-start]]-mechanism.

'''HTTP/1.1''' added also [[HTTP pipelining]] in order to further reduce lag time when using persistent connections by allowing clients to send multiple requests before waiting for each response.  This optimization was never considered really safe because a few web servers and many [[proxy server]]s, specially transparent proxy servers placed in Internet / [[Intranet]]s between clients and servers, did not handle pipelined requests properly (they served only the first request discarding the others, they closed the connection because they saw more data after the first request or some proxies even returned responses out of order etc.).  Because of this, only HEAD and some GET requests (i.e. limited to real file requests and so with [[URL]]s without query string used as a command, etc.) could be pipelined in a [[#Safe methods|safe]] and [[#Idempotent methods|idempotent]] mode.  After many years of struggling with the problems introduced by enabling pipelining, this feature was first disabled and then removed from most browsers also because of the announced adoption of HTTP/2.

'''HTTP/2''' extended the usage of persistent connections by multiplexing many concurrent requests/responses through a single TCP/IP connection.

'''HTTP/3''' does not use TCP/IP connections but QUIC + UDP (see also: [[#Technical overview|technical overview]]).