服务 TCP 断线错误分析
分析背景
在数据驱动架构升级这一主题下, 更好地统计异常断线率
统计结果
准备
服务是学生老师一对一连线, 多数情况下为学生的网络条件较差, 因此此处假定老师的网络为正常.
老师设备为 IPAD, 系统为 IOS 9.3.5, 网络 wifi: iyunxiao
学生 Android 设备为 一加6, 系统为 Android 9, IOS 设备为 IPAD mini, 系统为 IOS 11.3.1, Windows 系统为 Windows 10, 网络 wifi: AI-Yunxiao
IOS 程序模拟的异常为下标越界, 导致程序退出. (这是大多数的出现的异常情况)
Android 程序模拟的异常为程序跳入主界面, 报错显示程序报错. (Android 各设备显示均不相同, 无法很好的预测异常出现时的到底发生什么情况)
Windows 程序模拟的异常, 是程序卡住. 也不报错什么也不显示, 只是无法点击关闭按钮关闭页面.
过程(老师端程序均正常运行)
- 学生端程序在正常运行的情况下, 断开WiFi, 不杀掉客户端程序
- 学生端程序在正常运行的情况下, 杀掉客户端程序, 不断开 WiFi
- 学生端程序在正常运行的情况下, 先杀掉客户端程序, 再断开 WiFi
- 学生端程序在正常运行的情况下, 先断开 WiFi, 再杀掉客户端程序
- 学生端程序在进入课堂后, 30s后客户端突然奔溃
测试结果
- 过程1
IOS端: 服务端异常, i/o timeout, session: 7211938
Android: 服务端异常, i/o timeout, session: 7211968
Windows: 服务端异常, i/o timeout, session: 7211986 - 过程2
IOS端:
在老师设备上显示完指令的时候, 杀掉客户端, 服务端异常, EOF, session: 7211947 7211948
在老师设备上还有未显示完指令的时候, 杀掉客户端, 服务端异常, connection reset by peer, session: 7211946 7211949
Android端:
无论有无显示完的指令, 都是服务端异常服务端异常, EOF, session: 7211972
Windows 端:
服务端异常, connection reset by peer, session: 7211990 - 过程3
IOS端: 无论有无显示完的指令都是服务端异常, i/o timeout, session: 7211943
Android端:
在老师设备上显示完指令的时候, 杀掉客户端, 服务端异常, EOF, session: 7211975
在老师设备上还有未显示完指令的时候, 杀掉客户端, 有时候, 服务端异常, EOF, session: 7211974, 有时候, 服务端异常, connection reset by peer, session: 7211976 7211977
Windows 端:
服务端异常, connection reset by peer, session: 7211991 - 过程4
IOS端: 服务端异常, i/o timeout, session: 7211945
Android: 无论有无显示完的指令, 都是服务端异常, i/o timeout, session: 7211980 7211981
Windows 端: 服务端异常, i/o timeout, session: 7211992 - 过程5
IOS端: 无论有无显示完的指令, 都是服务端异常, connection reset by peer, session: 7211954
Android端：无论有无显示完的指令, 都是服务端异常服务端异常, EOF, session: 7211982 7211983
测试结论
只要三端先断开 WiFi, 无论杀掉客户端与否, 服务端都会出现 i/o timeout 的 TCP 错误.
Windows 在其他的异常情况下, 收到的都是Connection reset by peer的异常, 与参考文档中的结果一致, 参考文档中的客户端也是使用 Windows 平台.
IOS 在客户端被杀掉的情况下, 如果 WiFi 被断, 会收到 i/o timeout 的 TCP 错误, 跟过程1、过程4相似. 但是 WiFi 如果不被断, 当杀掉程序的那一刻, 如果还有 TCP 数据传输, 则是 Connection reset by peer, 否则是 EOF
Android 的情况比较复杂, 在客户端被杀掉的情况下, 如果 WiFi 被断, 其会出现 EOF 以及Connection reset by peer. 如果没被断, 则只会出现 EOF 的情况.
结果分析
从三端出现 TCP error 类型来推测异常发生的情景:
Android:
EOF 的出现表明客户端的程序奔溃, 无响应, 还有可能是程序被用户自己杀掉, 但是这种情况正常情况下, 用户不会无缘无故杀掉正在上课的程序.
i/o timeout 的出现表明客户端那块的网络出现异常, 路由器无网络, 进入长隧道等, 即用户网络消失了.
connection reset by peer 的出现也是出现在网络出现问题的时候.
IOS:
EOF: 发生在程序退出, 被用户杀掉
i/o timeout 的出现表明客户端那块的网络出现异常, 路由器无网络, 进入长隧道等, 即用户网络消失了.
connection reset by peer 出现在程序奔溃的
Windows:
i/o timeout 的情况同IOS、Android.
connection reset by peer 的情况发生在程序被杀等除网络发生的情况.
EOF 的异常未发生.
Broken pipe 在测试中未发生. 在正式环境上有出现, 但是也相对较少. 其出现常常伴随有connection reset by peer的异常
