Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



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


I 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).


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: