tcp-ip内核优化参数存档

参数（路径+文件）	描述	默认值	优化值
/proc/sys/net/core/rmem_default	默认的socket数据接收窗口大小（字节）。	229376	256960
/proc/sys/net/core/rmem_max	最大的socket数据接收窗口（字节）。	131071	513920
/proc/sys/net/core/wmem_default	默认的socket数据发送窗口大小（字节）。	229376	256960
/proc/sys/net/core/wmem_max	最大的socket数据发送窗口（字节）。	131071	513920
/proc/sys/net/core/netdev_max_backlog	在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。	1000	2000
/proc/sys/net/core/somaxconn	定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数。	128	2048
/proc/sys/net/core/optmem_max	表示每个套接字(socket)所允许的初始最大缓冲区的大小。	20480	81920
/proc/sys/net/ipv4/tcp_mem	确定TCP栈应该如何反映内存使用，每个值的单位都是内存页（通常是4KB）。第一个值是内存使用的下限；第二个值是内存压力模式开始对缓冲区使用应用压力的上限；第三个值是内存使用的上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的BDP可以增大这些值（注意，其单位是内存页而不是字节）。	94011  125351  188022	131072  262144  524288
/proc/sys/net/ipv4/tcp_rmem	为自动调优定义socket使用的内存。第一个值是为socket接收缓冲区分配的最少字节数；第二个值是默认值（该值会被rmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是接收缓冲区空间的最大字节数（该值会被rmem_max覆盖）。	4096  87380  4011232	8760  256960  4088000
/proc/sys/net/ipv4/tcp_wmem	为自动调优定义socket使用的内存。第一个值是为socket发送缓冲区分配的最少字节数；第二个值是默认值（该值会被wmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是发送缓冲区空间的最大字节数（该值会被wmem_max覆盖）。	4096  16384  4011232	8760  256960  4088000
/proc/sys/net/ipv4/tcp_keepalive_time	TCP发送keepalive探测消息的间隔时间（秒），用于确认TCP连接是否有效。	7200	1800
/proc/sys/net/ipv4/tcp_keepalive_intvl	探测消息未获得响应时，重发该消息的间隔时间（秒）。	75	30
/proc/sys/net/ipv4/tcp_keepalive_probes	在认定TCP连接失效之前，最多发送多少个keepalive探测消息。	9	3
/proc/sys/net/ipv4/tcp_sack	启用有选择的应答（1表示启用），通过有选择地应答乱序接收到的报文来提高性能，让发送者只发送丢失的报文段，（对于广域网通信来说）这个选项应该启用，但是会增加对CPU的占用。	1	1
/proc/sys/net/ipv4/tcp_fack	启用转发应答，可以进行有选择应答（SACK）从而减少拥塞情况的发生，这个选项也应该启用。	1	1
/proc/sys/net/ipv4/tcp_timestamps	TCP时间戳（会在TCP包头增加12个字节），以一种比重发超时更精确的方法（参考RFC 1323）来启用对RTT 的计算，为实现更好的性能应该启用这个选项。	1	1
/proc/sys/net/ipv4/tcp_window_scaling	启用RFC 1323定义的window scaling，要支持超过64KB的TCP窗口，必须启用该值（1表示启用），TCP窗口最大至1GB，TCP连接双方都启用时才生效。	1	1
/proc/sys/net/ipv4/tcp_syncookies	表示是否打开TCP同步标签（syncookie），内核必须打开了CONFIG_SYN_COOKIES项进行编译，同步标签可以防止一个套接字在有过多试图连接到达时引起过载。	1	1
/proc/sys/net/ipv4/tcp_tw_reuse	表示是否允许将处于TIME-WAIT状态的socket（TIME-WAIT的端口）用于新的TCP连接 。	0	1
/proc/sys/net/ipv4/tcp_tw_recycle	能够更快地回收TIME-WAIT套接字。	0	1
/proc/sys/net/ipv4/tcp_fin_timeout	对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。	60	30
/proc/sys/net/ipv4/ip_local_port_range	表示TCP/UDP协议允许使用的本地端口号	32768  61000	1024  65000
/proc/sys/net/ipv4/tcp_max_syn_backlog	对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。	2048	2048
/proc/sys/net/ipv4/tcp_low_latency	允许TCP/IP栈适应在高吞吐量情况下低延时的情况，这个选项应该禁用。	0
/proc/sys/net/ipv4/tcp_westwood	启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化，对于WAN 通信来说应该启用这个选项。	0
/proc/sys/net/ipv4/tcp_bic	为快速长距离网络启用Binary Increase Congestion，这样可以更好地利用以GB速度进行操作的链接，对于WAN通信应该启用这个选项。	1

