/proc/sys/net/ipv4 目录下的配置调优看法

上面的全部来自真实环境的tcp控制选项，还有如果需要进一步看这些选项的描述的话，请直接在终端敲man tcp.下面一一看这些的意义，以便后面复习。

tcp_abc 拥塞算法

tcp_abort_on_overflow ：tcp sync处理不过来干脆就直接拒绝连接了。

net.ipv4.tcp_adv_win_scale：

1: 默认值为2 

2: 在tcp_moderate_rcvbuf启用的情况下，用来对计算接收缓冲区和接收窗口的参数进行微调。 

3: 窗口与接收缓存之间的比例系数 那么这时大家可能有疑问，当窗口从初始窗口一路扩张到最大接收窗口时，最大接收窗口就是最大读缓存吗？ 不是，因为必须分一部分缓存用于应用程序的延时报文读取。到底会分多少出来呢？这是可配的系统选项，如下： cat net.ipv4.tcp_adv_win_scale = 2，这里的tcp_adv_win_scale意味着，将要拿出1/(2^tcp_adv_win_scale)缓存出来做应用缓存。即，默认tcp_adv_win_scale配置为2时，就是拿出至少1/4的内存用于应用读缓存，那么，最大的接收滑动窗口的大小只能到达读缓存的3/4。

tcp_allowed_congestion_control：允许的拥塞控制算法

tcp_app_win：

1: 默认值为:31 

2: 用于计算当前应用接收缓存的大小（只包括应用层数据，单位为字节)

3: 保留max(window/2^tcp_app_win, mss)数量的窗口由于应用缓冲。当为0时表示不需要缓冲

1: 默认值为2
2: 在tcp_moderate_rcvbuf启用的情况下，用来对计算接收缓冲区和接收窗口
的参数进行微调。
3: 窗口与接收缓存之间的比例系数
那么这时大家可能有疑问，当窗口从初始窗口一路扩张到最大接收窗口时，最
大接收窗口就是最大读缓存吗？
不是，因为必须分一部分缓存用于应用程序的延时报文读取。到底会分多少出
来呢？这是可配的系统选项，如下：
[cpp] view plaincopyprint?01.net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_adv_win_scale = 2
这里的tcp_adv_win_scale意味着，将要拿出1/(2^tcp_adv_win_scale)缓存出
来做应用缓存。即，默认tcp_adv_win_scale配置为2时，就是拿出至少1/4的内
存用于应用读缓存，那么，最大的接收滑动窗口的大小只能到达读缓存的3/4
1: 默认值为2
2: 在tcp_moderate_rcvbuf启用的情况下，用来对计算接收缓冲区和接收窗口
的参数进行微调。
3: 窗口与接收缓存之间的比例系数
那么这时大家可能有疑问，当窗口从初始窗口一路扩张到最大接收窗口时，最
大接收窗口就是最大读缓存吗？
不是，因为必须分一部分缓存用于应用程序的延时报文读取。到底会分多少出
来呢？这是可配的系统选项，如下：
[cpp] view plaincopyprint?01.net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_adv_win_scale = 2
这里的tcp_adv_win_scale意味着，将要拿出1/(2^tcp_adv_win_scale)缓存出
来做应用缓存。即，默认tcp_adv_win_scale配置为2时，就是拿出至少1/4的内
存用于应用读缓存，那么，最大的接收滑动窗口的大小只能到达读缓存的3/4
1: 默认值为2
2: 在tcp_moderate_rcvbuf启用的情况下，用来对计算接收缓冲区和接收窗口
的参数进行微调。
3: 窗口与接收缓存之间的比例系数
那么这时大家可能有疑问，当窗口从初始窗口一路扩张到最大接收窗口时，最
大接收窗口就是最大读缓存吗？
不是，因为必须分一部分缓存用于应用程序的延时报文读取。到底会分多少出
来呢？这是可配的系统选项，如下：
[cpp] view plaincopyprint?01.net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_adv_win_scale = 2
这里的tcp_adv_win_scale意味着，将要拿出1/(2^tcp_adv_win_scale)缓存出
来做应用缓存。即，默认tcp_adv_win_scale配置为2时，就是拿出至少1/4的内
存用于应用读缓存，那么，最大的接收滑动窗口的大小只能到达读缓存的3/4
tcp_available_congestion_control：可用的拥塞控制算法

