[Computer Network] TCP Protocol (2)

Hits: 0

Article directory

[packet capture]

Linux can use [tcpdump] to capture packets, save them in .pcap format ,
and then use [WireShark to] visualize and analyze (WireShark can capture packets directly on Windows)

# Client terminal one executes tcpdump to capture packets 
$ tcpdump -i any tcp and host 192.168 .3 .200  and port 80 -w http.pcap
 # Client terminal two executes curl command 
$ curl http: // 
# Client As soon as the terminal stops tcpdump to capture packets Ctrl+C and export http.pcap

HTTP is based on the TCP protocol for transport:

  • The first three packets are the packets for the TCP three-way handshake to establish the connection.
  • In the middle are the HTTP request and response packets
  • The last 3 packets are the waving packets of TCP disconnection (sometimes the server also closes the connection directly after receiving the FIN from the client, so ACK + FIN are sent at the same time, but usually four separate standard waves)

timeout retransmission

SYN packet loss for the first handshake

When the TCP handshake SYN packet initiated by the client for the first time does not receive the ACK from the server within the timeout period, it will retransmit the SYN packet over time. , 4s, 8s, 16s…), until the number of retransmissions of SYN packets reaches the value of tcp_syn_retries (default is 5), the client will no longer send SYN packets.

SYN+ACK packet loss in the second handshake

When the SYN and ACK packets of the second handshake are lost, the client will retransmit the SYN packet over time, and the server will also retransmit the SYN and ACK packet over time. The maximum number of retransmission times of client SYN packets is determined by tcp_syn_retries, and the default value is 5 times; the maximum number of retransmissions of server SYN and ACK packets is determined by tcp_synack_retries, and the default value is 5 times.

The specific process is shown in the figure:
after the server receives the SYN packet from the client, it will return SYN and ACK packets, but the client has not returned ACK. After the server times out, it retransmits the SYN and ACK packets. The SYN packet retransmitted by the client overtime arrives at the server. After the server receives it, it returns the SYN and ACK packets normally. The timeout timer is re-timed. After the timeout, the SYN + ACK is retransmitted. The transmitted SYN… So the timeout timer on the server side is only triggered once, and it is reset because it receives the SYN retransmitted by the client.
Finally, the client’s SYN timeout retransmission times reaches 5 times ( the default value of tcp_syn_retries is 5 times, which can be modified ), so it will not continue to send SYN packets.
After the client retransmits SYN for the last time, the server continues to retransmit SYN+ ACK up to 5 times ( the default value of tcp_synack_retries is 5 times, which can be modified ), and it will not continue to send.

ACK packet loss for the third [handshake]

When establishing a TCP connection, if the server cannot receive the ACK of the third handshake, the server will be temporarily in the SYN_RECV state, and the client will be in the ESTABLISHED state.

Since the server has never received the ACK of the TCP third handshake, it will retransmit the SYN and ACK packets until the number of retransmissions exceeds the tcp_synack_retries value (the default value is 5 times), and the server will disconnect the TCP connection.

The client will have two situations:
if the client does not send data packets, it has been in the ESTABLISHED state, and then after 2 hours, 11 minutes and 15 seconds, a “dead” connection can be found, so the client connection will be disconnected. (TCP’s keep-alive mechanism)
If the client sends a data packet and has not received an acknowledgment message for the data packet from the server, it will retransmit the data packet until the number of retransmissions exceeds the value of tcp_retries2 (the default value is 15). times), the client disconnects the TCP connection.

How long will the connection be disconnected if the client does not send data

TCP defines a time period. During this time period, if there is no connection-related activity, the TCP keep-alive mechanism will start to work. Every time interval, a “probe message” is sent, and the data contained in the probe message Very few, if there is no response to several consecutive probe packets, it is considered that the current TCP connection has died, and the system kernel will notify the upper-layer application of the error information.

Three-way handshake optimization


SYN of the first handshake (retransmission)

