Skip to content

又遇TCP协议栈异常问题

大家还记得我以前写的《TCP确认机制异常案例》(链接为:/?post=200)吗?今天在一个用户那边再次遇到了一个TCP协议栈异常的问题。

用户反馈的问题现象是业务交互出现异常,难以定位异常出现的原因,我在用户现场分析了异常出现时的报文交互情况,如下图所示:

点击查看原图

由F5设备主动向服务器发送SYN连接请求报文,服务器响应SYN/ACK报文,F5发送ACK报文确认后,向服务器连续发送3个大小分别为1514、1514、350大小的应用请求报文,但是1.199秒之后,F5重传了应用请求的第一个报文(该报文序列号为No7,该数据报其实是序号为No4的报文的重传),紧接着,2秒后,看到服务器的SYN/ACK的重传报文(该报文序列号为No8,该报文为No2报文的重传报文),后面数十秒的交互,基本是都是F5对应用请求报文的重传和服务器SYN/ACK报文的重传,在40秒之后,由F5主动发送RST报文释放该TCP连接。

由整个交互的过程,我们可以清晰的看到,服务器不断重传SYN/ACK报文,说明服务器没有正常处理F5的ACK报文(序列号为No3的报文),站在F5的角度,TCP连接已经建立成功,但是站在服务器的角度,却认为TCP连接未建立完成,因此服务器不断重传SYN/ACK报文,为什么服务器在明确收到了F5的三次握手的ACK报文,却没有正确处理呢?而且后续F5重传的应用请求报文(No7、No10、No11、No14、No17)都可以说是对服务器SYN/ACK报文的确认,但是服务器全部忽略了,因此,这基本上可以判断为服务器端系统的TCP协议栈出现异常,导致了应用出现了异常。

评论与留言

欢迎留言。你可以匿名留言,也可以自愿留下网名或邮箱;邮箱不会公开展示。

还没有留言,欢迎交流。

发表留言

网络分析技术档案