Transport Protocols - Learning Module

Loading content...

0/228

TCP Overview: The Foundation of Reliable Internet Communication

The Protocol That Built the Internet

When you load a web page, download a file, send an email, or stream a video, you're almost certainly relying on the Transmission Control Protocol (TCP). This remarkable protocol, first specified in RFC 793 in 1981, has become the backbone of reliable Internet communication—handling everything from simple text transfers to massive cloud database transactions spanning continents.

TCP isn't just a protocol; it's an engineering marvel that transforms the unreliable, best-effort delivery of IP packets into a dependable, ordered byte stream. Understanding TCP deeply isn't optional for network professionals—it's essential for diagnosing performance issues, designing distributed systems, and building applications that behave correctly under real-world network conditions.

What You Will Learn

By the end of this page, you will understand TCP's fundamental characteristics, how it provides reliability over an unreliable network layer, its connection-oriented nature, byte-stream semantics, and full-duplex communication model. You'll see why TCP remains the protocol of choice for most Internet applications after four decades of service.

TCP's Position in the Protocol Stack

To appreciate what TCP does, we must first understand what the layers below it provide—and critically, what they don't provide.

The Network Layer (IP) provides:

Host-to-host delivery across networks
Best-effort packet forwarding
Logical addressing (IP addresses)
Routing decisions at each hop

The Network Layer does NOT provide:

Guaranteed delivery (packets can be dropped)
Order preservation (packets can arrive out of order)
Duplicate detection (packets can be duplicated)
Flow control (senders can overwhelm receivers)
Congestion control (networks can become overloaded)

This gap between what applications need and what IP provides is precisely where TCP operates. TCP sits atop IP and adds all the missing reliability features, presenting applications with an abstraction of a reliable, ordered byte stream.

Protocol Stack Responsibilities
Layer	Protocol	Responsibility	Guarantees
Application	HTTP, FTP, SMTP, etc.	Application-specific semantics	Depends on transport choice
Transport	TCP	Reliable, ordered, process-to-process delivery	Delivery, ordering, integrity
Network	IP	Host-to-host routing	None (best-effort)
Data Link	Ethernet, Wi-Fi, etc.	Frame delivery over single link	Single-hop error detection
Physical	Cables, radio, etc.	Bit transmission	None

The End-to-End Principle

TCP embodies the end-to-end principle: reliability is implemented at the endpoints (hosts), not in the network core. Routers simply forward packets without guarantees. This design choice has proven remarkably scalable—routers remain simple and fast, while complexity is pushed to the edges where computational resources are more readily available.

Connection-Oriented Communication

TCP is connection-oriented, meaning that before any application data can be exchanged, the two communicating endpoints must first establish a connection. This is fundamentally different from connectionless protocols like UDP, where data can be sent immediately without any setup.

What does establishing a connection mean?

A TCP connection is a logical relationship between two endpoints that involves:

Agreement on communication parameters—both sides negotiate initial sequence numbers, maximum segment size, window scaling factors, and other options
State synchronization—both endpoints create Transmission Control Blocks (TCBs) containing connection state
Resource allocation—both sides allocate buffers for sending and receiving data
Identity verification—each side confirms it's communicating with the intended peer (though TCP itself doesn't provide cryptographic authentication)

Converting Mermaid diagram...

The Three-Way Handshake

TCP establishes connections using a three-way handshake:

SYN — The client sends a segment with the SYN (synchronize) flag set, along with a randomly chosen Initial Sequence Number (ISN)
SYN-ACK — The server responds with both SYN and ACK flags set, acknowledging the client's ISN and providing its own ISN
ACK — The client acknowledges the server's ISN, completing the handshake

Why three messages instead of two?

The three-way handshake ensures both sides agree on their initial sequence numbers and confirms that both directions of communication work. A two-way handshake couldn't confirm that the client received the server's ISN, potentially causing desynchronization.

Connection Setup Overhead

Each TCP connection requires at least 1.5 round-trip times (RTTs) before data can flow—the SYN, SYN-ACK, and then data can be sent with the final ACK. For high-latency networks or short-lived connections (like individual HTTP requests), this overhead is significant. Modern protocols like QUIC and TCP Fast Open aim to reduce this setup latency.

