This time, thoroughly understand TCP three handshake, four wave

What is “Three handshakes, four waves”?

TCP is a connection-oriented unicast protocol. Before sending data, communication parties must establish a connection.

The so-called “connection” is actually a piece of information about each other, such as IP address and port number, stored in the memory of the client and server.

TCP can be thought of as a byte stream that handles packet loss, duplication, and errors at the IP layer and below.

During the establishment of a connection, the two parties need to exchange some connection parameters. These parameters can be placed in the TCP header.

TCP provides a reliable, connection-oriented, byte stream, transport layer service that establishes a connection using a three-way handshake. Use four waves to close a connection.

TCP service model

Now that we’ve looked at the “three handshakes and four waves” of establishing and closing a connection, let’s take a look at TCP.

A TCP connection consists of two IP addresses and two port numbers. A TCP connection is typically divided into three phases: start, data transfer, and exit (close).

When TCP receives data from the other end, it sends an acknowledgement, but this acknowledgement is not sent immediately, usually after a while.

Acks are cumulative, and an ACK with an acknowledgment byte number N indicates that all bytes up to N (excluding N) have been received successfully.

The advantage of this is that if one ACK is lost, it is likely that subsequent acks will be sufficient to confirm the previous packet segment.

A complete TCP connection is bidirectional and symmetric, and data can flow equally in both directions, providing a duplex service to upper-layer applications.

Once a connection is established, each TCP segment in one direction of the connection contains an ACK for the segment in the opposite direction.

The sequence number enables a TCP receiver to discard duplicate segments and record the segments that arrive in disordered order.

Because TCP uses IP to transport segments, IP does not provide the ability to eliminate duplicates or ensure correct order.

TCP, on the other hand, is a byte stream protocol that never sends data to upper-layer programs in a random order.

So the TCP receiver is forced to hold data with a large sequence number from the application until the missing segment with a small sequence number is filled.

The TCP header

The source port and destination port determine the processes of both parties at the TCP layer. The sequence number indicates the first byte number in the packet segment data, and the ACK indicates the confirmation number.

The next sequence number that the sender expects to receive is the last successfully received data byte sequence number plus 1. This field is valid only if the ACK bit is enabled.

When a new connection is created, the SYN bit of the first packet segment sent from the client to the server is enabled. This is called the SYN segment.

The sequence number field contains the first sequence number to be used in this direction of the connection, the initial ISN, after which the ISN plus 1 is sent.

So the SYN bit field consumes a sequence number. This means that retransmission is used for reliable transmission, whereas ACK without consuming serial numbers is not.

The header length (the data offset in the figure) is in 32-bit words, that is, in 4bytes. It has only 4 bits and the maximum size is 15, so the maximum header length is 60 bytes and the minimum is 5, that is, the minimum header length is 20 bytes (the variable option is empty).

• ACK — confirm, making the confirmation number valid.
• RST — Resetting the connection (often seen as reset by peer) is the result of this field.
• SYN – The sequence number used to initialize a connection.
• FIN: The sender of the packet has stopped sending data to the other party.

When a connection is established or terminated, the segment exchanged contains only the TCP header and no data.

State transition

The transitions between the three handshakes and the four waves are shown below:

Why “Three handshakes, four waves”

Three-way handshake

Put the three-way handshake in a more understandable light.

The client and server need to connect before communication. The “three-way handshake” is used to ensure that the receiving and sending capabilities of the client and the other side are normal.

First handshake: The client sends a network packet and the server receives it. In this way, the server can conclude that the sending capability of the client and the receiving capability of the server are normal.

Second handshake: The server sends the packet and the client receives it. In this way, the client can conclude that the receiving and sending capabilities of the server and the client are normal.

From the perspective of the client, I received the response packet sent by the server, indicating that the server received the network packet sent by me during the first handshake and successfully sent the response packet, which indicates that the receiving and sending capabilities of the server are normal.

On the other hand, I received the response packet from the server, indicating that the network packet I sent for the first time successfully reached the server, so that my own sending and receiving capabilities are normal.

Third handshake: The client sends the packet and the server receives it. In this way, the server can conclude that the receiving and sending capabilities of the client and the sending and receiving capabilities of the server are normal.

After the first and second handshakes, the server does not know whether the receiving capability of the client and its own sending capability are normal.

On the third handshake, the server receives the client’s response to the second handshake. From the server’s point of view, my response data from the second handshake is sent out, and the client receives it. So, my ability to send is normal. The reception capacity of the client is also normal.

After the above three handshakes, both the client and server confirm that their receiving and sending capabilities are normal. Then you can communicate normally.

Each time, the person receiving the packet can draw some conclusions, while the person sending the packet has no clue.

Although I have the action of sending a packet, but how do I know I have sent, and the other party has received it?

As you can see from the above procedure, a minimum of three handshakes are required. Both failed to reach the conclusion that their own and the other’s ability to receive and send were normal.

In fact, each time the party receiving the network packet can at least get: the other party’s sending, our receiving is normal.

