As a continuation from the previous transmission control protocol post, we will discuss the handshake that the TCP uses to establish a connection with a server before the transmission of data commences. A fundemental aspect of TCP/IP communication, the handshake has a three-step process that we will discuss in detail in this blog post.
A brief history
The TCP handshake was introduced with the transmission control protocol in 1974. There was no detailed specification to the workings of the handshake around this time, they were introduced in 1981. In 1981 the handshake was formally defined and documented, this formed part of the TCP standard that was published in RFC 793.
Why is the TCP handshake important?
There are several reasons why the handshake is an important aspect of networking, especially the TCP/IP aspect of networking. I will do my best to include them all and give you an overview of what they are, with examples where possible.
Confirms states of readiness
Before any data is sent, there must be a mutual agreement between the two devices. This is known as a state of readiness of the respective device, the device that is sending data knows that the device receiving the data is ready to receive and visa versa. An exmaple of this is when you want to initiate a conversion, you make sure the other person is listening before you begin your conversation as information could be lost entirely.
Establishes initial sequence numbers
The intent of this part of the handshake allows for both devices to agree on how the data will be sent, particuarly the order of the data. Think of it like this: you start to tell a story, to make sure that the other person can understand and follow the story, you need to give them a beginning, middle and end. The sending and receiving device decide on how best to send this data to allow for structure.
Connection reliability is maintained throughout
Because both devices have an agreement as to how the data is being sent, following on from our story analogy, they both know when they have sent and received, respectively, the beginning, middle and end of the data.
Unwanted connections are prevented
The handshake acts as a barrier to fend off malicious requests. This is because the two devices have an agreement and any interference from a third party is recognised and dealt with accordingly.
Security at it’s foundations
Because the agreement has been made before any sensitive data is sent, this creates a pathway that is less likely to be intercepted across the deployment of the data. With the barrier in place, everything is verified before something happens – such as something snooping in on your private conversation.
Foundational aspect of TCP/IP
The handshake creates a place of safety and security for the transferring data. Think of it as a safe place to talk and tell your story.
Why is it called the three-way handshake?
The TCP handshake is commonly known as the three-way handshake. There are three steps that the TCP handshake takes before any data is sent or received. This (as previously discussed here) is to enhance security and reliability of the data that is being transferred.
A TCP/IP transmission is broken up into three segments, for the trust and relaibility of transfer to be at the forefront of it’s goal.
The first segment
To establish a connection, the sender firsts send a segment which includes the syncronise (SYN) flag set. This segment lets the receiver know that the sender wants to initiate a conversation with them. The SYN provides the initial ordering of the data too, one that the receiver needs to acknlowedge and agree on.
The second segment
The second segment in this handshake is the synchronise-acknowledge (SYN_ACK). By incrementing the sequence number, the receiver sends data back to the sender and sets it’s own SYN flag. This transfer in the initial stages is to ensure that both the sender and receiver are on the same page.
The third segment
Known as the acknowledge segment, the third segment sends the acknowledge (ACK) flag to the receiver and an agreement has been made whereby the handshake is now complete. Since this is complete, the data can now be transferred over.
Conclusion
We have reached the end of this blog post. Please feel free to let me know on any points that I have done well on explaining, any points that are wrong and any points that need further clarification/better understanding on my part. I am in the process of learning this as I write so I will not know it in detail – I just enjoy writing what I find interesting and learning along the way.
In the future, I will be writing a blog post on API explotations as I have quite an interest in them that is further developing the more I look into it.
Leave a Reply