6 ms·

Having written an HTTP server+proxy recently, I haven't been super impressed with HTTP/2 so far. There is some good in it (basically everything I'm not mentioni

by byuu 12y ago

Having written an HTTP server+proxy recently, I haven't been super impressed with HTTP/2 so far. There is some good in it (basically everything I'm not mentioning), but also a lot of bad. First, Firefox (and some others) are forcing TLS to use HTTP/2 : https://wiki.mozilla.org/Networking/http2 https://wiki.mozilla.org/Networking/http2 ; that's a big deal breaker for a lot of people. Yes, encryption is all well and good. I'll all for it! But SSL certs either cost money, or you get them from companies that will want cash to revoke them for you if compromised. SSL/TLS errors are still a royal bitch (and pop up with less popular authorities), with browsers warning you of your impending undoing if you choose to continue (sometimes damn near requiring a blood contract to override.) They also require extra CPU resources. This can be a problem for a site that is only hosting kitten pictures or video game news. It's also a barrier toward people like me experimenting with it, since I now also have to learn how to use TLS if I just want to toy around with the protocol. Second, I don't really agree that using a new, custom-made compression algorithm is a smart way to do headers. We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data, and to overcome the added programming complexity in working with these headers? Third, it's really a fundamentally different way to do things. Like the slides said, you're going to have to really redesign how servers and website packages serve up content to be optimized for this new model, or else performance may even be worse than HTTP/1.1 ... having seen the way the real world works, I'm not very confident that web developers are going to take this seriously enough, and we'll likely see a lot of "HTTP/1 over HTTP/2" behavior anyway (eg not taking advantage of server push.) The servers like Apache and nginx can only go so far toward doing this for you. Fourth, since it's not backward-compatible, we're pretty much not going to be able to use HTTP/2 exclusively for another 5 - 10 years. Which, of course, doesn't mean we shouldn't ever upgrade HTTP/1. It's just kind of crappy that we have to basically run two very different HTTP engines that serve content very differently for the next decade, waiting for people to upgrade their browsers. I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers, like 'Server-Push: "filename", ETag'; and perhaps a specification rule that no HTTP/1.2 request could ever ask for /favicon.ico or /apple-touch-icon.png. Just that would have reduced countless extra wasteful connection requests -> 304 Not Modified responses that we have today on HTTP/1.1, without having to resort to max-age and not being able to instantly update your site anymore. And it would just silently keep working for HTTP/1.1 users (obviously without the 1.2 benefits.) ... Also, all of these slides are always pretty sparse. Given that the new header format is binary, does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2" with an HTTP/1.1 OK response at present. (In fact, it responds with 200 OK even to "GET / ITS_JUST_A_HARMLESS_LITTLE_BUNNY/3.141592" ...)

