5 ms·
most tcp work is done in the network hardware these days isnt it? how can a userpace protocol possibly hope to be faster than that?
by DarkmSparks 3y ago
most tcp work is done in the network hardware these days isnt it?
how can a userpace protocol possibly hope to be faster than that?
- lxgr 3y ago"Fast" here means high throughput and/or low latency, not low on compute resources. If you're compute-bound (or using a userspace transport layer would make you compute-bound), this might not be a great choice, but many network-facing services aren't.
- wmf 3y agoNo, TCP is not in hardware and Linux (the most popular server OS) has a policy to never allow full TCP offload.
- DarkmSparks 3y agoNot convinced, but sounds like you know what you are talking about nginx has quic support now https://nginx.org/en/docs/quic.html https://nginx.org/en/docs/quic.html Do you fancy knocking up some benchmarks of typical server loads on accross some 100mbs/1gbs/10gbs connections and chrome headless?
- wmf 3y agoAs I said in another comment, I still expect TCP to use fewer cycles than QUIC due to kernel optimizations and partial NIC offload. IIRC people have done benchmarks showing this. Saturating 10G or even 100G with either protocol should be easy enough these days but if you want to do 400G or more from a single server then it matters.