When an application sends data across a network, it cannot assume that every packet will arrive intact, in order, or at all. IP can move packets between hosts, but it does not by itself provide the application with a reliable byte stream.
TCP is the transport protocol designed to solve that problem. It establishes a connection between two endpoints, numbers the data, acknowledges what has been received, retransmits data when necessary, and regulates how much can be sent at once.
For a server administrator, understanding TCP explains a large part of what happens between an application and a remote service: why a connection can be established, why it can stall, what retransmissions mean, and why a service can be listening but still fail to communicate normally.
TCP (Transmission Control Protocol) is a connection-oriented transport protocol that provides applications with a reliable, ordered byte stream between two endpoints.
It does this by establishing a connection, assigning sequence numbers to transmitted data, using acknowledgments to track received data, retransmitting data when loss is detected, and using flow and congestion control to avoid overwhelming the receiver or network.
- What TCP does and where it fits in network communication.
- How a TCP connection is established with the three-way handshake.
- Why sequence numbers and acknowledgments are essential.
- How TCP handles lost or duplicated data.
- What flow control and congestion control mean.
- How TCP connections are normally closed.
- How to observe TCP connections on a Linux server.
- 🌐 What Is TCP?
- IP
- TCP
- Application
- 🔗 Why Does TCP Need a Connection?
- 🤝 How the TCP Three-Way Handshake Works
- Client sends SYN
- Server sends SYN-ACK
- Client sends ACK
- 🔢 Sequence Numbers: How TCP Keeps Data in Order
- ✅ Acknowledgments: How TCP Knows What Arrived
- 🔄 What Happens When a TCP Segment Is Lost?
- Data is transmitted
- A segment is lost
- The sender detects a delivery problem
- The missing data can be retransmitted
- 📊 Flow Control: Don’t Overrun the Receiver
- 🚦 Congestion Control: Don’t Overload the Network
- 🧩 What Is Inside a TCP Segment?
- Sequence Number
- Acknowledgment Number
- Control Flags
- 🔌 TCP and Ports: How Applications Find Each Other
- 🔒 TCP Does Not Encrypt Your Data
- ⏹️ How Does a TCP Connection Close?
- 🧪 Mini Lab: Observe TCP Connections on Linux
- ⚠️ Common Mistakes
- 💡 Practical Notes for Server Administrators
- 📌 TCP in One Mental Model
🌐 What Is TCP?
TCP stands for Transmission Control Protocol. It operates at the transport layer of the Internet protocol suite and provides communication between applications running on different hosts.
The important distinction is between IP delivery and TCP communication.
IP provides addressing and packet delivery across interconnected networks. TCP sits above IP and gives an application a more useful abstraction: a reliable, ordered stream of bytes between two endpoints.
IP
Provides addressing and packet delivery between networked hosts.
TCP
Provides connection management, ordering, acknowledgments, retransmission, and flow control.
Application
Uses the TCP connection to exchange application data without managing individual network packets itself.
TCP does not guarantee that a network path itself is reliable. Instead, it detects problems that matter to the TCP connection and takes steps to recover from them where possible.
Think of TCP as a coordination layer between an application and an unreliable packet network. The application sees an ordered stream; TCP handles much of the work required to make that stream possible.
🔗 Why Does TCP Need a Connection?
Before two TCP endpoints exchange normal application data, they establish a connection and synchronize important state.
This state includes sequence-number information used to identify data and acknowledgment information used to track what has been received.
TCP therefore behaves differently from a simple protocol that sends an independent packet for every application message. A TCP connection has a lifecycle: it is established, used for data transfer, and eventually closed or aborted.
The word connection does not mean that a dedicated physical circuit has been created between the two machines. It means that the TCP endpoints maintain state describing the communication relationship.
🤝 How the TCP Three-Way Handshake Works
A TCP connection normally begins with a three-way handshake. Its purpose is to synchronize the initial sequence-number state of both endpoints and establish the connection.
Client sends SYN
The initiating endpoint sends a TCP segment with the SYN control flag. It includes the initial sequence number chosen for that side of the connection.
Server sends SYN-ACK
The other endpoint responds with its own SYN and acknowledges the sequence-number information received from the first endpoint.
Client sends ACK
The initiating endpoint acknowledges the server’s SYN. At this point, both sides have synchronized the connection state and can exchange application data.
The handshake is more than a formal ritual. TCP needs both endpoints to confirm the other’s initial sequence-number information. The three messages allow each side to establish synchronized state before normal data transfer begins.
TCP’s three-way handshake does not mean that the application has already completed its request. The handshake establishes the TCP connection. The application protocol still has to exchange its own data afterward. For example, an HTTP request is application data carried over an established transport connection.
🔢 Sequence Numbers: How TCP Keeps Data in Order
One of TCP’s most important ideas is that transmitted data is associated with sequence numbers.
Imagine an application produces a continuous stream of bytes. TCP divides that stream into segments for transmission. Sequence numbers allow the receiving endpoint to determine where each piece belongs in the overall stream.
This matters because packets do not have to arrive in the same order in which they were sent. A later segment can potentially arrive before an earlier one.
TCP can therefore recognize that data has arrived out of order and use the sequence information to reconstruct the correct byte stream before delivering it to the application.
✅ Acknowledgments: How TCP Knows What Arrived
TCP also uses acknowledgments, commonly called ACKs, to communicate what data the receiving endpoint expects next.
An acknowledgment is not simply a message saying “this particular packet arrived.” TCP acknowledgments are cumulative. An acknowledgment value indicates the next sequence number expected, which means that data before that point has been received in the relevant sequence.
This gives the sender information about the receiver’s progress.
For example, if a receiver acknowledges that it expects sequence number N next, the sender can interpret that acknowledgment as confirmation that the preceding sequence space has been received.
This mechanism is fundamental to TCP’s ability to detect missing data and manage the amount of outstanding unacknowledged data.
🔄 What Happens When a TCP Segment Is Lost?
Networks can lose packets. Congestion, errors, routing changes, or other network conditions can prevent a transmitted segment from reaching its destination.
TCP is designed to recover from data loss by retransmitting data that has not been successfully acknowledged.
Data is transmitted
The sender transmits TCP data with sequence information.
A segment is lost
The receiver never obtains one part of the expected byte stream.
The sender detects a delivery problem
TCP uses acknowledgments and loss-detection mechanisms to determine that expected data has not been successfully acknowledged.
The missing data can be retransmitted
TCP retransmits data that needs to be delivered again. The receiver uses sequence numbers to recognize where that data belongs and to handle duplicates correctly.
The important concept is that TCP does not make the network lossless. It provides mechanisms that allow a connection to recover from certain kinds of loss.
📊 Flow Control: Don’t Overrun the Receiver
Imagine a fast sender communicating with a receiver that temporarily has less capacity to accept incoming data. Simply sending as quickly as possible could overwhelm the receiver’s available receive buffer.
TCP addresses this with flow control.
The receiver advertises a receive window that represents how much additional data it is prepared to accept. The sender uses that information when deciding how much data can be outstanding without waiting for further acknowledgments.
This creates a feedback relationship:
Flow control is about the receiver’s capacity. It should not be confused with congestion control, which deals with conditions in the network itself.
🚦 Congestion Control: Don’t Overload the Network
A TCP sender also needs to consider the network path between the endpoints.
A network can become congested when traffic demand exceeds available capacity. TCP therefore includes congestion-control behavior that limits how aggressively a connection sends data and responds to signs of congestion.
Modern TCP implementations use congestion-control algorithms and loss-detection mechanisms that are specified across multiple IETF documents. The exact behavior can vary between implementations and algorithms.
| Mechanism | Main question | What it protects |
|---|---|---|
| Sequence numbers | Where does this data belong? | Ordering and duplicate detection |
| Acknowledgments | What data has been received? | Delivery tracking |
| Retransmission | What if data was lost? | Recovery from loss |
| Flow control | How much can the receiver accept? | Receiver capacity |
| Congestion control | How aggressively should we send? | Network capacity |
A useful mental model is to separate receiver pressure from network pressure. Flow control prevents a sender from overwhelming the receiver. Congestion control helps prevent the sender from contributing excessively to network congestion.
🧩 What Is Inside a TCP Segment?
TCP communicates using segments. A TCP segment contains a header followed by optional application data.
The header contains information that TCP needs to manage the connection, including source and destination ports, sequence and acknowledgment numbers, control flags, a receive window, and a checksum. TCP options may also be present.
Sequence Number
Identifies the position of data in the TCP byte stream.
Acknowledgment Number
Indicates the next sequence number the receiver expects when an acknowledgment is present.
Control Flags
Flags such as SYN, ACK, FIN, and RST help manage the TCP connection state.
You do not normally manipulate these fields directly when running a server application. The operating system’s TCP implementation manages them on behalf of applications.
🔌 TCP and Ports: How Applications Find Each Other
IP addresses identify network endpoints, but a server can run many networked applications at the same time.
TCP therefore works with port numbers. A TCP connection has a local endpoint and a remote endpoint, with each endpoint associated with an IP address and port.
This is why a client can communicate with a particular service on a server rather than merely reaching the machine as a whole.
For example, a browser can establish a TCP connection to a web service while another application on the same server maintains its own TCP connection. The operating system uses the endpoint information to associate incoming traffic with the appropriate socket and application.
🔒 TCP Does Not Encrypt Your Data
TCP provides reliable transport behavior, but it does not provide encryption or application-level authentication.
If an application needs confidentiality and cryptographic protection, another protocol can operate above TCP. TLS is a common example. In a typical HTTPS connection, TCP provides the transport connection while TLS provides cryptographic protection for the application protocol carried through it.
“TCP is secure because it is reliable” is incorrect. Reliability and security are different properties. TCP can help deliver data reliably, but it does not by itself encrypt the application data or prove the identity of the remote application.
⏹️ How Does a TCP Connection Close?
A TCP connection is not normally closed simply by one side disappearing. TCP has an orderly close procedure that uses the FIN control flag.
The two directions of a TCP connection are managed independently, so closing one direction does not necessarily mean that the other direction has stopped immediately.
In a normal close, one endpoint indicates that it has no more data to send. The other endpoint acknowledges this and can eventually close its own sending direction as well.
TCP also supports an abortive termination using RST. A reset indicates that the connection is being terminated abruptly rather than following the normal graceful close sequence.
The exact TCP state transitions are more detailed than this simplified model, but the important lesson is that connection termination is itself part of TCP’s protocol state.
🧪 Mini Lab: Observe TCP Connections on Linux
See TCP connections maintained by your Linux system and identify their states without changing the system.
The following command asks the Linux socket utility to show TCP sockets:
ss -tanLook at columns such as the TCP state, local address, and peer address. You may see states such as LISTEN, ESTABLISHED, or other TCP connection states depending on what is happening on the machine.
If your system has curl installed, you can make a normal HTTPS request to the documentation domain used below:
curl -v https://example.comThe verbose output shows connection-related information before the HTTP exchange. The exact output varies by operating system, curl version, network configuration, and the remote service.
The key concept is the separation of layers: DNS can resolve a name, TCP can establish a transport connection, TLS can protect the connection, and HTTP can exchange application data.
The lab is read-only from the server’s perspective. The commands do not modify network configuration or TCP settings.
⚠️ Common Mistakes
TCP cannot control the physical network or prevent packet loss. It provides mechanisms for detecting and recovering from loss at the transport layer when recovery is possible.
TCP provides a byte stream. Applications decide how their own messages are structured. A single application message may be transferred using multiple TCP segments, and TCP may combine data from multiple application writes.
The handshake establishes the TCP connection. Once established, application data can flow over that connection without repeating the initial handshake for every segment.
Reliability and latency are different properties. Retransmission can help recover from loss, but recovering from loss can also add delay.
Flow control concerns the receiver’s ability to accept data. Congestion control concerns conditions in the network path and how aggressively a sender should transmit.
TCP handles transport reliability and connection state. Encryption and authentication require other mechanisms, such as TLS, when the application protocol needs them.
💡 Practical Notes for Server Administrators
TCP problems become much easier to investigate once you separate the stages of communication.
- Can the name be resolved? This is a DNS question.
- Can the destination be reached? This involves IP routing and network connectivity.
- Can a TCP connection be established? Now you are investigating the transport layer and the service endpoint.
- Does the application respond correctly? This moves into the application protocol.
That separation prevents a common troubleshooting mistake: treating every connection failure as a generic “network problem.” Different layers can fail for different reasons.
When a server administrator sees ESTABLISHED in a socket listing, it means the operating system has an established TCP connection. It does not prove that the application protocol is healthy, responsive, authenticated, or returning the expected content.
📌 TCP in One Mental Model
You can remember TCP as a sequence of responsibilities rather than a list of packet flags:
Establish creates synchronized connection state. Number keeps the byte stream ordered. Acknowledge tracks received data. Recover handles certain losses through retransmission. Control manages receiver and network conditions. Close ends the connection in an orderly way when possible.
- Why does TCP use a three-way handshake instead of immediately sending normal application data?
- What problem do TCP sequence numbers solve?
- If a TCP segment is lost, how can TCP recover from the loss?
- What is the difference between TCP flow control and congestion control?
- Why does TCP provide a byte stream rather than preserving application message boundaries?
- Does an established TCP connection mean that the application itself is healthy?
🎓 Check Your Answers
- The three-way handshake allows both TCP endpoints to synchronize their initial sequence-number state and acknowledge that synchronization. The connection is therefore established before normal data transfer begins.
- Sequence numbers identify positions within the TCP byte stream. They allow the receiver to place data in the correct order, detect duplicates, and help the sender determine which transmitted data has been acknowledged.
- TCP can retransmit data that has not been successfully acknowledged. The receiver’s sequence and acknowledgment information gives the sender feedback about the progress of the byte stream and helps TCP detect delivery problems.
- Flow control protects the receiver by limiting how much unacknowledged data the sender can have outstanding according to the receiver’s advertised capacity. Congestion control deals with conditions in the network and regulates how aggressively TCP sends traffic.
- TCP is designed as a continuous ordered byte stream. It does not preserve the boundaries created by individual application writes. The application protocol is responsible for defining how its own messages are delimited or framed.
- No. An established TCP connection confirms transport-layer connection state, not application health. The application can still be stalled, overloaded, misconfigured, or returning incorrect responses while the TCP connection remains established.
TCP is the transport layer that gives applications an ordered, reliable byte stream over an underlying packet network that can lose or reorder data.
Its core mechanisms work together: the handshake establishes shared state, sequence numbers preserve ordering, acknowledgments track progress, retransmission handles loss, flow control protects the receiver, and congestion control responds to network conditions.
Once you understand those responsibilities, TCP stops looking like a collection of mysterious flags and starts looking like a coordinated system for moving application data between two endpoints.
