- 浏览: 2663551 次
- 来自: 杭州
文章分类
- 全部博客 (1188)
- webwork (4)
- 网摘 (18)
- java (103)
- hibernate (1)
- Linux (85)
- 职业发展 (1)
- activeMQ (2)
- netty (14)
- svn (1)
- webx3 (12)
- mysql (81)
- css (1)
- HTML (6)
- apache (3)
- 测试 (2)
- javascript (1)
- 储存 (1)
- jvm (5)
- code (13)
- 多线程 (12)
- Spring (18)
- webxs (2)
- python (119)
- duitang (0)
- mongo (3)
- nosql (4)
- tomcat (4)
- memcached (20)
- 算法 (28)
- django (28)
- shell (1)
- 工作总结 (5)
- solr (42)
- beansdb (6)
- nginx (3)
- 性能 (30)
- 数据推荐 (1)
- maven (8)
- tonado (1)
- uwsgi (5)
- hessian (4)
- ibatis (3)
- Security (2)
- HTPP (1)
- gevent (6)
- 读书笔记 (1)
- Maxent (2)
- mogo (0)
- thread (3)
- 架构 (5)
- NIO (5)
- 正则 (1)
- lucene (5)
- feed (4)
- redis (17)
- TCP (6)
- test (0)
- python,code (1)
- PIL (3)
- guava (2)
- jython (4)
- httpclient (2)
- cache (3)
- signal (1)
- dubbo (7)
- HTTP (4)
- json (3)
- java socket (1)
- io (2)
- socket (22)
- hash (2)
- Cassandra (1)
- 分布式文件系统 (5)
- Dynamo (2)
- gc (8)
- scp (1)
- rsync (1)
- mecached (0)
- mongoDB (29)
- Thrift (1)
- scribe (2)
- 服务化 (3)
- 问题 (83)
- mat (1)
- classloader (2)
- javaBean (1)
- 文档集合 (27)
- 消息队列 (3)
- nginx,文档集合 (1)
- dboss (12)
- libevent (1)
- 读书 (0)
- 数学 (3)
- 流程 (0)
- HBase (34)
- 自动化测试 (1)
- ubuntu (2)
- 并发 (1)
- sping (1)
- 图形 (1)
- freemarker (1)
- jdbc (3)
- dbcp (0)
- sharding (1)
- 性能测试 (1)
- 设计模式 (2)
- unicode (1)
- OceanBase (3)
- jmagick (1)
- gunicorn (1)
- url (1)
- form (1)
- 安全 (2)
- nlp (8)
- libmemcached (1)
- 规则引擎 (1)
- awk (2)
- 服务器 (1)
- snmpd (1)
- btrace (1)
- 代码 (1)
- cygwin (1)
- mahout (3)
- 电子书 (1)
- 机器学习 (5)
- 数据挖掘 (1)
- nltk (6)
- pool (1)
- log4j (2)
- 总结 (11)
- c++ (1)
- java源代码 (1)
- ocr (1)
- 基础算法 (3)
- SA (1)
- 笔记 (1)
- ml (4)
- zokeeper (0)
- jms (1)
- zookeeper (5)
- zkclient (1)
- hadoop (13)
- mq (2)
- git (9)
- 问题,io (1)
- storm (11)
- zk (1)
- 性能优化 (2)
- example (1)
- tmux (1)
- 环境 (2)
- kyro (1)
- 日志系统 (3)
- hdfs (2)
- python_socket (2)
- date (2)
- elasticsearch (1)
- jetty (1)
- 树 (1)
- 汽车 (1)
- mdrill (1)
- 车 (1)
- 日志 (1)
- web (1)
- 编译原理 (1)
- 信息检索 (1)
- 性能,linux (1)
- spam (1)
- 序列化 (1)
- fabric (2)
- guice (1)
- disruptor (1)
- executor (1)
- logback (2)
- 开源 (1)
- 设计 (1)
- 监控 (3)
- english (1)
- 问题记录 (1)
- Bitmap (1)
- 云计算 (1)
- 问题排查 (1)
- highchat (1)
- mac (3)
- docker (1)
- jdk (1)
- 表达式 (1)
- 网络 (1)
- 时间管理 (1)
- 时间序列 (1)
- OLAP (1)
- Big Table (0)
- sql (1)
- kafka (1)
- md5 (1)
- springboot (1)
- spring security (1)
- Spring Boot (3)
- mybatis (1)
- java8 (1)
- 分布式事务 (1)
- 限流 (1)
- Shadowsocks (0)
- 2018 (1)
- 服务治理 (1)
- 设计原则 (1)
- log (0)
- perftools (1)
最新评论
-
siphlina:
课程——基于Python数据分析与机器学习案例实战教程分享网盘 ...
Python机器学习库 -
san_yun:
leibnitz 写道hi,我想知道,无论在92还是94版本, ...
hbase的行锁与多版本并发控制(MVCC) -
leibnitz:
hi,我想知道,无论在92还是94版本,更新时(如Puts)都 ...
hbase的行锁与多版本并发控制(MVCC) -
107x:
不错,谢谢!
Latent Semantic Analysis(LSA/ LSI)算法简介 -
107x:
不错,谢谢!
Python机器学习库
http://blog.csdn.net/lionzl/article/details/4007206
///
允许重用本地地址和端口:
///
这样的好处是,即使socket断了,调用前面的socket函数也不会占用另一个,而是始终就是一个端口
///
这样防止socket始终连接不上,那么按照原来的做法,会不断地换端口。
int
nREUSEADDR = 1;
setsockopt(sockConnected,
SOL_SOCKET,
SO_REUSEADDR,
(const
char
*)&nREUSEADDR,
sizeof
(int
));
|
linger m_sLinger;
m_sLinger.l_onoff = 1; // (
在closesocket()调用,但是还有数据没发送完毕的时候容许逗留)
m_sLinger.l_linger = 0; // (
容许逗留的时间为0秒)
setsockopt(sockConnected,
SOL_SOCKET,
SO_LINGER,
(const
char
*)&m_sLinger,
sizeof
(linger));
|
Feedback
# 回复:[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:41 PM yun.zheng
回复人: elssann(臭屁虫和他的开心果) ( ) 信誉:51 2005-01-30 14:00:00 得分: 0
我的意思是:当一方关闭连接后,另外一方没有检测到,就导致了CLOSE_WAIT的出现,上次我的一个朋友也是这样,他写了一个客户端和
APACHE连接,当APACHE把连接断掉后,他没检测到,出现了CLOSE_WAIT,后来我叫他检测了这个地方,他添加了调用
closesocket的代码后,这个问题就消除了。
如果你在关闭连接前还是出现CLOSE_WAIT,建议你取消shutdown的调用,直接两边closesocket试试。
另外一个问题:
比如这样的一个例子:
当客户端登录上服务器后,发送身份验证的请求,服务器收到了数据,对客户端身份进行验证,发现密码错误,这时候服务器的一般做法应该是先发送一个密码错误的信息给客户端,然后把连接断掉。
如果把
m_sLinger.l_onoff = 1;
m_sLinger.l_linger = 0;
这样设置后,很多情况下,客户端根本就收不到密码错误的消息,连接就被断了。
# 回复:[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:41 PM yun.zheng
elssann(臭屁虫和他的开心果) ( ) 信誉:51 2005-01-30 13:24:00 得分: 0
出现CLOSE_WAIT的原因很简单,就是某一方在网络连接断开后,没有检测到这个错误,没有执行closesocket,导致了这个状态的实现,这在TCP/IP协议的状态变迁图上可以清楚看到。同时和这个相对应的还有一种叫TIME_WAIT的。
另外,把SOCKET的SO_LINGER设置为0秒拖延(也就是立即关闭)在很多时候是有害处的。
还有,把端口设置为可复用是一种不安全的网络编程方法。
# 回复:[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:42 PM yun.zheng
elssann(臭屁虫和他的开心果) ( ) 信誉:51 2005-01-30 14:48:00 得分: 0
能不能解释请看这里
http://blog.csdn.net/cqq/archive/2005/01/26/269160.aspx
再看这个图:
http://tech.ccidnet.com/pub/attachment/2004/8/322252.png
断开连接的时候,
当发起主动关闭的左边这方发送一个FIN过去后,右边被动关闭的这方要回应一个ACK,这个ACK是TCP回应的,而不
是应用程序发送的,此时,被动关闭的一方就处于CLOSE_WAIT状态了。如果此时被动关闭的这一方不再继续调用closesocket,那么他就不会
发送接下来的FIN,导致自己老是处于CLOSE_WAIT。只有被动关闭的这一方调用了closesocket,才会发送一个FIN给主动关闭的这一
方,同时也使得自己的状态变迁为LAST_ACK。
# 回复:[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:54 PM yun.zheng
elssann(臭屁虫和他的开心果) ( ) 信誉:51 2005-01-30 15:39:00 得分: 0
比如被动关闭的是客户端。。。
当对方调用closesocket的时候,你的程序正在
int nRet = recv(s,....);
if (nRet == SOCKET_ERROR)
{
// closesocket(s);
return FALSE;
}
很多人就是忘记了那句closesocket,这种代码太常见了。
我的理解,当主动关闭的一方发送FIN到被动关闭这边后,被动关闭这边的TCP马上回应一个ACK过去,同时向上面应用程序提交一个ERROR,导 致上面的SOCKET的send或者recv返回SOCKET_ERROR,正常情况下,如果上面在返回SOCKET_ERROR后调用了 closesocket,那么被动关闭的者一方的TCP就会发送一个FIN过去,自己的状态就变迁到LAST_ACK.
# 回复:[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 4:17 PM yun.zheng
int nRecvBufLength =
recv(sockConnected,
szRecvBuffer,
sizeof(szRecvBuffer),
0);
/// zhengyun 20050130:
/// elssann举例说,当对方调用closesocket的时候,我的程序正在
/// recv,这时候有可能对方发送的FIN包我没有收到,而是由TCP代回了
/// 一个ACK包,所以我这边程序进入CLOSE_WAIT状态。
/// 所以他建议在这里判断是否已出错,是就主动closesocket。
/// 因为前面我们已经设置了recv超时时间为30秒,那么如果真的是超时了,
/// 这里收到的错误应该是WSAETIMEDOUT,这种情况下也可以关闭连接的
if (nRecvBufLength == SOCKET_ERROR)
{
TRACE_INFO(_T("=用recv接收发生Socket错误="));
closesocket(sockConnected);
continue;
}
网络连接无法释放—— CLOSE_WAIT
关键字: TCP ,CLOSE_WAIT, Java, SocketChannel
问题描述: 最 近性能测试碰到的一个问题。客户端使用NIO,服务器还是一般的Socket连接。当测试进行一段时间以后,发现服务器端的系统出现大量未释放的网络连 接。用netstat -na查看,连接状态为CLOSE_WAIT。这就奇怪了,为什么Socket已经关闭而连接依然未释放。
解决: Google了半天,发现关于CLOSE_WAIT的问题一般是C的,Java似乎碰到这个问题的不多(这有一篇 不错的,也是解决CLOSE_WAIT的,但是好像没有根本解决,而是选择了一个折中的办法)。接着找,由于使用了NIO,所以怀疑可能是这方面的问题,结果找到了这篇 。顺着帖子翻下去,其中有几个人说到了一个问题—— 一端的Socket调用close后,另一端的Socket没有调用close .于是查了一下代码,果然发现Server端在某些异常情况时,没有关闭Socket。改正后问题解决。
时间基本上花在Google上了,不过也学到不少东西。下面为一张TCP连接的状态转换图:
说明:虚线和实线分别对应服务器端(被连接端)和客户端端(主动连接端)。
结合上图使用netstat -na命令即可知道到当前的TCP连接状态。一般LISTEN、ESTABLISHED、TIME_WAIT是比较常见。
分析:
上面我碰到的这个问题主要因为TCP的结束流程未走完,造成连接未释放。现设客户端主动断开连接,流程如下
Client 消息 Server
close()
------ FIN ------->
FIN_WAIT1 CLOSE_WAIT
<----- ACK -------
FIN_WAIT2
close()
<------ FIN ------
TIME_WAIT LAST_ACK
------ ACK ------->
CLOSED
CLOSED
如上图所示,由于Server的Socket在客户端已经关闭时而没有调用关闭,造成服务器端的连接处在“挂起”状态,而客户端则处在等待应答的状态上。此问题的典型特征是:一端处于FIN_WAIT2 ,而另一端处于CLOSE_WAIT . 不过,根本问题还是程序写的不好,有待提高。
TIME_WAIT状态
根据TCP协议,主动发起关闭的一方,会进入TIME_WAIT状态,持续2*MSL(Max Segment Lifetime),缺省为240秒,在这个post 中简洁的介绍了为什么需要这个状态。
值得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可 想而知,对于访问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压240*1000=240,000个 TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。
HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个 request/response,一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少,因为 240秒的时间实在是忒长了点,对于Windows,修改注册表,在HKEY_LOCAL_MACHINE/ SYSTEM/CurrentControlSet/Services/ Tcpip/Parameters上添加一个DWORD类型的值TcpTimedWaitDelay,一般认为不要少于60,不然可能会有麻烦。
对于大型的服务,一台server搞不定,需要一个LB(Load Balancer)把流量分配到若干后端服务器上,如果这个LB是以NAT方式工作的话,可能会带来问题。假如所有从LB到后端Server的IP包的 source address都是一样的(LB的对内地址),那么LB到后端Server的TCP连接会受限制,因为频繁的TCP连接建立和关闭,会在server上留 下TIME_WAIT状态,而且这些状态对应的remote address都是LB的,LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口,还有一些其他端口缺省也不会用),每个LB上的端口一旦进入 Server的TIME_WAIT黑名单,就有240秒不能再用来建立和Server的连接,这样LB和Server最多也就能支持300个左右的连接。 如果没有LB,不会有这个问题,因为这样server看到的remote address是internet上广阔无垠的集合,对每个address,60000多个port实在是够用了。
一开始我觉得用上LB会很大程度上限制TCP的连接数,但是实验表明没这回事,LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个,难道TIME_WAIT状态没起作用?用Net Monitor和netstat观察后发现,Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后,再来一个LB的XXXX端口的 SYN包,Server照样接收处理了,而是想像的那样被drop掉了。翻书,从书堆里面找出覆满尘土的大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》,中间提到一句,对于BSD-derived实现,只要SYN的sequence number比上一次关闭时的最大sequence number还要大,那么TIME_WAIT状态一样接受这个SYN,难不成Windows也算BSD-derived?有了这点线索和关键字 (BSD),找到这个post ,在NT4.0的时候,还是和BSD-derived不一样的,不过Windows Server 2003已经是NT5.2了,也许有点差别了。
做个试验,用Socket API编一个Client端,每次都Bind到本地一个端口比如2345,重复的建立TCP连接往一个Server发送Keep-Alive=false 的HTTP请求,Windows的实现让sequence number不断的增长,所以虽然Server对于Client的2345端口连接保持TIME_WAIT状态,但是总是能够接受新的请求,不会拒绝。那 如果SYN的Sequence Number变小会怎么样呢?同样用Socket API,不过这次用Raw IP,发送一个小sequence number的SYN包过去,Net Monitor里面看到,这个SYN被Server接收后如泥牛如海,一点反应没有,被drop掉了。
按照书上的说法,BSD-derived和Windows Server 2003的做法有安全隐患,不过至少这样至少不会出现TIME_WAIT阻止TCP请求的问题,当然,客户端要配合,保证不同TCP连接的sequence number要上涨不要下降。
发表评论
-
TCP连接状态异常记录
2018-08-16 14:36 1466参考:http://blueskykong.com/2018 ... -
TCP 协议介绍(三次握手,滑动窗口)
2014-08-14 16:29 3042http://condor.depaul.edu/jkri ... -
再谈KeepAlive
2014-07-28 14:48 1018为什么要有KeepAlive? 在谈KeepAlive之前 ... -
TCP 滑动窗口协议
2013-11-07 18:36 5558TCP滑动窗口机制 我们可以大概看一下上图的模型 ... -
再谈应用环境下的TIME_WAIT和CLOSE_WAIT
2012-10-11 15:38 4814原文:http://shootyou.iteye.co ...
相关推荐
TCP状态转换和IO多路转接 TCP状态转换是网络协议中的一种关键技术,它定义了TCP连接的七个状态:LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2和TIME_WAIT。这些状态之间的转换是通过三次握手...
本文将详细阐述TCP状态转换图中的关键状态,主要关注三次握手和四次挥手过程。 首先,TCP连接的建立过程,也就是著名的三次握手: 1. **CLOSED**: 所有连接的起始和结束状态,表示没有任何连接活动。 2. **LISTEN*...
下面我们将详细探讨TCP状态转换的各个阶段。 1. **CLOSED**: 这是TCP连接的初始和最终状态,表示连接未建立或已关闭。 2. **LISTEN**: 当一个TCP端点准备接受来自其他端点的连接请求时,它进入LISTEN状态。在这个...
TCP状态转换图详解.pdf
tcp状态图,高清,可以收藏多年。
TCP(Transmission Control Protocol)是一...理解TCP状态转换对于排查网络连接问题,优化连接建立和关闭的流程,以及处理异常网络条件非常重要。在Windows编程中,正确处理这些状态能够确保网络程序的稳定性和可靠性。
TCP共有11个网路状态,其中涉及到关闭的状态有5个。 在我们编写网络相关程序的时候,这5个状态经常出现。因为这5个状态相互关 联,相互纠缠,... 下是是根据W.Richard Stevens的《TCP/IP详解》一书的TCP状态转换图。
除了TCP状态转换,UDP(User Datagram Protocol)是一种无连接的协议,没有建立和关闭连接的过程,它的报文结构相对简单,包括源和目的端口号以及数据部分。 此外,子网划分是网络管理中的一种技术,通过子网掩码将...
这些状态之间的转换是TCP状态机的核心部分,具体如下: - 当客户端发送SYN报文段后,状态变为`SYN_SENT`。 - 服务器接收到SYN报文段并发送SYN+ACK报文段后,状态变为`SYN_RCVD`。 - 客户端接收到SYN+ACK报文段并...
7. **TCP状态转换图**:展示TCP连接从建立到结束期间经历的各种状态,如CLOSED、LISTEN、SYN_SENT、SYN_RECEIVED、ESTABLISHED等。 8. **应用层协议与TCP的交互**:如HTTP、FTP、SMTP等如何利用TCP进行数据传输。 ...
用VISSO画的TCP协议状态图,用于表示TCp的状态的转换.
七、TCP状态转换图 TCP连接有多种状态,如CLOSED、LISTEN、SYN_SENT、SYN_RECEIVED、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT等。理解这些状态和它们之间的转换对于诊断TCP...
#### 三、TCP状态及转换 ##### 1. 客户端TCP状态迁移 - **CLOSED**:初始状态,没有任何连接状态。 - **SYN_SENT**:在客户端发送连接请求(SYN)后,进入此状态,等待接收服务器的响应。 - **ESTABLISHED**:在...
本书深入浅出地解析了TCP的工作原理,涵盖了TCP连接的建立和终止、TCP窗口机制、拥塞控制、TCP状态转换图以及TCP选项等核心知识点。 从部分内容中可以看出,本书不仅仅关注于TCP协议,同样涉及到了UDP协议,以及...
无论是主动关闭连接的一方还是被动关闭的一方,完成所有状态转换后最终都会回到CLOSED状态,表示TCP连接完全关闭。 TCP状态变迁图清楚地展示了这些状态的流转,有助于理解和排查网络通信中的问题。理解TCP连接的...
一、TCP 状态转换图 在 F5 会话处理流程中,TCP 状态转换图是非常重要的一部分。 TCP 状态转换图描述了客户端与服务器之间的连接建立和终止过程。 1. 建立连接协议(三次握手) * 客户端发送一个带 SYN 标志的 ...
3. **TCP状态转换**:TCP连接经历CLOSED、LISTEN、SYN_SENT、SYN_RECEIVED、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK和TIME_WAIT等状态。 4. **流量控制**:TCP通过滑动窗口机制实现...
本教程将详细讲解如何通过OPC_OPC转MODBUS-TCP转换,以及OPC_MODBUS协议转换的相关知识。 首先,理解OPC与MODBUS协议的基本概念: 1. OPC:OPC是为了解决不同厂商的工业自动化设备之间数据交换的标准接口。它包括...