Comparing HTTP/3 vs. HTTP/2 Performance

Post by ignoramous » Tue, Apr 14, 2020, 3:57 PM UTC

cb22 wrote: post #26

georgyo wrote: post #22

Earlier quoted context omitted.

The application layer is the only place these changes can go anymore. IPv6 is a good example that protocol layer changes are really slow to roll out. You may also be interested in SCTP, which is awesome on paper and works well across the internet. But since most firewalls only understand TCP, UDP, and ICMP other protocols get auto dropped. SCTP could have been amazing. https://en.m.wikipedia.org/wiki/Stream_Control_T…

> SCTP could have been amazing It still is, it's part of the WebRTC spec, and when you use a WebRTC data channel, you're using SCTP over DTLS over UDP! (or TCP, possibly with a TURN relay, which may end up tunneling the whole thing over TLS over TCP :)) There are a lot of acronyms in WebRTC, thankfully there's https://webrtcglossary.com

Post by ATsch » Tue, Apr 14, 2020, 4:10 PM UTC

m_eiman wrote: post #41

ATsch wrote: post #28

Earlier quoted context omitted.

There's something else, performance aside, that's really exciting about HTTP/3: Fixing a decades old layering violation that has made truly mobile internet impossible. In TCP, a connection is uniquely identified by the following tuple: (src ip, src port, dst ip, dst port) The issue is that we depend not only on layer 4 details (port numbers) but also on layer 3 information (IP addresses). This means we can not ever k…

There’s also Multipath TCP that intends to solve that problem.

Post by ATsch » Tue, Apr 14, 2020, 4:15 PM UTC

rasz wrote: post #45

ATsch wrote: post #28

Earlier quoted context omitted.

There's something else, performance aside, that's really exciting about HTTP/3: Fixing a decades old layering violation that has made truly mobile internet impossible. In TCP, a connection is uniquely identified by the following tuple: (src ip, src port, dst ip, dst port) The issue is that we depend not only on layer 4 details (port numbers) but also on layer 3 information (IP addresses). This means we can not ever k…

>you'll be able to start a download at home, hop on your bike, ride to the office, and finish your download without the connection dropping once. you could do this for over 20 years as long as server supports HTTP/1.1 https://en.wikipedia.org/wiki/Byte_serving

Post by rixed » Tue, Apr 14, 2020, 4:40 PM UTC

ATsch wrote: post #28

jrochkind1 wrote: post #5

So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…

There's something else, performance aside, that's really exciting about HTTP/3: Fixing a decades old layering violation that has made truly mobile internet impossible. In TCP, a connection is uniquely identified by the following tuple: (src ip, src port, dst ip, dst port) The issue is that we depend not only on layer 4 details (port numbers) but also on layer 3 information (IP addresses). This means we can not ever k…

Post by Avamander » Tue, Apr 14, 2020, 4:52 PM UTC

ComputerGuru wrote: post #34

londons_explore wrote: post #16

A major benefit of HTTP/3 is the ability to transparently switch from one network connection to another without restarting requests. You could be midway through a gaming session over websocket, and walk away from your wifi, and you shouldn't notice a glitch. Nearly nothing else offers that ability, and it's very annoying, especially in offices with hundreds of wifi access points - I should be able to walk down the co…

This is called WiFi handoff and any enterprise AP deployment worth a damn should have this sorted out, albeit in a proprietary manner. The WiFi standard already has a client establishing a connection to a new AP before giving up the old one at the actual “physical” transport layer, these proprietary extensions exchange existing connection state information over the wired backbone between APs when a client is attempti…