文档章节

TCP异常关闭研究分析

偶素浅小浅
 偶素浅小浅
发布于 2016/11/02 19:51
字数 4033
阅读 50
收藏 1

版权声明:本文由谢代斌原创文章,转载请注明出处: 
文章原文链接:https://www.qcloud.com/community/article/108

来源:腾云阁 https://www.qcloud.com/community

研究测试TCP断开和异常的各种情况,以便于分析网络应用(比如tconnd)断网的原因和场景,帮组分析和定位连接异常掉线的问题,并提供给TCP相关的开发测试人员作为参考。

各个游戏接入都存在一定的掉线问题,而且有的游戏项目的掉线比例还比较高,现在互娱自研游戏的网络接入基本上都用的是tconnd和ProtocalHandler组件(该组件请参考附件的《TSF4G_ProtocalHandler开发指导手册》),因此参与其掉线原因分析和研究。

在参与A项目的掉线问题研究分析过程中,tconnd增加了玩家每个连接的流水日志和ProtocalHandler增加了每个连接的Qos上报日志,通过这些日志记录了每一次连接的断开原因和相关统计数据,其中包括了连接异常断开时TCP的底层错误码。

通过对tconnd的流水日志和ProtocalHandler的Qos日志进行统计分析,发现连接异常断开时TCP的错误码大部分是“104: Connection reset by peer”(Linux下)或“10054: An existing connection was forcibly closed by the remote host”(Windows下),单纯从错误码本来来说,大家都明白是“网络被对端重置了”,但究竟什么情况下会导致这种情况呢?因此就对TCP的各种关闭情况做了进一步的测试研究。

一. TCP异常关闭的研究测试

1. 服务器端只Recv消息而不Send消息

1.1 测试方法

服务器程序在接受客户端的TCP连接后Sleep几秒钟,客户端程序在TCP连接后立即发送很多消息给对端后做相应动作(退出或等待),服务器程序Sleep完后开始Recv消息。

注意:服务器程序测试了Linux和Windows版本,但客户端只测试了Windows版本,如果是Linux客户端则有些Case的结果会不一样。

1.2 测试Case

  • 客户端程序正常运行的情况下,拔掉网线,杀掉客户端程序
    目的:模拟客户端死机、系统突然重启、网线松动或网络不通等情况。
    结论:这种情况下服务器程序没有检测到任何异常,并最后等待“超时”才断开TCP连接。

  • 客户端程序发送很多数据包后正常关闭Socket并exit进程(或不退出进程)
    目的:模拟客户端发送完消息后正常退出的情况。
    结论:这种情况下服务器程序能够成功接收完所有消息,并最后收到“对端关闭”(Recv返回零)消息。

  • 客户端程序发送很多数据包后不关闭Socket直接exit进程
    目的:模拟客户端程序退出而忘记关闭Socket的情况(比如通过Windows窗口的关闭图标退出进程,而没有捕获相应关闭事件做正常退出处理等)。
    结论:这种情况下服务器程序能够收到部分TCP消息,然后收到“104: Connection reset by peer”(Linux下)或“10054: An existing connection was forcibly closed by the remote host”(Windows下)错误。

  • 客户端程序发送很多数据包的过程中直接Kill进程
    目的:模拟客户端程序崩溃或非正常方式结束进程(比如Linux下"kill -9"或Windows的任务管理器杀死进程)的情况。
    结论:这种情况下服务器程序很快收到“104: Connection reset by peer”(Linux下)或“10054: An existing connection was forcibly closed by the remote host”(Windows下)错误。

2.服务器端Recv消息并Send应答消息

2.1 测试方法

服务器程序在接受客户端的TCP连接后Sleep几秒钟,客户端程序在TCP连接后立即发送很多消息给对端后做相应动作(退出或等待),服务器程序Sleep完后开始Recv和Send消息。

注意:服务器程序测试了Linux和Windows版本,但客户端只测试了Windows版本,如果是Linux客户端则有些Case的结果可能会不一样。

