TCP3 Handshake Connection Protocol and 4-time handshake Disconnection Protocol

The TCP/IP state machine, as shown in:

In the TCP/IP protocol, the TCP protocol provides a reliable connection service with a three-time handshake to establish a connection, as shown in 1. (SYN packet indicates flag bit SYN=1,ACK packet indicates flag bit Ack=1,syn+ack package represents flag bit syn=1,ack=1)

(1) First handshake: When a connection is established, client A sends a SYN packet (SEQ_NUMBER=J) to Server B and enters the syn_send state, waiting for Server B to confirm.

(2) Second handshake: Server B receives the SYN packet, must confirm the SYN (ACK_NUMBER=J+1) of customer A, and also sends a SYN packet (seq_number=k), that is, the Syn+ack package, at which point Server B enters the SYN_RECV state.

(3) Third handshake: Client A receives Server B's Syn+ack package, sends acknowledgment packet ACK (ack_number=k+1) to Server B, the packet is sent, client A and Server B enter the established state, complete three handshake.

Three handshake is completed and the client and server begin to transfer data.

Figure 1 TCP Three-time handshake establishment connection

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

(1) Client A sends a fin to turn off customer A to Server B data Transfer (message segment 4).

(2) Server B receives this fin, which sends back an ACK, confirming that the serial number is received plus 1 (message Segment 5). As with Syn, a fin will occupy a sequence number.

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

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

TCP uses four waves to close connection 2 as shown.

Figure 2 TCP Four waves to close the connection

PS: Another diagram to close the connection

1. Why is a connection agreement a three-time handshake, and a four-time handshake when the connection is closed?

This is because the socket in the listen state of the server receives a connection request for the SYN message, and it can send the ACK and SYN (ACK response, and SYN synchronous) to a message. However, when the connection is closed, when the other side of the fin message notification, it only means that no data sent to you, but not all of your data are sent to the other side, so you may not be able to close the socket immediately, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.

2. Why does the time_wait state need to wait 2MSL before returning to the closed state?

This is because although both sides agree to close the connection, and the handshake of the 4 messages are also coordinated and sent, it can be directly back to the closed state (like from the Syn_send state to establish state); but 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 be re-sending the fin message because the timeout does not receive an ACK message, so this time_wait state is used to resend the possible missing ACK message.

3. Why can't I connect with a two-time handshake?

We know that 3 times handshake completes two important functions, both sides are ready to send data (both sides know each other is ready), also allow the two parties to negotiate the initial serial number, this serial number is sent and confirmed during the handshake. Now it is possible to change the three-time handshake to just two handshakes. As an example, consider the communication between the computer S and C, assuming that C sends a connection request packet to S, s receives the packet and sends a confirmation reply packet. In accordance with the two-time handshake agreement, S believes that the connection has been successfully established and can begin sending data groupings. However, c in the case of S answer packet is lost in the transmission, will not know if S is ready, do not know what kind of serial number s to build, C even doubt whether s receive their own connection request grouping. In this case, C considers that the connection is not yet successful, ignores any data groupings that are sent by S, and waits only for the connection acknowledgment answer packet. and S repeats the same grouping after the emitted packet timeout. This creates a deadlock.

Add:

A. By default (without changing the socket option), when you call Close (or closesocket, which says close no longer repeats), TCP continues to send the data out if there is data in the send buffer.

B. Sending fin simply means that the end cannot continue sending the data (the application layer can no longer call send), but may also receive data.

C. How does the application layer know the peer-to-peer shutdown? Typically, in the simplest blocking model, when you call recv, if you return 0, it means that the peer is closed. At this point the usual practice is to also call Close, then the TCP layer sends fin and continues to complete four handshake. If you do not call Close, the peer will be in the Fin_wait_2 state, and the local side will be in the close_wait state. This can write code to try.

D. In many cases, the TCP connection will be disconnected automatically by the TCP layer, for example, you have CTRL + C to terminate your program, the TCP connection will still shut down normally, you can write code to try.

Episode:

Special time_wait states:

From the above TCP connection Shutdown state transition diagram can be seen, the active shutdown of the party after sending out the other Fin message confirmation (ACK) message, will enter the TIME_WAIT state. The TIME_WAIT state is also known as the 2MSL state.

What is 2MSL? The MSL is maximum Segment Lifetime, which is the maximum lifetime of the message, in the words "TCP/IP Detail": "It (MSL) is the longest time in the network before any message segments are discarded." "Well, 2MSL is twice times that time. In fact, I don't think it's 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 segments, the active shutdown will continue to wait for a certain amount of time (2-4 minutes), even if the application ends at both ends. You can write code to try it and then use Setstat to view it.

Why do I need 2MSL? There are two reasons for this, according to the statement in TCP/IP and the TCP/IP guide:

First, ensure that the sent ACK will be sent to the other party successfully, how to guarantee? I think it might be sent through a timeout timer. This is difficult to demonstrate with the code.

Second, the message may be confused, meaning that other times the connection may be used as the connection. Direct reference to the TCP/IP guide saying: The second is to provide a "buffering period" between the end of this connection and any subsequ ENT ones. If not for this period, it was possible that packets from different connections could was mixed, creating confusion.

Impact of Time_wait Status: (1-4 minutes)

When one end of a connection is in the TIME_WAIT state, the connection will no longer be used. In fact, for our comparison, this port will no longer be used. When a port is in the TIME_WAIT state (which should actually be the connection), this means that the TCP connection is not disconnected (completely disconnected), and if you bind the port, it will fail. For a server, if the server suddenly crash out, it will not be able to restart within 2MSL because bind will fail. One way to solve this problem is to set the socket's SO_REUSEADDR option. This option means that you can reuse an address.

For the Time_wait episode:

When a TCP connection is established, the server will continue to listen on the original port and use this port to communicate with the client. The client, by default, uses a random port to communicate with the server-side listening port. Sometimes, for server-side security, we need to authenticate the client, which is the client that qualifies a particular port on an IP. The client can use bind to use a specific port. For the server side, when the SO_REUSEADDR option is set, it can be started within 2MSL and listen successful. But for the client, when the

When you use BIND and set SO_REUSEADDR, if you start within 2MSL, bind succeeds, but connect fails on the Windows platform. There is no such problem on Linux. (My experimental platform: WinXP, ubuntu7.10)

To resolve this issue with the Windows platform, you can set the So_linger option. The So_linger option determines the behavior of TCP when the close is called. So_linger involves the linger struct, if the l_onoff in the set struct is a non-0,l_linger 0, the TCP connection is immediately disconnected when close is called, and TCP does not send the unsent data from the send buffer. Instead, an RST message is sent to the other party immediately, and the TCP connection (when it shuts down) does not enter the TIME_WAIT state. As you can see, this solves the problem, but it's not safe. Setting the So_linger state in the above manner is equivalent to setting the So_dontlinger state.

Unexpected when disconnecting:

This is not an accident at the time of disconnection, when a TCP connection occurs with some physical contingencies, such as a network cable disconnection, the TCP implementation on Linux still considers the connection to be valid, and Windows returns an error message after a certain amount of time. This may seem to be resolved by setting the So_keepalive option, but it is not known whether this option is valid for all platforms.

TCP3 Handshake Connection Protocol and 4-time handshake Disconnection Protocol