- 浏览: 221783 次
- 性别:
- 来自: 深圳
-
文章分类
- 全部博客 (391)
- java (18)
- python (3)
- ruby (4)
- linux (48)
- 网络 (9)
- 前端 (2)
- 社会、文化、哲学、人生、百态 (0)
- 工具 (10)
- 下载 (0)
- 常用地址 (0)
- tracert (0)
- mysql (8)
- 开源相关收藏 (1)
- 模块查看依懒 (1)
- watch使用 (1)
- Tcpdump (2)
- easy_install安装 (1)
- 构造redis批量删除脚本 (1)
- MYSQL 性能测试 (1)
- JAVA code encode utf-8 (1)
- linux nginx awk 实时 每妙 (1)
- mkpasswd (1)
- spring security oauth (1)
- jmap dump java memory Analyzer (1)
- JAVA DUMP (1)
- swap linux 过高 解决 (1)
- SWAP (1)
- jmap jstat jstack dump (1)
- java jconsole 的使用 (1)
- git 常用 (1)
- MYSQL 索引 动态 唯一 (1)
- TCP 三次握手 四次挥手 (1)
- linux date (1)
- 删除 空行 注释行 (1)
- maven3 yum linux install repository (1)
- linux git 搭建 (1)
- linux sar eth1 查看 流量 (1)
- sar (1)
- netstat ip 过滤 常用脚本 (1)
- Tcpdump 包分析网络连接过程 (1)
- net ipv4 tcp time wait tw recycle (0)
- /etc/sysctl.conf linux 网络 配置 (1)
- ss 网络连接查看 (比netstat 快很多,实时性牺牲) (1)
- MYSQL 关键字 (1)
- Linux 下多核CPU知识 (1)
- top (1)
- 令牌 证书 (1)
- mysql unix timestamp (1)
- 端口扫描 nc nmap (1)
- 204 http code 状态码 (1)
- ss -s ss -l (1)
- linux 常用 curl (1)
- linux sed 替换 换行 (1)
- centos yum install rpm install (1)
- spring-mvc源码解读 (1)
- 使用iftop查看实时的网络流量 (0)
- linux 命令 expect (1)
- HTTP (1)
- openssl ddif 加密 (1)
- iptables 详解 (1)
- python 虚拟化 VirtualEnv virtualenvwrapper (1)
- nginx (2)
- more less 实用技巧 (1)
- linux nginx (2)
- linux curl https ssl 证书 ca (1)
- openssl (1)
- php mysql linux (1)
- linux 虚拟机 虚拟 xen (0)
- linux 虚拟机 虚拟 xen kvm (1)
- linux perl 单行执行技巧 (1)
- mysql 查看库占用空间 表查用空间 (1)
- linux tcpdump (1)
- maven (1)
- sun.misc.Unsafe (1)
- OpenSSL生成证书 (1)
- http://blog.csdn.net/zzulp/article/details/8018751 (1)
- maven 本地 jar dependency (1)
- 计算JAVA代码行数最简单命令 sed (1)
- 常用的证书格式转换 rsa eg (1)
- 加密 解密 签名 (1)
- 分析jar包冲突 (1)
- 使用JMockit编写java单元测试 (1)
- Linux 技巧:让进程在后台可靠运行的几种方法 (1)
- 环境变量控制 (1)
- 5+ 个 tar 命令的用法,附示例 (1)
- scp自动输入密码 (1)
- ps axo pid (1)
- ppid (1)
- comm (1)
- pmem (1)
- lstart|grep mysql (0)
- lstart (1)
- etime|grep mysql (1)
- UML类图字少好理解 (1)
- HTTP经典文章 (1)
- git (1)
- Git常用命令 (1)
- LINUX 系统被攻击的分析过程 (1)
- NIO (1)
- LINUX 操作快捷键使用 (1)
- openSSL命令、PKI、CA、SSL证书原理 (1)
- shell (2)
- 转载 (1)
- mysqldump 可以直接dump->xml (1)
- VIM比较全面的文章 (1)
- eclipse regex 正则表达式 (1)
- synchronized (1)
- 锁 (1)
- java 正则表达式 regex (1)
- Reference Queue 引用 源码 (1)
- spring aop 源码 分析 (1)
- java @Cache @Transaction 注解 (1)
- spring aop (1)
- spring jdk proxy cglib 动态代理 性能比较 (1)
- spring proxy private public 代理限制 (1)
- spring transaction aop 事务 (1)
- spring autowire 注解注入 (1)
- 桥接 NAT NAT地址转换 内部网络 虚拟网络 (1)
- spring-web-mvc 源码解读 之 RequestMappingHandlerMapping (1)
- find atime mtime ctime -n n +n (1)
- android studio 快捷键初探 (1)
- android 源码阅读的计划 (1)
- 计算机网络学习-VLAN (1)
- sed 高级 合并行 (1)
- CAP 一致性 可用性 分布式容错性 (1)
- android lib so 库文件 (0)
- android lib so 库文件 移植 (1)
- android 不错的博文 (1)
- sourceinsight 源码 阅读 (1)
- Android Tab UI (1)
- 诗 (1)
- mysql 批处理 (0)
- netty 堆外内存 DirectByteBuffer (1)
- netty 并发 百万 推送 (1)
- Linux操作系统中内存buffer和cache的区别 (1)
- maven intellij target bytecode version (1)
- linux sleep()的实现原理 (1)
- android (2)
- javadoc 代码注释规范 (1)
- spring 自动注入bean auto (1)
- Photoshop CS6常用快捷键 (1)
- 股票 数据 机器 分析 (1)
- 批处理 (1)
- mysql -e (1)
- char (1)
- Unicode (1)
- 编码 (1)
- utf8 (1)
- utf-8 (1)
- utf16 (1)
- utf-16 (1)
- IntelliJ IDEA (1)
- ide (1)
- idea (1)
- intellij (1)
- 文件 (1)
- 目录 (1)
- 源代码 (1)
- CountDownLatch (1)
- CyclicBarrier (1)
- Semaphore (1)
- spring (1)
- linux 查看不同进制文件 (1)
- WebMvcConfigurationSupport (1)
- sdkman工具的使用 (1)
- http header (1)
- LINUX系统优化 (1)
最新评论
-
gelongmei:
威武我大酒神
shell脚本不换行刷新数据
cp_tw_recycle和tcp_timestamps的文章汇总
cp_tw_recycle和tcp_timestamps的文章汇总
http://blog.csdn.net/mei922/article/details/4801858TCP连接机制
http://blog.csdn.net/caianye/article/details/38540867
http://zhumeng8337797.blog.163.com/blog/static/100768914201262010163658/
2014-08-13 18:38 848人阅读 评论(0) 收藏 举报
临近年关,人会变得浮躁,期间写的代码可谓乱七八糟。不过出来混始终是要还的,这不最近就发现一个PHP脚本时常连不上服务器。
遇到这类问题,我习惯于先用strace命令跟踪了一下看看:
shell> strace php /path/to/file EADDRNOTAVAIL (Cannot assign requested address)
从字面结果看似乎是网络资源相关问题。这里顺便介绍一点小技巧:在调试的时候一般是从后往前看strace命令的结果,这样更容易找到有价值的信息。
查看一下当前的网络连接情况,结果发现TIME_WAIT数非常大:
shell> netstat -nt | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}' TIME_WAIT 28233
重复了几次测试,结果每次出问题的时候,TIME_WAIT都等于28233,这真是一个魔法数字!实际原因很简单,它取决于一个内核参数net.ipv4.ip_local_port_range:
shell> sysctl -a | grep port net.ipv4.ip_local_port_range = 32768 61000
因为端口范围是一个闭区间,所以实际可用的端口数量是:
shell> echo $((61000-32768+1)) 28233
问题分析到这里基本就清晰了,解决方向也明确了,内容所限,这里就不说如何优化程序代码了,只是从系统方面来阐述如何解决问题,无非就是以下两个方面:
首先是增加本地可用端口数量。这点可以用以下命令来实现:
shell> echo "net.ipv4.ip_local_port_range = 10240 61000" >> /etc/sysctl.conf shell> sysctl -p
其次是减少TIME_WAIT连接状态。网络上已经有不少相关的介绍,大多是建议:
shell> sysctl net.ipv4.tcp_tw_reuse=1 shell> sysctl net.ipv4.tcp_tw_recycle=1
注:通过sysctl命令修改内核参数,重启后会还原,要想持久化可以参考前面的方法。
这两个选项在降低TIME_WAIT数量方面可以说是立竿见影,不过如果你觉得问题已经完美搞定那就错了,实际上这样可能会引入一个更复杂的网络故障。
关于内核参数的详细介绍,可以参考官方文档。我们这里简要说明一下tcp_tw_recycle参数。它用来快速回收TIME_WAIT连接,不过如果在NAT环境下会引发问题。
RFC1323中有如下一段描述:
An additional mechanism could be added to the TCP, a per-hostcache of the last timestamp received from any connection.This value could then be used in the PAWS mechanism to rejectold duplicate segments from earlier incarnations of theconnection, if the timestamp clock can be guaranteed to haveticked at least once since the old connection was open. Thiswould require that the TIME-WAIT delay plus the RTT togethermust be at least one tick of the sender’s timestamp clock.Such an extension is not part of the proposal of this RFC.
大概意思是说TCP有一种行为,可以缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。
Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle,因为tcp_timestamps缺省就是开启的,所以当tcp_tw_recycle被开启后,实际上这种行为就被激活了。
现在很多公司都用LVS做负载均衡,通常是前面一台LVS,后面多台后端服务器,这其实就是NAT,当请求到达LVS后,它修改地址数据后便转发给后端服务器,但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是LVS的地址,加上端口会复用,所以从后端服务器的角度看,原本不同客户端的请求经过LVS的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,还可以通过下面命令来确认数据包不断被丢弃的现象:
shell> netstat -s | grep timestamp ... packets rejects in established connections because of timestamp
如果服务器身处NAT环境,安全起见,通常要禁止tcp_tw_recycle,至于TIME_WAIT连接过多的问题,可以通过激活tcp_tw_reuse来缓解。
进一步思考,既然必须同时激活tcp_timestamps和tcp_tw_recycle才会触发这种现象,那只要禁止tcp_timestamps,同时激活tcp_tw_recycle,就可以既避免NAT丢包问题,又降低TIME_WAIT连接数量。如果服务器并不依赖于RFC1323,那么这种方法应该也是可行的,不过最好多做测试,以防有其他的副作用。
shell> sysctl net.ipv4.tcp_timestamps=0 shell> sysctl net.ipv4.tcp_tw_recycle=1
…
总体来说,这次网络故障本身并没什么高深之处,本不想罗罗嗦嗦写这么多,不过拔出萝卜带出泥,在过程中牵扯的方方面面还是值得大家品味的,于是便有了这篇文字。
近来线上陆续出现了一些connect失败的问题,经过分析试验,最终确认和proc参数tcp_tw_recycle/tcp_timestamps相关;
1. 现象
第一个现象:模块A通过NAT网关访问服务S成功,而模块B通过NAT网关访问服务S经常性出现connect失败,抓包发现:服务S端已经收到了syn包,但没有回复synack;另外,模块A关闭了tcp timestamp,而模块B开启了tcp timestamp;
第二个现象:不同主机上的模块C(开启timestamp),通过NAT网关(1个出口ip)访问同一服务S,主机C1 connect成功,而主机C2 connect失败;
2. 分析
根据现象上述问题明显和tcp timestmap有关;查看linux 2.6.32内核源码,发现tcp_tw_recycle/tcp_timestamps都开启的条件下,60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。
源码函数:tcp_v4_conn_request(),该函数是tcp层三次握手syn包的处理函数(服务端);
源码片段:
if (tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
peer->v4daddr == saddr) {
if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
(s32)(peer->tcp_ts - req->ts_recent) >
TCP_PAWS_WINDOW) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
goto drop_and_release;
}
}
tmp_opt.saw_tstamp:该socket支持tcp_timestamp
sysctl_tw_recycle:本机系统开启tcp_tw_recycle选项
TCP_PAWS_MSL:60s,该条件判断表示该源ip的上次tcp通讯发生在60s内
TCP_PAWS_WINDOW:1,该条件判断表示该源ip的上次tcp通讯的timestamp 大于本次tcp
分析:主机client1和client2通过NAT网关(1个ip地址)访问serverN,由于timestamp时间为系统启动到当前的时间,因此,client1和client2的timestamp不相同;根据上述syn包处理源码,在tcp_tw_recycle和tcp_timestamps同时开启的条件下,timestamp大的主机访问serverN成功,而timestmap小的主机访问失败;
参数:/proc/sys/net/ipv4/tcp_timestamps - 控制timestamp选项开启/关闭
/proc/sys/net/ipv4/tcp_tw_recycle - 减少timewait socket释放的超时时间
3. 解决方法
echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle;
tcp_tw_recycle默认是关闭的,有不少服务器,为了提高性能,开启了该选项;
为了解决上述问题,个人建议关闭tcp_tw_recycle选项,而不是timestamp;因为 在tcp timestamp关闭的条件下,开启tcp_tw_recycle是不起作用的;而tcp timestamp可以独立开启并起作用。
源码函数: tcp_time_wait()
源码片段:
if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);
......
if (timeo < rto)
timeo = rto;
if (recycle_ok) {
tw->tw_timeout = rto;
} else {
tw->tw_timeout = TCP_TIMEWAIT_LEN;
if (state == TCP_TIME_WAIT)
timeo = TCP_TIMEWAIT_LEN;
}
inet_twsk_schedule(tw, &tcp_death_row, timeo,
TCP_TIMEWAIT_LEN);
timestamp和tw_recycle同时开启的条件下,timewait状态socket释放的超时时间和rto相关;否则,超时时间为TCP_TIMEWAIT_LEN,即60s;
内核说明文档 对该参数的介绍如下:
tcp_tw_recycle - BOOLEAN
Enable fast recycling TIME-WAIT sockets. Default value is 0.
It should not be changed without advice/request of technical
experts.
来源:http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
在一些高并发的 WebServer上,为了端口能够快速回收,打开了net.ipv4.tcp_tw_recycle,而在关闭 net.ipv4.tcp_tw_recycle的时候,kernal 是不会检查对端机器的包的时间戳的;打开了 tcp_tw_reccycle 了,就会检查时间戳,很不幸移动的cmwap发来的包的时间戳是乱跳的,所以服务器就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据,不是新的请求”,于是丢掉不回包,造成大量丢包。
#ExtMail专业版# 这两天在处理一个新签客户的古怪问题,分支机构大部分用户都能访问,但少数用户时而能访问时而不行,通过缩小故障包围圈,目前初步探明是内核参数 net.ipv4.tcp_tw_recycle = 1的问题,设置为0后初步解除故障。
通过此次故障,警示我们在进行日常程序,系统等变更,修改,重启等的操作上,需要我们严格按照流程仔细去进行测试,评估修改后的风险及出现问题回退和解决方法;特别是对内核参数的修改一定要理解透彻,不能盲目修改。然后进行逐步发布,避免故障影响全局。尽量让故障率降低。
http://blog.csdn.net/mei922/article/details/4801858TCP连接机制
http://blog.csdn.net/caianye/article/details/38540867
http://zhumeng8337797.blog.163.com/blog/static/100768914201262010163658/
2014-08-13 18:38 848人阅读 评论(0) 收藏 举报
临近年关,人会变得浮躁,期间写的代码可谓乱七八糟。不过出来混始终是要还的,这不最近就发现一个PHP脚本时常连不上服务器。
遇到这类问题,我习惯于先用strace命令跟踪了一下看看:
shell> strace php /path/to/file EADDRNOTAVAIL (Cannot assign requested address)
从字面结果看似乎是网络资源相关问题。这里顺便介绍一点小技巧:在调试的时候一般是从后往前看strace命令的结果,这样更容易找到有价值的信息。
查看一下当前的网络连接情况,结果发现TIME_WAIT数非常大:
shell> netstat -nt | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}' TIME_WAIT 28233
重复了几次测试,结果每次出问题的时候,TIME_WAIT都等于28233,这真是一个魔法数字!实际原因很简单,它取决于一个内核参数net.ipv4.ip_local_port_range:
shell> sysctl -a | grep port net.ipv4.ip_local_port_range = 32768 61000
因为端口范围是一个闭区间,所以实际可用的端口数量是:
shell> echo $((61000-32768+1)) 28233
问题分析到这里基本就清晰了,解决方向也明确了,内容所限,这里就不说如何优化程序代码了,只是从系统方面来阐述如何解决问题,无非就是以下两个方面:
首先是增加本地可用端口数量。这点可以用以下命令来实现:
shell> echo "net.ipv4.ip_local_port_range = 10240 61000" >> /etc/sysctl.conf shell> sysctl -p
其次是减少TIME_WAIT连接状态。网络上已经有不少相关的介绍,大多是建议:
shell> sysctl net.ipv4.tcp_tw_reuse=1 shell> sysctl net.ipv4.tcp_tw_recycle=1
注:通过sysctl命令修改内核参数,重启后会还原,要想持久化可以参考前面的方法。
这两个选项在降低TIME_WAIT数量方面可以说是立竿见影,不过如果你觉得问题已经完美搞定那就错了,实际上这样可能会引入一个更复杂的网络故障。
关于内核参数的详细介绍,可以参考官方文档。我们这里简要说明一下tcp_tw_recycle参数。它用来快速回收TIME_WAIT连接,不过如果在NAT环境下会引发问题。
RFC1323中有如下一段描述:
An additional mechanism could be added to the TCP, a per-hostcache of the last timestamp received from any connection.This value could then be used in the PAWS mechanism to rejectold duplicate segments from earlier incarnations of theconnection, if the timestamp clock can be guaranteed to haveticked at least once since the old connection was open. Thiswould require that the TIME-WAIT delay plus the RTT togethermust be at least one tick of the sender’s timestamp clock.Such an extension is not part of the proposal of this RFC.
大概意思是说TCP有一种行为,可以缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。
Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle,因为tcp_timestamps缺省就是开启的,所以当tcp_tw_recycle被开启后,实际上这种行为就被激活了。
现在很多公司都用LVS做负载均衡,通常是前面一台LVS,后面多台后端服务器,这其实就是NAT,当请求到达LVS后,它修改地址数据后便转发给后端服务器,但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是LVS的地址,加上端口会复用,所以从后端服务器的角度看,原本不同客户端的请求经过LVS的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,还可以通过下面命令来确认数据包不断被丢弃的现象:
shell> netstat -s | grep timestamp ... packets rejects in established connections because of timestamp
如果服务器身处NAT环境,安全起见,通常要禁止tcp_tw_recycle,至于TIME_WAIT连接过多的问题,可以通过激活tcp_tw_reuse来缓解。
进一步思考,既然必须同时激活tcp_timestamps和tcp_tw_recycle才会触发这种现象,那只要禁止tcp_timestamps,同时激活tcp_tw_recycle,就可以既避免NAT丢包问题,又降低TIME_WAIT连接数量。如果服务器并不依赖于RFC1323,那么这种方法应该也是可行的,不过最好多做测试,以防有其他的副作用。
shell> sysctl net.ipv4.tcp_timestamps=0 shell> sysctl net.ipv4.tcp_tw_recycle=1
…
总体来说,这次网络故障本身并没什么高深之处,本不想罗罗嗦嗦写这么多,不过拔出萝卜带出泥,在过程中牵扯的方方面面还是值得大家品味的,于是便有了这篇文字。
近来线上陆续出现了一些connect失败的问题,经过分析试验,最终确认和proc参数tcp_tw_recycle/tcp_timestamps相关;
1. 现象
第一个现象:模块A通过NAT网关访问服务S成功,而模块B通过NAT网关访问服务S经常性出现connect失败,抓包发现:服务S端已经收到了syn包,但没有回复synack;另外,模块A关闭了tcp timestamp,而模块B开启了tcp timestamp;
第二个现象:不同主机上的模块C(开启timestamp),通过NAT网关(1个出口ip)访问同一服务S,主机C1 connect成功,而主机C2 connect失败;
2. 分析
根据现象上述问题明显和tcp timestmap有关;查看linux 2.6.32内核源码,发现tcp_tw_recycle/tcp_timestamps都开启的条件下,60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。
源码函数:tcp_v4_conn_request(),该函数是tcp层三次握手syn包的处理函数(服务端);
源码片段:
if (tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
peer->v4daddr == saddr) {
if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
(s32)(peer->tcp_ts - req->ts_recent) >
TCP_PAWS_WINDOW) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
goto drop_and_release;
}
}
tmp_opt.saw_tstamp:该socket支持tcp_timestamp
sysctl_tw_recycle:本机系统开启tcp_tw_recycle选项
TCP_PAWS_MSL:60s,该条件判断表示该源ip的上次tcp通讯发生在60s内
TCP_PAWS_WINDOW:1,该条件判断表示该源ip的上次tcp通讯的timestamp 大于本次tcp
分析:主机client1和client2通过NAT网关(1个ip地址)访问serverN,由于timestamp时间为系统启动到当前的时间,因此,client1和client2的timestamp不相同;根据上述syn包处理源码,在tcp_tw_recycle和tcp_timestamps同时开启的条件下,timestamp大的主机访问serverN成功,而timestmap小的主机访问失败;
参数:/proc/sys/net/ipv4/tcp_timestamps - 控制timestamp选项开启/关闭
/proc/sys/net/ipv4/tcp_tw_recycle - 减少timewait socket释放的超时时间
3. 解决方法
echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle;
tcp_tw_recycle默认是关闭的,有不少服务器,为了提高性能,开启了该选项;
为了解决上述问题,个人建议关闭tcp_tw_recycle选项,而不是timestamp;因为 在tcp timestamp关闭的条件下,开启tcp_tw_recycle是不起作用的;而tcp timestamp可以独立开启并起作用。
源码函数: tcp_time_wait()
源码片段:
if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);
......
if (timeo < rto)
timeo = rto;
if (recycle_ok) {
tw->tw_timeout = rto;
} else {
tw->tw_timeout = TCP_TIMEWAIT_LEN;
if (state == TCP_TIME_WAIT)
timeo = TCP_TIMEWAIT_LEN;
}
inet_twsk_schedule(tw, &tcp_death_row, timeo,
TCP_TIMEWAIT_LEN);
timestamp和tw_recycle同时开启的条件下,timewait状态socket释放的超时时间和rto相关;否则,超时时间为TCP_TIMEWAIT_LEN,即60s;
内核说明文档 对该参数的介绍如下:
tcp_tw_recycle - BOOLEAN
Enable fast recycling TIME-WAIT sockets. Default value is 0.
It should not be changed without advice/request of technical
experts.
来源:http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
在一些高并发的 WebServer上,为了端口能够快速回收,打开了net.ipv4.tcp_tw_recycle,而在关闭 net.ipv4.tcp_tw_recycle的时候,kernal 是不会检查对端机器的包的时间戳的;打开了 tcp_tw_reccycle 了,就会检查时间戳,很不幸移动的cmwap发来的包的时间戳是乱跳的,所以服务器就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据,不是新的请求”,于是丢掉不回包,造成大量丢包。
#ExtMail专业版# 这两天在处理一个新签客户的古怪问题,分支机构大部分用户都能访问,但少数用户时而能访问时而不行,通过缩小故障包围圈,目前初步探明是内核参数 net.ipv4.tcp_tw_recycle = 1的问题,设置为0后初步解除故障。
通过此次故障,警示我们在进行日常程序,系统等变更,修改,重启等的操作上,需要我们严格按照流程仔细去进行测试,评估修改后的风险及出现问题回退和解决方法;特别是对内核参数的修改一定要理解透彻,不能盲目修改。然后进行逐步发布,避免故障影响全局。尽量让故障率降低。
相关推荐
net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 1 net.ipv4.tcp_keepalive_time = 1800 net.ipv4.tcp_max_tw_buckets = 6000 net.ipv4.tcp_mem = 94500000 915000000 927000000...
内容概要:本文详细介绍了利用FLAC3D进行隧道台阶法施工模拟的方法和技术细节。首先解释了隧道台阶法施工的基本流程,重点在于开挖命令的应用,如'zone cmodel assign'和'zone remove'用于改变区域本构模型并执行开挖操作。接着阐述了支护结构的设置方法,包括超前加固体、初衬、二衬、锚杆和锁脚锚杆的具体配置方式。此外,还讲解了如何通过'mesh'命令直接在FLAC3D中生成符合实际工程需求的网格模型。最后展示了模拟后的围岩体位移云图和应力云图,验证了计算结果的有效性,强调了这些数据对优化施工方案的重要性。 适合人群:从事岩土工程、隧道工程及相关领域的工程师和技术人员。 使用场景及目标:适用于需要进行隧道施工模拟的专业人士,旨在提升他们对FLAC3D的理解和应用能力,确保隧道施工的安全性和高效性。 其他说明:文中提供的实例和命令操作均基于真实项目经验,有助于读者更好地理解和掌握FLAC3D的实际应用技巧。
内容概要:本文介绍了纤维骨料细观尺度混凝土模型的设计与应用,重点在于如何通过控制骨料尺寸和体积率,在不同有限元软件(如Abaqus、Ansys、Ls-Dyna、Flac3d)中进行有效的四面体网格划分和六面体网格投影。文中提供了生成随机骨料位置和直径的Python代码片段,并详细解释了网格划分过程中需要注意的技术细节,如碰撞检测、网格转换公式以及材料属性设置。此外,还讨论了模型验证的方法及其在实际工程项目中的应用价值。 适合人群:从事土木工程、材料科学领域的研究人员和技术人员,尤其是那些需要利用有限元方法进行混凝土结构分析的专业人士。 使用场景及目标:①帮助工程师更好地理解和预测纤维混凝土的行为特性;②为实际工程项目提供理论支持和技术指导,从而优化纤维混凝土的应用;③提高仿真精度,减少实验成本和时间。 其他说明:文中提到的一些具体操作步骤和技术细节对于初学者来说可能具有一定挑战性,建议读者在实践中逐步掌握相关技能并积累经验。同时,正确设置物理量单位非常重要,错误的单位可能导致计算结果严重偏离预期。
嵌入式八股文面试题库资料知识宝典-c++个人笔记总结.zip
内容概要:本文详细介绍了西门子S7-1200 PLC在工业自动化领域的应用,重点讲解了其模块、板卡和通讯方式。首先概述了PLC模块和板卡作为基本单元的作用,接着深入探讨了支持的多种通讯协议,包括Modbus-RTU、S7通讯、Modbus-TCP和TCP/IP等。每种协议都配有具体的代码分析和调试方法。最后,介绍了博途V16编程软件的使用体验,强调了其对S7-1200 PLC编程的支持。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对西门子S7-1200 PLC有初步了解或希望深入了解的人群。 使用场景及目标:适用于需要掌握PLC模块化设计、不同通讯协议的应用场景,旨在帮助读者理解PLC的工作原理,提高编程和调试能力,从而更好地应用于实际项目中。 其他说明:文中提供的实例和代码分析有助于读者快速上手,同时推荐使用博途V16及以上版本的编程软件进行实践操作。
内容概要:本文介绍了Comsol仿真软件在等离子体空气反应领域的应用,重点探讨了其无模型反应框架的功能。该框架能模拟超过40种气体(如氧气、氮气、氦气)的详细反应过程,提供碰撞截面数据、迁移率扩散系数、速率系数和汤森系数的查询与求解功能,并通过bosig+模块实现自定义反应路径的选择。此外,文中强调了代码分析与实践应用的重要性,以及这些功能如何提升等离子体反应研究的效率和准确性。 适合人群:从事等离子体物理、化学反应动力学及相关领域研究的专业人士和技术人员。 使用场景及目标:适用于需要精确模拟复杂等离子体环境中气体反应的研究项目,旨在提高对等离子体反应机制的理解,优化实验设计,预测反应行为。 其他说明:Comsol仿真软件凭借其强大的计算能力,在等离子体研究中扮演着重要角色。随着技术的发展,该框架有望进一步推动相关领域的创新和发展。
嵌入式八股文面试题库资料知识宝典-同方万维硬件测试工程师.zip
嵌入式八股文面试题库资料知识宝典-c,c++笔试.zip
少儿编程scratch项目源代码文件案例素材-激光连接.zip
嵌入式八股文面试题库资料知识宝典-奔图电子-软件笔试试题v1.1(C,C++工程师).zip
嵌入式八股文面试题库资料知识宝典-国科环宇有限公司.zip
基于LDA主题模型对AIGC的影响力分析.pdf
可以自己添加应用和功能版,在/opt/upt/apps/下面添加ubin目录和ulib目录,把你想用的程序添加到ubin,支持模块添加到ulib中,就可以运行,具体刷机操作,请看《》
内容概要:本文探讨了遗传算法在车辆路径优化问题(VRP)中的应用及其改进,特别是在冷链物流、软时间窗和多配送中心场景下的路径优化策略。文中介绍了遗传算法通过模拟自然界进化过程来寻找最优路径解决方案的能力,并详细讨论了其在冷链物流中的重要性,即确保产品运输过程中的温度稳定和时效性。此外,还提到了软时间窗概念的应用,以平衡客户满意度和运输成本。在多配送中心场景下,遗传算法能有效处理复杂路径规划问题,如外卖配送路径优化和充电桩电车车辆路径优化。除了遗传算法,蚁群算法、模拟退火算法和粒子群算法也在不同类型的路径优化问题上得到广泛应用,如旅行商问题(TSP)、容量约束的车辆路径规划(CVRP)和带距离、容量和时间窗约束的车辆路径规划(VRPTW)。最后,文章强调了遗传算法改进的研究方向,旨在提高运算速度和精度,从而提升物流效率和客户满意度。 适合人群:从事物流与运输领域的研究人员和技术人员,对车辆路径优化感兴趣的学者和从业者。 使用场景及目标:适用于冷链物流、外卖配送、充电桩电车等多种实际应用场景,旨在优化路径规划,降低运输成本,提高客户满意度。 其他说明:本文不仅介绍了现有算法的应用情况,还指出了未来可能的研究方向和发展趋势。
内容概要:本文详细介绍了物流领域的车辆路径优化(VRP)及其扩展问题——带时间窗的车辆路径优化(VRPTW),并探讨了冷链物流车辆路径优化(考虑充电桩需求)。文中通过MATLAB实现了遗传算法解决这些问题的具体步骤,包括参数设置、种群初始化、适应度函数计算、遗传算法循环等。此外,还讨论了多配送中心场景下的路径优化挑战和其他优化算法(如蚁群算法、粒子群算法、节约算法和模拟退火算法)的应用。最后,针对冷链物流和电动汽车路径优化提出了具体的解决方案和技术细节。 适合人群:从事物流管理、运筹学、算法设计的研究人员和工程师,尤其是对MATLAB有一定基础的技术人员。 使用场景及目标:适用于需要优化物流配送路径的企业和个人,旨在提高配送效率、降低成本、提升服务质量。具体应用场景包括但不限于城市配送、冷链运输、电动车辆调度等。 其他说明:文中提供了完整的MATLAB代码示例,帮助读者更好地理解和实践各种优化算法。同时,强调了不同算法的特点和适用条件,便于读者根据实际情况选择最合适的算法。
嵌入式八股文面试题库资料知识宝典-文思创新面试题2.zip
嵌入式八股文面试题库资料知识宝典-网络编程.zip
少儿编程scratch项目源代码文件案例素材-火柴人防御.zip
AI数字形象制作口播视频
少儿编程scratch项目源代码文件案例素材-绝地武士冲刺.zip