5 ms·

Under the "Why Revise HTTP" http://http2.github.io/faq/#why-revise-http http://http2.github.io/faq/#why-revise-http section the summary is basically "So we don

Under the "Why Revise HTTP" http://http2.github.io/faq/#why-revise-http http://http2.github.io/faq/#why-revise-http section the summary is basically "So we don't have to be as mindful of the number of HTTP requests" Is this really a compelling reason? I would argue it is not, especially if we have to trade a human-readable and easy to troubleshoot text-based protocol with a binary one. It seems like we are solving a small problem by creating a larger one.

ubernostrum 12y ago
The correct answer is that HTTP/2 has to do this because Google is unable to show you a simple search box without making over a dozen HTTP requests. Their more involved properties require dozens to even hundreds of requests in order to perform complex tasks like showing a list of plain text posts. And, of course, they can't possibly impose any kind of discipline on the way they do things, so instead the entire internet has to change to accommodate them.
- FooBarWidget 12y ago
  It's so easy to blame everything on Google/Microsoft/$OTHER_BLACK_SHEEP being stupid. I don't know how many websites you've been to, but a large number of them perform hundreds of requests, not just Google. The modern web is full of images, CSS, webfonts, dynamically loaded Javascript, mashups and other things, each which require one or more HTTP requests. Having lots of requests has been the reality for a large part of the web for a number of years now.
- zaphar 12y ago
  My plaintext no animations statically generated site does 5 connections to load the content. http://jeremy.marzhillstudios.com http://jeremy.marzhillstudios.com Now I could optimize that even more by inlining everything with data-inline: but that would impact caching code and be strictly worse for the network. A property from google even websearch has fancy transitions and animations and dynamic content. And Google has every incentive to limit the number of connections to their page. When I worked there I worked on some of those technologies specifically to avoid too many connections. Blaming Google for not being disciplined enough disregards their economic incentives to be disciplined enough. They invested a lot of energy in this before SPDY came out. There comes a time where you just have to recognize that the protocol is fighting against you and either give up or evolve the protocol.
- twistedpair 12y ago
  Google created GWT which uses every trick under the sun to reduce connection counts. I use it on my sites and if you don't let your web property devolve into a bolt-on JS mire (as many large sites do, i.e. Borders recently made 248 requests to load), you can load the page/app in 4 requests. (1) index.html, (2) app.nocache.js (3) A56284CFC0D680C7DBA0F93CA9AE8F75.cache.js (cache fragment for given page/state) (4) XHR for page data/state to display Now, if you've got some CSS and minor images/fonts, these can be an your options request (5) resource bundle. On many Google properties, (2 and 5) are inlined into (1). The take away? These technologies and frameworks have been out there for a long time (8 years in the case of GWT), so you don't have to make hundreds of requests if you're disciplined. I can only assume Google has thrown in the towel trying to get script kiddies to ever be disciplined.
- wpietri 12y ago
  Exactly right. Humans only exist to serve their tools. No, wait a sec. That doesn't sound right. Could it be that our tools exist to serve humans? And that rather than putting effort into accommodating ourselves to the limitations of our current tools, we should instead put our effort into making tools that work the way we want? Nah, sounds crazy. If HTTP/1 was good enough for my grand-dad, it's good enough for me.
FooBarWidget 12y ago
Human-readable is only a matter of tooling. Why is HTTP human-readable? Because you have a lot of tools that understand ASCII. Without them, HTTP is just as unreadable to you as any other stream of bytes.
- protonfish 12y ago
  True, but it doesn't undermine my point. You can troubleshoot HTTP 1.1 with common, generic tools. How do you work with HTTP2? I have no idea.
  - FooBarWidget 12y ago
    The tools don't exist right now, but they will become available. Existence of tooling follows demand. HTTP 2 has a large momentum so tooling will exist.
    - bigbango 12y ago
      I'm not willing trade away the human readability of HTTP/1 for a a performance gain that I really don't need. What about tools for reading corrupt binary HTTP/2 frames?
  - wpietri 12y ago
    When I'm debugging HTTP, 98% of the time it's either with curl, Wireshark, or by dumping state in my own server-side code. Things like curl will work just the same. Wireshark has an HTTP/2 plugin; given their history, I'm sure it'll be excellent by the time there's much HTTP2 in the wild. And anybody writing server-side code is hacking together their own tools anyhow. The rare occasion where this will be a big difference for me is telnetting to port 80 and typing HTTP by hand. Honestly, I only do that out of habit; I can do the same things just as well with curl. But even when HTTP/2 ships, I'm sure it will be at least a decade before servers stop supporting HTTP/1.1. Probably longer. So I'm not expecting this to make a big difference to my debugging habits.