注意不要启用tcp_tw_recycle参数，原因见
简单你来说，因为：
1、现在大部分的客户端都是NAT出来的，因此建议tw_recycle还是关闭
2、打开了 tcp_tw_reccycle 了，就会检查时间戳，很不幸移动的cmwap发来的包的时间戳是乱跳的，所以我方的就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。
处理这个问题不建议关闭tcp timestamp，因为 在tcp timestamp关闭的条件下，开启tcp_tw_recycle是不起作用的；而tcp timestamp可以独立开启并起作用，关了tcp timestamp不知道有会有什么性能、安全方面的隐患，能看linux源代码的可以去瞅瞅。

原文http://www.cnblogs.com/fczjuever/archive/2013/04/17/3026694.html
顺便有个bsd的内核参数参考站点

自用参数  
lvs主服务器下面几个4096都换8192
vm.swappiness = 0 
net.ipv4.tcp_wmem = 4096 87380 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0（原因见上面说明，系统默认也是0）
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.ip_local_port_range = 7000 65000
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 4096 #该参数决定了，网络设备接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
net.core.somaxconn = 8192

补充两篇文章
http://www.blogjava.net/yongboy/archive/2014/07/30/416373.html

最近在学习TCP方面的基础知识，对于古老的SYN Flood也有了更多认识。SYN Flood利用的是TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。
SYN Flood的原理简单，实现也不复杂，而且网上有许多现成的程序。
我在两台虚拟机上(虚拟机C攻击虚拟机S)做测试，S上跑了apache监听80端口，用C对S的80端口发送SYN Flood，在无任何防护的情况下攻击效果显著。用netstat可以看见80端口存在大量的半连接状态(SYN_RECV)，用tcpdump抓包可以看见大量伪造IP发来的SYN连接，S也不断回复SYN+ACK给对方，可惜对方并不存在(如果存在则S会收到RST这样就失去效果了)，所以会超时重传。
这个时候如果有正常客户A请求S的80端口，它的SYN包就被S丢弃了，因为半连接队列已经满了，达到攻击目的。
对于SYN Flood的防御一般会提到修改 net.ipv4.tcp_synack_retries, net.ipv4.tcp_syncookies, net.ipv4.tcp_max_syn_backlog
目的就是减小SYN+ACK重传次数，增加半连接队列长度，启用syn cookie。
当S开启syn cookie的时候情况会缓解，一旦半连接队列满了系统就会启用syn cookie功能，同时在/var/log/messages记录kernel: possible SYN flooding on port 80. Sending cookies.
但也不是可以完全防御的，如果说攻击瞬间并发量足够大，毕竟S的CPU内存有限，一般大公司都有专业的防火墙设备来应对。
其中对于net.ipv4.tcp_max_syn_backlog的描述一般都称为半连接队列的长度，但在我实际测试的过程中却发现SYN_RECV状态的数量与net.ipv4.tcp_max_syn_backlog设置的值相差甚远。
S系统配置如下：
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_syn_backlog = 4096
但SYN_RECV状态的数量却只有256
于是就开始相关资料，首先想到的是TCP/IP详解卷1中提到的backlog，man 2 listen:
int listen(int sockfd, int backlog);
The backlog parameter defines the maximum length the queue of pending connections may grow to. If a connection request arrives with
the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmis-
sion, the request may be ignored so that retries succeed.
NOTES
The behaviour of the backlog parameter on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely estab-
lished sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for
incomplete sockets can be set using the tcp_max_syn_backlog sysctl. When syncookies are enabled there is no logical maximum length
and this sysctl setting is ignored. See tcp(7) for more information.
可见backlog在Linux 2.2之后表示的是已完成三次握手但还未被应用程序accept的队列长度。
man 7 tcp:
tcp_max_syn_backlog (integer; default: see below)
The maximum number of queued connection requests which have still not received an acknowledgement from the connecting client.
If this number is exceeded, the kernel will begin dropping requests. The default value of 256 is increased to 1024 when the
memory present in the system is adequate or greater (>= 128Mb), and reduced to 128 for those systems with very low memory (<=
32Mb). It is recommended that if this needs to be increased above 1024, TCP_SYNQ_HSIZE in include/net/tcp.h be modified to
keep TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog, and the kernel be recompiled.
可见tcp_max_syn_backlog确实是半连接队列的长度，那为何会不准呢？
这时候正好让同事也在两台机器上测试了一下，得到的数据居然与tcp_max_syn_backlog完全一致。
开始怀疑是系统哪个地方配置有问题，又发现一个可疑的配置 net.core.somaxconn 它是listen的第二个参数int backlog的上限值，如果程序里的backlog大于
net.core.somaxconn的话就会取net.core.somaxconn的值。S系统的net.core.somaxconn = 128
?View Code C
//file:net/socket.c

