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

91–100 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#91

Post by pi-e-sigma »

afavour wrote: post #57
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.

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?

yes, too much to ask for a multi-trillion company, especially that this company was until recently well known for maintaining crazy level of backward compatibility

Re: HTTP/2 and HTTP/3 explained

#92

Post by KaiserPro »

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…

> It was only a bit later that it became clear just how ossified TCP was.

It has almost _always_ been tied to OS, but moreover the OS of every node in between you and the webpage. That was the most frustrating thing, there were and are solutions for making TCP more latency resistant but also get better throughput and deal with "buffer bloat" which was a big thing at the time.

I was working in transcontental bulk transfer which used to mean that things like aspera/fasp was the defacto standard for fast/latency/loss resistant transport. So I had seen this first hand. I suspect it was probably why I was dismissed, because I wasn't a dyed in the wool webdev.

Re: HTTP/2 and HTTP/3 explained

#93

Post by cruffle_duffle »

KaiserPro wrote: post #66
richardwhiuk wrote: post #50

Earlier quoted context omitted.

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

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.

Re: HTTP/2 and HTTP/3 explained

#94

Post by bsdetector »

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…

SPDY's header compression allowed cookies to be easily leaked. This vulnerability was well known at the time so had they even asked an intern at Google Zero to look at it they would have been immediately schooled.

https://bugzilla.mozilla.org/show_bug.cgi?id=779413

In their performance tests vs HTTP 1.1 the team simulated loading many top websites, but presumably by accident used a single TCP connection for SPDY across the entire test suite (this was visible in their screenshots of Chrome's network panel, no connection time for SPDY).

They also never tested SPDY against pipelining - but Microsoft did and found pipelining performed the same. SPDY's benefit was merely a cleaner, less messy equivalent of pipelining.

So I think it's fair to say these developers were not the best Google had to offer.

Re: HTTP/2 and HTTP/3 explained

#95

Post by pi-e-sigma »

cruffle_duffle wrote: post #93
KaiserPro wrote: post #66

Earlier quoted context omitted.

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

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.

How about latency of the key press? Why Apple II has practically zero latency and your modern monster desktop is visibly lagging in a fucking text editor? Despite Apple II being literally millions times slower than a modern rig.

Re: HTTP/2 and HTTP/3 explained

#96

Post by natoliniak »

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…

> you can do whatever horrors you want

and i do. i run a personal static website over http. oh the horror.

Re: HTTP/2 and HTTP/3 explained

#97

Post by srj »

liveoneggs wrote: post #71
ithkuil wrote: post #18

Earlier quoted context omitted.

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…

Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.

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

Re: HTTP/2 and HTTP/3 explained

#98

Post by Aloisius »

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…

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

Re: HTTP/2 and HTTP/3 explained

#99

Post by KaiserPro »

cruffle_duffle wrote: post #93
KaiserPro wrote: post #66

Earlier quoted context omitted.

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

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.

> old commodore PET wasn’t rendering ray-traced 4K UHD graphics at 60hz…

Nor is my phone, yet newer apps are now struggling to render basic GUIs at 60hz.

Re: HTTP/2 and HTTP/3 explained

#100

Post by srj »

KaiserPro wrote: post #67
richardwhiuk wrote: post #36

Earlier quoted context omitted.

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

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