linux内核 与 web服务器 相关的某些参数（sysctl）

缘由

昨天， 深入理解nginx的书到了，之前看了不少pdf的版本，这本书与 深入剖析nginx相比，我觉得阅读难度更低一些，或者是说 深入理解nginx讲的更细和更有条理一些。

我今天仔细看了第一章，打算以后一天一章。并且选取某一个我觉得比较感兴趣的知识点总结一下。

今天总结：linux内核 与 web服务器 相关的某些参数（sysctl）

linux内核的参数

从本书这一点点的理解来看，linux作为底层操作系统，实现了最基本的功能。但是某些功能的没有开启，而某些功能设置的限制的并不适合web服务器的运作。所以我们需要改变linux内核的参数，使其更适合web服务器发挥作用。那么这里有两个问题，一个就是如何改变，另一个就是如何才是最适合。

• 关于如何改变，可以选择修改操作系统的配置文件：/etc/sysctl.conf，另外使用sysctl命令也修改、查看某一个内核参数的命令，具体就自己man一下吧
• 怎么样才适合呢？其实这是更具体的业务有关的，常用的web服务器有：
  
  1、静态web内容服务器
  2、反向代理服务器
  
  这两种服务器的功能不同，需要操作系统提供的功能也不完全一样，提供功能的强度（参数大小）也不完全一样。
  

举例

nginx为我们提供一种常用的配置，采用修改/etc/sysctl.conf文件的方式，将参数设定为如下图所示：

• 这是一种web服务器需要的通用功能：使nginx能够支持更多的并发请求

在解释其含义之前，我在我的电脑上做了测试，查看了上述所有参数的值,如下所示：

asd@asd-desktop:~$ sysctl fs.file-max 
fs.file-max = 999999
asd@asd-desktop:~$ sysctl net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_reuse = 0
asd@asd-desktop:~$ sysctl net.ipv4.tcp_keepalive_time
net.ipv4.tcp_keepalive_time = 7200
asd@asd-desktop:~$ sysctl net.ipv4.tcp_fin_timeout 
net.ipv4.tcp_fin_timeout = 60
asd@asd-desktop:~$ sysctl net.ipv4.tcp_max_tw_buckets 
net.ipv4.tcp_max_tw_buckets = 65536
asd@asd-desktop:~$ sysctl net.ipv4.ip_local_port_range 
net.ipv4.ip_local_port_range = 32768	61000
asd@asd-desktop:~$ sysctl net.ipv4.tcp_rmem 
net.ipv4.tcp_rmem = 4096	87380	6291456
asd@asd-desktop:~$ sysctl net.ipv4.tcp_wmem 
net.ipv4.tcp_wmem = 4096	16384	4194304
asd@asd-desktop:~$ sysctl net.core.netdev_max_backlog 
net.core.netdev_max_backlog = 1000
asd@asd-desktop:~$ sysctl net.core.rmem_default 
net.core.rmem_default = 163840
asd@asd-desktop:~$ sysctl net.core.wmem_default 
net.core.wmem_default = 163840
asd@asd-desktop:~$ sysctl net.core.rmem_max 
net.core.rmem_max = 131071
asd@asd-desktop:~$ sysctl net.core.wmem_max 
net.core.wmem_max = 131071
asd@asd-desktop:~$ sysctl net.ipv4.tcp_syncookies 
net.ipv4.tcp_syncookies = 1
asd@asd-desktop:~$ sysctl net.ipv4.tcp_max_syn_backlog 
net.ipv4.tcp_max_syn_backlog = 512
asd@asd-desktop:~$ 

其中fs.file-max 是我通过/etc/sysctl.conf实际的改动了，所以和书上的一直。

常见参数的含义