tcp_base_mss：1: 默认值为:512

2: 分组层路径MTU发现(MTU探测)中使用的search_low的初始值。如果允许MTU探测，这个初始值就是连接使用的初始MSS值。

tcp_challenge_ack_limit：Linux内核都遵从这一守则，系统中有个全局变量sysctl_tcp_challenge_ack_limit，就是存储challenge ACK计数器。

tcp_congestion_control：使用的可用的拥塞控制算法

tcp_cookie_size：SYN COOKIE的大小

tcp_dsack: duplicate selective 算法，用来通告发送方，那些数据是重复的。

tcp_early_retrans：主要解决快速重传3个ack的问题，google大神的杰作，http://www.pagefault.info/?p=457

tcp_ecn:ECN(explicit congestion notification)-like algorithmsz

tcp_fack：tcp  快速重传算法，接收端三次ack就会启动发送端发包的策略

tcp_fastopen：TFO（TCP Fast Open）是一种能够在TCP连接建立阶段传输数据的机制。使用这种机制可以将数据交互提前，降低应用层事务的延迟。可以在应用层如下面设置。

setsockopt(sfd, IPPROTO_TCP/*SOL_TCP*/, 23/*TCP_FASTOPEN*/, &qlen, sizeof(qlen));
 

 这个特性对于短连接的业务类型比较有很大的帮助，据测试结果有4%~41%的性能提升。

tcp_fin_timeout：本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。默认值为 60 秒。过去在2.2版本的内核中是 180
秒。

您可以设置该值，但需要注意，如果您的机器为负载很重的web服务器，您可能要冒内存被大量无效数据报填满的风险，FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1，因为它们最多只吃 1.5K 的内存，但是它们存在时间更长。

tcp_frto：开启F-RTO,一个针对TCP重传超时(RTOs)的增强的恢复算法。在无线环境下特别有益处，因为在这种环境下分组丢失典型地是因为随机无线电干扰而不是中间路由器组塞。参考RFC
4318了解更多的细节。

这个文件拥有下列值之一:

Ø  0 禁用。

Ø  1 开启基本版本的F-RTO算法。

Ø  2 如果流使用SACK的话，开启SACK-增强的F-TRO算法。不过当使用SACK时是基本版本也是可以使用的，因为有这种场景存在，F-RTO和开启SACK的TCP流分组计数合作不好。

tcp_keepalive_intvl=7200->tcp_keepalive_probes=9->tcp_keepalive_time=75

如果某个TCP连接在idle 2个小时后,内核才发起probe(探查).如果probe 9次(每次75秒既tcp_keepalive_intvl值)不成功,内核才彻底放弃,认为该连接已失效。

tcp_limit_output_bytes: TCP small queues TCP小队列,这个机制是用来针对缓存膨胀(bufferbloat)，意思是在tcp传输路径中有中很多的缓存，比如socket
buffer，qdisc的队列buffer，网卡驱动层也有队列buffer。  而这些buffer会缓存住数据包，但是对于tcp协议层而言，可能已经认为数据包已经发送到网络中，会增加数据包传输的rtt时间，而可以自定义的socket buffer 大小，qdisc队列长度，会膨胀放大延时。因此，可以通过tcp_limit_output_bytes这个proc参数让用户限制qdisc的队列和驱动层队列中所有数据包的总字节数， 默认是131072字节。

tcp_low_latency: 允许
TCP/IP 栈适应在高吞吐量情况下低延时的情况；这个选项一般情形是的禁用。

tcp_max_orphans: 系统所能处理不属于任何进程的TCP
sockets最大数量（主动关闭端发送了FIN后转到FIN_WAIT_1，这时TCP连接就不属于某个进程了）。假如超过这个数量，那么不属于任何进程的连接会被立即reset，并同时显示警告信息。之所以要设定这个限制，纯粹为了抵御那些简单的 DoS 攻击﹐千万不要依赖这个或是人为的降低这个限制(这个值Redhat AS版本中设置为32768，但是很多防火墙修改的时候,建议该值修改为2000)

