Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the principle of linux's tcpip three-way handshake and four-wave hand". In daily operation, I believe that many people have doubts about the principle of linux's tcpip three-way handshake and four-wave hand. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "what is the principle of linux tcpip three-way handshake and four-wave hand?" Next, please follow the editor to study!

TCPIP three-way handshake

TCP (Transmission Control Protocol) Transmission Control Protocol

TCP is a host-to-host layer transmission control protocol that provides reliable connection services and uses a three-way handshake to establish a connection:

The bit code is the tcp flag bit, and there are six kinds of marks: SYN (synchronous online) ACK (acknowledgement confirmation) PSH (push transfer) FIN (finish end) RST (reset reset) URG (urgent Emergency)

Sequence number (sequence number) Acknowledge number (confirmation number)

First handshake: host A sends the bitcode syn=1 and randomly generates seq number=1234567 packets to the server. Host B is known by SYN=1, and A requires the establishment of online.

Second handshake: host B will confirm the online information after receiving the request, send ack number= (seq+1 of host A) and syn=1,ack=1 to A, and randomly generate seq=7654321 packets.

The third handshake: host A checks whether the ack number is correct, that is, the seq number+1 sent for the first time, and whether the bitcode ack is 1. If it is correct, host A will send ack number= (seq+1 of host B), ack=1, and host B will confirm the seq value and ack=1 to establish a successful connection.

After completing the three-way handshake, host An and host B begin to transmit data.

In TCP/IP protocol, TCP protocol provides reliable connection service and uses three-way handshake to establish a connection.

First handshake: when establishing a connection, the client sends a syn packet (syn=j) to the server, enters the SYN_SEND state, and waits for the server to confirm

The second handshake: when the server receives the syn packet, it must confirm the customer's SYN (ack=j+1). At the same time, it also sends a SYN packet (syn=k), that is, the SYN+ACK packet, when the server enters the SYN_RECV state; the third handshake: the client receives the SYN+ACK packet of the server and sends the confirmation packet ACK (ack=k+1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state and complete the three-way handshake. After completing the three-way handshake, the client and the server begin to transmit data.

Example:

IP 192.168.1.116.3337 > 192.168.1.123.7788: s 362654483636 26544836

IP 192.168.1.123.7788 > 192.168.1.116.3337: s 1739326486 1739326486 ack 3626544837

IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487

First handshake: 192.168.1.116 send bitcode syn=1, randomly generate seq number=3626544836 packets to 192.168.1.123192.168.1.123 by SYN=1 know 192.168.1.116 requires the establishment of online

Second handshake: 192.168.1.123 to confirm online information after receiving the request, send ack number=3626544837,syn=1,ack=1 to 192.168.1.116, randomly generate seq=1739326486 packets

The third handshake: 192.168.1.116 check whether the ack number is correct, that is, the seq number+1 sent for the first time, and whether the bitcode ack is 1. If correct, 192.168.1.116 will send the ack number=1739326487,ack=1192.168.1.123 and confirm that the seq=seq+1,ack=1 is received and the connection will be established successfully.

Illustration:

A three-way handshake (figure 1, figure 2)

(figure 1)

(figure 3)

The flag bit of the second handshake (figure 4)

We can see that there is a confirmation bit and a synchronization bit in the flag bit, that is, the response (SYN + ACK)

(figure 5)

A complete three-way handshake is a request-reply-reconfirmation

* magnificent dividing line * *

TCPIP four-wave analysis

Four breakups:

Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when a party completes its data transmission task, it can send a FIN to terminate the connection in this direction. Receiving a FIN simply means that there is no data flow in this direction, and an TCP connection can still send data after receiving a FIN. The first party to perform the shutdown will perform an active shutdown, while the other party will perform a passive shutdown.

(1) client A sends a FIN to turn off data transmission from client A to server B (message segment 4).

(2) Server B receives this FIN and sends back an ACK confirming that the sequence number is the received sequence number plus 1 (message segment 5). Like SYN, a FIN will take a sequence number.

(3) Server B closes the connection with client An and sends a FIN to client A (message segment 6).

(4) client A sends back ACK message confirmation, and sets the confirmation sequence number to receive the sequence number plus 1 (message segment 7).

Detailed description of status:

CLOSED: there is nothing more to say about this. It represents the initial state.

LISTEN: this is also a state that is very easy to understand, indicating that some SOCKET on the server side is listening and can accept connections.