Connection-Oriented Benefits

•State synchronization — Both endpoints know the connection is operational before sending data
•Parameter negotiation — MSS, window scale, timestamps, and selective acknowledgments can be negotiated
•Resource preparation — Buffers are allocated, ensuring resources are available
•Sequence number initialization — Random ISNs prevent spoofing attacks and old segment confusion
•Path verification — The handshake confirms bidirectional reachability

Reliability Mechanisms

TCP's defining characteristic is reliable delivery. But what exactly does reliability mean, and how does TCP achieve it over an unreliable network?

TCP's reliability guarantees:

No data loss — Every byte sent by the sender will be delivered to the receiver (or an error will be reported)
No duplication — Bytes are delivered exactly once, never duplicated
No corruption — Data arrives exactly as it was sent, with integrity verified
Ordered delivery — Bytes are delivered in the exact order they were sent

These guarantees are maintained even when the underlying network drops packets, delivers them out of order, duplicates them, or corrupts them. Let's examine the mechanisms that make this possible.

TCP Reliability Mechanisms
Problem	Mechanism	How It Works
Packet loss	Retransmission	Sender maintains timers; if ACK doesn't arrive, segment is retransmitted
Out-of-order delivery	Sequence numbers	Each byte has a sequence number; receiver reorders segments
Duplicate packets	Sequence numbers	Receiver detects and discards duplicate segments
Data corruption	Checksum	16-bit checksum covers header and payload; corrupted segments are discarded
Receiver overflow	Flow control	Receiver advertises window size; sender limits outstanding data
Network congestion	Congestion control	Sender adapts rate based on detected congestion

The Acknowledgment and Retransmission Model

TCP uses positive acknowledgments with retransmission (PAR). For every segment sent, the receiver sends an acknowledgment. If the sender doesn't receive an ACK within a timeout period, it assumes the segment was lost and retransmits.

Key aspects of TCP's acknowledgment scheme:

Cumulative ACKs — An ACK for byte N means all bytes up to N-1 have been received correctly
Selective Acknowledgments (SACK) — An optional extension allowing receivers to report non-contiguous blocks received
Delayed ACKs — Receivers may delay ACKs to piggyback them on return data
Duplicate ACKs — Three duplicate ACKs trigger fast retransmit without waiting for timeout

Reliability vs. Performance

TCP's reliability comes at a performance cost. Retransmissions add latency, acknowledgments consume bandwidth, and head-of-line blocking delays data while waiting for out-of-order segments. This is why understanding the reliability mechanisms is crucial—knowing when these costs are acceptable and when alternatives like UDP might be better.

Byte-Stream Service

TCP provides a byte-stream abstraction to applications—a continuous, ordered stream of bytes, not discrete messages. This is a fundamental design choice with far-reaching implications.

What this means in practice:

The application writes bytes to the send buffer; TCP decides how to segment them
The receiver reads bytes from the receive buffer; message boundaries are not preserved
TCP may combine multiple writes into one segment (coalescing)
TCP may split one write across multiple segments (fragmentation)
The receiver may receive data in different chunks than the sender wrote

Sender Side

•Application calls write() with 1000 bytes
•TCP adds to send buffer
•TCP segments based on MSS and congestion window
•May send as one 1000-byte segment
•Or two 500-byte segments
•Or combine with other writes

Receiver Side

•Application calls read() for 1000 bytes
•May receive 500 bytes (partial read)
•Must call read() again for remaining
•Or may receive 1500 bytes (multiple writes)
•Application must parse byte stream
•Must implement own message framing

The Message Boundary Problem

Because TCP doesn't preserve message boundaries, applications must implement their own framing. Common approaches include: fixed-length messages, length-prefixed messages (sending length before data), delimiter-separated messages (like HTTP's CRLF), or self-describing formats (like JSON or Protocol Buffers). Failing to handle this correctly is a common source of bugs.

message_framing.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Length-prefixed message framing example
 
import struct
 
def send_message(sock, message: bytes):
    """Send a message with 4-byte length prefix."""
    # Pack length as 4-byte big-endian integer
    length_prefix = struct.pack('>I', len(message))
    # Send length + message
    sock.sendall(length_prefix + message)
 
