6 ms·

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sh

by bgentry 12y ago

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

bgentry 12y ago
If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.html#_removing_1_x_optimizations http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...
- colin_jack 12y ago
  Couldn't agree more, its also one of the best written tech books I've ever read.
- hueving 12y ago
  If it requires a book to optimize for HTTP2, doesn't that counter your comment's parent's point? It's supposed to be simple.
  - rogeryu 12y ago
    Simple to use doesn't mean simple to create. Even a simple and small code base doesn't mean the think-process preceding the actual programming was simple.
  - exogen 12y ago
    One can write a book about literally anything. But besides that, it already "required" a book – at least two of them in fact, both published before Google even announced SPDY: "High Performance Web Sites" [1] in 2007 and its sequel "Even Faster Web Sites" [2] in 2009, both by Steve Souders. What are they about? Essentially, optimizing your HTTP responses for the ways in which actual web browsers make HTTP requests. Any web performance analysis tool worth using (like YSlow and PageSpeed – both of which Steve Souders was involved in btw) recommended the practices outlined in those books. So, no. I don't think a new book with updated practices says anything about the protocol. The optimization tips from this book will simply become widespread common knowledge the same way they did in the past. [1] http://shop.oreilly.com/product/9780596529307.do http://shop.oreilly.com/product/9780596529307.do [2] http://shop.oreilly.com/product/9780596522315.do http://shop.oreilly.com/product/9780596522315.do
  - bgentry 12y ago
    It requires a small section in a book to tell you how to undo all the tricks you've had to learn in the past 10 years to make an HTTP/1.1 website fast. Most of that is irrelevant and detrimental with HTTP/2, which is kind of the point. You'll get the benefits of those optimizations without having to do anything special to get them. That book is also a phenomenal resource on the performance of all things web-related, so you should check it out regardless of any concerns you have about HTTP/2.
- bkeroack 12y ago
  Thanks. That book is a great resource.
jmspring 12y ago
Try hacking together a rudimentary one over a socket opened by AT commands. Embedded programming including cellular modems for the win, Bob.
derefr 12y ago
The real problem, I think, will be moving to "idiomatic" HTTP2-centric design (lots of little resources, relying on parallel chunked delivery and server-suggested retrieval) while still keeping HTTP/1.1 clients fast. I'm betting there will come a polyfill to make HTTP/2 servers able to deliver content to HTTP/1.1-but-HTML5 web browsers in an HTTP/2-idiomatic way—perhaps, for example, delivering the originally-requested page over HTTP/1.1 but having everything else delivered in HTTP2-ish chunks over a websocket.
- mattmanser 12y ago
  Now that all of the browsers have moved to an auto update model and the only ones that haven't are on mobiles that have short lifespans, that's really only going to be important to the big players for about a year or two. Or maybe I'm overly optimistic!
  - MrBuddyCasino 12y ago
    I'm afraid you are - while things have improved for the reasons you outlined, corporate IT still going to be a major party pooper.
  - josteink 12y ago
    Think all software written for all devices involving every single embedded thingie with a webclient reporting in or polling data everywhere: Every ATM, every POS device, every IOT-device made yet and everyone to be made in the future. Every little gadget with a network stack ever made. And you're telling me all of those will have an updated HTTP-stack within 2 years? You're not being "overly optimistic", you're being tragically unrealistic. Like every other published internet-standard, HTTP/1.0 and HTTP/1.1 will be here until the end of the internet. Sadly the clusterfuck that is HTTP/2.0 will too now. The people talking about HTTP/3.0 already really seems to have missed this bit. (They're talking about 3.0 because HTTP/2.0 didn't really solve the problems we have with HTTP/1.1, but nevermind that, Google steam-rolled this one through and we want to be trendy) The question is now: How many HTTP-stacks do you want to support? Is 2 OK? 3? 4? When do you say enough is enough?
