71–80 of 84 posts
> With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). This issue is really noticeable on my crappy home mobile internet when loading web pages, in combination with the timeout being absurdly long for reasons I don't understand.
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…
One of the things I was looking forward to from IPv6 was the mobility of IPs [1].
[1] - https://en.wikipedia.org/wiki/Mobile_IP#Changes_in_IPv6_for_...
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…
Part of me consider HTTP/3 as an application protocol and disagree with this. This is not a problem for HTTP to solve but a problem for the routing protocol to solve. Is it desirable to reinvent a routing protocol at the application layer, so that we can use it as another transport protocol and so on? Shouldn't we be using a single, unique 128bit address for every device regardless of which physical network it is att…
The "flat address space" idea however is completely ridiculous. That would mean every node on the internet keeping track of the path to every singe other node. This is what ethernet does and it barely scales to ten or so thousand nodes. Routers are already struggling hard with the 700k table entries we have for the IPv4 internet. To the point where providers actually wrap IP packets inside of simpler protocols once they enter the network.
We need some kind of hierarchical addressing that expresses the location of a node in the network. We know this works. We just need the layers above not to rely on those addresses staying constant.
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…
> This means we can not ever keep a connection alive when moving from one network and hence IP address into another. One of the things I was looking forward to from IPv6 was the mobility of IPs [1]. [1] - https://en.wikipedia.org/wiki/Mobile_IP#Changes_in_IPv6_for_...
Earlier quoted context omitted.
Part of me consider HTTP/3 as an application protocol and disagree with this. This is not a problem for HTTP to solve but a problem for the routing protocol to solve. Is it desirable to reinvent a routing protocol at the application layer, so that we can use it as another transport protocol and so on? Shouldn't we be using a single, unique 128bit address for every device regardless of which physical network it is att…
Each Ethernet interface has a unique address; using them is widely regarded as a privacy violation.
Earlier quoted context omitted.
There’s also Multipath TCP that intends to solve that problem.
SCTP gets closer to it with multi-homing.
> With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). This issue is really noticeable on my crappy home mobile internet when loading web pages, in combination with the timeout being absurdly long for reasons I don't understand.
This is a major set back introduced with HTTP/2 and I'm not sure why this is not mentioned often. Under firefox you can set "network.http.sdpy.enable" to false to switch back to HTTP/1. The improvement I have with HTTP2 is hardly noticeable, but HOL blocking is very tangible as soon as you have occasional random packet loss.
Thanks! I might have to try that out, currently relegated to tunneling everything over sshuttle which of course makes things slower but reliable since it decompiles the TCP packets making them appear to work flawlessly to HTTP... HTTP1 may be a faster solution.
[edit]
Trying this now. Correction on parent comment for Firefox:
goto:
about:config
search:
network.http.spdy.enabled.http2Earlier quoted context omitted.
SCTP gets closer to it with multi-homing.
Still incredibly disappointed this didn't catch on widely before NAT prevented any new protocols. There'd be so many problems we wouldn't have today.