I made a tcp/ip echo server by using kqueue on a unix(OSX) machine.It desinged to open 100 tcp/ip ports and accept 4000 clients per port.I made about 230,000 connections by using 15 another machines. ( 4000 conn per single process, and 4 process per box)
It seems that the server could accept more than that but the problem was the client side.There is a limitation to make much connections. Such as Windows XP - 3000, Windows7 & Unix - 16384 ..
Is the limitation right ? did I wrong ? I want to make as much connections as I can on a single client, such as 500,000 / Machine.
How could I overcome ?
You can configure multiple IPv4 address on the client machine. Process that runs on client should receive source IP address as parameter, and bind connect socket to it. So with 10 IP addresses you can easily reach 400000 connections.
I want to make as much connections as I can on a single client, such as 500,000 / Machine.
You can't. A TCP connection is identified by the tuple {protocol, source address, source port, target address, target port}. Four of these five elements are fixed. The remaining element, source port, can only have 65535 distinct values at the most, as a port number has 16 bits and cannot be zero.
So your expectation of 500,000 connnections to the same client is over-optimistic by a factor of about 10.
Related
I came to my knowledge that if a machine makes 2 requests to the same destination IP and the same destination port, the source ports have to be different. But if that is the case, there must be a maximum number of active connections a client can have to a server. Is there a limit on how many such connections there can be?
A port is 16 bits, so the absolute limit would be 216.
Of course, port 0 is not really ever used and ports 1 to 1023 are clearly reserved for servers. Plus, in most cases, you have a limited range of ports you can use to connect as a client. These are called ephemeral ports and are between 49152 and 65535.
The number 49152 is 0xC000. So you get the top quarter of the ports available to clients or 16384 ports (214). That's your limit as a client.
Note that memory is also required. More or less depending on your application but also the kernel needs enough memory to allocate so many ports. So you are more likely to run out of memory before you can allocate that many ports (unless, like me, you have a computer with 512Mb of RAM or more... then you'll have a hard time to stress the memory allocation in most cases).
In practical use, I've never run out of client ports. The main issue I run into is multiple applications trying to listen on the same port (i.e. two servers trying to listen on port 80, for example).
I was wondering, admitting an address system translation which uses public address in order to offer an access to Internet to 15 computers, how could I find the maximum of simultaneous TCP connections supportable by this system please?
I am beginner with network and not able to find an answer to that, although I was thinking, a TCP connection can handle 65 535 simultaneous connections, since there is 15 computers then I get : 65 535/15 = 4369, is that correct?
Thanks a lot in advance
The things you called "address system translation" always named as NAT(Netowrk Address Translation) devices such as routers.
A network connection is checked by the tuple of five elements: Source IP, Source Port, Destination IP, Destination Port, and Protocol. So the limitation of connection numbers is decided by these elements.
You said 65536 connetions, this is the limitation of ports.
For a Circumstance like you said, 1 router with 1 external IP, for every one of the 15 PC inside of the NAT LAN, the circumstances is like:
Source IP is the router's external IP
Source Port has at max 65536 choices
Destination IP is limited by the IPV4 or IPV6 address length
Destination Port is limited by 65536
Protocol can choose TCP/UDP
So you can see, in theory we can have millions of connections for every PC. But the thing is that we need to consider the limitation of hardware, OS and virtual memory, so we can't have so much.
I have recently discovered ip masquerading.
My question is simple: if routers actually map hosts ports to their own ports, what if they run out of ports ? Suppose the network has got 4 hosts on IPs 192.168.0.{2,3,4,5}, each using 20000 ports, how does a router map 80000 ports to his 65000.
Although I couldn't find any information on this, I am guessing masquerading occurs on traffic only, thus there shouldn't be 20k ports to map per host, but why not ? I can't figure it out.
It depends what you mean by 'using 20000 ports'. If you had an application which was listening on 20000 ports on each of 192.168.0.{2,3,4,5} (perhaps allocating the external mapping dynamically using UPnP, it would exhaust the available ports eventually. It's possible that a quota would prevent anywhere near 65000 being allocated. See https://www.rfc-editor.org/rfc/rfc6887#section-17.2
However, you are probably talking about connections out from 192.168.0.{2,3,4,5} to the wider Internet. In this case, no ~65000 limit would apply because a socket is a defined based on the {source ip, source port, dest ip and dest port}. N.B. It's possible to open more than ~65000 sockets from a single server (assuming the OS is so configured), and therefore it's also possible, in theory, to do so with IP masquerading.
A more comprehensive answer is here:
https://serverfault.com/questions/541699/nat-gateway-maximum-connection-limit
Assuming infinite performance from hardware, can a Linux box support >65536 open TCP connections?
I understand that the number of ephemeral ports (<65536) limits the number of connections from one local IP to one port on one remote IP.
The tuple (local ip, local port, remote ip, remote port) is what uniquely defines a TCP connection; does this imply that more than 65K connections can be supported if more than one of these parameters are free. e.g. connections to a single port number on multiple remote hosts from multiple local IPs.
Is there another 16 bit limit in the system? Number of file descriptors perhaps?
A single listening port can accept more than one connection simultaneously.
There is a '64K' limit that is often cited, but that is per client per server port, and needs clarifying.
Each TCP/IP packet has basically four fields for addressing. These are:
source_ip source_port destination_ip destination_port
<----- client ------> <--------- server ------------>
Inside the TCP stack, these four fields are used as a compound key to match up packets to connections (e.g. file descriptors).
If a client has many connections to the same port on the same destination, then three of those fields will be the same - only source_port varies to differentiate the different connections. Ports are 16-bit numbers, therefore the maximum number of connections any given client can have to any given host port is 64K.
However, multiple clients can each have up to 64K connections to some server's port, and if the server has multiple ports or either is multi-homed then you can multiply that further.
So the real limit is file descriptors. Each individual socket connection is given a file descriptor, so the limit is really the number of file descriptors that the system has been configured to allow and resources to handle. The maximum limit is typically up over 300K, but is configurable e.g. with sysctl.
The realistic limits being boasted about for normal boxes are around 80K for example single threaded Jabber messaging servers.
If you are thinking of running a server and trying to decide how many connections can be served from one machine, you may want to read about the C10k problem and the potential problems involved in serving lots of clients simultaneously.
If you used a raw socket (SOCK_RAW) and re-implemented TCP in userland, I think the answer is limited in this case only by the number of (local address, source port, destination address, destination port) tuples (~2^64 per local address).
It would of course take a lot of memory to keep the state of all those connections, and I think you would have to set up some iptables rules to keep the kernel TCP stack from getting upset &/or responding on your behalf.
Suppose two web browsers are running on the same computer and are accessing the same website (in other words, accessing the same IP address on the same port).
How does the operating system recognize which packets are from/for which program?
Does each program have a unique id field in the TCP header? If so, what is the field called?
The two programs are not actually accessing the "same port." For purposes of TCP, a connection is defined by the tuple (src_ip,src_port,dst_ip,dst_port).
The source port is usually ephemeral, which means it is randomly assigned by the OS. In other words:
Program A will have:
(my_ip, 10000, your_ip, 80)
Program B will have:
(my_ip, 10001, your_ip, 80)
Thus, the OS can see those are different "connections" and can push the packets to the correct socket objects.
the source port number will be different even if the destination port number is the same. the kernel will associate the source port number with the process.
When the client opens a connection to destination port 80, it uses an arbitrary unused source port on the local machine, say 17824. The web server then responds to that client by sending packets to destination port 17824.
A second client will use a second unused port number, say 17825, and so the two sockets' packets will not be mixed up since they'll use different port numbers on the client machine.
Christopher's answer is partially correct.
Programs A and B actually have a handle to a socket descriptor stored in the underlying OS's socket implementation. Packets are delivered to this underlying socket, and then any process which has a handle to that socket resource can read or write it.
For example, say you are writing a simple server on a Unix like OS such as Linux or Mac OSX.
Your server accepts a connection, at which point a connection consisting of
( src IP, src Port, dest IP, dest Port )
comes in to existence in the underlying OS socket layer. You then fork a process to handle the connection - at this point you now have two processes with handles to the socket both of which can read / write it.
Typically ( always ) the original server will close it's handle to the socket and let the forked process handle it. There are many reasons for this, but the one that is not always obvious to people is that when the child process finishes it's work and closes the socket the socket will stay open and connected if the parent process still has an open handle to it.
By port number.
IP address is used to identify computer, and port is used to identify process(application) within the computer. When a port is used by one process, other processes can't use it any more. So if any packet is sent to that port, only the owner of that port can handle that packet.
Connections are identified by a pair of endpoints.
– Endpoint means (ip, port)
Os assigns random number as src port number so, when packet travels to the receiving side, it is treated as different process's msg, since src port numbers are different.