Byte interview: under what scenario will syn packets be discarded?

Hello everyone , I'm Xiao Lin .

There was a reader in the autumn recruitment interview , Asked such a question ：SYN When and under what circumstances will the message be discarded ？

good heavens , Have you asked so many details in the interview now ？

But then again , This problem is also related to work , Because I met such a strange time at work , The client initiated a connection to the server , But the connection was not established , Through packet capture analysis, it is found that , The server is receiving SYN Message , But there was no reply SYN+ACK（TCP The second handshake ）, explain SYN The message is ignored by the server , Then the client has been timeout retransmission SYN message , Until the maximum number of retransmissions is reached .

Next , I'll give you what I've met SYN Two scenarios in which messages are discarded ：

Turn on tcp_tw_recycle Parameters , And in NAT In the environment , cause SYN The message is discarded

TCP Two queues are full （ Semi and full connection queues ）, cause SYN The message is discarded

Cheating father tcp_tw_recycle
TCP During the four waves , The active disconnect will have a TIME_WAIT The state of , This state will continue 2 MSL Before it turns into CLOSED state .

stay Linux Under the operating system ,TIME_WAIT The duration of the state is 60 second , This means that 60 Seconds , The client will always occupy this port . Need to know , Port resources are also limited , Generally, the ports that can be opened are 32768~61000 , You can also specify the range through the following parameter settings ：

 net.ipv4.ip_local_port_range
1
that , If you take the initiative to disconnect the connected party TIME_WAIT Too many states , Full of port resources , You cannot create a new connection .

however TIME_WAIT State is not a decoration function , It has two functions ：

Prevent old packets with the same Quad from being received , That is to prevent data in historical connections , Accepted by the following connection , Otherwise, it will cause the subsequent connection to receive an invalid data ,
Guarantee 「 Passive close connection 」 One side can be properly shut down , That is to guarantee the final ACK It allows the passive shutdown party to receive , To help it shut down properly ;
however ,Linux The operating system provides two system parameters that can be used to quickly recycle data TIME_WAIT State connection , Both parameters are off by default ：

net.ipv4.tcp_tw_reuse, If this option is turned on , client （ Connection initiator ） Calling connect() Function time , The kernel will randomly find one time_wait The state is more than 1 Second connections are reused for new connections , So this option only applies to the connection initiator .
net.ipv4.tcp_tw_recycle, If this option is turned on , Allow in TIME_WAIT State connections are quickly recycled ;
To make these two options work , There is a prerequisite , Is to open TCP Time stamp , namely net.ipv4.tcp_timestamps=1（ Default is 1)）.

tcp_tw_recycle In the use of the NAT It's not safe under the network ！

For servers , If it's turned on at the same time recycle and timestamps Options , It will open a system called 「 per-host Of PAWS Mechanism 」.

First of all, let's talk about what is PAWS Mechanism ？

tcp_timestamps After the option is turned on , PAWS The mechanism will automatically turn on , Its function is to prevent TCP The serial number in the package is bypassed .

Normally, everyone TCP Bags will have their own unique SEQ, appear TCP Packets are multiplexed when retransmitted SEQ Number , So that the receiver can pass SEQ Number to determine the uniqueness of the packet , It can also judge whether the data is retransmitted when a data packet is repeatedly received . however TCP This SEQ The number is limited , altogether 32 bit,SEQ Start with incremental , Overflow from 0 Start increasing again in turn .

So when SEQ After overflow occurs, it simply passes through SEQ The number cannot identify the uniqueness of the packet , When a packet is delayed or delayed due to retransmission, the data transmitted by the connection may be destroyed , such as ：

Upper figure A The packet has been retransmitted , And in SEQ No. 1 runs out again from A When increasing , For the first time A The packet arrived late Server, In this case, if there is no other mechanism to ensure ,Server You'll think it's late A The packet is correct and received , Instead, it will be sent for the third time SEQ by A Packet discarding , Cause data transmission error .

PAWS To avoid this problem , In the open tcp_timestamps In case of option , All from one machine TCP Packets will be sent with a time stamp ,PAWS Both sides of the connection are required to maintain the timestamp of the last received packet （Recent TSval）, Every time a new packet is received, the timestamp value in the packet will be read Recent TSval It's worth comparing , If it is found that the timestamp in the received packet is not incremented , Indicates that the packet is expired , The packet will be discarded directly .

For the example in the figure above, I have PAWS The mechanism can do it after receiving Delay Arrived at A When packet No , Recognize that it is an expired packet and throw it away .

What is per-host Of PAWS Mechanism? ？

I mentioned earlier , Open the recycle and timestamps Options , Will open a kind of called per-host Of PAWS Mechanism .per-host It's right 「 Opposite end IP do PAWS Check 」, Not right 「IP + port 」 Four tuples do PAWS Check .

But if the client network environment is used NAT gateway , Then each machine in the client environment passes through NAT After gateway , It's going to be the same IP Address , In the view of the server , It's like just dealing with a client , Can't distinguish .

Per-host PAWS Mechanism utilization TCP option Inside timestamp Field growth to determine crosstalk data , and timestamp According to the client's respective CPU tick The resulting value .

