Hacker News Reader

HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.

View on HN

Good point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar.

Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.

For clients these numbers don't matter as much, many thousands of packets per second doesn't really happen to them. For a server with a fast pipe it does happen. I hope one of the big providers will share numbers. I don't think many of them actually use user-space stacks with TCP, would be interesting if QUIC improves performance measurably.

The client doesn't have to use a "connected" UDP socket either. The client can bind to a random local port and use "sendto" to talk to many servers.

TCP is not only used for HTTP

Reply on news.ycombinator.com