TCP Fast Open and HTTP/3: Network-Level Optimizations for Lightning-Fast Drupal

Slide 1 - Title
"Hello everyone! Thank you for coming. Today, we'll talk about network optimizations for Drupal. TCP Fast Open and HTTP/3. Let's make Drupal faster!"

# Slide 2 - About Me
"My name is Nicolas Perussel. You can call me Mamoot. I'm Head of Architecture at Ekino. I've worked with PHP and Drupal for 20 years. I love Nintendo, rum, Warhammer, and music. Nice to meet you!"

# Slide 3 - Session Objectives
"Today is special. We won't change any PHP code. Zero. Nothing. We'll optimize the network layer instead. And it works great!"

# Slide 4 - TTFB
"TTFB means Time To First Byte. It's the time before your server sends data. This is our challenge today."

# Slide 5 - The Reality
"The truth is simple. Latency is everywhere. On the internet, latency is always there. We cannot remove it. But we can reduce it!"

# Slide 6 - WHY?
"Why do we have latency? Let me explain how the internet works."

# Slide 7 - How Internet Works
"This is how the internet works. It's beautiful from space. But there's a lot happening under the hood."

# Slide 8 - TCP
"Let me introduce TCP. Transmission Control Protocol. It's Layer 4. The transport layer. TCP carries your HTTP requests. It's like a truck carrying packages."

# Slide 9 - TCP Handshake
"TCP needs a handshake before sending data. Three steps. SYN. SYN-ACK. ACK. It's like saying hello before talking."

# Slide 10 - Round Trip Time
"This handshake takes time. We call it RTT. Round Trip Time. One RTT is the time for data to go back and forth. TCP handshake takes 1.5 RTT. Look at this ping example. From France to drupal.org. About 26 milliseconds average."

# Slide 11 - AWS Latency
"Here's real latency data from AWS. From France to other regions. Paris to Frankfurt: 19 milliseconds. Paris to Ireland: 28 milliseconds. Paris to Stockholm: 35 milliseconds. Distance matters!"

# Slide 12 - TLS
"Now let's add security. TLS. Transport Layer Security. It's Layer 5 and 6. TLS wraps TCP. HTTPS uses port 443. HTTP uses port 80. TLS transports HTTP without reading it."

# Slide 13 - TLS Handshake
"TLS also needs a handshake. TLS 1.2 takes 4 steps. That's 2 RTT. TLS 1.3 takes only 2 steps. That's 1 RTT. TLS 1.3 is 50% faster!"

# Slide 14 - First Advice
"My first advice: Use TLS 1.3. It's simple. Just two lines in nginx config. Look: ssl_protocols TLSv1.2 TLSv1.3. And ssl_prefer_server_ciphers off. That's it! Today, 73% of websites use TLS 1.3. It's the standard now."

# Slide 15 - 0-RTT with TLS 1.3
"TLS 1.3 has a cool feature. Zero RTT. The client sends data in the first packet. No waiting. Zero roundtrip. But... there's a security problem. Replay attacks."

# Slide 16 - 0-RTT Security
"Zero RTT is safe for GET requests. Loading CSS, JavaScript, images. Reading Drupal pages. But NOT safe for POST forms. No webforms, no commerce, no login. An attacker could replay the request many times."

# Slide 17 - Fighting Replay Attacks
"Two ways to protect against replay attacks. Full nginx way: Block dangerous requests with a map. Or nginx plus PHP: Check the early data header in PHP. Both work well."

# Slide 18 - Session Resumption
"TLS 1.3 has session resumption. Two types: Session IDs and Session Tickets. Session IDs don't scale with load balancing. Don't use them. Session Tickets are better. The server sends encrypted state to the client. No storage needed. Works with load balancers. Perfect for Drupal!"

# Slide 19 - OCSP Stapling
"Let me explain OCSP Stapling. Without it, the client checks certificate status. Extra delay: 100 to 300 milliseconds. With stapling, the server checks instead. Then includes it in the handshake. The client doesn't wait. Saves 200 milliseconds!"

# Slide 20 - TLS Monitoring
"Monitor your TLS performance. This nginx config logs everything. Protocol version, cipher, session reused, early data, request time. Very useful for debugging."

