Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2 and HTTP/3 explained

alexandrehtrb.github.io

Post reply on HN
Print view View original

61–70 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#61

Post by afavour »

JackSlateur wrote: post #47
superkuh wrote: post #44

The biggest difference is that HTTP/3 (and to a lesser extent, 2) are designed and implemented entirely and exclusively for for profit-business use cases at the detriment to all other use cases and specifically longevity. Since there are no HTTP/3 implementations that allow the use of non-CA TLS or even just plain text that means in order to host a visitable website for major browsers you have to get continued re-app…

Which is, in my opinion, good I am sick of seing all kind of unsecure websites (or other things over TLS) as well as private CA Those things should not be put in production. If people cannot willingly work properly, then their life should be made harder and harder.

Nope. It should be possible to set up infrastructure to serve web content without being beholden to a certificate authority. By all means there can be a bunch of warnings whenever anyone tries to access it but it should still be possible.

Re: HTTP/2 and HTTP/3 explained

#62

Post by blueflow »

richardwhiuk wrote: post #50
blueflow wrote: post #21

Earlier quoted context omitted.

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.

> overall reliability, UI usability, latency and performance is this just a rose-tinted gut feel, or do you have actual data?

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

Re: HTTP/2 and HTTP/3 explained

#63

Post by pornel »

anonymoushn wrote: post #10
tialaramex wrote: post #5

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/HTTP_pipelining In practice it's not wrong. HTTP 1.x servers, and especially "middleboxes" get this badly enough wrong that when you ship this feature ("HTTP 1 pipelining") your users will report a low but persistent error rate. Oops the password request and image download were kinda sorta fused together. You can (and some very minor browsers do) just insist it's not your bug and then pa…

Do you get a mostly eliminated error rate if you only use pipelining over TLS, or have server operators situated their defective middleboxes behind their TLS termination?

Not really, because broken proxies include anti-virus software that sits at the endpoint, as well as corporate TLS-MITMing boxes.

Browsers have spent years trying to find a way to deploy pipelining, but nothing really worked. You can't even allowlist based on known-good User-Agent or Via headers, because the broken proxies are often transparent. It's also very hard to detect pipelining errors, because you don't just get responses out of order, you may get response bodies mangled or interleaved.

The idea is truly dead. With H2 being widely supported now, and having superior pipelining in every way, there's no incentive to retry the pain of deossifying H1.

Re: HTTP/2 and HTTP/3 explained

#64

Post by jsnell »

pi-e-sigma wrote: post #54
jsnell wrote: post #48

Earlier quoted context omitted.

Here's a third option: the five month old anonymous HN account claiming to know what the H2 designers were thinking of is wrong. How would you compare the likelihood of that to your two options? 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, and that was already the case during the original SPDY design w…

So again, why HTTP3 is pushed when HTTP2 was meant to be the holy grail? Seems that even Google doesn't consider HTTP2 to be so great.

