The main part is the four handshakes: In fact, from my perspective, the client and server are not differentiated. Either party can call close (or closesocket) or the like.
To terminate a connection. Now let's talk about the normal situation. When you call the close function to disconnect a connection
One Party 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 message segment with the FIN flag configured. The fin message may also contain user data. If there is still data to be sent
It is completely normal to add this FIN packet. Later, you will see that there are many additional packets, such as ACK packets. We need to grasp
The principle is that TCP will certainly achieve the maximum efficiency, so the optimization method you can think of, 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
Note that TCP is duplex, that is, you can imagine that a pair of TCP connections have two data paths. When sending FIN packets
It means that one end of the fin cannot send data, that is, one of the data paths is disabled. Send a message at one end that is passively disabled
After ACK, the application layer usually detects that the connection is about to be disconnected, and then the application layer that is passively disconnected 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, now passive
The closing end also sends fin to the active closing end. Sometimes, the passive shutdown end will combine the ACK and FIN packets to send them together. Active
The shut-down end also sends ack after receiving the fin, and then closes the entire connection (in fact, it is not completely closed, but it only closes the packet sending to be exchanged.
), 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 enough.
Strict four handshakes-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 commonly used figure,
However, here I only show the status transition diagram when the connection is disconnected, from <the TCP/IP guide>:
The following figure shows the windump information during normal shutdown: 14:00:38. 819856 IP cd-zhangmin.1748> 220.181.37.55.80: F (0) ack 1 win 65535
14:00:38. 863989 IP 220.181.37.55.80> cd-zhangmin.1748: F (0) ack 2 win 2920
14:00:38. 864412 IP cd-zhangmin.1748> 220.181.37.55.80:. Ack 2 win 65535Additional 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, the close statement is not repeated), if
There is still data in the sending buffer, and TCP will continue to send the 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, when you call Recv, if 0 is returned, it indicates the peer
Disable. 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.
Closed, you can try to write code. Special time_wait status: From the above status transition diagram of TCP connection closure, we can see that after one party actively closes a message,
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>:"
MSL is the longest time in the network before any packet segment is discarded ." Then, 2msl is twice the time. Actually, I don't think so.
You need to understand the exact meaning of this MSL. What you need to understand is that when the TCP connection completes the exchange of the four packet segments, the active Shutdown
One Party 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 is successfully sent to the other party? I think it may be sent through the timeout timer. This is hard to use.
The code is demonstrated.
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: When one end of a connection is in the time_wait status, the connection will no longer be used. In fact, it is of practical significance for us.
Yes, 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
The 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. Solve this problem
One way 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
A random port is used to communicate with the listening port of the server. Sometimes, for the sake of server security, we need
Authentication: Specifies the client of a specific port of an IP address. 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. If the Rochelle Onoff In the struct is set to a non-zero value and the Rochelle linger is set to 0, the TCP connection is called during close.
Will be immediately disconnected, TCP will not send unsent data in the sending buffer, but will immediately send an RST packet to the other party, at this time TCP Connection
The connection 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 in the preceding method is equivalent to setting 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, TCP implementation on Linux
The connection will still be considered valid, while windows will return 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. |