net.ipv4.tcp_max_syn_backlog: 在三次握手处于半连接的最大数目，对于那些依然还未获得客户端确认的连接请求，需要保存在队列中最大数目。默认值是1024，可提高到2048。

tcp_max_tw_buckets：系统在同时所处理的最大timewait
sockets 数目。如果超过此数的话，time-wait socket 会被立即砍除并且显示警告信息。

tcp_mem：该文件保存了三个值，分别是
low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。
presure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。

high：允许所有tcp sockets用于排队缓冲数据报的页面量。

 tcp_min_tso_segs：tso（TCP
Segment Offload）是一种利用网卡的少量处理能力，降低CPU发送数据包负载的技术，需要网卡硬件及驱动的支持。

tcp_moderate_rcvbuf：接收数据时是否调整接收缓存

tcp_mtu_probing：对于开启了
jumbo frames 的机器来说，需要开启，默认是 0。这个主要是为了弥补使用 PMTUD 调整 MTU 出现的一些问题。如果置为 2，则会牵扯到 tcp_base_mss，默认为 512，即使用 tcp_base_mss 作为起始的 MSS 值。与之相关的还有 ip_no_pmtu_disc 这个参数，默认为 0，即依然会优先使用传统的 PMTUD，只有当遇到 blackhole 的时候才会使用 PLPMTUD(Packetization
Layer Path MTU Discovery)，也就是上面提到的技术。

tcp_no_metrics_save：如果开启，tcp会在连接关闭时也就是LAST_ACK状态保存各种连接信息到路由缓存中，新建立的连接可以使用这些条件来初始化.。通常这会增加总体的系统性能，但是有些时候也会引起性能下降。

tcp_no_metrics_save：如果有使用TCP_NOTSENT_LOWAT选项，则使用用户设置的值。

否则使用sysctl_tcp_notsent_lowat，默认为无穷大。

net.ipv4.tcp_retries1 = 3

放弃回应一个TCP 连接请求前﹐需要进行多少次重试。RFC 规定最低的数值是3﹐这也是默认值﹐根据RTO的值大约在3秒 - 8分钟之间。(注意:这个值同时还决定进入的syn连接)

(第二种解释：它表示的是TCP传输失败时不检测路由表的最大的重试次数，当超过了这个值，我们就需要检测路由表了)

 

net.ipv4.tcp_retries2 = 15

在丢弃激活(已建立通讯状况)的TCP连接之前﹐需要进行多少次重试。默认值为15，根据RTO的值来决定，相当于13-30分钟(RFC1122规定，必须大于100秒).(这个值根据目前的网络设置,可以适当地改小,我的网络内修改为了5)

(第二种解释：表示重试最大次数，只不过这个值一般要比上面的值大。和上面那个不同的是，当重试次数超过这个值，我们就必须放弃重试了)

 

net.ipv4.tcp_orphan_retries：

主要是针对孤立的socket(也就是已经从进程上下文中删除了，可是还有一些清理工作没有完成).对于这种socket，我们重试的最大的次数就是它

我们通过一个dup ACK并不能可靠的确认是发生了丢包还是发生了乱序传输，因此会存在一个门限(duplicate ACK threshold或者叫做dupthresh)，当TCP收到的dup ACK数超过这个门限的时候，就会认为发生了丢包，进而初始化一个快速重传。最初协议中给出的dupthresh这个门限是3，但是RFC 4653给出了一种调整dupthresh的方法。Linux中则可以通过/proc/sys/net/ipv4/tcp_reordering来设置默认值，另外Linux可能还会根据乱序测量的结果来更新实际的dupthresh。dupthresh的范围最终会在/proc/sys/net/ipv4/tcp_reordering和/proc/sys/net/ipv4/tcp_max_reordering之间。

tcp_rmem：接收缓冲区长度，三个参数：min default max。

tcp_sack：启用有选择的应答（Selective Acknowledgment），这可以通过有选择地应答乱序接收到的报文来提高性能（这样可以让发送者只发送丢失的报文段）；（对于广域网通信来说）这个选项应该启用，但是这会增加对
CPU 的占用。

