Three handshakes, four waves, and tcp transition

Three handshakes, four waves, and tcp transition. The status transition diagram is not beautiful, but it can explain the problem. Let's take a look, if the image is too small to be visible during browsing, You can enlarge the webpage. I explained the figure from three handshakes and four handshakes, and then proposed and solved some problems. I. Three handshakes 1. At the time of t1, the client process must be connected to a server. Therefore, a synchronous request frame, syn = 1, is sent. From now on the client enters the syn sent phase (t1-t3 ). 2. At time t2, the server receives the synchronization request from the client and sends the confirmation and synchronization request, syn = 1, ack = 1 ,. From this moment on the server enters the syn receive phase (t2-t4 ). 3. At the time of t3, the client receives the synchronization and confirmation from the server, and the client immediately sends ack = 1, that is, the confirmation frame. At this time, the client changes the status from syn sent to established (t3-t5) status. 4. At the t4 moment, the server receives confirmation from the client, and the server changes from the syn reveive status to the established (t4-t6) status. By the end of the three handshakes, the client and server can send data to each other. 2, 4 waves Protocol 5, in the t5 moment, the client sends a request to cancel the connection, fin = 1, the client immediately from the established State to fin wait 1 State (t5-t7 ). 6. At the t6 moment, the server receives the client's withdrawal request and sends a confirmation frame. At this time, the server is in the state of established to the closed wait state (t6-t8 ). 7. At the t7 moment, the client received a confirmation frame from the server side, and the client immediately changed from fin wait 1 to fin wait 2 (t7-t9 ). Note that the server does not immediately send the cancel frame because the server may still have data that has not been transmitted. 8. At the moment of t8, the server sends a request to cancel the connection, and immediately changes from the closed wait Status to the last ack (t8-t10) status, waiting for the client to send a confirmation frame. 9. At the TIME of t9, the client received the server-side withdrawal request and sent a confirmation frame. At this TIME, the client was immediately in the FIN WAIT2 state to the time wait (t9-t9 + 2msl) state, and after 2msl, go to the closed status. 10. The Server receives a confirmation frame from the client at the time of t10 and enters the closed state immediately. The four waves of the Agreement have ended. The following are some problems. (The following questions and knowledge points all come from the internet) 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. I have not found the answer to the following questions, but I have some guesses. 4. The client sends a revocation request. After the server confirms that a connection has been disconnected, and the client cannot send data, however, the client can receive data. The question is, why does the client send a confirmation frame after receiving the cancellation request from the server? Doesn't it mean that the client can only receive data and cannot send data? A: Connection and Revocation Requests are control requests. The ports used to send and receive data are different from those used to process connections and revoke services. That is to say, after the client revokes the request, the client cannot send data to the server, but it does not mean that the client cannot send request connections and confirm frames to the server. Supplement:. 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. Special TIME_WAIT status: the Status transition diagram of the TCP connection closure shows that after the active closing party sends the ACK message to the other party, will enter the TIME_WAIT status. 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? According to The TCP/IP explanation and The TCP/IP Guide, there are two reasons: first, how can we ensure that The ACK sent 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. 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, when bind is used on the client and SO_REUSEADDR is set, if bind is started in 2MSL, although bind is successful, 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. If l_onoff In the struct is set to a non-0 value and l_linger is set to 0, the TCP connection will be disconnected immediately when close is called, and TCP will not send unsent data in the sending buffer, instead, an RST packet is sent to the peer immediately. At this time, the TCP connection (when it is closed) will not enter the TIME_WAIT status. As you can see, this solution solves the problem but is not safe. Setting the SO_LINGER status is equivalent to setting the SO_DONTLINGER status. Disconnection accident: this is not an accident when the connection is disconnected. When a TCP connection experiences some physical exceptions, such as network cable disconnection, the TCP implementation on linux still considers the connection valid, while 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.