linux网络调优问题

转载自:

网络调优

tcp连接保持管理：
如果在该参数指定时间内某条连接处于空闲状态，则内核向远程主机发起探测

net.ipv4.tcp_keepalive_time = 7200

内核向远程主机发送的保活探测的时间间隔

net.ipv4.tcp_keepalive_intvl = 75

内核发送保活探测的最大次数，如果探测次数大于这个数，则断定远程主机不可达，则关闭该连接并释放本地资源
一个连接7200s空闲后，内核会每隔75秒去重试，若连续9次则放弃。这样就导致一个连接经过2h11min的时间才能被丢弃，降低该值能够尽量减小失效连接所占用的资源，而被新的连接所使用。

net.ipv4.tcp_keepalive_probes = 9

tcp连接管理：
表示在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

net.core.netdev_max_backlog=3000

控制每个端口的tcp syn的队列长度，来自客户端的连接请求需要排队，直至服务器接受，如果连接请求数大于该值，则连接请求会被丢弃，客户端无法连接服务器，一般服务器要提高此值

net.ipv4.tcp_max_syn_backlog = 1024

控制内核向某个socket的ack,syn段（三次握手的第二次握手）重新发送响应的次数，降低此值可以尽早检测到来自远程主机的连接失败尝试

net.ipv4.tcp_synack_retries = 5

控制内核向已建立连接的远程主机重新发送数据的次数，降低此值，可以尽早的检测连接失效

net.ipv4.tcp_retries2 = 15

SYN Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

net.ipv4.tcp_syncookies = 1

如下的sysctl命令用于改变安全设置，但是它也可以防止网络性能的下降。这些命令被设置为缺省值。

关闭如下参数可以防止黑客对服务器IP地址的攻击

sysctl -w net.ipv4.conf.eth0.accept_source_route=0
sysctl -w net.ipv4.conf.lo.accept_source_route=0
sysctl -w net.ipv4.conf.default.accept_source_route=0
sysctl -w net.ipv4.conf.all.accept_source_route=0

以下命令使服务器忽略来自被列入网关的服务器的重定向。因重定向可以被用来进行攻击，所以我们只接受有可靠来源的重定向

sysctl -w net.ipv4.conf.eth0.secure_redirects=1
sysctl -w net.ipv4.conf.lo.secure_redirects=1
sysctl -w net.ipv4.conf.default.secure_redirects=1
sysctl -w net.ipv4.conf.all.secure_redirects=1

另外，你可以配置接受或拒绝任何ICMP重定向。ICMP重定向是器传输信息的机制。比如，当网关接收到来自所接网络主机的Internet数据报 时，网关可以发送重定向信息到一台主机。网关检查路由表获得下一个网关的地址，第二个网关将数据报路由到目标网络。关闭这些重定向得命令如下：

sysctl -w net.ipv4.conf.eth0.accept_redirects=0
sysctl -w net.ipv4.conf.lo.accept_redirects=0
sysctl -w net.ipv4.conf.default.accept_redirects=0
sysctl -w net.ipv4.conf.all.accept_redirects=0

如果这个服务器不是一台，那么它不会发送重定向，所以可以关闭该功能：

sysctl -w net.ipv4.conf.eth0.send_redirects=0
sysctl -w net.ipv4.conf.lo.send_redirects=0
sysctl -w net.ipv4.conf.default.send_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0

配置服务器拒绝接受广播风暴或者smurf 攻击attacks:

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

忽略所有icmp包或者pings:

sysctl -w net.ipv4.icmp_echo_ignore_all=1

有些路由器针对广播祯发送无效的回应，每个都产生警告并在内核产生日志。这些回应可以被忽略：

sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1

下边的命令用来对连接数量非常大的服务器进行调优。
表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0

net.ipv4.tcp_tw_reuse = 1

表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0

net.ipv4.tcp_tw_recycle = 1