参数名	含义	更多说明
fs.file-max	一个进程最多能打开的文件数	主要影响nginx的worker进程的打开文件的数量，影响并发
net.ipv4.tcp_tw_reuse	为1时，表示允许TIME_WAIT状态的socket重新用于新的TCP连接	web服务器总是存在大量TIME_WAIT的socket
net.ipv4.tcp_keepalive_time	TCP发送keepalive的频率，默认为两小时	设置的小，能够清理无效连接
net.ipv4.tcp_fin_timeout	服务器主动关闭连接时，socket保持在FIN_WAIT_2的状态的时间
net.ipv4.tcp_max_tw_buckets	允许TIME_WAIT socket存在的最大值，超过这个值就会打印警告信息， 并清除多余TIME_WAIT socket	过多的TIME_WAIT会使服务器变慢
net.ipv4.ip_local_port_range	UDP和TCP的连接中本地端口的取值范围
net.ipv4.tcp_rmem	TCP接受缓存中的（用于TCP接受滑动窗口）最小值、默认值、最大值
net.ipv4.tcp_wmem	TCP发送缓存中的（用于TCP发送滑动窗口）最小值、默认值、最大值
net.core.netdev_max_backlog	网卡接受速度大于内核处理速度时，会有一个队列维持这些数据包 这个值是这个数据包的最大值
net.core.rmem_default	内核套接字接收缓冲区默认的大小
net.core.wmem_default	内核套接字发送缓冲区默认的大小
net.core.rmem_max	内核套接字接收缓冲区最大的大小
net.core.wmem_max	内核套接字发送缓冲区最大的大小
net.ipv4.tcp_syncookies	与性能无关，为1表示解决了TCP的SYN攻击	开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击
net.ipv4.tcp_max_syn_backlog	表示SYN队列的长度，默认为1024，加大队列长度可以容纳更多等待连接的网络连接数。

可以看出，理解上面的内容需要更多TCP/IP的知识，也是暴露了我对这方面知识的不足，我以后会单开一篇写自己对TCP/IP的理解。现在对里面几个要点进行解释：

补充常识

SYN攻击

（摘自百度百科）

SYN（synchronous）是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN+ACK应答表示接收到了这个消息，最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。

SYN攻击属于DDoS攻击的一种，它利用 TCP协议缺陷 ，通过发送大量的半连接请求，耗费CPU和内存资源。SYN攻击除了能影响主机外，还可以危害路由器、防火墙等网络系统，事实上SYN攻击并不管目标是什么系统，只要这些系统打开TCP服务就可以实施。服务器接收到连接请求（syn= j），将此信息加入未连接队列，并发送请求包给客户（syn=k,ack=j+1），此时进入SYN_RECV状态。当服务器未收到客户端的确认包时，重发请求包，一直到超时，才将此条目从未连接队列删除。配合IP欺骗，SYN攻击能达到很好的效果，通常，客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

TCP协议的缺陷：
一个正常的TCP连接需要三次握手，首先客户端发送一个包含SYN标志的数据包，其后服务器返回一个SYN/ACK的应答包，表示客户端的请求被接受，最后客户端再返回一个确认包ACK，这样才完成TCP连接。在服务器端发送应答包后，如果客户端不发出确认，服务器会等待到超时， 期间这些半连接状态都保存在一个空间有限的缓存队列中；如果大量的SYN包发到服务器端后没有应答，就会使服务器端的TCP资源迅速耗尽，导致正常的连接不能进入，甚至会导致服务器的系统崩溃。

TIME_WAIT

（摘自： TCP/IP TIME_WAIT状态原理）

通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。如下图所示，

客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间，进入CLOSED状态。

• MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间IP数据包将在网络中消失 。

TCP/IP协议就是这样设计的，是不可避免的。主要有两个原因:

1. 可靠地实现TCP全双工连接的终止
   TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态 。
2.  允许老的重复分节在网络中消逝 
   TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。

keepalive

在TCP中有一个Keep-alive的机制可以检测死连接，原理很简单，TCP会在空闲了一定时间后发送数据给对方：

1. 如果主机可达，对方就会响应ACK应答，就认为是存活的。
2. 如果可达，但应用程序退出，对方就发RST应答，发送TCP撤消连接。
3. 如果可达，但应用程序崩溃，对方就发FIN消息。
4. 如果对方主机不响应ack, rst，继续发送直到超时，就撤消连接。

这个时间就是默认的二个小时。