TCP Connection — Three-Way Handshaking
TCP Connection Establishment — Three-Way Handshaking
TCP is a connection-oriented protocol. Before any application data is exchanged, the two TCP endpoints must establish a logical connection.
The connection establishment process is called three-way handshaking.
A useful way to understand it is:
SYN → SYN + ACK → ACK
The three messages synchronize the sequence numbers in both directions and confirm that both sides are ready for communication.
1. Why does TCP need connection establishment?
TCP provides full-duplex communication, meaning both sides can send data simultaneously.
Therefore, before data transfer begins, both TCP endpoints need to:
- agree to establish a connection,
- synchronize their sequence numbers,
- acknowledge each other's initial sequence number,
- communicate the receiver's available window size.
TCP creates a logical connection, not a physical connection.
The underlying IP protocol remains connectionless. IP simply delivers individual TCP segments.
Application ↓ TCP ←── Logical TCP connection ──→ TCP ↓ ↓ IP IP
If a TCP segment is lost, corrupted, or arrives out of order, TCP handles the problem. IP itself is not aware of these TCP-level operations.
2. Passive Open and Active Open
The connection establishment starts with the two applications taking different roles.
Server — Passive Open
The server application tells its TCP:
"I am ready to accept a connection."
This is called a passive open.
The server TCP waits for connection requests.
Client — Active Open
The client application wants to communicate with the server and tells its TCP:
"Connect me to this server."
This is called an active open.
TCP then starts the three-way handshake.
3. Three Steps of the TCP Handshake
The three steps are:
Client Server | | | ----------- SYN ------------------------> | | | | <-------- SYN + ACK -------------------- | | | | ----------- ACK ------------------------> | | | | Connection Established |
Let's examine each step carefully.
Step 1: Client Sends SYN
The client sends the first TCP segment.
Only the SYN flag is set.
Client → Server SYN = 1 SEQ = x
Here, x is the client's Initial Sequence Number (ISN).
For example:
SEQ = 8000
The client is essentially saying:
"I want to establish a connection. My initial sequence number is 8000."
Why is the SYN flag used?
SYN means Synchronize.
It is used to synchronize the sequence numbers of the two TCP endpoints.
Does the SYN segment carry data?
No.
The SYN segment is a control segment and normally carries no application data.
However, it consumes one sequence number.
For example:
SYN SEQ = 8000
After sending it, the next sequence number becomes:
8001
The textbook describes this by saying that the SYN segment carries one imaginary byte.
So:
SYN → consumes 1 sequence number
Does the first SYN contain an acknowledgment number?
No.
The first SYN does not acknowledge anything because the client has not yet received a segment from the server.
Therefore, the acknowledgment field is not meaningful at this point.
Step 2: Server Sends SYN + ACK
The server receives the client's SYN.
The server responds with a segment in which two flags are set:
SYN = 1 ACK = 1
This is called a SYN + ACK segment.
For example:
Server → Client SEQ = 15000 ACK = 8001 SYN = 1 ACK = 1
This segment performs two jobs simultaneously.
Job 1: Acknowledge the client's SYN
The server received:
Client SYN SEQ = 8000
Because a SYN consumes one sequence number, the next sequence number expected from the client is:
8001
Therefore, the server sends:
ACK = 8001
This means:
"I received your SYN with sequence number 8000, and I expect 8001 next."
Job 2: Synchronize the server's sequence number
The server also needs to establish its own initial sequence number.
Suppose the server chooses:
SEQ = 15000
The server is therefore saying:
"My initial sequence number is 15000."
So the SYN + ACK simultaneously:
- acknowledges the client's SYN,
- sends the server's own SYN.
Does SYN + ACK consume a sequence number?
Yes.
The SYN + ACK is a control segment containing a SYN, so it consumes one sequence number.
Therefore:
Server SYN sequence number = 15000 Next server sequence number = 15001
Again, it can be thought of as carrying one imaginary byte.
Receive Window
Because this segment contains an acknowledgment, the server can also advertise its receive window (rwnd).
For example:
SEQ = 15000 ACK = 8001 rwnd = 5000
This tells the client how much data the server is currently prepared to receive.
This is important for TCP flow control.
Step 3: Client Sends ACK
The client receives the server's SYN + ACK.
The client now sends the third segment.
This is an ACK segment.
Client → Server ACK = 15001
The client is acknowledging the server's SYN.
The server's SYN had:
SEQ = 15000
Since SYN consumes one sequence number, the next expected sequence number from the server is:
15001
Therefore:
ACK = 15001
This means:
"I received your SYN with sequence number 15000. I expect 15001 next."
Complete Example
Consider the following values:
- Client ISN = 8000
- Server ISN = 15000
The handshake becomes:
CLIENT SERVER | | | | | SYN | | SEQ = 8000 | |----------------------------->| | | | | | SYN + ACK | | SEQ = 15000 | | ACK = 8001 | |<-----------------------------| | | | | | ACK | | ACK = 15001 | |----------------------------->| | | | | | CONNECTION ESTABLISHED | |<============================>|
Understanding the Sequence and ACK Numbers
This is the most important part of the handshake.
First segment
Client → Server SYN SEQ = 8000
The SYN consumes one sequence number.
Therefore:
Next expected client sequence = 8001
The server responds:
ACK = 8001
Second segment
Server → Client SYN + ACK SEQ = 15000 ACK = 8001
The server's SYN consumes one sequence number.
Therefore:
Next expected server sequence = 15001
The client responds:
ACK = 15001
Why Three Messages Are Necessary
You might ask: why can't TCP establish the connection using only two messages?
Because both sides need to synchronize their sequence numbers and confirm that communication works in both directions.
The three messages accomplish:
| Step | Sender | Purpose |
|---|---|---|
| 1 | Client | Requests connection and sends client ISN |
| 2 | Server | Acknowledges client ISN and sends server ISN |
| 3 | Client | Acknowledges server ISN |
Therefore:
SYN ↓ Client's sequence number known to server SYN + ACK ↓ Server's sequence number known to client Client's SYN acknowledged ACK ↓ Server's SYN acknowledged
Now both sides have synchronized sequence numbers.
Important Point: SYN and ACK Sequence Consumption
A common source of confusion is whether control segments consume sequence numbers.
SYN
A SYN segment carries no data but consumes one sequence number.
SYN SEQ = 8000 ↓ Next = 8001
SYN + ACK
A SYN + ACK segment also carries no data but consumes one sequence number.
SYN + ACK SEQ = 15000 ↓ Next = 15001
Pure ACK
A pure ACK that carries no data consumes no sequence number.
ACK ACK = 15001 No data → No sequence number consumed
Can the Third ACK Carry Data?
Yes.
Some implementations allow the third segment to carry the first chunk of data from the client.
In that case:
ACK + Data
is sent.
Since it contains data, the segment consumes sequence numbers corresponding to the number of data bytes carried.
So the third segment is normally a pure ACK, but it can also carry data in some implementations.
Complete Handshake with Window Information
A simplified example similar to the textbook can be represented as:
Client Server | | | SYN | | SEQ = 8000 | |------------------------------------------>| | | | SYN + ACK | | SEQ = 15000 | | ACK = 8001 | | rwnd = 5000 | |<------------------------------------------| | | | ACK | | ACK = 15001 | | rwnd = 10000 | |------------------------------------------>| | | | TCP CONNECTION ESTABLISHED | | |
The exact window values are examples; their purpose is to show that the receiver can advertise its available receiving capacity during the handshake.
What Happens After the Handshake?
Once the third ACK has been received, the TCP connection is established.
Now bidirectional data transfer can begin.
Client Server | | | SYN | |------------------------------------------>| | | | SYN + ACK | |<------------------------------------------| | | | ACK | |------------------------------------------>| | | |=========== DATA TRANSFER ===============>| |<========== DATA TRANSFER ================| | |
TCP can now use:
- sequence numbers,
- acknowledgment numbers,
- sliding windows,
- retransmissions,
- checksums,
- flow control,
- congestion control,
- piggybacking.
TCP Connection Termination
TCP is a connection-oriented, full-duplex protocol. After data transfer is completed, the connection must be terminated properly.
Either the client or the server can initiate connection termination, although it is commonly initiated by the client.
TCP implementations support two approaches:
- Three-way handshaking
- Four-way handshaking with a half-close option
Here we focus first on the three-way handshaking described in the text.
1. Three-Way Handshaking for Connection Termination
The basic sequence is:
FIN → FIN + ACK → ACK
Suppose the client initiates the termination.
Client Server | | | FIN | |------------------------------------------>| | | | FIN + ACK | |<------------------------------------------| | | | ACK | |------------------------------------------>| | | | Connection terminated |
Let's understand each step.
Step 1: Client Sends FIN
When the client application finishes its communication, it gives a close command to the client TCP.
The client TCP sends a segment with the FIN flag set.
Client → Server FIN = 1 SEQ = x
The FIN segment may:
- contain the last chunk of data, or
- contain only control information.
If the FIN segment contains no data, it consumes one sequence number because it needs to be acknowledged.
For example:
FIN SEQ = x
The next sequence number will therefore be:
x + 1
The FIN essentially tells the server:
"I have finished sending data."
Importantly, this closes the client-to-server direction. It does not necessarily mean that the server must stop sending data immediately.
Step 2: Server Sends FIN + ACK
The server TCP receives the client's FIN.
The server:
- informs the server application about the request to close, and
- sends a FIN + ACK segment.
The segment performs two functions simultaneously:
- ACK → acknowledges the client's FIN.
- FIN → announces that the server also wants to close its direction of the connection.
For example:
Server → Client FIN = 1 ACK = 1 SEQ = y ACK = x + 1
The ACK = x + 1 acknowledges the client's FIN.
The server's FIN has sequence number y.
If this FIN + ACK segment contains no data, it consumes one sequence number.
Therefore:
Server FIN SEQ = y Next expected server sequence = y + 1
Step 3: Client Sends ACK
The client receives the server's FIN + ACK.
The client sends the final ACK.
Client → Server ACK = 1 ACK number = y + 1
The acknowledgment number is:
because the server's FIN had sequence number y, and a FIN consumes one sequence number.
The final ACK:
- confirms receipt of the server's FIN,
- normally carries no data,
- consumes no sequence number.
After this exchange, the TCP connection is closed.
Complete Example
Suppose:
-
Client sends FIN with
SEQ = x -
Server sends FIN + ACK with
SEQ = y -
Client acknowledges with
ACK = y + 1
The exchange is:
CLIENT SERVER | | | FIN | | SEQ = x | |----------------------------->| | | | FIN + ACK | | SEQ = y | | ACK = x + 1 | |<-----------------------------| | | | ACK | | ACK = y + 1 | |----------------------------->| | | | CONNECTION CLOSED | | |
Why are the acknowledgment numbers x + 1 and y + 1?
Because FIN consumes one sequence number, even when it carries no data.
So:
Client FIN: SEQ = x ↓ Next expected = x + 1
and
Server FIN: SEQ = y ↓ Next expected = y + 1
What Is Half-Close?
TCP supports half-close, which is an important feature of connection termination.
A half-close means:
One endpoint stops sending data, but it can continue receiving data.
TCP is full-duplex, so the two directions can be closed independently.
Consider:
Client → Server CLOSED Client ← Server STILL OPEN
The client can tell the server:
"I have finished sending data, but I am still willing to receive data from you."
This is achieved by sending a FIN.
Example: Sorting Application
Following is a good example involving sorting.
Suppose the client wants the server to sort a large amount of data.
Step 1 — Client sends data
Client ────────────────> Server Data to sort
The server needs to receive all the data before it can begin sorting.
Step 2 — Client finishes sending
After sending all the data, the client sends a FIN.
Client ───── FIN ─────> Server
This means:
"I have finished sending data."
The client-to-server direction is now closed.
Step 3 — Server acknowledges
The server sends an ACK.
Client <──── ACK ───── Server
However, the server can still send data to the client.
Step 4 — Server processes the data
The server sorts the received data.
Client Server | | |------ Data to sort -------->| | | |------ FIN ----------------->| | | |<--------- ACK --------------| | | | Server sorts data | | | |<------ Sorted data ----------| | |
Thus, the connection is only partially closed at first.
Why Is Half-Close Useful?
Half-close is useful when one side has finished sending but still needs to receive a response.
For example:
Client → Server Send complete input ↓ Client sends FIN ↓ Server receives all input ↓ Server processes input ↓ Server → Client Send result
The classic textbook example is:
Client sends data to a server to be sorted.
The client does not need to send anything more after providing all the data, but it still needs to receive the sorted result.
Connection Termination vs Connection Establishment
It is useful to compare the two processes.
| Connection Establishment | Connection Termination |
|---|---|
| Uses SYN | Uses FIN |
| Establishes a TCP connection | Closes a TCP connection |
| Synchronizes sequence numbers | Terminates data exchange |
SYN → SYN+ACK → ACK | FIN → FIN+ACK → ACK |
| Connection becomes established | Connection becomes closed |
A simple way to remember:
ESTABLISHMENT SYN ↓ SYN + ACK ↓ ACK TERMINATION FIN ↓ FIN + ACK ↓ ACK
TCP connection termination uses FIN and ACK messages to independently close the two directions of the full-duplex connection, and TCP can support a half-close when one side finishes sending but continues receiving.
Why Is TCP Connection Logical?
It is important not to think of the TCP connection as a dedicated physical path.
TCP uses IP underneath it.
Application ↓ TCP ↓ IP ↓ Internet
IP is connectionless and may deliver individual segments independently.
TCP creates the illusion of a logical connection between the two application processes.
For example, if Segment 2 is lost:
Segment 1 ✓ Segment 2 ✗ Segment 3 ✓
TCP can detect the problem and retransmit Segment 2.
IP itself does not perform this retransmission.
Similarly, if segments arrive out of order:
Segment 1 Segment 3 Segment 2
TCP can hold Segment 3 until Segment 2 arrives and then deliver the data to the application in the correct order.
Three Phases of a TCP Connection
The complete TCP communication can therefore be viewed as three phases:
TCP Connection │ ┌───────────┼───────────┐ ↓ ↓ ↓ Connection Data Connection Establishment Transfer Termination │ ↓ Three-way Handshake
Phase 1 — Connection Establishment
SYN → SYN + ACK → ACK
Phase 2 — Data Transfer
Data + ACK Data + ACK Data + ACK ...
Phase 3 — Connection Termination
The connection is closed using FIN/ACK exchanges.
Summary
TCP connection establishment uses a three-way handshake:
-
Client → Server: SYN
- SYN flag set.
- Client sends its Initial Sequence Number (ISN).
- SYN consumes one sequence number.
-
Server → Client: SYN + ACK
- SYN and ACK flags set.
- Server sends its own ISN.
-
Acknowledges the client's SYN using
ACK = client ISN + 1. - Advertises its receive window.
- SYN consumes one sequence number.
-
Client → Server: ACK
- ACK flag set.
-
Acknowledges the server's SYN using
ACK = server ISN + 1. - A pure ACK carries no data and consumes no sequence number.
After the third step, the TCP connection is established and full-duplex data transfer can begin.
Comments
Post a Comment