bcoates 12y ago
I don't mind the binary protocol that much, but the apparent assumption that every endpoint is a fat stateful cache (push, multiplexing) is madness. Have they actually worked out how to implement a HTTP/2 front end cache in the face of ill-behaved clients, crashy servers, and the way wireless breaks a lot of the assumptions that would make "one big TCP session" a good idea in the first place? If TCP+TLS handshakes are so expensive, wouldn't it be a better investment of everyone's resources to work on an L3 protocol for setting up a fast second session? Leave the multiplexing to packet people.
- martinflack 12y ago
  > I don't mind the binary protocol that much, but the apparent assumption that every endpoint is a fat stateful cache (push, multiplexing) is madness. A client can say it does not want push in the settings frame up front. And then it can make one request at a time, effectively avoiding multiplexing, although each frame in the response will have a 9-byte frame header (similar to the overhead in chunking today in 1.x). By saying it does not want push, it relieves itself of having an object cache. It will still be on the hook for having an HPACK table as state. (In practice this will be coded once in each language in a library and most developers will never think about it.) > Have they actually worked out how to implement a HTTP/2 front end cache in the face of ill-behaved clients, crashy servers, and the way wireless breaks a lot of the assumptions that would make "one big TCP session" a good idea in the first place? The community has indeed been working on a corpus of interoperability libraries, servers, clients, and proxies: https://github.com/http2/http2-spec/wiki/Implementations https://github.com/http2/http2-spec/wiki/Implementations > If TCP+TLS handshakes are so expensive, wouldn't it be a better investment of everyone's resources to work on an L3 protocol for setting up a fast second session? Leave the multiplexing to packet people. It's multiplexing with declared weighting and dependency trees. So for example, the client can tell the server that it wants files A, B, C, and D, but to have B, C, D is useless until it has A, and once A is finished, the relative importance of B is twice as much as C or D. That's much easier to do on one socket. Also one socket gets the header compression in HPACK to benefit from all the headers going through the same state engine. Giant sets of cookies (more common than we'd like to believe) are now more efficiently expressed. One socket also helps the server-side keep statistics and logs more organized as related requests are together. I understand your suggestion to do it on a lower level, and that's a fine idea, but I also understand why the working group did it on an HTTP layer, especially with SPDY as precedent. I work at Akamai, and I'm one of the open source library contributors (the Common Lisp one). These opinions are my own.

ubernostrum 12y ago

The correct answer is that HTTP/2 has to do this because Google is unable to show you a simple search box without making over a dozen HTTP requests. Their more involved properties require dozens to even hundreds of requests in order to perform complex tasks like showing a list of plain text posts. And, of course, they can't possibly impose any kind of discipline on the way they do things, so instead the entire internet has to change to accommodate them.

FooBarWidget 12y ago
It's so easy to blame everything on Google/Microsoft/$OTHER_BLACK_SHEEP being stupid. I don't know how many websites you've been to, but a large number of them perform hundreds of requests, not just Google. The modern web is full of images, CSS, webfonts, dynamically loaded Javascript, mashups and other things, each which require one or more HTTP requests. Having lots of requests has been the reality for a large part of the web for a number of years now.
zaphar 12y ago
My plaintext no animations statically generated site does 5 connections to load the content. http://jeremy.marzhillstudios.com http://jeremy.marzhillstudios.com Now I could optimize that even more by inlining everything with data-inline: but that would impact caching code and be strictly worse for the network. A property from google even websearch has fancy transitions and animations and dynamic content. And Google has every incentive to limit the number of connections to their page. When I worked there I worked on some of those technologies specifically to avoid too many connections. Blaming Google for not being disciplined enough disregards their economic incentives to be disciplined enough. They invested a lot of energy in this before SPDY came out. There comes a time where you just have to recognize that the protocol is fighting against you and either give up or evolve the protocol.
twistedpair 12y ago
Google created GWT which uses every trick under the sun to reduce connection counts. I use it on my sites and if you don't let your web property devolve into a bolt-on JS mire (as many large sites do, i.e. Borders recently made 248 requests to load), you can load the page/app in 4 requests. (1) index.html, (2) app.nocache.js (3) A56284CFC0D680C7DBA0F93CA9AE8F75.cache.js (cache fragment for given page/state) (4) XHR for page data/state to display Now, if you've got some CSS and minor images/fonts, these can be an your options request (5) resource bundle. On many Google properties, (2 and 5) are inlined into (1). The take away? These technologies and frameworks have been out there for a long time (8 years in the case of GWT), so you don't have to make hundreds of requests if you're disciplined. I can only assume Google has thrown in the towel trying to get script kiddies to ever be disciplined.
wpietri 12y ago
Exactly right. Humans only exist to serve their tools. No, wait a sec. That doesn't sound right. Could it be that our tools exist to serve humans? And that rather than putting effort into accommodating ourselves to the limitations of our current tools, we should instead put our effort into making tools that work the way we want? Nah, sounds crazy. If HTTP/1 was good enough for my grand-dad, it's good enough for me.

