Understanding TCP and the Three-Way Handshake

The Transmission Control Protocol (TCP) is a set of rules that helps devices talk to each other over the internet.

It’s designed to reliably send data across networks, ensuring they reach their destination successfully.

A key part of this reliability is the TCP Three-Way Handshake, a process that establishes a secure connection between two devices before data exchange begins.

In this reading, we will explore the role of TCP and the Three-Way Handshake in ensuring accurate and secure data transmission.

Additionally, we will analyze an example of HTTP traffic to illustrate these concepts in action.

The TCP/IP Model

Let’s start with the TCP/IP model, as it’s essential for understanding how TCP operates.

TCP/IP stands for Transmission Control Protocol and Internet Protocol, and it lays the foundational for network communication by explaining how data moves across networks.

The TCP/IP model is made up of four layers, each with its own role in the data transmission process: the application layer, transport layer, internet layer, and network access layer.

TCP is responsible for establishing a connection between two devices and ensuring the reliable transmission of data, while IP manages the routing and addressing of packets.

Where TCP Fits In

In the TCP/IP model, TCP works at the Transport Layer.

Here’s how the process works from start to finish:

• The Application Layer passes data, such as web requests, emails, or file transfers, to TCP, which divides it into smaller units called segments.
• TCP prepares these segments for reliable delivery by adding headers with essential information, like sequence numbers, to ensure they can be reassembled in the correct order on the receiving end.

• Once the data reaches the Internet Layer, IP takes over, adding its own headers for addressing and routing, turning these segments into packets that can be transmitted across networks.
• Finally, packets reach the Network Access Layer. Here, they are wrapped with additional headers and trailers, transforming them into frames. These frames are the actual units sent over the network, whether by wired, wireless, or other means.

This layered process, from segments to packets to frames, ensures that data moves smoothly and accurately across networks, with each layer handling a specific part of the journey.

Example: Visiting a Website

Let’s say you want to visit a website from your computer, which is connected to a network set up like this: your computer connects to a switch, then to a router, followed by another switch, and finally to a server that hosts the website.

You type the website's URL into your browser and click Enter. Your computer first uses the DNS server within your network to determine the IP address associated with this URL, which is typically the server's IP address where the website is hosted. After that, your computer sends a GET request to retrieve the content of the website.

Now, a process called encapsulation occurs. The application protocol we are using is HTTPS. Within the Application Layer, the GET request is encapsulated inside an HTTPS header that informs the destination server about the type of request being made.

Let’s imagine the data (the GET request) as a piece of letter that is encapsulated inside an envelope. Each time we move down the TCP/IP model, the envelope is wrapped in another envelope with additional data.

The request moves down to the Transport Layer. Here, it is wrapped in a TCP header, which includes important information like source and destination port numbers, sequence numbers, and other control data. At this stage, the data is divided into segments.

Next, we move to the Internet Layer, where a new header is added with the source and destination IP addresses, transforming the segments into packets.

Finally, the packets arrive at the Network Access Layer, where they are further encapsulated with additional headers and trailers, turning them into frames. These frames are then sent over Ethernet cables to the switch.

The switch opens the first envelope and sees that the data should be sent to a specific MAC address. It consults its MAC address table to determine which router it should send the frames to.

Now, the process of opening envelopes is called decapsulation – it’s like opening the envelopes to check their contents.

The router receives the frames and opens the second envelope, which contains the destination IP. It examines its routing tables to determine where the data should go.

Since the switch can only see MAC addresses, the router must inform the second switch of the MAC address corresponding to the destination IP – the server hosting the website.

To find out this MAC address, the router sends an ARP request. Once it obtains the MAC address, the router re-encapsulates the packets with the new MAC addresses into frames and sends them to the switch.

The data is then transmitted through the second switch to the server. The server decapsulates the frames, removing each layer until it reveals the HTTPS message. It recognizes your GET request and prepares to send back the contents of the website.

The server then repeats the same process to send the webpage data back to your computer, encapsulating it in layers as it goes.

Why TCP is Reliable

TCP begins with a Three-Way Handshake to establish a connection between two devices:

1. The client sends a SYN (synchronize) packet to the server.
2. The server responds with a SYN-ACK (synchronize-acknowledge) packet.
3. The client sends an ACK (acknowledge) packet back to the server.

This process ensures both devices are ready to communicate.

Once the connection is established, TCP begins breaking down the data into smaller segments.

Segmenting the data enables smoother transmission and prevents large chunks from overwhelming the network.

Each segment is wrapped in a TCP header that holds essential details. This header includes information such as source and destination port numbers, sequence numbers, and flags.

