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

51–60 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#51

Post by jsnell »

MrBuddyCasino wrote: post #38
WhitneyLand wrote: post #37

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

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.

Re: HTTP/2 and HTTP/3 explained

#52

Post by aetimmes »

MrBuddyCasino wrote: post #38
WhitneyLand wrote: post #37

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

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.

Re: HTTP/2 and HTTP/3 explained

#53

Post by dragonwriter »

aetimmes wrote: post #52
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.

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.

> cmd.exe is a terminal emulator

Isn't Windows Console the (old) terminal emulator, with cmd.exe being just the command-line interpreter.

Re: HTTP/2 and HTTP/3 explained

#54

Post by pi-e-sigma »

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

Earlier quoted context omitted.

[flagged]

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.

Re: HTTP/2 and HTTP/3 explained

#55

Post by pi-e-sigma »

aetimmes wrote: post #52
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.

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.

cmd.exe can be used with shitload command line utilities and is a full blown scripting language just less powerful than Unix bash. The analogy works just fine.

Re: HTTP/2 and HTTP/3 explained

#56

Post by KaiserPro »

dontlaugh wrote: post #49
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…

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

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

Re: HTTP/2 and HTTP/3 explained

#57

Post by afavour »

MrBuddyCasino wrote: post #38
WhitneyLand wrote: post #37

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

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.

Wouldn't it be more likely that maintaining backwards compatibility (an important Windows trait, after all) while also implementing all of Powershell would be a considerably more difficult task than just making a new scripting environment?

Re: HTTP/2 and HTTP/3 explained

#58

Post by pi-e-sigma »

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.

But then he got a promotion. So it was a calculated bet that paid off.

Re: HTTP/2 and HTTP/3 explained

#59

Post by miohtama »

sylware wrote: post #24
GuB-42 wrote: post #22

Earlier quoted context omitted.

Most of the complexity actually comes from encryption. If you don't need encryption, HTTP/1.1 is great. Especially since unencrypted HTTP/2 and 3 are usually not supported. HTTP/2 is sometimes considered a mistake. HTTP/3 is certainly more complex than HTTP/1.1, but that's in large part because it is actually several protocols in one. It replaces TCP with QUIC and therefore implements its features. It also has encryp…

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

We should have stayed in Gopher.

Re: HTTP/2 and HTTP/3 explained

#60

Post by pi-e-sigma »

jchw wrote: post #33
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…

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 :)
Post reply on HN