ReviseAlgo Logo

Networking & Web Fundamentals

HTTP & HTTPS

The request/response protocol of the web and its TLS-encrypted, authenticated form.

In short

The request/response protocol of the web and its TLS-encrypted, authenticated form.

HTTP (HyperText Transfer Protocol) is the application-layer protocol the web runs on. A client sends a request (a method like GET or POST, a path, headers, and an optional body) and the server returns a response (a status code, headers, and a body). HTTP is stateless — each request is independent.

HTTPS is HTTP layered over TLS (Transport Layer Security). It encrypts the traffic so no one in between can read or tamper with it, and it authenticates the server via a certificate so the client knows it is talking to the real site.

1. Learning Objectives

By the end of this lesson, you will be able to:

  • Analyze the request/response structure of the HTTP protocol, including methods, headers, and status codes.
  • Explain the cryptographic mechanics of HTTPS, detailing how symmetric encryption, asymmetric encryption, and digital certificates work together.
  • Trace the step-by-step execution of TLS 1.2 and TLS 1.3 handshakes, calculating round-trip time (RTT) overhead.
  • Contrast HTTP/1.1, HTTP/2, and HTTP/3 in terms of multiplexing, header compression, and Head-of-Line (HoL) blocking.
  • Design systems utilizing connection pooling, TLS session resumption, and HTTP Strict Transport Security (HSTS) to balance performance and security.

2. Prerequisites

To fully grasp the concepts in this lesson, you should be familiar with:

  • Basic Networking: The client-server model, ports, sockets, and IP routing.
  • TCP/IP Basics: The three-way handshake (SYN, SYN-ACK, ACK) and reliable packet delivery.
  • Security Fundamentals: Symmetric key encryption (shared secret) versus asymmetric key encryption (public/private key pairs) and cryptographic hashing.

3. Why This Topic Matters

In system design, HTTP is the primary transport protocol for web traffic, REST APIs, GraphQL, and microservice communications. Understanding its strengths and bottlenecks dictates how you scale systems. Without a deep understanding of HTTP and TLS, system designers face critical flaws:

  • Security Risks: Transmitting credentials or sensitive data over unencrypted HTTP exposes systems to man-in-the-middle (MITM) attacks and data tampering.
  • Latency Bottlenecks: Improper TLS configurations can add hundreds of milliseconds of overhead due to unnecessary cryptographic handshakes.
  • Scaling Failures: Underestimating connection limits, ignoring HTTP/2 multiplexing, or neglecting Head-of-Line blocking can collapse high-throughput API gateways and CDNs under load.

4. Real-world Analogy

Imagine sending a message through a courier service:

HTTP is like sending a handwritten postcard. Anyone along the delivery route (postal workers, delivery drivers, nosy neighbors) can read the message, modify it, or rewrite it entirely before it reaches the recipient. Worse, anyone can write a postcard and sign it with a fake name, and the recipient has no easy way to prove who actually sent it.

HTTPS is like putting the message into a locked, tamper-proof, steel lockbox. The key to unlock it is safely negotiated between you and the recipient. The lockbox is delivered by an armored transport vehicle. Attached to the box is a certificate of authenticity signed by a globally recognized notary (a Certificate Authority). The recipient can verify the notary's seal to prove that the box came from you, and they can be absolutely sure the contents have not been altered or read by anyone in transit.

5. Core Concepts

Before analyzing the request lifecycle, we must understand the fundamental building blocks of HTTP and HTTPS:

HTTP Protocol Characteristics

HTTP is an application-layer, text-based (up to HTTP/1.1) or binary (HTTP/2 and HTTP/3) protocol. It has two main traits:

  • Statelessness: Each request-response cycle is independent. The protocol itself does not retain session memory. Session states are maintained externally via cookies, tokens (JWTs), or server-side sessions.
  • Extensibility: Custom behavior is easily added through headers, which pass metadata alongside the request/response payloads.

HTTP Request Structure