After the client sends SYN, the status changes to SYN_SENT. Under normal circumstances, the server will return SYN+ACK within a few milliseconds, but if the client does not receive the SYN+ACK message for a long time, it will resend the SYN packet, and the number of retransmissions Determined by the parameter tcp_syn_retries, the default is 5. Generally, after the first timeout retransmission is 1 second, the timeout interval increases by 2 times. After the fifth retransmission of SYN, wait for 32 seconds. If there is still no response ACK, the client will Terminate the three-way handshake. (Total time 1+2+4+8+16+32=63 seconds, about 1 minute)

The number of SYN retransmissions can be modified according to the stability of the network and the busyness of the target server, and the upper limit of the client’s three-way handshake time can be adjusted. For example, in intranet communication, the number of retries can be appropriately reduced to expose errors to applications as soon as possible.


SYN for the first handshake (SYN [queue] overflow)

When the server receives the SYN packet, it will immediately reply with a SYN+ACK packet, indicating that it has received the client’s serial number, and also sends its own serial number to the other party.
At this point, a new connection appears on the server, and the status is SYN_RCV. The Linux kernel establishes a semi-connection queue (uncompleted connection queue/SYN queue) to store new connections that have not completed the three-way handshake. If the queue overflows, new connections cannot be established. This is the case with SYN attacks.

Methods to deal with SYN queue overflow: 1. Adjust the size of the SYN queue, not only tcp_max_syn_backlog, but also somaxconn and backlog (the size of the accept queue), otherwise it is invalid to simply increase the syn queue 2. Control the operation after overflow, For example, discard directly (continue to keep the connection, but discard the packets after the queue is full), or return RST (tell the client to abolish the handshake process and the connection); 3. Start the SYN cookie, and the SYN received for the new connection will no longer be placed Enter the SYN queue, calculate a cookie, and put it into the SYN+ ACK returned to the client. After receiving the ACK from the client, take out the cookie for verification, and enter the accept queue directly after the connection is confirmed to be legal.

ACK+SYN of the second handshake (retransmission)

If the client does not receive ACK+SYN, and the server cannot receive the ACK response from the client, it will resend ACK+SYN. The number of retransmissions is determined by tcp_synack_retries, and the default is 5. However, since the client does not receive SYN+ACK, it will also resend the SYN, so the count timing of each retransmission by the server will be interrupted and reset by the client’s SYN. Until the client resends the SYN for the last time, after the server responds normally with ACK+SYN, it will continue to resend 5 times. If the client still does not receive a response, the connection will be terminated.

When the network is busy and unstable, the packet loss will become serious. At this time, the tcp_synack_retries parameter should be adjusted to increase the number of retransmissions, otherwise, the number of retransmissions can be reduced.

ACK for the third handshake (accept queue)

After the server receives the ACK, the connection is established successfully. At this time, the kernel will remove the connection from the semi-connection queue, then create a new full connection, add it to the accept queue, and wait for the process to call the accept function to take out the connection. If the process cannot call the accept function in time, the accept queue (also called the full connection queue) will overflow, and eventually the established TCP connection will be discarded.

The response method of accept queue overflow: 1. Adjust the accept queue size, min(somaxconn, backlog), the former is the default Linux kernel parameter 128, the latter is generally 511, both can be adjusted, 2. Control the operation after overflow, such as Directly discard (continue to maintain the connection), or send RST to the client (indicates abolishing the handshake process and the connection)

If it is judged to be a short-term overflow (burst traffic), the following packets are generally chosen to be discarded. The connection status of the client is still ESTABLISHED. As long as the server does not reply with an ACK, the client’s request will be”retransmitted” multiple times. If the process on the server is only temporarily busy and the accept queue is full, then when the accept queue is empty, the request packet received again will still trigger the server to successfully establish a connection because it contains an ACK.

Discarding can improve the success rate of connection establishment. Only when you are very sure that the TCP full connection queue will overflow for a long time, you need to set the tcp_abort_on_overflow parameter to 1 and send an RST reset message to the client to tell the client that the connection has failed.

Three-way handshake process

The standard TCP three-way connection is the picture above, and only the third handshake can carry data. HTTP requests must be sent after an RTT (one round trip time from client to server)

After the Linux 3.7 kernel version, the TCP Fast Open function is provided, which can reduce the delay of establishing a TCP connection.

You may also like...

Leave a Reply

Your email address will not be published.