8 ms·

> 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 use

> 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 better over high latency or lossy links than http2 > With HTTP/2, this problem is solved with streams, each stream corresponds to a message. Many streams can be interleaved in a single TCP packet. If a stream can't emit its data for some reason, other streams can take its place in the TCP packet. This is where HTTP2 failed. It shoved everything into one single TCP connection which works fine on LAN and LAN like networks, and sucks balls in the real world. 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. However QUIC seems to be actually reasonable. I've yet to fully test it in real world scenarios, but it does offer promise for highspeed latency resistant data streaming. One day I'll re-write my TCP multiplexor to compare the performance.

ghusbands 3y ago
> entirely predictable had the HTTP2 team bothered to talk to anyone who did networking I think it's good that things have evolved rather than being stuck behind naysaying. Sure, there were pitfalls/hurdles that could have been avoided, but it's not clear that maintaining perfection every step of the way would have got us to QUIC.
- blueflow 3y ago
  This is not some pitfall. This is a major problem in tech and IMHO totally unacceptable. The same things are re-invented all over again and again without actually making much of an improvement. The result of this is that we get constant upgrades and "improvements", but overall reliability, UI usability, latency and performance in general are actually worsening every year.
  - deleted 3y ago
    [deleted]
  - richardwhiuk 3y ago
    > overall reliability, UI usability, latency and performance is this just a rose-tinted gut feel, or do you have actual data?
    - blueflow 3y ago
      Reliability: Gut feeling. I'm a support engineer. The modern DevOps/Cloud stack is just garbage. People only believe they save money with it because they don't calculate in what they will pay me. UI usability: This is a discoverable, good UI: https://jbss.de/bilder/scr118d.gif https://jbss.de/bilder/scr118d.gif . You can instantly tell what is a button, where you can enter text and what is inert. You can even read out all the hotkeys from the screenshot. Now, without hovering over it with your mouse, check the header of this post (the grey line) and tell me which strings will take you to a place (= are a link), which do an action (= are a button) or are inert. They all look the same and you need to investigate it first with the cursor. And even then you can't tell the buttons ("flag", "vouch") apart from the links ("parent", "context"). Latency and performance: I played RTS games for 15 years. Despite getting old and rustly, i easily hit 120 APM during office work. I can tell if an application can handle it. Things like the Windows Start menu were fast enough for me until like Vista, but now they aren't - i need to wait a bit or i click before it is popped up.
    - KaiserPro 3y ago
      > have actual data The CPU/GPU required to render an interface at 60hz has gone up inline with moore's law.
      - cruffle_duffle 3y ago
        How about resolution? Color depth? Complexity of what is displayed? Last I checked my old commodore PET wasn’t rendering ray-traced 4K UHD graphics at 60hz… 60hz is pretty easy if all you are doing is a simple character buffer.
ithkuil 3y ago
I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking. Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web page). Perhaps they thought that people with really horrible packet loss will just fallback to http or use amp or whatever. But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did
- liveoneggs 3y ago
  Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.
  - srj 3y ago
    Are you saying there's ddos potential because UDP itself doesn't have a connection handshake? There's still one on top of UDP. The initial packet could be forged, but so could one from TCP (a SYN flood).
    - pi-e-sigma 3y ago
      SYN flood cookies are probably older than me at this point
- pi-e-sigma 3y ago
  [flagged]
  - WhitneyLand 3y ago
    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.
