linux的msl

MSL，即Maximum Segment Lifetime，一个数据分片(报文)在网络中能够生存的最长时间，在RFC 793中定义MSL通常为2分钟，即超过两分钟即认为这个报文已经在网络中被丢弃了。对于一个TCP连接，在双方进入TIME_WAIT后，通常会等待2倍MSL时间后，再关闭掉连接，作用是为了防止由于FIN报文丢包，对端重发导致与后续的TCP连接请求产生顺序混乱，具体原理这里就不详细解释了，可以参考：http://blog..net/qwertyupoiuytr/article/details/68938963

MSL的时长其实是一个估计值，由于这个值会影响很多基于TCP的应用的连接复用和调优，所以在实际生产中，需要针对具体的应用来调整MSL的具体值(需要注意的是，由于MSL值是对于系统层面来说，所以调整后，会对系统中部署的全部应用产生影响)。下面说明了针对Linux系统和Windows系统调整MSL的方法。

Linux，以CentOS为例：

查看默认的MSL值(60s)：

[root@DanCentOS65var]# cat /proc/sys/net/ipv4/tcp_fin_timeout

60

修改默认60为120：

[root@DanCentOS65var]# echo 120 > /proc/sys/net/ipv4/tcp_fin_timeout

修改完成后，重新加载配置文件：

[root@DanCentOS65var]# sysctl -p /etc/sysctl.conf

查看是否已经生效：

[root@DanCentOS65var]# sysctl -a | grep fin

net.ipv4.tcp_fin_timeout= 120

Windows上修改"2MSL"的值：

打开注册表编辑器(regedit)：

ca506ffee29c9b04fa947f5b87c2d727.png

找到HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters，在右侧找到TcpTimedWaitDelay这一个键值(Win2000之后的系统中可能会没有这个值，如果没有，创建一个即可)：

8ce567160f937f0e47cf2296b4fa7fed.png

指定对应的值即可：

b04995cdd2b385e4fe0eed76c5123907.png

注意在Windows系统中，这个注册表键值就直接等于TIME_WAIT到CLOSED状态的等待市场，也就是2MSL的值，而不像Linux中，我们修改的是MSL的值。

 

打开CSDN，阅读体验更佳

 
 
相关推荐更多相似内容
msl3等级烘烤时间_msl湿敏等级对应表_程绵羊的博客
元件的湿度敏感等级(MSL):IPC将其分为1、2、2a、3、4、5、5a、6共8个等级,其湿度敏感级别 逐级递增. 防潮包装袋(MBB):一种为了阻止水蒸气进入而设计用来... PCB MSL 湿敏等级只做开封后生产过程中的停留时间的参考,不做烘烤...
2MSL到底有多长_m673010624的博客_2msl是多久
2MSL到底有多长 以前一直不知道2MSL到底有多长,直到看到这个比喻 https://juejin.im/post/5b29d2c4e51d4558b80b1d8c 钱老给的具体答案是4分钟
如何解决TIME_WAIT过多的解决办法（附Socket中的TIME_WAIT状态详解）
http://hi.baidu.com/xzhijun/blog/item/3a5f49609d443cd58cb10d01.html浏览器打开
 
 
 

最近网站流量有些上升，感觉到访问速度有些慢；用netstat -na命令发现系统中有大量状态为TIME-WAIT的TCP连接，google了下；修改了/etc/sysctl.conf中一些内核参数；解决了TCP连接中TIME-WAIT sockets的问题。
编辑/etc/sysctl.conf文件，增加如下内容：

#vi /etc/sysctl.conf
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1024  65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.route.gc_timeout = 100
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1

再执行以下命令，让修改结果立即生效：
sysctl -p

用以下语句看了一下服务器的TCP状态：

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key," ",state[key]}'
 

返回结果如下：
TIME_WAIT 4654
FIN_WAIT1 576
FIN_WAIT2 91
ESTABLISHED 866
SYN_RECV 654
CLOSING 285
LAST_ACK 78

效果：处于TIME_WAIT状态的sockets从原来的20000多减少到5000左右；同时处于SYN_RECV等待处理状态的sockets也下降了。
通过上面的设置以后，你可能会发现一个新的问题，就是netstat时可能会出现这样的警告：
warning, got duplicate tcp line
这正是上面允许tcp复用产生的警告，不过这不算是什么问题，总比不允许复用而给服务器带来很大的负载合算的多

