TCP

The Transmission Control Protocol: a handshake opens a connection between two ports, then bytes arrive complete and in order, resent when lost and paced to what the path can carry.

What it is: Network protocols (transport protocols)
Type: Open source
Made by: IETF
License: Open standard (IETF RFC)
Facts checked: 8 October 2026

What it is

TCP turns IP’s best-effort datagrams into a reliable, in-order, two-way byte stream. A connection is defined by a pair of sockets, each an IP address plus a port, and starts with a three-way handshake: the client sends a SYN with its initial sequence number, the server answers with a SYN-ACK carrying its own, and the client acknowledges that. From then on every byte has a sequence number. The receiver acknowledges what it has, the sender retransmits what goes unacknowledged, and a checksum on each segment catches corruption. A window field tells the sender how much the receiver can buffer (flow control), and every TCP must also run congestion control (slow start, congestion avoidance and exponential backoff of its retransmission timer) so that it slows down when the path is overloaded.

TCP carries bytes, not messages: it guarantees no link between how the application wrote data and how the other side reads it, so protocols on top mark their own boundaries. HTTP/1.1 uses Content-Length or chunked encoding, and HTTP/2 uses length-prefixed frames. Closing is a separate exchange of FIN segments, after which the side that closed first must linger in TIME-WAIT for twice the maximum segment lifetime. The current specification is RFC 9293 (August 2022), which gathered four decades of fixes to RFC 793 into one document.

Why teams pick it

Reliable and ordered by default: lost segments are resent and duplicates dropped, so the application reads exactly the bytes that were sent
Mandatory congestion control lets many connections share a path without driving it into congestion collapse
The transport that HTTP/1.1, HTTP/2, TLS, SSH and FTP were all designed for, so a TCP service works with the tools and libraries every platform already has

Watch out for

One round trip for the handshake before any data, and another for TLS on top, before the first request leaves
Head-of-line blocking: one lost segment holds back every byte behind it, even data for unrelated HTTP/2 streams
A connection is bound to its two addresses and ports, so when a phone moves to another network it breaks and has to be reopened
No message boundaries, and closed connections linger in TIME-WAIT (two maximum segment lifetimes, which the spec takes as 2 minutes each)

Alternatives

What all transport protocols have in common →

QUICOpen sourceA secure, multiplexed transport over UDP: TLS 1.3 is built into its handshake, many streams share one connection without blocking each other, and a connection can survive a change of network.UDPOpen sourceThe User Datagram Protocol: ports and a checksum on top of IP, and nothing else. Each datagram is sent on its own, with no connection, no retransmission and no ordering.

How it fits with other technologies

What uses TCP

Open a TCP connection, see both sockets, and send bytes · python

import socket

# create_connection resolves the name and runs SYN, SYN-ACK, ACK
with socket.create_connection(("example.com", 80), timeout=5) as s:
    print(s.getsockname(), "->", s.getpeername())  # e.g. ('192.168.1.20', 53188) -> ('<server ip>', 80)
    s.sendall(b"HEAD / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n")
    print(s.recv(1024).split(b"\r\n")[0])  # b'HTTP/1.1 200 OK'
# leaving the block closes the connection with a FIN; the OS picked the client port

See it in a real stack

No architecture uses TCP yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from1973–2022

By 1973 ARPA was funding packet radio and satellite networks alongside the ARPANET, and the ARPANET’s own host-to-host protocol, NCP, couldn’t span them. Work began that year on a protocol that could. Vint Cerf, Yogen Dalal and Carl Sunshine published a specification of an Internet Transmission Control Program as RFC 675 in December 1974. After several revisions the result was two protocols: IP (RFC 791) carries datagrams between hosts with no reliability at all, and TCP (RFC 793, September 1981) adds connections, sequencing and retransmission only at the two ends.

In November 1981 RFC 801 set out the move of every ARPANET host from NCP to TCP/IP, with the goal of a complete switch by 1 January 1983. As traffic grew, TCP itself had to change: RFC 1122 (October 1989) required Van Jacobson’s slow start and congestion avoidance, so that senders back off when the network is overloaded. Fixes and extensions kept arriving in separate documents for decades, until RFC 9293 (August 2022) gathered them into one specification and obsoleted RFC 793.

Why it’s built this way

Reliability at the ends, not in the network: IP gives no acknowledgements, retransmissions or flow control. TCP detects loss with sequence numbers and errors with checksums, and corrects both by retransmitting, so the networks in between only have to forward packets.
A three-way handshake: RFC 9293 gives the principal reason as preventing old duplicate connection requests, still wandering the network, from being mistaken for new ones. Each side picks an initial sequence number and has it acknowledged before data counts.
Port numbers to multiplex: TCP uses ports to identify application services and to keep many flows between the same two hosts apart, so one machine can run a web server, a mail server and hundreds of client connections at once.

Timeline

1973
Work begins on a host-to-host protocol for interconnected networks
1974
RFC 675 specifies an Internet Transmission Control Program
1981
RFC 793 defines TCP, alongside IP in RFC 791
1983
Target date for the ARPANET’s complete switch from NCP to TCP/IP
1989
RFC 1122 makes congestion control a requirement
2022
RFC 9293 consolidates the specification and obsoletes RFC 793

Sources6 · facts checked 8 October 2026

Improve this page on GitHub