To fully answer this question, we need to think from five different angles:
• Protocol level: Can TCP and UDP share the same port number?
• Client TCP process: Can multiple processes share a TCP port?
• Client UDP process: Can multiple processes share a UDP port?
• Server TCP process: Can multiple processes listen to the same TCP port?
• Server UDP process: Can multiple processes listen to the same UDP port?
Let's analyze them one by one.
1. Protocol level: Can TCP and UDP share ports?
Answer: Yes! This is basic common sense in network design.
Let's first break down the essence of this problem:
TCP and UDP are two completely different "worlds". The operating system prepares 65536 ports (0-65535) for each of them. It's like two identical buildings, each with 65536 rooms, one for TCP and one for UDP.
The same port number is two completely independent resources on TCP and UDP! For example:
• TCP port 53 is one thing
• UDP port 53 is another thing
• They do not interfere with each other and can be used at the same time
(1) Classic example: DNS service
The best example is the DNS server, which uses both TCP and UDP port 53:
• UDP port 53: handles small queries (most daily DNS queries)
• TCP port 53: handles large queries and zone transfers
You can verify this yourself with the command netstat -tuln | grep :53:
When your computer queries a website domain name, it usually sends the request via UDP. If the data is too large (more than 512 bytes), it automatically switches to TCP. In either case, the server is ready to receive you on port 53!
(2) Official rules for port allocation
The international organization IANA (Internet Assigned Numbers Authority) is responsible for port allocation, and they usually do this:
• Assign a port number to the same service on both TCP and UDP
• But the service can choose to use only TCP, only UDP, or both
For example:
• Port 80 is assigned to the HTTP service
• But HTTP only uses TCP port 80
• UDP port 80 is actually idle and can be used by other programs
(3) Port usage in real life
In actual applications:
• Some services use the same TCP/UDP port (such as DNS uses port 53)
• Some services only use TCP (such as HTTP uses port 80)
• Some services only use UDP (such as SNTP uses port 123)
So, when someone asks whether TCP and UDP can use the same port number, the answer is simple and clear: Yes! They are two independent worlds and do not interfere with each other.
2. Client TCP process: Can multiple processes share a TCP port?
Answer: No! This is the basic rule of TCP communication.
A simple example: Your computer IP is 1.1.1.1, if the browser has already used port 8888, then:
• 1.1.1.1:8888 is exclusively used by the browser
• Other programs cannot use this port anymore and must use another port number
• Even if the browser closes the connection, the port will enter the TIME_WAIT state (lasting 1-4 minutes), during which it cannot be used by other programs
Why is it designed this way?
Because a TCP connection is uniquely identified by a four-tuple: [source IP, source port, destination IP, destination port]. If multiple programs share the source port, the system cannot distinguish who should return the data to.
But there is an exception: different IPs can use the same port.
If your computer has two IPs:
• Ordinary network card: 1.1.1.1
• Loopback address: 127.0.0.1
Then:
• Even if the browser occupies 1.1.1.1:8888
• Other programs can still use 127.0.0.1:8888
This is because the operating system manages TCP resources according to the [IP:port] combination, and the same port under different IPs is regarded as different resources.
The trap of TIME_WAIT state:
When the TCP connection is closed, the port is not released immediately, but enters the TIME_WAIT state (usually lasting 2MSL, about 1-4 minutes). During this time, the port is still occupied for the specific IP.
This is why sometimes you will encounter the error bind: Address already in use when restarting the service, even if you can't see any process using it.
3. Client UDP process: Can multiple processes share a UDP port?
Answer: On the surface, no, but it's interesting to look into it!
There are two completely different ways to use UDP ports, which leads to different port sharing rules:
(1) Unbound port (automatically allocated by the system)
If your program only sends UDP packets and does not call the bind() function:
In this case:
• When sending data, the port temporarily allocated by the system (such as 8888) is indeed exclusively occupied
• But when not sending data, other programs can use this port to send data
• Here comes the problem: if the server responds to port 8888, it may be intercepted by other programs occupying this port!
This is the true portrayal of the "connectionless" feature of UDP. The system does not record who is using this port or who sent what. It is only responsible for transmitting data packets.
This mode is suitable for one-way communication (such as log reporting) of "send and forget". We call this mode Unconnected UDP.
(2) Explicitly bind the port (using the bind function)
If your program explicitly binds the port:
In this case:
• Port 8888 is completely exclusive and cannot be used by other programs
• The port will not be released until the program ends and the socket is closed
Furthermore, you can also use connect() to specify the communication object (connect does not establish a real connection for UDP, but records the target address in the kernel):
Copy
// Specify the target server address
connect(sock, &server_addr, addr_len);
• 1.
• 2.
When both parties use the bound port to communicate, UDP communication becomes a fixed four-tuple like TCP:
• Client IP: 1.1.1.1
• Client port: 8888
• Server IP: 2.2.2.2
• Server port: 9999
This "bind and connect" method is commonly known as Connected UDP, and is the standard practice for most UDP applications that require two-way communication.
Remember: the choice of mode is not for style, but based on your application needs. Need two-way communication? Use Connected UDP. Just send data one-way? Unconnected UDP is enough.
(3) Code comparison: Decrypt the essential difference between the two modes
Unconnected UDP (unsafe but flexible):
// At the same time, process B may:
sockB = socket(AF_INET, SOCK_DGRAM, 0);
sendto(sockB, "World", 5, 0, &other_server, sizeof(other_server));
// If A no longer sends packets, the system may allocate 8888 to B
// Result: If the server replies to port 8888, it may be accidentally received by process B
Connected UDP (safe and controllable, but still not reliable):
Copy
// Process A
sockA = socket(AF_INET, SOCK_DGRAM, 0);
bind(sockA, &local, sizeof(local)); // Explicitly bind to port 8888
connect(sockA, &server, sizeof(server)); // Associate with a specific server
send(sockA, "Hello", 5, 0); // Simplified send
// Process B tries to use the same port
sockB = socket(AF_INET, SOCK_DGRAM, 0);
ret = bind(sockB, &local, sizeof(local)); // Try to bind to 8888
// Result: bind() fails and returns EADDRINUSE error
4. Server TCP process: Can multiple processes listen on the same TCP port?
Answer: By default, no, but SO_REUSEADDR provides a sophisticated exception mechanism.
When a TCP server starts, one of the most important steps is to bind and listen to the port. Normally, a TCP port can only be listened by one process, which ensures that the connection request has a clear handler. But in practical applications, this restriction is sometimes too rigid. That's why the operating system provides a more advanced port reuse mechanism.
(1) In-depth understanding of SO_REUSEADDR
SO_REUSEADDR is a socket option that modifies the default behavior of the operating system in handling address binding:
Why is it called "Reuse Address" instead of "Reuse Port"? This reveals its core mechanism: it allows different processes to listen to the same port, but requires binding to different IP addresses or binding with different degrees of precision. Simply put, one process can bind to a specific IP address, and the other process can bind to all IP addresses (wildcard address).
(2) Precise binding priority rules
Suppose a server has the following IP addresses:
• IP1 = 2.2.2.2 (network card 1)
• IP2 = 3.3.3.3 (network card 2)
• IP3 = 127.0.0.1 (loopback interface)
Now we create two processes with SO_REUSEADDR enabled:
• Process A binds *:80 (or 0.0.0.0:80, which means listening to port 80 on all interfaces)
• Process B binds 2.2.2.2:80 (explicitly specifies listening to port 80 on network card 1)
How does the system decide which process handles the connection? Operating systems follow a core principle: the most specific binding wins.
(3) Hidden mechanism of automatic failover
This design not only provides flexibility, but also has built-in failover capabilities. Assume that NIC 1 (2.2.2.2) fails:
Copy
The amazing thing is that the connection originally sent to 2.2.2.2:80 will automatically be transferred to process A for processing! This is because:
• After NIC 1 fails, the specific binding of process B becomes invalid
• But the operating system can still receive data packets destined for 2.2.2.2 through other NICs
• At this time, the wildcard-bound process A automatically "inherits" the processing rights
This mechanism is the cornerstone of a high-availability system, without the need for additional fault detection and switching logic.
(4) Other important functions of SO_REUSEADDR
In addition to the reuse of IP binding mentioned above, SO_REUSEADDR also provides another key function: allowing binding of addresses in TIME_WAIT state.
When a TCP server is restarted, the previous connection may be in TIME_WAIT state, making the port temporarily unreusable. Setting SO_REUSEADDR can immediately rebind these ports without waiting for TIME_WAIT to time out (usually 1-4 minutes).
5. Server UDP process: Can multiple processes listen to the same UDP port?
Answer: The basic rules are similar to TCP, but UDP provides a more powerful SO_REUSEPORT option.
The basic port sharing rules of the UDP server are similar to those of TCP (refer to the previous analysis of TCP), but UDP provides an additional "superpower" - SO_REUSEPORT.
(1) SO_REUSEPORT: UDP's secret weapon
SO_REUSEPORT goes one step further than SO_REUSEADDR. It allows:
• Multiple processes to bind to the exact same IP:port combination
• Each process can receive packets sent to that address
(2) Implementation principle: kernel load balancing mechanism
How does the operating system decide which process to send a packet to?
The modern Linux kernel uses a carefully designed hash algorithm to calculate a hash value based on the source address, source port, destination address, and destination port of the packet, and then selects a receiving process based on the hash result. This design ensures:
• Requests from the same client are always handled by the same process (session consistency)
• Requests from multiple clients are evenly distributed to different processes (load balancing)
This is particularly useful on multi-core systems - each CPU core runs a receiving process, overcoming the bottleneck of single-process receiving.
(3) Multicast and broadcast: perfect application scenarios
Another killer application of SO_REUSEPORT is UDP multicast and broadcast:
(4) Why is it called REUSEPORT instead of REUSEADDR?
This naming reflects its design focus:
• SO_REUSEADDR: mainly focuses on the reuse of the same port under different IPs
• SO_REUSEPORT: truly allows the exact same IP+port to be reused by multiple processes
Although SO_REUSEPORT can also be used for multicast addresses (such as 224.0.0.1), its main innovation is to allow true reuse of the same ordinary IP address and port.
Summary: See through the essence of the problem and easily deal with the interview
Okay, back to the original interview question: Can TCP and UDP use the same port?
The answer is: Yes! But this is just the tip of the iceberg.
Through our discussion, you now know:
• The port tables of TCP and UDP are completely independent (just like DNS uses port 53 of TCP and UDP at the same time)
• Once the client TCP port is occupied by one process, other processes can't use it (at least under the same IP)
• There are two ways to use the client UDP port. It is very casual when not bound, and very specific after binding.
• The server TCP process can play high-availability tricks through SO_REUSEADDR
• The server UDP process can use SO_REUSEPORT to achieve true port sharing and load balancing
Mastering these, you have surpassed most interviewers. Because you not only know "what", but also understand "why" and "how to use".
Next time you encounter this question in an interview, you can give a brief answer first, and then add: "This question is actually very profound. I can analyze it from several angles..." - the interviewer will definitely be impressed!