尽管如此，还是有解决办法的：

1、 安装rpm包：
[root@root2 opt]# rpm -Uvh net-tools-1.60-62.1.x86_64.rpm
Preparing...                ########################################### [100%]
1:net-tools              ########################################### [100%]
[root@root2 opt]#

对于下载的是源码的rpm则需要使用以下方法安装：
2、 安装rpm源码包方法：
a)        安装src.rpm:
# [root@root1 opt]# rpm -i net-tools-1.60-62.1.src.rpm
……
b)        制作rpm安装包：
[root@root1 opt]# cd /usr/src/redhat/SPECS/
[root@root1 SPECS]# rpmbuild -bb net-tools.spec
c)        rpm包的升级安装：
[root@root1 SPECS]# pwd
/usr/src/redhat/SPECS
[root@root1 SPECS]# cd ../RPMS/x86_64/
[root@root1 x86_64]# rpm -Uvh net-tools-1.60-62.1.x86_64.rpm

3、 再使用netstat来检查时系统正常。

附录：

内核参数说明：
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1800 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.ip_local_port_range = 1024   65000 表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死（本站正好采用的是squid+apache，修改前面几项参数后time_wait连接数依旧没有减少，最后修改了此参数）。
net.ipv4.route.gc_timeout = 100  路由缓存刷新频率，当一个路由失败后多长时间跳到另一个
默认是300
net.ipv4.tcp_syn_retries = 1  对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右。

TCP状态的变迁图：

状态描述：
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉

TCP中TIME_WAIT的相关原理：

在socket的TIME_WAIT状态结束之前，该socket所占用的本地端口号将一直无法释放。编写过高TCP并发并且采用短连接方式进行通讯的软件程序的人，都可能体会到，这样的通讯系统在高并发高负载下运行一段时间后，就常常会出现做为客户端的程序无法向服务端建立新的socket连接的情况。此时用"netstat-anp"命令查看系统将会发现机器上存在大量处于TIME_WAIT状态的socket连接，并且占用大量的本地端口号。最后，当该机器上的可用本地端口号被占完，而旧的大量处于TIME_WAIT状态的socket尚未被系统回收时，就会出现无法向服务端创建新的socket连接的情况。此时的通讯系统几乎停转，空有再好的性能也发挥不出来。
如果能够在客户端程序主动关闭socket之前，让该socket的接收队列中仍保留一些数据（至少要有多余的一个字节的数据），然后调用close关闭，那么上述的无法向服务端创建新的socket连接的情况将不会出现。这是因为当socket的接收队列中仍有数据未被应用程序读走就被强行关闭时，操作系统（至少在笔者验证过的操作系统上的确如此）的TCP/IP协议栈驱动程序会在底层主动向服务端发送一个要求结束TCP连接的控制包，并将该TCP包头的flag控制字段中的RESET位置位，从而迅速结束了此TCP连接。这其实是操作系统对TCP连接断开的一种异常处理。而正常情况下（socket 的接收队列中无未读数据），当应该程序调用close关闭连接时，底层驱动程序向服务端发送的要求结束TCP连接的控制包头的flag控制字段中是将 FIN位置位，并且严格遵循上图所示的状态转换过程，最终到达TIME_WAIT状态并持续2*MSL的时间。

awk命令解释

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key," ",state[key]}'

/^tcp/
滤出tcp开头的记录，屏蔽udp, socket等无关记录。
state[]
相当于定义了一个名叫state的数组
NF
表示记录的字段数，如上所示的记录，NF等于6
$NF
表示某个字段的值，如上所示的记录，$NF也就是$6，表示第6个字段的值，也就是TIME_WAIT
state[$NF]
表示数组元素的值，如上所示的记录，就是state[TIME_WAIT]状态的连接数
++state[$NF]
表示把某个数加一，如上所示的记录，就是把state[TIME_WAIT]状态的连接数加一
END
表示在最后阶段要执行的命令
for(key in state)
遍历数组
print key," ",state[key]
打印数组的键和值，中间用 制表符分割，美化一下。


 
 
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/cheyunhua/p/15351075.html