An HTTP request consists of three components:

  1. Request Line: Contains the HTTP method (e.g., GET, POST, PUT, DELETE), target URL path (e.g., /api/v1/users), and HTTP version (e.g., HTTP/1.1).
  2. Headers: Key-value pairs providing metadata, such as content type, authorization credentials, caching directives, and cookies.
  3. Body: The payload of the request (optional, usually sent with POST, PUT, or PATCH).

HTTP Response Structure

An HTTP response mirrors the request structure:

  1. Status Line: Contains the HTTP version and a status code (e.g., 200 OK, 404 Not Found, 500 Internal Server Error).
  2. Headers: Server metadata, caching headers, content length, and instructions like cookie setting.
  3. Body: The returned data payload (HTML, JSON, XML, images, etc.).

HTTPS Security Architecture

HTTPS (HTTP Secure) is HTTP executing over a TLS (Transport Layer Security) session. It provides three guarantees:

  • Confidentiality: Encrypts the transmitted data, preventing eavesdroppers from reading it.
  • Integrity: Detects whether the data has been altered or tampered with in transit using Message Authentication Codes (MAC).
  • Authenticity: Proves that the client is talking to the legitimate owner of the domain name via cryptographic certificates issued by trusted Certificate Authorities (CAs).

6. Visualization

The diagrams below illustrate the differences in round-trip times (RTT) between a TLS 1.2 and a TLS 1.3 handshake over an established TCP connection.

TLS 1.2 Handshake (2 RTT Overhead)

TLS 1.3 Handshake (1 RTT Overhead)

7. How It Works

The lifecycle of an HTTPS connection consists of a highly orchestrated series of network steps:

  1. DNS Resolution: The client resolves the domain name (e.g., example.com) to an IP address using local DNS caches or authoritative name servers.
  2. TCP Connection (3-Way Handshake): The client establishes a reliable transport channel by sending a SYN packet, receiving a SYN-ACK from the server, and responding with an ACK (1 RTT).
  3. TLS Negotiation (The Handshake):
    • The client sends a ClientHello listing supported TLS versions, cryptographic cipher suites, and a random number (ClientRandom). In TLS 1.3, it also includes key share guesses.
    • The server replies with a ServerHello selecting the highest common TLS version and cipher suite, providing a ServerRandom, sending its SSL/TLS certificate, and establishing a shared key using Diffie-Hellman Key Exchange.
    • The client verifies the SSL/TLS certificate against its local trust store of root Certificate Authorities. It checks the certificate's domain name, expiration, and revocation status (via CRL or OCSP).
    • Once verified, both client and server generate the Session Keys (symmetric keys) derived from the random values and key exchange parameters.
  4. Encrypted Application Data Exchange: Both client and server encrypt all subsequent HTTP data (headers, paths, query parameters, body) using the symmetric session keys.
  5. Session Caching/Resumption: The client stores a session ticket or ID to bypass the full handshake on future connections.
  6. Connection Closure: A TLS alert protocol exchange (close_notify) gracefully terminates the cryptographic session before the TCP socket is closed.

8. Internal Architecture

To process HTTP and HTTPS requests at high throughput, modern client and server architectures decouple operations into specialized layers:

Component Primary Responsibility Key Failure Points
HTTP Parser & Router Parses raw bytes into HTTP requests, validates headers, and maps URLs to handler paths. Maliciously crafted header sizes, buffer overflows, and slowloris attacks (sending headers extremely slowly).
TLS Cryptographic Engine Executes key derivation, public key signature validation, and symmetric encryption/decryption (e.g., OpenSSL). CPU exhaustion due to intensive RSA/DH math, memory leaks in security libraries, and cipher mismatch errors.
Certificate Store Maintains a secure list of globally trusted Certificate Authorities (CAs) to validate incoming server identities. Outdated root certificate bundles causing trust validation failures on legitimate sites.
Session Cache & Ticket Store Caches TLS Session IDs (server-side) or decrypts client Session Tickets to allow fast 1-RTT/0-RTT reconnection. Memory consumption (for Session IDs), security compromise of Session Ticket Encryption Keys (STEK).
Socket & Transport Manager Manages the underlying TCP sockets (using epoll/kqueue) or UDP ports for HTTP/3 QUIC connections. File descriptor limits, socket starvation, Ephemeral Port Exhaustion, and TCP packet reordering bottlenecks.

