|
To answer your specific question about why not in TCP, it's not deployable. Here's why: * In order to get multiplexing and other features introduced with HTTP/2, you need to change protocol framing. However, this means that the protocol is no longer backwards compatible. There are many ways to roll out non-backwards-compatible changes, but for TCP, they were deemed unacceptable. For example, you could negotiate the protocol change via a TCP extension. However, TCP extensions are known not to be widely deployable (https://www.imperialviolet.org/binary/ecntest.pdf) over the public internet. You could use a specific port, but that doesn't traverse enough middleboxes on the public internet (http://www.ietf.org/mail-archive/web/tls/current/msg05593.ht...). Yada yada. * More importantly, TCP is generally implemented in the OS. That means, updating a protocol requires OS updates. That means we need both server and client OS updates in order to speak the new protocol. If you look at the very sad numbers on Windows versions uptake, Android version uptake, etc, you'll understand why many people don't want to wait for all OSes to update in order to take advantage of new protocol features. To quote Roberto (http://www.ietf.org/mail-archive/web/tsvwg/current/msg12184....) in his response to IETF transport protocol folks asking why application protocol folks are hacking around the transport: """
I understand the points you make, and am sympathetic. I feel the same way when I see people abusing HTTP to provide async notifications, etc.
The fact is, however, if it isn't deployed, no matter how nice it would theoretically be when it is, it isn't useful and people WILL work around the problem.
That is true regardless of whether the problem is at the application layer (e.g. HTTP), or at the transport layer (e.g. TCP), or elsewhere.
The primary motivation is to get things working, and making things that lack redundancy, or are elegant comes in at a distant second. Deployed is the most important feature, thus things which quickly move protocols and protocol changes from theoretical to deployed are by far the most important things.
The longer this takes, the more likely that the work-around becomes standard practice, at which point we've all "lost" the game.
-=R
""" Basically, this is another instance of Linus's quote (https://lkml.org/lkml/2009/3/25/632): "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." Theoretically, it'd be far more elegant to fix this in the transport layer. But in practice, it doesn't work. Except, maybe if you implement on top of UDP (e.g. QUIC), since that would be in user-space and firewalls don't filter out UDP as much. For more extensive analysis of HTTP/2's deployability options, amongst other considerations, check out my post on HTTP/2 considerations: https://insouciant.org/tech/http-slash-2-considerations-and-.... |