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.
- HTTP/2 (2015) and HTTP/3 (2019) do not make previous versions of the protocol obsolete.
HTTP functions as a request-response protocol in the client-server computing model. A web browser for example, may be the client and an application running on a computer hosting a website may be the server.
The server provides resources such as HTML files and other content, or performes other functions on
behalf of the client, returning 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. However
both a web browser and a mobile app are user agents, as indeed is any 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 servers to improve response time. Web browsers cache previously accessed
web resources and reuse them, when possible, to reduce network traffic.
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, and
Transmission Control Protocol (TCP) is commonly
used. However, HTTP can be adapted to use unreliable protocols such as the
Universal Datagram Protocol (UDP), for example in HTTPU and
Simple Service Discovery Protocol (SSDP), and in in HTTP/3 which use UDP instead of TCP.
userinfo host port
┌───────┴───────┐ ┌────┴────────┐ ┌┴┐
scheme authority path query fragment
An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server (typically
port 80, occasionally port 8080). An HTTP server listening on that port waits for a client's request
message. Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a
message of its own. The body of this message is typically the requested resource, although an error message
or other information may also be returned.
In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request. Such
persistent connections reduce request latency perceptibly, because the client does not need to re-negotiate
the 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 slow-start-mechanism.
Version 1.1 of the protocol also made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed rather than
buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before
waiting for each response. Another addition to the protocol was byte serving, where a server transmits
just the portion of a resource explicitly requested by a client.
HTTP session state
HTTP is a stateless protocol. A stateless protocol does not require the HTTP server to retain information or status about each user for the duration of multiple requests. However, some web applications implement
states or server side sessions using for instance HTTP cookies or hidden variables within web forms.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network. In HTTPS, the communication protocol is encrypted
using Transport Layer Security (TLS), or, formerly, its predecessor, Secure Sockets Layer (SSL). The
protocol is therefore also often referred to as HTTP over TLS, or HTTP over SSL.
The principal motivation for HTTPS is authentication of the accessed website and protection of the privacy and integrity of the exchanged data while in transit. It protects against man-in-the-middle attacks. The
bidirectional encryption of communications between a client and server protects against eavesdropping and
tampering of the communication. In practice, this provides a reasonable assurance that one is communicating
without interference by attackers with the website that one intended to communicate with, as opposed to an
Historically, HTTPS connections were primarily used for payment transactions on the World Wide Web, e-mail and for sensitive transactions in corporate information systems. Since 2018, HTTPS is used more often by web
users than the original non-secure HTTP, primarily to protect page authenticity on all types of websites;
secure accounts; and keep user communications, identity, and web browsing private.
HTTPS creates a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server
certificate is verified and trusted.
Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request URL (which particular web page was requested), query parameters,
headers, and cookies (which often contain identity information about the user). However, because host
(website) addresses and port numbers are necessarily part of the underlying TCP/IP protocols, HTTPS cannot
protect their disclosure. In practice this means that even on a correctly configured web server,
eavesdroppers can infer the IP address and port number of the web server (sometimes even the domain name
e.g. www.example.org, but not the rest of the URL) that one is communicating with, as well as the amount
(data transferred) and duration (length of session) of the communication, though not the content of the
TCP head-of-line blocking
Although the design of HTTP/2 effectively addresses the HTTP-transaction-level head-of-line blocking problem by allowing multiple concurrent HTTP transactions, all those transactions are multiplexed over a single
TCP connection, meaning that any packet-level head-of-line blocking of the TCP stream simultaneously blocks
all transactions being accessed via that connection. This head-of-line blocking in HTTP/2 is now widely
regarded as a design flaw, and much of the effort behind QUIC and HTTP/3 has been devoted to reduce
head-of-line blocking issues.