注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

mie

 
 
 

日志

 
 

网络错误码10053和10054  

2014-05-19 18:12:58|  分类: 网络开发 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

        最近的一个软件中,部分情况下客户端会卡住(收不到网络消息),而一旦客户端主动发送某个网络消息,网络连接就会断开。

        这里,其实网络连接已经断开,由于没有开启keep alive,也没有发送心跳之类的,同时,出于性能考虑,后台运行时,和服务器无其他数据交互。当然,这可能被部分防火墙等当作无效连接给强制关闭连接(此说法未验证,不知道是否正确,道听途说,,)。

       而10053的错误,有的人认为可能是防火墙强制关闭连接。也就是说,如果我开启了keep alive,应该是可以避免这类情况发生的。于是,做了相应处理,但是还是频繁出现10053。

       本人并非专门做服务器的,所以对这类虽然知道不是自己的原因的问题,却没法给出合理的说法来排除自己的嫌疑。网上的说法众说纷纭,遇到过此类问题的人,写客户端的说是服务器导致的,写服务器的说是客户端主动关闭连接。为此,我找了一个简单的tcp服务器和tcp客户端的代码,进行了一个测试,并且重现了10053和10054错误:两个都是服务器端关闭了连接,客户端会收到10053或者10054,其中10054只重现了一次,其他都是10053.

      重现方法:开启服务器端——》开启客户端连接服务器——》结束服务器进程(其实是关闭连接,为了操作简单,这样处理)——》客户端recv(无任何反应)——》客户端send再recv,有错误码,可能是10053或者10054.

      那到底是什么原因呢?根据这个现象,大致可以排除各种不合理的解释,也证明下面的说法是正确的。

 

参考:socket error 10053,10054究竟是怎么引起的

http://bbs.csdn.net/topics/360024280


 

 
jwybobo2007
jwybobo2007
 

#13得分:100 回复于: 2011-01-27 11:17:23

出现10053的原因是因为在你执行这次send的时候对端已经执行过closesocket了,而发送的数据还是被成功的推入了发送缓冲区中,因此返回了0,此时你可能还没得到FIN消息,而紧接着recv这边就得到了对端关闭socket的FIN消息,因此此时需要放弃发送缓冲中的数据,异常终止连接,所以得到了
10053错误:您的主机中的软件中止了一个已建立的连接。
而为什么又能得到10054的错误号,原因应该在于你设置了SO_LINGER了,一但设置了它,则有一个等待时间,在该等待时间内可以处理发送缓冲区的数据,一但超时或者发送缓冲都被发送完并被确认,则服务端有可能发送RST消息而不是FIN,此时就应该得到重置错误,也就是10054。
不同的系统对SO_LINGER的实现方式不一样,得到的结果也不一样,不知道按我这样解释是否对你有帮助。如果我有理解错误,欢迎大家指正。

这位的解释正好完美解释了我的测试结果。非常感谢!!!

 

      由此可见,10053和10054大多是对端的问题。

      那么有没有可能是错误码出现方的问题呢?我们做同样的测试,我们closesocket,然后send或者recv,返回了错误码10038无效的套接字。可见我们自己又怎么能closesocket来关闭连接呢?!

      那么有没有可能木马关闭了socket呢?首先,如果是木马导致,出现概率会很小;其次,木马如果closesocket,我们自己照样没法使用socket,也是10038。而如果木马发送恶意的测试数据包,可能被服务器给closesocket,这可能会导致10053 10054,当然这种情况应该有对应的服务器日志。

      同上,协议错误,服务器可能会主动关闭连接。也是会出现10053 10054。

      有没有可能是防火墙导致的呢?这个未作测试,但如果是防火墙所致,不应该成为普遍现象。

 

2014.6.4

      通过加入心跳包解决. 加了keep alive 但是无效.  服务器模型是基于IOCP的, 虽然未作深入跟踪, 但客户端网络模型基于异步select,代码的处理也都没有问题, 而服务器的IOCP部分的一些处理并非安全, 这个问题暂时不管了,待过段时间有空了,写个iocp来分析一下.


2014.10.25

        解决!!!

         前段时间再次出现这个问题。同事查看了服务器端日志,没有异常情况。而我这边查了客户端日志,也没有异常情况。

          最终,我将怀疑目标指向运维配置的内网防火墙,因为听说此前更换过防火墙,而客户端收到10053,也就是在远端(非客户端的其他环节)断开了网络连接,既然不是服务器主动关闭连接,那只能是客户端和服务器之间的某个环节。我曾经查过几个同事的机器配置,以确定是否第三方软件防火墙所致,结果发现,有的纯净的机器也有这个问题。由此,只能是服务器和客户端机器之间了,所以 只能是内网防火墙。

         一直认为新来的运维技术不行,哈哈,终于被我给逮着了,重启防火墙之后,ok!后来过了几天又是这样,出现问题时,客户端的其他同事告诉运维重启防火墙。结果,这帮家伙打死不承认,然后过会儿问是不是好了,还说他们什么都没改,不是他们的问题,,,


By:zhanyonhu

  评论这张
 
阅读(2038)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016