Foundations — TCP — header, connection (3-way handshake, 4-way termination)

Before you can read the parent note, you need to see every word it leans on. This page builds each one from nothing, in an order where every idea only uses ideas already defined above it.

0. What is a "byte"? (the atom TCP counts)

The picture: imagine a long ribbon of little boxes, each box holding one byte. That ribbon is your data.

Why TCP needs this: the parent note keeps saying "TCP numbers bytes, not packets." If you don't know a byte is one box on the ribbon, that sentence is meaningless. TCP glues a position number onto each box so it can talk about "the box at position 1000."

1. Bits as capacity — why "16-bit" and "32-bit" appear

The picture: a row of light-switches. Each switch is a bit. The number of distinct patterns of on/off is what you can count.

Why the topic needs it. The parent says ports need 16 bits because ports run $\mathrm{0..65535}=2^{16}-1$, and sequence numbers need 32 bits. Now you can check that claim yourself:

2. What is a "process" and a "port"?

The picture: the machine is an apartment building (it has one street address — its IP). The port is which apartment door the message goes to.

Why the topic needs it. The TCP header's first two fields are Source Port and Dest Port. They exist so the data reaches the right program, not just the right computer. See Sockets & Ports for the full story.

3. IP: the unreliable delivery service underneath

The picture: you drop numbered postcards in a mailbox. Some vanish. Some overtake others. Some get photocopied. IP is best-effort, nothing more.

Why the topic needs it. This is the whole reason TCP exists. The parent's opening line — "TCP turns an unreliable packet-tossing network (IP) into a reliable pipe" — only makes sense once you see IP as this careless postman. TCP rides inside IP packets. Details: IP — packet structure & routing.

4. Segment vs. packet — which envelope holds which

The picture: think of nested envelopes. The inner envelope is the TCP segment — its writing (ports, seq, ack, flags) is the TCP header. The outer envelope is the IP packet — its writing (source/dest IP address) is the IP header. The postman (§3) only reads the outer envelope; the inner one is opened by TCP at the far end.

Why the topic needs it. From here on the parent says "segment" constantly (e.g. "seq of a segment = byte index of its first data byte"). You now know a segment is the TCP-level chunk, distinct from the IP packet carrying it.

5. "Reliable, ordered, byte-stream" — unpacking the promise

The picture: the careless postman from §3 drops postcards in random order, but a smart clerk (TCP) at the receiving end re-sorts them by their position number, refills missing ones, and hands the app a perfectly ordered stack.

Why the topic needs it. Every mechanism in the parent — sequence numbers, acknowledgments, the handshake — is machinery that upgrades §3's chaos into this promise. See Reliable Data Transfer Principles.

6. Sequence number — a position label on the ribbon

The picture: back to the ribbon of boxes from §0. If a chunk of data starts at box #1000 and is 500 boxes long, it occupies boxes $1000$ through $1499$; the next chunk starts at box $1500$.

The picture: an odometer with $2^{32}$ positions. Roll past the last number and it clicks back to $0000\dots$. TCP is built to expect this roll-over, so a seq of $2^{32}-3$ followed by $5$ bytes correctly lands at seq $2$, not at an error.

Why the topic needs it. Without the "modulo" rule, the parent's claim that seq "wraps around" looks like a bug. It's not — it's arithmetic on a fixed-size odometer.

7. ISN — where each side starts counting

The picture: two friends about to pass notes. Friend A says "I'll number my notes starting at 1000." Friend B says "I'll start mine at 5000." Those starting numbers are the two ISNs.

Why $x$ and $y$ differ (both directions have their own ribbon): TCP is full-duplex — data flows both ways at once, and each direction is its own separate ribbon with its own counting. So there are two ISNs, one per direction.

Why not always start at 0? Starting at an unpredictable number stops old, delayed packets from a previous connection from being mistaken for new data.

8. Acknowledgment number — "the next box I want"

The picture: the clerk has correctly stacked boxes up to #1000. It holds up a sign: "send me #1001 next." That $1001$ is the ack number. It silently confirms everything before $1001$ arrived (this is called a cumulative ack).

Why "next expected" and not "last received"? It packs two facts into one number: "I have everything up to here" AND "here's where to continue." This is the single most-tested subtlety in the parent note, and it's why ack $=\text{ISN}+1$ (the SYN uses up one position — covered on the handshake page).

9. Flags — the one-bit verbs

The picture: a row of six little on/off lamps riding on top of every segment. Which lamps are lit tells the other side what kind of message this is.

Why the topic needs it. The handshake and teardown are nothing but sequences of these lamps switching on: SYN → SYN,ACK → ACK for setup; FIN, ACK, FIN, ACK for teardown.

10. The rest of the header — data offset, reserved, checksum

The picture: a little ruler at the front of the segment saying "the payload starts this many 4-byte steps in." Without it the receiver wouldn't know where the header ends and data begins — because options make the header a variable length.

The picture: a fingerprint of the whole segment. Change one bit anywhere and the fingerprint should no longer match.

11. Urgent pointer & the URG flag

The picture: a highlighted stretch at the front of the payload with a marker — the urgent pointer — showing where the highlight stops. The app is nudged to look at that stretch immediately. (Rarely used in practice, but it's a real header field, so it's here.)

Why the topic needs it. The parent lists the URG flag and says it "makes the urgent pointer valid" — this section defines the field that flag refers to.

12. Window — "how much more I can accept"

The picture: the clerk has a shelf of limited size. The window is the clerk shouting the number of empty shelf-slots left. When the shelf is full, window = 0 → "pause."

Why the topic needs it. Otherwise the parent's "how many more bytes I can buffer" would be capped at 64 KB, and readers would wrongly conclude TCP can never keep a fast link busy. Full mechanics: Sliding Window & Flow Control.

13. Options — the stretchy tail of the header

The picture: the fixed 20 bytes are the standard form; Options is the "attach extra sheets here" section, and Data Offset counts how many sheets were attached.

14. Contrast anchor: what UDP leaves out

How these feed the topic

Equipment checklist

Test yourself — cover the right side.

Connections

• 4.3.19 TCP — header, connection (3-way handshake, 4-way termination) (Hinglish) — parent, in Hinglish
• IP — packet structure & routing — the unreliable layer TCP fixes
• UDP — connectionless transport — the contrast that shows what TCP adds
• Sockets & Ports — where port numbers come from
• Reliable Data Transfer Principles — seq/ack and retransmission theory
• Sliding Window & Flow Control — the window field and window scaling in action
• TCP Congestion Control — the other limit, the network's