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

21–30 of 67 posts

Re: Http2 explained

#21

Post by bsdetector »

mongol wrote: post #10
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?

Probably Apple, there is another mention of them later on in the document.

Could be. Mobile Safari uses pipelining, so for Apple there's not a lot of benefit from HTTP2. It isn't a big enough deal for them to push a new protocol, like it is to say Google that doesn't have pipelining in their browser.

Re: Http2 explained

#22

Post by bsdetector »

Lukasa wrote: post #4
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…

Because running multiple TCP connections in parallel plays havoc with TCP congestion control and also plays poorly with the TCP slow-start logic. Every TCP connection begins its receive window again and so it starts small, so fetching many moderately-sized or large resources (think images) will cost you many round trips you didn't need to spend.

If you start out making 6 TCP connections then in a perfect network their receive windows all expand in parallel -- 6 times faster than a single HTTP2 connection. You're likely to see several HTTP2 connection made as well. There'll at least be a second one in case the first SYN is lost, just like with HTTP 1.

The key TCP benefit is keeping a connection open. That can be done with keep-alive as well.

Re: Http2 explained

#23

Post by bagder »

bsdetector wrote: post #21
mongol wrote: post #10

Earlier quoted context omitted.

Probably Apple, there is another mention of them later on in the document.

Could be. Mobile Safari uses pipelining, so for Apple there's not a lot of benefit from HTTP2. It isn't a big enough deal for them to push a new protocol, like it is to say Google that doesn't have pipelining in their browser.

Sorry, but that doesn't make a lot of sense. Pipelining is far from a replacement for HTTP/2 as the document explains a bit. Besides, Safari already supports SPDY because of this.

Re: Http2 explained

#24

Post by jude- »

Lukasa wrote: post #4
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…

Because running multiple TCP connections in parallel plays havoc with TCP congestion control and also plays poorly with the TCP slow-start logic. Every TCP connection begins its receive window again and so it starts small, so fetching many moderately-sized or large resources (think images) will cost you many round trips you didn't need to spend.

Moreover, it's bad from a QoS standpoint. Opening many TCP streams in parallel is not fair to other users sharing the routers between you and the server. You'd get more than your fair share of bandwidth.

Re: Http2 explained

#25

Post by derefr »

jude- wrote: post #20

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

Why not just have the wire sniffer decode the frames before presenting them. If you're interested in what's going on at the HTTP level, you aren't reading packetwise IP packet dumps, because it's hard to make sense of anything and everything is all mixed together; you're looking at abstracted, higher-level flows, where it's just taken for granted that you have a set of linear TCP streams.

HTTP2 is a(n SCTPish) transport-layer protocol squished in underneath an application-layer protocol. Use tools that abstract away the transport-layer protocol.

Or, just, y'know, disable HTTP2? It's an "optional feature" as much as TLS and compression are. Everything that speaks HTTP2 also speaks HTTP1.1, just like everything that speaks compressed/encrypted HTTP also speaks uncompressed/unencrypted HTTP.

Re: Http2 explained

#26

Post by derefr »

jtokoph wrote: post #17

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?

WebSockets were always intended for only one specific thing—allowing web browsers and web servers to speak connection-oriented, stateful wire protocols (like IRC or IMAP) at one-another over an HTTP tunnel.

Any other usage than this has been merely a polyfill for lack of efficiently-multiplexed or easily-server-initiated messaging.

Given an efficiently-multiplexed, bidirectional-async messaging channel in the form of HTTP2, WebSockets can fall back to just being for what they're for, and we can relegate their polyfill usage to the same place Comet "async forever iframes" have gone.

Re: Http2 explained

#27

Post by testrun »

necubi wrote: post #19
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.

I think he/she is not talking about the transport protocol (TCP/UDP), but the higher up layers (5 - 7) cramming functionality from the lower layers. Might be reading it the wrong way.

Re: Http2 explained

#28

Post by serge2k »

necubi wrote: post #19
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.

Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude.

Seems far more reasonable than letting things stagnate for years. It's what chrome is doing with sha1 certs.

Give a timeframe, if you don't get your upgrade in then too bad.

Re: Http2 explained

#30

Post by otterley »

bwross wrote: post #8
Lukasa wrote: post #4

Earlier quoted context omitted.

Because running multiple TCP connections in parallel plays havoc with TCP congestion control and also plays poorly with the TCP slow-start logic. Every TCP connection begins its receive window again and so it starts small, so fetching many moderately-sized or large resources (think images) will cost you many round trips you didn't need to spend.

Additionally, a TCP connection is essentially an operating system resource; you need to set aside a port and space for a send and receive buffer. It might seem fine for a client to open hundreds connections, but imagine being a server with thousands of clients all opening hundreds of connections to you. You very quickly run out of resources and either have to close connections or reject new connections.

That hasn't been a practical problem in many years. Most servers have gigabytes of RAM and a 64-bit kernel nowadays.
Post reply on HN