19 ms·

SPDY and HTTP/2 are pure wins without any real effort. Slap the spdy directive into nginx, a 5 character change, and presto, site goes faster. On sites I've wor

SPDY and HTTP/2 are pure wins without any real effort. Slap the spdy directive into nginx, a 5 character change, and presto, site goes faster. On sites I've worked on, getting a 10-30% advantage is common. That's an awesome ROI for 5 chars. I'm very happy that Google and others had the need and capability to replace HTTP/1.1. They did the hard work, now we all won.

Silhouette 11y ago
SPDY and HTTP/2 are pure wins without any real effort. Slap the spdy directive into nginx, a 5 character change, and presto, site goes faster. On sites I've worked on, getting a 10-30% advantage is common. I'm happy for you that you got those kinds of results just from the switch to SPDY. None of the experiments I've seen did that well, but of course the benefits for these new protocols will depend on the specifics for each individual site. Just to be clear, my main concern here isn't so much the protocol itself as the effect it has on all the infrastructure that is built around it and the implications for compatibility and long-term stability. For example, there have been calls for various kinds of compression/encryption to be required. Then CRIME happened, and it turned out that using gzip compression within an encrypted stream wasn't such a good idea after all. What if the new standards had baked in that kind of security flaw? There is also a whole industry of network monitoring tools used for intrusion protection, virus scanning, fault diagnostics, and many other useful applications. How many of those tools will work with these new protocols? What about cache/proxy tools? Just as there are still few options for production-level servers that cope with HTTP/2, there is also a whole range of intermediary tools that serve useful purposes but don't currently have HTTP/2 counterparts.
- MichaelGG 11y ago
  What's your point, though? Staying on 1.1 would guarantee we continue to lack tools to use HTTP/2. The MITM proxies, which seem to all be written by incompetent software vendors, can strip out the HTTP/2 indicators and force their users back to 1. So if that's their goal, it's easy enough to achieve it. For everyone else, it's optional. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. From an implementor's POV, 2 is easier to implement than 1. The new feature complexity is balanced by having sane parsing rules. And remember: We've (the Internet) have been using SPDY for a couple years now. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc.
  - Silhouette 11y ago
    The MITM proxies, which seem to all be written by incompetent software vendors, I'm not sure not spending time and money supporting a proprietary protocol created by an organisation with a reputation for dropping anything it doesn't like any more at short notice qualifies anyone as "incompetent". can strip out the HTTP/2 indicators and force their users back to 1. At which point anyone whose site was designed to be friendly to HTTP/2 in the ways described in the presentation will perform dramatically worse than it does under HTTP/1.1 if nothing is changed. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. And you don't see a problem with that? We've (the Internet) have been using SPDY for a couple years now. Which Internet? A few high profile sites have been using it, but who else? Several major browsers haven't even supported SPDY until quite recently. Most don't support HTTP/2 fully yet. And in my search earlier, literally no-one was even talking about how to use some of the new capabilities to best effect server-side, never mind demonstrating server-side software that can actually do it. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc. You must be joking. The kind of network monitoring and security devices I was talking about have 5-7 figure price tags in US dollars, sales cycles measured in months, purchasing cycles measured in years, and working lifetimes potentially measured in decades. Two years to understand, integrate, fully test, advertise, provide for evaluation, and ultimately sell support for a new protocol is nothing in this industry. Among the projects I have recently worked on, I think three different major web servers were used, a couple of different reverse proxies for load balancing, and assorted other proxies for caching and the like. As far as I'm aware, exactly none of them fully supports HTTP/2 as of today. And just to be absolutely clear, I'm talking about a collection of software that runs probably 90% of all web sites that exist today, if not more. Perhaps you would argue that the developers of all of these tools are also incompetent, in which case I refer the honourable gentleman to the answer I gave a few moments ago. It's true that there are some organisations that don't rely on mainstream networking hardware and standard software stacks any more. They really do literally design and build their own network infrastructure and write a lot of their own software stack instead of buying from the big brands. However, it's also true that I could probably count the number of such organisations in the entire world on my fingers. For everyone else, these issues do matter. Edit: Here's a handy survey of the adoption of HTTP/2 by various significant tools as of a couple of months ago. It seems broadly in line with my own experience. http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-http2-adoption/ http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-...

