3 ms·
So I understand how multiplexing everything through a single TCP session is a bad idea. But what was the problem with using multiple TCP sessions like HTTP 1.1
by mgaunard 5y ago
So I understand how multiplexing everything through a single TCP session is a bad idea.
But what was the problem with using multiple TCP sessions like HTTP 1.1 does? Is it just the problem that there is a latency cost to establishing the connection (even though those sessions are reused later on)?
How about extending TCP to establish multiple sessions at once instead?
- vlmutolo 5y agoI think it's just that hundreds of TCP connections per user can really bog down the servers. Individual TCP connections are much more expensive than QUIC streams. QUIC also handles things like transparent IP-address switching (on either side of the connection).
- mgaunard 5y agoThere is no difference in server overhead, the amount of state to maintain and data received/sent is the same. Also nothing prevents the server from implementing TCP in userland, apart from maybe security concerns, but then if you want low latency you have to discard those anyway.
- deleted 5y ago[deleted]
- jayd16 5y agoExtending TCP is considered infeasible due to its pervasiveness and the calcification of it across the ecosystem. Implementing a new protocol is also considered infeasible for similar reasons. So they arrived at a new protocol over UDP to implement new features.