Does QUIC utilize file descriptiors and separate port like TCP?

Question

For my application I will need to have push notifications server. The amount of messages will be very low, just enough for one simple server instance, but it will need to be scalable and keep alive many connections from listeners. Traditional way is to use WebSockets, but there is a limitition of how many connections it can hold alive. Each TCP connection utilizes one file descriptor in Linux, as well as one socket. And ports/sockets are scarce, typically you can't use more than 20K-30K per IP, or at least that is what they say.

I found articles from people who claim they were able do reach 1.000.000 simultaneous connections, they did that by orchestrating several server instances in docker, each one keeping only 10.000 connections.

I did some googling and try to understand, if QUIC has same limitations as TCP in terms of resoruce usage? I can't find any definitive answer. Does it also uses separate port/socket for each new established connection and terefore limited to 20K - 30K simultaneous connections? Or since it is pure udp and implemented on sofware level, not on OS level, can it be free from that limitation?

Answer 1

Clients have a limit on the number of connections that they can open, limited primarily by the number of ephemeral ports (about 65k).

However, servers do not have this limit.

On servers, the limit is primarily due to number of file descriptors and memory.

It is not uncommon for a single large server to support many hundreds of thousands of simultaneous connections, even up to 1 million, so the 10k limit you mention is incorrect in general (perhaps it's not optimal, and it's better distributing the load over different servers, but nonetheless is possible).

QUIC, based on UDP, shares the same behavior as TCP: on the client a limit due to ephemeral ports, but on the server the limit is only due to number of file descriptors and memory.

For server push behavior, it is likely that many of the connections will be idle, and therefore consume very little resources (primarily memory), as these connections won't be very active at the same time.

To sum up, TCP and UDP (or QUIC) would have the same behavior and issues, so picking one over the other should be based on other factors.

The design of your server system should be based on real limits: file descriptors and memory.

Therefore, WebSocket is a viable solution. Solutions based on QUIC are likely more complicated due to (with respect to WebSocket) lack of libraries or products, and the inherent complexity of the protocol.

Answer 2

This question is probably too broad, however QUIC is relatively "new" in vendor support and adoption. For example, Microsoft has QUIC as an extension for SMB 3.1.1 in Windows Server 2025 (or Windows Server 2022 Azure Edition).

Additionally, basic performance thresholds and baselines can vary from terrible and not scalable, to 180,000 TLS connections per second or 60,000 TLS handshake connections per second per node when using a performant SSL stack. That makes scaling 1,000,000 connections across a smaller number of nodes practical and ordinary (or painful and impractical if using the wrong stack or there is a misconfiguration).

That said, it does not mean that QUIC is right for your usage. You need to decide that based on your own testing.

The State of SSL Stacks

Answer 3

Each TCP connection utilizes one file descriptor in Linux, as well as one socket. And ports/sockets are scarce, typically you can't use more than 20K-30K per IP, or at least that is what they say.

Yes. But file descriptors point to open file descriptions, which is only limited by the amount of resource there is in kernel. Also, you can spawn processes to manage clusters of clients if you run out of FDs in one process, and that's how some process managers work in Apache HTTPd.

Or since it is pure udp and implemented on sofware level, not on OS level, can it be free from that limitation?

I suppose yes. Many modern operating systems have configurable kernel limits that can be changed trans-reboot.

QUIC has its own mechanism of multiplexation that works independently of UDP ports, which right now aren't typically implemented in kernel, which means it likely won't occupy FDs or ports or creates sockets.

I haven't studied the efficiency improvements of QUIC over TCP, but I suppose there must be some. QUIC communication is protected cryptographically. Adding that it implements new multiplexation, my engineering opinion says it's likely more efficiently implemented in user-space overall, than the TCP in kernel.

Lastly. Like the previous SPDY (which became HTTP-2), you can use WebSocket under the new transport: RFC-9220.