# Slide 21 - TLS Summary
"With these TLS tweaks, we save a lot. 50% faster handshake with TLS 1.3. Minus 200 milliseconds with OCSP stapling. Minus 100 milliseconds with session resumption. Total: about 350 milliseconds saved on first connection!"

# Slide 22 - BUT...
"But wait. There's more we can do!"

# Slide 23 - Remember the Stack
"Remember this stack. We optimized TLS at Layer 5-6. But what about TCP at Layer 4? Can we optimize TCP too?"

# Slide 24 - Focus on TCP
"Let's focus on TCP now."

# Slide 25 - Can We Optimize TCP?
"Can we optimize TCP? Yes we can!"

# Slide 26 - Old Technology
"TCP is old technology. Very old. But Google found a way to improve it."

# Slide 27 - TCP Fast Open
"Welcome to TCP Fast Open. TFO. Google created this in 2011. Published as RFC 7413 in 2014. First connection still takes 2 RTT. But later connections take only 1 RTT! The client sends a cookie plus data in the first packet."

# Slide 28 - TFO Configuration
"TFO configuration is simple. Check your kernel version. You need Linux 3.7 or higher. Linux 4.11 is best. Enable it with sysctl. Then add one line to nginx config. Listen 443 ssl http2 fastopen=256. Done!"

# Slide 29 - TFO Security Risk
"Is TFO dangerous? There's a risk. SYN flood amplification. An attacker sends many SYNs with 64KB data. The server allocates memory for each. But if you configure it right, it's safe. Keep the queue small. Use rate limiting. Monitor your server. Then TFO is fine."

# Slide 30 - Good to Know
"Good news! Cloudflare says 99.7% of DDoS attacks are volumetric. TFO attacks are very rare. Less than 0.1%. Akamai confirms this. TFO exploitation is not seen at scale. The IETF RFC says the risks are manageable. So don't worry too much!"

# Slide 31 - All Optimizations Together
"Look at the difference. Without optimization: 6 RTT. With optimization: only 2 RTT! First connection with 100ms latency. Before: 600 milliseconds. After: 200 milliseconds. We save 400 milliseconds. That's 66% faster! For reconnections, even better. TLS 1.3 plus TFO plus 0-RTT: just 1 RTT. 100 milliseconds total. We save 200 milliseconds. Also 66% faster!"

# Slide 32 - Back to Layers
"We optimized TCP and TLS. But can we do even better?"

# Slide 33 - Can We Do Better?
"Can we do better? The answer is yes!"

# Slide 34 - The Next Step
"What's next? Let me show you!"

# Slide 35 - HTTP/3 and QUIC
"HTTP/3 and QUIC! This is exciting stuff!"

# Slide 36 - Protocol Evolution
"Let's look at history. HTTP/1.1 in 1997. HTTP/2 in 2015. Now HTTP/3 in 2022. HTTP/2 fixed some problems. But not everything. Head-of-line blocking. Slow handshake. Not good for mobile."

# Slide 37 - HTTP/3 Solves Problems
"HTTP/3 solves these problems. It's like a superhero! Boom! Bang! Crack! All problems gone!"

# Slide 38 - What is QUIC
"What is QUIC? Quick UDP Internet Connections. Traditional stack uses TCP. Modern stack uses UDP. Why UDP? Because TCP is in the kernel. Hard to change. UDP is flexible. QUIC reimplements reliability in userspace. Key features: TLS 1.3 embedded. Multiplexing without blocking. Native 0-RTT. Connection migration."

# Slide 39 - Head-of-Line Blocking Solved
"HTTP/2 has a problem. One lost packet blocks everything. All streams wait. With Drupal, imagine 40 assets loading. One packet lost on app.js. All CSS, images, JSON blocked. Extra 200 milliseconds for everything! HTTP/3 fixes this. Only the affected stream waits. Others continue. 1% packet loss typical on mobile. HTTP/2: minus 20% performance. HTTP/3: minus 1% performance. That's 15 to 40% faster on mobile!"