2.2 测试结果

  • 客户端程序发送很多数据包后正常关闭Socket并exit进程(或不退出进程)
    目的:模拟客户端正常关闭Socket后,服务器端在检查到TCP对端关闭前向客户端发送消息的情况。
    结论:这种情况下服务器程序接收和发送部分TCP消息后,在Send消息时产生“32: Broken pipe”(Linux下)或“10053: An established connection was aborted by the software in your host machine”(Windows下)错误。

  • 客户端程序发送很多数据包后不关闭Socket直接exit或Kill进程
    目的:模拟客户端程序退出而忘记关闭Socket、或客户端程序崩溃或非正常方式结束进程的情况。
    结论:这种情况下服务器程序在Recv或Send消息时产生“104: Connection reset by peer”(Linux下)或“10054: An existing connection was forcibly closed by the remote host”(Windows下)错误。

3. 效果和总结

3.1 总结

TCP发现网络异常(特别是Linux下的104错误或Windows下10054错误)的情况很多,比如网络本身的问题、中间路由器问题、网卡驱动器问题等不可抗拒因素,但下面是应用程序本身可能会导致的问题,也是我们需要进一步研究和解决的情况,特别是程序崩溃导致问题:

  • 当TCP连接的进程在忘记关闭Socket而退出、程序崩溃、或非正常方式结束进程的情况下
    (Windows客户端),会导致TCP连接的对端进程产生“104: Connection reset by peer”(Linux下)或“10054: An existing connection was forcibly closed by the remote host”(Windows下)错误。

  • 当TCP连接的进程机器发生死机、系统突然重启、网线松动或网络不通等情况下
    -(Windows客户端),连接的对端进程可能检测不到任何异常,并最后等待“超时”才断开TCP连接。

  • 当TCP连接的进程正常关闭Socket时,对端进程在检查到TCP关闭事件之前仍然向TCP发送消息
    (Windows客户端),则在Send消息时会产生“32: Broken pipe”(Linux下)或“10053: An established connection was aborted by the software in your host machine”(Windows下)错误。

3.2 效果

针对A项目的掉线问题,通过问卷调查和联系个别玩家等方法,发现掉线的情况很大部分是客户端程序直接退出了,因此推动项目组实现了客户端的Qos上报功能,最后通过客户端的Qos上报的统计数据得出客户端程序的崩溃比例比较高,占了总掉线的很大比率,当然其它情况也存在,但比例相对比较小。

因此,A项目首先应该解决客户端程序的崩溃问题,如果该问题解决了,也就解决大部分掉线问题。

二. TCP异常关闭的进一步研究测试

1. 背景

B项目游戏在跨服跳转时的掉线比例比较高,经过分析ProtocalHandler和tconnd的日志,发现掉线出现的情况是:tconnd发送了跨服跳转消息后立即关闭了Socket,客户端进程在接收到跨服跳转消息之前发送消息后收到Windows 10054错误,然后做断线重连失败。

B项目实现跨服跳转的流程是GameSvr给客户端程序下发的跨服跳转命令的同时携带了Stop请求,也就是说tconnd在向客户端转发跨服跳转消息后立即就会关闭当前的Socket连接,而且B项目的客户端程序会定期不断地向服务器上报消息。这又怎么会导致客户端程序收到10054错误而呢?鉴于此,对TCP的连接做进一步的场景测试分析。

2. TCP异常进一步测试研究

2.1 测试方法

客户端和服务器端程序建立TCP连接,服务器程序在TCP缓冲区中有消息或没有消息的情况下关闭Socket,客户端在对端Socket已经关闭的情况下继续Send和Recv消息。

注意:服务器端只测试了Linux版本,但客户端测试了Windows和Linux两个版本。

2.2 测试结果

  • 服务器端已经close了Socket,客户端再发送数据
    目的:测试在TCP对端进程已经关闭Socket时,本端进程还未检测到连接关闭的情况下继续向对端发送消息。
    结论:第一包可以发送成功,但第二包发送失败,错误码为“10053: An established connection was aborted by the software in your host machine”(Windows下)或“32: Broken pipe,同时收到SIGPIPE信号”(Linux下)错误。

  • 服务器端发送数据到TCP后close了Socket,客户端再发送一包数据,然后接收消息
    目的:测试在TCP对端进程发送数据后关闭Socket,本端进程还未检测到连接关闭的情况下发送一包消息,接着接收消息。
    结论:客户端能够成功发送第一包数据(这会导致服务器端发送一个RST包 <已抓包验证>),客户端再去Recv时,对于Windows和Linux程序有如下不同的表现:
    Windows客户端程序:Recv失败,错误码为“10053: An established connection was aborted by the software in your host machine”。
    Linux客户端程序:能正常接收完所有消息包,最后收到正常的对端关闭消息(这一点与Window下不一样,RST包没有被提前接收到)。

  • 服务器端在TCP的接收缓冲区中还有未接收数据的情况下close了Socket,客户端再收包
    目的:测试在TCP的接收缓冲区中还有未接收数据的情况下关闭Socket时,对端进程是否正常。
    结论:这种情况服务器端就会向对端发送RST包,而不是正常的FIN包(已经抓包证明),这就会导致客户端提前(RST包比正常数据包先被收到)收到“10054: An existing connection was forcibly closed by the remote host”(Windows下)或“104: Connection reset by peer”(Linux下)错误。

