Consider a phone conversation. Both parties can speak and listen simultaneously—there's no need to say "over" and wait for a response like with a walkie-talkie. Ideas flow freely in both directions, interruptions are possible, and the conversation feels natural.

TCP works the same way. A single TCP connection provides two independent, simultaneous communication channels—one in each direction. Data can flow from client to server at the same time as data flows from server to client. Neither side needs to wait for the other to finish.

This full-duplex capability is so fundamental that we often take it for granted. But it's not a given—many communication systems are half-duplex (one direction at a time) or simplex (one direction only). TCP's full-duplex design enables efficient, natural communication patterns that match how humans think about conversations.

In this page, we'll explore how TCP implements full-duplex communication: independent sequence spaces, simultaneous data flow, piggybacking, half-close operations, and the impact on protocol design.

Before diving into TCP's full-duplex implementation, let's understand the three communication modes:

Simplex: One Direction Only

Data flows in only one direction, permanently. One side is always the sender; the other is always the receiver.

Examples: Television broadcasting, keyboard input to computer, traditional pager systems.

Half-Duplex: Both Directions, But Not Simultaneously

Data can flow in both directions, but only one direction at a time. When one side transmits, the other must wait.

Examples: Walkie-talkies, traditional Ethernet (CSMA/CD on shared medium), some satellite links.

Full-Duplex: Both Directions Simultaneously

Data flows in both directions at the same time. Both sides can send and receive concurrently.

Examples: Telephone calls, TCP connections, modern full-duplex Ethernet.

TCP is inherently full-duplex.

Every TCP connection supports simultaneous bidirectional data flow from the moment it's established. There's no mode switching, no signaling required, no turn-taking protocol. Both endpoints can write to and read from the connection at any time.

This is not just a convenience—it's an architectural foundation that enables efficient protocol design and matches natural communication patterns.

TCP implements full-duplex by maintaining two completely independent byte streams—one in each direction. Each stream has its own:

• Initial Sequence Number (ISN)
• Current sequence number
• Acknowledgment tracking
• Send and receive buffers
• Window management

When Host A communicates with Host B over TCP, there are actually two logical streams:

1. A → B Stream: Bytes sent from A to B, tracked by A's sequence numbers, acknowledged by B
2. B → A Stream: Bytes sent from B to A, tracked by B's sequence numbers, acknowledged by A

These streams are independent. The sequence numbers for A→B have no relationship to the sequence numbers for B→A.

Each direction is managed independently:

Why independence matters:

This independence is crucial for correct operation:

• B can ACK A's data immediately without having data to send
• A can close its sending direction (send FIN) while still receiving from B
• Congestion in one direction doesn't directly affect the other
• Loss rates may differ between directions (asymmetric paths)

The TCP header structure reflects full-duplex operation. Every segment carries fields for both sending and receiving:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |  ← For THIS segment's data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |  ← For OTHER direction's data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Rsv |  Flags  |          Window Size                  |  ← Receive window for OTHER direction
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key bidirectional fields:

A single segment can carry both data and acknowledgment:

Segment from A to B:
  - Seq=1000, Len=500 → A is sending bytes 1000-1499 to B
  - ACK=2500          → A confirms receipt of B's bytes up to 2499
  - Window=8192       → A has 8KB of receive buffer available

This single segment:
  1. Sends data in the A→B direction
  2. Acknowledges data in the B→A direction
  3. Provides flow control for the B→A direction

This combination is called piggybacking and is a major efficiency gain from full-duplex operation.

Piggybacking is the practice of including ACK information in data-carrying segments, rather than sending separate ACK-only segments. This is a natural consequence of full-duplex operation and provides significant efficiency gains.

Without piggybacking:

A → B: [SEQ=1000, DATA=500 bytes]
B → A: [ACK=1500]                    ← ACK-only segment
B → A: [SEQ=2000, DATA=500 bytes]    ← Data segment

Total segments: 3

With piggybacking:

A → B: [SEQ=1000, DATA=500 bytes]
B → A: [SEQ=2000, ACK=1500, DATA=500 bytes]  ← ACK piggybacked on data

Total segments: 2

Piggybacking saves:

• Segment header overhead (20-60 bytes per saved segment)
• IP header overhead (20+ bytes per saved segment)
• Processing overhead at both endpoints and routers
• Network bandwidth

Delayed ACKs enable piggybacking:

To maximize piggybacking opportunities, TCP uses delayed ACKs: instead of immediately acknowledging received data, the receiver waits briefly (up to 500ms per RFC, typically 40-200ms in practice).

During this delay, if the application generates data to send, the ACK is piggybacked on the outgoing segment. If no data is generated, a standalone ACK is sent after the delay expires.

Delayed ACK rules (RFC 5681):

1. Delay at most one ACK (immediately ACK every second full segment)
2. Maximum delay of 500ms (commonly configured to 40-200ms)
3. Immediately ACK out-of-order segments (to trigger fast retransmit)
4. Immediately ACK segments with PSH flag (application requested push)

Full-duplex means both directions can carry data at the exact same time. This isn't just alternating quickly—it's true simultaneous transmission.

How is this possible?