jchw 3y ago
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 of resources per origin. While it's true that HTTP/2 can be worse than HTTP/1.1, I don't think it usually is; it's pretty easy to demonstrate just how much better HTTP/2 is over a typical Internet connection. SPDY and HTTP/2 were clearly better and rarely worse, whereas HTTP/3 is almost never worse (maybe when interplay with TCP rate control is poor?) On very unreliable and very high latency connections it can definitely go the other way, but statistically my experience is that a large majority of cases see an improvement on plain-old HTTP/2. That said, for all of the complexity HTTP/2 adds, it is kind of a nice protocol. I like that all of the "special" parts of the HTTP/1.1 request and response were just turned into header fields. HPACK is a minor pain in the ass, but it is pretty efficient. You get multiple concurrent bidirectional streams per connection and they can each send headers/trailers. There's even the MASQUE protocol, which enables unreliable datagrams with HTTP/3. Put together this makes HTTP/2 and HTTP/3 amazingly versatile protocols that you can really use for all kinds of shit, which makes sense given the legacy of HTTP/1.1. There are some pitfalls even still. For example, all of this added complexity has made life a bit harder for load balancing and middleboxes. TCP level load balancing or round robin is basically defeated by using HTTP/2 multiplexing, without the client being explicitly cautious of this.
- pi-e-sigma 3y ago
  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 :)
  - avianlyric 3y ago
    Have you got any data to backup that claim? It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push over a single TCP connection. You’re also completely ignoring TCP slow start process, which you can bet your bottom dollar will prevent six TCP streams beating six multiplexed streams over a single TCP stream when measuring latency from first connection.
richardwhiuk 3y ago
> That's not really head of line blocking, because in HTTP1.1 you'd just open up another connection. All browsers cap the number of connections which are opened to a single domain (I think on IE this was 4, and has increased to 10, but it's not a large number).
- KaiserPro 3y ago
  you are correct, but with keepalive, 10 connections over http1 will beat 1 connection over http2[1] even 4 connections will do better. [1] when there is high latency, or some packet loss, and the requests are batched evenly over all connections.
  - srj 3y ago
    Each of those connections needs its own TCP and TLS handshake making a total of 6 trips. Also, although this didn't take off, h2 had push promise which could have been a big help.
    - pi-e-sigma 3y ago
      Yeah HTTP/2 push is so great that Chrome removed it. Straight from the horse mouth: "However, it was problematic as Jake Archibald wrote about previously, and the performance benefits were often difficult to realize" https://developer.chrome.com/blog/removing-push https://developer.chrome.com/blog/removing-push
jeltz 3y ago
One thing in favor of QUIC is that it had a lot of other people also working on it, not just the HTTP2 team. People like Daniel Stenberg who have worked in networking for ages and are not beholden to the incentive structures at Google.
- alwaysjoe 3y ago
  According to his Wikipedia page he was also on the working group for HTTP2
dontlaugh 3y ago
HTTP/2 works quite well in practice though, both in browsers and for custom RPC protocols. Certainly better than HTTP/1.1.
- KaiserPro 3y ago
  It works well on desktop. On mobile it really performs badly. especially if you are doing interactive things and lazy loading.
1vuio0pswjnm7 3y ago
It is imposible to meaningfuly evaluate these different protocols against each other without considering the "use case". For example, if someone is requesting 100 pages from a site, all hosted on the same domain, and nothing else,1 then HTTP/1.1 is the best of the three. The requests can be sent over a single connection. HOL blocking is not an issue. I have tested this exhaustively outside the browser for over a decade. (People promoting HTTP/2 and HTTP/3, and HN commenters submitting snarky replies every time I mention the utility of HTTP/1.1 pipelining, apparently have not tested this at all.) 1. This is text retrieval. The www is not a handful of browsers controlled by companies that seek to profit from advertising. It was and still is a facility that provides for (hyper)text retrieval. HTTP/2 and HTTP/3 come from an advertising commpany and a CDN that expect ads hosted on different domains in every page. That is what _they_ want. Is that want _www users_ want. We do not know because www users were never asked. We do know that www users do not like ads. When given the choice, they say, "No." The advertising company keeps repeating this HOL blocking as a problem of HTTP/1.1, and now it gets parroted everywhere, and few even know what it means. HOL blocking is not a problem if the www user is not requesting ads and tracking from different domains. How many www users actually want to request ads and tracking and particpate in telemetry. The so-called "tech" company might try to argue that all of them do, or more commonly that, "They do not care." Meanwhile its own employees call ad blocking a "right of passage" (direct quote from a reply I got on HN). The truth is that when evaluating these new HTTP protocols, it matters what the www user is trying to do. Many users are simply trying to retrieve information as text. But the advertising company believes that www users only want to do what is in the interest of the advertising company: let the advertising company's browser automatically send requests for ads, tracking and telemetry purposes. (Except for employees of so-called "tech" companies profiting from the sale of online ad services. They exempted and are free to block the ads and tracking.)
ntwrkgy 3y ago
> 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_RJIb4cPQw2syeDXGV_4/ https://mailarchive.ietf.org/arch/msg/quic/N82WBOa_RJIb4cPQw...

ghusbands 3y ago

> entirely predictable had the HTTP2 team bothered to talk to anyone who did networking I think it's good that things have evolved rather than being stuck behind naysaying. Sure, there were pitfalls/hurdles that could have been avoided, but it's not clear that maintaining perfection every step of the way would have got us to QUIC.

blueflow 3y ago
This is not some pitfall. This is a major problem in tech and IMHO totally unacceptable. The same things are re-invented all over again and again without actually making much of an improvement. The result of this is that we get constant upgrades and "improvements", but overall reliability, UI usability, latency and performance in general are actually worsening every year.
- deleted 3y ago
  [deleted]
- richardwhiuk 3y ago
  > overall reliability, UI usability, latency and performance is this just a rose-tinted gut feel, or do you have actual data?
  - blueflow 3y ago
    Reliability: Gut feeling. I'm a support engineer. The modern DevOps/Cloud stack is just garbage. People only believe they save money with it because they don't calculate in what they will pay me. UI usability: This is a discoverable, good UI: https://jbss.de/bilder/scr118d.gif https://jbss.de/bilder/scr118d.gif . You can instantly tell what is a button, where you can enter text and what is inert. You can even read out all the hotkeys from the screenshot. Now, without hovering over it with your mouse, check the header of this post (the grey line) and tell me which strings will take you to a place (= are a link), which do an action (= are a button) or are inert. They all look the same and you need to investigate it first with the cursor. And even then you can't tell the buttons ("flag", "vouch") apart from the links ("parent", "context"). Latency and performance: I played RTS games for 15 years. Despite getting old and rustly, i easily hit 120 APM during office work. I can tell if an application can handle it. Things like the Windows Start menu were fast enough for me until like Vista, but now they aren't - i need to wait a bit or i click before it is popped up.
  - KaiserPro 3y ago
    > have actual data The CPU/GPU required to render an interface at 60hz has gone up inline with moore's law.
    - cruffle_duffle 3y ago
      How about resolution? Color depth? Complexity of what is displayed? Last I checked my old commodore PET wasn’t rendering ray-traced 4K UHD graphics at 60hz… 60hz is pretty easy if all you are doing is a simple character buffer.

ithkuil 3y ago

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking. Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web page). Perhaps they thought that people with really horrible packet loss will just fallback to http or use amp or whatever. But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did