tcp_slow_start_after_idle：在长连接的应用优化，常常用到这个参数，参看这个网址http://blog.csdn.net/hedpatczw/article/details/51471999

tcp_stdurg：不讨论

tcp_synack_retries：对于远端的连接请求SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连接请求包。这是所谓的三次握手.这里决定内核在放弃连接之前所送出的
SYN+ACK 数目.

tcp_syncookies：表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

tcp_syn_retries：对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右时间。(对于大负载而物理通信良好的网络而言,这个值偏高,可修改为2.这个值仅仅是针对对外的连接,
对进来的连接,是由tcp_retries1 决定的)

tcp_thin_dupack和tcp_thin_linear_timeouts

当TCP连续大量的发送数据的时候，当出现丢包的时候可以有足够的dup ACK来触发快速重传。但是internet上还有大量的交互式服务，这类服务一般都是由小包组成，而且一次操作中需要传输的数据包一般比较少，比如在线游戏、股票交易等，这一类数据流我们就称呼为thin stream。在一次交互式操作触发一次TCP传输的时候，如果传输的这个数据包发生丢包，很可能后面没有足够的dup
ACK来触发快速重传，最终只能依赖RTO超时来进行重传。还有一种受限传输的场景，如果发送窗口受到拥塞控制的限制只能发送出少量的TCP报文的时候，如果丢包也可能会因为收不到足够的dup ACK而不能触发快速重传。关于拥塞控制我们后续内容会介绍。这样会降低用户体验。同时如果RTO多次指数回退，可能会进一步进一步降低用户体验。之前我们介绍过RTO指数回退的目的是降低网络拥塞，而实际上交互式操作一般数据量很小，没有必要通过指数回退来降低网络拥塞。

综上介绍，为了改善thin stream的传输，linux针对引入了两个控制参数

/proc/sys/net/ipv4/tcp_thin_dupack：当该开关打开的时候，只需要一个dup ACK且缓存中没有待发送数据就可以触发快速重传

/proc/sys/net/ipv4/tcp_thin_linear_timeouts：当该参数打开的时候，前6次RTO超时触发的重传并不进行指数回退。

tcp_timestamps：

该参数控制RFC 1323 时间戳与窗口缩放选项。默认情况下，启用时间戳与

窗口缩放，但是可以使用标志位进行控制。0位控制窗口缩放，1 位控制时间戳。

值为0（禁用 RFC 1323选项）

值为1（仅启用窗口缩放）

值为2（仅启用时间戳）

值为3（两个选项均启用）

net.ipv4.tcp_timestamps=0

说明：

时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。

值为0（禁用时间戳）

值为1（启用时间戳）

只有客户端和服务端都开启时间戳的情况下，才会出现能ping通不能建立tcp三次握手的情况，所以做为提供服务的公司，不可能保证所有

tcp_tso_win_divisor：单个TSO段可消耗拥塞窗口的比例，默认值为3。

tcp_tw_recycle：表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0，表示关闭

這個選項很容易導致nat系統崩潰！

tcp_tw_reuse：表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0，表示关闭；导致NAT

tcp_window_scaling：TCP使用16位来记录窗口大小,也就是说最大值是64KB,如果超过它,就需要使用tcp_window_scaling机制。

tcp_wmem：如果指定了tcp_wmem，则net.core.wmem_default被tcp_wmem的覆盖。sendBuffer在tcp_wmem的最小值和最大值之间自动调节。如果调用setsockopt()设置了socket选项SO_SNDBUF，将关闭发送端缓冲的自动调节机制，tcp_wmem将被忽略，SO_SNDBUF的最大值由net.core.wmem_max限制。

TCP在TIME-WAIT状态下的时候，如果接收到reset包，它可能会提前结束TIME-WAIT状态，这种行为即叫做TIME-WAIT
Assassination(TWA)，数据包的流程如下图所示：为了避免TIME-WAIT状态提前被reset结束，一些系统的TCP实现在TIME-WAIT状态下不会响应rst消息。linux则可以通过net.ipv4.tcp_rfc1337设置TCP在TIME-WAIT下是否响应reset，如果设置tcp_rfc1337为0，在TIME-WAIT下如果接收到reset则会直接关闭tcp连接，而不会等到2MSL超时。