SYN_RCVD: this status indicates that the SYN message has been received. Under normal circumstances, this state is an intermediate state during the three-way handshake session of the server-side SOCKET when establishing a TCP connection. It is very short, and basically you can hardly see this state with netstat, unless you specifically write a client-side test program that deliberately refuses to send the last ACK message during the three-way TCP handshake. Therefore, in this state, when receiving the ACK message from the client, it will enter the ESTABLISHED state.

SYN_SENT: this state echoes SYN_RCVD remote vision. When the client SOCKET performs a CONNECT connection, it first sends the SYN message, so it then enters the SYN_SENT state and waits for the server to send the second message in the three-way handshake. The SYN_SENT status indicates that the client has sent a SYN message.

ESTABLISHED: this is easy to understand, indicating that a connection has been established.

FIN_WAIT_1: this state should be well explained. In fact, the real meaning of FIN_WAIT_1 and FIN_WAIT_2 status is to wait for each other's FIN message. The difference between these two states is that when the SOCKET is in the ESTABLISHED state, it wants to close the connection actively and sends a FIN message to the other party, the SOCKET enters the FIN_WAIT_1 state. When the other party responds to the ACK message, it enters the FIN_WAIT_2 state. Of course, under the actual normal circumstances, no matter what the other party's circumstances are, he should respond to the ACK message immediately, so the FIN_WAIT_1 status is generally difficult to see, while the FIN_WAIT_2 status can sometimes be seen with netstat.

FIN_WAIT_2: this state has been explained in detail above. In fact, SOCKET in FIN_WAIT_2 state means semi-connection, that is, one party asks for a close connection, but also tells the other party that I still have some data to send to you for the time being, and then close the connection later.

TIME_WAIT: it means that you have received the FIN message from the other party and sent the ACK message. After waiting for 2MSL, you can return to the available state of CLOSED. If you receive a message with both the FIN flag and the ACK flag in the FIN_WAIT_1 state, you can directly enter the TIME_WAIT state without going through the FIN_WAIT_2 state.

CLOSING: this kind of state is special, it should be very rare in practice, and it is a relatively rare exception. Under normal circumstances, when you send a FIN message, you should first receive (or at the same time) the other party's ACK message, and then receive the other party's FIN message. But the CLOSING status indicates that after you send the FIN message, you do not receive the other party's ACK message, but also receive the other party's FIN message. Under what circumstances will this happen? In fact, if you think about it, it is not difficult to draw a conclusion: if both parties are close a SOCKET at almost the same time, then both parties will send FIN messages at the same time, that is, a CLOSING status will appear, indicating that both parties are closing the SOCKET connection.

CLOSE_WAIT: this state actually means that you are waiting for a shutdown. How do you understand it? When the other party close a SOCKET and send a FIN message to yourself, your system will no doubt respond to an ACK message to the other party, and then enter the CLOSE_WAIT state. Next, in fact, what you really need to consider is to see if you still have data to send to the other party. If not, you can also close the SOCKET, send the FIN message to the other party, that is, close the connection. So when you are in CLOSE_WAIT, all you need to do is wait for you to close the connection.

LAST_ACK: this state is relatively easy to understand. It is a passive shutdown party that sends a FIN message and finally waits for the other party's ACK message. When you receive the ACK message, you can enter the CLOSED available state.

Summary:

1. Why is it that establishing a connection protocol is a three-way handshake, while closing a connection is a four-way handshake?

This is because when the SOCKET in the LISTEN state of the server receives the connection request of the SYN message, it can send ACK and SYN (ACK acts as a reply and SYN acts as a synchronization) in a single message. But when you close the connection, when you receive a notification from the other party's FIN message, it only means that the other party has no data to send to you. But not all your data is sent to the other party, so you may not shut down SOCKET immediately, that is, you may need to send some data to the other party, and then send the FIN message to the other party to show that you agree to close the connection now, so the ACK message and the FIN message here are sent separately in most cases.

2. Why do I have to wait for TIME_WAIT status to return to CLOSED status after 2MSL?

This is because although both parties have agreed to close the connection, and the four messages of the handshake have been coordinated and sent, they can go directly back to the CLOSED state (just like from the SYN_SEND state to the ESTABLISH state). However, because we have to assume that the network is unreliable, you cannot guarantee that the last ACK message you send will be received by the other party, so the SOCKET in the LAST_ACK state may resend the FIN message because it has not received the FIN message during the timeout, so the function of this TIME_WAIT state is to resend the ACK message that may be lost.

At this point, the study on "what is the principle of linux's tcpip three-way handshake and four-wave hand" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.