9 ms·

Http2 explained

180 points by antouank 12y ago

nly 12y ago
> 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.
- patrickmcmanus 12y ago
  otoh - http on sctp on ipv6 with ipsec hasn't really moved the internet forward.
- necubi 12y ago
  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.
  - testrun 12y ago
    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.
    - detaro 12y ago
      They only try to cram functionality from lower levels into higher ones because establishing new lower ones is nearly impossible. SCTP (or variants of it) would implement a lot that is now build on higher levels, but there is a reason it's only used in private networks.
      - Chlorus 12y ago
        No kidding, take a look at the presentation[0] for multipath TCP - and that was a relatively 'simple' transport layer modification. Look at slide #30 for a glimpse into the madness caused by crappy middleboxes. [0]http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
        xorcist 12y ago
        The alternative is to layer something over HTTP. That's may be even worse. There are no simple ways to upgrade global infrastructure.
  - serge2k 12y ago
    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.
    - billyhoffman 12y ago
      > Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. "Upgrade or suffer" rarely works in practice. Rendering (or rather the lack of rendering) malformed XHTML is a great example of this
    - mobiplayer 12y ago
      Google can push that because there's a huge user base with Chrome and you don't want your shiny ecommerce site to be marked as not safe by Chrome, do you? On the other hand, the packets moved through the wires to send this comment to HN and the ones moved to send this comment to your computer are easily managed by dozens of different people and a handful of different companies with different agendas, budgets, needs and even skills. Cisco definitely manufactured and sold most of the devices out there, but they surely don't manage them or decide when they're upgraded. It gets worse, because actually there's not only Cisco out there. I'm not saying it can't be done, but just look at the slow IPv6 adoption, despite the efforts of all the big players (Google, Cisco, Juniper, Microsoft, Linux, ... !) supporting it in a timely manner, it's still not there.
      - gsnedders 12y ago
        Also remember that everything Google has ever pushed through has been above UDP/TCP, because it's far easier to push through changes on top of that than not. There's a reason why QUIC is being developed on top of UDP instead of as a transport layer in its own right.
otterley 12y ago
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; allowing 100 connections per request doesn't seem like a problem nowadays. And doing so would solve 99% of the browser performance problem without introducing a significantly more complicated multiplexing protocol.
- Lukasa 12y ago
  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.
  - bwross 12y ago
    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.
    - otterley 12y ago
      That hasn't been a practical problem in many years. Most servers have gigabytes of RAM and a 64-bit kernel nowadays.
      - getsat 12y ago
        Linux starts to act weird around 200,000 concurrent connections in my experience, even with aggressive sysctl tuning. You end up with weird edge cases like netstat literally taking 15 minutes of CPU time (in kernel) before it dumps the list of connections to stdout. Not sure about FreeBSD or any other OSes.
jerf 12y ago
"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection" Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come back with explanations of why you might need Content-Length, a different issue.
- Lukasa 12y ago
  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!"
  - Lukasa 12y ago
    Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(
    - jerf 12y ago
      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.
  - ashmud 12y ago
    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?
    - 12y ago
stusmall 12y ago
"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?
- mongol 12y ago
  Probably Apple, there is another mention of them later on in the document.
  - bsdetector 12y ago
    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.
    - bagder 12y ago
      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.
    - billyhoffman 12y ago
      Apple has already committed to (and rolled out support for) SPDY. If you have iOS8, your Mobile Safari can use SPDY. Presumablely they will shift to HTTP/2 as well. http://zoompf.com/blog/2014/06/spdy-coming-to-safari-future-versions-of-ie http://zoompf.com/blog/2014/06/spdy-coming-to-safari-future-...
- bch 12y ago
  > "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 ?
jtokoph 12y ago
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?
- derefr 12y ago
  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.
jude- 12y ago
> 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.
- derefr 12y ago
  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.
  - jude- 12y ago
    > Why not just have the wire sniffer decode the frames before presenting them. Certainly possible, but why make our lives harder by implementing HTTP/2 such that it requires a decoder to read in the first place? If the number of bytes sent remains the same, why not make the fields as self-documenting as possible? > Everything that speaks HTTP2 also speaks HTTP1.1 No, they have fundamentally different wire formats. This statement isn't even true for HTTP/1.1 and HTTP/1.0, which both have the same wire formats and share many fields but have different interpretations for some of them.
muppetman 12y ago
I find it amusing that the document that explains HTTP2 is a PDF I have to download. There's no HTML version. (Yes, I'm aware that HTTP != HTML.)
geographomics 12y ago
At the risk of not being quite critical enough for HN - that was an excellent read. Clear explanations, a very pleasant layout, and useful visual metaphors for the trickier parts of the spec. I found it to be both enjoyable and informative. A really nice example of documentation done well.
- bagder 12y ago
  As the author of the document - thanks!
gaastonsr 12y ago
Beautifully written, thanks for this.
teddyh 12y ago
Still not even a mention of SRV records in the “critiques” section. I’m more saddened than surprised, really.
deleted 12y ago
[deleted]
djhworld 12y ago
Is there a "one page" HTML version of this? I tend to read stuff on my phone via apps like Instapaper etc, PDFS don't really suit mobile devices :(
Mojah 12y ago
If anyone is looking for a practical guide to using HTTP/2, what changes it will bring compared to HTTP/1.1 in terms of architecting websites and web applications, I've written a guide on that: http://ma.ttias.be/architecting-websites-http2-era/ http://ma.ttias.be/architecting-websites-http2-era/
gremlinsinc 12y ago
Wow - was expecting something scary, super technical and over my head - very easy overview - not that I'm not technical I do server support for a huge web hosting firm - but sometimes http docs get way too tech spec --this was very clear to understand.

