What happens if the senders on a TCP connection have the same port and IP?

Question

Computer networks

A TCP/IP socket is identified by five parameters {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL}
What happens if two different senders have the same IP and port?
IP - high probability (many sit behind NAT)
Port - is given randomly, and with more connections (for example, a popular web service), the probability of meeting a duplicate increases.

Answer 1

1) IP - high probability (many sit behind NAT)
If you mean that there are the same ip in different local networks, then there is no such probability. The connection contains a white ip.
If there are several clients from one white ip, then go to step 2.
2) the probability of meeting a duplicate is
not growing. Lots of ports of course, if all ports are exhausted there won't be duplicates, just the connection will be denied to the client (if you're talking about the server).
If the client is behind NAT - NAT maps internal ports to external ones. Accordingly, routers give the first free external port for a new connection, and two clients simply cannot have the same external port.

Answer 2

If all five values ​​match (src ip, src port, dst ip, dst port, protocol), then the packets related to two different connections will be mixed up, mixed up, and the devil himself will break his leg in what happens.
But!
The initiator of the connection (or NAT) Src port chooses not just random, but so that the five fields (src ip, src port, dst ip, dst port, protocol) in the connection table do not repeat.
That's all!
Indeed, both the connection initiator and NAT can reuse the pair (src ip, src port) for other connections. In NAT, this is called Endpoint Independent Mapping and serves to save the address pool. In addition, a number of services (the same ICQ) behave strangely, seeing several connections with different (src ip, src port), but under one account.
But, since at least one value from the triplet (dst ip, dst port, protocol) is unique, the packets related to different connections are not mixed.

Answer 3

If the same IP - then it's the same host - the network does not work on a different IP.
Theoretically, there can be a second connection from the same host and from the same port only in a situation where the client fell off for some reason (for example, the computer went into reboot unexpectedly) and, when reconnected, opened the same port, while the server had not yet managed to break past connection. In this case, the received SYN packet to establish a connection will cause an error on the server, something like out of sequence, and a new connection will not be established.
Usually the client will get a thump and try to connect again from a different port.
A hanging connection on the server will fall off on a timeout after some time.
The situation is quite specific, quite possible in life, but I don't think it's very common. And standard mechanisms will work it out quite normally.

Answer 4

Nothing.
Because this cannot be. Or more precisely, maybe - but within your individual server. Yes, RFC1918-based networks use concurrent addressing, but connections between them are made by NAT servers that have unique IPs. That's why they ended, because they had to be unique.

Answer 5

Packages will go to one person. The most common example is L2TP/IPsec VPN two clients behind one nat that does not change the port. When the second VPN tries to go up, it cannot go up, because the nat device in the NAT rules table has an IP / port entry already occupied, and it sends all return packets to the device that is registered in this entry. If the device thinks that the NAT entry is stale, then the first VPN will break and the second one will be built.
In a normal network with a normally configured nat, this situation should not occur, except for the situation in which one connection timed out broke the nat device, after which the next connection was assigned the same IP + port as the broken connection, and then the device flew belated package. In this case, it should be discarded, since its source does not match the entry in the nat table. That is, it is correct to assume that such a situation does not happen, but when debugging, you need to check whether it turns out that the nat device is trying to assign the same IP + port to two connections.