def recv_message(sock) -> bytes:
    """Receive a length-prefixed message."""
    # First, read the 4-byte length prefix
    length_data = recv_exactly(sock, 4)
    if not length_data:
        return None
    
    # Unpack the length
    message_length = struct.unpack('>I', length_data)[0]
    
    # Now read exactly that many bytes
    return recv_exactly(sock, message_length)
 
def recv_exactly(sock, n: int) -> bytes:
    """Receive exactly n bytes from socket (handling partial reads)."""
    data = b''
    while len(data) < n:
        chunk = sock.recv(n - len(data))
        if not chunk:
            return None  # Connection closed
        data += chunk
    return data
 
# Usage example
# send_message(sock, b'Hello, World!')
# message = recv_message(sock)  # Returns b'Hello, World!'

Contrast with Message-Oriented Protocols

Unlike TCP, UDP and SCTP preserve message boundaries. When an application sends a datagram via UDP, the receiver gets that exact datagram (or nothing). This simplifies application code but requires the application to handle potential message loss itself.

The byte-stream model suits many applications—file transfers, remote terminals, database connections—where data is naturally a continuous stream. But for request-response patterns or discrete events, the lack of message boundaries adds complexity.

Full-Duplex Communication

TCP connections are full-duplex, meaning data can flow simultaneously in both directions. Each direction of flow is independent, with its own sequence numbers, acknowledgments, and flow control.

What full-duplex enables:

Either side can send data at any time, without waiting for the other
Acknowledgments can be piggybacked on data flowing in the reverse direction
The connection can be half-closed (one direction terminated while the other remains open)
Applications can implement symmetrical protocols where both sides send and receive

Converting Mermaid diagram...

Independent Sequence Spaces

Each direction of a TCP connection has its own:

Sequence number space — Client-to-server and server-to-client have independent sequence numbers
Acknowledgment tracking — Each side tracks what it has sent and what has been acknowledged
Flow control window — Each receiver advertises its own receive window
Send and receive buffers — Four buffers total: send and receive on each endpoint

Piggybacking

Because of full-duplex operation, acknowledgments can be efficiently combined with data. When a host has data to send, it can include the ACK for recently received data in the same segment, reducing overall packet count.

