欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

TCP确认机制异常案例

作者:易隐者 发布于:2012-12-8 15:06 Saturday 分类:案例讨论

缘起
        一个好友通过Sina微博转发了一个兄弟的问题给我,其问题如下:
“AB机器tcp,A发送100字节给B,B返回数据但是其ACK=1,这期间A均正确ACK B的所有序列号,B置FIN位,A发 FIN+ACK 给B,此后B返回的ACK=2,那么此时A是应该重传之前的99字节,还是直接重传之前的FIN+ACK包给B?”。

       通过这样的描述我认为这在实际环境中应该不会存在,结果这个兄弟告诉我是在实际环境中发生的,并将交互的报文传一份给我。

       好奇之余,对这个报文进行了仔细的分析,接下来跟我一起来看一下整个分析的过程。

分析产生这个交互的原因

       选取其中一个TCP会话,查看其具体的报文交互情况,如下图所示: 

点击查看原图

       这个报文交互的情况截图结合下面的TCP交互流图一起,看起来更清晰一些:

点击查看原图

        通过交互报文的解码,我们可以清晰的看到,服务器192.168.104.229已经对客户端发送的get请求作出了应用层的响应,如下图所示:

点击查看原图

       其响应为:HTTP/1.0 403 Forbdden
       但是其ACK号却为1,接收并处理了客户端的应用请求报文,但却并未对其进行确认,这充分证明服务器192.168.114.229的TCP确认机制出现了异常!

       我们再来一起看看客户端主动发送FIN报文之后的交互情况:
 点击查看原图
       客户端在发送FIN报文之后,服务器的ACK号变为2,这对于客户端来说,这是对其应用字段的确认,这说明服务器端仅收到客户端1字节的应用字段,因此客户端将剩下的303字节的应用字段放在FIN报文中一起发给服务器端,而服务器在收到这个报文后,回应客户端的ACK号变为3,客户端接着将剩下的302字节的应用字段放在FIN报文中再次重传给服务器端,如此反复。
       至此,我们已经能够意识到,服务器端的ACK确认并不是针对客户端的应用字段的,而是针对客户端的FIN报文的,服务器的确认机制出现了异常,服务器不再确认客户端的应用字段,而只确认客户端的SYN报文和FIN报文。

分析结论

       此问题产生的原因为:服务器的TCP确认机制出现异常,其只确认SYN报文和FIN报文而不对应用数据进行确认。

       另外,我们还留意到一个有意思的现象正常情况下,端系统一般都会在发送的数据段获得对端确认之后,才会主动发送FIN报文,释放TCP连接,如果在多次重传之后仍未得到对端的确认,通常会向对端发送RST报文,异常释放TCP连接,但是此处可能为了提高交互的效率,客户端与服务器在发送的数据段未收到对端的确认报文就主动发送FIN报文释放TCP连接。

阅读全文>>

标签: TCP SYN FIN ACK TCP确认机制

评论(0) 引用(0) 浏览(6703)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1