3 ms·
It does miss the point of a stateless, text-based protocol but only because that's core to the problems currently experienced in HTTP/1.1 that are identified ne
by X-Cubed 13y ago
It does miss the point of a stateless, text-based protocol but only because that's core to the problems currently experienced in HTTP/1.1 that are identified near the start of the presentation.
The nice thing about this approach is that it is entirely contained such that the web application in the browser doesn't know (or even need to know) the difference, in the same way that current web applications don't need to worry about whether the request data was compressed or not.
- comex 13y agoCertainly, there are plenty of things in HTTP 2.0 that make sense to be there, such as server push, specialized header compression, etc. However, some things, such as avoiding making multiple connections due to congestion and due to slow-start being slow, flow control, and arguably encryption, seem like they would be better addressed in TCP. And in fact, Google is trying to do that with QUIC. The problem is that if (when) those things get standardized in HTTP/2.0, they need to be supported forever, even if an improved transport layer protocol makes them obsolete in relatively short order.
- jimktrains2 13y agoYour post made me reflect a bit and I agree with you whole-heartedly. I wouldn't have such a visceral dislike of HTTP/2.0 if it didn't have the TCP-like features in it.
- FooBarWidget 13y agoYou can't address things in TCP. There is so much network infrastructure deployed that trying to push any non-backward compatible change in TCP is futile. Google did the right thing by addressing the problems in layer 5.
- comex 13y agoThen just tunnel on top of UDP, like QUIC currently does. Doesn't mean it has to be specific to one application.