TCP connection establishment and disconnection process (including the TCP status chart when the connection is disconnected)

The process of three handshakes when a TCP connection is established.
The process of three handshakes when a TCP connection is established is briefly described. According to the TCP header, the order of the following three packets in the connection establishment process is described. 0020 00 50 83 aa 46 49 3e dd 33 96 37 a3 a0 12... P .. FI>. 3. 7... 0030 16 a0 c4 c0 00 00 02 04 05 b4 04 02 08 0a d7 9b ................ 0040 62 b7 00 56 4a 2a 01 03 02 B .. VJ *.... (1) 0020 83 aa 00 50 33 96 37 a2 00 00 00 a0 02 ..... p3.7 ....... 0030 16 d0 84 1d 00 00 02 04 05 b4 04 02 08 0a 00 56 ............... v0040 4a 2a 00 00 00 00 01 03 00 J *........ (2) 0020 83 aa 0 0 50 33 96 37 a3 46 49 3e de 80 10 ..... p3.7.FI>... 0030 16 d0 f3 4b 00 00 01 08 0a 00 56 4a 36 d7 9b... K ....... vj6 .. 0040 62 b7 www.2cto.com B. (3) solution: In TCP/IP, TCP provides reliable connection services and uses three handshakes to establish a connection. 1) It is the second handshake. The flags bit is 12, the binary is 0001 0010, that is, there is syn and ack.2) it is the first handshake. The flags bit is 02, And the binary is 0000, that is, syn has no ack. 3) it is the third handshake. The flags bits are 10 and the binary value is 0001 0000, indicating that there is ack without syn. The connection accesses port 80 and is open for HTTP (HyperText Transport Protocol). The first handshake: when a connection is established, the client sends a syn Packet (syn = j) go to the server and enter the SYN_SEND status. wait for confirmation from the server. The second handshake: the server receives the syn Packet and must confirm the customer's SYN (ack = j + 1 ), at the same time, the client also sends a SYN Packet (syn = k), that is, the SYN + ACK packet. At this time, the server enters the SYN_RECV state. The third handshake: the client receives the SYN + ACK packet from the server, an ACK (ack = k + 1) Confirmation packet is sent to the server. After the packet is sent, the client and server enter the ESTABLISHED status and three handshakes are completed. After three handshakes are completed, the client and the server start to transmit data. Tcp-Disconnect: the main part is the four-way handshake. In fact, from my perspective, the client and the server are not distinguished. Either party can call close (or closesocket) functions such as www.2cto.com start to actively terminate a connection. Now let's talk about the normal situation. When the close function is called to disconnect a connection, the party that actively disconnects sends the FIN (finish packet) to the other party. With your previous experience, I think you should understand what I mean when I talk about FIN packets. That is, a packet segment with the FIN flag configured. FIN packets may also be appended with user data. If there is still data to be sent on this side, it is completely normal to attach the data to this FIN packet. Later, you will see that there are many additional packets, such as ACK packets. The principle we need to grasp is that TCP will certainly achieve the maximum efficiency as far as possible, so you can think of the optimization method, I think TCP will think.
When a passively closed party receives a FIN message, it sends an ACK confirmation message (you should be familiar with ACK ). Here is something to note, because TCP is duplex, that is to say, you can imagine that a pair of TCP connections have two data paths. When sending a FIN message, it means that one end of the send FIN cannot send data, that is, one of the data paths is disabled. After an ACK is sent to the end of the passive disconnection, the application layer usually detects that the connection is about to be disconnected, and then the application layer calls close to close the connection.
I can tell you that once you call close (or closesocket), this end will send FIN packets. That is to say, the end of passive shutdown also sends FIN to the active shutdown end. Sometimes, the passive shutdown end will combine the ACK and FIN packets to send them together. After receiving the FIN, the active closing end also sends ACK, and then closes the entire connection (in fact, it is not completely closed, but the packet to be switched is completely sent), and the four handshakes are completed. As you can see, because the passive shutdown end may combine ACK and FIN for sending, this is not a strict four-way handshake-four packet segments.
In the previous article, I did not mention TCP status conversion. Here I am still wondering if I should take out The general figure. However, here I will only show The status conversion chart when The connection is disconnected, from <The TCP/IP Guide>:
Vc2U = "src =" http://www.bkjia.com/uploads/allimg/131119/19445Q947-0.png "/>
Give a normal close when the windump information: 14: 00: 38.819856 IP cd-zhangmin.1748> 220.181.37.55.80: F 1:1 (0) ack 1 win 6553514: 00: 38.863989 IP 220.181.37.55.80> cd-zhangmin.1748: F 1:1 (0) ack 2 win 292014: 00: 38.864412 IP cd-zhangmin.1748> 220.181.37.55.80 :. ack 2 win 65535 supplementary details:
For the above four handshakes, I will add the following details: 1. by default (without changing the socket option), when you call close (or closesocket, which means close is no longer repeated), if www.2cto.com still has data in the sending buffer, TCP continues to send data. 2. If a FIN message is sent, it indicates that the data cannot be sent (the application layer cannot call send again), but the data can be received. 3. 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. 4. In many cases, TCP connection disconnection is automatically performed 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. If you reference <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 netstat to view it.
Why 2MSL? According to <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 www.2cto.com connections cocould be mixed, creating confusion.
TIME_WAIT status: when one end of a connection is in the TIME_WAIT status, the connection cannot be used any more. 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 in 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, the connection fails on windows platform even though bind is successful. 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, TCP connection to www.2cto.com 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. Author: mongojie