TCP assigns each segment a sequence number. This allows the receiver to put all the data segments back together in the right order, even if they arrive out of sequence.

As the receiver gets each segment, it sends back an acknowledgment (ACK) to the sender. This confirms that each segment has been received successfully.

If an acknowledgment is missing, the sender knows that segment may have been lost and will retransmit it.

To further ensure data integrity, TCP includes a checksum in each segment’s header to verify that data wasn’t corrupted during transmission.

If any segment is corrupted, TCP will retransmit it until it is received correctly.

These features ensure that all data reaches its destination completely and accurately.

Because of its reliability, TCP is ideal for applications where accurate data delivery is essential, such as web browsing (HTTP & HTTPS), file sharing (FTP), and email (IMAP, POP, SMTP).

The Three-Way Handshake

TCP uses this handshake process to establish a reliable connection between a client (such as your browser) and a server (like a website).

Think of it as a way for both parties to agree on how they want to communicate before the actual data transfer begins.

Step-by-step breakdown when visiting a website:

1. Initiation (SYN): The browser, acting as the client, initiates the connection by sending a SYN (synchronize) packet to the server hosting the website. This packet includes a starting sequence number (e.g., X), essentially signaling, “Hey, I want to start a connection, and here’s my starting sequence number: X.”
2. Response (SYN-ACK): Upon receiving the SYN packet, the server responds with a SYN-ACK (synchronize-acknowledge) packet. This response includes its own starting sequence number (e.g., Y), along with an acknowledgment of the client’s sequence number incremented by 1 (X + 1). It’s like the server replying, “I’ve received your request and here’s my starting sequence number: Y. I acknowledge your number X + 1.”
3. Acknowledgment (ACK): Finally, the client replies with an ACK (acknowledge) packet to confirm receipt of the server’s SYN-ACK packet. This packet contains the server’s sequence number incremented by 1 (Y + 1), signaling, “I got your response, and now we’re synchronized and ready to exchange data.”

The packet is called a SYN packet because, during the handshake, it is necessary to synchronize sequence numbers between the client and server. The starting sequence number for both sides is known as the Initial Sequence Number (ISN), a vital component in TCP communication.

When the client sends a SYN packet to the server, it’s essentially saying, “Hey, I’m going to start counting the data I send from this number.”

In response, the server needs to take an important action: it acknowledges the client’s sequence number by incrementing it by one in its reply. This lets the client know that the server has received its message and is ready to proceed with the connection.

Sequence numbers are chosen randomly instead of starting at zero. The client and server each select random numbers (X and Y) for the following reasons:

• Preventing Confusion: If the client and server have communicated previously and start a new session, using the same sequence numbers could lead to old messages being mistaken for new ones. Random starting points help prevent this overlap and confusion.
• Security: Randomizing helps protect against certain types of attacks, such as TCP spoofing, ensuring that only legitimate connections are recognized.

This synchronization is crucial because TCP ensures reliable data transfer by tracking and managing the order of packets.

By knowing the sequence numbers, both the client and server can reassemble data in the correct order and detect any missing or out-of-sequence segments.

The Handshake in Action

To illustrate the TCP Three-Way Handshake in action, let’s analyze the following tcpdump output generated from a connection to a web server on port 80 (HTTP).

I used the tcpdump -nn -S port 80 command to monitor traffic on port 80, and then executed the curl http://167.235.253.88 command to initiate a request to the web server.

This output captures the sequence of packets exchanged during the handshake and the subsequent data transfer:

13:34:12.344584 IP 92.72.34.89.26232 > 167.235.253.88.80: Flags [S], seq 3531231207, win 65535, options [mss 1412,nop,wscale 6,nop,nop,TS val 3019538245 ecr 0,sackOK,eol], length 0
13:34:12.344657 IP 167.235.253.88.80 > 92.72.34.89.26232: Flags [S.], seq 2227943007, ack 3531231208, win 65160, options [mss 1460,sackOK,TS val 1425199703 ecr 3019538245,nop,wscale 7], length 0
13:34:12.372629 IP 92.72.34.89.26232 > 167.235.253.88.80: Flags [.], ack 2227943008, win 2056, options [nop,nop,TS val 3019538274 ecr 1425199703], length 0
13:34:12.372629 IP 92.72.34.89.26232 > 167.235.253.88.80: Flags [P.], seq 3531231208:3531231285, ack 2227943008, win 2056, options [nop,nop,TS val 3019538274 ecr 1425199703], length 77: HTTP: GET / HTTP/1.1
13:34:12.372862 IP 167.235.253.88.80 > 92.72.34.89.26232: Flags [.], ack 3531231285, win 509, options [nop,nop,TS val 1425199732 ecr 3019538274], length 0
13:34:12.373363 IP 167.235.253.88.80 > 92.72.34.89.26232: Flags [P.], seq 2227943008:2227943870, ack 3531231285, win 509, options [nop,nop,TS val 1425199732 ecr 3019538274], length 862: HTTP: HTTP/1.1 200 OK
13:34:12.400041 IP 92.72.34.89.26232 > 167.235.253.88.80: Flags [.], ack 2227943870, win 2042, options [nop,nop,TS val 3019538302 ecr 1425199732], length 0

