Editing HTTP (section)

==Technical overview==
HTTP functions as a [[request–response]] protocol in the [[client–server model]]. A [[web browser]], for example, may be the ''client'' whereas a [[process (computing)|process]], named [[web server]], running on a computer [[Host (network)|hosting]] one or more [[website]]s may be the ''server''. The client submits an HTTP ''request'' message to the server. The server, which provides ''resources'' such as [[HTML]] files and other content or performs other functions on behalf of the client, returns a ''response'' message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

A web browser is an example of a ''[[user agent]]'' (UA). Other types of user agent include the indexing software used by search providers ([[web crawler]]s), [[voice browser]]s, [[mobile app]]s, and other [[software]] that accesses, consumes, or displays web content.

HTTP is designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from [[web cache]] servers that deliver content on behalf of [[upstream server]]s to improve response time. Web browsers cache previously accessed web resources and reuse them, whenever possible, to reduce network traffic. HTTP [[proxy server]]s at [[private network]] boundaries can facilitate communication for clients without a globally routable address, by relaying messages with external servers.

To allow intermediate HTTP nodes (proxy servers, web caches, etc.) to accomplish their functions, some of the [[List of HTTP header fields|HTTP headers]] (found in HTTP requests/responses) are managed [[hop-by-hop transport|hop-by-hop]] whereas other HTTP headers are managed [[end-to-end principle|end-to-end]] (managed only by the source client and by the target web server).

HTTP is an [[application layer]] protocol designed within the framework of the [[Internet protocol suite]]. Its definition presumes an underlying and reliable [[transport layer]] protocol.<ref name="rfc9110-3.3" /> In [[HTTP/3]], the [[Transmission Control Protocol]] (TCP) is no longer used, but the older versions are still more used and they most commonly use TCP. They have also been adapted to use unreliable protocols such as the [[User Datagram Protocol]] (UDP), which HTTP/3 also (indirectly) always builds on, for example in [[HTTPU]] and [[Simple Service Discovery Protocol]] (SSDP).

[[Web resource|HTTP resources]] are identified and located on the network by [[Uniform Resource Locator]]s (URLs), using the [[Uniform Resource Identifier]]s (URIs) schemes ''http'' and ''[[https]]''. As defined in {{IETF RFC|3986}}, URIs are encoded as [[hyperlink]]s in [[HTML]] documents, so as to form interlinked [[hypertext]] documents.

In HTTP/1.0 a separate TCP [[connection-oriented communication|connection]] to the same server is made for every resource request.<ref name="rfc1945-1.3">{{cite IETF |rfc=1945 |sectionname=Overall Operation |section=1.3 |title=RFC 1945|pages=6–8}}</ref>

In HTTP/1.1 instead a TCP connection can be reused to make multiple resource requests (i.e. of HTML pages, frames, images, [[Client-side scripting|scripts]], [[Cascading Style Sheets|stylesheets]], etc.).<ref name="rfc9112-9.1" /><ref name="rfc9112-9.3">{{cite IETF |rfc=9112 |sectionname=Connection Management: Persistence |section=9.3 |title=RFC 9112, HTTP/1.1}}</ref>

HTTP/1.1 communications therefore experience less [[network latency|latency]] as the establishment of TCP connections presents considerable overhead, especially under high traffic conditions.<ref>{{cite web |url=https://www.w3.org/Protocols/Classic.html |title=Classic HTTP Documents |publisher=W3.org |date=1998-05-14 |access-date=2010-08-01}}</ref>

[[HTTP/2]] is a revision of previous HTTP/1.1 in order to maintain the same client–server model and the same protocol methods but with these differences in order:
* to use a compressed binary representation of metadata (HTTP headers) instead of a textual one, so that headers require much less space;
* to use a single [[Internet Protocol suite|TCP/IP]] (usually [[encryption|encrypted]]) connection per accessed server domain instead of 2 to 8 TCP/IP connections;
* to use one or more bidirectional streams per TCP/IP connection in which HTTP requests and responses are broken down and transmitted in small packets to almost solve the problem of the HOLB ([[head-of-line blocking]]).{{refn|group=note|In practice, these streams are used as multiple TCP/IP sub-connections to [[multiplexing|multiplex]] concurrent requests/responses, thus greatly reducing the number of real TCP/IP connections on server side, from 2..8 per client to 1, and allowing many more clients to be served at once.}}
* to add a push capability to allow server application to send data to clients whenever new data is available (without forcing clients to request periodically new data to server by using [[Polling (computer science)|polling]] methods).<ref name="rfc9113-2">{{cite IETF |rfc=7540 |section=2 |sectionname=HTTP/2 Protocol Overview| title=RFC 9113, HTTP/2)}}</ref>

HTTP/2 communications therefore experience much less latency and, in most cases, even higher speeds than HTTP/1.1 communications.

[[HTTP/3]] is a revision of previous HTTP/2 in order to use [[QUIC]] + UDP transport protocols instead of TCP. Before that version, TCP/IP connections were used; but now, only the IP layer is used (which UDP, like TCP, builds on). This slightly improves the average speed of communications and to avoid the occasional (very rare) problem of TCP connection [[TCP congestion control|congestion]] that can temporarily block or slow down the data flow of all its streams (another form of "''head of line blocking''").