nginx学习笔记一（Linux内核参数延申）

这篇文章最要是在阅读《深入理解niginx模块开发与架构解析》书时，一些个人笔记与一些内容得延申。
主要内容：Linux内核参数
书本内容：在阅读第一章时，提及到Linux搭建nginx做为高性能web服务器时，需要对Linux内核做一些调优，分别是以下的内核参数

fs.file--max = 999999
net.ipv4.tcp_te_reuse = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.ip_local_port_range = 1024    61000
net.ipv4.tcp_rmem = 4096  32768  262142
net.ipv4.tcp_wmem = 4096 32768 262142
net.core.netdev_max_backlog = 8096
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 2097152
net.core.wmem_max = 2097152
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn.backlog = 1024

下面给出这些选项得书中解释和个人理解，以及一些延申

file–max
书中说明: 表示进程可以同时打开的最大句柄数。
个人理解: 看到这里的时候第一时间想到的是，ulimit -a查看得到的最大文件描述符数有和这个有什么区别。
于是查看了file–max和ulimit的描述，如下
/proc/sys/fs/file–max
This file defines a system-wide limit on the number of open files for all processes. (Seealso setrlimit(2), which can be used by a process to set the per-process limit,RLIMIT_NOFILE, on the number of files it may open.) If you get lots of error messagesabout running out of file handles, try increasing this value:
这里描述的 file–max就是系统所有进程能打开文件描述符的上限了
ulimit
Provides control over the resources available to the shell and to processes started by it, on systems that allow  such control.
这里的理解就是当前shell用户和shell用户运行的进程能打开的文件描述符上限

tcp_tw_reuse
书中说明: 这个参数设置为1，表示允许将TIME_WAIT状态的socket重新用于新的TCP连接。
个人理解: 相信大家对TCP的三次握手，四次挥手都比较了解，在TCP的四次挥手中，主动方发出FIN包后进入FIN_WAIT1状态，收到对方的ACK回复后进入FIN_WAIT2状态，然后被动方在没有数据发送后，发送FIN给主动关闭方，然后主动关闭方进入TIME_WAIT状态。主动关闭方会在TIME_WAIT等待2*MSL时间，然后再对资源回收。这里说明一下为什么要将tcp_tw_reuse设置成1，来让TIME_WAIT状态的socket重新用于新的TCP连接？TCP断开连接的目的就是要回收socket连接资源，拆除信道等，如果服务器存在大量的TIME_WAIT状态下的socket，会造成大量的浪费，可能导致新的连接无法接入。这里只做大概的解释，TIME_WAIT的快速回收也会造成其它的问题，详细请看这两篇文章从 TCP 三次握手说起：浅析TCP协议中的疑难杂症 ( 1 )和从 TCP 三次握手说起：浅析TCP协议中的疑难杂症 ( 2 )

tcp_keepalive_time
书中说明: 这个参数表示当keepalive启动时，TCP发送keepalive消息的频度。默认是2小时，若将其设置的小一些，可以更快的清理无效的连接。
个人理解: TCP连接一般会分为长连接和短连接。长连接是指连接双方会在一定时间内保存连接，不管是有无数据交流。短连接是在发送方发送完数据后，就会主动把连接关闭。而在长连接中，在无数据传输时，服务端如何知道客户端是否已经死亡，如何死亡就要将连接断开，回收资源，不然会造成资源浪费。而这个探测客户端是否存活，就是keepalive机制。其中有三个相关的参数tcp_keepalive_time（keepalive的空闲时长），tcp_keepalive_intvl（keepalive探测包的发包间隔），tcp_keepalive_probes（keepalive的发包次数）。也就是说，当一个连接在tcp_keepalive_time时间内没有收到客户端的数据传输的话，服务端就会发送keepalive包，如果客户端没有对keepalive包做回复的话，服务端就会以tcp_keepalive_intvl间隔总共发送tcp_keepalive_probes个包，如果都没有回复的话，就断开连接，回收资源。