9. Request Lifecycle

When an application triggers an HTTPS request (e.g., fetching data from https://api.example.com/v1/resource), the request progresses through the network stack chronologically:

Client-Side Serialization & Encryption

  1. Application Layer: The HTTP library serializes the request into standard HTTP format:
  • TLS Layer: The serialized string is sent to the TLS engine. The engine encrypts the payload, wrapping it inside a TLS Application Data record.
  • OS TCP/UDP Socket: The OS kernel writes the encrypted bytes to the socket. It segments them, attaches TCP headers (specifying Source Port and Destination Port 443), and schedules transmission.

    • Network Transit

    1. IP Routing: The OS wraps the TCP segment in an IP packet, appending source and destination IP addresses. The packet is dispatched over the physical network interface, hopping through routers and switches via BGP (Border Gateway Protocol) routing rules.

    Server-Side Decryption & Execution

    1. TLS Termination: The server's reverse proxy (e.g., Nginx, Envoy) reads the incoming bytes from the socket. Using the symmetric session key, the TLS engine decrypts the payload back into cleartext HTTP.
    2. HTTP Routing: The reverse proxy parses the HTTP string, checks routing tables, and forwards the request to the upstream application microservice (often via internal HTTP or gRPC).
    3. Application Handling: The web framework parses the request, executes database queries, constructs the JSON response, and writes it back down the reverse proxy tunnel. The response is encrypted and packetized back to the client.

    10. Deep Dive

    Let's dissect the core architectural changes in HTTP history and the cryptographic mechanics of TLS.

    The Evolution of HTTP

    Each major version of HTTP solved a critical networking limitation:

    • HTTP/1.0: Required a brand new TCP connection for every request/response cycle. This introduced severe latency overhead due to repeated TCP 3-way handshakes and slow-start warm-ups.
    • HTTP/1.1: Introduced Keep-Alive, allowing a client to reuse a single TCP connection for multiple sequential requests. It also added HTTP Pipelining (sending multiple requests without waiting for responses), but this suffered from Head-of-Line (HoL) Blocking. If the first request was slow to process, all subsequent responses were blocked behind it.
    • HTTP/2: Replaced the text-based protocol with a binary framing layer. It introduced Multiplexing: breaking requests and responses into independent, interleaved frames sent concurrently over a single TCP connection. This eliminated application-level HoL blocking. It also added HTTP/2 Header Compression (HPACK) and Server Push. However, if a packet is dropped, the TCP layer blocks the entire connection (TCP-level HoL blocking).
    • HTTP/3: Replaces TCP with QUIC (Quick UDP Internet Connections) built on top of UDP. Since QUIC understands independent data streams directly, a dropped packet in stream A does not block stream B. It also merges the transport and security handshakes, achieving secure connections in just 1 RTT (or 0 RTT for recurring visits).

    TLS Cryptographic Mechanics

    HTTPS relies on a hybrid cryptosystem using two types of encryption:

    1. Asymmetric Encryption (Handshake Phase): Uses public/private key pairs. The server publishes its public key via an X.509 certificate. The client uses this public key to verify identity and securely negotiate a shared secret. Because asymmetric math is CPU-heavy, it is only used during the handshake. Modern systems use Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) to establish the key, providing Perfect Forward Secrecy (PFS). PFS ensures that even if the server's private key is stolen in the future, past recorded sessions cannot be decrypted.
    2. Symmetric Encryption (Data Phase): Once the shared session key is derived, all data payload is encrypted using symmetric algorithms like AES-GCM or ChaCha20-Poly1305. These algorithms are extremely fast and are often executed directly in hardware via processor instruction sets (AES-NI).

    Certificate Validation & Revocation

    A digital certificate links a public key to an identity (domain name). Clients must verify this authenticity using the Public Key Infrastructure (PKI). To check if a certificate was revoked before its expiration date, clients use two methods:

    • CRL (Certificate Revocation List): The client periodically downloads a file containing all revoked certificates from the CA. This list can grow large and slow down lookups.
    • OCSP (Online Certificate Status Protocol): The client queries the CA's OCSP responder directly in real time. To eliminate this extra network check, servers can use OCSP Stapling. The server queries the CA, obtains a signed, timestamped proof of validity, and "staples" it to the certificate sent to the client during the TLS handshake.

    11. Production Example

    Large-scale platforms like Netflix and Cloudflare configure HTTP/HTTPS to optimize both throughput and latency across millions of active connections.

    Edge TLS Termination

    To minimize latency, CDNs terminate the TLS connection at Edge locations close to the client. The round-trip time (RTT) for the TCP/TLS handshakes is completed locally (e.g., within 5–20ms). Once decrypted, the Edge proxy routes the HTTP request to the Origin datacenter over pre-established, persistent TCP connections (connection pools) across a dedicated fiber backbone. This keeps the application server free from TLS handshake CPU overhead.

    Nginx Production SSL Config Example

    A production-ready Nginx configuration block optimizes TLS performance and security as follows:

    12. Advantages

    Adopting modern HTTP standards layered with HTTPS offers critical benefits:

    • Ironclad Data Security: Protects authentication tokens, request payloads, and API keys from extraction or manipulation by network intermediaries.
    • Trust and Search Engine Optimization: Search engines penalize unencrypted HTTP sites. Browsers display security warnings on HTTP sites, lowering user trust.
    • Performance via Multiplexing: HTTP/2 and HTTP/3 multiplexing allow loading dozens of assets over a single socket, reducing page load times by avoiding the browser's 6-connection-per-domain limit.
    • Access to Modern Web Features: Service Workers, push notifications, geolocation APIs, and WebAuthn credentials require HTTPS for execution.

    13. Limitations

    Despite its benefits, HTTPS has challenges in deployment and execution:

    • Initial Connection Latency: The additional network round trips for TCP and TLS handshakes delay the first byte of a connection, especially on high-latency mobile networks.
    • Increased CPU Overhead: Establishing secure sessions requires asymmetric key generation and signature validations, demanding additional CPU resource allocations at high scales.
    • Management Complexity: Monitoring SSL/TLS certificate chains, handling key rotations, and debugging configuration issues add operational overhead.
    • Loss of Intermediary Caching: Public ISP routers or intermediate network caches cannot cache HTTPS responses. Caching must be moved to CDN nodes or client browsers.

    14. Trade-offs

    Edge TLS Termination vs. End-to-End Encryption

    Decrypting traffic at the load balancer (Edge TLS termination) decreases internal latency and simplifies certificate management. However, if internal networks are compromised, attackers can read plaintext backend traffic. End-to-End Encryption secures the backend but increases internal CPU overhead and complicates key provisioning.

    Session Tickets (Stateless) vs. Session IDs (Stateful)

    Session Tickets encrypt session state and store it on the client. When the client reconnects, the server decrypts the ticket to resume the session. This is stateless and scales horizontally across multiple servers. The trade-off is security: if the Session Ticket Encryption Key (STEK) is compromised, an attacker can decrypt all intercepted sessions until the key is rotated.

    HTTP/2 vs. HTTP/3 Fallback

    HTTP/3 is faster but operates on UDP. Many enterprise firewalls block UDP port 443. System designers must build fallback mechanisms to negotiate HTTP/2 over TCP seamlessly, increasing the complexity of the networking layer.

    15. Performance Considerations

    To scale HTTPS systems to thousands of requests per second, optimize these settings:

    • Pre-established Connections: Maintain warm connection pools at the API Gateway level to backend microservices, eliminating TLS handshake latency for incoming API requests.
    • Enable 0-RTT TLS Resumption: Using TLS 1.3 0-RTT allows clients to send application data in the very first payload (ClientHello) if they have a cached session ticket. Ensure replay protection is enabled to restrict this to safe HTTP methods (like GET).
    • Optimize Certificate Chain Size: Ensure the server certificate chain is small. Keep it under 14KB to fit within the initial TCP congestion window (initcwnd=10), preventing an extra network round-trip just to download the certificate.
    • Application-Layer Protocol Negotiation (ALPN): Use ALPN extensions during the TLS handshake to negotiate HTTP/2 or HTTP/3, removing the need for a separate round trip to check protocol support.

    16. Failure Scenarios

    In production, HTTP/HTTPS systems fail in predictable ways:

    • Certificate Expiration Outages: If automated certificate renewals fail or are unmonitored, the certificate expires. Browsers immediately block access to the site with a security error, halting API clients and user traffic.
    • TLS Cipher Suite Mismatch: If a server disables legacy ciphers (e.g. TLS 1.0/1.1) to meet security standards, older mobile devices, legacy browsers, or embedded IoT systems will fail to negotiate a handshake, leading to connection timeouts.
    • TCP Head-of-Line Blocking under Packet Loss: On networks with over 2% packet loss, HTTP/2 can perform worse than HTTP/1.1. If one TCP segment is lost, the entire single TCP connection stalls, blocking all multiplexed streams. HTTP/3 solves this by switching to UDP.
    • DDoS TLS Floods: Attackers target the TLS handshake layer by sending millions of fake ClientHello requests. Because calculating public keys is CPU-expensive, the server exhausts its CPU resource pools, crashing the web server.
    • OCSP Responder Failures: If OCSP Stapling is disabled and the CA's OCSP server goes offline or responds slowly, the client's browser hangs while waiting to verify the certificate's revocation status.

    17. Best Practices

    Implement these design patterns to secure and optimize your HTTP services:

    • Enforce HSTS (HTTP Strict Transport Security): Add the Strict-Transport-Security header with a long max-age and the preload directive, forcing browsers to communicate only via HTTPS and mitigating SSL stripping attacks.
    • Automate Certificate Rotation: Use Let's Encrypt with the ACME protocol, or AWS Certificate Manager, to rotate certificates automatically every 60–90 days. Keep keys secure and monitor rotation.
    • Disable Legacy TLS: Deprecate SSLv3, TLS 1.0, and TLS 1.1. Restrict server settings to TLS 1.2 and TLS 1.3 only.
    • Implement OCSP Stapling: Configure servers to pre-fetch and cache certificate revocation status from the CA, protecting user privacy and speeding up connection setups.
    • Use Security Headers: Set security-hardening headers: Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Referrer-Policy.

    18. Common Mistakes

    Avoid these common misconfigurations in production:

    • Mixed Content Errors: Loading static assets (images, JavaScript, CSS) over HTTP on an HTTPS page. Modern browsers block these insecure assets, breaking page functionality.
    • Neglecting Intermediate Certificates: Providing only the server's leaf certificate instead of the full chain. While some desktop browsers cache intermediate certificates, mobile browsers will fail to verify the trust chain and reject the connection.
    • Committing Private Keys to Git: Uploading the private key file (e.g., privkey.pem) to source control repositories. Always inject keys via secure secrets management tools (e.g., HashiCorp Vault, AWS Secrets Manager).
    • Not Reusing TCP/TLS Connections: Failing to configure connection pooling on backend API clients, causing each microservice API call to establish a fresh TCP and TLS session, which degrades server performance.

    19. Implementation

    Below is a complete, runnable Python script that implements a low-level HTTPS client. Rather than relying on high-level libraries like requests, this implementation establishes a raw TCP socket, wraps it in a secure TLS context, performs the handshake, extracts TLS connection and certificate metadata, and sends/parses a raw HTTP/1.1 request.

    20. Interview Questions

    Easy Question

    Question: What is the difference between HTTP and HTTPS, and how are symmetric and asymmetric encryption used in HTTPS?

    Answer: HTTP is an unencrypted, plaintext application-layer protocol that transmits data over port 80. It provides no confidentiality, integrity, or authenticity guarantees. HTTPS runs HTTP over a TLS session, default port 443, securing the channel. HTTPS is a hybrid cryptosystem: 1. Asymmetric Encryption (using public/private keys) is used only during the TLS handshake to verify the server's identity (via certificates) and securely exchange/negotiate a shared secret. 2. Symmetric Encryption (using a shared session key) is used for all subsequent data transfers because it is computationally fast and resource-efficient.

    Medium Question

    Question: How does HTTP/2 multiplexing resolve HTTP/1.1 pipelining limitations, and what is Head-of-Line (HoL) blocking?

    Answer: HTTP/1.1 allows reusing connections (Keep-Alive) and pipelining, but responses must be returned in the exact chronological order they were requested. If the first request is slow to process, all subsequent responses are blocked; this is HTTP Head-of-Line blocking. HTTP/2 solves this by introducing a Binary Framing Layer. It divides requests and responses into smaller, discrete binary frames. Each stream has a unique ID. The client and server interleave these frames over a single TCP connection concurrently. This eliminates HTTP/1.1 Head-of-Line blocking, allowing slow and fast resources to download out of order. However, because it still relies on a single TCP connection, TCP Head-of-Line blocking remains: if one packet is dropped on the network, the TCP layer halts the entire queue of multiplexed streams to wait for retransmission.

    Hard Question

    Question: Detail the changes in the TLS 1.3 handshake compared to TLS 1.2. How does TLS 1.3 achieve 1-RTT connection setup, and what are the security implications of 0-RTT session resumption?

    Answer: TLS 1.3 optimizes the handshake in the following ways: 1. Cipher Suite Reduction: TLS 1.3 supports only a few modern, secure ciphers (removing support for legacy RSA key exchange and static Diffie-Hellman), which simplifies negotiation. 2. 1-RTT Handshake: In TLS 1.2, negotiating cipher suites and key exchange parameters required two network round trips (2 RTT). In TLS 1.3, the client anticipates the server's key exchange algorithm and proactively includes its key share (using ECDHE groups) directly inside the ClientHello. The server responds with its public key share, certificate, and finishes the handshake in its very first response. This establishes the symmetric key in exactly 1 RTT. 3. 0-RTT Session Resumption: Returning clients can send application data (e.g., an HTTP GET request) directly inside the initial ClientHello using a pre-shared key (PSK) derived from a previous session. Security Implications: 0-RTT is vulnerable to Replay Attacks. An attacker intercepting the encrypted 0-RTT request packet can copy it and send it to the server multiple times. The server decrypts and executes it, which could cause duplicate transactions (e.g., billing requests or state modifications). To mitigate this, 0-RTT must only be used for idempotent requests (safe HTTP methods like GET) and servers must implement replay detection windows.

    21. Practice Exercises

    Easy Exercise

    Write a script (in Python, Go, or Node.js) that accepts a target domain URL, checks the validation status of its SSL/TLS certificate, and prints the exact number of days remaining until expiration. The script should alert the user if the certificate expires in less than 14 days.

    Medium Exercise

    Create an Nginx configuration snippet for an API Gateway that routes traffic to three backend microservices. The gateway must enforce TLS 1.3, support HTTP/2, enable HTTP Strict Transport Security (HSTS) with preloading, specify a secure cipher list, and configure OCSP stapling with a fallback DNS resolver.

    Hard Exercise

    Simulate a high-latency network (e.g., RTT of 200ms) with 3% packet loss using network simulation tools (such as tc or Network Link Conditioner). Compare the average page-load time of loading a test website containing 30 static images under three scenarios: (a) HTTP/1.1 with connection pooling, (b) HTTP/2 multiplexing over TCP, and (c) HTTP/3 over UDP/QUIC. Write an analytical report explaining the results and detailing the exact mechanics of Head-of-Line blocking observed in each setup.

    22. Challenge Problem

    Scenario: You are the lead system architect of a global multi-tenant e-commerce platform similar to Shopify. The platform allows over 150,000 merchants to link their custom domains (e.g. shop.merchantdomain.com) directly to your infrastructure.

    System Constraints & Design Objectives

    • Automated Cert Provisioning: The platform must automatically provision, validate (via DNS-01 or HTTP-01 challenges), and renew TLS certificates for 150,000+ custom domains using Let's Encrypt without service disruption.
    • Sub-100ms Latency: The edge proxies must complete TLS handshakes close to the users. You cannot restart proxy instances when new certificates are added or rotated.
    • TLS Flood DDoS Mitigation: The platform must withstand large-scale connection floods targeting the handshake layer without exhausting Edge proxy CPUs.
    • Legacy Compatibility: Safe fallbacks must support older checkout systems (requiring TLS 1.2) while routing modern browsers through TLS 1.3 and HTTP/3.

    Design a detailed technical architecture addressing the storage, routing, auto-renewal validation, dynamic loading (without server restarts), and security constraints of this Edge TLS Layer. Draw a deployment diagram showing the client, the validation workers, certificate stores, and the request routers.

    23. Summary

    HTTP serves as the primary communication protocol of the modern web. In its original forms, HTTP was constrained by high connection overhead and Head-of-Line blocking. The evolution to HTTP/2 and HTTP/3 has significantly reduced latency through frame multiplexing and UDP-based QUIC transports. Concurrently, HTTPS has transitioned from a premium security add-on to a global mandatory standard, relying on hybrid cryptography (asymmetric key handshakes and symmetric session keys) to guarantee confidentiality, data integrity, and authentic identity verification. Configuring connection pools, automated certificate rotation, HSTS, and session tickets is critical for scaling modern distributed systems.

    24. Cheat Sheet

    Feature HTTP/1.1 HTTP/2 HTTP/3 HTTPS (TLS 1.2) HTTPS (TLS 1.3)
    Transport Protocol TCP TCP UDP (QUIC) TCP + TLS TCP + TLS / QUIC
    Handshake Latency 1 RTT (TCP) 1 RTT (TCP) 1 RTT (Combined) 3 RTT (TCP + TLS) 2 RTT (TCP + TLS)
    Head-of-Line Blocking Yes (Application level) Yes (TCP packet drop level) No Dependent on HTTP ver. Dependent on HTTP ver.
    Multiplexing No (Pipelining only) Yes (Frames) Yes (QUIC Streams) Supported (with HTTP/2) Supported
    Encryption No Optional (Mandated by browsers) Mandatory (Built into QUIC) Yes Yes (Modern ciphers only)
    Header Compression None (Plaintext) HPACK (Static/Dynamic table) QPACK (Out-of-order streams) N/A N/A

    25. Quiz

    1. What type of encryption is used for data transmission after the HTTPS handshake completes?

      • A) Asymmetric encryption
      • B) Symmetric encryption
      • C) Hashing
      • D) None; data is plain text

      Correct Answer: B

      Explanation: Asymmetric encryption is only used during the handshake to verify identity and exchange keys. Once the session keys are agreed, all subsequent communication uses fast symmetric encryption.

    2. How does HTTP/2 solve HTTP/1.1 Head-of-Line (HoL) blocking?

      • A) By opening multiple TCP sockets in parallel
      • B) By switching from TCP to UDP
      • C) By using a binary framing layer to multiplex requests/responses over a single TCP connection
      • D) By using gzip compression on HTTP headers

      Correct Answer: C

      Explanation: The binary framing layer splits messages into frames and allows concurrent interleaving (multiplexing) on one TCP connection, removing FIFO restrictions.

    3. What is a key performance limitation of HTTP/2 multiplexing compared to HTTP/3 under lossy network conditions?

      • A) It uses HPACK instead of QPACK
      • B) Packet loss causes TCP-level Head-of-Line blocking, stalling all streams on the connection
      • C) It does not support keep-alive connections
      • D) It requires longer public key exchanges

      Correct Answer: B

      Explanation: Because HTTP/2 runs over TCP, TCP treats the connection as a single linear stream. If a packet is lost, TCP stalls all streams to wait for retransmission. HTTP/3 runs on UDP (via QUIC), making streams independent.

    4. What does Perfect Forward Secrecy (PFS) guarantee?

      • A) The certificate will never expire
      • B) The client can verify the identity of intermediate Certificate Authorities
      • C) If the server's private key is compromised in the future, past recorded encrypted traffic cannot be decrypted
      • D) The client can bypass the TLS handshake for future connections

      Correct Answer: C

      Explanation: PFS uses ephemeral key exchanges (ECDHE). Session keys are unique to each session and not derived from the server's permanent private key, protecting past traffic if the private key is later compromised.

    5. Which mechanism allows a web server to deliver the certificate revocation status directly to the client during the handshake, preventing the client from querying the CA?

      • A) CRL download
      • B) OCSP Stapling
      • C) HSTS preloading
      • D) ALPN negotiation

      Correct Answer: B

      Explanation: OCSP Stapling allows the server to query the CA responder, sign the validation timestamp, and present ("staple") it to the client during the TLS handshake, eliminating client-side network queries.

    6. How many network round-trips (RTT) are required for a TLS 1.3 handshake on a brand new TCP connection?

      • A) 1 RTT
      • B) 2 RTT
      • C) 3 RTT
      • D) 4 RTT

      Correct Answer: B

      Explanation: A brand new connection requires 1 RTT for the TCP 3-way handshake and 1 RTT for the TLS 1.3 handshake, totaling 2 RTT before application data can be sent.

    7. What security vulnerability is introduced when using TLS 1.3 0-RTT session resumption?

      • A) Man-in-the-middle attacks
      • B) Session hijacking
      • C) Replay attacks
      • D) Brute force attacks on public keys

      Correct Answer: C

      Explanation: 0-RTT sends early application data alongside the first hello packet without a fresh challenge, allowing attackers to intercept and replay the request to execute duplicate state actions.

    8. Which HTTP header forces browsers to communicate with a domain only over HTTPS?

      • A) Content-Security-Policy
      • B) Strict-Transport-Security
      • C) Access-Control-Allow-Origin
      • D) X-Frame-Options

      Correct Answer: B

      Explanation: The Strict-Transport-Security (HSTS) header tells the browser to intercept all HTTP requests to that domain and rewrite them locally to HTTPS for the specified duration.

    9. What does the initial TCP congestion window (initcwnd) size dictate in web performance?

      • A) The maximum number of concurrent HTTP/2 streams allowed
      • B) The size of the symmetric encryption session key
      • C) The amount of data a server can send before receiving an acknowledgment (ACK), usually set to ~14KB (10 segments)
      • D) The time duration a socket stays open in a keep-alive pool

      Correct Answer: C

      Explanation: Tuning initcwnd to 10 segments (~14KB) allows the certificate chain and initial webpage to fit in the first TCP burst, avoiding extra round-trip time.

    10. Why does HTTP/3 use QPACK instead of HTTP/2's HPACK compression?

      • A) QPACK does not require a dynamic table
      • B) HPACK relies on in-order delivery of packets, which fails on UDP/QUIC because UDP packets can arrive out of order
      • C) QPACK is a plaintext compression algorithm
      • D) HPACK is incompatible with TLS 1.3

      Correct Answer: B

      Explanation: HPACK assumes strict serial in-order byte delivery. Because QUIC streams are processed out of order, QPACK was designed to resolve compression state without stalling streams (avoiding decompression HoL blocking).

    26. Further Reading

    • High Performance Browser Networking by Ilya Grigorik (O'Reilly) - A foundational guide on TCP, UDP, TLS, HTTP/2, and wireless networks.
    • RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3: The official specification detailing TLS 1.3 state transitions.
    • RFC 7540 & RFC 9114: The official specifications for HTTP/2 and HTTP/3 over QUIC.
    • Cloudflare Learning Hub - What is TLS? Detailed descriptions of the cryptographic handshakes and PKI infrastructure.

    27. Next Lesson Preview

    In the next lesson, we will explore Domain Name System (DNS). We will study the hierarchical resolution lifecycle (Root, TLD, and Authoritative Nameservers), common DNS record types (A, AAAA, CNAME, MX, NS), and strategies for DNS load balancing, geographical routing, and DDoS mitigation at the resolution layer.

    Key takeaways

    • HTTP is stateless request/response; HTTPS = HTTP + TLS.
    • HTTPS gives confidentiality, integrity, and server authenticity.