Tcp
The Transmission Control Protocol (TCP) is the transport-layer protocol that provides a reliable, ordered, error-checked byte stream between two programs over the unreliable, packet-based Internet. An application writes bytes into one end of a TCP connection and the same bytes come out the other end, in order and without gaps, even if the underlying network dropped, duplicated or reordered the packets that carried them.
TCP grew out of the 1974 work of Vint Cerf and Robert Kahn on connecting different networks, and its classic specification is RFC 793, published in 1981 alongside RFC 791 for IP. Together they form the TCP/IP suite that the ARPANET adopted in January 1983. RFC 793 was updated by many later documents, and the specification was consolidated as RFC 9293 in 2022, yet a connection from a 1980s implementation would still be recognized. TCP's guiding idea is that the network core stays simple and best-effort while the two end hosts do the work of guaranteeing correct delivery.
Every TCP connection begins with a three-way handshake that establishes state at both ends. The client sends a SYN segment carrying its initial sequence number, the server replies with SYN-ACK carrying its own number and acknowledging the client's, and the client answers with an ACK. Only then does data flow. A connection is identified by the four-tuple of source address, source port, destination address and destination port, which is how a server on port 443 can hold thousands of simultaneous conversations. Closing uses FIN segments in each direction, and a connection abruptly refused or aborted is signaled with RST.
Reliability comes from sequence numbers, acknowledgments and retransmission, while two separate controls keep the sender from doing harm. Flow control stops a fast sender from overwhelming a slow receiver: each ACK advertises a receive window, the amount of buffer space left. Congestion control stops senders collectively from overwhelming the network itself. After Internet congestion collapses in the mid-1980s, Van Jacobson's 1988 algorithms introduced slow start and congestion avoidance: a sender begins with a small window, grows it quickly while acknowledgments return, and cuts it sharply when loss signals congestion. Later variants refine this idea, including Reno, CUBIC (long the default on Linux) and Google's BBR, which estimates bandwidth and delay rather than reacting only to loss.
TCP's guarantees have a price, and its limits explain why other protocols exist. The handshake costs a round trip before any data moves, and encrypted connections add further round trips for TLS. Because delivery is in order, one lost packet stalls everything behind it until it is retransmitted, a problem called head-of-line blocking. TCP also treats loss as a congestion signal, which performs poorly on lossy wireless links. These weaknesses motivated QUIC, which rebuilds reliability on top of UDP, and applications that prefer timeliness over completeness, such as live calls, choose UDP outright.
A frequent misunderstanding is that TCP preserves message boundaries. It does not: it delivers a stream of bytes, and a single send of 1,000 bytes may arrive as two reads of 500, or two sends may be merged into one read. Programs built on it must frame their own messages with length prefixes or delimiters, which is exactly what HTTP and many database protocols do. Another is that TCP makes data safe: it guarantees delivery but not secrecy, so TLS is layered on top. In practice, tuning TCP buffers and congestion control matters for moving large datasets between data centers and for distributed machine-learning jobs that synchronize across many nodes.
Read TCP as the Internet's promise-keeper: a handshake, numbered bytes, acknowledgments and a throttled sending rate that together turn a lossy, unordered packet network into a trustworthy ordered stream, at the price of extra round trips and waiting.