Full-Duplex vs. Half-Duplex vs. Simplex
Mode	Data Flow	Example	TCP Analogy
Simplex	One direction only	Broadcast TV	N/A (TCP doesn't support)
Half-Duplex	Both directions, but alternating	Walkie-talkies	After half-close
Full-Duplex	Both directions simultaneously	Telephone call	Normal TCP connection

Half-Close: Shutdown vs. Close

TCP supports graceful half-close via the FIN flag. An application can call shutdown(SHUT_WR) to indicate it's done sending while still receiving. This is essential for protocols where one side needs to signal 'end of request' while waiting for a response. The close() call terminates both directions.

TCP Segment Structure

The TCP segment (also called a TCP packet when encapsulated in IP) consists of a header followed by optional data. The header carries all the control information needed for reliable, ordered delivery.

TCP Header Fields (20 bytes minimum):

TCP Header Fields
Field	Size	Purpose
Source Port	16 bits	Identifies the sending application
Destination Port	16 bits	Identifies the receiving application
Sequence Number	32 bits	Position of first data byte in stream
Acknowledgment Number	32 bits	Next expected byte from peer
Data Offset	4 bits	Header length in 32-bit words
Reserved	4 bits	Reserved for future use
Flags	8 bits	Control flags (SYN, ACK, FIN, RST, PSH, URG, ECE, CWR)
Window Size	16 bits	Receive window for flow control
Checksum	16 bits	Error detection covering header and data
Urgent Pointer	16 bits	Offset to urgent data (if URG flag set)
Options	Variable	Optional extensions (MSS, SACK, timestamps, etc.)

The Control Flags

TCP's eight flags control connection management and data handling:

SYN — Synchronize sequence numbers (connection establishment)
ACK — Acknowledgment field is valid
FIN — Sender is finished sending (connection termination)
RST — Reset the connection (abort)
PSH — Push data to application immediately (don't buffer)
URG — Urgent pointer field is valid
ECE — ECN-Echo (explicit congestion notification)
CWR — Congestion window reduced

Maximum Segment Size (MSS)

MSS is the largest amount of data TCP will send in a single segment, negotiated during connection setup. It's calculated from the Path MTU minus IP and TCP header sizes. Typical values are 1460 bytes (Ethernet) or 1220 bytes (with IPsec overhead). MSS is NOT the same as MTU—MSS is payload only, while MTU includes headers.

Flow and Congestion Control Overview

Two critical mechanisms prevent TCP from overwhelming either the receiver or the network: flow control and congestion control. While often confused, they serve different purposes.

Flow Control — Protecting the Receiver

The receiver has finite buffer space. If the sender transmits too fast, the receiver's buffer overflows and data is lost. TCP solves this with the sliding window mechanism:

The receiver advertises its available buffer space in the Window Size field
The sender limits its unacknowledged data to this window size
As the receiver processes data and frees buffer space, it advertises a larger window
If the receiver's buffer fills, it advertises window=0, stopping the sender

Congestion Control — Protecting the Network

The network has finite capacity. If too many senders transmit too fast, routers become overwhelmed, drop packets, and in extreme cases, the network collapses (congestion collapse). TCP solves this with:

Slow start — Begin with a small congestion window, grow exponentially
Congestion avoidance — After a threshold, grow linearly
Fast retransmit — Detect loss via duplicate ACKs
Fast recovery — Reduce window without returning to slow start

Flow Control

•Purpose: Prevent receiver overflow
•Signal: Receiver advertises window
•Location: End-to-end (receiver → sender)
•Mechanism: Sliding window
•Response: Stop when window = 0

Congestion Control

•Purpose: Prevent network overload
•Signal: Packet loss, ECN marks
•Location: Sender-side estimation
•Mechanism: AIMD algorithms
•Response: Reduce congestion window

Effective Window

The actual amount of data TCP can send is limited by the MINIMUM of the flow control window (receiver's limit) and the congestion window (network's estimated capacity). If either is small, transmission is throttled. This is why performance analysis requires examining both windows.

TCP's Strengths and Weaknesses

After four decades of service, TCP's strengths have been proven in production at every scale imaginable. But its weaknesses have also become clear, driving the development of alternative protocols.

Why TCP dominates:

TCP Strengths

•Universal availability — Implemented in every operating system, supported by every network
•Proven reliability — Four decades of testing and refinement
•Automatic congestion response — Plays nicely with other network users
•In-kernel implementation — Highly optimized, zero-copy possible
•Firewall friendly — Stateful inspection is well understood
•Application simplicity — Applications get a simple byte-stream abstraction

TCP Weaknesses

•Connection setup latency — 1-1.5 RTT before data flows
•Head-of-line blocking — One lost segment delays all following data
•Ossification — Middleboxes block TCP extensions, preventing evolution
•No multipath support — TCP ties connections to IP addresses
•Limited congestion control — Can't easily update algorithms
•No message boundaries — Applications must implement framing

Modern Evolution

Protocols like QUIC (which powers HTTP/3) address many TCP weaknesses while maintaining reliability. QUIC runs over UDP, enabling faster evolution, eliminates head-of-line blocking through multiplexed streams, supports connection migration, and reduces connection setup to 0-1 RTT. Understanding TCP deeply helps you appreciate what QUIC improves.

Summary: TCP at a Glance

TCP is the reliable workhorse of Internet communication. Let's consolidate the key concepts:

Key Takeaways

•TCP provides reliability over unreliable IP — retransmission, ordering, duplicate detection, and integrity checking transform best-effort delivery into guaranteed delivery
•Connection-oriented operation — three-way handshake establishes state before data flows, enabling parameter negotiation and bidirectional verification
•Byte-stream abstraction — TCP delivers a continuous stream of bytes; applications must implement their own message framing
•Full-duplex communication — data flows independently in both directions with separate sequence spaces
•Flow control protects receivers — sliding window prevents buffer overflow
•Congestion control protects networks — AIMD algorithms prevent network collapse
•Universal deployment — TCP works everywhere but evolves slowly due to middlebox ossification

What's next:

With TCP's comprehensive features come complexity and overhead. The next page explores UDP—TCP's lightweight alternative that trades reliability for speed and simplicity. Understanding UDP's design philosophy will help you appreciate when each protocol is appropriate.

Page Complete

You now have a deep understanding of TCP's fundamental characteristics—its position in the protocol stack, connection-oriented nature, reliability mechanisms, byte-stream service, and full-duplex operation. Next, we'll explore UDP and see how a radically different design philosophy serves different application needs.

TCP Overview: The Foundation of Reliable Internet Communication

The Protocol That Built the Internet

What You Will Learn

TCP's Position in the Protocol Stack

To appreciate what TCP does, we must first understand what the layers below it provide—and critically, what they don't provide.

The Network Layer (IP) provides:

Host-to-host delivery across networks
Best-effort packet forwarding
Logical addressing (IP addresses)
Routing decisions at each hop

The Network Layer does NOT provide:

Guaranteed delivery (packets can be dropped)
Order preservation (packets can arrive out of order)
Duplicate detection (packets can be duplicated)
Flow control (senders can overwhelm receivers)
Congestion control (networks can become overloaded)

Protocol Stack Responsibilities
Layer	Protocol	Responsibility	Guarantees
Application	HTTP, FTP, SMTP, etc.	Application-specific semantics	Depends on transport choice
Transport	TCP	Reliable, ordered, process-to-process delivery	Delivery, ordering, integrity
Network	IP	Host-to-host routing	None (best-effort)
Data Link	Ethernet, Wi-Fi, etc.	Frame delivery over single link	Single-hop error detection
Physical	Cables, radio, etc.	Bit transmission	None

The End-to-End Principle

Connection-Oriented Communication

What does establishing a connection mean?

A TCP connection is a logical relationship between two endpoints that involves:

Agreement on communication parameters—both sides negotiate initial sequence numbers, maximum segment size, window scaling factors, and other options
State synchronization—both endpoints create Transmission Control Blocks (TCBs) containing connection state
Resource allocation—both sides allocate buffers for sending and receiving data
Identity verification—each side confirms it's communicating with the intended peer (though TCP itself doesn't provide cryptographic authentication)

Converting Mermaid diagram...

The Three-Way Handshake

TCP establishes connections using a three-way handshake:

SYN — The client sends a segment with the SYN (synchronize) flag set, along with a randomly chosen Initial Sequence Number (ISN)
SYN-ACK — The server responds with both SYN and ACK flags set, acknowledging the client's ISN and providing its own ISN
ACK — The client acknowledges the server's ISN, completing the handshake

Why three messages instead of two?

Connection Setup Overhead

Connection-Oriented Benefits

•State synchronization — Both endpoints know the connection is operational before sending data
•Parameter negotiation — MSS, window scale, timestamps, and selective acknowledgments can be negotiated
•Resource preparation — Buffers are allocated, ensuring resources are available
•Sequence number initialization — Random ISNs prevent spoofing attacks and old segment confusion
•Path verification — The handshake confirms bidirectional reachability

Reliability Mechanisms

TCP's defining characteristic is reliable delivery. But what exactly does reliability mean, and how does TCP achieve it over an unreliable network?

TCP's reliability guarantees:

No data loss — Every byte sent by the sender will be delivered to the receiver (or an error will be reported)
No duplication — Bytes are delivered exactly once, never duplicated
No corruption — Data arrives exactly as it was sent, with integrity verified
Ordered delivery — Bytes are delivered in the exact order they were sent

These guarantees are maintained even when the underlying network drops packets, delivers them out of order, duplicates them, or corrupts them. Let's examine the mechanisms that make this possible.

TCP Reliability Mechanisms
Problem	Mechanism	How It Works
Packet loss	Retransmission	Sender maintains timers; if ACK doesn't arrive, segment is retransmitted
Out-of-order delivery	Sequence numbers	Each byte has a sequence number; receiver reorders segments
Duplicate packets	Sequence numbers	Receiver detects and discards duplicate segments
Data corruption	Checksum	16-bit checksum covers header and payload; corrupted segments are discarded
Receiver overflow	Flow control	Receiver advertises window size; sender limits outstanding data
Network congestion	Congestion control	Sender adapts rate based on detected congestion

The Acknowledgment and Retransmission Model

Key aspects of TCP's acknowledgment scheme:

Cumulative ACKs — An ACK for byte N means all bytes up to N-1 have been received correctly
Selective Acknowledgments (SACK) — An optional extension allowing receivers to report non-contiguous blocks received
Delayed ACKs — Receivers may delay ACKs to piggyback them on return data
Duplicate ACKs — Three duplicate ACKs trigger fast retransmit without waiting for timeout

Reliability vs. Performance

Byte-Stream Service

TCP provides a byte-stream abstraction to applications—a continuous, ordered stream of bytes, not discrete messages. This is a fundamental design choice with far-reaching implications.

What this means in practice:

The application writes bytes to the send buffer; TCP decides how to segment them
The receiver reads bytes from the receive buffer; message boundaries are not preserved
TCP may combine multiple writes into one segment (coalescing)
TCP may split one write across multiple segments (fragmentation)
The receiver may receive data in different chunks than the sender wrote

Sender Side

•Application calls write() with 1000 bytes
•TCP adds to send buffer
•TCP segments based on MSS and congestion window
•May send as one 1000-byte segment
•Or two 500-byte segments
•Or combine with other writes

Receiver Side

•Application calls read() for 1000 bytes
•May receive 500 bytes (partial read)
•Must call read() again for remaining
•Or may receive 1500 bytes (multiple writes)
•Application must parse byte stream
•Must implement own message framing

The Message Boundary Problem

message_framing.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Length-prefixed message framing example
 
import struct
 
def send_message(sock, message: bytes):
    """Send a message with 4-byte length prefix."""
    # Pack length as 4-byte big-endian integer
    length_prefix = struct.pack('>I', len(message))
    # Send length + message
    sock.sendall(length_prefix + message)
 
def recv_message(sock) -> bytes:
    """Receive a length-prefixed message."""
    # First, read the 4-byte length prefix
    length_data = recv_exactly(sock, 4)
    if not length_data:
        return None
    
    # Unpack the length
    message_length = struct.unpack('>I', length_data)[0]
    
    # Now read exactly that many bytes
    return recv_exactly(sock, message_length)
 
def recv_exactly(sock, n: int) -> bytes:
    """Receive exactly n bytes from socket (handling partial reads)."""
    data = b''
    while len(data) < n:
        chunk = sock.recv(n - len(data))
        if not chunk:
            return None  # Connection closed
        data += chunk
    return data
 
# Usage example
# send_message(sock, b'Hello, World!')
# message = recv_message(sock)  # Returns b'Hello, World!'

Contrast with Message-Oriented Protocols

Full-Duplex Communication

TCP connections are full-duplex, meaning data can flow simultaneously in both directions. Each direction of flow is independent, with its own sequence numbers, acknowledgments, and flow control.

What full-duplex enables:

Either side can send data at any time, without waiting for the other
Acknowledgments can be piggybacked on data flowing in the reverse direction
The connection can be half-closed (one direction terminated while the other remains open)
Applications can implement symmetrical protocols where both sides send and receive

Converting Mermaid diagram...

Independent Sequence Spaces

Each direction of a TCP connection has its own:

Sequence number space — Client-to-server and server-to-client have independent sequence numbers
Acknowledgment tracking — Each side tracks what it has sent and what has been acknowledged
Flow control window — Each receiver advertises its own receive window
Send and receive buffers — Four buffers total: send and receive on each endpoint

Piggybacking

Full-Duplex vs. Half-Duplex vs. Simplex
Mode	Data Flow	Example	TCP Analogy
Simplex	One direction only	Broadcast TV	N/A (TCP doesn't support)
Half-Duplex	Both directions, but alternating	Walkie-talkies	After half-close
Full-Duplex	Both directions simultaneously	Telephone call	Normal TCP connection

Half-Close: Shutdown vs. Close

TCP Segment Structure

TCP Header Fields (20 bytes minimum):

TCP Header Fields
Field	Size	Purpose
Source Port	16 bits	Identifies the sending application
Destination Port	16 bits	Identifies the receiving application
Sequence Number	32 bits	Position of first data byte in stream
Acknowledgment Number	32 bits	Next expected byte from peer
Data Offset	4 bits	Header length in 32-bit words
Reserved	4 bits	Reserved for future use
Flags	8 bits	Control flags (SYN, ACK, FIN, RST, PSH, URG, ECE, CWR)
Window Size	16 bits	Receive window for flow control
Checksum	16 bits	Error detection covering header and data
Urgent Pointer	16 bits	Offset to urgent data (if URG flag set)
Options	Variable	Optional extensions (MSS, SACK, timestamps, etc.)

The Control Flags

TCP's eight flags control connection management and data handling:

SYN — Synchronize sequence numbers (connection establishment)
ACK — Acknowledgment field is valid
FIN — Sender is finished sending (connection termination)
RST — Reset the connection (abort)
PSH — Push data to application immediately (don't buffer)
URG — Urgent pointer field is valid
ECE — ECN-Echo (explicit congestion notification)
CWR — Congestion window reduced

Maximum Segment Size (MSS)

Flow and Congestion Control Overview

Two critical mechanisms prevent TCP from overwhelming either the receiver or the network: flow control and congestion control. While often confused, they serve different purposes.

Flow Control — Protecting the Receiver

The receiver has finite buffer space. If the sender transmits too fast, the receiver's buffer overflows and data is lost. TCP solves this with the sliding window mechanism:

The receiver advertises its available buffer space in the Window Size field
The sender limits its unacknowledged data to this window size
As the receiver processes data and frees buffer space, it advertises a larger window
If the receiver's buffer fills, it advertises window=0, stopping the sender

Congestion Control — Protecting the Network

Slow start — Begin with a small congestion window, grow exponentially
Congestion avoidance — After a threshold, grow linearly
Fast retransmit — Detect loss via duplicate ACKs
Fast recovery — Reduce window without returning to slow start

Flow Control

•Purpose: Prevent receiver overflow
•Signal: Receiver advertises window
•Location: End-to-end (receiver → sender)
•Mechanism: Sliding window
•Response: Stop when window = 0

Congestion Control

•Purpose: Prevent network overload
•Signal: Packet loss, ECN marks
•Location: Sender-side estimation
•Mechanism: AIMD algorithms
•Response: Reduce congestion window

Effective Window

TCP's Strengths and Weaknesses

After four decades of service, TCP's strengths have been proven in production at every scale imaginable. But its weaknesses have also become clear, driving the development of alternative protocols.

Why TCP dominates:

TCP Strengths

•Universal availability — Implemented in every operating system, supported by every network
•Proven reliability — Four decades of testing and refinement
•Automatic congestion response — Plays nicely with other network users
•In-kernel implementation — Highly optimized, zero-copy possible
•Firewall friendly — Stateful inspection is well understood
•Application simplicity — Applications get a simple byte-stream abstraction

TCP Weaknesses

•Connection setup latency — 1-1.5 RTT before data flows
•Head-of-line blocking — One lost segment delays all following data
•Ossification — Middleboxes block TCP extensions, preventing evolution
•No multipath support — TCP ties connections to IP addresses
•Limited congestion control — Can't easily update algorithms
•No message boundaries — Applications must implement framing

Modern Evolution

Summary: TCP at a Glance

TCP is the reliable workhorse of Internet communication. Let's consolidate the key concepts:

Key Takeaways

•TCP provides reliability over unreliable IP — retransmission, ordering, duplicate detection, and integrity checking transform best-effort delivery into guaranteed delivery
•Connection-oriented operation — three-way handshake establishes state before data flows, enabling parameter negotiation and bidirectional verification
•Byte-stream abstraction — TCP delivers a continuous stream of bytes; applications must implement their own message framing
•Full-duplex communication — data flows independently in both directions with separate sequence spaces
•Flow control protects receivers — sliding window prevents buffer overflow
•Congestion control protects networks — AIMD algorithms prevent network collapse
•Universal deployment — TCP works everywhere but evolves slowly due to middlebox ossification

What's next:

Page Complete