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

81–90 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#81

Post by jsnell »

MrBuddyCasino wrote: post #70
jsnell wrote: post #51

Earlier quoted context omitted.

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

Here's a source for my claim: https://news.ycombinator.com/item?id=31302174

(I'd heard the story in person from Snover years before that, so it definitely wasn't just sour grapes from somebody about to leave the company.)

I can totally believe that MS had a culture where making improvements to cmd.exe was impossible to justify, but that doesn't actually mean that a greenfield project in the same space would be considered promo-worthy either. It seems more likely that everything in that space was viewed as career suicide and you needed to be working on Internet stuff, just like at today's bigco anything except AI will have the same problem.

Re: HTTP/2 and HTTP/3 explained

#82

Post by pi-e-sigma »

jsnell wrote: post #40
sylware wrote: post #24

Earlier quoted context omitted.

Then HTTP[23] are significantly more costly to implement, they are a mistake then. Nothing to brag about then.

That's a pretty silly take. You're basically asserting that implementation difficulty is always the main priority, and there can never be any worthwhile tradeoffs that could offset that complexity. But in reality, the world probably only needs a few dozen H3 implementations, just like there are only tens of production TCP stacks. But those implementations will be used by billions of people, hundreds of billions of ma…

Enter IPv6. Same arguments, it's 'only' a matter of implementation. 30 years later still most of the implementations are worse than IPv4.

Re: HTTP/2 and HTTP/3 explained

#83

Post by jchw »

pi-e-sigma wrote: post #60
jchw wrote: post #33

Earlier 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 :)

I'm sure it can. However in my real world use cases, HTTP/2 and 3 work better when available for me, so I'm glad to have them. I'm sure this comes as no surprise to most people since SPDY went through a lot of testing before becoming HTTP/2, but just because it doesn't win on every point of the graph does not mean it doesn't still win overall.

Besides that, more than half my point is that I like HTTP/2 and HTTP/3 for the featureset, and you can't get that by increasing the max connection limit for HTTP/1.1.

Re: HTTP/2 and HTTP/3 explained

#84

Post by pi-e-sigma »

kstrauser wrote: post #79
pi-e-sigma wrote: post #14

Earlier quoted context omitted.

[flagged]

> you folks just don't even bother to learn TCP first before shitting on it. Let me stop you right there. I promise you you're not the only person who really knows how TCP works. The people who made HTTP2 and HTTP3 are clearly smart, knowledge folks who have a different perspective than you do. It's OK to disagree with them , but it's a bad look for you to assume that they're ignorant on the subject.

I didn't assume they are ignorant. I assumed that the are fraudulent. They knew they couldn't really improve existing protocols because it's simply not possible but moved forward anyway for personal gain. Just like everything from Google for the last 20 years. You make big splash with new and 'revolutionary' 6th version of instant messaging, get your promo and move on. And here we are, HTTP2 ran its course, time for HTTP3 because we need the promotions and the clout of 'innovators'

Re: HTTP/2 and HTTP/3 explained

#85

Post by chasd00 »

subtra3t wrote: post #29
IgorPartola wrote: post #26

> the UDP protocol wasn't optimized by routers and operating systems over the last decades due to its low usage, making it comparatively slower than TCP What exactly does this mean?

I haven't read the article yet but I think that means that UDP was used less than TCP and so routers/operating systems didn't optimize for it as much as they did for TCP. Hope this helps.

there's nothing to optimize with UDP, you put a datagram on the wire and off it goes. There's no sequence number like in TCP to re-order and construct a stream on the receiving side. There is no stream, it's UDP. You put a datagram on the wire and that's it. There no syn/ack either so no congestion control in routers, no back-off or anything.

Re: HTTP/2 and HTTP/3 explained

#86

Post by KaiserPro »

azinman2 wrote: post #75
KaiserPro wrote: post #65

Earlier quoted context omitted.

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

So what was that real world effect?

5-25% increase in loadtime (median), which caused a drop off in ongoing activity. Users also complained.

Re: HTTP/2 and HTTP/3 explained

#87

Post by JackSlateur »

afavour wrote: post #61
JackSlateur wrote: post #47

Earlier quoted context omitted.

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 .

But you can : you can do whatever horrors you want, privately. You want your own browser with specific compiled-options ? Then do it and deploy it on your private perimeter.

However, if you want to expose something publicly, then your own ideas matters less than the interests of your clients (at least, this is how I see things) : so exposing to the internet something without TLS or with a self-signed / private CA certificates is something that should be denied (those three propositions are the same, if you think about it).

Re: HTTP/2 and HTTP/3 explained

#88

Post by pi-e-sigma »

KaiserPro wrote: post #86
azinman2 wrote: post #75

Earlier quoted context omitted.

So what was that real world effect?

5-25% increase in loadtime (median), which caused a drop off in ongoing activity. Users also complained.

It doesn't matter. You can provide the numbers when asked by the proponents of HTTP2/3 'do you have proof of your claim??', they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.

Re: HTTP/2 and HTTP/3 explained

#89

Post by [deleted] »

afavour wrote: post #61
JackSlateur wrote: post #47

Earlier quoted context omitted.

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 .

[deleted]

Re: HTTP/2 and HTTP/3 explained

#90

Post by superkuh »

JackSlateur wrote: post #87
afavour wrote: post #61

Earlier quoted context omitted.

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 .

But you can : you can do whatever horrors you want, privately. You want your own browser with specific compiled-options ? Then do it and deploy it on your private perimeter. However, if you want to expose something publicly, then your own ideas matters less than the interests of your clients (at least, this is how I see things) : so exposing to the internet something without TLS or with a self-signed / private CA cer…

These kinds of security mindsets exist because browsers have been made extremely insecure these days by encouraging and even setting the default behavior to automatically execute random programs downloaded from random places while at the same time exposing bare metal functionality for speed.

This incredibly insecure business use case has made it so using a browser for merely surfing the web is dangerous and that's why CA TLS is required. But if you just turn JS off... it's fine.

There is so much more to the web than just business web applications selling things or institutional/government websites with private information. There are human people on the web and their use cases matter too. HTTP/3 disregards them. It's fine for now but when Chrome removes HTTP/1.1 for "security reasons" it's not going to be fine.

Post reply on HN