Understanding TCP: 3-Way Handshake Basics

The Internet is a giant network of interconnected devices spread across the world. But connection alone doesn’t guarantee communication. For computers to exchange information properly, they must speak a common language. To share this information effectively, the World Wide Web was born, which follows commonly accepted languages and rules. In networking, these shared languages and rules are defined through protocols.

In the world of protocols, different rules are defined for each layer of the OSI model. Today, we will look at the protocol associated with the Transport Layer, which is basically responsible for transferring data from the higher levels of the OSI model to the Network Layer. This protocol is called TCP, also known as the Transmission Control Protocol.

Why Do We Need TCP?

It is important to understand that no single protocol in the OSI model is self-sufficient in transferring data end-to-end on its own. It is basically a synchronized effort of all the protocols across the OSI layers that makes the successful sharing of data over the World Wide Web happen. In this chain, the Transport Layer protocol we are dealing with works in synchronization with Application Layer protocols like HTTP. Basically, TCP works "under the hood" for the successful implementation of HTTP on the web.

As TCP works in the Transport Layer, it is the protocol the Application Layer turns to when it needs a reliable, ordered, and congestion-free transfer of data.

In contrast, when the Application Layer is concerned about the speed of data transfer and is not worried about the order or potential loss of data mid-way (like in video streaming), the Transport Layer uses UDP to cater to that specific use case.

So, it all depends on the need of the Application Layer. When it requires that data does not get lost-i.e., reliable transfer-the Transport Layer uses TCP.

TCP has the following characteristics that make it the go-to protocol for HTTP when looking for safe transfer:

➤ Loss detection mechanism: If a packet is lost, it gets notified.

➤ Congestion control: It follows algorithms to ensure the smooth delivery of data packets.

➤ Retransmission: This happens automatically if a packet is not received.

➤ Three-way handshake: A strict process to establish connections.

How TCP Works Internally

Now, to understand how TCP achieves reliable data transfer, we will look at its internal working. TCP follows a Three-Way Handshake process that makes the connection reliable; hence, it is called a "Connection-Oriented Protocol."

The Transport Layer sits within the Operating System (OS) of the client’s system. The moment an HTTP request is initiated from the client’s browser, the OS exposes an API that gets triggered. When hit, these APIs trigger the OS to break the data into pieces called segments. Port numbers are then attached to these segments (both the sender’s and receiver’s port numbers), and they are transferred via a multiplexer to the Network Layer.

This process of breaking the data into segments and applying numbering is done at the Transport Layer (in the OS). When the data is broken down into segments for TCP, a sequence number is assigned to them. This basically helps in ordering the data. If a segment is lost, the numbering helps us recognize exactly which piece went missing, and retransmission of only that particular segment is initiated. This effectively handles packet loss and retransmission.

The 3-Way Handshake

While this processing happens at the OS level, the OS simultaneously sends a SYN (synchronize) request to the server’s Transport Layer. The server sends back an acknowledgment (ACK) along with its own SYN. Upon receiving that, the client’s OS sends a final ACK back to the server.

Once this final ACK is successfully sent, a connection is established. This whole "to-and-fro" process of SYN and ACK is termed the Three-Way Handshake. Only once this is established can we send and receive data at the Application Layer via HTTP.

Let’s look at the numbers to understand the SYN and ACK transfer better.

First, the client sends a SYN packet with a number-let's say, 32.
Upon receiving that, the server sends back a SYN + ACK. The ACK is always the received number plus one (so ACK will be 33). The server also sends its own SYN, which is a random number generated by the server-let's say 56.
Upon receiving these, the client sends back an ACK. As mentioned, this is always the received SYN plus one. Hence, the ACK will be 57.

When the server receives this, the connection is established and ready for data transfer.

Terminating the Connection

Once we are done with all the data transfer and sharing, the client’s Transport Layer (inside the OS) triggers a FIN flag and an ACK flag to the server. This signals the server to finish the connection as we are done with the data sharing.

The server, upon receiving the termination message, responds back with an ACK flag to the client so that the connection comes to an end and closes gracefully.

While making a connection, these all steps happen