liveoneggs 3y ago
Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.
- srj 3y ago
  Are you saying there's ddos potential because UDP itself doesn't have a connection handshake? There's still one on top of UDP. The initial packet could be forged, but so could one from TCP (a SYN flood).
  - pi-e-sigma 3y ago
    SYN flood cookies are probably older than me at this point
pi-e-sigma 3y ago
[flagged]
- WhitneyLand 3y ago
  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.

jchw 3y ago

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 of resources per origin. While it's true that HTTP/2 can be worse than HTTP/1.1, I don't think it usually is; it's pretty easy to demonstrate just how much better HTTP/2 is over a typical Internet connection. SPDY and HTTP/2 were clearly better and rarely worse, whereas HTTP/3 is almost never worse (maybe when interplay with TCP rate control is poor?) On very unreliable and very high latency connections it can definitely go the other way, but statistically my experience is that a large majority of cases see an improvement on plain-old HTTP/2. That said, for all of the complexity HTTP/2 adds, it is kind of a nice protocol. I like that all of the "special" parts of the HTTP/1.1 request and response were just turned into header fields. HPACK is a minor pain in the ass, but it is pretty efficient. You get multiple concurrent bidirectional streams per connection and they can each send headers/trailers. There's even the MASQUE protocol, which enables unreliable datagrams with HTTP/3. Put together this makes HTTP/2 and HTTP/3 amazingly versatile protocols that you can really use for all kinds of shit, which makes sense given the legacy of HTTP/1.1. There are some pitfalls even still. For example, all of this added complexity has made life a bit harder for load balancing and middleboxes. TCP level load balancing or round robin is basically defeated by using HTTP/2 multiplexing, without the client being explicitly cautious of this.

