Web Protocols: HTTP, HTTPS, and DoH
The web runs on a stack of protocols that enable browsers, servers, and applications to communicate. Understanding how HTTP, HTTPS, HTTP/2, HTTP/3, WebSocket, and DoH work is essential for diagnosing connectivity issues, optimizing performance, and securing communications.
Table of Contents
1. HTTP Request and Response
HTTP (Hypertext Transfer Protocol) is a stateless, request-response protocol. A client sends a request, and the server returns a response. Each exchange is independent, though mechanisms like cookies and sessions provide statefulness at the application layer.
HTTP Request:
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: en-US
Connection: keep-aliveHTTP Response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
Date: Mon, 30 Jun 2025 12:00:00 GMT
Server: nginx/1.24.0
<!DOCTYPE html>
<html>...</html>Every HTTP message consists of a start line, headers, an empty line, and an optional body. Requests include the method, path, and HTTP version. Responses include the status code and reason phrase.
2. HTTP Methods
| Method | Purpose | Idempotent | Has Body | Safe |
|---|---|---|---|---|
| GET | Retrieve a resource | Yes | No | Yes |
| POST | Submit data / create resource | No | Yes | No |
| PUT | Replace a resource entirely | Yes | Yes | No |
| PATCH | Partially update a resource | No | Yes | No |
| DELETE | Remove a resource | Yes | Optional | No |
| HEAD | Same as GET but no body returned | Yes | No | Yes |
| OPTIONS | Describe communication options | Yes | No | Yes |
| TRACE | Loop-back test | Yes | No | Yes |
Idempotent means multiple identical requests produce the same result. Safe means the request does not modify server state. Understanding these properties is important for designing reliable APIs and handling retries correctly.
3. HTTP Status Codes
| Code | Category | Meaning | Common Use |
|---|---|---|---|
| 200 | Success | OK | Standard success response |
| 201 | Success | Created | Resource created (POST) |
| 204 | Success | No Content | Success with no body |
| 301 | Redirect | Moved Permanently | Permanent URL change |
| 302 | Redirect | Found | Temporary redirect |
| 304 | Redirect | Not Modified | Cache validation |
| 400 | Client Error | Bad Request | Invalid syntax |
| 401 | Client Error | Unauthorized | Authentication required |
| 403 | Client Error | Forbidden | Access denied |
| 404 | Client Error | Not Found | Resource does not exist |
| 429 | Client Error | Too Many Requests | Rate limiting |
| 500 | Server Error | Internal Server Error | Generic server failure |
| 502 | Server Error | Bad Gateway | Invalid upstream response |
| 503 | Server Error | Service Unavailable | Server overloaded or down |
| 504 | Server Error | Gateway Timeout | Upstream server timeout |
4. Common HTTP Headers
Request headers:
| Header | Purpose | Example |
|---|---|---|
| Host | Target hostname (required in HTTP/1.1) | Host: www.example.com |
| User-Agent | Client software identifier | User-Agent: Mozilla/5.0 ... |
| Accept | Preferred response content types | Accept: text/html, application/json |
| Authorization | Authentication credentials | Authorization: Bearer eyJhb... |
| Cookie | Stored cookies | Cookie: session=abc123 |
| If-None-Match | Cache validation (ETag) | If-None-Match: "etag123" |
Response headers:
| Header | Purpose | Example |
|---|---|---|
| Content-Type | Response body type | Content-Type: text/html; charset=UTF-8 |
| Cache-Control | Caching directives | Cache-Control: max-age=3600 |
| Set-Cookie | Store a cookie | Set-Cookie: id=abc; HttpOnly; Secure |
| Strict-Transport-Security | Force HTTPS | Strict-Transport-Security: max-age=31536000 |
| Access-Control-Allow-Origin | CORS policy | Access-Control-Allow-Origin: https://app.com |
| ETag | Resource version identifier | ETag: "etag123" |
5. HTTPS and the TLS Handshake
HTTPS is HTTP over TLS (Transport Layer Security). It encrypts the communication between client and server, providing confidentiality, integrity, and authentication.
TLS 1.3 handshake (1-RTT):
Client Server
|--- ClientHello + KeyShare --------->|
| (supported ciphers, ECDHE key) |
|<-- ServerHello + KeyShare ----------|
| + EncryptedExtensions |
| + Certificate |
| + CertificateVerify |
| + Finished |
|--- Finished ----------------------->|
|<========= Application Data ========|What happens during the handshake:
- ClientHello: Client sends supported cipher suites, TLS version, and a random number.
- ServerHello: Server selects cipher suite, sends its certificate and ECDHE key share.
- Certificate verification: Client validates the server's certificate chain against trusted CAs.
- Key derivation: Both parties derive the same session keys from the ECDHE shared secret.
- Finished: Both parties confirm the handshake completed successfully.
All data after the handshake is encrypted with symmetric keys derived during key exchange. TLS 1.3 achieves this in a single round trip (1-RTT), compared to 2-RTT in TLS 1.2.
6. HTTP/2
HTTP/2 (RFC 7540, 2015) is a major revision that improves performance while maintaining backward compatibility with HTTP/1.1 semantics.
Key features:
- Multiplexing: Multiple requests and responses over a single TCP connection simultaneously, eliminating head-of-line blocking at the HTTP layer.
- Binary framing: Messages are split into binary frames, which are more efficient to parse than text.
- Header compression (HPACK): Reduces overhead by compressing repeated headers.
- Server push: Server can proactively send resources the client will need (e.g., CSS, JS for an HTML page).
- Stream prioritization: Clients can indicate which resources are more important.
Limitation: HTTP/2 still runs over TCP, so packet loss at the TCP level blocks all streams (TCP head-of-line blocking). HTTP/3 addresses this.
7. HTTP/3 and QUIC
HTTP/3 (RFC 9114, 2022) replaces TCP with QUIC (RFC 9000), a UDP-based transport protocol designed by Google.
Key advantages:
- No TCP head-of-line blocking: Each stream is independent; packet loss on one stream does not affect others.
- Built-in encryption: TLS 1.3 is integrated into QUIC, not layered on top.
- 0-RTT connection establishment: Returning clients can send data immediately.
- Connection migration: Connections survive IP address changes (e.g., switching from Wi-Fi to cellular).
- Improved congestion control: More responsive to network conditions.
Adoption: HTTP/3 is supported by Chrome, Firefox, Safari, Edge, Cloudflare, Google, Facebook, and most major CDNs. Over 30% of web traffic uses HTTP/3 as of 2025.
8. WebSocket and DoH
WebSocket (RFC 6455) provides full-duplex, persistent communication over a single TCP connection. Unlike HTTP's request-response model, either side can send messages at any time.
WebSocket handshake:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=After the handshake, the connection switches from HTTP to the WebSocket protocol. Messages are framed with minimal overhead (2–14 bytes of framing per message).
Use cases: Real-time chat, live dashboards, multiplayer games, collaborative editing, stock tickers, IoT device communication.
DNS over HTTPS (DoH): DoH (RFC 8484) sends DNS queries as HTTPS requests, encrypting them to prevent surveillance and tampering. It uses standard HTTP/2 or HTTP/3 connections to DNS resolvers like https://cloudflare-dns.com/dns-query. Browsers like Firefox and Chrome support DoH natively, and operating systems are increasingly adding support.