TCP vs UDP, HTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC), Keep-Alive and Connection Reuse
How data travels over the wire (TCP/UDP) and how the web protocol HTTP evolved: fewer handshakes, multiplexing and connection reuse make a website fast.
51.1 Why is it used?
- Every new TCP + TLS connection takes 1-3 round trips; with a 100ms RTT on a mobile network, page load becomes 300ms+ slower.
- HTTP/1.1 allows only one request at a time per connection: with 100 images the browser opens 6 connections and queues them (head-of-line blocking).
- HTTP/2 multiplexing and HTTP/3 (QUIC over UDP) lower latency, especially on lossy mobile networks such as Jio/Airtel 4G.
- Keep-Alive and connection pooling save server CPU (TLS handshakes) and ports; they help handle lakhs of connections on sale day.
- Choosing the right protocol: UDP for video calls/gaming, TCP for payments/APIs; a common interview question.
51.2 How it works
- TCP: connection-oriented, 3-way handshake (SYN, SYN-ACK, ACK), reliable, ordered delivery, retransmission and congestion control.
- UDP: connectionless, no handshake, no guarantee of delivery/order; very fast and lightweight; DNS, VoIP, live gaming and QUIC run on it.
- HTTP/1.1: a text protocol, Keep-Alive by default (many requests one after another on one TCP connection), but only one response at a time: HOL blocking.
- HTTP/2: binary framing, multiple parallel streams on one TCP connection (multiplexing), HPACK header compression; but on a TCP packet loss all streams stall.
- HTTP/3: the QUIC protocol over UDP, TLS 1.3 built in, a 1-RTT handshake (0-RTT on a repeat visit), per-stream loss recovery: one packet loss blocks only that stream.
- Connection Migration (QUIC): based on a Connection ID, so the connection does not break even when switching from WiFi to 4G.
- Keep-Alive & Connection Reuse: a connection once built is reused for many requests, saving handshake cost; set an idle timeout (say 60s).
- Connection Pooling: a pool of ready connections from the app server to the DB/upstream (HikariCP, Nginx upstream keepalive); no new connection per request.
- 1.HTTP/1.1 & HTTP/2 (TCP + TLS): 1 SYN -> 2 SYN-ACK -> 3 ACK + TLS ClientHello -> 4 TLS ServerHello/Finished -> 5 GET /product -> 6 Response
- 2.Data arrives after 2-3 RTT = 200-300ms for setup alone
- 3.HTTP/3 (QUIC over UDP, TLS 1.3 built in): 1 QUIC Initial + TLS hello -> 2 Handshake done -> 3 GET /product -> 4 Response
- 4.Only 1 RTT; a repeat visit = 0-RTT, with the GET in the very first packet
- 1.HTTP/1.1: 6 TCP connections, one request at a time; requests queue on each connection and the next cannot go until the previous response arrives (HTTP HOL blocking) + 6 handshakes
- 2.HTTP/2: 1 TCP connection, streams mixed (multiplexing); HTTP HOL blocking is gone, but TCP-level HOL remains: one loss = everyone waits
- 3.HTTP/3: independent QUIC streams; a loss stalls only stream 2 while the rest keep going; switching WiFi to 4G keeps the connection alive via the Connection ID
- 4.Browser -> h3/h2 -> CDN edge -> reused conn (Nginx keepalive 64) -> App
51.3 Tools
| Tool | Type | How it is used |
|---|---|---|
| Nginx | Web server / reverse proxy | listen 443 ssl http2; and in newer versions listen 443 quic for HTTP/3; upstream keepalive 64 reuses backend connections. |
| Envoy | L7 proxy | Supports downstream HTTP/1.1, HTTP/2, HTTP/3; upstream connection pools and protocol translation (client HTTP/3, backend HTTP/1.1). |
| Cloudflare | CDN / Edge | Enable HTTP/3 (QUIC) and 0-RTT with one toggle; at the edge HTTP/3 to the client, HTTP/1.1 or HTTP/2 to the origin. |
| curl --http3 | CLI testing tool | Check HTTP/3 is working with curl -I --http3 https://site.com; use --http2 and -v for handshake details. |
| AWS CloudFront / ALB | Managed CDN / LB | CloudFront supports HTTP/2 and HTTP/3; ALB speaks HTTP/2 on the client side and keep-alive connections to the backend. |
| Chrome DevTools / Wireshark | Debugging | Look at the Protocol column (h2, h3) in the Network tab; analyse the TCP handshake, retransmissions and QUIC packets in Wireshark. |
51.4 Comparison: HTTP/1.1 vs HTTP/2 vs HTTP/3
| Point | HTTP/1.1 | HTTP/2 | HTTP/3 (QUIC) |
|---|---|---|---|
| Transport | TCP | TCP | QUIC over UDP |
| Format | Text based | Binary frames | Binary frames (QUIC streams) |
| Multiplexing | No, one request at a time per connection | Yes, many streams on one connection | Yes, independent streams |
| Head-of-line blocking | Yes at the HTTP level | No at the HTTP level, yes at the TCP level | No, a loss affects only one stream |
| Handshake (new connection) | TCP + TLS: 2-3 RTT | TCP + TLS: 2-3 RTT (2 with TLS 1.3) | 1 RTT, 0-RTT on a repeat visit |
| Header compression | No | HPACK | QPACK |
| Network change (WiFi to 4G) | Connection breaks | Connection breaks | Continues via connection migration |
| Best for | Simple internal APIs, legacy clients | Modern websites, gRPC | Mobile users, lossy networks, video streaming |
51.5 When to choose which
- TCP: when every byte matters and order is needed: payments, APIs, file downloads, DB connections.
- UDP: when speed > reliability: live video calls, gaming, DNS; or when the protocol on top (QUIC) provides reliability itself.
- HTTP/2: today's default for websites and gRPC microservices; simple to enable on Nginx/ALB.
- HTTP/3: best for mobile-heavy Indian traffic; enable it on the CDN (Cloudflare/CloudFront) and keep an HTTP/2 fallback.
- Always keep Keep-Alive + upstream connection pooling on: a free performance win.
51.6 Real-world example
An illustrative scenario: a Flipkart product page on mobile (Jio 4G).
- The user opens the app/website on 4G, with RTT of about 80-100ms and some packet loss.
- With HTTP/1.1: 6 parallel TCP connections, each with a TCP + TLS handshake; 200ms+ is lost on setup alone.
- With HTTP/2: all images, CSS and JS go over a single connection in parallel streams; but one dropped packet stalls every stream.
- With HTTP/3 (QUIC): a 1-RTT handshake, 0-RTT on a repeat visit; a dropped packet of one image does not stall the other streams.
- The user switches from WiFi to 4G in the metro; QUIC keeps the connection alive through the connection ID, with no page reload.
- From the CDN edge to the origin, Nginx upstream keepalive connections are reused; no new TCP/TLS handshake per request.
- Result: faster page load, less server CPU spent on TLS handshakes, and more users on the same hardware on sale day.
51.7 Interview tips
- Remember this line: 'HTTP/2 removed HTTP-level HOL blocking, HTTP/3 removed TCP-level HOL blocking too'.
- Common mistake: applying old HTTP/1.1 hacks (domain sharding, sprite sheets) even on HTTP/2; the benefit of multiplexing shrinks.
- Keeping UDP 443 blocked on the firewall: HTTP/3 will not work; always keep an HTTP/2 fallback.
- Not using keep-alive/pooling towards the backend: a new connection per request, TIME_WAIT sockets and port exhaustion. Number to quote: at 100ms RTT, TCP + TLS setup = 200-300ms, QUIC 1 RTT (0-RTT on repeat visits).