内核参数优化之2-1 tcp/ip 标志位报文解析

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

---

 

• 众所周知,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

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