At the physical layer, modern networks (like Ethernet with full-duplex switches) can transmit and receive simultaneously on separate wire pairs or frequencies. At the TCP layer, each host can:

• Write data to the send buffer at any time
• Read data from the receive buffer at any time
• Have multiple segments in flight in each direction
• Process incoming and outgoing data independently

Timeline of simultaneous transmission:

Why this matters for applications:

1. Request streaming: A client can start sending a large upload while the server is still sending results from a previous request

2. Bidirectional protocols: WebSocket, gRPC streaming, and other protocols leverage full-duplex for natural bidirectional communication

3. No artificial latency: Unlike half-duplex, there's no overhead from direction switching

4. Efficient bulk transfers: Both directions can saturate available bandwidth simultaneously

Because TCP's two directions are independent, each can be closed separately. This is called half-close: one side finishes sending while the other continues.

How half-close works:

1. Host A finishes sending data and sends a FIN (finish) segment
2. Host B acknowledges the FIN—A's sending direction is now closed
3. But B→A direction remains open; B can continue sending
4. When B finishes, B sends its own FIN
5. A acknowledges; now the connection is fully closed

During the half-closed state:

• A cannot send more data (it has sent FIN)
• A can still receive data from B
• B can send data to A
• B cannot receive more data from A (A is done)

Use cases for half-close:

1. Signaling end of input: A client sends a query, then uses shutdown(SHUT_WR) to signal "I'm done." The server knows no more requests are coming and can send a complete response without waiting.

2. Streaming responses: The client sends a short request, then closes its send side. The server streams a large response (video, large dataset) while the client consumes it.

3. rsh/rlogin protocols: Historic remote shell protocols used half-close to signal end of stdin while keeping stdout/stderr open.

API for half-close:

// Close only the write side (send FIN)
shutdown(socket, SHUT_WR);  // Can still read

// Close only the read side (less common)
shutdown(socket, SHUT_RD);  // Can still write

// Close both (equivalent to close)
shutdown(socket, SHUT_RDWR);

// close() closes both directions and the socket
close(socket);

Each direction has independent flow control. Host A's receive window controls B→A data; Host B's receive window controls A→B data.

Why independent flow control?

The two directions may have completely different characteristics:

• Asymmetric data transfer: A downloads a 1GB file from B, but only sends acknowledgments back. A needs a large receive buffer; its send buffer can be small.

• Asymmetric processing: A sends data quickly, but B's application is slow to read. B's receive window shrinks; A must slow down. Meanwhile, B might have a large window for A.

• Asymmetric network: The path from A to B might have different bandwidth than B to A (common with cable/DSL).

Window Advertisement in Each Direction:

Segment from A to B:
  Window field = A's receive window (for B→A data)
  "I can accept X more bytes from you"

Segment from B to A:
  Window field = B's receive window (for A→B data)  
  "I can accept Y more bytes from you"

The window field always advertises the sender's incoming capacity, which controls the outgoing rate of the remote host.

Zero window in one direction:

If B's receive buffer fills (slow application), B advertises rwnd=0. A stops sending data (A→B is paused). But B→A can continue normally—B can still send, and A's window is unaffected.

Application protocols can leverage full-duplex in different ways. Understanding these patterns helps in protocol design and implementation.

Pattern 1: Request-Response (Underutilizes Full-Duplex)

Classic HTTP/1.x: client sends request, waits, server sends response. This is essentially half-duplex usage of a full-duplex channel.

Client → Server: Request
Client waits...
Server → Client: Response
Client sends next request...

Pattern 2: Pipelining (Better Utilization)

HTTP/1.1 pipelining: client sends multiple requests without waiting. Still request-response, but overlapped.

Client → Server: Request 1
Client → Server: Request 2
Client → Server: Request 3
Server → Client: Response 1
Server → Client: Response 2
Server → Client: Response 3

Pattern 3: Multiplexing (HTTP/2)

Multiple independent streams interleaved on one connection. Both directions carry frames for multiple streams.

Client → Server: [Stream 1 headers]
Client → Server: [Stream 2 headers]
Server → Client: [Stream 1 headers]
Client → Server: [Stream 1 data]
Server → Client: [Stream 2 headers]
Server → Client: [Stream 1 data]
...

Pattern 4: True Bidirectional (Full Utilization)

WebSocket, gRPC streaming: both sides send whenever they want, independently.

Client → Server: Message A
Server → Client: Message 1
Client → Server: Message B  } These can happen
Server → Client: Message 2  } simultaneously
Server → Client: Message 3
Client → Server: Message C

TCP's full-duplex capability transforms a single connection into two independent communication channels. Let's consolidate what we've learned:

Module Complete:

With this page, we've covered all five fundamental characteristics of TCP:

1. TCP Characteristics — The overall properties that define TCP
2. Connection-Oriented — State management and the three-way handshake
3. Reliable Delivery — Sequence numbers, ACKs, and retransmission
4. Ordered Delivery — Sequence-based reassembly and receive buffering
5. Full-Duplex — Independent bidirectional communication

These characteristics form the foundation for everything else in TCP. The next modules will build on this foundation, exploring sequence numbers in depth, header format details, the three-way handshake, state diagrams, and connection termination.