以下内容纯属虚构,切勿轻易相信!

• 众所周知,tcp/ip三次握手和四次挥手,均由syn/ack/fin三个标志位报文决定,但是这三个标志位报文,并不是说在构建连接的时候只发送一次的,因为协议不知道网络状况. 故而就存在了以下参数,可以调节发送次数
• net.ipv4.tcp_syn_retries
  • 这个参数从字面上来看就是syn标志位报文的重试次数,什么时候发送syn标志位呢?三次握手中,请求端第一次构建连接的时候,默认是5次,但是对于一个处于网络状况好的请 求端,5次显然是多了,因此,我们来个2
• net.ipv4.tcp_synack_retries = 5
  • 这个参数从字面上来看是syn+ack标志位报文的重试次数,什么时候发送syn+ack标志位呢?三次握手中,响应端为了应答请求端的syn标志位报文,同时请求构建的时候,默认是5次,和上面一样,网络环境好,就来个2.
  • 这里还牵扯到一个东西,ddos攻击里面有一个就是针对syn+ack报文的攻击,也就是说,如果有疯子一直大量发送syn标志位,但是服务器需要发送syn+ack来响应,但是那个疯子却不回复ack标志位,导致服务器需要一直重试到次数结束.
  • 且服务器的syn等待队列是有上限的,因为大量疯子的syn报文占用了,那么服务器就接收不到正常的syn报文请求了.这里还有一个响应端syn等待队列的参数
• net.ipv4.tcp_max_syn_backlog 疑问项?
  • 这个参数就是定义响应端的SYN_RCVD状态队列,默认是1024,根据服务器性能和负载情况,可以调高此数值,比如8192
  • 假设被ddos syn flood了,syn等待队列也溢出了,该怎么搞?可以启用net.ipv4.tcp_syncookies
  • 到这里,可能有人发现,设定了这个参数,但是服务器在并发测试的时候,发现SYN_RCVD的状态还是128或者512(内核小于2.6.20),其原因如下:
    • 服务器的被请求源于服务的监听端口,重启服务,即重新调用listen函数
    • 在内核大于2.6.20的时候,listen函数会在调用的时候读取内核参数net.core.somaxconn的值,它的默认值是128,来确定backlog的大小
    • 在内核小于2.6.20的时候,listen函数有一个固定值TCP_SYNQ_HSIZE这个单向链表数组,它的默认值是512,你可以修改这个值,确保这个值*16 <= net.ipv4.tcp_max_syn_backlog,这个链表的位置在$KERNEL/include/net/tcp.h
    • 但是不管你如何修改上面的参数,如果你不修改服务中listen的显性参数backlog,那么服务依然会限制
    • nginx中是这么修改的listen 80 default backlog = 8192
    • php-fpm中是这么修改的listen.backlog = 8192
• net.core.netdev_max_backlog 疑问项?
  • 如果说tcp_max_syn_backlog是针对syn半开连接的话,这个参数就是针对一个整体的,意思就是说当内核处理不过来的时候,多余的就先扔到队列中
• net.ipv4.tcp_syncookies
  • 这个参数的作用是当syn等待队列溢出的时候,就给请求端发送syncookies,直接绕过三次握手,构建连接.但这违反了tcp/ip协议,可能会影响其他服务,所以如果不确定是攻击,而是正常负载,则不要开启

OK,假设我们内核是大于2.6.20的,那么我们如果想要实现以下场景:

1. 一个服务器,加载的是nginx服务,他正在接收请求,请求越来越多,他处理不过来了,所以将多余的请求扔到了一个队列中(队列上限8192);
   • net.core.netdev_max_backlog = 8192
2. 但是这时候又来了一大批奇怪的请求,服务器怎么回应,这些请求源都不响应,且这些请求量也很大,故而服务器将其扔到了另一个队列(队列上限8192);
   • net.core.somaxconn = 8192
   • net.ipv4.tcp_max_syn_backlog = 8192
   • listen 80 default backlog = 8192
3. 为了防止这些垃圾请求过于占用资源,服务器规定回应报文(ack+syn)的次数为2
   • net.ipv4.tcp_synack_retries = 2

到目前为止,三次握手已经走了一半,继续路程~