180 points by antouank 12y ago

nly 12y ago

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

patrickmcmanus 12y ago
otoh - http on sctp on ipv6 with ipsec hasn't really moved the internet forward.
necubi 12y ago
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.
- testrun 12y ago
  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.
  - detaro 12y ago
    They only try to cram functionality from lower levels into higher ones because establishing new lower ones is nearly impossible. SCTP (or variants of it) would implement a lot that is now build on higher levels, but there is a reason it's only used in private networks.
    - Chlorus 12y ago
      No kidding, take a look at the presentation[0] for multipath TCP - and that was a relatively 'simple' transport layer modification. Look at slide #30 for a glimpse into the madness caused by crappy middleboxes. [0]http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
      - xorcist 12y ago
        The alternative is to layer something over HTTP. That's may be even worse. There are no simple ways to upgrade global infrastructure.
- serge2k 12y ago
  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.
  - billyhoffman 12y ago
    > Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. "Upgrade or suffer" rarely works in practice. Rendering (or rather the lack of rendering) malformed XHTML is a great example of this
  - mobiplayer 12y ago
    Google can push that because there's a huge user base with Chrome and you don't want your shiny ecommerce site to be marked as not safe by Chrome, do you? On the other hand, the packets moved through the wires to send this comment to HN and the ones moved to send this comment to your computer are easily managed by dozens of different people and a handful of different companies with different agendas, budgets, needs and even skills. Cisco definitely manufactured and sold most of the devices out there, but they surely don't manage them or decide when they're upgraded. It gets worse, because actually there's not only Cisco out there. I'm not saying it can't be done, but just look at the slow IPv6 adoption, despite the efforts of all the big players (Google, Cisco, Juniper, Microsoft, Linux, ... !) supporting it in a timely manner, it's still not there.
    - gsnedders 12y ago
      Also remember that everything Google has ever pushed through has been above UDP/TCP, because it's far easier to push through changes on top of that than not. There's a reason why QUIC is being developed on top of UDP instead of as a transport layer in its own right.

otterley 12y ago

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; allowing 100 connections per request doesn't seem like a problem nowadays. And doing so would solve 99% of the browser performance problem without introducing a significantly more complicated multiplexing protocol.

Lukasa 12y ago
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.
- bwross 12y ago
  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.
  - otterley 12y ago
    That hasn't been a practical problem in many years. Most servers have gigabytes of RAM and a 64-bit kernel nowadays.
    - getsat 12y ago
      Linux starts to act weird around 200,000 concurrent connections in my experience, even with aggressive sysctl tuning. You end up with weird edge cases like netstat literally taking 15 minutes of CPU time (in kernel) before it dumps the list of connections to stdout. Not sure about FreeBSD or any other OSes.

jerf 12y ago

"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection" Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come back with explanations of why you might need Content-Length, a different issue.

Lukasa 12y ago
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!"
- Lukasa 12y ago
  Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(
  - jerf 12y ago
    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.
- ashmud 12y ago
  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?
  - 12y ago

stusmall 12y ago

"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?

mongol 12y ago
Probably Apple, there is another mention of them later on in the document.
- bsdetector 12y ago
  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.
  - bagder 12y ago
    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.
  - billyhoffman 12y ago
    Apple has already committed to (and rolled out support for) SPDY. If you have iOS8, your Mobile Safari can use SPDY. Presumablely they will shift to HTTP/2 as well. http://zoompf.com/blog/2014/06/spdy-coming-to-safari-future-versions-of-ie http://zoompf.com/blog/2014/06/spdy-coming-to-safari-future-...
bch 12y ago
> "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 ?

jtokoph 12y ago

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?

derefr 12y ago
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.

jude- 12y ago

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

derefr 12y ago
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.
- jude- 12y ago
  > Why not just have the wire sniffer decode the frames before presenting them. Certainly possible, but why make our lives harder by implementing HTTP/2 such that it requires a decoder to read in the first place? If the number of bytes sent remains the same, why not make the fields as self-documenting as possible? > Everything that speaks HTTP2 also speaks HTTP1.1 No, they have fundamentally different wire formats. This statement isn't even true for HTTP/1.1 and HTTP/1.0, which both have the same wire formats and share many fields but have different interpretations for some of them.

muppetman 12y ago

I find it amusing that the document that explains HTTP2 is a PDF I have to download. There's no HTML version. (Yes, I'm aware that HTTP != HTML.)

geographomics 12y ago

At the risk of not being quite critical enough for HN - that was an excellent read. Clear explanations, a very pleasant layout, and useful visual metaphors for the trickier parts of the spec. I found it to be both enjoyable and informative. A really nice example of documentation done well.

bagder 12y ago
As the author of the document - thanks!

gaastonsr 12y ago

Beautifully written, thanks for this.

teddyh 12y ago

Still not even a mention of SRV records in the “critiques” section. I’m more saddened than surprised, really.

deleted 12y ago

[deleted]

djhworld 12y ago

Is there a "one page" HTML version of this? I tend to read stuff on my phone via apps like Instapaper etc, PDFS don't really suit mobile devices :(

Mojah 12y ago

If anyone is looking for a practical guide to using HTTP/2, what changes it will bring compared to HTTP/1.1 in terms of architecting websites and web applications, I've written a guide on that: http://ma.ttias.be/architecting-websites-http2-era/ http://ma.ttias.be/architecting-websites-http2-era/

gremlinsinc 12y ago

Wow - was expecting something scary, super technical and over my head - very easy overview - not that I'm not technical I do server support for a huge web hosting firm - but sometimes http docs get way too tech spec --this was very clear to understand.