Each step is related, and the next “response” is triggered by the first “request,” so each handshake can lead to additional conclusions.

For example, if the server receives data packets during the third handshake, it indicates that the server can only obtain the sending capability of the client and the receiving capability of the server.

However, in combination with the second time, it indicates that the client received the response packet sent by the server in the second time and made a response, thus obtaining the additional conclusion: the client received and the server sent are normal.

To summarize:

Four times to wave

TCP connections are two-way peer-to-peer, which means that both parties can send or receive data to each other at the same time.

When either party wants to close the connection, it sends a command to tell the other party that I’m closing the connection. An ACK is sent back, and the connection in one direction is closed.

But the other direction can continue to transmit data, and when all data is sent, a FIN segment is sent to close the connection in that direction. The receiver sends an ACK to confirm closing the connection.

Notice that the party that receives a FIN packet can reply only one ACK, but cannot immediately return a FIN segment to the other party. The “instruction” to end data transmission is given by the upper application layer. I am only a porter, and I cannot understand the “will of the upper layer”.

How to complete “three handshakes, four waves”?

In fact, the purpose of the three-way handshake is not only to let the communication parties know that a connection is being established, but also to use the options of the packet to transmit special information and exchange the initial SEQUENCE number ISN.

The three-way handshake means that three packet segments are sent, and the four-way wave means that four packet segments are sent. Note that both SYN and FIN segments are reliably transmitted using retransmission.

Principle of three-way handshake:

• The client sends a SYN segment with an initial sequence number, ISN(c), for the client.
• The server replies with its SYN segment, specifying its ISN(s). To confirm the client’s SYN, the ISN(c)+1 is used as the ACK value. Each SYN is sent, the sequence number is incremented by one, and if it is lost, it is retransmitted.
• To confirm the SYN on the server, the client returns the ISN(s)+1 as the ACK value.

Four wave principle:

• The client sends a FIN segment with its current serial number K that it wants the recipient to see. It also contains an ACK to confirm the latest data sent by the other party.
• The server adds K to 1 as the ACK sequence number, indicating that the last packet was received. The upper application is notified that the other end initiated a shutdown, which usually causes the application to initiate its own shutdown.
• The server initiates its own FIN segment, ACK=K+1, Seq=L.
• Client confirmation. ACK=L+1

Why is it three handshakes to establish a connection, but four waves to close it? This is because in LISTEN state, the server receives a SYN packet for establishing a connection and sends the ACK and SYN packets to the client.

When a FIN packet from the peer party is received, the peer party only stops sending data but can still receive data. The upper-layer application determines whether to close the data transmission channel. Therefore, the PEER ACK and FIN packets are sent separately.

“Three handshakes, four waves” advanced

ISN

An important function of the three-way handshake is that the client and server exchange ISN(Initial Sequence Number) so that the other side knows how to assemble the data by Sequence Number when they receive the data next.

If the ISN is fixed, an attacker can easily guess the subsequent confirmation number:

ISN = M + F(localhost, localport, remotehost, remoteport) Copy the code

M is a timer that increments by one every four milliseconds. F is a Hash algorithm that generates a random value based on the source IP address, destination IP address, source port, and destination port. Make sure that the Hash algorithm cannot be easily extrapolated externally.

Serial number winding

Because the ISN is random, the serial number can easily exceed 2^31-1. TCP’s judgment on packet loss and disorder depends on the comparison of sequence numbers.

TCP sequence wraparound (TCP sequence wraparound)

/* 
* The next routines deal with comparing 32 bit unsigned ints 
* and worry about wraparound (automatic with unsigned arithmetic). 
*/ 
static inline int before(__u32 seq1, __u32 seq2){ 
    return (__s32)(seq1-seq2) < 0; 
} 

#define after(seq2, seq1) before(seq1, seq2) Copy the code

The code above is the code in the kernel to resolve the wrap problem. __s32 stands for signed integer, while __u32 stands for unsigned integer.

When the sequence number is wound, the sequence number becomes smaller, and when subtracted, the result becomes a signed number, so the result is negative.

Suppose that SEQ1 =255 and seq2=1 (winding occurs). Seq1 = 1111 1111 seq2= 0000 0001 We want the comparison result to be seQ1 - seQ2 = 1111 1111-0000 0001 ----------- 1111 1110 since we converted the result to a signed number, Since the highest bit is 1, the result is a negative number, and the absolute value of a negative number is 0000 0001 + 1 = 0000 0010 = 2 so seQ1 - seq2 < 0Copy the code

Check whether any connection overflows netstat-s | grep LISTEN Copy the code

[root@server ~]# netstat -s | egrep "listen|LISTEN"
667399 times the listen queue of a socket overflowed 
667399 SYNs to LISTEN sockets ignored Copy the code

667399 times, which indicates the number of times the full connection queue overflowed, if executed every few seconds, the full connection queue must occasionally be full if this number keeps increasing.

Check whether the Accept queue overflows:

[root@server ~]# netstat -s | grep TCPBacklogDropCopy the code