3 效果和总结

3.1 总结

TCP应用程序某些看是正常的行为下也可能会导致对端接收到异常,比如当TCP接收缓冲区中还有未收数据的情况下关闭Socket,则会导致对端接收到异常关闭而不是正常关闭;反过来说,当TCP检测到异常关闭时并不一定表示业务上出问题了,因为很可能就是业务正常结束了。下面是本次测试的主要结论:

  • 当TCP连接的对端进程已经关闭了Socket的情况下,本端进程再发送数据时,第一包可以发送成功(但会导致对端发送一个RST包过来):之后如果再继续发送数据会失败,错误码为“10053: An established connection was aborted by the software in your host machine”(Windows下)或“32: Broken pipe,同时收到SIGPIPE信号”(Linux下)错误;之后如果接收数据,则Windows下会报10053的错误,而Linux下则收到正常关闭消息。

  • TCP连接的本端接收缓冲区中还有未接收数据的情况下close了Socket,则本端TCP会向对端发送RST包,而不是正常的FIN包,这就会导致对端进程提前(RST包比正常数据包先被收到)收到“10054: An existing connection was forcibly closed by the remote host”(Windows下)或“104: Connection reset by peer”(Linux下)错误。

3.2 效果

B项目跨服跳转的掉线问题有相当一部分的种情况是tconnd向客户端转发跨服跳转消息后立即关闭Socket连接,而此时刚好客户端向tconnd发送了数据包:

  • 第一种情况:tconnd在关闭Socket的时刻其TCP的接收缓冲区中有未收的消息,这就使得tconnd进程的TCP向客户端发送的是RST包而不是正常结束的FIN包,所以客户端程序就会提前收到RST包(RST包会比正常数据提前收到),而不会先收完跨服跳转消息后再接收到正常结束消息,这就导致客户端收到网络异常断线而做重连,但之前的连接是tconnd主动关闭的,所以不可能重连成功,从而导致掉线。

  • 第二种情况:tconnd已经关闭了Socket后,客户端在接收到跳转消息和检测到TCP关闭之前向tconnd发送了消息,这就会导致客户端程序收到异常断线而做重连并失败。

最后,与B项目项目组一起讨论,改进了大部分跨服跳转的业务流程后,掉线比例j减少了很多,当然还是存在一定比例的掉线,但这应该就是其它一些原因了(网络异常问题原因很多,国内当前的网络环境下,掉线问题是不可能完全避免的)。

三.结束语

通常情况下,向TCP的Socket发送完数据后关闭Socket,大家认为这样很正常的方式肯定没有问题,对端应该正确收完数据后收到TCP的关闭消息,但实际上在某些情况下并非如此:当TCP本端的接收缓冲区中有未收的数据时关闭Socket,这会导致对端收到RST的异常关闭消息;当对端在本端已经关闭Socket的情况下再次发送消息时,也会导致对端收到异常关闭消息;还有为了避免TIME_WAIT而设置了SO_LINGER选项的话,也会导致连接提前夭折使对端收到RST异常关闭消息。

有些时候业务流程对是否引起掉线也很重要(特别是连接关闭流程),比如前面的B项目的跨服跳转掉线问题很大部分就是因为GameSvr请求关闭连接导致的。建议各个游戏项目的关闭流程(包括跨服跳转的原连接的关闭)最好都由客户端发起关闭,这样就一定程度上避免上述问题的发生(因为客服端发起关闭的时候,一般业务流程都走完了,服务器端也不会再向客户端发送消息了)。

