TCP three-way handshake, when four waving unforeseen circumstances, in order to ensure stability, is how to deal with?

A. Order
when we talk to the TCP protocol, when the most is the three-way handshake chat with four wave. But most of the information flow in and articles are written in normal circumstances. But have you ever thought, three-way handshake or four times, waving, if an exception occurs, is how to deal with? Who in turn deal with?

TCP as the protocol of a fly, before and after the data transmission, it is necessary to establish a connection between two-terminal, and maintaining the state of each connection in the dual port. TCP and nothing special, in the face of changing network conditions, can only be ensured through constant reliability and retransmission algorithms.

Before the connection is established, TCP three-way handshake will be by double-ended state guarantee correct, then you can normally transmit the data. When the data transfer is complete, when the need to disconnect, TCP handshake may be accomplished by two-terminal disconnection and recovering their resources.

We learn TCP and build even break even when the majority are saying that a standard process, but the network environment is changing, not as often as the standard textbook, then to talk about today, and four times TCP three-way handshake when the wave, if unusual circumstances, is how to deal with? who made that deal?

Two. TCP three-way handshake
2.1 three-way handshake is simple to understand
, though, said three-way handshake abnormal situation, we first look at the three-way handshake.

When transferring data via TCP, the first step is to first establish a connection. TCP connection establishment, we often say that the three-way handshake.

We often three-way handshake, described as a "request → Answer → Answer the answer."

As for why the TCP handshake is three times? In fact, it is to make double-ended are undergoing a "request → response" process to confirm that they are still there. Network situation is changing, requires a double-ended request initiated their own initiative and the other replies response process to ensure that the other party and the network is normal.

The picture below, the change is more classic TCP three-way handshake messages and double-ended state.

TCP three-way handshake, when four waving unforeseen circumstances, in order to ensure stability, is how to deal with
us first explain this picture:

1. In the initial, double-ended in a CLOSE state, the server in order to provide services, will take the initiative to listen on a port, enter the LISTEN state.

2. The client sends "SYN" packet connections, after entering the SYN-SENT state, the server at the client to receive the "SYN" after the package, reply "SYN, ACK" packet, after entering the SYN-RCVD state.

3. After the client receives the server sent a "SYN, ACK" package, you can confirm the presence of the other party, then replies, "ACK" packet, and enter the ESTABLISHED state.

4. After the server receives the last "ACK" packet, also entered the ESTABLISHED state.

This is normal TCP three-way handshake, the handshake after the completion of the double-ended are entering ESTABLISHED state, after this, is the normal data transfer process.

Abnormalities 2.2 TCP handshake
normal contracting and answering three-way handshake, and the status of the double end twist we've talked about, then take a look at the course of this three-way handshake, the emergence of unusual circumstances.

1. The client first "SYN" packet lost.

If the client first "SYN" packet is lost, that is, the server does not know the client had sent a packet processing flow mainly in the client.

In the TCP protocol, one end of a set of "request - response" in, within a certain time frame, as long as do not receive "ACK" response packet, whether the other party does not receive a request packet, the response packet or the other he did not receive, are considered to be a loss, will trigger a timeout retransmission mechanism.

So in this case will enter retransmission "SYN" packet. The "TCP / IP Volume Comments Ⅰ: Protocol" describes in this case three attempts, each time interval is 5.8s, 24s, 48s, 76S is about three times, and most Berkeley system will establish a new connection the maximum time limit for the 75s.

That is the first three-way handshake "SYN" packets lost, retransmits, total trial time is 75s.

Reference: "TCP / IP Volume 1 18 | TCP connection establishment and termination."

2. Server receives "SYN" and reply "SYN, ACK" packet lost.

At this point the server has received the packet and reply if the reply is "SYN, ACK" packets lost, standing on the client's perspective, it would be considered the beginning of the "SYN" lost, then continue retransmission, what we said earlier, "error 1" process.

The end of the service, the "SYN, ACK" If you send a packet is lost, the client does not receive incoming "ACK" packet, will trigger retransmission, the Service end SYN_RCVD state within the timeout period, after the meeting in order to wait for 3s, 6s, 12s, re-send "SYN, ACK" packet.

