This chapter matters because it makes the cost of reliable delivery visible: connection setup, byte ordering, flow control, and congestion control are always paid for in latency, memory, and state.
In practice, it helps you design retries, connection reuse, streaming, and backpressure with a clear sense of how the transport layer reshapes application latency and throughput.
In interviews and design discussions, it lets you explain transport choices and load behavior through actual TCP mechanisms rather than vague claims about reliability.
Practical value of this chapter
Reliable delivery
Builds intuition for acknowledgments, retransmissions, and the cost of preserving order.
Congestion behavior
Shows how congestion control shapes data-flow decisions and retry policy.
Connection lifecycle
Shows how handshake, keep-alive, and queueing shape request-path performance.
Interview depth
Strengthens transport-layer discussion in reliability-critical design cases.
RFC
RFC 9293 (TCP)
Current TCP specification: segment format, connection states, and protocol behavior.
TCP matters not just as a “reliable transport,” but as the layer that converts network quality into concrete latency, memory cost, connection state, and service behavior under load.
In system design, it helps to understand how TCP creates connection state, why it relies on ACKs, and how retransmission, flow control, and congestion control shape service stability before application logic even gets involved.
Real transfer speed depends on MSS, cwnd, the receive window, RTT, and bandwidth-delay product. That is why nominal link bandwidth alone does not guarantee high throughput or low latency.
For architects, this turns into practical choices: when to keep connections warm, how to tune timeout and retry policy, where to apply backpressure, and why slow start or head-of-line blocking can quietly distort the user-visible request path.
Key properties of TCP
Reliable delivery
TCP preserves byte-stream order, acknowledges delivered segments, and retransmits data when the network drops it.
Connection state
Before payload flows, both peers establish shared connection state and negotiate the basic session parameters.
Acknowledgments and retransmissions
ACKs let TCP detect loss without application help and recover the stream after network disruption.
Flow control
The receiver limits in-flight data through the receive window so its buffers do not overflow.
Congestion control
The sender adjusts its pace from network signals instead of pushing for maximum speed all the time.
How the TCP segment header is structured
The header fields encode ordering, acknowledgments, window negotiation, error checking, and loss recovery behavior.
TCP segment header (base)
20-60 bytesSource Port
16 bits
Destination Port
16 bits
Sequence Number
32 bits
Acknowledgment Number
32 bits
Data Offset
4 bits
Reserved
3 bits
Flags
9 bits
Window Size
16 bits
Checksum
16 bits
Urgent Pointer
16 bits
Options + Padding (optional)
32 bits
The base header usually takes 20 bytes. Options such as MSS, Window Scale, SACK Permitted, and Timestamps can extend it to 60 bytes.
TCP connection lifecycle
Connection setup
SYN -> SYN-ACK -> ACK, synchronization of initial sequence numbers, MSS, and window settings.
Data transfer
Byte-stream segmentation, ACK processing, receive-window updates, and retransmissions on loss.
Connection teardown
FIN/ACK exchange in both directions, plus TIME_WAIT to protect the path from stale segments.
The TCP three-way handshake
The handshake does more than “open a socket”: it synchronizes sequence numbers, confirms reachability, and creates connection state that later costs latency, memory, and operational care.
TCP three-way handshake
Select a step or use the controls to replay the connection setup.
State
Click "Start" to see all TCP connection setup steps.
Once the connection is established, TCP keeps balancing growth and caution. This is where receiver limits, queue buildup, and path capacity become visible in real behavior.
Flow and congestion control dynamics
Step through RTT stages to watch how cwnd and rwnd evolve over time.
Congestion window (cwnd)
2 MSSReceive window (rwnd)
18 MSSEffective window (min)
2 MSSQueue pressure
8%Higher queue occupancy raises tail latency even when packet loss remains modest.
RTT
18 ms
Loss
0.0%
Estimated throughput
1.3 Mbps
MSS = 1460B
Phase: Slow start
What is happening in this step: Connection just started: sender ramps up cwnd quickly while the path is still uncongested.
Term decoding
- cwnd = congestion window - Sender-side window: adjusted by congestion signals and limits in-flight data volume.
- rwnd = receive window - Receiver-advertised window in ACKs that reflects available buffer capacity.
- send window = min(cwnd, rwnd) - Effective sending limit is always the smaller value of these two windows.
Related chapter
IPv4 and IPv6: evolution of IP addressing
How IP routing properties reshape TCP throughput, stability, and predictability.
How routing and network conditions shape TCP behavior
RTT and BDP
Higher RTT and bandwidth-delay product require larger effective windows to keep throughput high.
Loss and queue growth
Packet loss and queue buildup shrink cwnd, raise tail latency, and slow recovery.
Asymmetric routing
Different forward and reverse paths can reorder segments and trigger unnecessary duplicate ACK patterns.
MTU and fragmentation
Path MTU Discovery failures lead to fragmentation, blackhole behavior, and heavy retransmission loops.
Idle timeouts in NAT and load balancers
Middleboxes and load balancers can cut long-lived TCP sessions and make the outage look like a network incident.
Why this matters in System Design
- Handshake cost and connection warm-up directly shape p95/p99 at the service entry point.
- Window size, RTT, and congestion control define real throughput, not just nominal link bandwidth.
- Poor timeout and retry policy can trigger cascading failures very quickly under stress.
- Transport-level understanding helps separate network incidents from business-logic or application bugs faster.
Common mistakes
Treating the transport layer as stable by default and ignoring tail latency across network segments.
Mixing congestion signals and application timeouts into one metric without a layered breakdown.
Ignoring connection reuse and keep-alive, so the service keeps paying for avoidable handshakes.
Using identical timeout and retry policies for intra-DC and inter-region traffic.
Related chapters
- OSI model - places TCP in the transport layer and helps troubleshoot network problems one layer at a time.
- IPv4 and IPv6: evolution of IP addressing - shows how IP routing properties and addressing choices shape TCP behavior.
- UDP protocol - compares reliable TCP transport with a minimal transport that leaves guarantees to the application.
- HTTP protocol - shows how an application protocol reuses TCP connections in real production systems.
- WebSocket protocol - highlights the constraints and benefits of long-lived TCP sessions.
- Load Balancing - adds L4/L7 balancing, stickiness, and timeout behavior to the TCP picture.
- Remote call approaches - connects transport mechanics with timeout, retry, and backoff strategy.
- Why distributed systems and consistency matter - moves from transport mechanics into architectural trade-offs in distributed systems.