SPDY and HTTP/2 are pure wins without any real effort. Slap the spdy directive into nginx, a 5 character change, and presto, site goes faster. On sites I've worked on, getting a 10-30% advantage is common. That's an awesome ROI for 5 chars. I'm very happy that Google and others had the need and capability to replace HTTP/1.1. They did the hard work, now we all won.

Silhouette 11y ago

SPDY and HTTP/2 are pure wins without any real effort. Slap the spdy directive into nginx, a 5 character change, and presto, site goes faster. On sites I've worked on, getting a 10-30% advantage is common. I'm happy for you that you got those kinds of results just from the switch to SPDY. None of the experiments I've seen did that well, but of course the benefits for these new protocols will depend on the specifics for each individual site. Just to be clear, my main concern here isn't so much the protocol itself as the effect it has on all the infrastructure that is built around it and the implications for compatibility and long-term stability. For example, there have been calls for various kinds of compression/encryption to be required. Then CRIME happened, and it turned out that using gzip compression within an encrypted stream wasn't such a good idea after all. What if the new standards had baked in that kind of security flaw? There is also a whole industry of network monitoring tools used for intrusion protection, virus scanning, fault diagnostics, and many other useful applications. How many of those tools will work with these new protocols? What about cache/proxy tools? Just as there are still few options for production-level servers that cope with HTTP/2, there is also a whole range of intermediary tools that serve useful purposes but don't currently have HTTP/2 counterparts.

MichaelGG 11y ago
What's your point, though? Staying on 1.1 would guarantee we continue to lack tools to use HTTP/2. The MITM proxies, which seem to all be written by incompetent software vendors, can strip out the HTTP/2 indicators and force their users back to 1. So if that's their goal, it's easy enough to achieve it. For everyone else, it's optional. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. From an implementor's POV, 2 is easier to implement than 1. The new feature complexity is balanced by having sane parsing rules. And remember: We've (the Internet) have been using SPDY for a couple years now. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc.
- Silhouette 11y ago
  The MITM proxies, which seem to all be written by incompetent software vendors, I'm not sure not spending time and money supporting a proprietary protocol created by an organisation with a reputation for dropping anything it doesn't like any more at short notice qualifies anyone as "incompetent". can strip out the HTTP/2 indicators and force their users back to 1. At which point anyone whose site was designed to be friendly to HTTP/2 in the ways described in the presentation will perform dramatically worse than it does under HTTP/1.1 if nothing is changed. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it. And you don't see a problem with that? We've (the Internet) have been using SPDY for a couple years now. Which Internet? A few high profile sites have been using it, but who else? Several major browsers haven't even supported SPDY until quite recently. Most don't support HTTP/2 fully yet. And in my search earlier, literally no-one was even talking about how to use some of the new capabilities to best effect server-side, never mind demonstrating server-side software that can actually do it. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc. You must be joking. The kind of network monitoring and security devices I was talking about have 5-7 figure price tags in US dollars, sales cycles measured in months, purchasing cycles measured in years, and working lifetimes potentially measured in decades. Two years to understand, integrate, fully test, advertise, provide for evaluation, and ultimately sell support for a new protocol is nothing in this industry. Among the projects I have recently worked on, I think three different major web servers were used, a couple of different reverse proxies for load balancing, and assorted other proxies for caching and the like. As far as I'm aware, exactly none of them fully supports HTTP/2 as of today. And just to be absolutely clear, I'm talking about a collection of software that runs probably 90% of all web sites that exist today, if not more. Perhaps you would argue that the developers of all of these tools are also incompetent, in which case I refer the honourable gentleman to the answer I gave a few moments ago. It's true that there are some organisations that don't rely on mainstream networking hardware and standard software stacks any more. They really do literally design and build their own network infrastructure and write a lot of their own software stack instead of buying from the big brands. However, it's also true that I could probably count the number of such organisations in the entire world on my fingers. For everyone else, these issues do matter. Edit: Here's a handy survey of the adoption of HTTP/2 by various significant tools as of a couple of months ago. It seems broadly in line with my own experience. http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-http2-adoption/ http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-...