SYSCALL_DEFINE2(listen, int, fd, int, backlog)
{
struct socket *sock;
int err, fput_needed;
int somaxconn;

sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (sock) {
somaxconn = sock_net(sock->sk)->core.sysctl_somaxconn;
//上限不超过somaxconn
if ((unsigned)backlog > somaxconn)
backlog = somaxconn;

err = security_socket_listen(sock, backlog);
if (!err)
err = sock->ops->listen(sock, backlog);

fput_light(sock->file, fput_needed);
}
return err;
}
查了apache文档关于ListenBackLog 指令的说明，默认值是511. 可见最终全连接队列(backlog)应该是net.core.somaxconn = 128
证实这点比较容易，用慢连接攻击测试观察到虚拟机S的80端口ESTABLISHED状态最大数量384
正好等于256(apache prefork模式MaxClients即apache可以响应的最大并发连接数) + 128(backlog即已完成三次握手等待apache accept的最大连接数)。说明全连接队列长度等于min(backlog,somaxconn);

有些东西总是很容易遗忘，一时记得了，过两天就真正还给周公了。零零碎碎的不如一并记下来，以后可以直接拿过来查询即可。
以下内容基于Linux 2.6.18内核。

一。listen方法传入的backlog参数，net.core.somaxconn
这个参数具体意义，先看看Linux Socket的listen解释
man listen
#include
int listen(int sockfd, int backlog);
int类型的backlog参数，listen方法的backlog意义为，已经完成三次握手、已经成功建立连接的套接字将要进入队列的长度。

一般我们自己定义设定backlog值，若我们设置的backlog值大于net.core.somaxconn值，将被置为net.core.somaxconn值大小。若不想直接硬性指定，跟随系统设定，则需要读取/proc/sys/net/core/somaxconn。
net\Socket.c :

/*
*  Perform a listen. Basically, we allow the protocol to do anything
*  necessary for a listen, and if that works, we mark the socket as
*  ready for listening.
*/

int sysctl_somaxconn = SOMAXCONN;

asmlinkage long sys_listen(int fd, int backlog)
{
struct socket *sock;
int err, fput_needed;

if ((sock = sockfd_lookup_light(fd, &err, &fput_needed)) != NULL) {
if ((unsigned) backlog > sysctl_somaxconn)
backlog = sysctl_somaxconn;

err = security_socket_listen(sock, backlog);
if (!err)
err = sock->ops->listen(sock, backlog);

fput_light(sock->file, fput_needed);
}
return err;
}
比如经常使用的netty(4.0)框架，在Linux下启动时，会直接读取/proc/sys/net/core/somaxconn值然后作为listen的backlog参数进行调用Linux系统的listen进行初始化等。

int somaxconn = 3072;
BufferedReader in = null;
try {
in = new BufferedReader(new FileReader("/proc/sys/net/core/somaxconn"));
somaxconn = Integer.parseInt(in.readLine());
logger.debug("/proc/sys/net/core/somaxconn: {}", somaxconn);
} catch (Exception e) {
// Failed to get SOMAXCONN
} finally {
if (in != null) {
try {
in.close();
} catch (Exception e) {
// Ignored.
}
}
}

