tags in the . .ico is the /favicon.ico fallback that<br>many crawlers, RSS readers, and older Safari hit directly. -->

-->

How TCP Works — Handshake, Sequence Numbers, Congestion Control

Search tools and guides ⌘K

12 min read · Guide · Network<br>How it works · Network<br>TCP,<br>picked apart.<br>IP delivers postcards into a hurricane. TCP, somehow, makes them feel like a phone call —<br>ordered, reliable, and exactly the bytes you sent. The trick is bookkeeping.

Parts01 – 08 InteractiveFull lifecycle PrereqIP / sockets

Part 01<br>What TCP promises<br>What does TCP guarantee?<br>Three guarantees, layered on chaos.<br>TCP (Transmission Control Protocol) provides three guarantees on top of the unreliable IP layer: reliable, ordered, byte-stream delivery . Vint Cerf and Bob Kahn specified it in 1974; RFC 793 standardised it in 1981, refreshed as RFC 9293 in 2022. TCP underlies HTTP/1, HTTP/2, SSH, SMTP, FTP, and most other application protocols.<br>IP delivers packets like postcards thrown into a hurricane: capable of arriving<br>duplicated, out of order, or never arriving at all. TCP layers a perfectly<br>reliable, ordered, byte-stream abstraction directly on top.<br>Three guarantees, all of them implemented in one of the most carefully evolved pieces of<br>infrastructure on the planet.

01<br>Reliable<br>Every byte you send is acknowledged or retransmitted. If a packet drops at a router<br>five hops in, TCP notices the gap and resends — without the application ever knowing.<br>02<br>Ordered<br>Bytes arrive in exactly the sequence they were sent. The receiver buffers<br>out-of-order segments and waits — the OS will not deliver byte 1000 to the application<br>until byte 1 has been delivered.<br>03<br>Byte-stream<br>There are no messages in TCP. The sender writes 100 bytes; the receiver may<br>read 80 then 20, or 100 in one shot. Application protocols layered on TCP must add<br>their own framing — which is exactly what HTTP, TLS, and Redis all do.

Part 02<br>Why three packets, not two<br>TCP three-way handshake<br>Three-way handshake.<br>A connection isn't open until both sides know two things: their own initial sequence<br>number, and the peer's. With two packets you can synchronize one direction. To synchronize<br>both directions and prove the round trip works, you need three.<br>The Initial Sequence Numbers are not zero — and they shouldn't be. If a router delays a<br>packet for two minutes and finally delivers it, random ISNs ensure the new connection<br>rejects the stale packet as mathematically impossible. Without random ISNs, a long-lost<br>packet from a closed connection could inject corrupted bytes into your live database<br>query. The number of bugs this avoids is measured in decades.

SYN · SYN-ACK · ACK<br>Three packets, one round trip.<br>Client SYN announces its ISN. Server SYN-ACK announces its own ISN and acknowledges the<br>client's. Client ACK confirms. After this third segment, both sides are in<br>ESTABLISHED; data may flow.

Options ride along<br>MSS · SACK · window scaling.<br>The handshake also negotiates options: maximum segment size (so neither side overshoots<br>the path MTU), selective acknowledgement (so a single dropped packet doesn't stall the<br>whole window), and window scaling (so 16-bit windows can advertise gigabytes).

Part 03<br>Watch a connection live<br>TCP connection lifecycle — open, talk, close<br>Open, talk, close.<br>The simulator below plays the entire lifecycle: three-way handshake, a single<br>request/response data exchange, and the four-way teardown. Use the phase tabs to jump,<br>the player to scrub, and + Show wire bytes to read the actual segment header<br>values at each step.

Three-way handshakeData flowFour-way teardown<br>↺ ◀ ▶ Play ▶ 0.5×1×2×

CLIENTBrowser198.51.100.24:51324SERVERexample.com93.184.216.34:443 01SYN 02 SYN-ACK 03 ACK · handshake complete 04 DATA · 17 bytes 05 ACK · cumulative 06 DATA · response 07 ACK 08 FIN · client closes 09 ACK · server received FIN 10 FIN · server closes 11 ACK · TIME_WAIT begins 11 SEGMENTS · 3 PHASES · 1 RELIABLE BYTE-STREAM<br>Step 01 of 11<br>The client starts with a SYN — synchronize. It picks a random Initial Sequence Number (ISN) so that any stale packet from a long-dead connection cannot be mistaken for live data. The window field offers receive-buffer space; options negotiate MSS, selective ACK, and window scaling.<br>+ Show wire bytes

Part 04<br>The bookkeeping<br>TCP sequence numbers and cumulative ACKs<br>Sequence numbers, cumulative ACKs.<br>Every byte gets a number. The sequence number in a TCP header is the number of the<br>first byte of the payload. The acknowledgement number is the next byte the<br>receiver expects.<br>The ACK is cumulative — ack=1018 means<br>"every byte up to and including 1017 has arrived." If the receiver got bytes 1–100 then<br>bytes 201–300, it does not ack 300. It keeps acking 101 — repeatedly, urgently —<br>screaming at the sender that there's a hole. When the sender sees three duplicate ACKs in<br>a row, it doesn't wait for its retransmit timer; it triggers fast retransmit<br>and resends the missing segment immediately.<br>This is why packet loss shows up as a stutter on a...