程序收到网络异常的情况很多(最多的就是Linux下的104错误和Windos下的10054/10053错误):有网络本身的问题、也有应用使用不当的问题;有运营商之间的跨网络问题、网络中间路由器问题、玩家机器硬件(比如网卡及其驱动)问题和操作系统、杀毒软件、防火墙等软件问题,还有玩家的上网设备和路由器等中间设备问题等,但客户端程序崩溃问题有可能会占掉线的很高比例,这也是值得我们注意和改进的地方。还有种情况值得我们注意,有些TP-LINK的路由器,当UDP包大小超过其MTU值时会导致用户机器的网络断开,从而引起掉线(这个问题在某些项目的个别玩家中已经出现过)。

网络异常关闭引起掉线是当前游戏中普遍存在的问题,区别只在于掉线的比例多少,特别是国内各运营商之间跨网络访问更是不太顺畅,要将其完全消除是不可能的,但我们的目标是将其控制在较小的可接受范围内。

本文转载自:

共有 人打赏支持
偶素浅小浅
粉丝 6
博文 202
码字总数 0
作品 0
信阳
私信 提问
activimq异常崩掉

移动端一个app应用和activimq通过mqtt协议进行了正常连接,然后app端强行异常退出,连接没有正常关闭,这时候activimq服务端会关闭连接,但是也会抛出一个异常: Transport Connection to: t...

小智小智
2017/06/24
49
2
C3p0使用时出现的异常及解决方案

当并发量大的时候,C3P0连接池会出现如下异常信息: 对于这部分的异常分析如下: 网上很多说是C3P0的bug问题。c3p0在同时关闭statement和connection的时候,或者关闭他们之间的时间很短的时候...

长平狐
2012/09/03
3.4K
0
Tomcat 源码分析(-)启动过程分析

前面几篇文章分别介绍了Tomcat的安装、优化和框架,本文主要用于分析Tomcat源码启动过程,研究一个框架最好的着手方式可能就是研究它的启动过程,因为在这过程中我们可以看到它内部的层次关系...

AaronSheng
2016/11/28
29
0
tomcat JDBC连接池c3p0连接资源耗尽导致tomcat实例对应的app移动端无法访问。

tomcat app手机端程序无法打开了。 直接查看tomcat日志: [test@web01 logs]$ tail catalina.out at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at......

sandshell
2018/05/04
0
0
学习东西总结:

一.JAVA 基础 1、JAVA并发编程 2.JAVA NIO系列 3.JVM深入了解 4.JAVA性能优化相关研究 5.JAVA7,8新特性 二、数据库 1.数据库优化研究 2.MYSQL高可用性研究 3.MYSQL源码研究 三、网络 1.HTTP...

QH_C
2016/03/25
5
0

没有更多内容

加载失败,请刷新页面

加载更多

第11章 多线程

程序、进程、线程 程序(program)是为完成特定任务、用某种语言编写的一组指令的集合。即指一段静态的代码,静态对象。 **进程(process)**是程序的一次执行过程或是正在运行的一个程序。动...

流小文
20分钟前
2
0
SpringBoot引入第三方jar包或本地jar包的处理方式

在开发过程中有时会用到maven仓库里没有的jar包或者本地的jar包,这时没办法通过pom直接引入,那么该怎么解决呢 一般有两种方法 - 第一种是将本地jar包安装在本地maven库 - 第二种是将本地j...

独钓渔
今天
2
0
五、MyBatis缓存

一、MyBatis缓存介绍 缓存的使用可以明显的加快访问数据速度,提升程序处理性能,生活和工作中,使用缓存的地方很多。在开发过程中,从前端-->后端-->数据库等都涉及到缓存。MyBatis作为数据...

yangjianzhou
今天
2
0
最近研究如何加速UI界面开发,有点感觉了

最近在开发JFinal学院的JBolt开发平台,后端没啥说的,做各种极简使用的封装,开发者上手直接使用。 JBolt开发平台包含常用的用户、角色、权限、字典、全局配置、缓存、增删改查完整模块、电...

山东-小木
今天
3
0
《月亮与六便士》的读后感作文3000字

《月亮与六便士》的读后感作文3000字: 看完英国作家威廉.萨默塞特.毛姆所著《月亮与六便士》(李继宏译),第一疑问就是全书即没提到“月亮”,也没提到“六便士”。那这书名又与内容有什么...

原创小博客
昨天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部