HyperText Transfer Protocol (HTTP)

HTTP is a request-response protocol that governs the communication between web browsers and servers, allowing for the retrieval and transfer of web pages and other resources over the [internet].

HTTP is specified by the IETF (Internet Engineering Task Force).

HTTP methods

HTTP methods define actions to be performed on the resource identified by the request URI. The most common methods are:

  • GET: Used to retrieve information from the server. It should not modify the state of the resource, making it ideal for read operations without side effects. Example: fetching a list of users, or details about a specific user.

  • POST: Used to create a new resource. It is useful when the result of a request creates a state change or side effects on the server. Example: creating a new user.

  • PUT: Used to update or replace an existing resource. It’s important to send the complete entity in the request. Example: updating an existing user’s name and age.

  • PATCH: Unlike PUT, PATCH is used to make partial updates on a resource. Example: updating the name of a user without touching other fields like age.

  • DELETE: Used to delete a resource. Example: deleting a user.

HTTP response codes

Common status codes returned by the server in response to a client request include:

  • 1xx: Informational response codes.

    • 100 Continue*: Indicates that the initial part of the request has been received and the client should continue sending the rest of the request.

  • 2xx: Success response codes.

    • 200 OK: The request has been successful. This is the most commonly used code to indicate success.

    • 201 Created: The request has been fulfilled and as a result a new resource has been created.

    • 204 No Content: The request has been successfully completed, but there is no content to send in the response.

  • 3xx: Redirection response codes.

    • 301 Moved Permanently: The resource of the requested URL has been changed permanently. The new URL should be specified in the response.

    • 302 Found: Indicates that the request resources is temporarily under a different URL.

  • 4xx: Client error response codes.

    • 400 Bad Request: The request cannot be understood or processed by the server due to a client syntax error.

    • 401 Unauthorized: Indicates that the request requires authentication and the client has not authenticated itself.

    • 403 Forbidden: The server understood the request but is refusing to authorize it.

    • 404 Not Found: The server could not find the requested resource.

    • 405 Method Not Allowed: The HTTP method used in the request is not allowed for the specified resource.

  • 5xx: Server error response codes.

    • 500 Internal Server Error: The server encountered a situation it doesn’t know how to handle.

    • 502 Bad Gateway: The server, while acting as a gateway or proxy, received an invalid response from the upstream server.

    • 503 Service Unavailable: The server is not ready to handle the request, typically due to maintenance or overload.

The HTTP request/response cycle

When a browser (or any HTTP client) makes a request to, say, https://example.com/page, the following sequence occurs:

1. DNS resolution

The client first needs to translate the hostname (example.com) into an IP address. It checks its local DNS cache, then queries a recursive DNS resolver (typically provided by the OS or ISP), which in turn queries authoritative DNS servers if the address is not cached. The result is an IP address (e.g. 93.184.216.34) and a TTL indicating how long to cache it.

2. TCP connection (three-way handshake)

With an IP address in hand, the client opens a TCP connection to the server on port 443 (HTTPS) or port 80 (HTTP). TCP uses a three-way handshake to establish the connection:

  1. SYN — client sends a synchronize segment to the server.

  2. SYN-ACK — server acknowledges and sends its own synchronize.

  3. ACK — client acknowledges; the connection is now established.

This handshake incurs one full round-trip before any data can be sent.

3. TLS handshake (HTTPS only)

For HTTPS, a TLS handshake takes place over the established TCP connection to negotiate encryption:

  1. The client sends a ClientHello with supported TLS versions and cipher suites.

  2. The server responds with its chosen cipher suite and its digital certificate (containing its public key).

  3. The client verifies the certificate against a trusted Certificate Authority (CA).

  4. The two parties exchange or derive a shared symmetric session key.

  5. Both sides confirm the handshake is complete; all subsequent data is encrypted.

TLS 1.3 (current standard) reduces this to a single round-trip, compared to two round-trips for TLS 1.2.

4. HTTP request

With a secure channel established, the client sends an HTTP request. It consists of:

  • Request line: method, path, and HTTP version — e.g. GET /page HTTP/1.1.

  • Headers: metadata such as Host, Accept, Authorization, Cookie, Content-Type, and User-Agent.

  • Body (optional): present for POST, PUT, and PATCH requests, containing the payload.

5. Server processing and HTTP response

The server receives the request, processes it (routing it through application logic, querying databases, etc.), and returns an HTTP response consisting of:

  • Status line: HTTP version and status code — e.g. HTTP/1.1 200 OK.

  • Headers: metadata such as Content-Type, Content-Length, Set-Cookie, Cache-Control, and Location.

  • Body (optional): the response payload — HTML, JSON, binary data, etc.

6. Connection handling

  • HTTP/1.1: Connections are kept alive by default (Connection: keep-alive), allowing multiple requests to reuse the same TCP connection and avoid repeated handshakes. However, each request must complete before the next can begin (head-of-line blocking).

  • HTTP/2: Multiplexes multiple requests over a single connection simultaneously, eliminating head-of-line blocking at the HTTP layer.

  • HTTP/3: Uses QUIC (UDP-based) instead of TCP, which eliminates head-of-line blocking at the transport layer and reduces connection establishment overhead.

The connection is eventually closed either by the client or server sending a Connection: close header or after an idle timeout.

Performance implications

The full cycle for a first HTTPS request to a new host involves: DNS lookup + TCP handshake + TLS handshake + HTTP request/response — potentially three or more round trips before the first byte of content is received. Techniques to reduce this include:

  • DNS caching and pre-fetching: Browsers cache DNS results and can pre-resolve hosts referenced in a page.

  • Connection reuse and pooling: Keep-alive and HTTP/2 multiplexing avoid the cost of repeated TCP/TLS handshakes.

  • TLS session resumption: TLS session tickets allow a reconnecting client to skip the full handshake.

  • CDNs: Terminating TLS at an edge server geographically close to the user reduces round-trip time.

See Also