# Slide 40 - Connection Migration
"Another cool feature. Connection migration. With TCP, if your IP changes, connection is lost. You're on a train. WiFi to 4G. TCP says goodbye. New handshake needed. 300 to 500 milliseconds lost. With QUIC, the connection stays alive. The connection ID doesn't change. Zero latency. Perfect for webforms, admin sessions, media uploads, APIs."

# Slide 41 - Support and Adoption
"HTTP/3 support is good now. Top 1000 sites: 60% support HTTP/3. 85% via CDN. 15% directly on origin. For Drupal: drupal.org uses HTTP/3 with Fastly. Acquia Cloud supports HTTP/3. Platform.sh supports HTTP/3. The time is NOW to enable HTTP/3!"

# Slide 42 - Alt-Svc Header
"How does HTTP/3 discovery work? The Alt-Svc header. The browser connects with HTTP/2 over TCP first. The server responds with Alt-Svc: h3. The browser learns: this server supports HTTP/3. It's on UDP port 443. I can use it for 24 hours. Always add this header. Even without HTTP/3 active. Prepare for migration!"

# Slide 43 - Configuration Example
"Configuration is easy. Check nginx version. Minimum 1.25.0. Check if QUIC module is compiled. Add three lines to nginx config. Listen 443 quic reuseport. Listen 443 ssl http2 for fallback. Add the Alt-Svc header. Enable TLS 1.3. Enable early data for 0-RTT. Enable quic_retry for DDoS protection. That's it!"

# Slide 44 - Limitations
"HTTP/3 has some limitations. Four things to consider. First, CPU and RAM consumption. HTTP/3 uses more resources. 10 to 20% more CPU. 50 to 100 MB more RAM per process. Second, some firewalls block UDP. Enterprise networks especially. Solution: automatic fallback to HTTP/2. That's why we keep both. Third, load balancing. UDP load balancing is different. You need QUIC-aware load balancers. Like HAProxy 2.6 or nginx Plus. Or disable HTTP/3 behind classic load balancers. Fourth, debugging is harder. Encrypted UDP traffic. Use qlog for debugging. It's standardized QUIC logs."

# Slide 45 - Takeaway Chart
"Here's the big picture. Number of roundtrips needed. HTTP/2 with TLS 1.2: 4 roundtrips. HTTP/2 with TLS 1.3: 3 roundtrips. HTTP/2 with TLS 1.3 and 0-RTT: 2 roundtrips. HTTP/3 with QUIC: 2 roundtrips. HTTP/3 with QUIC and 0-RTT: only 1 roundtrip! From 4 to 1. That's huge!"

# Slide 46 - Priority Table
"My recommendations by priority. Number one: TLS 1.3. Easy to implement. Critical impact. Do this first! Number two: OCSP Stapling. Also easy. Also critical. Number three: HTTP/2. Easy and high impact. Number four: Session Resumption. Easy and high impact. Number five: TCP Fast Open. Medium difficulty. Medium priority. Number six: HTTP/3 with QUIC. Medium difficulty. Medium priority. Number seven: BBR. Medium difficulty. Low priority. Maybe another talk later!"

# Slide 47 - Secret Reveal
"Want to know a secret? Use a CDN! It's simpler! CDNs handle all this for you. Cloudflare, Fastly, Akamai. They already support everything. TLS 1.3. HTTP/3. QUIC. Zero RTT. All automatic. But it's good to understand how it works!"

Transcript