FooBarWidget 12y ago

Human-readable is only a matter of tooling. Why is HTTP human-readable? Because you have a lot of tools that understand ASCII. Without them, HTTP is just as unreadable to you as any other stream of bytes.

protonfish 12y ago
True, but it doesn't undermine my point. You can troubleshoot HTTP 1.1 with common, generic tools. How do you work with HTTP2? I have no idea.
- FooBarWidget 12y ago
  The tools don't exist right now, but they will become available. Existence of tooling follows demand. HTTP 2 has a large momentum so tooling will exist.
  - bigbango 12y ago
    I'm not willing trade away the human readability of HTTP/1 for a a performance gain that I really don't need. What about tools for reading corrupt binary HTTP/2 frames?
- wpietri 12y ago
  When I'm debugging HTTP, 98% of the time it's either with curl, Wireshark, or by dumping state in my own server-side code. Things like curl will work just the same. Wireshark has an HTTP/2 plugin; given their history, I'm sure it'll be excellent by the time there's much HTTP2 in the wild. And anybody writing server-side code is hacking together their own tools anyhow. The rare occasion where this will be a big difference for me is telnetting to port 80 and typing HTTP by hand. Honestly, I only do that out of habit; I can do the same things just as well with curl. But even when HTTP/2 ships, I'm sure it will be at least a decade before servers stop supporting HTTP/1.1. Probably longer. So I'm not expecting this to make a big difference to my debugging habits.

bcoates 12y ago

I don't mind the binary protocol that much, but the apparent assumption that every endpoint is a fat stateful cache (push, multiplexing) is madness. Have they actually worked out how to implement a HTTP/2 front end cache in the face of ill-behaved clients, crashy servers, and the way wireless breaks a lot of the assumptions that would make "one big TCP session" a good idea in the first place? If TCP+TLS handshakes are so expensive, wouldn't it be a better investment of everyone's resources to work on an L3 protocol for setting up a fast second session? Leave the multiplexing to packet people.

martinflack 12y ago
> I don't mind the binary protocol that much, but the apparent assumption that every endpoint is a fat stateful cache (push, multiplexing) is madness. A client can say it does not want push in the settings frame up front. And then it can make one request at a time, effectively avoiding multiplexing, although each frame in the response will have a 9-byte frame header (similar to the overhead in chunking today in 1.x). By saying it does not want push, it relieves itself of having an object cache. It will still be on the hook for having an HPACK table as state. (In practice this will be coded once in each language in a library and most developers will never think about it.) > Have they actually worked out how to implement a HTTP/2 front end cache in the face of ill-behaved clients, crashy servers, and the way wireless breaks a lot of the assumptions that would make "one big TCP session" a good idea in the first place? The community has indeed been working on a corpus of interoperability libraries, servers, clients, and proxies: https://github.com/http2/http2-spec/wiki/Implementations https://github.com/http2/http2-spec/wiki/Implementations > If TCP+TLS handshakes are so expensive, wouldn't it be a better investment of everyone's resources to work on an L3 protocol for setting up a fast second session? Leave the multiplexing to packet people. It's multiplexing with declared weighting and dependency trees. So for example, the client can tell the server that it wants files A, B, C, and D, but to have B, C, D is useless until it has A, and once A is finished, the relative importance of B is twice as much as C or D. That's much easier to do on one socket. Also one socket gets the header compression in HPACK to benefit from all the headers going through the same state engine. Giant sets of cookies (more common than we'd like to believe) are now more efficiently expressed. One socket also helps the server-side keep statistics and logs more organized as related requests are together. I understand your suggestion to do it on a lower level, and that's a fine idea, but I also understand why the working group did it on an HTTP layer, especially with SPDY as precedent. I work at Akamai, and I'm one of the open source library contributors (the Common Lisp one). These opinions are my own.