TCP

Before a TCP connection carries any application data, both endpoints complete a handshake establishing the connection's parameters, after which TCP tracks every segment sent, expects acknowledgment of receipt, retransmits anything not acknowledged within an expected window, and reassembles segments into their original order regardless of the order they actually arrived in — all of which happens transparently to the application using the connection, which simply sees a reliable, ordered stream of data.

The reliability guarantees TCP provides carry a genuine cost in connection setup latency and per-segment overhead, which is precisely the tradeoff QUIC was designed to address by combining TCP's connection-establishment step with encryption negotiation into a single faster handshake while still preserving reliable, ordered delivery — meaning QUIC targets the same reliability guarantee TCP provides but through a different underlying mechanism optimized for reduced round trips. This is also why TCP and UDP represent genuinely different mechanisms for the same general transport function rather than simply different generations of the same approach: an application choosing between them is trading TCP's delivery guarantees and ordering against UDP's lower overhead and latency, a decision that depends entirely on whether the specific application can tolerate occasional loss or reordering in exchange for reduced overhead. For CE verticals, TCP remains the default transport underlying the great majority of enterprise, industrial, and control-plane traffic across mining, energy, and maritime operations specifically because data completeness and correct ordering usually matter more for these applications than shaving marginal latency off connection setup, even as latency-sensitive field applications increasingly explore QUIC-based alternatives where setup speed matters more.