TCP, QUIC & reliable delivery

Its job in the system

An application often needs more than individual best-effort packets. A web document must be delivered coherently, even if some packets are lost or reordered along the way. Transport protocols provide endpoint behaviours above IP. They do not remove network limits, but they organise how applications use the available path.

How it works

TCP provides a reliable, ordered byte stream between endpoints. Sequence information and acknowledgements help detect missing data and support retransmission. Flow control protects the receiver from more data than it can accept; congestion control adapts sending to network conditions. These are distinct reasons for a sender to slow down.

QUIC provides secure transport over UDP and supports multiple streams. HTTP/3 uses QUIC, while HTTP/1.1 and HTTP/2 commonly use TCP. UDP alone supplies a simpler datagram service without TCP-style delivery guarantees, but a protocol built above UDP can add reliability and other features. A transport’s behaviour is not determined by the word “UDP” alone.

What it connects to

Transport sits between application messages and IP packets. It connects to the TLS and HTTP story, although modern protocol layering is not always a neat stack of separate boxes. If an alternate network path becomes available after a failure, endpoint mechanisms may recover lost data; if connectivity remains absent, a transfer can time out.

Different places, different designs

Different applications choose different trade-offs. Live conversation may value timely arrival over waiting indefinitely for old data, while a downloaded file needs completeness. Network filtering and software support can affect protocol choice. Our web journey describes common alternatives without assuming that every browser session uses the same one.