And this "SYN, ACK" number of retransmissions package, there are different configurations under different operating systems, for example, can be configured by tcp_synack_retries In Linux, the default is 5. If within this number of retries, you have not received "ACK" response packet, then the server will automatically close the connection.

And because the client without receiving "SYN, ACK", will be retransmitted, when the client retransmission "SYN" is received, the server will re-send "SYN, ACK" package now.

3. The last time the client replies "SYN, ACK" in "ACK" packet lost.

If the last "ACK" packet is lost, because the server does not receive "ACK" will go retransmission mechanism, and the client time to enter the ESTABLISHED state.

In most cases, the client enters ESTABLISHED state, it shows the connection is established, data is sent immediately. However, because the server has not received a final "ACK" packet, it is still in the SYN-RCVD state.

So the key here is that the server in in SYN-RCVD state, how the client received packet processing?

This is also the more controversial areas, where some of the information will be written when the server is in the SYN-RCVD state, the client received a packet, it will respond directly to RTS packet response indicates the server error, and enter CLOSE state.

But such a setting a little too strict, Imagine, the server also determine whether the other party by real three-way handshake stage, this time the other side of the data has been sent, and that is certainly there.

So when the next SYN-RCVD state in the server, the client receives the actual transmitted data packets, will consider the connection has been established, and enter the ESTABLISHED state.

Practice makes perfect, specific test procedures may refer to the article: "TCP three-way handshake third ack lost what will happen."

Then the actual situation, why is this so?

When a client in the ESTABLISHED state, begins to send packets will carry a confirmation number "ACK", so "ACK" response packet even if the client is lost, the server when it receives the packet, through ACK sequence number in the acknowledgment packet into the normal ESTABLISHED state.

参考：《 What if a TCP handshake segment is lost? 》

4. The client does not send the last time deliberately "SYN" packet.

Front have been saying that the abnormal normal logic, both sides are pretty friendly, outlaw things, but also because the main objective abnormalities such as network problems, then said a hostile situation.

If the client is malicious, after sending "SYN" packet, and received "SYN, ACK" after not reply, then the server is now in a state of semi-connected, although the server will be re-configured through tcp_synack_retries the number of times the test will not wait indefinitely, but it is also a period of time.

If there is a short time a large number of such malicious connections to the server, it will be great pressure, which is called the SYN FLOOD.

It belongs to the category of security, not discussed today, we are interested can inform themselves about.

Three. TCP four times and waved
3.1 is simple to understand four waved
finished TCP three-way handshake, continue to analyze anomalies TCP four waved.

Keep the writing style, before that, we first take a brief look at the four wave of TCP.

When the data transfer is complete, you need to disconnect the time, TCP will take four times waving a way to safely disconnect.

Why the need to shake hands three times, four times and waved need it?
In essence, the need to go through a double-ended "break up" the process, to ensure their own and the opposite end of the state is correct. The attitude of friendly consultations, you first proposed breaking up, but also make the utmost good faith to each other, not fight each other a surprise. You say no to play do not play, after that who would be willing to play with you.

Below this figure, changes more classic TCP messages and four double-wave end state.

TCP three-way handshake, when four waving unforeseen circumstances, in order to ensure stability, is how to handle
us explain this picture:

1. 初始时双端还都处于 ESTABLISHED 状态并传输数据，某端可以主动发起「FIN」包准备断开连接，在这里的场景下，是客户端发起「FIN」请求。在发出「FIN」后，客户端进入 FIN-WAIT-1 状态。

2. 服务端收到「FIN」消息后，回复「ACK」表示知道了，并从 ESTABLISHED 状态进入 CLOSED-WAIT 状态，开始做一些断开连接前的准备工作。

3. 客户端收到之前「FIN」的回复「ACK」消息后，进入 FIN-WAIT-2 状态。而当服务端做好断开前的准备工作后，也会发送一个「FIN,ACK」的消息給客户端，表示我也好了，请求断开连接，并在发送消息后，服务端进入 LAST-ACK 状态。

