Chinaunix首页 | 论坛 | 博客
  • 博客访问: 520140
  • 博文数量: 100
  • 博客积分: 2058
  • 博客等级: 大尉
  • 技术积分: 1029
  • 用 户 组: 普通用户
  • 注册时间: 2010-07-14 23:29
文章分类
文章存档

2011年(94)

2010年(6)

分类: 系统运维

2011-05-04 17:14:17

tcp_fin_timeout :INTEGER
默认值是 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 发送FINClientServer 就置为LAST_ACK状态。

       Client --->  ACK  --->  Server 

Client回应了ACK,那么Server 的套接字才会真正置为CLOSED状态。

Server 程序处于CLOSE_WAIT状态,而不是LAST_ACK状态,说明还没有发FINClient,那么可能是在关闭连接之前还有许多数据要发送或者其他事要做,导致没有发这个FIN packet

通常来说,一个CLOSE_WAIT会维持至少2个小时的时间。如果有个流氓特地写了个程序,给你造成一堆的CLOSE_WAIT,消耗资源,那么通常是等不到释放那一刻,系统就已经解决崩溃了。


阅读(17511) | 评论(0) | 转发(0) |
0

上一篇:TCP Keepalive HOWTO

下一篇:ruby patron包的简介

给主人留下些什么吧!~~