The flags are shown inside the square brackets, such as [S] for SYN, [S.] for SYN-ACK, and [.] for ACK.

Let’s first analyze the first three packets, which represent the handshake:

1. SYN Packet (Initiation): At 13:34:12.344584, the client (IP 92.72.34.89) initiates a connection to the server (IP 167.235.253.88) by sending a SYN packet from its ephemeral port 26232 to the server's port 80. This packet indicates that the client is ready to establish a connection and includes its initial sequence number (3531231207).
2. SYN-ACK Packet (Response): Just 73 microseconds later, at 13:34:12.344657, the server responds to the client’s SYN packet with a SYN-ACK packet. This packet is sent from port 80 of the server to the client's ephemeral port 26232. The server acknowledges the client's request by incrementing the client's sequence number to 3531231208 and introduces its own initial sequence number (2227943007).
3. ACK Packet (Acknowledgment): At 13:34:12.372629, the client sends an ACK packet back to the server to confirm receipt of the server’s SYN-ACK packet. This packet acknowledges the server's sequence number, incremented to 2227943008. This communication occurs between the same port numbers as before: the client’s port 26232 and the server’s port 80.

At this point, the client and server are synchronized and ready to exchange data.

Note that the TCP handshake occurs before any actual data exchange takes place. The handshake is completed prior to TCP dividing the data into segments and passing them down to the Network Layer for encapsulation into packets. You can confirm this by observing that the length of the handshake packets is zero, indicating that no data is being transferred during the handshake process itself.

Sequence numbers play a crucial role, helping the sender determine whether the receiver has received the data by sending acknowledgments. When the receiver acknowledges the data, it adds the length of the received data to the sender’s sequence number.

For example, if the client sends 100 bytes of data, the server adds 100 to the client’s sequence number in its acknowledgment.

During the handshake, only 1 is added to the sequence number because no actual data is being transferred – just a synchronization request. This increment of 1 is often referred to as a Ghost Byte, as it does not correspond to any real data being sent. It simply indicates that the handshake was acknowledged.

Now, let’s analyze the last four packets in which data exchange begins:

1. Data Transmission Initiated by the Client: In this packet, the client (IP 92.72.34.89) sends a push (P) packet with a sequence number ranging from 3531231208 to 3531231285, indicating it is sending 77 bytes of data. This packet contains an HTTP GET request.
2. Acknowledgment from the Server: The server responds with an acknowledgment (ACK) for the data received from the client, indicating that it has successfully received the last byte of the client's data (up to sequence number 3531231285).
3. Data Transmission from the Server: The server now sends its response, which is a push packet containing an HTTP status code 200 OK along with 862 bytes of data.
4. Final Acknowledgment from the Client: Finally, the client sends another acknowledgment, confirming that it has received the entire response from the server up to the sequence number 2227943870.

In summary, these packets show how data is exchanged after the TCP handshake. They demonstrate how the client requests data, the server responds, and how acknowledgments help keep the connection reliable.

Troubleshooting Tip

When encountering network issues, start by analyzing network traffic and focus on the transport layer within the TCP/IP model.

This approach allows for a more streamlined troubleshooting process:

1. If TCP is functioning correctly: Move up the TCP/IP model to inspect the application layer.
2. If TCP shows issues (e.g., retransmissions or out-of-order packets): Shift focus downward to diagnose the network layer, where underlying problems may be affecting traffic flow.

This method helps isolate problems efficiently by using the TCP/IP model as a guide.

Starting at the transport layer allows you to quickly determine if the issue lies higher in the stack, such as application-level misconfigurations, or lower in the network layers, where physical connectivity or routing might be at fault.

Conclusion and Final Thoughts

In conclusion, understanding how TCP works and the Three-Way Handshake is essential for grasping how data is transmitted and troubleshooting network issues.

If you found value in this reading or have any questions or feedback, please don't hesitate to share your thoughts in the discussion section.

Your input is greatly appreciated, and you can also contact me directly if you prefer.