pi-e-sigma 3y ago
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 :)
- avianlyric 3y ago
  Have you got any data to backup that claim? It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push over a single TCP connection. You’re also completely ignoring TCP slow start process, which you can bet your bottom dollar will prevent six TCP streams beating six multiplexed streams over a single TCP stream when measuring latency from first connection.

richardwhiuk 3y ago

> That's not really head of line blocking, because in HTTP1.1 you'd just open up another connection. All browsers cap the number of connections which are opened to a single domain (I think on IE this was 4, and has increased to 10, but it's not a large number).

KaiserPro 3y ago
you are correct, but with keepalive, 10 connections over http1 will beat 1 connection over http2[1] even 4 connections will do better. [1] when there is high latency, or some packet loss, and the requests are batched evenly over all connections.
- srj 3y ago
  Each of those connections needs its own TCP and TLS handshake making a total of 6 trips. Also, although this didn't take off, h2 had push promise which could have been a big help.
  - pi-e-sigma 3y ago
    Yeah HTTP/2 push is so great that Chrome removed it. Straight from the horse mouth: "However, it was problematic as Jake Archibald wrote about previously, and the performance benefits were often difficult to realize" https://developer.chrome.com/blog/removing-push https://developer.chrome.com/blog/removing-push

jeltz 3y ago

One thing in favor of QUIC is that it had a lot of other people also working on it, not just the HTTP2 team. People like Daniel Stenberg who have worked in networking for ages and are not beholden to the incentive structures at Google.

alwaysjoe 3y ago
According to his Wikipedia page he was also on the working group for HTTP2

dontlaugh 3y ago

HTTP/2 works quite well in practice though, both in browsers and for custom RPC protocols. Certainly better than HTTP/1.1.

KaiserPro 3y ago
It works well on desktop. On mobile it really performs badly. especially if you are doing interactive things and lazy loading.

1vuio0pswjnm7 3y ago

It is imposible to meaningfuly evaluate these different protocols against each other without considering the "use case". For example, if someone is requesting 100 pages from a site, all hosted on the same domain, and nothing else,1 then HTTP/1.1 is the best of the three. The requests can be sent over a single connection. HOL blocking is not an issue. I have tested this exhaustively outside the browser for over a decade. (People promoting HTTP/2 and HTTP/3, and HN commenters submitting snarky replies every time I mention the utility of HTTP/1.1 pipelining, apparently have not tested this at all.) 1. This is text retrieval. The www is not a handful of browsers controlled by companies that seek to profit from advertising. It was and still is a facility that provides for (hyper)text retrieval. HTTP/2 and HTTP/3 come from an advertising commpany and a CDN that expect ads hosted on different domains in every page. That is what _they_ want. Is that want _www users_ want. We do not know because www users were never asked. We do know that www users do not like ads. When given the choice, they say, "No." The advertising company keeps repeating this HOL blocking as a problem of HTTP/1.1, and now it gets parroted everywhere, and few even know what it means. HOL blocking is not a problem if the www user is not requesting ads and tracking from different domains. How many www users actually want to request ads and tracking and particpate in telemetry. The so-called "tech" company might try to argue that all of them do, or more commonly that, "They do not care." Meanwhile its own employees call ad blocking a "right of passage" (direct quote from a reply I got on HN). The truth is that when evaluating these new HTTP protocols, it matters what the www user is trying to do. Many users are simply trying to retrieve information as text. But the advertising company believes that www users only want to do what is in the interest of the advertising company: let the advertising company's browser automatically send requests for ads, tracking and telemetry purposes. (Except for employees of so-called "tech" companies profiting from the sale of online ad services. They exempted and are free to block the ads and tracking.)

ntwrkgy 3y ago

> 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_RJIb4cPQw2syeDXGV_4/ https://mailarchive.ietf.org/arch/msg/quic/N82WBOa_RJIb4cPQw...