Tcp3 handshake connection protocol and 4 handshake disconnection Protocol

Disclaimer: This article is reprinted ~

Shows the TCP/IP state machine:

In TCP/IP, TCP provides reliable connection services and uses three handshakes to establish a connection, as shown in figure 1. (Syn packets indicate the flag SYN = 1, ACK packets indicate the flag ACK = 1, SYN + ACK packets indicate the flag SYN = 1, ACK = 1)

(1) first handshake: when a connection is established, client a sends the SYN Packet (seq_number = J) to server B and enters the syn_send status. Wait for server B to confirm.

(2) second handshake: When server B receives the SYN packet, it must confirm that customer a's Syn (ack_number = J + 1) and send a SYN Packet (seq_number = k) by itself ), that is, the SYN + ACK packet. At this time, server B enters the syn_recv state.

(3) third handshake: Client A receives the SYN + ACK packet from server B and sends the ACK (ack_number = k + 1) Confirmation packet to server B, client A and server B enter the established status and complete three handshakes.

After three handshakes are completed, the client and the server start to transmit data.

Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.

(1) Client A sends a fin to disable data transmission from client a to server B (packet segment 4 ).

(2) When server B receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.

(3) server B Closes the connection with client a and sends a fin to Client A (packet segment 6 ).

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

TCP uses four waves to close the connection 2.

PS: Another figure that closes the connection

1. Why is the three-way handshake while the four-way handshake when the connection is closed?

This is because when the socket in the listen status of the server receives the SYN Packet connection request, it can reply to ack and Syn (syn plays a synchronous role) it is sent in a message. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, therefore, you may not close the 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, indicating that you agree to close the connection now, therefore, the ACK messages and fin messages are sent separately in most cases.

2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?

This is because both parties have agreed to close the connection, and the four handshake packets are also coordinated and sent, it can be directly returned to the closed state (just like from syn_send to establish State), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you sent will be received by the other party. Therefore, the socket in the last_ack status of the other party may fail to receive the ACK message due to timeout, but resend the fin message, therefore, the time_wait status is used to resend potentially lost ACK packets.

3. Why cannot I use two handshakes for connection?

We know that three handshakes are required to complete two important functions: Both parties must prepare for data sending (both parties know that each other is ready), and both parties must allow negotiation on the initial serial number, the serial number is sent and confirmed during the handshake.
Now, only two handshakes are needed to change the three-way handshake. A deadlock may occur. For example, considering the communication between computer S and C, assuming C sends a connection request group to S, s receives the group and sends a confirmation Response Group. According to the two handshakes, s considers that the connection has been successfully established and can start sending data groups. However, if C's Response Group in S is lost during transmission, it will not know if S is ready or what serial number S has created, c even doubts whether s has received its own connection request group. In this case, C considers that the connection has not been established successfully, and ignores any data groups sent by S, only waiting for the connection to confirm the response group. When the Group sent by S times out, the same group is repeatedly sent. In this way, a deadlock occurs.

Supplement:

A. by default (without changing the socket option), when you call close (or closesocket, the close is not repeated), if there is data in the sending buffer, TCP continues to send data.

B. If fin is sent, it means that the end cannot send data continuously (the application layer cannot call send again), but it can also receive data.

C. How does the application layer know that the peer is disabled? Generally, in the simplest blocking model, if 0 is returned when you call Recv, it indicates that the peer is disabled. At this time, the usual practice is to call close, so the TCP layer sends fin and continues to complete four handshakes. If you do not call close, the peer end will be in the fin_wait_2 state, and the local end will be in the close_wait state. You can try writing code here.

D. In many cases, the TCP connection is automatically disconnected by the TCP layer. For example, if you press Ctrl + C to terminate your program, the TCP connection will still be closed normally. You can try writing code.

Episode:

Special time_wait status:

From the above status transition diagram of TCP connection closure, we can see that the active closing party enters the time_wait status after sending the ACK message to the FIN packet of the other party. The time_wait status is also known as the 2msl status.

What is 2msl? MSL is maximum segment lifetime, that is, the maximum message survival time. In reference to "TCP/IP details", "it (MSL) it is the longest time in the network before any packet segment is discarded." Then, 2msl is twice the time. In fact, I don't think it is necessary to understand the exact meaning of this MSL. What you need to understand is that when the TCP connection completes the exchange of four packet segments, the active side will continue to wait for a certain period of time (2-4 minutes), even if the applications at both ends end. You can try to write the code and use setstat to view it.

Why 2msl? There are two reasons for this:

First, how can we ensure that the Ack is successfully sent to the other party? I think it may be sent through the timeout timer. This makes it difficult to use code for demonstration.

Second, messages may be obfuscated, meaning that connections at other times may be treated as current connections. Directly reference the TCP/IP guide: the second is to provide a "buffering period" between the end of this connection and any subsequent ones. If not for this period,
It is possible that packets from different connections cocould be mixed, creating confusion.

The impact of time_wait status: (1 to 4 minutes)

When one end of a connection is in the time_wait status, the connection will no longer be used. In fact, what makes sense for us is that this port will no longer be used. When a port is in the time_wait status (in fact, this connection should be used), this means that the TCP connection is not closed (completely disconnected). If you bind this port, it will fail. For the server, if the server suddenly crashes, it cannot be restarted within 2msl, because bind will fail. One way to solve this problem is to set the so_reuseaddr option of the socket. This option means you can reuse an address.

For time_wait:

When a TCP connection is established, the server will continue to use the original port to listen and use this port to communicate with the client. By default, the client uses a random port to communicate with the listening port of the server. Sometimes, for the sake of server security, we need to verify the client, that is, to limit a client with a specific IP address port. The client can use bind to use specific ports. On the server side, when the so_reuseaddr option is set, it can be started in 2msl and listen is successful. However, for the client

When BIND is used and so_reuseaddr is set, if BIND is started in 2msl, although bind succeeds, connect fails on Windows platform. This problem does not exist in Linux. (My lab platform: WINXP, ubuntu7.10)

To solve this problem on Windows, you can set the so_linger option. The so_linger option determines the TCP behavior when close is called. So_linger involves the linger struct.Rochelle off is not 0, and Rochelle linger is 0When close is called, the TCP connection will be disconnected immediately. TCP will not send unsent data in the sending buffer, but will immediately send an RST packet to the other party. At this time, the TCP connection (when closed) does not enter the time_wait status. As you can see, this solution solves the problem but is not safe. PassThe above methodSetting the so_linger status is equivalent to setting the so_dontlinger status.

Disconnection exceptions:

This is not an accident when the connection is disconnected. When some physical exceptions occur during the TCP connection, such as network disconnection, the TCP implementation on Linux still considers the connection valid, windows returns an error message after a certain period of time. This seems to be solved by setting the so_keepalive option, but I don't know if this option is valid for all platforms.