Mojah 12y ago
If at any point you need a reference guide of all the HTTP/1.1 hacks that we {could,should,would} change for HTTP/2, I found the following post really useful: http://ma.ttias.be/architecting-websites-http2-era/ http://ma.ttias.be/architecting-websites-http2-era/
byuu 12y ago
> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to write an HTTP/1.1 server, it'll only take a single engineer several years to write an HTTP/2 server (and one mistake will undermine all of its attempts at security.) If you are going to say, "well use someone else's TLS/HPACK/etc library!", then I'll say the same, "use someone else's HTTP/1.1 header parsing library!" HTTP/2 may turn out to be great for a lot of things. But making things easier/simpler to program is certainly not one of them. This is a massive step back in terms of simplicity.
- ddalex_ro 12y ago
  And the lack in simplicity is why it will fail. People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. People are not good with dealing with a single monstrous object of unfathomable proportions, they will try to break it down in things they understand. If the thing is too complex, with too many inputs, too many outputs and too many states, this is a recipe for confusion. This is why overly complicated things always fail in face of simple things. One could argue that FTP/SFTP was just as good as transferring bytes over network, but HTTP/1.0 won because it was simpler. HTTP/2 was written to tickle the egos of its developers, following the principle - it is hard to write, it is hard to read. And its downfall is going to come from this problem.
  - stephen_g 12y ago
    I'm really confused by comments like these. Are you somebody who implements low-level network protocols? I've written parsers and generators for plenty of binary protocols. It's actually really not that bad - you just need slightly different tooling. Yes, if somebody else hasn't written those it takes a bit longer because you have to do that yourself, but you save a lot of time because it's far easier to parse than text. And guess what - people have already written plenty of tooling for HTTP/2 already... And HTTP/2 is fairly straightforward as protocols go (you wouldn't believe the crazy proprietary control protocols around the place - trust me, HTTP/2 is not at all bad) The 'downfall' of HTTP/2 is also a real long shot - most people are already browsing in browsers that support it, and for many web site owners, using it is literally adding two lines to an nginx configuration file...
EugeneOZ 12y ago
nginx doesn't support http2, apache too.. So maybe it's time to make some efforts to implement it on servers first. Maybe make some donations to apache, nginx dev. teams to speed up this process.
- youngtaff 12y ago
  This is my real worry, at least nginx supports SPDY so has a base to evolve from, Apache support appears to be in a really bad place last time I checked.
  - jimktrains2 12y ago
    The two most largely deployed servers on the Internet don't have HTTP2 support so their experience implementing and using it was never factored into the protocol. And people wonder why I don't like it.
    - youngtaff 12y ago
      MS seem to be doing a good job of building it into IIS, Traffic Server has it, as does H2O, nghttp2 and others. Google, FB, Twitter, Akamai have adapted their http daemons for it. nginx has SPDY support so HTTP/2 should be forthcoming but I wonder if this will be the death of Apache - they didn't seem to be able to update the SPDY plugin to 2.4
- vbezhenar 12y ago
  nginx fully supports SPDY. HTTP/2 is largely based on SPDY so I expect that nginx will support HTTP/2 very soon.
- solarizde 12y ago
  Yes it's a pitty, Apache and mod SPDY is really a pain currently.

by bgentry 12y ago

bgentry 12y ago

If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.html#_removing_1_x_optimizations http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...

colin_jack 12y ago
Couldn't agree more, its also one of the best written tech books I've ever read.
hueving 12y ago
If it requires a book to optimize for HTTP2, doesn't that counter your comment's parent's point? It's supposed to be simple.
- rogeryu 12y ago
  Simple to use doesn't mean simple to create. Even a simple and small code base doesn't mean the think-process preceding the actual programming was simple.
- exogen 12y ago
  One can write a book about literally anything. But besides that, it already "required" a book – at least two of them in fact, both published before Google even announced SPDY: "High Performance Web Sites" [1] in 2007 and its sequel "Even Faster Web Sites" [2] in 2009, both by Steve Souders. What are they about? Essentially, optimizing your HTTP responses for the ways in which actual web browsers make HTTP requests. Any web performance analysis tool worth using (like YSlow and PageSpeed – both of which Steve Souders was involved in btw) recommended the practices outlined in those books. So, no. I don't think a new book with updated practices says anything about the protocol. The optimization tips from this book will simply become widespread common knowledge the same way they did in the past. [1] http://shop.oreilly.com/product/9780596529307.do http://shop.oreilly.com/product/9780596529307.do [2] http://shop.oreilly.com/product/9780596522315.do http://shop.oreilly.com/product/9780596522315.do
- bgentry 12y ago
  It requires a small section in a book to tell you how to undo all the tricks you've had to learn in the past 10 years to make an HTTP/1.1 website fast. Most of that is irrelevant and detrimental with HTTP/2, which is kind of the point. You'll get the benefits of those optimizations without having to do anything special to get them. That book is also a phenomenal resource on the performance of all things web-related, so you should check it out regardless of any concerns you have about HTTP/2.
bkeroack 12y ago
Thanks. That book is a great resource.

jmspring 12y ago

Try hacking together a rudimentary one over a socket opened by AT commands. Embedded programming including cellular modems for the win, Bob.

derefr 12y ago

The real problem, I think, will be moving to "idiomatic" HTTP2-centric design (lots of little resources, relying on parallel chunked delivery and server-suggested retrieval) while still keeping HTTP/1.1 clients fast. I'm betting there will come a polyfill to make HTTP/2 servers able to deliver content to HTTP/1.1-but-HTML5 web browsers in an HTTP/2-idiomatic way—perhaps, for example, delivering the originally-requested page over HTTP/1.1 but having everything else delivered in HTTP2-ish chunks over a websocket.

