Limitations of HTTP/2 Over TCP and How HTTP/3 Solves Them 1

Oct,12 2024

  

When I stumbled upon a YouTube video discussing the limitations of  
HTTP/2 over TCP, it caught me off guard. We use these technologies every 
day without considering their drawbacks. What I thought was an advantage 
of HTTP/2 turned out to have some critical limitations! Let me explain.  


HTTP/2 and the TCP Bottleneck

Imagine we have four requests over a single HTTP/2 connection to load resources 
for a web page:  

-  main.js -> stream 1  
-  style.css -> stream 2  
-  img.jpg -> stream 3  
-  image.jpg -> stream 4  

With HTTP/2, TCP segments these streams for transmission. 
Let’s say each stream is split into two segments:  

-  Stream 1 -> Segment 1, Segment 2 (passes)  
-  Stream 2 -> Segment 3, Segment 4 (error in Segment 3)  
-  Stream 3 -> Segment 5, Segment 6 (blocked)  
-  Stream 4 -> Segment 7, Segment 8 (blocked)  

Now, here’s the problem: If  Segment 3 encounters an error, 
TCP halts all subsequent segments—even if they are error-free! 
This behavior, known as TCP Head-of-Line (HOL) Blocking, causes 
significant delays because TCP ensures strict order and reliability
for the data.  

In short, a single error in one stream can disrupt the delivery of 
all streams over the connection, even when other streams are unaffected.  

How HTTP/3 Solves This with UDP  

HTTP/3 takes a completely different approach by replacing TCP with  
UDP, a protocol traditionally used for real-time applications like 
video calls.  

UDP doesn’t care if a datagram (the UDP equivalent of a TCP segment) 
gets lost—it simply keeps sending and receiving data, ensuring the 
unaffected streams continue without interruption. Let’s look at the 
same example with HTTP/3:  

-  Stream 1 -> Datagram 1, Datagram 2 (passes)  
-  Stream 2 -> Datagram 3 (error), Datagram 4 (skipped)  
-  Stream 3 -> Datagram 5, Datagram 6 (passes)  
-  Stream 4 -> Datagram 7, Datagram 8 (passes)  

Here, even though  Datagram 3 has an error, the other streams (3 and 4) 
proceed unaffected. This approach dramatically improves performance and 
eliminates the Head-of-Line blocking issue.  



Why It Matters  

The shift to HTTP/3 and UDP highlights how everyday technologies evolve
to address fundamental bottlenecks. HTTP/3 ensures smoother and faster
performance, especially for modern, resource-heavy websites.  

If you’re like me, you’ll find it fascinating how something we take for 
granted—like how browsers fetch resources—has hidden limitations and 
ingenious solutions.  

 Reference:  
1. [YouTube: What is HTTP/3?](https://www.youtube.com/watch?v=beDiiWE8ESM)  

Note: Blog page not optimized for mobile device, fixing soon...
When I stumbled upon a YouTube video discussing the limitations of HTTP/2 over TCP, it caught me off guard. We use these technologies every day without considering their drawbacks. What I thought was an advantage of HTTP/2 turned out to have some critical limitations! Let me explain. HTTP/2 and the TCP Bottleneck Imagine we have four requests over a single HTTP/2 connection to load resources for a web page: - main.js -> stream 1 - style.css -> stream 2 - img.jpg -> stream 3 - image.jpg -> stream 4 With HTTP/2, TCP segments these streams for transmission. Let’s say each stream is split into two segments: - Stream 1 -> Segment 1, Segment 2 (passes) - Stream 2 -> Segment 3, Segment 4 (error in Segment 3) - Stream 3 -> Segment 5, Segment 6 (blocked) - Stream 4 -> Segment 7, Segment 8 (blocked) Now, here’s the problem: If Segment 3 encounters an error, TCP halts all subsequent segments—even if they are error-free! This behavior, known as TCP Head-of-Line (HOL) Blocking, causes significant delays because TCP ensures strict order and reliability for the data. In short, a single error in one stream can disrupt the delivery of all streams over the connection, even when other streams are unaffected. How HTTP/3 Solves This with UDP HTTP/3 takes a completely different approach by replacing TCP with UDP, a protocol traditionally used for real-time applications like video calls. UDP doesn’t care if a datagram (the UDP equivalent of a TCP segment) gets lost—it simply keeps sending and receiving data, ensuring the unaffected streams continue without interruption. Let’s look at the same example with HTTP/3: - Stream 1 -> Datagram 1, Datagram 2 (passes) - Stream 2 -> Datagram 3 (error), Datagram 4 (skipped) - Stream 3 -> Datagram 5, Datagram 6 (passes) - Stream 4 -> Datagram 7, Datagram 8 (passes) Here, even though Datagram 3 has an error, the other streams (3 and 4) proceed unaffected. This approach dramatically improves performance and eliminates the Head-of-Line blocking issue. Why It Matters The shift to HTTP/3 and UDP highlights how everyday technologies evolve to address fundamental bottlenecks. HTTP/3 ensures smoother and faster performance, especially for modern, resource-heavy websites. If you’re like me, you’ll find it fascinating how something we take for granted—like how browsers fetch resources—has hidden limitations and ingenious solutions. Reference: 1. [YouTube: What is HTTP/3?](https://www.youtube.com/watch?v=beDiiWE8ESM)