3 ms·
While trimming fat from excessively complex web pages would be nice, HTTP over TLS over TCP has some very clear fundamental inefficiencies that need to be addre
by simiones 3y ago
While trimming fat from excessively complex web pages would be nice, HTTP over TLS over TCP has some very clear fundamental inefficiencies that need to be addressed sooner or later.
The biggest one is that there is just no reason to negotiate multiple encrypted sessions between the same client and server just to achieve multiple parallel reliable streams of data. But since TLS is running over TCP, and a TCP connection has a single stream of data (per direction) you are forced to negotiate multiple TLS sessions if you want multiple parallel streams, which needlessly uses server resources and needlessly uses network resources.
Additionally, because TCP and TLS are separate protocols, TCP+TLS connection negotiation is needlessly chatty: the TLS negotiation packets could very well serve as SYN/SYN-ACK/ACK on their own, but the design of TCP stacks prevents this.
I believe it would be theoretically possible to simply set the SYN flags on the Client Hello and Server Hello TLS packets to achieve the TCP handshake at the same time as the TLS handshake, but I don't think any common TCP/IP stack implementation would actually allow that (you could probably do it with TCP Fast Open for the Client Hello, but I don't think there is any way to send the Server Hello payload in a a SYN-ACK packet with the default stacks on Linux, Windows, or any of the BSDs).
And, since you'd still need to do this multiple times in order to have multiple independent data streams, it's probably not worth the change compared to solving both problems in a new transport protocol (the way QUIC has).
- xorcist 3y agoThe right way would probably be to implement a real TCP replacement. Look at SCTP for inspiration. There are certainly things that could be improved and would be even nore useful than multiplexing, such as working congestion control and multipath. I understand that HTTP is the new TCP, but I don't have to like it.
- taway1237 3y agoisn't QUIC the new TCP in this case?
- NoGravitas 3y agoSort of? Except being implemented on top of IP, like TCP and UDP are, it's implemented on top of UDP, mainly so that existing middleboxes don't have to be updated. Either a TCP replacement or a major version update to TCP would be the Right Thing, but we can't have good things.
- nightpool 3y agoThat's.... exactly what QUIC is? I don't understand your comment
- xorcist 3y agoQUIC runs over UDP. In this sense it is more like a tunneling protocol than a layer 4 one.
- simiones 3y agoIs there anything in the design of UDP that constrains what QUIC would have wanted to do? If it used a different ID in the IP packet, would it really change anything about the UDP headers? I would say UDP is such a simplistic protocol you can actually see it more as a protocol-building framework than a layer in-and-of itself.
- xorcist 3y agoIf everything is just datagrams, what good are datagrams? Are we forever bound to use deep inspection just to keep acceptable service in our networks? Having a separate layer for data connections was a good idea for many reasons which have been clear for over four decades.
- simiones 3y agoI'm not sure what you mean. What does UDP have to do with acceptable service? If you want to prioritize certain kinds of traffic, you either to do deep packet inspection, or you trust IP-level QOS info (which you probably shouldn't). There is no other way. No one sane prioritizes UDP in general, you prioritize things like VoIP, for which you anyway need to do DPI. And separating data connections from encryption has in fact proven to be a a bad idea over those 40 years.
- nightpool 3y agoThe difference seems pretty academic. Practicality >> purity, especially when trying to get new networking protocols deployed to ~4e9 people