35
5
There are 65536 ports for every system in the network, and every connection or Send/Receive will use one of those.
My question is: what happens if we have 65536+1 connections?!
I know that it does not happens in normal way, but I'm curious to know how Operating Systems handle it.
Omid Golparvar
Posted 2015-07-23T21:01:55.960
Reputation: 341
61
Please be aware that a system can handle more than 65536 concurrent connections, because they do not necessarily each use a separate port.
A TCP connection or UDP flow is defined by the 4-tuple:
(source IP address, source port, destination IP address, destination port)
So even if you have a web server machine with just a single IP address, and a single HTTP server software package listening only on port 80, it could theoretically handle 65536 connections per client IP address connecting to it. So 64Ki connections from client IP address 1, plus 64Ki connections from client IP address 2, etc.
So the protocols support, to a first approximation, 248 connections/flows to a single TCP or UDP port on a single IPv4 address. Consider both TCP and UDP together, and both IPv4's address space and IPv6's cosmically/comically large address space, and you can see that the the protocols themselves are not likely to ever be the source of the limit to the number of concurrent connections that a host can handle.
Similarly, there's nothing in the TCP or UDP protocols that keep a client machine from using a single source port on a single IP address to make multiple outgoing connections to various server addresses and ports. Sometimes a given OS's networking APIs might not make this easy, but it's important to remember that, say, the venerable old "[BSD] Sockets" API is just one API to TCP and UDP. TCP and UDP may have capabilities that are not exposed by the traditional Sockets API.
So the number of concurrent TCP connections or UDP flows a given host can handle is limited not so much by port numbers, but by system resources such as the RAM space and CPU time it takes to keep track of all those connections and service them all. Also an OS's implementation-specific details can impose artificial limits. For example, in the Unix "everything is a file" philosophy, there might be a file descriptor for every TCP connection or UDP flow. If your Unix kernel has a limit to the number of file descriptors it can keep track of, that file descriptor limit is an artificial limit on the number of concurrent TCP connections or UDP flows your kernel can handle.
Spiff
Posted 2015-07-23T21:01:55.960
Reputation: 84 656
2
May be worth linking to https://en.wikipedia.org/wiki/C10k_problem in this excellent answer.
– ChrisInEdmonton – 2015-07-23T23:41:07.2831I implemented a TCP server which could accommodate 65,534 connections from every possible IP address simultaneously. It doesn't do much--it simply echos incoming text with a few character substitutions--but it runs on a very small hardware platform. I don't think it's quite RFC-compliant, but it seems to work pretty well, despite neither knowing nor caring how many TCP connections are open on most of its ports. – supercat – 2015-07-24T15:36:29.210
2If you really need to connect more than 65536 connections between two machines, then you can set up the machines to use multiple IP address. Each IP address you add to the two machines increases the maximum number of connections quadratically (at least in theory, you'll more likely meet other problems first). – Lie Ryan – 2015-07-25T00:53:25.067
12The connection would be refused. But you'll realistically have problems long, long before 65535 open connections. – ChrisInEdmonton – 2015-07-23T21:12:54.760
1@ChrisInEdmonton No. If it's an outbound connection it will get a bind error as it can't allocate a local port. If it's an inbound connection the port limit does not apply. – user207421 – 2015-07-24T23:45:05.683
if the connection is inbout, you will receive a connection refused, if it is outbound, your socket call will error. I wont put this as an answer because i am not sure. – Jorge Aldo – 2015-07-26T03:00:58.600