TCP: Reliable Transport

Learning objective

Follow a TCP connection and use packet evidence to explain reliable byte delivery, MSS, sliding windows, SACK, fast retransmit, and closure.

Why transport protocols exist

IP gets a packet to a host; TCP gets an ordered byte stream to an application on that host. TCP uses ports to identify the application conversation and sequence numbers to track bytes.

Segments, ports, and sockets

A TCP segment carries a portion of the byte stream. A port is a number in the TCP header, not a physical connector. A socket is an operating-system endpoint; a connected TCP conversation is identified by protocol and the two IP-address/port pairs. UDP uses datagrams and is covered in the next lesson.

Source and destination ports

The destination port helps find a service; the source port identifies the client's side. Several clients can reach the same server port at once because the complete endpoint pairs differ.

TCP header essentials

Swipe sideways to see all fields

TCP segment header format

Source port · 16 bits						Destination port · 16 bits
Sequence number · 32 bits
Acknowledgement number · 32 bits
Data offset · 4 bits			Reserved · 3 bits			Flags · 9 bits			Receive window · 16 bits
Checksum · 16 bits						Urgent pointer · 16 bits
Options + padding · optional
Application data · variable

Alongside ports, the header carries sequence and acknowledgement numbers, flags, an advertised receive window, checksum, and optional fields. SYN begins negotiation; ACK acknowledges bytes; FIN and RST close in different ways.

Interactive TCP connection journey

Play setup, delivery, loss, graceful closure, refusal, and timeout. Read packet direction and endpoint state together.

TCP Connection Journey

Choose a TCP journey

Successful three-way handshakeApplication data transferLost segment and retransmissionGraceful connection closeConnection refused with resetConnection attempt timeout

ClientClient: SYN-SENT

ServerServer: LISTEN

1. SYN · seq 1000✉
2. SYN, ACK · seq 5000 · ACK 1001
3. ACK · seq 1001 · ACK 5001

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 4: Client sends SYN

The client proposes initial sequence number 1000.

TCP evidence for Client sends SYN

Field	Value
Flags	SYN
Sequence number	1000
Acknowledgement number	Not present
Payload	0 bytes
Receive window	64240

Observed state: Client sends SYN

MSS and segment sizing

MSS (Maximum Segment Size) limits TCP payload bytes per segment, not the whole IP packet. Each peer can advertise its receive MSS in a SYN; a sender chooses a payload size that also fits the path and its own limits. In our example, MSS is 100 bytes so segment 1001–1100 carries 100 payload bytes. MSS is not the same as MTU.

Here is a separate handshake example showing where TCP options appear:

| Packet | Options offered | What the sender learns | | --- | --- | --- | | Client SYN | MSS 1460; Window Scale shift 2; SACK-Permitted | The client can receive payloads up to 1460 bytes and offers a 4× scale for its later advertised receive windows. | | Server SYN-ACK | MSS 1360; Window Scale shift 3; SACK-Permitted | The server can receive payloads up to 1360 bytes and offers an 8× scale for its later advertised receive windows. | | Client ACK | No new negotiation | Both endpoints know whether window scaling and SACK were offered in both directions. The client should not exceed the server's advertised MSS when sending toward it. |

Window scaling

The TCP header's window field is 16 bits. A Window Scale option in SYN segments negotiates a power-of-two multiplier for later advertised receive windows. For example, a displayed window value of 1,000 with scale factor 4 means 4,000 bytes of advertised space. The SYN's own window field is not scaled. This is receive-side flow control, not the congestion window. RFC 7323 defines the option.

Sequence numbers and acknowledgements

TCP numbers bytes, not packets. Segment 1001–1100 carries 100 bytes; ACK 1101 means the receiver next expects byte 1101. An ACK confirms transport receipt, not that the application has processed the data. TCP can buffer out-of-order bytes until the missing gap is filled.

Loss, retransmission, and duplicates