mattmanser 12y ago
Now that all of the browsers have moved to an auto update model and the only ones that haven't are on mobiles that have short lifespans, that's really only going to be important to the big players for about a year or two. Or maybe I'm overly optimistic!
- MrBuddyCasino 12y ago
  I'm afraid you are - while things have improved for the reasons you outlined, corporate IT still going to be a major party pooper.
- josteink 12y ago
  Think all software written for all devices involving every single embedded thingie with a webclient reporting in or polling data everywhere: Every ATM, every POS device, every IOT-device made yet and everyone to be made in the future. Every little gadget with a network stack ever made. And you're telling me all of those will have an updated HTTP-stack within 2 years? You're not being "overly optimistic", you're being tragically unrealistic. Like every other published internet-standard, HTTP/1.0 and HTTP/1.1 will be here until the end of the internet. Sadly the clusterfuck that is HTTP/2.0 will too now. The people talking about HTTP/3.0 already really seems to have missed this bit. (They're talking about 3.0 because HTTP/2.0 didn't really solve the problems we have with HTTP/1.1, but nevermind that, Google steam-rolled this one through and we want to be trendy) The question is now: How many HTTP-stacks do you want to support? Is 2 OK? 3? 4? When do you say enough is enough?

Mojah 12y ago

If at any point you need a reference guide of all the HTTP/1.1 hacks that we {could,should,would} change for HTTP/2, I found the following post really useful: http://ma.ttias.be/architecting-websites-http2-era/ http://ma.ttias.be/architecting-websites-http2-era/

byuu 12y ago

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to write an HTTP/1.1 server, it'll only take a single engineer several years to write an HTTP/2 server (and one mistake will undermine all of its attempts at security.) If you are going to say, "well use someone else's TLS/HPACK/etc library!", then I'll say the same, "use someone else's HTTP/1.1 header parsing library!" HTTP/2 may turn out to be great for a lot of things. But making things easier/simpler to program is certainly not one of them. This is a massive step back in terms of simplicity.

ddalex_ro 12y ago
And the lack in simplicity is why it will fail. People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. People are not good with dealing with a single monstrous object of unfathomable proportions, they will try to break it down in things they understand. If the thing is too complex, with too many inputs, too many outputs and too many states, this is a recipe for confusion. This is why overly complicated things always fail in face of simple things. One could argue that FTP/SFTP was just as good as transferring bytes over network, but HTTP/1.0 won because it was simpler. HTTP/2 was written to tickle the egos of its developers, following the principle - it is hard to write, it is hard to read. And its downfall is going to come from this problem.
- stephen_g 12y ago
  I'm really confused by comments like these. Are you somebody who implements low-level network protocols? I've written parsers and generators for plenty of binary protocols. It's actually really not that bad - you just need slightly different tooling. Yes, if somebody else hasn't written those it takes a bit longer because you have to do that yourself, but you save a lot of time because it's far easier to parse than text. And guess what - people have already written plenty of tooling for HTTP/2 already... And HTTP/2 is fairly straightforward as protocols go (you wouldn't believe the crazy proprietary control protocols around the place - trust me, HTTP/2 is not at all bad) The 'downfall' of HTTP/2 is also a real long shot - most people are already browsing in browsers that support it, and for many web site owners, using it is literally adding two lines to an nginx configuration file...

EugeneOZ 12y ago

nginx doesn't support http2, apache too.. So maybe it's time to make some efforts to implement it on servers first. Maybe make some donations to apache, nginx dev. teams to speed up this process.

youngtaff 12y ago
This is my real worry, at least nginx supports SPDY so has a base to evolve from, Apache support appears to be in a really bad place last time I checked.
- jimktrains2 12y ago
  The two most largely deployed servers on the Internet don't have HTTP2 support so their experience implementing and using it was never factored into the protocol. And people wonder why I don't like it.
  - youngtaff 12y ago
    MS seem to be doing a good job of building it into IIS, Traffic Server has it, as does H2O, nghttp2 and others. Google, FB, Twitter, Akamai have adapted their http daemons for it. nginx has SPDY support so HTTP/2 should be forthcoming but I wonder if this will be the death of Apache - they didn't seem to be able to update the SPDY plugin to 2.4
vbezhenar 12y ago
nginx fully supports SPDY. HTTP/2 is largely based on SPDY so I expect that nginx will support HTTP/2 very soon.
solarizde 12y ago
Yes it's a pitty, Apache and mod SPDY is really a pain currently.