TCP, UDP and ports

A port number is 16 bits, so it runs from 0 to 65535. Web servers using HTTPS listen on port 443.

Two puzzles first. In a video call, one small piece of your friend's voice goes missing on the way. Should your app ask for it again? Now you are downloading a homework file, and one piece of the file goes missing. Same question. Decide both before reading on.

Two missing pieces, two different answers

If you said no for the call and yes for the file, you have already chosen between the two transports. A piece of sound that arrives half a second late is useless. The conversation has moved on, so it is better to skip that piece and play the next one. A file with one piece missing is broken, so that piece is worth waiting for. The internet has a transport for each case: TCP waits and resends, UDP sends and moves on. Before either can help, though, a packet has to reach the right program.

Which program gets the packet: ports

An IP address gets a packet to the right computer. But one computer runs many programs at once: a browser with several tabs, a chat app, a music app. Both TCP and UDP headers carry a source port and a destination port, each a 16-bit number from 0 to 65535, and the port says which program a packet is for. A server program listens on an agreed port: 80 for plain HTTP, 443 for HTTPS, 53 for DNS, 25 for mail between servers. RFC 6335 splits the range into system ports 0 to 1023, user ports 1024 to 49151 and dynamic ports 49152 to 65535. Your computer picks a temporary source port for each conversation, often from the dynamic range. An address and a port together, such as 198.51.100.20:443, name one end of a conversation exactly.

TCP checks off every byte

TCP (RFC 9293) turns an unreliable stream of packets into something like a phone line for bytes. First the two sides set up a connection with a three-way handshake: the client sends SYN, the server answers SYN-ACK, and the client replies ACK. From then on every byte has a sequence number. The receiver sends acknowledgements (ACKs) saying how far it has got, and puts out-of-order pieces back in place. If the sender hears no ACK within a timeout, it sends the data again. RFC 6298 sets the first timeout at 1 second and then adjusts it to the measured round-trip time. TCP also slows down when it sees loss, so one busy link is not flooded.

UDP sends and moves on

UDP (RFC 768, 1980) does much less. Its header is only 8 bytes: two ports, a length and a checksum. There is no handshake, no sequence number and no resending. For the video call in the first puzzle, that is exactly right. Short DNS questions use UDP too, because one question and one answer are quicker without a handshake. QUIC, the transport under HTTP/3, runs on UDP and builds its own resending on top.

Four numbers keep two tabs apart

Four numbers together identify one TCP connection: source address, source port, destination address and destination port. That is how a server on port 443 can talk to thousands of browsers at once without mixing them up, and how your laptop keeps two tabs on the same site apart, because each tab's connection uses a different source port. Tap a packet in the simulator and read its header. Before the home router the source is 192.168.0.12 port 51000. After it, NAT has changed both numbers, and the router remembers the swap so replies go back to the right tab.