SOMAXCONN = somaxconn;
......
private volatile int backlog = NetUtil.SOMAXCONN;
一般稍微增大net.core.somaxconn值就显得很有必要。

设置其值方法：

sysctl -w net.core.somaxconn=65535
较大内存的Linux，65535数值一般就可以了。

若让其生效，sysctl -p 即可，然后重启你的Server应用即可。

二。网卡设备将请求放入队列的长度，netdev_max_backlog

内核代码中sysctl.c文件解释：

number of unprocessed input packets before kernel starts dropping them, default 300
我所理解的含义，每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的最大数目，一旦超过将被丢弃。

所起作用处，net/core/Dev.c：

int netif_rx(struct sk_buff *skb)
{
struct softnet_data *queue;
unsigned long flags;

/* if netpoll wants it, pretend we never saw it */
if (netpoll_rx(skb))
return NET_RX_DROP;

if (!skb->tstamp.off_sec)
net_timestamp(skb);

/*
* The code is rearranged so that the path is the most
* short when CPU is congested, but is still operating.
*/
local_irq_save(flags);
queue = &__get_cpu_var(softnet_data);

__get_cpu_var(netdev_rx_stat).total++;
if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
if (queue->input_pkt_queue.qlen) {
enqueue:
dev_hold(skb->dev);
__skb_queue_tail(&queue->input_pkt_queue, skb);
local_irq_restore(flags);
return NET_RX_SUCCESS;
}

netif_rx_schedule(&queue->backlog_dev);
goto enqueue;
}

__get_cpu_var(netdev_rx_stat).dropped++;
local_irq_restore(flags);

kfree_skb(skb);
return NET_RX_DROP;
}
以上代码看一下，大概会明白netdev_max_backlog会在什么时候起作用。

net.core.somaxconn  内核里已经完成三次握手、已经成功建立连接的套接字将要进入队列的长度，也是个backlog（差不多可以理解为完成tcp-ip链接但是还没来得及处理的队列长度）
如果小与net.ipv4.tcp_max_syn_backlog，那么net.ipv4.tcp_max_syn_backlog的值会被net.core.somaxconn取代
同样，如果listen()函数中传入的backlog值大于net.core.somaxconn，也会被net.core.somaxconn取代

net.ipv4.tcp_max_syn_backlog ，参数决定了SYN_RECV状态队列的数量，一般默认值为512或者1024，即超过这个数量，系统将不再接受新的TCP连接请求，一定程度上可以防止系统资源耗尽。可根据情况增加该值以接受更多的连接请求。 差不多可以理解为处理不完的syn发起数队列

net.ipv4.netdev_max_backlog这个更好理解了，这个就是网卡比内核快，要丢队列里的backlog了

修正2015-12-18

/proc/sys/net/core/wmem_default
/proc/sys/net/core/wmem_max
/proc/sys/net/core/rmem_default
/proc/sys/net/core/rmem_max
上面这四个是所有socket相关的 包括tcp udp,tcp对应的设置收到上述参数的限制

/proc/sys/net/core/optmem_max
上面这个参数看中文的说明有点模糊,还要修正

英文文档说明为

optmem_max — Configures the maximum ancillary buffer size allowed per socket.

socket的ancillary buffer size 是什么鬼？

文档

补充下lvs的参数
arp_ignore:定义对目标地址为本地IP的ARP询问不同的应答模式0 
0 - (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求 
1 - 只回答目标IP地址是来访网络接口本地地址的ARP查询请求 
2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内 
3 - 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应 
4-7 - 保留未使用 
8 -不回应所有（本地地址）的arp查询

有关arp_announce的相关介绍：
arp_announce:对网络接口上，本地IP地址的发出的，ARP回应，作出相应级别的限制: 确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口 
0 - (默认) 在任意网络接口（eth0,eth1，lo）上的任何本地地址 
1 -尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理. 
2 - 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送.

lvs的设置无非是工作网卡上忽略arp请求, 然后工作网卡和lo网卡arp_announce为2
arp_announce为1就是严格模式,内网发现有广播包乱窜可以在指定网卡上这只arp_announce=1
顺便all中的取值和制定网卡中的取值 以最大的为准