If bytes go missing, TCP may resend the missing sequence range. If the original was only delayed, the receiver can use sequence numbers to discard duplicate bytes. A retransmission can follow duplicate ACK evidence or a timer; neither guarantees eventual delivery.

Flow control and receive window

The receiver advertises buffer space with its receive window. In a simple example, the sender's window left edge is the oldest unacknowledged byte; the right edge is the first byte beyond the current sending limit. As cumulative ACKs move the left edge, the sender can send more. Real sending is also constrained by congestion control, which responds to the network rather than receiver buffer space.

Interactive TCP sliding window

Watch how a sender's byte window moves during normal delivery. The diagram separates acknowledged bytes, outstanding bytes, and bytes still waiting to be sent. Loss recovery is taught separately below.

See TCP’s byte window move

The numbered markers show byte positions in the TCP stream. Move one step at a time or play the complete packet flow.

▣Sender

Ready

▤Receiver

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 5: Sender is ready

The sender may transmit bytes 1001 through 1500. Left edge 1001 is the oldest unacknowledged byte; right edge 1501 is the first byte outside this example's window.

100112011401160118012001

1001–11001101–12001201–13001301–14001401–15001501–16001601–17001701–18001801–19001901–2000

Sent and acknowledgedSent but not acknowledgedWaiting to send

Sender window left edge

1001 — oldest unacknowledged byte

Next byte to send

1001

Sender window right edge

1501 — first byte outside this window

Cumulative ACK

1001 — next missing byte

SACK-Permitted and SACK blocks

SACK-Permitted can be offered in a SYN. Later, a receiver may use a SACK option to report contiguous bytes received beyond a missing gap. If bytes 1101–1200 are missing but 1201–1400 arrived, the cumulative ACK remains 1101 while the SACK block has left edge 1201 and right edge 1401. The right edge is exclusive: byte 1401 is not in that block. These SACK block edges are different from the sender window's left and right edges. RFC 2018 defines both options.

Fast retransmit

When later data arrives but an earlier segment is missing, the receiver repeats the same cumulative ACK. In the example, three duplicate ACKs for 1101 trigger fast retransmit of bytes 1101–1200 without waiting for the retransmission timer. SACK tells the sender that later bytes are already held. Without enough duplicate ACKs, recovery may instead wait for a timeout. RFC 5681 describes the classic trigger.

Interactive fast retransmit and SACK

Follow the two endpoint lifelines from a lost segment through three duplicate ACKs. Each optional SACK block reports the later bytes held by the receiver using a left edge and an exclusive right edge; the cumulative ACK stays at the first missing byte until the retransmission fills the gap. The packet animation shows the direction of every step.

Watch fast retransmit repair a missing segment

Time runs downward. Segment 4 (bytes 1101–1200) is lost; segments 5–7 arrive above the gap. Each sends a duplicate ACK back toward the sender.

SenderReceiver

1. DATA 1101–1200 lost✉
2. DATA 1201–1300
3. 1st duplicate ACK 1101
4. DATA 1301–1400
5. 2nd duplicate ACK 1101
6. DATA 1401–1500
7. 3rd duplicate ACK 1101
8. RETRANSMIT 1101–1200
9. ACK 1501

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 9: Bytes 1101–1200 are lost

The sender transmits this range but it does not arrive. The receiver still expects byte 1101.

Receiver buffer

1101–12001201–13001301–14001401–1500

Missing · buffered out of order · awaiting arrival · received in order

Cumulative ACK

1101 — first missing byte

Duplicate ACKs

0 of 3

No SACK block yet. The sender must advertise SACK-Permitted in its SYN before the receiver may report SACK blocks to it.

Graceful closure and resets

FIN closes one sending direction gracefully; TCP is full duplex, so the other direction closes separately. RST rejects or abruptly ends a connection. A SYN timeout means no response was observed, not that a particular firewall or host was definitely responsible.