tcp_fin_timeout
书中说明: 这个参数表示当服务器主动关闭连接时，socket保存在FIN_WAIT-2状态的最大时间。
个人理解: 这个参数比较理解，不理解的可以再去看看上面提及的两篇TCP的文章。

tcp_max_tw_buckets
书中说明: 这个参数表示操作系统允许TIME_WAIT套接字数量的最大值，如果超过这个数字，TIME_WAIT套接字将立刻被清楚并打印告警信息。改参数默认为180000，过多的TIME_WAIT套接字会使web服务器变慢。
个人理解: 这个清除TIME_WAIT的套接字还是比较好理解的，除了设置tcp_max_tw_buckets的值外，还能使用RST包从外部清除。具体如何还是看上面的那两篇文章。

tcp_max_syn_backlog
书中说明: 这个参数表示TCP三次握手建立阶段接收SYN请求队列的最大长度，默认是1024，将其设置大一些可以使出现Nginx繁忙来不及accept新连接的情况时，Linux不至于丢失客户端的连接请求。

ip_local_port_range
书中说明: 这个参数定义UDP和TCP连接本地（不包括连接的远端）端口的取值范围
个人理解: 书中说明已经很清晰了，如果想要为一些服务预留特定的端口，避免被TCP或UDP的连接占用了端口（特别是TCP的长连接）导致服务无法启动的问题。可以设置ip_local_reserved_ports这个参数

net_ipv4.tcp_rmem
书中说明: 这个参数定义了TCP接收缓存（用于TCP接收滑动窗口）的最小值，默认值，最大值
个人理解: 我们重新设置TCP缓存大小的范围在最小值和最大值的区间

net.ipv4_tcp_wmem
书中说明: 这个参数定义了TCP发送缓存（用于TCP发送滑动窗口）的最小值，默认值，最大值
个人理解: 如上

netdev_max_backlog
书中说明: 当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。这个参数表示该队列的最大值

rmem_default
书中说明: 这个参数表示内核套接字接收缓存区默认大小

wmem_default
书中说明: 这个参数表示内核套接字发送缓存区默认大小

rmem_max
书中说明: 这个参数表示内核套接字接收缓存区域最大大小

wmem_max
书中说明: 这个参数表示内核套接字发送缓存区域最大大小
个人理解: 这里解释一下内核缓存区和tcp的滑动窗口关系，在网络数据传输整个过程中，网卡接收到数据包时，会将这些数据包保存到一个缓存区域（内核接收缓存区域），然后内核根据数据是属于那个TCP连接的，将数据移到具体的TCP接收缓存中。然后应用程序在从TCP的接收滑动窗口获取数据。更新滑动窗口大小。

tcp_syncookies
书中说明: 用于解决TCP的SYN攻击
个人理解：
SYN半连接队列：Server端收到Client的SYN包并回复SYN,ACK包后，该连接的信息就会被移到一个队列，这个队列就是SYN半连接队列(此时TCP连接处于 非同步状态 )

accept连接队列：Server端收到SYN,ACK包的ACK包后，就会将连接信息从[1]中的队列移到另外一个队列，这个队列就是accept连接队列(这个时候TCP连接已经建立，三次握手完成了) 用户进程调用accept()系统调用后，该连接信息就会从[2]中的队列中移走

SYN攻击：也就是服务端短时间接收到大量的SYN请求连接包，然后回复SYN ACK包，就将连接放到SYN半连接队列中，但是客户端并没有回复服务端的SYN的请求，然后服务端就开始重传，而这些SYN半连接都是需要消耗内存。

SYN Cookie：对TCP服务器端的三次握手做一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器接收到TCP SYN包并返回TCP SYN + ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。这个cookie作为将要返回的SYN ACK包的初始序列号。当客户端返回一个ACK包时，根据包头信息计算cookie，与返回的确认序列号(初始序列号 + 1)进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。