Lukasa 12y ago
These are all really good points, let me just address one or two. > We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data? The commonly-cited reason for pursuing header compression is making the very first request of a session, when your initial congestion window is small. The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs. Reducing duplication is great and will help for a lot of cases as well, but my impression from the WG has been that it's less important than that first round trip. Note also that HPACK is really quite efficient in terms of CPU cycles. It takes relatively few to compress the headers very heavily. Finally, if you really don't like it, you can turn HPACK off. That gives an out for constrained devices that genuinely can't spare the cycles. > Does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2.0" with an HTTP/1.1 OK response at present. Yes, because there's a draft spec. I invite you to read it[0]. The summary is that you have three options: 1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to. 2. For HTTP/2 over TLS you use ALPN, a feature of TLS that lets you request a protocol in the TLS negotiation (to avoid an extra round trip). 3. Alternatively, you might be able to use HTTP Alternative Services (a WIP draft). The behaviour Apache is using is clearly a bug. [0]: https://tools.ietf.org/html/draft-ietf-httpbis-http2 https://tools.ietf.org/html/draft-ietf-httpbis-http2
- byuu 12y ago
  Thanks for the response! > The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs. Thank you, that makes sense. I definitely see how bloated some of these headers can get these days with super-long user-agent strings, x-foo values, accepted modes, etc. If this is really going to make a substantial number of initial requests and responses fit into a single round-trip, then that sounds like a decent rationale. > Note also that HPACK is really quite efficient in terms of CPU cycles. Is there a C implementation of it? I had quite the bitch of a time to implement INFLATE in C, taking about 10KB of super-nasty code at a minimum. I hope that pain isn't repeated here. Something like just plain LZSS would be a real treat because that's maybe five lines of code. Of course, compressing with LZSS isn't very efficient in the naive case. I'm guessing HPACK is probably an entropy coder ... I'll Google around for more on HPACK, thanks for providing the name to me. > Finally, if you really don't like it, you can turn HPACK off. That's really interesting, and good to hear. So that would have to mean the initial request from the client cannot be compressed (eg your Upgrade header), and the server then must decide what to send back. Hopefully we don't end up with any clients that ignore you and start sending their subsequent request headers compressed anyway. > 1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to. So is this going to be yet another "your PC boots in 16-bit real mode in 2014", where servers have to keep switching from HTTP/1 to HTTP/2 on each new startup forevermore? :/ I mean, I don't know what the alternative would be other than header compatibility with 1.1 ... In this case, will the server and client be able to leave that initial HTTP/1 Upgrade: connection open, and just start using it as HTTP/2, eg sending data back and forth in turn? (I can't see why not.)

by byuu 12y ago

Lukasa 12y ago

These are all really good points, let me just address one or two. > We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data? The commonly-cited reason for pursuing header compression is making the very first request of a session, when your initial congestion window is small. The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs. Reducing duplication is great and will help for a lot of cases as well, but my impression from the WG has been that it's less important than that first round trip. Note also that HPACK is really quite efficient in terms of CPU cycles. It takes relatively few to compress the headers very heavily. Finally, if you really don't like it, you can turn HPACK off. That gives an out for constrained devices that genuinely can't spare the cycles. > Does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2.0" with an HTTP/1.1 OK response at present. Yes, because there's a draft spec. I invite you to read it[0]. The summary is that you have three options: 1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to. 2. For HTTP/2 over TLS you use ALPN, a feature of TLS that lets you request a protocol in the TLS negotiation (to avoid an extra round trip). 3. Alternatively, you might be able to use HTTP Alternative Services (a WIP draft). The behaviour Apache is using is clearly a bug. [0]: https://tools.ietf.org/html/draft-ietf-httpbis-http2 https://tools.ietf.org/html/draft-ietf-httpbis-http2

byuu 12y ago
Thanks for the response! > The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs. Thank you, that makes sense. I definitely see how bloated some of these headers can get these days with super-long user-agent strings, x-foo values, accepted modes, etc. If this is really going to make a substantial number of initial requests and responses fit into a single round-trip, then that sounds like a decent rationale. > Note also that HPACK is really quite efficient in terms of CPU cycles. Is there a C implementation of it? I had quite the bitch of a time to implement INFLATE in C, taking about 10KB of super-nasty code at a minimum. I hope that pain isn't repeated here. Something like just plain LZSS would be a real treat because that's maybe five lines of code. Of course, compressing with LZSS isn't very efficient in the naive case. I'm guessing HPACK is probably an entropy coder ... I'll Google around for more on HPACK, thanks for providing the name to me. > Finally, if you really don't like it, you can turn HPACK off. That's really interesting, and good to hear. So that would have to mean the initial request from the client cannot be compressed (eg your Upgrade header), and the server then must decide what to send back. Hopefully we don't end up with any clients that ignore you and start sending their subsequent request headers compressed anyway. > 1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to. So is this going to be yet another "your PC boots in 16-bit real mode in 2014", where servers have to keep switching from HTTP/1 to HTTP/2 on each new startup forevermore? :/ I mean, I don't know what the alternative would be other than header compatibility with 1.1 ... In this case, will the server and client be able to leave that initial HTTP/1 Upgrade: connection open, and just start using it as HTTP/2, eg sending data back and forth in turn? (I can't see why not.)