TCP 3-way handshake is one of the most commonly asked question and now you are going to find the answers you have been looking for the entire time. This article goes in-depth of the TCP handshake it.
TCP (Transmission Control Protocol) is a connection-oriented protocol which sends and receives data using sequence and acknowledgment numbers. This protocol is reliable because if data is lost in transit from source to destination, TCP retransmits the data either timeout is reached or data is successfully received. Another benefit of TCP, it also identifies duplicate messages and discards them properly.
TCP also provides an overflow control mechanism to slow data transfer when sending machine is transmitting very fast for the receiving machine. TCP also sends data delivery information to upper-layer protocols & applications it supports. Having all these features makes TCP end-to-end reliable transport protocol.
3-way Handshake is the reason why TCP is an end-to-end reliable connection or connection-oriented protocol. If there is communication between two machines or communication is happening between a client & the server, the 3-way handshake must need to complete initially. Once this 3-way handshake is successfully established, both machines or client & server start sending & receiving data with each other.
Using the below data flow diagram, we will see the TCP 3-way handshake process when Client is trying to reach the https server. “HTTPS uses TCP to forward traffic”.
Client IP Address >192.168.0.100
HTTPS Server IP Address > 104.211.92.54 HTTPS Port >443
- The client is initiating the connection request with https server by sending “SYN” packet
- Now, http server has received the “SYN” packet from client and it acknowledges the request by responding with “SYN” & “ACK” to the client.
- After receiving “SYN” & “ACK” packet from the server, the client sends “ACK” packet to the server confirming 3-way handshake is established successfully. And data transfer can be started.
As both client & server agreed to talk with each other, now they will start sending and receiving data. This is the way, TCP 3-way handshake is established in the network before actual data is sent and received from both ends.
Below is the Wireshark capture showing TCP 3 -way handshake:-
“SYN” Flag is set when connection request was sent by Client to HTTPS server:-
“SYN” & “ACK” Flag is set when the server responded to client:-
“ACK” flag is set when the client confirmed with the server that 3-way handshake is established:-
- How sequence and acknowledgment numbers work in TCP?
Sequence & acknowledgment numbers play a very important role in maintain TCP as a reliable & connection-oriented protocol.
In TCP session, the client on either side maintains a 32-bit sequence number which keeps track of how much data it has sent. This sequence number is included in each transmitted packet, and acknowledged by the opposite client called as an acknowledgment number to inform sending client that transmitted data was received successfully.
During TCP session, when a client initiates TCP traffic, its sequence number is random, this number may be any value between 0 & 4,294,967,295. Normally, in “Wireshark or any packet analyzers”, these typically display relative sequence and acknowledgment numbers in place of the actual value. And these numbers are relative to the initial sequence number of that stream. It is very helpful to keep track of relatively small, predictable numbers sent throughout the network.
As for example, the initial relative sequence number shown in below packet is 0 (naturally), while ASCll decode in the 3rd pane shows the actual sequence number is 0x00000000.
In Wireshark tool, navigate to Statistics à Flow Graph à Select TCP flow and click OK. Wireshark automatically builds a graphical summary of the TCP traffic flow. It will help in understanding how sequence & acknowledgment numbers are used throughout the TCP session.
In the above graph, each row represents a single TCP packet. The left column indicates the direction of the packet, TCP ports, segment length, and the flag(s) set. The column at right lists the relative sequence and acknowledgment numbers in decimal.
Now, we will use this packet flow graph to understand the working process of sequence and acknowledge numbers.
1st Packet
Each side of a TCP session starts out with a (relative) sequence number of zero. Likewise, the acknowledgment number is also zero, as there is not yet a complementary side of the conversation to acknowledge.
2nd Packet
The server responds to the client with a sequence number of 0 because this is the 1st packet in this TCP session and a relative acknowledgment number of 1. The acknowledgment number is set to 1 to indicate the receipt of the client’s SYN flag in packet #1.
Notice that the acknowledgment number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload).
3rd Packet
Like in 2nd packet, the client responds to the server’s sequence number of zero with an acknowledgment number of 1. The client includes its own sequence number of 1 (incremented from zero because of the SYN).
At this point, the sequence number for both hosts is 1. This initial increment of 1 on both hosts’ sequence numbers occurs during the establishment of all TCP sessions.
4th Packet
This is the 1st packet in the stream which carries an actual payload (specifically, the client’s HTTP request). The sequence number is left at 1 since no data has been transmitted since the last packet in this stream. The acknowledgment number is also left at 1, since no data has been received from the server, either.
Note that this packet’s payload is 725 bytes in length.
5th Packet
This packet is sent by the server to acknowledge the data sent by the client in 4th packet while upper layers process the HTTP request. Notice that the acknowledgment number has increased by 725 (the length of the payload in 4th packet) to 726; e.g., “I have received 204 bytes so far.” The server’s sequence number remains at 1.
6th Packet
This packet marks the beginning of the server’s HTTP response. Its sequence number is still 1, since none of its packets prior to this one have carried a payload. This packet carries a payload of 1448 bytes.
7th Packet
The sequence number of the client has been increased to 726 because of the last packet it sent. Having received 1448 bytes of data from the server, the client increases its acknowledgment number from 1 to 1449.
For the majority of the capture, we will see this cycle repeat. The client’s sequence number will remain steady at 726 because it has no data to transmit beyond the initial 725-byte request. The server’s sequence number, in contrast, continues to grow as it sends more segments of the HTTP response.
TCP Connection Closed (FIN Packet)
After acknowledging the last segment of data from the server, the client processes the HTTP response as a whole and decides no further communication is needed. FIN Packet is sent by the client with the FIN flag set. Its acknowledgment number remains the same as in the prior packet.
The server acknowledges the client’s desire to terminate the connection by increasing the acknowledgment number by one (similar to what was done in packet #2 to acknowledge the SYN flag) and setting the FIN flag as well.
The client sends its final sequence number of 727 and acknowledges the server’s FIN packet by incrementing the acknowledgment number by 1 to 22952.
At this point, both hosts have terminated the session and can release the software resources dedicated to its maintenance.
Cisco ISE basic interview question and answer
Cisco FirePower (FTD) Interview Questions and Answers
Information Security interview questions
Cisco Stealthwatch basic interview questions and answers
[…] TCP 3-Way Handshake […]