TCP and UDP: two ways to use a network
IP promises almost nothing. A packet may be lost, duplicated, delayed, or delivered out of order, and nothing will tell you which happened. Everything dependable on the Internet is built on top of that, not into it.
There are two common answers. UDP adds ports and a checksum to IP and stops there — eight bytes of header, no connection, no promises.
TCP adds a great deal more, and charges a handshake for it.
What UDP is good for
That run is a DNS lookup: one datagram out, one back, done. No connection was established because there was nothing to establish — a single question and a single answer need no ordering, and if the answer never arrives the application simply asks again.
That is the pattern UDP fits: query/response exchanges, real-time media where a late frame is worse than a missing one, and anything that would rather implement its own recovery than accept TCP's. What UDP never does is hide a problem from you.
The entire UDP header: +-----------------+-----------------+| source port | dest port |+-----------------+-----------------+| length | checksum |+-----------------+-----------------+What TCP rebuilds
TCP numbers every byte it sends and expects an acknowledgement for it. That single mechanism gives ordering, deduplication and recovery — but recovery starts with a problem: nothing on the network reports a loss. No router sends an apology. The sender finds out because an acknowledgement it was expecting does not arrive before a timer expires.
Watch the timer do the work:
One last thing that can go wrong: size
Every link has a maximum packet size, its MTU — usually 1500 bytes, and less on anything tunnelled. Send something larger and it is fragmented into pieces, or dropped with an ICMP error telling the sender to try smaller. Neither outcome is reported to the application, and the second one is invisible if the error is filtered.
Key takeaways
- IP guarantees nothing. Both transports are answers to that, and neither changes the network underneath.
- UDP is ports and a checksum: eight bytes, no connection, no recovery, and no hidden delay.
- TCP numbers bytes and acknowledges them, which buys ordering and reliability at the price of a handshake and a wait.
- Loss is silent. The sender discovers it when a timer expires, not because anything reported it.
- In-order delivery means one lost segment stalls everything behind it — the transport-layer head-of-line blocking HTTP/3 exists to escape.