When the client A adopt NAT Gateway and server establishment TCP Connect , Then the server automatically shuts down and quickly recycles TIME-WAIT After the connection of the State , client B Also through NAT Gateway and server establishment TCP Connect , Note that the client A and client B Because after the same NAT gateway , So use the same IP Address and server establishment TCP Connect , If the client B Of timestamp Than client A Of timestamp Small , Well, due to the of the server per-host Of PAWS The role of mechanism , The server will discard the client host B It's from SYN package .

therefore ,tcp_tw_recycle In the use of the NAT There are problems under the network , If it's right TCP Four tuples do PAWS Check , Not right. 「 same IP do PAWS Check 」, Then there won't be this problem .

Many blogs on the Internet say open tcp_tw_recycle Parameters to optimize TCP, I believe you're a ghost , The bad old man is very bad ！

tcp_tw_recycle stay Linux 4.12 After version , Directly cancels this parameter .

accpet The queue is full
stay TCP Three handshakes ,Linux The kernel maintains two queues , Namely ：

Semi connected queues , Also known as SYN queue ;
Full connection queue , Also known as accepet queue ;
The server receives the client initiated SYN After the request , The kernel stores the connection in the semi connection queue , And respond to the client SYN+ACK, Then the client will return ACK, The server receives the third handshake ACK after , The kernel will remove the connection from the semi connection queue , Then create a new full connection , And add it to accept queue , Wait for the process to call accept Function to take out the connection .

The half connection queue is full
When the server causes syn attack , It may lead to TCP The half connection queue is full , At this time, the back came syn Bags will be discarded .

however , If it's on syncookies function , Even if the semi connected queue is full , And will not throw away syn package .

syncookies That's what it does ： The server calculates a value based on the current state , Put it on your own side SYN+ACK Send out in a message , When the client returns ACK When the message , Take out the value to verify , If the legitimate , Think the connection is successful , As shown in the figure below .

Turn on syncookies function

syncookies The parameter has the following three values ：

0 value , Indicates that the feature is turned off ;
1 value , Only if SYN When the semi connection queue cannot be placed , Turn it on again ;
2 value , It means unconditional opening function ;
So in response to SYN When the attack , Just set it to 1 that will do ：

Here are some defenses SYN The way to attack ：

Increase semi connection queue ;
Turn on tcp_syncookies function
Reduce SYN+ACK Number of retransmissions
Mode one ： Increase semi connection queue

To increase the semi connection queue , We learned that we can't just increase tcp_max_syn_backlog Value , It needs to be increased together somaxconn and backlog, That is to increase the full connection queue . otherwise , It's just a simple increase tcp_max_syn_backlog It's invalid .

increase tcp_max_syn_backlog and somaxconn The method is to modify Linux Kernel parameters ：

increase backlog The way , Every Web The service is different , such as Nginx increase backlog The method is as follows ：

Last , After changing the above parameters , To restart Nginx service , Because the semi connection queue and the full connection queue are in listen() The initialization of the .

Mode two ： Turn on tcp_syncookies function

Turn on tcp_syncookies The way it works is simple , modify Linux Kernel parameters ：

Mode three ： Reduce SYN+ACK Number of retransmissions

When the server receives SYN When the attack , There will be a lot of people in SYN_REVC State of TCP Connect , In this state TCP Will the retransmission SYN+ACK , When retransmission exceeds the maximum number of times , Will disconnect .

So for SYN Scenes of attack , We can reduce SYN+ACK The number of retransmissions , In order to speed up in SYN_REVC State of TCP Connection is broken .

The full connection queue is full
When the server concurrently processes a large number of requests , If TCP accpet Queue too small , Or the application calls accept() Not in time , Will cause accpet The queue is full , Then subsequent connections will be discarded , In this way, the number of server-side requests will not go up .

We can go through ss Order to see accpet Queue size , stay 「LISTEN state 」 when ,Recv-Q/Send-Q The meaning is as follows ：

Recv-Q： At present accpet The size of the queue , That is, three handshakes have been completed and waiting for the server accept() Of TCP Number of connections ;
Send-Q： At present accpet Maximum queue length , The output above shows monitoring 8088 Port of TCP Service process ,accpet The maximum length of the queue is 128;
If Recv-Q Is larger than Send-Q, It means that accpet When the queue is full .

To solve this problem , We can ：

turn up accpet The maximum length of the queue , The way to turn it up is by turning it up backlog as well as somaxconn Parameters .
Check why the system or code calls accept() Not in time ;
About SYN Queue and accpet queue , I wrote a very detailed article before ：TCP What happens when the semi connection queue and full connection queue are full ？ How to deal with it ？

Okay , I'll share it with you today .

If a big man knows other scenes , Welcome to the comment area to share , Let me also increase my knowledge, ha ha .
————————————————
Copyright notice ： This paper is about CSDN Blogger 「 Kobayashi coding」 The original article of , follow CC 4.0 BY-SA Copyright agreement , For reprint, please attach the original source link and this statement .
Link to the original text ：https://blog.csdn.net/qq_34827674/article/details/122038574