The fundamental identification of a TCP connection relies on the 4-tuple: (source IP, source port, destination IP, destination port). This means in theory, a client can reuse the same source port when connecting to different destination endpoints.

Through testing in Java (as shown below), we can observe that modern Linux systems do allow port reuse for outbound connections when connecting to different destinations:

// Java example demonstrating port reuse
Socket s1 = new Socket();
s1.setReuseAddress(true);
SocketAddress saremote = new InetSocketAddress("localhost",9999);
SocketAddress salocal = new InetSocketAddress("localhost",9990);
s1.bind(salocal);
s1.connect(saremote);

Socket s2 = new Socket();
s2.setReuseAddress(true);
SocketAddress saremote2 = new InetSocketAddress("localhost",9998);
SocketAddress salocal2 = new InetSocketAddress("localhost",9990);
s2.bind(salocal2);
s2.connect(saremote2);

While traditional Unix implementations maintained strict port uniqueness per host, modern Linux kernels (since 3.9) with SO_REUSEADDR allow this behavior. The netstat output confirms two active connections from port 9990 to different destinations:

tcp6       0      0 localhost:9990          localhost:9998          CONNECTED 
tcp6       0      0 localhost:9990          localhost:9999          CONNECTED

The 65,536 port limitation applies per destination endpoint, not globally. With multiple destinations, the practical connection limit becomes:

65,536 ports × number of possible destination endpoints (IP:port combinations)

1. Requires explicit SO_REUSEADDR socket option
2. Behavior varies across operating systems
3. Some middleboxes might incorrectly handle such connections
4. Load balancers and NAT devices may impose additional restrictions

This technique proves valuable in scenarios like:
- High-performance proxy servers
- Load testing tools
- Connection pooling implementations
- Services requiring massive outbound connections

While many developers believe source ports must be unique per host, the TCP protocol actually identifies connections through the complete 4-tuple: (source IP, source port, destination IP, destination port). This means you can reuse the same source port for multiple connections as long as the destination differs.

Here's a working example showing port reuse on Linux:

// First connection using port 9990
Socket s1 = new Socket();
s1.setReuseAddress(true);
s1.bind(new InetSocketAddress("localhost", 9990));
s1.connect(new InetSocketAddress("localhost", 9999));

// Second connection using the SAME source port
Socket s2 = new Socket();
s2.setReuseAddress(true);
s2.bind(new InetSocketAddress("localhost", 9990));
s2.connect(new InetSocketAddress("localhost", 9998));

Modern operating systems handle this scenario differently:

• Linux (kernel 3.9+): Fully supports port reuse with SO_REUSEADDR
• Windows: Behaves similarly but requires careful socket options
• BSD-based systems: Traditionally stricter, but recent versions support it

The theoretical limit isn't 65,536 connections per host, but rather per destination. With multiple destinations, you can exceed this:

// Potential to create thousands of connections from same source port
for (int i = 0; i < 100; i++) {
    Socket s = new Socket();
    s.setReuseAddress(true);
    s.bind(new InetSocketAddress(localIP, 9990));
    s.connect(new InetSocketAddress(remoteIPs[i], 80));
}

There are exceptions where uniqueness is enforced:

• When using the exact same 4-tuple (connection collision)
• During TIME_WAIT state without proper socket options
• With certain firewall configurations that track connections

For reliable port reuse:

// Recommended socket configuration
Socket s = new Socket();
s.setReuseAddress(true);
s.setSoLinger(true, 0);  // Avoid TIME_WAIT issues
s.setTcpNoDelay(true);

Remember that while possible, excessive port reuse may trigger security mechanisms in network equipment.