Skip to main content

Command Palette

Search for a command to run...

The Transmission Control Protocol

Published
7 min read

The TCP protocol - also known as the transmission control protocol is a part of the OSI model that is used to provide reliability to the process of sending and receiving data packets over the internet. Out of the 7 layers it is a part of the transport layer and is used for socket to socket addressing.

Below the Transport layer is the network layer. Via the Internet Protocol -aka IP - it takes the data packet and somehow sends them to another machine over the internet. But they just attempt to do it. There is no guarantee that the packet has reached. That the packet that reached was safe and not corrupt. Also it is a possibility that the receiver didn’t have enough space in the buffer so it could not accept the packet - or there was too much congestion in the network for the packet to be able to reach there successfully. It also happens that the packets arrive out of order. IP seems henceforth useless but it is not - its just that all the above problems are handled by TCP.

To understand TCP - lets first try and understand a data packet.

Data Packet

For understanding data packets - lets first try to understand data. Now data is nothing but a stream of what is called as a bit. A bit is the simplest unit of information that has 2 possible states - on and off. Based on a given bit sequence and if each bit is on or off - generally represented by a 0 or 1 - it represents information. A sequence of 8 bits is called a byte. If we lock down the size of number of bits and make a bundle of it - its called a data packet. This data packet - before being transferred gets attached to it - layers of headers - extra data that is used by the internet to send them with information, security, to destination. Basically the raw data is surrounded by layers of more data that helps in making the data transferable on the internet and understandable by another machine.

One such data header is attached to the “payload” - the raw data - by TCP too.

TCP Header

TCP Header

This is what a TCP header looks like.

The first 2 important fields is - port numbers of the source and destination.

Because after reaching the machine - the IP address - the packet doesn’t know which port to go to- this is handled by TCP. It tells my client is using this port and they want to establish a connection with this port of yours. The port address is a 16 bit address.

After this we have the Sequence Number and the Acknowledgement Numbers. These two numbers are like this.

The sequence number is the number of the first byte in a segment and Acknowledgement number say x says that - I received the x-1 th byte - please send the x th byte. This is important because if the server is saying I need the xth byte means everything before it successfully reached me. If instead we would receive Acknowledgement number as x-1 we would resend our data packet. This helps in avoiding packet loss.

After that we have Header length - which has the size of the header encoded in it. There are a few reserved bits and then a few flags. Then there is the window size field that indicates to the receiver how many bytes is the sender capable of receiving back . This helps in flow control and ensure that the receiver is not overwhelmed.
Next is the Checksum - of the header field . This encrypted data is a way of checking if the header’s,payload and the IP’s header content are actually correct. If they were corrupted then the checksum calculated at destination will not match with what is in the header. At the end there are optional bits used for padding the header or some experimentation purposes.

Three Way Handshake

Since the main job of TCP is reliability - when it gets to the server it ensures that a connection is perfectly established. To do this - it performs a process called as the Three Way Handshake.

The three way sync can be thought of as a phone call. First when we call someone - we say hello - to check if they are there. Then if they reply for the hello with yes I am here - we will understand that they are there but they don’t know if we heard them.
So we will tell them that yes we heard them. By this time both parties have recognized that they can hear each other so they can continue to talk without any worries.

Like this.

Person1:
Can you hear me?

Person2:
Yes I can hear you - now can you hear me?

Person 1:
Yes I heard you.

This will ensure a successful connection between them.

SYN

For this the first thing that we need to know are about the SYN and the ACK bit in the flags in headers.
First the client sends a request with the SYN bit 1 and ACK 0- Indicating it wants to establish a connection and also that the Current Sequence Number is its Initial Sequence Number.

Before that we first need to understand this.
Say a TCP request goes and comes with a reply.

Say the first TCP request had:

Sequence number =x

Acknowledgement =y

Then the responding TCP will have:
Sequence Number = y

Acknowledgement = x+1

This means that when Acknowledgment Number is sent - it means that sequence number is requested for.
And Acknowledgment means that for a given sequence number I got your packet - so send me the next one.

So the first request is like this:

ACK = 0
SYN = 1
Sequence Number = Client Initial Sequence Number (Can be anything)
Acknowledgement Number = Invalid for now.

SYN+ACK

When the server gets it - it replies with both the SYN and ACK bit set. The server acknowledges the Sequence Number sent by client and in the Acknowledgement number field sends the Sequence Number +1 - indicating it accepts the request and asks for the next data packet - which won’t be sent here but to keep the rules consistent the protocol works like that. And it also sends its own Initial Sequence Number in the Sequence Number field.

So the response looks like this:

ACK = 1
SYN = 1
Sequence Number = Server Initial Sequence Number (Can be anything)
Acknowledgement Number = Client Initial Sequence Number+ 1

ACK

When the client sees this - it understands that the server has accepted the connection. So it sends the ACK bit as 1 - now saying that its sequence number is its own Initial Sequence Number + 1 along with the Acknowledgement Number as = Server’s Sequence Number +1.

Here is how the response looks like:

ACK = 1
SYN = 0
Sequence Number = Client Initial Sequence Number + 1
Acknowledgement Number = Server Initial Sequence Number + 1

After this the connection is successfully established. And the conversation can continue.

TCP connection Termination

Now after the talking is done between the two servers the TCP also has a responsibility to close the connection.

Here the flag involved is the FIN - finished flag.

The process is called as a 4 way handshake - since it involves 4 steps.

First the Client Requests for the connection Termination

Client Requests Termination

It says FIN=1 along with sequence number as last byte it sent +1

Server Accepts Termination

It says ACK=1 along with Acknowledgment Number = Last Client Byte +1

Now here the connection doesn’t close. Because it is possible that even after the client has stopped sending the server still needs to send more data.

So server initiates its own connection termination request once its done.

Server Requests Termination

It says FIN=1 and seq= last byte sent by it.

Client Accepts Termination

It says ACK = 1 and ack number = last byte sent by server +1

And this is how the Transmission Control Protocol serves its purpose in the vast system of Internet allowing us to open our websites , mails and make our API calls without any worries.