Why is a TCP Socket identified by a 4 tuple?

Question

Newbie to networking here. I'm reading the Computer Networking (3rd edition) book, and in section 3.2 they are discussing multiplexing / demultiplexing for both UDP and TCP.

In the UDP protocol, a socket is uniquely identified by the source IP and the source port.

In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information for the receiving host to correctly demultiplex the segment and send it to the correct process?

The only reason I can think of why this is necessary is if clients always send the TCP segment to the same port as the connection-request segment. For example, my browser always sends data to port 80 of the server even though the server has established a TCP socket specifically for that session on a different port. In that case, TCP has to use the source IP and source port information to demultiplex to the correct socket. It can't rely solely on the source IP information, because a single host can establish multiple sessions, but each session has to be on a different port.

The reason why UDP does not have this problem is because the destination IP / port combo identifies the socket to which the process that will handle the request is attached, since in UDP there is no "spawning" of multiple new sockets for requests.

Is this correct or have I reached the wrong conclusion?

Answer 1

Unfortunately things get confusing because there are two different definitions of socket out there. The TCP rfc uses the term socket to refer to a combination of address and port, but berkerly sockets and it's derivatives (the API used by pretty much every practical implementation of IP in use today) uses the term socket to refer to a type of operating system communications object.

Why does the TCP protocol require two extra pieces of information for the receiving host to correctly demultiplex the segment and send it to the correct process?

It's not just a matter of the correct process but the correct communications object.

The only reason I can think of why this is necessary is if clients always send the TCP segment to the same port as the connection-request segment. For example, my browser always sends data to port 80

They do.

even though the server has established a TCP socket specifically for that session on a different port.

This seems to be a common misconception, probablly caused by the different definitions of socket. Accepting a connection creates a new communications object (socket in the Berkerly sockets sense of the term) but does not allocation a new ip/port combination (socket in the TCP RFC sense of the term) on the server.

The reason why UDP does not have this problem is because the destination IP / port combo identifies the socket to which the process that will handle the request is attached, since in UDP there is no "spawning" of multiple new sockets for requests.

Correct (assuming your paragraph is using "socket" in the berkerly sockets sense).

Answer 2

In the UDP protocol, a socket is uniquely identified by the source IP and the source port.

In the TCP protocol, the socket is uniquely identified by the source IP, source port, destination IP, and destination port. Why does the TCP protocol require two extra pieces of information

NB for TCP terminology, the socket is the address-port pair; a pair of sockets defines the connection. (Per RFC 793 p5)

I'm afraid you're mistaken about UDP, which although it doesn't really have "sockets" -- even if the Berkeley Sockets library calls them that, and it's a reasonable thing to call an address-port pair -- multiplexes in essentially the identical way to TCP.

A typical situation where you can see this is the case is simultaneous multiple DNS resolutions from one host to the same DNS server, where clearly only the source port number is necessarily different. You can see this is exactly the same situation as multiple simultaneous TCP connections from one client to a single web server.

UDP has connectionless datagrams. Host A sends the datagram out of an address-port pair, directed at an address-port pair at B, which typically, but not always, replies in the mirror way. Speaking more loosely of the "communication", it operates over exactly the same 4-tuple as a TCP connection.

You will sometimes see reference to a 5-tuple of (procotol, source address, source port, destination address, destination port), where protocol would be 17 for UDP, 6 for TCP etc. This is what most firewalls, routers etc use for NAT and similar operations to identify this communicating pair.

even though the server has established a TCP socket specifically for that session on a different port

I'm afraid you're also mistaken about TCP, possibly because of the conflict of terminology between the definition of the TCP protocol (RFC 793) and its most common practical implementation, the Berkeley Sockets Library, as used in Unix and everything descended from it.

If you focus on the protocol it's much clearer: there is no "different port". The web server is only listening on, for example, 1.1.1.1 port 80. The client only sends from, for illustration 2.2.2.2 port 56789. Every single packet will be 1.1.1.1:80 to 2.2.2.2:56789 or vice versa; easily verified by looking at packets with tcpdump/wireshark/etc.

(To very briefly digress to the Berkeley implementation, a TCP connection is represented by an integer typically but confusingly called sockfd; a TCP socket is represented by a struct sockaddr. The accept() system call very confusingly speaks of making a "new connected socket", by which it means new connection structure in the connected state. The tuple of this resulting thing would be in our example (1.1.1.1, 80, 2.2.2.2, 56789). Regarding UDP, the library allows you to consider UDP as connected, which is a convenient if completely wrong way of describing UDP datagram exchange between two processes, and just means the structure remembers the far address-port pair, which in programming terms makes the UDP "connection" look just like a TCP one. Remember the Berkeley library is not just for IP, and has generalisations of several different underlying networking systems. If you want to follow up these network programming terms I suggest Stack Overflow, which has many very competent network programmers.)

Answer 3

If the book you're reading is "Computer Networking- A Top-Down Approach" by Jim Kurose, you and I are reading the same book. :-) FYI, the book actually states the two-tuple which identifies a UDP socket is based on the destination (not source) IP and port. At least, that's what the 7th edition states.

To answer your question, TCP is connection-oriented, while UDP is connection-less. Therefore, when a TCP request is established between a host and server, each side of that connection will want to be certain that subsequent requests will use the same connection (otherwise, what's the point of using a connection-oriented protocol like TCP?). And since two data segments with the same destination IP and port but different source IPs and ports will use two separate sockets on the server-side, the only way to ensure that subsequent requests use the same socket as the original request is to use both the source and destination IP/port when matching data segments with their correct sockets.

By contrast, UDP is not connection-oriented. You don't have to worry about using the same socket as previous requests, and there's no need to include the source IP/port when identifying which UDP socket to route the segment to. Hence, a two-tuple is sufficient.

Answer 4

In the UDP protocol, a socket is uniquely identified by the source IP and the source port.

Please don't mix network programming (sockets) with network protocols.

However in the case of UDP you also have this 4-tuple!

The difference between TCP and UDP is that UDP does not use fixed connections so one socket can be used to send data to different computers and/or different destination ports.

For this reason the OS only saves 2 elements of the 4-tuple (IP address and port number of the local port) while the other 2 elements (IP address and port number of the other computer) have to be provided by the application (in the sendto() function).

On the other hand TCP is connection-oriented and a socket describes a connection between two computers. Therefore one socket can only be used to send data to a certain TCP port of a certain computer (using the send() function).

This means that all of the 4 elements (and not only 2 of them) of the 4-tuple are fixed for the socket so the OS can store all 4 elements and the application does not have to provide 2 of the 4 elements.