Modern Web Transport on AWS: TCP Congestion, HTTP/2, HTTP/3, and QUIC
Quick summary: Packet loss on mobile networks still punishes HTTP/1.1 head-of-line blocking—but HTTP/3 only helps if CloudFront terminates QUIC and your origin connection pools are sized for multiplexed streams. This guide connects Reno, Cubic, BBR, HPACK, and QUIC to ALB and CloudFront decisions.
Key Takeaways
- Packet loss on mobile networks still punishes HTTP/1
- 1 head-of-line blocking—but HTTP/3 only helps if CloudFront terminates QUIC and your origin connection pools are sized for multiplexed streams
- This guide connects Reno, Cubic, BBR, HPACK, and QUIC to ALB and CloudFront decisions
- In June 2026, CloudFront supports HTTP/3 (QUIC) for viewer connections, while Application Load Balancers terminate HTTP/2 over TCP to targets
- That split matters: shaving 40 ms on the last mile does nothing if your origin opens a new database connection per multiplexed stream
Table of Contents
In June 2026, CloudFront supports HTTP/3 (QUIC) for viewer connections, while Application Load Balancers terminate HTTP/2 over TCP to targets. That split matters: shaving 40 ms on the last mile does nothing if your origin opens a new database connection per multiplexed stream.
Benchmark pattern — Synthetic mobile loss (3% packet drop) against a static API behind CloudFront: HTTP/2 viewer p95 410 ms → HTTP/3 p95 290 ms; origin-side p95 unchanged at 180 ms until we raised ALB target keep-alive and RDS Proxy pool max to 40 (was 10). Artifact: transport tuning notes.
Mechanisms that actually change latency
TCP congestion (Reno, Cubic, BBR)
On EC2 origins, Cubic backs off aggressively on loss; BBR can maintain higher throughput on long-fat pipes but misbehaves on shallow buffers. For APIs, prefer stable RTT (same-AZ targets, NLB for TCP passthrough) over sysctl tuning unless you have kernel evidence.
HTTP/2 multiplexing and HPACK
One TCP connection carries many streams—head-of-line blocking remains at TCP layer. HPACK header compression helps repeated JWT-heavy APIs. ALB HTTP/2 to targets reduces connection count; ensure idle timeout > client keep-alive.
HTTP/3 and QUIC
QUIC runs over UDP with per-stream loss recovery—one lost packet does not stall unrelated streams. Enable on CloudFront for browser traffic; do not assume origin HTTP/3 without custom setup.
Connection pooling pitfalls
Multiplexing increases ** concurrent in-flight requests per TCP connection**. If the app pool allows 10 DB connections but HTTP/2 delivers 200 parallel API requests, you queue at the pool—not the load balancer.
AWS services map
| Concept | AWS surface | When to skip |
|---|---|---|
| Edge HTTP/3 | CloudFront | Internal east-west APIs |
| L7 multiplexing | ALB HTTP/2 | Raw TCP / TLS passthrough → NLB |
| Origin tuning | EC2 + RDS Proxy pool | Fully serverless with Data API only |
| API throttling | API Gateway account limits | NLB → ECS gRPC |
When this advice breaks
- WebSockets — Different lifecycle; HTTP/2 multiplexing irrelevant.
- gRPC over ALB — HTTP/2 settings differ; see gRPC guide in API track.
- Lambda-only APIs — No origin pool; cold start and ENI scale dominate.
What to do this week
- Enable HTTP/3 on CloudFront distributions serving mobile browsers; compare
time-to-first-byteby protocol in Real-Time Logs. - Set ALB idle timeout ≥ client keep-alive; verify target group deregistration delay during deploys.
- Graph app → RDS connections vs HTTP request concurrency; align pool max with peak multiplexed streams.
- Enable RDS Proxy for connection-heavy microservices behind HTTP/2.
What this guide doesn’t cover
TLS 1.3 handshake details and certificate pinning—see the TLS guide (part 2 of this track).
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
