3 ms·

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

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

by bcoates 12y ago

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.