Don't Panic: TCP and UDP

TCP and UDP are the two traffic clerks standing above IP. IP can get a packet to the correct host, which is an impressive achievement until that host contains more than one program. The clerks use port numbers to point traffic at the right application endpoint. Same building, different desks, no interpretive dance required.

TCP is the clerk with a ledger. It establishes a connection, numbers the bytes, accepts acknowledgments, retransmits detected loss, and slows down for a receiver or a congested path. That is useful when every byte matters and arrives in sequence. The catch is that TCP is a byte stream, not a parcel service. Two application writes can emerge as one read, or as awkward fragments, so the application must label where its records begin and end.

UDP carries separate datagrams. Each delivered datagram keeps its boundary, and there is no transport handshake before sending. That makes it a fit when message boundaries matter or late data has less value than missing data. It also hands back several chores: delivery, ordering, duplicate handling, flow control, and congestion control do not disappear. They relocate into the protocol above UDP, where they become your problem with a much smaller hat.

A port is a delivery clue, not an identity card. TCP port eighty and UDP port eighty belong to separate transport namespaces. Neither transport tells you what the application data means, whether a peer processed it, or whether that peer is authorized. Those answers live in the application protocol and its security design.

Start with the Intro when the connection, datagram, and endpoint vocabulary is new. Use Slides when the choice between stream and message needs a compact map. Keep the Cheatsheet nearby for port ranges, header fields, and capture filters. The practice reference then turns the model into localhost evidence, where TCP chunks bytes and UDP keeps the two messages separate.

Don't Panic: TCP and UDP

Relevant careers