tcp参数详解之tcp_fin_timeout
来源:互联网 发布:程序员口中的专业术语 编辑:程序博客网 时间:2024/06/16 14:04
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。
默认值是 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 发送FIN给Client,Server 就置为LAST_ACK状态。
Client ---> ACK ---> Server
Client回应了ACK,那么Server 的套接字才会真正置为CLOSED状态。
Server 程序处于CLOSE_WAIT状态,而不是LAST_ACK状态,说明还没有发FIN给Client,那么可能是在关闭连接之前还有许多数据要发送或者其他事要做,导致没有发这个FIN packet。
通常来说,一个CLOSE_WAIT会维持至少2个小时的时间。如果有个流氓特地写了个程序,给你造成一堆的CLOSE_WAIT,消耗资源,那么通常是等不到释放那一刻,系统就已经解决崩溃了。
0 0
- tcp参数详解之tcp_fin_timeout
- tcp参数详解之tcp_fin_timeout
- tcp参数详解之tcp_fin_timeout
- tcp参数详解之tcp_fin_timeout
- TCP/IP编程之listen函数backlog参数详解(linux)
- tcp之backlog参数
- TCP listen() Backlog 参数详解
- TCP listen() Backlog 参数详解
- TCP参数调优详解
- 分享tcp参数详解的两篇文章
- DataSnap-TCP keepAlive和KeepAliveInterval参数详解
- 抓包参数tcp[13]详解
- rpm之参数详解
- Tcp-IP详解之Telnet
- TCP/IP详解之链路层
- TCP之拥塞处理详解
- TCP之拥塞处理详解
- Linux 之 TCP 协议详解
- 理解PCA原理与C++\Matlab实现
- redhat6.5安装redis和telnet
- Cocoapod 安装使用笔记
- 队列与栈相互实现
- HibernateUtil工具类
- tcp参数详解之tcp_fin_timeout
- post和get请求
- Linux USB系统
- 101. Symmetric Tree | 判断二叉树是否为镜像二叉树
- mac80211解析七
- Spring+SpringMVC+MyBatis+easyUI整合基础篇(一)项目简介
- JavaScript——封装输出log信息的方法
- S2 一本书 Day06上机练习1-4
- SpringMVC入门之九:multipart文件上传