I understand the basics of how ports work. However, what I don't get is how multiple clients can simultaneously connect to say port 80. I know each client has a unique (for their machine) port. Does the server reply back from an available port to the client, and simply state the reply came from 80? How does this work?
How do multiple clients connect simultaneously to one port, say 80, on a server? [duplicate]
Asked Answered
First off, a "port" is just a number. All a "connection to a port" really represents is a packet which has that number specified in its "destination port" header field.
Now, there are two answers to your question, one for stateful protocols and one for stateless protocols.
For a stateless protocol (ie UDP), there is no problem because "connections" don't exist - multiple people can send packets to the same port, and their packets will arrive in whatever sequence. Nobody is ever in the "connected" state.
For a stateful protocol (like TCP), a connection is identified by a 4-tuple consisting of source and destination ports and source and destination IP addresses. So, if two different machines connect to the same port on a third machine, there are two distinct connections because the source IPs differ. If the same machine (or two behind NAT or otherwise sharing the same IP address) connects twice to a single remote end, the connections are differentiated by source port (which is generally a random high-numbered port).
Simply, if I connect to the same web server twice from my client, the two connections will have different source ports from my perspective and destination ports from the web server's. So there is no ambiguity, even though both connections have the same source and destination IP addresses.
Ports are a way to multiplex IP addresses so that different applications can listen on the same IP address/protocol pair. Unless an application defines its own higher-level protocol, there is no way to multiplex a port. If two connections using the same protocol simultaneously have identical source and destination IPs and identical source and destination ports, they must be the same connection.
If you connect to the same web server twice from your client, the two connections will have the same destination port too. Only the source port is different. –
Clear
@notacat: "and destination ports on the remote end". From the perspective of the server, the connections have different source ports. Clarified. –
Licentiate
"If two connections using the same protocol have identical source and destination IPs and identical source and destination ports, they must be the same connection." - That should go in wikipedia! –
Evannia
@Licentiate - Now suppose in case of Corporate networks, normally the Ports are blocked. I have a P2P application which needs to communicate, so in that case to make it work else PORT FILTERING will stall it, i need to open some set of Ports. For Eg: I open Port - 6881 and now the communication starts occuring. But in the case when there are multiple clients using the same Port (6881), Then it works at a time for a Client , i.e. Client 1 and Client 2 under the same NAT(6881 opened) cannot communicate Internally as well as not even with CLient-X sitting under NAT-X[ Simultaneously ],. Why is so ? –
Albertina
@Albertina Off topic, but your P2P application seems to be a Bittorrent client :) Correct? –
Verbatim
What happens if two NAT'ed computers happened to pick the same source port by chance? –
Adenosine
@HelloWorld There are two "source port"s in play in a NAT scenario. The source port that the original computer set, and the external source port on the router. The latter is chosen by the router, not the hosts. Since, internally, each host has a different IP address, there is no collision. –
Licentiate
@Borealid, that is the case with Symmetric NATs but not with Port Restricted Cone NATs. Most home routers are Port Restricted Cone NATs. How do those resolve this? –
Adenosine
@HelloWorld I think you have misunderstood how DNAT works. The packet is rewritten at the router to have a different source port which is chosen by the router, and a different source IP as well. The number of simultaneous connections is limited by the number of available ports on the router's public interface(s). –
Licentiate
My confusion stemmed from not understanding the difference between a Port restricted cone NAT and a symmetric NAT, I thought that Port restricted NAT's reserve the source port, but that is not the case. Thanks for clarifying. –
Adenosine
If server has a tuple ip:port of source, how it is possible that I can open this same page on two different instances of browser? Does the browser bind to the particular port number and each instance has different port? –
Sudarium
"TCP and UDP extend IP addresses with a concept known as a port, a 16-bit number that supplements an IP address to specify a particular communication channel". That should make it short and clear. –
Billiton
After reading this I was wondering whether the reverse also works (Client reuse same port to different destinations), however netcat would not let me:
netcat: bind failed: Address already in use. This blog post led me to the solution: The kernel prevents reusing the same source port for reliability reasons. With the socket option SO_REUSEADDR it is possible though. With the option I was able to create two connections with same source IP/Port using socat: socat - TCP:127.0.0.1:9000,sourceport=8000,reuseaddr –
Fantastically Interesting answers. I have a new question. When there is a single UDP server (with a single listening port) and multiple UDP clients, the system will work well. How to handle the same scenario when we want a scalable multi-server system? –
Cardinalate
@Cardinalate one option is to just put a load balancer in front of the servers. It sends each incoming UDP packet to a server at random. Done. –
Licentiate
"If two concurrent connections using the same protocol have identical source and destination IPs and identical source and destination ports, they must be the same connection." I believe this statement is only true if it says concurrent. The ephemeral port chosen by the client may be reused later on for a subsequent connection with the same server identified by the same ip:port, thereby arriving at the same 4-tuple, yet these will be two different connections at two different points in time. I'm actually facing this issue as I'm trying to reconstruct TCP connections from a packet trace. –
Slurp
Wow, so there are only 65k * 65k possible connections on the same port for the same IP? –
Southbound
TCP port numbers are 16 bits each. So there can only be 65536 TCP connections at the same time with the same destinationIP-sourceIP-destinationPort combination. Giving your machine more IP addresses lets it handle more connections at once. What you said isn't quite right because fixing destinationPort and sourceIP, but allowing different destinationIPs, would give at least 2^16 * 2^32ish (for IPv4) + 2^16 * 2^128ish (for IPv6) simultaneous TCP connections. –
Licentiate
Important:
I'm sorry to say that the response from "Borealid" is imprecise and somewhat incorrect - firstly there is no relation to statefulness or statelessness to answer this question, and most importantly the definition of the tuple for a socket is incorrect.
First remember below two rules:
Primary key of a socket: A socket is identified by
{SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL}not by{SRC-IP, SRC-PORT, DEST-IP, DEST-PORT}- Protocol is an important part of a socket's definition.OS Process & Socket mapping: A process can be associated with (can open/can listen to) multiple sockets which might be obvious to many readers.
Example 1: Two clients connecting to same server port means: socket1 {SRC-A, 100, DEST-X,80, TCP} and socket2{SRC-B, 100, DEST-X,80, TCP}. This means host A connects to server X's port 80 and another host B also connects to the same server X to the same port 80. Now, how the server handles these two sockets depends on if the server is single-threaded or multiple-threaded (I'll explain this later). What is important is that one server can listen to multiple sockets simultaneously.
To answer the original question of the post:
Irrespective of stateful or stateless protocols, two clients can connect to the same server port because for each client we can assign a different socket (as the client IP will definitely differ). The same client can also have two sockets connecting to the same server port - since such sockets differ by SRC-PORT. With all fairness, "Borealid" essentially mentioned the same correct answer but the reference to state-less/full was kind of unnecessary/confusing.
To answer the second part of the question on how a server knows which socket to answer. First understand that for a single server process that is listening to the same port, there could be more than one socket (maybe from the same client or from different clients). Now as long as a server knows which request is associated with which socket, it can always respond to the appropriate client using the same socket. Thus a server never needs to open another port in its own node than the original one on which the client initially tried to connect. If any server allocates different server ports after a socket is bound, then in my opinion the server is wasting its resource and it must be needing the client to connect again to the new port assigned.
A bit more for completeness:
Example 2: It's a very interesting question: "can two different processes on a server listen to the same port". If you do not consider protocol as one of the parameters defining sockets then the answer is no. This is so because we can say that in such a case, a single client trying to connect to a server port will not have any mechanism to mention which of the two listening processes the client intends to connect to. This is the same theme asserted by rule (2). However, this is the WRONG answer because 'protocol' is also a part of the socket definition. Thus two processes in the same node can listen to the same port only if they are using different protocols. For example, two unrelated clients (say one is using TCP and another is using UDP) can connect and communicate to the same server node and to the same port but they must be served by two different server processes.
Server Types - single & multiple:
When a server processes listening to a port that means multiple sockets can simultaneously connect and communicate with the same server process. If a server uses only a single child process to serve all the sockets then the server is called single-process/threaded and if the server uses many sub-processes to serve each socket by one sub-process then the server is called a multi-process/threaded server. Note that irrespective of the server's type a server can/should always use the same initial socket to respond back (no need to allocate another server port).
Suggested Books and the rest of the two volumes if you can.
A Note on Parent/Child Process (in response to query/comment of 'Ioan Alexandru Cucu')
Wherever I mentioned any concept in relation to two processes say A and B, consider that they are not related by the parent-child relationship. OS's (especially UNIX) by design allows a child process to inherit all File-descriptors (FD) from parents. Thus all the sockets (in UNIX like OS are also part of FD) that process A listening to can be listened to by many more processes A1, A2, .. as long as they are related by parent-child relation to A. But an independent process B (i.e. having no parent-child relation to A) cannot listen to the same socket. In addition, also note that this rule of disallowing two independent processes to listen to the same socket lies on an OS (or its network libraries), and by far it's obeyed by most OS's. However, one can create own OS which can very well violate this restriction.
Great explanation. One more thing, using "SO_REUSEADDR" two processes can share same socket but that's multicast. If I have new ServerSocket(80) and I span new thread for each accept() then I am serving one client at a time (I can't send data packets simultaneously even with non blocking queue). So only real difference between single/multi thread web server is it that single process cannot serve second client until HTTP request for first is complete. –
Unicef
Just to clarify OP, I think it's port 80 of many different machines, probably a server cluster and/or multiple network cards. –
Unicef
You said that without procol as a defining parameter of a socket, client trying to connect to a server-port will not have any mechanism to mention which of the two listening process the client intends to. Now my question is, would'nt client port no. will help in distinguishing which socket to respond to, even if two different processes listen to same port, without having the need to see the protocol for it? –
Aventurine
Not sure if "Thus two processes in same node can listen to same port only if they are using different protocol" is actually true... You could have a process listen on a port and then fork itself. You would then end up with two processes listening on the same port. When a new connection arrives it's the OS' responsibility to decide which one of the two processes will handle the request. –
Lupine
@Ioan Alexandru Cucu - You're right and to accommodate concerns like yours, I've added a note to my response. Thanks for bringing this up. However, note that OS doesn't fork from a process that's already listening on a socket (at least I'm not aware of), it's rather the application program which might fork. In such cases, the program must be careful in listening and processing incoming data by parent and/or child process. –
Gennie
Now suppose in case of Corporate networks, normally the Ports are blocked. I have a P2P application which needs to communicate, so in that case to make it work else PORT FILTERING will stall it, i need to open some set of Ports. For Eg: I open Port - 6881 and now the communication starts occuring. But in the case when there are multiple clients using the same Port (6881), Then it works at a time for a Client , i.e. Client 1 and Client 2 under the same NAT(6881 opened) cannot communicate Internally as well as not even with CLient-X sitting under NAT-X[ Simultaneously ],. Why is so ? –
Albertina
@BuckCherry - Please advise if I understand correctly. BTW, great explanation! I am not using a web service. I am using Google Protocol Buffers to stream data directly to an HTTP socket/port on a remote machine. Our concern is what if two clients attempt to connect to the remote application simultaneously? Will the OS handle this? Or do I need to handle each connection on a different thread? Thank you for clearing up my confusion. –
Manichaeism
It would be worth adding that an independent process B still has a mechanism to take over the socket from process A, if processA transfers the socket's file descriptor to processB over a local unix domain socket as an ancillary message (aka control message) using
sendmsg() system call with SCM_RIGHTS. This is true not just for sockets, but any file-descriptor owned by a process can be transferred to another process even if it is not a child process. –
Augsburg @ Zohaib – Response to post @Aug-21, 2013. By design a socket is made protocol aware and thus there could be a scenario where multiple server sockets listening to same port. This means we need to establish a mechanism so that a single client socket can indicate which of the multiple server sockets listening on same port to be targeted. In this vein, as you can see there is no contention about client socket src-port; and the solution lies on the protocol of the client socket. A server socket out of all listening on a port is selected that matches the client-socket’s protocol. –
Gennie
@ Miss Lucy – I suppose your question should be a new post, however I would still make a quick response. I don’t know specifically about “Google Protocol Buffers”, but in general transport layer that comes as part of OS will allow opening and manage multiple simultaneous connections. However how a server will handle them is application layer’s responsibility. If server is not multi-threaded then it will unnecessarily will be blocked for previous connection to be served.Hope this helps! –
Gennie
vote for the unnecessary of state-less/full protocols. –
Loafer
A TCP socket can be identified by a 4-tuple, as the TCP part is already implied. You keep talking about the client 'binding' where you appear to mean 'connecting'. Two processes can listen to the same TCP port if they are both bound to different local IP addresses and neither of those is INADDR_ANY. –
Kimmie
@EJP: Thanks for pointing out the wrong usage of 'binding' - I'll edit to replace them with 'connect' soon. About the other two points - you're right and they are also in lined with the idea of socket tuple I've mentioned. If you fix protocol as UDP, TCP, etc, then the tuple is reduced to 4 items. –
Gennie
The statement "A listening to, can be listened by many more processes A1, A2, .. as long as they are related by parent-child relation to A." is no true for UNIX like systems, as @Augsburg have said, it's possible to share socket's file descriptors with local UNIX domain messages, thus sharing over unrelated process. –
Merilynmeringue
This one is much more correct than the one above. Hope when some one see this comment, it's already on the top of the answer list –
Echo
Can we clarify what is meant by a "protocol" here? "Thus two processes in the same node can listen to the same port only if they are using different protocols." I take it this is true for TCP vs UDP and not web sockets vs http, for instance. Is there an authoritative list of protocols that can be used by a socket?? –
Bitten
@KyleMcClellan - I could not spend a lot of time in generalizing this response, but I would say that the protocols are various combinations of Layer 3(network) and 4(transport) protocols, and they are not about the layers above such as session or application layers. This is because a network socket of this discussion operates at a transport layer with the knowledge of network layer. In general, any book/resource on socket implementation in UNIX or Linux should provide you ample details. You may like to start with the man-page of 'socket'. –
Gennie
Also, be aware of ICMP sockets under the purview of this discussion, where the protocol is purely in layer 3. –
Gennie
TCP / HTTP Listening On Ports: How Can Many Users Share the Same Port
So, what happens when a server listen for incoming connections on a TCP port? For example, let's say you have a web-server on port 80. Let's assume that your computer has the public IP address of 24.14.181.229 and the person that tries to connect to you has IP address 10.1.2.3. This person can connect to you by opening a TCP socket to 24.14.181.229:80. Simple enough.
Intuitively (and wrongly), most people assume that it looks something like this:
Local Computer | Remote Computer
--------------------------------
<local_ip>:80 | <foreign_ip>:80
^^ not actually what happens, but this is the conceptual model a lot of people have in mind.
This is intuitive, because from the standpoint of the client, he has an IP address, and connects to a server at IP:PORT. Since the client connects to port 80, then his port must be 80 too? This is a sensible thing to think, but actually not what happens. If that were to be correct, we could only serve one user per foreign IP address. Once a remote computer connects, then he would hog the port 80 to port 80 connection, and no one else could connect.
Three things must be understood:
1.) On a server, a process is listening on a port. Once it gets a connection, it hands it off to another thread. The communication never hogs the listening port.
2.) Connections are uniquely identified by the OS by the following 5-tuple: (local-IP, local-port, remote-IP, remote-port, protocol). If any element in the tuple is different, then this is a completely independent connection.
3.) When a client connects to a server, it picks a random, unused high-order source port. This way, a single client can have up to ~64k connections to the server for the same destination port.
So, this is really what gets created when a client connects to a server:
Local Computer | Remote Computer | Role
-----------------------------------------------------------
0.0.0.0:80 | <none> | LISTENING
127.0.0.1:80 | 10.1.2.3:<random_port> | ESTABLISHED
Looking at What Actually Happens
First, let's use netstat to see what is happening on this computer. We will use port 500 instead of 80 (because a whole bunch of stuff is happening on port 80 as it is a common port, but functionally it does not make a difference).
netstat -atnp | grep -i ":500 "
As expected, the output is blank. Now let's start a web server:
sudo python3 -m http.server 500
Now, here is the output of running netstat again:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
So now there is one process that is actively listening (State: LISTEN) on port 500. The local address is 0.0.0.0, which is code for "listening for all". An easy mistake to make is to listen on address 127.0.0.1, which will only accept connections from the current computer. So this is not a connection, this just means that a process requested to bind() to port IP, and that process is responsible for handling all connections to that port. This hints to the limitation that there can only be one process per computer listening on a port (there are ways to get around that using multiplexing, but this is a much more complicated topic). If a web-server is listening on port 80, it cannot share that port with other web-servers.
So now, let's connect a user to our machine:
quicknet -m tcp -t localhost:500 -p Test payload.
This is a simple script (https://github.com/grokit/dcore/tree/master/apps/quicknet) that opens a TCP socket, sends the payload ("Test payload." in this case), waits a few seconds and disconnects. Doing netstat again while this is happening displays the following:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.10:500 192.168.1.13:54240 ESTABLISHED -
If you connect with another client and do netstat again, you will see the following:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.10:500 192.168.1.13:26813 ESTABLISHED -
... that is, the client used another random port for the connection. So there is never confusion between the IP addresses.
this should the top answer –
Pokelogan
The page github.com/grokit/quickweb is giving a 404 –
Knossos
@AlexandreSantos github.com/grokit/dcore/tree/master/apps/quicknet –
Seating
127.0.0.1 is an address, not a port. –
Kimmie
@Seating My server is creating only one process, no threads to handle multiple connections. Why is that ? –
Robotize
telnet localhost 500 is a simpler way to create a connection that will stay. –
Thorlay You say '5-tuple: (local-IP, local-port, remote-IP, remote-port, protocol)', so, does it possible to start two servers with different protocols on 1 port? for example one TCP and one HTTP? Why, if not? –
Clywd
@Seating could you share your knowledge on this #49730136 –
Carchemish
one can just use
nc 0.0.0.0 500 to connect to the server, and if you use python 2, ` python -m SimpleHTTPServer 500` start http server. –
Cave The line
127.0.0.1:80 | 10.1.2.3:<random_port> | ESTABLISHED is impossible. –
Kimmie Can multiple clients talk to a process on the server simultaneously? For example, 100 browsers try to open google.com at roughly the same time, to simplify things lets say all 100 HTTP requests reach the same server. Then this server responds to 100 requests one at a time, correct? –
Respirator
Normally, for every connecting client the server forks a child process that communicates with the client (TCP). The parent server hands off to the child process an established socket that communicates back to the client.
When you send the data to a socket from your child server, the TCP stack in the OS creates a packet going back to the client and sets the "from port" to 80.
So if a server had say 1,000 simultaneous connections (I know that is high), it would have to contend with 1,000 threads!? That seems out of control. Or are fibers used (thread barreling). –
Spinnaker
@IanC Not all the web-servers are multi-thread (Apache with worker module) or multi-process (Apache with pre-fork module). Look for Lighty (formally Lighttpd) and NginX for some very capable non-threaded web servers. Even in a multi-thread environment, you don't have to handle all the incoming connections at once. You may employ a queue with a preset maximum size. –
Evertor
So since the packet sent back to the client is said to be from port 80, does that mean when the data goes thorugh the main server, so it can be directed to the proper child-process again? –
Foxhole
So since the header in the packet that is returned to the client is said to be from port 80, doesn't that mean the client program will continually se –
Foxhole
@m1tk4, so the response actually comes from port 80. ? More so as client use HTTP/1.1 pipe-lining, i.e multiple "GET"'s over same socket. So even though HTTP is stateless, client-server socket / TCP is not, response must come from same child process. –
Unicef
The days of forking a new process were over in the 1990s. Nowadays it is a thread, a completion port, or just another thing for a non-blocking
select() loop to handle. –
Kimmie Multiple clients can connect to the same port (say 80) on the server because on the server side, after creating a socket and binding (setting local IP and port) listen is called on the socket which tells the OS to accept incoming connections.
When a client tries to connect to server on port 80, the accept call is invoked on the server socket. This creates a new socket for the client trying to connect and similarly new sockets will be created for subsequent clients using same port 80.
Words in italics are system calls.
Ref
© 2022 - 2024 — McMap. All rights reserved.