What I don't understand:
Why was the multiplexing in HTTP/2 and 3 pulled into the application layer instead of using a layer 4 protocol like SCTP?
HTTP/2 and HTTP/3 explained
141–150 of 155 posts
Re: HTTP/2 and HTTP/3 explained
#142Earlier quoted context omitted.
It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.
[flagged]
> You have two options: -highly accomplished and highly experienced engineers were actually too stupid (...)
You're making quite clear you are the type of person who is extremely quick to accuse everyone and anyone of being incompetent in the absence of evidence or in spite of evidence.
You do not need to Google too hard to find tons of open-source benchmarks of real world servers showing off performance gains from switching to HTTP/2 and HTTP/3.
But here you are, claiming everyone is incompetent and that their work was bad. In spite of all the evidence.
It's clear that you have nothing relevant to say about the topic and no evidence to even suggest your beliefs have a leg to stand on.
Re: HTTP/2 and HTTP/3 explained
#143Earlier quoted context omitted.
People react to incentives. Windows got PowerShell instead of an improved cmd.exe because improving or fixing existing things does not matter in the yearly promotion package talks, but new stuff does.
cmd.exe is a terminal emulator and PowerShell is a fully-formed scripting language (that Windows desperately needed). This analogy doesn't work the way you think it does.
This is mixing up cmd.exe which is the dos-like (but not dos) scripting interpreter, and conhost.exe which is the actual old terminal emulator/console that the kernel would spin up whenever you ran cmd.exe.
Re: HTTP/2 and HTTP/3 explained
#144Earlier quoted context omitted.
[flagged]
[flagged]
We've banned this account for repeatedly breaking the site guidelines, and not just in this thread.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
Re: HTTP/2 and HTTP/3 explained
#145Earlier quoted context omitted.
[flagged]
[flagged]
We've banned this account for repeatedly breaking the site guidelines, and not just in this thread.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
Re: HTTP/2 and HTTP/3 explained
#146Earlier quoted context omitted.
[flagged]
We've banned this account for repeatedly breaking the site guidelines, and not just in this thread. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html .
[deleted]
Re: HTTP/2 and HTTP/3 explained
#147> This is called head-of-line blocking. In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used. Thats not really head of line blocking, because in HTTP1.1 you'd just open up another connection. The issue with HTTP1.1 is that opening up lots of connections can introduce lots of latency, especially if you are doing Encryption. HTTP1.1 performs much much…
> This is Top of line blocking and was entirely predictable had the HTTP2 team bothered to talk to anyone who did networking.
>
> Its part of the reason why I was greatly suspicious of QUIC, because it appeared like it was designed by the same people that thought http2 was a good idea.
Agreed - i've always found them to be living in a world of their own, which doesn't match the realities of actual networking out there.
In fact, the very same team after touting QUIC over UDP as the revolutionary protocol is now complaining that the real world realities aren't matching their expectations and so are now proposing to do QUIC over TCP. Here's that proposal https://mailarchive.ietf.org/arch/msg/quic/N82WBOa_RJIb4cPQw...
Re: HTTP/2 and HTTP/3 explained
#148Earlier quoted context omitted.
HTTP/1.1 (RFC2616) specified a limit of two connections per server, which most browsers initially interpreted to mean per-origin, which still lead to quite a lot of unnecessary blocking. I think browsers eventually decided to increase that to 6, but as evidenced by viewing the "Network" tab of the Developer Tools on a lot of modern pages, it is in fact not very uncommon anymore to have a substantially larger number o…
This limit is completely artificial. Let's limit HTTP/2 to maximum 6 multiplexed streams per connection and see how it fares with HTTP1.1 with 6 TCP connections to the server. All of sudden HTTP1.1 wins :)
That would greatly limit the maximum number of simultaneous clients behind the same IP (at the office, at the university etc)
When the limit is reached, all clients would be broken
Looks like a good deal indeed, why do not we do that
Re: HTTP/2 and HTTP/3 explained
#149Earlier quoted context omitted.
> The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think Surely packet loss due to poor signal quality is rather common over mobile networks and that packet loss still affects TCP's congestion window. Admittedly anecdotal, but I just connected to a 5G network with low signal strength and it certainly seems to be…
The parent is just moving goal posts. The whole idea behind multiplexing data streams inside a single TCP connection was that in case of a packet loss you don't lose all your streams. But it doesn't work in practice which is not really surprising when you think about it. When you have multiple TCP connections it's less likely that all of them will get reset due to connectivity issues. Whereas with data multiplexing w…
A problem with radio signal or with a wire would affect all TCP connections at the same time. It does not matter if it is one or many, the outcome will be the same. I believe in real life this is a majority of cases. A problem affecting just one TCP connection out of many on the same link must be related to the software on the other side, not network itself.
Re: HTTP/2 and HTTP/3 explained
#150Earlier quoted context omitted.
I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-sele... > Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application.
Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.
I am curious of why the kernel does not allow it; there could be an API that gives you fragments of the stream in "events" like {slice: [10000, 10100], data:} and let the application have a peak preview of future data