4. 客户端在收到「FIN,ACK」消息后，会立即回复「ACK」，表示知道了，并进入 TIME_WAIT 状态，为了稳定和安全考虑，客户端会在 TIME-WAIT 状态等待 2MSL 的时长，最终进入 CLOSED 状态。

5. 服务端收到客户端回复的「ACK」消息后，直接从 LAST-ACK 状态进入 CLOSED 状态。

正常的经过四次挥手之后，双端都进入 CLOSED 状态，在此之后，双端正式断开了连接。

3.2 TCP 挥手的异常情况
四次挥手的正常发包和应答过程，我们已经简单了解了，接下来就继续看看，四次挥手过程中，出现的异常情况。

1. 断开连接的 FIN 包丢了。

我们前面一直强调过，如果一个包发出去，在一定时间内，只要没有收到对端的「ACK」回复，均认为这个包丢了，会触发超时重传机制。而不会关心到底是自己发的包丢了，还是对方的「ACK」丢了。

所以在这里，如果客户端率先发的「FIN」包丢了，或者没有收到对端的「ACK」回复，则会触发超时重传，直到触发重传的次数，直接关闭连接。

对于服务端而言，如果客户端发来的「FIN」没有收到，就没有任何感知。会在一段时间后，也关闭连接。

2. 服务端第一次回复的 ACK 丢了。

此时因为客户端没有收到「ACK」应答，会尝试重传之前的「FIN」请求，服务端收到后，又会立即再重传「ACK」。

而此时服务端已经进入 CLOSED-WAIT 状态，开始做断开连接前的准备工作。当准备好之后，会回复「FIN,ACK」，注意这个消息是携带了之前「ACK」的响应序号的。

只要这个消息没丢，客户端可以凭借「FIN,ACK」包中的响应序号，直接从 FIN-WAIT-1 状态，进入 TIME-WAIT 状态，开始长达 2MSL 的等待。

3. 服务端发送的 FIN,ACK 丢了。

服务端在超时后会重传，此时客户端有两种情况，要么处于 FIN-WAIT-2 状态（之前的 ACK 也丢了），会一直等待；要么处于 TIME-WAIT 状态，会等待 2MSL 时间。

也就是说，在一小段时间内客户端还在，客户端在收到服务端发来的「FIN,ACK」包后，也会回复一个「ACK」应答，并做好自己的状态切换。

4. 客户端最后回复的 ACK 丢了。

客户端在回复「ACK」后，会进入 TIME-WAIT 状态，开始长达 2MSL 的等待，服务端因为没有收到「ACK」的回复，会重试一段时间，直到服务端重试超时后主动断开。

或者等待新的客户端接入后，收到服务端重试的「FIN」消息后，回复「RST」消息，在收到「RST」消息后，复位服务端的状态。

5. 客户端收到 ACK 后，服务端跑路了。

客户端在收到「ACK」后，进入了 FIN-WAIT-2 状态，等待服务端发来的「FIN」包，而如果服务端跑路了，这个包永远都等不到。

在 TCP 协议中，是没有对这个状态的处理机制的。但是协议不管，系统来凑，操作系统会接管这个状态，例如在 Linux 下，就可以通过 tcp_fin_timeout 参数，来对这个状态设定一个超时时间。

需要注意的是，当超过 tcp_fin_timeout 的限制后，状态并不是切换到 TIME_WAIT，而是直接进入 CLOSED 状态。

参考：《 关于FIN_WAIT2 》

6. 客户端收到 ACK 后，客户端自己跑路了。

After the client receives the "ACK" direct running, the server in the follow-up "FIN, ACK" would not send the receiving end, will not get a reply, TCP will continue to go out retry mechanism, in which case the service LAST-ACK state in the end.

It would be divided into two kinds of situations Analysis:

After more than a certain time, the server initiative calls.
After receiving the "RST" initiative disconnected.
"RST" reset message is a message indicating that the current error, and should return to the original state. If the client has access to a new client, sends "SYN" In order to establish the desired connection, then this "SYN" will be ignored, and reply directly to the foot "FIN, ACK" message, the new client after receiving "FIN" messages are not recognized, and will return a "RST" message.