TCP- Three handshakes and four waves

Three handshakes — an exciting meeting

TCP’s three-way handshake and four-way wave, like the process between young lovers from meeting to breaking up, is cloying, but necessary.

Let’s start with the three handshakes. The two principals involved in the three-way handshake are the client and the server. The client is most likely a boy, more active, initially initiated communication by it, asking:

“Hello server, can I have a chat with you?”

If the server thinks the request is okay, it will respond with a positive “Yes, let’s talk.”

The client received a positive reply, happy, hurriedly said: “good good, I know you promised me, we can start to chat now!”

The whole dating process is shown below

When you look at the actual TCP connection setup process, you can see that the difference is not that big. You just need to convert human language into computer language

First of all, you need to know that in the computer world, the client and server communicate with each other through something called a message. In this case, SYN packets and ACK packets appear

  • SYN packet: identifies the SYN packet. When SYN=1 and ACK=0, it indicates that this is a connection request packet. If the peer agrees to establish a connection, SYN=1 and ACK=1 should be set in the response packet. Therefore, a SYN value of 1 indicates that this is a connection request or connection accept message.
  • ACK packets: According to the TCP protocol, this packet is valid only when ACK=1, and the ACK value of all packets sent after the connection is established must be 1.

The computer version of the dating process is as follows:

The client sends a connection request with SYN=1, ACK=0, and SEq =x.

SYN=1 does not carry data, but consumes a sequence number, so the SYN arrives at the battlefield with a sequence number seQ of x.

The server replies with SYN=1, ACK=1, seq= Y and ACK= x+1.

ACK=1, SEq =x+1, ACK= y+1

Why does TCP insist on three handshakes?

This is a classic question. According to our conventional logic, there are only two steps needed to establish a connection between people:

  • A sends an invitation to B
  • B accepts

Why is it three steps in the computer world?

This is because, unlike humans, there is something called “network state” between computers, which can affect their communication. Through the three-way handshake, the client has experienced a request and a response, and the server has also experienced a request and a response. At this time, on the one hand, it confirms that the current network status is good, and on the other hand, it confirms that the communication object can both request and respond, and it is really not wrong. Only in this secure, stable premise, two computers can establish TCP connection.

Four waves — a hard goodbye

Words client and server two people chat happily, suddenly the client’s mobile phone rang — it was his mother called him home for dinner. The client has to make a separation to the server, with the following dialogue:

  • Client: My mother told me to go home for dinner
  • Server: What? So you went home when your mom told you to, and you stopped playing with me?
  • Server: Ok, get out of here
  • Client: I’m out

A new type of packet is the FIN packet, which releases a connection. If the FIN value is 1, the sender finishes sending data and requests to release the transport connection.

Therefore, the client throws a FIN=1 packet to the server. And, of course, the serial number seq= X.

The server receives the breakup message and is devastated, but accepts the reality and replies with an ACK=1 sign to confirm. Of course, there is the confirmation code ACK = X +1, and its own serial number seq= Y.

While accepting the reality, the server still had something to say (in the above dialog, the last word “go”). As the initiative to break up the party, the client knows the wrong, so it will wait for the server to finish what it wants to say before leaving. After saying the rest, the server decides that it is time to end the relationship and sends a FIN=1 packet to the client to terminate the relationship. ACK=1, ACK= x+1, and its new sequence number, seq= Z.

The client receives the break up request from the server, and hurriedly says ok: throws an ACK=1 packet to the server. Of course, the confirmation code ACK= Z +1, the confirmation identifier ACK=1, and its new sequence number seq=x+1.

Why do TCP breakups have to be waved four times?

TCP is a full-duplex protocol, which means that both parties can send or receive data to each other at the same time.

When a client wants to disconnect, it can only confirm that it has no data to send to the server, but not that the server has any data to send.

Well, it takes two to break up. The client will not terminate the relationship because it has run out of words, but will wait for the server to finish. Therefore, even if the client throws a break request, the server can still transmit data.

The first two waves only confirm the breakup, but do not immediately confirm the breakup.

Before the third wave, the server says what it wants to say and notifies the client again. At this point, both sides are really ready to separate.

On the fourth wave, the client receives the breakup request from the server and responds with the “accept” signal, finally bringing the relationship to an end.

Discrimination between TCP and UDP

TCP requires a three-way handshake to establish a connection. This ensures that a stable transmission channel can be established between the two parties. Therefore, TCP is also known as “connection-oriented reliable Transport”.

UDP, on the other hand, has no handshake, no informed consent, a very casual protocol.

Under UDP, data can be sent whenever it wants. It also doesn’t care whether the other party receives its data or not, and it doesn’t use congestion controls-even on snail’s pace 2G and 3G networks, it doesn’t slow down to keep packets from getting lost.

Therefore, UDP is also known as “connectionless unreliable transport”.

UDP application scenarios

At first glance, UDP looks so unreliable, we simply use TCP protocol selection, as if there is no meaning!

In fact, it is reasonable to exist, and UDP has some advantages, such as:

  • It can serve multiple parties: UDP supports not only one-to-one transport, but also one-to-many, many-to-many, and many-to-one. Unicast, multicast, broadcast it is not a problem.
  • Header overhead is small: UDP headers are only 8 bytes large, whereas TCP requires 20 bytes. UDP is more efficient than TCP for the same packet content.
  • Casualness is also an advantage: sometimes, when our connections need to be established in real time, we don’t have the resources to give you repeated three-way handshakes and four-way waves, which makes UDP more flexible.

Combined with the advantages of UDP, I believe it is not difficult to imagine its application scenarios: in some occasions requiring strong real-time requirements, such as network telephone, video conference, online live broadcast, UDP is more suitable than TCP. As for file transmission, which requires high reliability and stability and strong connection certainty, TCP is more reliable.