Umm... Like, pretty clearly H2 wasn't meant to be the Holy Grail? Not sure where you're getting that from. (Though as an aside, it feels like you've now backtracked from "H2 is a failure that's worse than H1" through "H2 was a marginal improvement" to "H2 wasn't the holy grail".)

It didn't need to be the Holy Grail to be worth creating. It just needed to be better than H1 was, or better than what H1 could be evolved to with the same amount of effort. And likewise, it's totally possible for H2 to be better than H1 while also H3 is better than H2.

You appear to be confused by the idea that somebody would ever create something other than the absolute best possible thing. Why create H2 first, rather than just jump straight to H3?

One obvious reason is that H2 is far less complex than H3 thanks to piggybacking on TCP as the transport mechanism. The downside is that you then have to deal with all the problems of TCP as well. At the time, there would have been a lot of optimism about eliminating those problems by evolving TCP. An extension for connection migration, an extension for 0-RTT connection setup, an extension for useful out of order data delivery, etc.

It was only a bit later that it became clear just how ossified TCP was. Up until then, one could have told a story about how Microsoft controlled the primary client operating system, and were not really motivated to implement the RFCs in a timely manner, and that's why the feature rollouts were taking a decade. In the 2010s, it became clear that evolution was impossible even when all the coordination and motivation was there. See TCP Fast Open for a practical example.

So around 2015-ish you see big tech companies switch to UDP-based protocols just so that they can actually do protocol evolution.

The other plausible reason is that it's going to be far easier to get the initial work for making H2 funded, since the scope is more limited. And once you show the real-world gains (which, again, would have been there since H2 is better than H1), you then have the credibility to get funding for a more ambitious project.

Re: HTTP/2 and HTTP/3 explained

#65

Post by KaiserPro »

ithkuil wrote: post #18
KaiserPro wrote: post #13

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

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 pa…

> 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

As someone who was part of the rollout of HTTP2 for a $large_website, I can confirm that "this will harm mobile performance" was outright and flatly rejected. This included people who were our reps on the w3c. I just had to sit there and wait for the real world metrics to come in

"multiplexing will remove bottlenecks!"

"benchmarks prove that its faster!"

"you just don't understand how TCP works"

"the people at google are very smart, what do you know?"

"server push will reduce latency"

etc etc etc.

We even had the graphs of page size over time (going ever up) and average usable bandwidth (not keeping up, especially on mobile) None of that mattered until the rollout had a real world effect on our performance.

Re: HTTP/2 and HTTP/3 explained

#66

Post by KaiserPro »

richardwhiuk wrote: post #50
blueflow wrote: post #21

Earlier quoted context omitted.

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.

> overall reliability, UI usability, latency and performance is this just a rose-tinted gut feel, or do you have actual data?

> have actual data

The CPU/GPU required to render an interface at 60hz has gone up inline with moore's law.

Re: HTTP/2 and HTTP/3 explained

#67

Post by KaiserPro »

richardwhiuk wrote: post #36
KaiserPro wrote: post #13

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

> 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).

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.

Re: HTTP/2 and HTTP/3 explained

#68

Post by KaiserPro »

WhitneyLand wrote: post #37
pi-e-sigma wrote: post #25

Earlier quoted context omitted.

[flagged]

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.

> It’s not an error in thinking to assume a good faith basis

Its nothing about faith here. I was looking at the evidence. The problem was that a lot of people I was working with had faith that SPDY was something that it wasn't.

They either interpreted what I was saying as either an excuse to not change infra (the change was minimal), "old think" because I was not a hot young fullstack node engineer, or that they thought I was trying to be more clever than google.

Re: HTTP/2 and HTTP/3 explained

#69

Post by chucke »

jsnell wrote: post #64
pi-e-sigma wrote: post #54

Earlier quoted context omitted.

So again, why HTTP3 is pushed when HTTP2 was meant to be the holy grail? Seems that even Google doesn't consider HTTP2 to be so great.

Umm... Like, pretty clearly H2 wasn't meant to be the Holy Grail? Not sure where you're getting that from. (Though as an aside, it feels like you've now backtracked from "H2 is a failure that's worse than H1" through "H2 was a marginal improvement" to "H2 wasn't the holy grail".) It didn't need to be the Holy Grail to be worth creating. It just needed to be better than H1 was, or better than what H1 could be evolved…

That's quite the history lesson, thx for the info.

I agree that H2 is defacto better than H1, and easier to implement when compared to H3. However, I'll call out the 2 biggest time sinks of the RFC: stream prioritisation and server push. Both of which had narrow application, and incomplete/inefficient specification. H3 seems to have ditched both. My question is, how did this ever end up in the final RFC? As both seem like the kind of thing that could have been easily disproved in SPDY deployments, as well as just asking people doing HTTP for a living.

Re: HTTP/2 and HTTP/3 explained

#70

Post by MrBuddyCasino »

jsnell wrote: post #51
MrBuddyCasino wrote: post #38

Earlier 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.

That's actually a hilarious example (in the "hilariously wrong" sense), because Jeffrey Snover had to accept a demotion to make PowerShell. He was told it was a useless project, not fit for someone at his level to work on, and bumped down a level when he persisted.

Interesting, because a Windows kernel hacker told it differently [0]:

These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones.

(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)

[0] https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...

Post reply on HN