Introduction: TCP as a Reliable Byte Stream
Transport protocols give applications different delivery services. User Datagram Protocol (UDP) sends independent datagrams with low protocol overhead, but it does not provide TCP's retransmission, ordering, or connection state. A datagram can be lost, damaged, duplicated, or delivered out of order, so an application using UDP must handle any required recovery itself.
The Transmission Control Protocol (TCP) provides a connection-oriented byte stream. In an ordinary connection, endpoints first exchange control segments, then use sequence numbers, acknowledgments, checksums, retransmission, and flow control while data is exchanged. Each direction can be closed independently, and an endpoint can abort the connection when an error requires it.
TCP is one of the main protocols in the . Its role is to provide a reliable, ordered, error-checked byte stream between applications on hosts communicating over IP. IP forwards packets toward a host; TCP demultiplexes the stream to an application using ports and delivers bytes in order when the connection remains usable. TCP does not preserve application message boundaries, and a failed connection can end before all requested data is delivered. The application must frame its own messages and decide how to handle an end-of-stream or connection error. TCP also does not guarantee a particular throughput or latency, because those depend on the path, endpoint resources, and congestion-control state.
Core Characteristics of TCP
TCP behavior follows several principles that define its transport service.
- Connection-Oriented
For an ordinary TCP connection, endpoints establish connection state before sending application data. This is a logical association identified by the local and remote addresses and ports, not a dedicated physical circuit. The three-way handshake exchanges initial sequence information and confirms reachability in both directions. Both endpoints then retain state for sequence validation, acknowledgments, flow control, and timers. The association is local to the two endpoint implementations; routers forward IP packets without maintaining the TCP connection state. TCP Fast Open can change when application data is sent, but the connection still uses TCP state and sequence validation.
- Reliable Delivery
TCP can recover from ordinary loss and reject corrupted segments while the connection remains active. Its reliability uses several mechanisms. A checksum detects corruption, while ACKs and retransmission deal with missing ranges. If recovery cannot complete, TCP reports an error or closes the connection, so reliability is a protocol service with defined failure cases, not a promise of delivery under every network condition:
- Sequence Numbers: TCP assigns sequence numbers to the bytes in each direction. The numbers identify a byte range and support duplicate detection and reassembly.
- Acknowledgments (ACKs): The receiver acknowledges the next sequence number it expects. A cumulative ACK can therefore confirm a contiguous range of bytes and leave a missing range unacknowledged.
- Checksum: Each TCP segment includes a checksum computed over the TCP header, data, and a pseudo-header. If validation fails, the receiver discards the segment; later acknowledgments or a timer can cause retransmission.
- Ordered Data Stream
IP can deliver TCP segments out of order. TCP uses sequence numbers to reassemble a contiguous byte stream before making it available to the application. For example, segments carrying ranges corresponding to 1, 2, 5, 4, and 3 can be buffered and presented in order after the missing ranges arrive. The application receives bytes in sequence; it does not receive the original message boundaries.
- Full-Duplex Communication
A TCP connection is full-duplex: each endpoint can send and receive bytes simultaneously over the same connection. The two directions have separate sequence spaces, acknowledgments, and flow-control windows. A FIN closes one direction, so the other direction can remain open during an orderly half-close.
Establishing a Connection: The Three-Way Handshake
The process of creating a TCP connection is the three-way handshake. It exchanges initial sequence information and lets each endpoint confirm that the peer can receive and acknowledge control segments. The SYN and SYN-ACK also consume sequence numbers, which is why the acknowledgment values in the example increase by one. A listener can reject a request, remain silent, or use a SYN-cookie policy when pending state is under pressure.
Consider a client such as a browser connecting to a listening web server. The sequence values are illustrative.
- Step 1: The Client Sends a SYN Packet
The client sends a TCP segment with the SYN (Synchronize) flag set to 1. Along with the SYN, it sends an . For this example, use SEQ=100; the value is illustrative, not a fixed TCP constant.
- Step 2: The Server Responds with a SYN-ACK Packet
If an application is listening on the destination port, the server processes the client's SYN and responds with a segment that has two flags set:
- The SYN flag is set to 1, and the server sends its own ISN, represented here as SEQ=300.
- The ACK (Acknowledgment) flag is set to 1. The acknowledgment number is the client's ISN plus one, so the example uses ACK=101.
The server has acknowledged the client's initial sequence value and supplied its own. The actual values are generated by the endpoints and are not fixed at 100 or 300.
- Step 3: The Client Acknowledges the Server's Response
The client receives the SYN-ACK and sends a segment with the ACK flag set to 1. Its acknowledgment number is the server's ISN plus one, represented as ACK=301 in the example. This segment does not need SYN because both initial sequence values have been exchanged.
After the final ACK, both endpoints can enter ESTABLISHED and send application bytes. TCP provides a byte stream; the application protocol determines how those bytes form requests or messages.
Terminating a Connection: The Four-Way Handshake
An orderly close shuts down the two full-duplex directions independently. A typical exchange uses four control segments, but simultaneous close and abort with RST follow different transitions. FIN indicates that an endpoint has no more bytes to send in its direction; it does not discard data already delivered to TCP. The receiving application can observe end-of-stream for that direction while the opposite direction remains usable. TIME-WAIT belongs to the active closer and protects the old connection tuple from delayed duplicates.
In this example, the client initiates the orderly close:
- Step 1: The Client Sends a FIN Packet
After finishing its data, the client sends a TCP segment with the FIN (Finish) flag set. This signals that the client has closed its sending direction.
- Step 2: The Server Acknowledges the FIN
The server receives FIN and sends an ACK. The server will receive no more bytes from the client, but it may still send its remaining data. The connection is half-closed in the client-to-server direction.
- Step 3: The Server Sends Its Own FIN Packet
After the server finishes its remaining data, it sends its own FIN, closing the server-to-client direction.
- Step 4: The Client Acknowledges the Server's FIN
The client receives the server's FIN and sends the final ACK. The active closer then enters TIME-WAIT for 2MSL, allowing a retransmitted FIN to be acknowledged and old duplicates to expire under TCP rules. The server can enter CLOSED after receiving the final ACK.
Managing Data Flow: Flow Control and Congestion Control
TCP limits outstanding data using separate receiver and network signals. Flow control protects the receiver's buffer, while congestion control responds to the condition of the shared network path.
Flow Control: Protecting the Receiver
Flow control prevents a fast sender from exceeding a slower receiver's available buffer. Each TCP connection has receive-buffer space for data that has arrived before the application reads it.
The TCP header includes a 16-bit Window Size field. The receiver advertises available buffer space; a busy receiver can advertise a smaller value. The sender limits unacknowledged bytes to the advertised receive window. The window-scale option extends the effective range beyond the unscaled 16-bit field. A zero window stops new data, while the persistence mechanism can probe for a later update. This mechanism adapts the byte rate to the receiver's capacity.
Congestion Control: Protecting the Network
While flow control protects the receiver, congestion control protects the shared path. If many senders transmit at high rates, queues in intermediate routers can fill, causing congestion, loss, and delay.
TCP maintains a Congestion Window (cwnd)that limits data in flight based on the sender's congestion estimate. The usable limit is the smaller of cwnd and the receiver's advertised window. Slow start, congestion avoidance, fast retransmit, and fast recovery adjust cwnd in response to acknowledgments and loss; ECN can also signal congestion. A loss is commonly treated as a congestion signal, so the sender reduces its sending rate and then increases it cautiously according to the congestion-control algorithm in use. The exact response can vary with the standardized congestion-control update in use, and the receiver window can remain the limiting value even when the path has capacity.