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

Http2 explained

daniel.haxx.se

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Http2 explained

#11

Post by youngtaff »

otterley wrote: post #2

I'm still not entirely sure why the problems inherent in single-stream connections (request/response) couldn't be solved simply by removing the artificial RFC-recommended limitation on parallel connections to a server. As the author says, providers have been escaping this limitation for years by simply adding hostname aliases, but has nothing negative to say about it. Modern HTTP servers are highly concurrent; allowi…

Will Chan of Chromium wrote a good post explaining the congestion issues with opening many TCP connections - https://insouciant.org/tech/network-congestion-and-web-brows...

Re: Http2 explained

#12

Post by jerf »

Lukasa wrote: post #6
Lukasa wrote: post #5

Earlier quoted context omitted.

Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial congestion window on your new connection. HTTP/2 allows you to avoid that by saying "I'm done with this stream now, sorry!"

Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(

No problem, I see I was not clear. Yes, I am specifically curious about the edge case when you "can't" just disconnect the TCP. Scare quoted because I'm sure you can, it just involves something undesirable happening. I have vague ideas and guesses, but I'm curious about what the intent was.

Re: Http2 explained

#13

Post by bch »

stusmall wrote: post #7

"Some of the bigger players in the HTTP field have been missing from the working group discussions and meetings. I don't want to mention any particular company or product names here, but clearly some actors on the Internet today seem to be confident that IETF will do good without these companies being involved..." I haven't been following this much, who is he referring to?

> "clearly some actors on the Internet today seem to be confident that IETF will do good without these companies being involved"

That's impossible to believe. Now I wonder -- what's the _real_ reason ?

Re: Http2 explained

#14

Post by patrickmcmanus »

ashmud wrote: post #9
Lukasa wrote: post #5

Earlier quoted context omitted.

Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial congestion window on your new connection. HTTP/2 allows you to avoid that by saying "I'm done with this stream now, sorry!"

How do web browsers handle cancelled requests? Subjectively speaking, it feels like browsers can take a while to recover from cancelling the loading of a large page/page with a large number of assets. Could this be part of that?

you're right. Cancel's in H1 are very painful because all the in-progress transactions have to be torn down completely. New transactions have to set them all up again.

H2 let's you just send the server a short message that says "stop sending that stream" and you can go ahead and pipeline a new request right along with that cancel.

This happens a lot more than you think as you browse through a collection of things and are just scanning them and clicking the next button - that's a really common use case h2 will handle much better.

Re: Http2 explained

#15

Post by nly »

> 8.4.6. “It has layering violations”

> Seriously, that's your argument? Layers are not holy untouchable pillars of a global religion

If layers aren't 'untouchable pillars', then why have we not fixed the ones we have? IPSec, IP, TCP and TLS are all a jumbled rotten mess. Poor layering has resulted in a lot of warts like inefficient or underleveraged handshakes and the lack of things like mobility, multi-homing, authentication, reliable datagrams and stream multiplexing. What is really being said here is yes, the layers we have (TCP, NAT) really are untouchable pillars.

Cramming workarounds in to a higher, application-specific, layers doesn't benefit the wider Internet.

Re: Http2 explained

#16

Post by patrickmcmanus »

otterley wrote: post #2

I'm still not entirely sure why the problems inherent in single-stream connections (request/response) couldn't be solved simply by removing the artificial RFC-recommended limitation on parallel connections to a server. As the author says, providers have been escaping this limitation for years by simply adding hostname aliases, but has nothing negative to say about it. Modern HTTP servers are highly concurrent; allowi…

The first answer is that parallelism without priority (which is what parallel h1 is) can lead to some really horrible outcomes. Critical pieces of the page get totally shoved out of the way while bulky, but less important parts, get the bandwidth they need.That's why H2 and SPDY are both mux'd and prioritized.

also you can definitely over-shard with h1.. as said downthread that can cause congestion problems and indeed even packet loss. For a little while pinterest had gigantic packet loss problems that were due to over sharding of images.

The really annoying thing is that the "right amount of sharding" has to do with available bandwidth, the size of the resources being sent, and the latency between client and server.. Those things aren't really knowable on a generic per-origin basis when setting your links up - so the spdy/h2 approach works better in practice.

if I had a criticism here, its that implementing priority right is a lot trickier than just have a bunch of independent connections. We will probably see some bad implementations in the early days until folks internalize how important it is.

Re: Http2 explained

#17

Post by jtokoph »

Does anyone know how WebSockets fit into the http2 world? Will we just end up using http2 server push and the rest of the protocol as a substitute for WebSockets?

Re: Http2 explained

#18

Post by patrickmcmanus »

nly wrote: post #15

> 8.4.6. “It has layering violations” > Seriously, that's your argument? Layers are not holy untouchable pillars of a global religion If layers aren't 'untouchable pillars', then why have we not fixed the ones we have? IPSec, IP, TCP and TLS are all a jumbled rotten mess. Poor layering has resulted in a lot of warts like inefficient or underleveraged handshakes and the lack of things like mobility, multi-homing, auth…

otoh - http on sctp on ipv6 with ipsec hasn't really moved the internet forward.

Re: Http2 explained

#19

Post by necubi »

nly wrote: post #15

> 8.4.6. “It has layering violations” > Seriously, that's your argument? Layers are not holy untouchable pillars of a global religion If layers aren't 'untouchable pillars', then why have we not fixed the ones we have? IPSec, IP, TCP and TLS are all a jumbled rotten mess. Poor layering has resulted in a lot of warts like inefficient or underleveraged handshakes and the lack of things like mobility, multi-homing, auth…

Good luck getting everybody to upgrade their kernel to support your new transport protocol. Realistically, UDP and TCP are what we have. We may wish they were more suited to modern use cases, but realistically we must build on those foundations. If that means violating "layering" for performance, so be it.

Re: Http2 explained

#20

Post by jude- »

> 8.4.4. “Not being ASCII is a deal-breaker”

> Yes, we like being able to see protocols in the clear since it makes debugging and tracing easier. But text based protocols are also more error prone and open up for much more parsing and parsing problems.

> If you really can't take a binary protocol, then you couldn't handle TLS and compression in HTTP 1.x either and its been there and used for a very long time.

First, you can have the best of both worlds of fixed-sized frames and human readability: make sure each HTTP keyword has a finite, short length. ASCII abbreviations are an acceptable means to this end. This would also eliminate a lot of the implementation difficulties and performance penalties of writing and using a parser.

Second, TLS and compression are not integrated into HTTP/1.1, meaning that people who want to be able to read an HTTP stream on the wire can do so by disabling these features. It's disingenuous to claim that people don't care about human readability just because these extensions exist.

Post reply on HN