1. TCP Fast Open and HTTP/3 Network-Level Optimizations for Lightning-Fast Drupal
2. My nickname: @mamoot 20XP on practicing PHP and web development Specialized in I Like : • Nintendo (Donkey Kong & Mario) • Savouring Rhum • Warhammer painting • Listen & Play Music Nicolas Perussel Head Of Architecture
3. Session objectives Today we'll explore how network protocol optimizations can dramatically improve Drupal performance without changing a single line of PHP code!
4. The Network Performance Challenge TTFB TIME TO FIRST BYTE
5. The Reality
6. WHY?
7. THIS IS HOW INTERNET IS WORKING
8. TCP (Transmission Control Protocol) IP TCP HTTP APPLICATION LAYER LEVEL 7 TRANSPORT LAYER LEVEL 4 NETWORK LAYER LEVEL 3 http://www.drupal.org TCP SEGMENT IP PACKET
9. TCP Three-Way Handshake SYN (SYNCHRONISE) SYN + ACK (ACKNOWLEDGE) ACK
10. Round Trip Time (RTT) RTT Send Request Receive Response RTT Receive Response Send Request TCP Handshake = 1,5 RTT Client → Server: SYN 0.5 RTT Server → Client: SYN-ACK 1.0 RTT Client → Server: ACK + HTTP Data 1.5 RTT
11. https://aws-latency-test.com/ 46 ms 35 ms 39 ms 34 ms 28 ms 19 ms
12. TLS (Transport Layer Security) IP TCP TLS HTTP APPLICATION LAYER LEVEL 7 SESSION / PRESENTATION LAYER LEVEL 5-6 TRANSPORT LAYER LEVEL 4 NETWORK LAYER LEVEL 3 HTTPS :443 :80 Route the packets on the internet TCP carries the TLS bytes without knowing what they are TLS is a wrapper around TCP. TLS transports the bytes of HTTP without reading them
13. TLS Handshake TLS 1.2 TLS 1.3 ClientHello ServerHello AskForCertificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished HTTP REQUEST Finished HTTP RESPONSE ClientHello KeyShare ServerHello KeyShare Verify Certificate Finished HTTP REQUEST Finished HTTP RESPONSE 4 steps 2 RTT 2 steps 1 RTT
14. First Advice Use TLS 1.3 Better performance : reduce the TLS handshake of 50% - Noticeable improvement on high-traffic sites - Particularly beneficial for REST and JSON:API APIs - Reduces latency for mobile/remote users
15. We can go further with TLS 1.3 … TLS 1.3 ClientHello KeyShare Early Data HTTP GET HTTP RESPONSE 0 RTT ServerHello KeyShare Early Data Finished 0 RTT Concept - Allows data to be sent from the first packet (zero round- trip) - Uses a previous session ticket - Handshake time = 0ms for repeated connections Vulnerability to replay attacks 1. An attacker captures a legitimate 0-RTT request (e.g., POST /user/login) 2. They can "replay" this request multiple times 3. Without protection, this can cause: multiple form submissions; duplicate financial transactions; Repeated non-idempotent actions …
16. 0 RTT: security vs performance SAFE FOR : - Idempotent GET requests - Loading static resources (CSS, JS, images) - Caching Drupal pages NOT SAFE FOR : - POST forms (webform, commerce, login) - API mutations (POST, PATCH, PUT, DELETE) - Payment transactions
17. How to fight against Replay Attack Full Nginx way Nginx + PHP approach
18. TLS 1.3 : Session Resumption Two resumption mechanisms: Session IDs (old method) : • The server stores session state in memory • Problem: Doesn't scale with load balancing • Not recommended for multi-server Drupal Session Tickets : • Encrypted state sent to the client • Stateless server (no storage) • Compatible with load balancing Best practices for Drupal: • Synchronize ticket keys between servers • Automatically rotate keys every 24-48 hours • Monitor session resumption rates (target: >70%)
19. TLS : OCSP Stapling Eliminating Validation Latency The problem without stapling: • Client connects to the Drupal server • Client must contact the CA's OCSP responder • Additional delay of 100-300ms • If the OCSP responder is down → connection failure The solution: OCSP Stapling: • The server periodically retrieves the OCSP status • The server "staples" the TLS handshake response • The client no longer needs to contact the OCSP responder Benefits: • Reduces handshake time by ~200ms • Improves confidentiality (no leaks to the CA) • Resilience if the OCSP responder is unavailable
20. TLS Monitoring
21. With some TLS tweaks… -50% handshake time with TLS 1.3 -200ms latency with OCSP stapling -100ms with the Session Resumption = ~350ms total gain on first connection
22. BUT …
23. Remember this… IP TCP TLS APPLICATION LAYER LEVEL 7 SESSION / PRESENTATION LAYER LEVEL 5-6 TRANSPORT LAYER LEVEL 4 NETWORK LAYER LEVEL 3 HTTPS :443 https://www.drupal.org
24. IP TCP TRANSPORT LAYER LEVEL 4 NETWORK LAYER LEVEL 3 TLS APPLICATION LAYER LEVEL 7 HTTPS :443 SESSION / PRESENTATION LAYER LEVEL 5-6
25. Can we optimize TCP?
27. Welcome to TCP FastOpen (TFO) FIRST CONNECTION 2 RTT LATER CONNECTIONS 1 RTT With TCP Fast Open, Google has presented a protocol extension for reducing unnecessary latencies in network traffic. The proposal was originally presented in 2011 and was published as RFC 7413 in December 2014. TFO Origin https://www.keycdn.com/support/tcp-fast-open
28. TFO Configuration (simple as that) Supported OS : • Linux kernel 3.7+ : Support TFO • Linux kernel 3.13+ : Support TFO server • Linux kernel 4.11+ : Full support and stable
29. TFO SYN Flood Amplification Attack The risk: • TFO allows up to 64KB to be sent in the initial SYN. • An attacker with a valid TFO cookie can amplify a SYN flood • Amplification factor: x234 The attack scenario: 1. Attacker obtains a valid TFO cookie 2. Forges SYNs with 64KB of data + spoofed IP 3. Server allocates 64KB × number of SYNs in RAM 4. Memory exhaustion → Server crash SAFE FOR : If properly configured: • Limited queue (64) • Monitoring active • Rate limiting in place NOT SAFE IF : If misconfigured: • Huge queue (1024+) • No rate limiting • Undersized server IS TFO DANGEROUS ?
30. Good to know Cloudflare Q4 2024 DDoS Report: "99.7% of DDoS attacks are volumetric Layer 3/4 attacks (SYN floods, UDP floods, etc.). Sophisticated application-layer attacks exploiting protocol features like TFO remain extremely rare (<0.1%). " Source : https://blog.cloudflare.com/ddos-threat-report-2024-q4/ Akamai State of the Internet Report 2024 : "TCP Fast Open exploitation has not been observed in the wild at scale. Traditional SYN floods and reflection attacks remain the primary DDoS vectors. » Source : https://www.akamai.com/resources/state-of-the-internet-reports "The security considerations are similar to those of SYN cookies. While TFO increases the potential payload of a SYN flood attack, practical mitigations (limited queue size, rate limiting) make this a manageable risk. » Source : https://datatracker.ietf.org/doc/html /rfc7413#section-6 IETF RFC 7413 (TFO)
31. With all the tweaks… WITHOUT OPTIMIZATION TLS 1.2 6 RTT • RTT 1: [TCP SYN/SYN-ACK/ACK] • RTT 2: [TLS ClientHello] • RTT 3: [TLS rest if the handshake] • RTT 4: [OCSP check part 1] • RTT 5: [OCSP check part 2] • RTT 6: [HTTP GET /] 600ms WITH OPTIMIZATION 2 RTT • RTT 1: [TCP SYN+TFO + TLS 1.3 + OCSP stapled] • RTT 2: [HTTP GET /] FIRST CONNECTION - 100ms LATENCY 200ms SESSION RESUMPTION TLS 1.2 3 RTT • RTT 1: [TCP SYN/SYN-ACK/ACK] • RTT 2: [TLS abbreviated handshake] • RTT 3: [HTTP GET /] 300ms TLS 1.3 + TFO + 0-RTT 1 RTT • RTT 1: [Tout en un : TFO + 0-RTT + HTTP GET] RECONNECTION - 100ms LATENCY 100ms -400ms (-66%) -200ms (-66%)
32. IP NETWORK LAYER LEVEL 3 TLS APPLICATION LAYER LEVEL 7 HTTPS :443 SESSION / PRESENTATION LAYER LEVEL 5-6 TCP TRANSPORT LAYER LEVEL 4
33. Can we do better?
35. HTTP/3 and QUIC
36. The Web Protocol Revolution HTTP/2 HTTP/1.1 HTTP/3 1997 2015 2022 Head-of-Line Blocking • HTTP/2: multiplexing at HTTP level • But underlying TCP blocks everything if 1 packet is lost • All streams wait for retransmission Slow handshake • TCP handshake (1 RTT) • TLS handshake (1-2 RTT) = 2-3 RTT before sending data Not designed for mobility • WiFi → 4G switch: new TCP connection • All state lost
37. The Web Protocol Revolution HTTP/2 HTTP/1.1 1997 2015 2022 Head-of-Line Blocking • HTTP/2: multiplexing at HTTP level • But underlying TCP blocks everything if 1 packet is lost • All streams wait for retransmission Slow handshake • TCP handshake (1 RTT) • TLS handshake (1-2 RTT) = 2-3 RTT before sending data Not designed for mobility • WiFi → 4G switch: new TCP connection • All state lost HTTP/3
38. What is QUIC (Quick UDP Internet Connections) IP TCP TLS 1.3 HTTP/2 IP QUIC (embeds TLS 1.3) HTTP/3 UDP Traditional stack Modern stack • TCP is in the kernel (hard to modify) • UDP is "dumb" but flexible • QUIC reimplements reliability in userspace. Enables innovation without kernel modifications Why UDP? • TLS 1.3 embedded (no separate layer) • Multiplexing without HOL blocking • Native and secure 0-RTT • Connection migration (IP/port change) • Continuous improvements possible Key features
39. Head-of-Line Blocking – Problem solved HTTP/2 over TCP: The Problem Concrete example with Drupal: Loading a Drupal page with 40 assets • 1 packet lost on app.js (1% loss) • All other assets (CSS, images, JSON) blocked • Total latency: +200ms for ALL files HTTP/3 over QUIC: The Solution Result: • 1% packet loss (typical WiFi/4G) • HTTP/2: -20% performance • HTTP/3: -1% performance (only affected stream) Gain for Drupal: 15-40% faster on unstable mobile networks
40. Connection Migration - Mobility The TCP Problem The QUIC Solution Drupal use cases: • Webform forms being filled • Admin sessions while moving • Media uploads (guaranteed continuity) • REST/JSON:API on mobile Gain: Smooth user experience, no "connection lost"
41. Support and Adoption Top 1000 sites (2025 stats): • 60% support HTTP/3 • 85% via CDN (Cloudflare, Fastly, etc.) • 15% directly on their origin Drupal specifically: • Drupal.org: HTTP/3 active (Fastly) • Acquia Cloud: HTTP/3 available • Platform.sh/Upsun: HTTP/3 supported The time is NOW to enable HTTP/3!
42. The Alt-Svc Header - HTTP/3 Discovery The browser learns: • "This server supports HTTP/3 » • "It's listening on UDP port 443 » • "I can use HTTP/3 for 24h (ma=max-age)" QUIC HTTP/2 Over TCP HTTP/2 200 OK Alte-Svc: h3 … HTTP/3 (QUIC over UDP)
43. Configuration example
44. Limitations and considerations Load Balancing UDP load balancing ≠ TCP load balancing Potential issues: • More complex sticky sessions • ECMP can misroute UDP • Connection ID must be routed correctly Solutions: • Use QUIC-aware LB (HAProxy 2.6+, Nginx Plus…) • OR disable HTTP/3 behind classic LB Some firewalls block UDP Enterprise / restrictive networks: • UDP port 443 blocked • Only TCP allowed Solution: Automatic fallback to HTTP/2 (that's why we keep "listen 443 ssl http2") More complex debugging Traditional tools (tcpdump, Wireshark): • HTTP/2: easy to capture (TCP) • HTTP/3: encrypted UDP traffic, harder Solution: Use qlog (standardized QUIC logs) CPU/RAM consumption • HTTP/2: Light (TCP managed by kernel) • HTTP/3: Heavier (QUIC in userspace) Impact on Drupal server: • +10-20% CPU for QUIC • +50-100MB RAM per nginx process Mitigation: Adjust worker_processes
45. Take away https://www.debugbear.com/blog/http3-quic-protocol-guide
46. Take away TLS/HTTP Optimization Stack by Priority # Optimization Impact Difficulty Priority 1 TLS 1.3 Easy CRITICAL 2 OCSP Stapling Easy CRITICAL 3 HTTP/2 Easy HIGH 4 Session Resumption Easy HIGH 5 TCP Fast Open Medium MEDIUM 6 HTTP/3 (QUIC) Medium MEDIUM 7 BBR Medium LOW
47. Use a CDN, it’s simpler! (secret reveal)
48. 49 DANKE