Learn the special status of TCP in the TCP Series

Learn the special status of TCP in the TCP Series

The previous two articles introduced the TCP status change and demonstrated the normal status change between the client and the server through experiments.

Next, let's take a look at several special states in the Process of TCP status change.

SYN_RCVD

When a TCP connection is established, when the server receives a [SYN] packet, it sends the [SYN, ACK] packet and enters the SYN_RCVD status.

 

According to the previous article, the above behavior of the server is called passive open, and will wait for the [ACK] packet from the customer to establish the TCP connection. However, if the client does not respond at this time, the server will time out and re-transmit the [SYN, ACK] packet.

Let's take a look at the example we used in the article "Learn TCP: Environment setup". This example is just that the client sends a TCP connection to the server to establish a request packet, and then enters the waiting state.

Let's run this example again. We can see through Wireshark packet capture that the server in the virtual machine has made five timeout retransmission at intervals of 3 s, 6 s, 12 s, 24 s, A total of 45 s. However, when the Fifth [SYN, ACK] packet is sent, the server will continue waiting for 48 s, and the fifth retransmission also times out.

 

During the server retransmission period, run the netstat-anp TCP | findstr "192.168.56" command on the command line of the VM. The server is in the SYN_RCVD state.

 

SYN Flood Attack

As shown in the preceding experiment, when the server receives a TCP connection request from the client, it will send a [SYN, ACK] packet to enter the SYN_RCVD status. If you do not receive confirmation from the client, the server will attempt to re-upload and keep SYN_RCVD in State for a period of time (usually 30 seconds to 2 minutes ).

Due to the SYN_RCVD status on the server, SYN Flood attacks occur.

The so-called SYN Flood attack means that after a malicious client sends a SYN to the server, the server goes offline. Therefore, the server needs to wait 93 s by default (usually 30 seconds to 2 minutes, the above example is 93 s) before the connection is closed.

In this way, attackers can exhaust the server's SYN connection queue so that normal connection requests cannot be processed.

The server has many settings for how to avoid SYN Flood attacks. I will not introduce them here. If you are interested, you can check them online.

TIME_WAIT

In the normal state change of the client, the client proactively terminates the TCP connection, and then changes from the TIME_WAIT status to the CLOSED status.

 

The TIME_WAIT status is also known as the 2MSL (Maximum Segment Lifetime) Wait state. This setting is one of the four timers in TCP (next to the other three timers ).

RFC793 defines MSL as 2 minutes, but in implementation, MSL is generally 30 seconds, 1 minute or two minutes.

Why does TIME_WAIT exist?

There is a TIME_WAIT status, rather than directly converting to the CLOSED status, mainly for the following two reasons:

The client enters the TIME_WAIT status after sending the final confirmation [ACK], but this [ACK] package may be lost. In this case, the server will re-transmit [FIN, ACK]. That is to say, the MSL at TIME_WAIT stop 2 is used to cause TCP to send the final [ACK] again to lose this [ACK.

Prevent the packets in the last connection from appearing again after they get lost, and affect the new connection (after 2MSL, all the repeated packets in the last connection will disappear)

TIME_WAIT Effect

When one end enters the TIME_WAIT status, the result is that the port cannot be used again during the 2MSL period.

Let's look at an experiment. The operating system cannot detect Pcap. the TCP connection status of the client implemented by. Net. Therefore, a simple socket Client is implemented using Python and the port number of the client is forced to be 3333:

from socket import *import timeClient_ADDR = ("192.168.56.101", 3333)Server_ADDR = ("192.168.56.102", 8081)BUFSIZ = 1024client = socket(AF_INET, SOCK_STREAM)client.bind(Client_ADDR)client.connect(Server_ADDR)print "client connect to server"print "quit after 5 seconds"time.sleep(5)client.close()

After the program runs, you can run the netstat command to check that the client is in the "ESTABLISHED" status. After the connection is terminated, the client enters the "TIME_WAIT" status.

 

When the client program is run again, the following exception occurs, prompting that the port is occupied:

 

TIME_WAIT impact

From the above introduction, we can see that the end of the TCP connection will enter the TIME_WAIT status, and the TCP connection port of this end will be unavailable in 2MSL time.

In the case of highly concurrent short connections, there will be a lot of TIME_WAIT resources, and the available port resources of the system will be exhausted.

This illustrates how important HTTP KeepAlive is to the HTTP server. When KeepAlive is set, the browser will reuse a TCP connection to process multiple HTTP requests, slowing down the impact of TIME_WAIT.

Reset message segment

As for the reset packet segment, it is not a TCP status, but it is indeed an indispensable part of the TCP status change, so we will give a brief introduction here.

The reset packet segment is the TCP packet with the RST flag in the TCP header. Generally, TCP sends a [RST] packet to reset the TCP connection whenever a connection error occurs during the sending of a message segment.

Generally, the [RST] package is often encountered below:

Port that does not exist in the request

This time, we still run the example in "Learn TCP: establish the Environment". We just changed the target port to "1234 ".

EndPointInfo endPointInfo = new EndPointInfo();endPointInfo.SourceMac = "08:00:27:00:C0:D5";endPointInfo.DestinationMac = "08:00:27:70:A6:AE";endPointInfo.SourceIp = "192.168.56.101";endPointInfo.DestinationIp = "192.168.56.102";endPointInfo.SourcePort = 3330;//endPointInfo.DestinationPort = 8081;endPointInfo.DestinationPort = 1234;

Run the program. Because the "1234" port in the virtual machine is not a TCP listening port, it will receive the [RST] package from the virtual machine:

 

 

An error occurred while terminating a connection.

As we can see above, it takes four waves to terminate a TCP connection normally, which is also called orderly release ).

However, a connection is also released through the [RST] package, which is called abortive release ).

Terminating a connection abnormally has two advantages for the application:

Discard any band-sent data and immediately send the reset packet segment

The receiver of the [RST] package can distinguish whether the other end is shut down abnormally or normally.

Summary

This article describes two special statuses in TCP status transition: SYN_RCVD and TIME_WAIT.

The SYN_RCVD status will retransmit the [SYN, ACK] packet for a specific port on the server end within a period of time until the port times out or the client returns a response. During this period, this port on the server is occupied. The TIME_WAIT status indicates that the end of the TCP connection is automatically CLOSED, and the CLOSED status enters only after 2MSL is kept.

The second half briefly introduces the reset packet segment and the frequent use of the reset packet segment.