Socket programming - why is the web server still using listening port 80 to communicate with the client even after they have accepted the connection?
Usually the web server listens for any incoming connection on port 80. So my question is that it shouldn't be that in the general concept of socket programming this port 80 is meant to listen for an incoming connection. But after the server accepts the connection, it will use a different port, such as port 12345, to communicate with the client. But, when I look at wireshark, the server always uses port 80 during communication. I'm confused here.
And what if https://www.facebook.com:443 , a hundred thousand connections to it per second. Is it possible for one port to handle such a large amount of traffic?
source to share
A specific socket is uniquely identified by a 5-tuple (i.e. a list of 5 specific properties). These properties are:
- Source IP address
- Destination IP
- Source port number
- Destination port number
- Transport protocol (usually TCP or UDP)
These parameters must be unique for open sockets at the same time. Where you are probably confused is what happens on the client side and what happens on the server side in TCP. Regardless of the application protocol in question (HTTP, FTP, SMTP, whatever) TCP behaves the same.
When you open a socket on the client side, it will choose a random high numbered port for a new outgoing connection. This is necessary, otherwise you were unable to open two separate sockets on the same machine on the same server. Since it is perfectly reasonable to do this (and this is very common in the case of web servers, such as opening stackoverflow.com in two separate tabs), and the 5-tuple for each socket must be unique, a random large number of port is used as the source port. However, each of these sockets will connect to port 80 on the stackoverflow.com web server.
On the server side, stackoverflow.com can already distinguish these two different sockets from your client because they already have different port numbers on the client side. When it sees an incoming request packet in your browser, it knows which of the sockets it is open with should respond to you due to a different source port number. Likewise, when it wants to send you a reply packet, it can send it to the desired endpoint on your side by setting the destination port number to the client side port number it received the request for.
The bottom line is that for each client connection there is no need to have a separate port number on the server side, since the server can already uniquely identify each client connection by its client IP address and client side number. This is how TCP (and UDP) sockets work independently of the application layer protocol.
source to share
it shouldn't be that in the general concept of socket programming this port 80 is meant to listen for an incoming connection. But after the server accepts the connection, it will use a different port, such as port 12345, to communicate with the client.
Not.
But, when I look at wireshark, the server always uses port 80 during communication.
Yes.
I am confused here.
Just because your "general concept" is wrong. The received socket is using the same local port as the listening socket.
And what if https://www.facebook.com:443 , a hundred thousand connections to it per second. Is it possible for one port to handle such a large amount of traffic?
The port is just a number. It is not a physical thing. It doesn't process anything. TCP identifies connections based on the tuple {source IP, source port, target IP, target port}. No problem if the whole set is unique.
source to share
Not all servers are web servers listening on port 80, and they also do not support all long-term connection servers. Web servers, in particular, are stateless.
Your suggestion to open a new port for further communication is exactly what happens when using FTP , but as you have seen, it is not necessary.
Ports are not a physical concept, they exist in a standardized form that allows multiple servers to be reached on the same node without specialized multiplexing software. Such software still exists, but for completely different reasons (see: sshttp ). What you see as a response from the server on port 80, the server sees as a response to you on the non-random port to which the OS assigns your connection.
source to share
When the server listening socket receives a TCP request for the first time, a function such as Socket java.net.ServerSocket.accept()
will return a new communication port number which has the same number as the port from java.net.ServerSocket.ServerSocket(int port)
, Here are the screenshots.
source to share