tcp_fin_timeout
默认值是 60
对于本端断开的socket连接，TCP保持在FIN_WAIT_2状态的时间。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。默认值为 60 秒。过去在2.2版本的内核中是 180 秒。您可以设置该值?但需要注意?如果您的机器为负载很重的web服务器?您可能要冒内存被大量无效数据报填满的风险?FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1 ?因为它们最多只吃 1.5K 的内存?但是它们存在时间更长。另外参考 tcp_max_orphans。
CLOSE_WAIT状态的生成原因
如果服务器程序APACHE处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！
假设CLIENT端主动断掉当前连接，那么双方关闭这个TCP连接共需要四个packet：
Client —> FIN —> Server
Client < --- ACK <--- Server
这时候Client端处于FIN_WAIT_2状态；而Server 程序处于CLOSE_WAIT状态。
Client <--- FIN <--- Server
这时Server 发送FIN给Client，Server 就置为LAST_ACK状态。
Client ---> ACK —> Server
Client回应了ACK，那么Server 的套接字才会真正置为CLOSED状态。
Server 程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没有发FIN给Client，那么可能是在关闭连接之前还有许多数据要发送或者其他事要做，导致没有发这个FIN packet。
通常来说，一个CLOSE_WAIT会维持至少2个小时的时间。如果有个流氓特地写了个程序，给你造成一堆的CLOSE_WAIT，消耗资源，那么通常是等不到释放那一刻，系统就已经解决崩溃了。
改变这个值的前要经过认真的监测,避免因为死套接字造成内存溢出。

sysctl -w net.ipv4.tcp_fin_timeout=30

对于所有的队列（即系统），设置最大系统发送缓存(wmem) 和接收缓存(rmem)到8MB

sysctl -w net.ipv4.core.wmem_max=8388608
sysctl -w net.ipv4.core.rmem_max=8388608

使用如下命令调整tcp发送和接收缓存。该命令设定了三个值：最小值、初始值和最大值：

sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608"
sysclt -w net.ipv4.tcp.wmem="4096 87380 8388608"

第三个值必须小于或等于wmem_max和rmem_max。

当服务器负载繁重或者是有很多客户端都是超长延时的连接故障，可能会导致half-open连接数量的增加。这对于Web服务器很来讲很平常，尤其有很多拨号客户时。这些half-open连接保存在 backlog（积压） connections 队列中。
将这个值最少设置为4096 (缺省为1024)。 即便是服务器不接收这类连接，设置这个值还能防止受到denial-of-service (syn-flood)的攻击

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

设置ipfrag参数，尤其是NFS和Samba服务器。这里，我们可以设置用于重新组合IP碎片的最大、最小内存。当ipfrag_high_thresh值被指派，碎片会被丢弃直到达到ipfrag_low_thres值。
当TCP数据包传输发生错误时，开始碎片整理。有效的数据包保留在内存，同时损坏的数据包被转发。例如，设置可用内存范围从256 MB到384 MB

sysctl -w net.ipv4.ipfrag_low_thresh=262144
sysctl -w net.ipv4.ipfrag_high_thresh=393216

网络安全设置
防止TCP SYN Flood 攻击

TCP SYN Flood是一种常见，而且有效的远端(远程)拒绝服务(Denial of Service)攻击方式，它透过一定的操作破坏TCP三次握手建立正常连接，占用并耗费系统资源，使得提供TCP服务的主机系统无法正常工作。由於 TCP SYN Flood是透过网路底层对服务器Server进行攻击的，它可以在任意改变自己的网路IP地址的同时，不被网路上的其他设备所识别，这样就给防范网路犯 罪部门追查犯罪来源造成很大的困难。

系统检查
一般情况下，可以一些简单步骤进行检查，来判断系统是否正在遭受TCP SYN Flood攻击
1、服务端无法提供正常的TCP服务。连接请求被拒绝或超时
2、透过 netstat -an 命令检查系统，发现有大量的SYN_RECV连接状态

iptables的设置
防止同步包洪水(Sync Flood)

iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

也有人写作

iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT

–limit 1/s 限制syn并发数每秒1次，可以根据自己的需要修改

防止各种端口扫描

iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Ping洪水攻击(Ping of Death)

iptables -A FORWARD -p icmp --icmp-type echo- -m limit --limit 1/s -j ACCEPT