system
Given the following post, respond as if you're commenting on Reddit:
human
ELI5: Why is HTTP/3 using UDP is more reliable than HTTP/2 (etc) using TCP?
gpt
In theory it shouldn't be, or the difference should be very minimal. UDP packets add 8 bytes of overhead for the protocol which is mostly the "port" numbers, whereas TCP adds 20 for its reliability features on top of that. 12 bytes isn't too bad, and implementing your own reliability layer is going to cost at least some overhead in HTTP/3. So there shouldn't be much difference.

In practice, the historical details of how systems implemented TCP have not withstood the test of time or user patience. The general consensus was that if packets on the network aren't making it to its destination, there is congestion and the sender should slow down to avoid making the problem worse and relieve the pressure. Wireless (cellular, WiFi, etc) are rather ruining that and packet loss could be caused by anything, not necessarily warranting slowing down data rates. Furthermore network hardware buffers packets - how many varies by the hardware and how much it costs, but you don't usually want that happening. If buffers are big then latency (ping times) goes up, and if buffers are small then packet loss can occur when lots of data is moving through the network while TCP settles on its transmission rate.

Finally, TCP has a connection setup time which can slow down initial connections to web site. Throw in SSL encryption setup and your first visit to a web site slows down significantly compared to clicking links once you've already arrived. With a connectionless setup we can skip a few steps if we were to merge the replacement TCP connection setup and the SSL setup into the same steps.

HTTP/3 (using "Quic", the UDP layer) was intended to deal with some of these issues by making it smarter than TCP. Using lessons learned from above we can do better.