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

别具匠心的HTTP应用层行为设计

作者:易隐者 发布于:2012-12-26 16:09 Wednesday 分类:网络分析

       今年的年初,有位兄弟在QQ跟我讨论一个较为少见的报文交互情况,我当时在看了具体的报文交互之后,对他说是某种HTTP探测机制,他则对我说有人认为是某种SACK的重传机制,记得我曾说过我会找时间好好研究一下这个交互的行为,后来的确也写了一些分析、画了一些图示,但是在未完成的情况下被耽搁了,直至最近才把这个翻出来,闲话少说,我们还是直奔主题,一起来看一下这个有意思的应用交互行为吧。

       这个报文交互过程如下:

点击查看原图

       其交互的数据流图如下: 

点击查看原图

       我们再来看一下其中几个重要报文的详细解码,首先看服务器的HTTP 200 OK响应报文的解码,如下图所示: 

点击查看原图

服务器响应报文解码(No128报文解码)

       这个服务器的响应报文,其应用字段长度为585字节,序列号为101871,最后两字节应用字段为Hex 0d0a,我们再来看一下客户端对这个服务器响应报文的确认报文的解码,如下图所示: 

点击查看原图

       从上图解码来看,这是一个最为常见的确认报文,确认号为102456(101871+585)。我们再看看服务器的重传报文解码,如下: 

点击查看原图

服务器后续重传报文解码(No132报文解码)

       我们能够清楚的看到,这个来自服务器的重传报文其应用字段为1字节,序列号为102454,应用字段为Hex 0d,通过序列号我们可以看出这个重传报文并不是No130应用响应报文的重传,而仅仅是重传了No130报文中倒数第二个字节的应用字段!我们再看看客户端对服务器这个重传报文(No132报文)进行确认的报文解码: 

点击查看原图

客户端对服务器这个重传报文(No132报文)进行确认的报文解码

       客户端确认号为102456,但是其SACK却显示为102454-102455!确认号大于块左边界、块右边界值,这是不符合SACK的相关规范的!

       我把这个交互过程制作一个更为清晰明了的图示如下: 

点击查看原图

       现在大家应该清楚这个交互的具体情况了,那么疑问来了:

1, 服务器端为何重传倒数第二个字节的应用字段?
2, 客户端在确认服务器的重传报文时,为何使用不规范的SACK?

       带着这两个疑问,我用自己的机器访问163网站,重现了这个交互过程如下: 

点击查看原图

       这个过程跟上面的交互过程几乎是一致的,我们就不再做详细的分析了,但是我们来仔细的查看一下客户端对服务器一字节应用字段重传的确认报文的解码: 

点击查看原图

客户端对服务器重传报文进行确认的报文解码

       在这个解码中,我们看到,我的机器在对服务器的一字节重传报文进行确认时,并未使用SACK,而是正常的重传了对服务器应用响应报文的确认,这是一般情况下的正常处理。这也说明了服务器的这个“重传一字节应用字段”的行为并不会导致客户端的确认出现异常。只有系统处理差异才能够解释这种情况的发生:我使用的客户端是XP操作系统,而那位与我讨论的兄弟使用的是其他操作系统。不同的操作系统在遇到这种重传部分应用字段的报文时处理机制不一样导致了疑问2的出现,这种不合SACK规范的确认报文虽然不会对服务器造成交互的影响,但足以让我们产生困惑,因此,严格来说,那位与我讨论的兄弟所使用的端系统如此处理是异常的。

       如此我们解决了第二个疑问。

       而针对第一个疑问,问遍了google和baidu无果后,让我们一起来分析一下这种行为可能带来的好处和坏处。

       服务器在作出应用响应之后,在200ms左右未收到来自客户端的确认报文,则将倒数第二个字节的应用字段封装重传给客户端。

这样做的好处是在如下几种情况下会提高服务器与客户端的交互效率

1, 服务器发往客户端的应用响应报文在网络传输过程中被丢弃
       服务器的响应报文被丢弃,未到达客户端,在这种情况下,服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为,避免了服务器端被动等待客户端确认报文到达直至重传定时器清零,服务器才可以重传报文,服务器通过这种行为主动探测客户端对服务器报文接收的情况,提高了交互的效率。 

点击查看原图

服务器应用响应报文被丢弃时的交互过程图示

2,客户端对服务器应用响应报文的确认在网络传输过程中被丢弃
       如果客户端对服务器应用响应报文的确认报文在到达服务器之前被丢弃了,那么,会出现服务器端等待客户端确认报文到达的情况,这是一个超时重传的等待时间,一般至少在数秒之间,而服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为,可以在200ms左右主动发送“封装最后倒数第二个字节应用字段的重传报文”,这个报文到达客户端之后,客户端将重新发送确认报文,这减少了超时重传的等待时间,从而提高了交互的效率;

点击查看原图

客户端对服务器响应报文的确认被丢弃时交互过程的图示

坏处就是:与一般正常交互过程相比,可能会给网络多带来两个64字节的小包

       如果客户端正常收到了服务器的应用响应报文,只是客户端的ACK报文较慢(网络传输延时或者客户端的delay ack机制等)到达服务器,则服务器会发送这种带有一个应用字段的重传报文,而客户端在收到这个报文后,会对这个报文进行确认。

       而这个坏处相对于其带来的好处而言,实在不值一提,因此不得不说,这个HTTP应用行为的设计是别具匠心的!

       那么为什么是倒数第二个字节而不是倒数第一个字节、倒数第三个字节或者其他字节?理论上来说重传任何一个字节达到的效果都是一样的,只重传部分应用字段(一个字节)是为了节约网络带宽资源,或许程序设计者如此设计有一些特别的用处,但是这只能去问程序设计者本人了。

      另:我已将相关报文文件作为附件上传至此,有兴趣的兄弟姐妹可下载学习探讨,下载后解压即可使用wireshark直接打开查看。

阅读全文>>

附件下载:
别具匠心的HTTP应用行为设计-兄弟提供的原报文.zip 203.32KB
别具匠心的HTTP应用行为设计-我重现的报文1.zip 2.1KB
别具匠心的HTTP应用行为设计-我重现的报文2.zip 4.21KB

标签: sack 解码 重传 get delay ack HTTP 应用行为

评论(1) 引用(0) 浏览(78267)

TCP SACK选项

作者:易隐者 发布于:2012-8-1 22:37 Wednesday 分类:网络分析

一般TCP的ACK过程

       在TCP的交互过程中,除了第一个SYN请求报文的ACK标志未置1外,其他的报文的ACK标志都是置1的。当客户端与服务器在交互的过程中,某些数据报被丢弃时,其ACK确认和后续数据交互的过程如下图所示:

点击查看原图 
图 1  一般丢包情况下的ACK确认和后续数据交互的过程示意图

       在上图所示的交互过程中,我们可以清楚的发现,在交互中由于某些未知的不可控的原因导致包含data-2的数据报文丢失。虽然仅有包含data-2的报文丢失,客户端已经收到其他的data,但是,服务器却要将data-2以及data-2之后的其他Data重传一次,这就造成了交互效率的低下。正是为了解决这个问题,诞生了SACK。

SACK介绍

       SACK(Selective Acknowledgment,选择性确认)技术,使TCP只重新发送交互过程中丢失的包,不用发送后续所有的包,而且提供相应机制使接收方能告诉发送方哪些数据丢失,哪些数据重发了,哪些数据已经提前收到了。如此大大提高了客户端与服务器端数据交互的效率,其确认和数据交互的过程如下图所示:

点击查看原图
图 2  SACK确认和丢包后续数据交互示意图

阅读全文>>

标签: TCP重传 sack TCP丢包 TCP选项

评论(2) 引用(0) 浏览(16932)

视频点播服务间歇性中断故障分析案例

作者:易隐者 发布于:2012-8-1 22:15 Wednesday 分类:网络分析

故障环境

1 网络拓扑

点击查看原图

2 说明

1、VOD在线视频是通过web页面观看的,通讯流全部使用HTTP的80端口传输数据;
2、客户端与服务器是纯路由环境下完成数据交互的。

故障现象

1、客户端通过浏览器在线观看VOD视频时,不定时(有时几分钟、有时十几分钟,没有规律)的出现中断情况;
2、使用ping命令长时间测试VOD服务器的连通性,一直正常;
3、异常时,VOD服务器的web页面访问正常。

阅读全文>>

标签: IP标识 sack tcpdump 重传 IPS 策略误报 视频点播故障 IPID

评论(1) 引用(0) 浏览(6565)

疑难杂症分析案例-启明星辰竟然用的是我08年制作的PPT

作者:易隐者 发布于:2012-7-3 18:04 Tuesday 分类:案例讨论

      下班后,在网上查找启明防火墙的命令行手册,没想到竟然在百度文档里发现了下面这个系列的培训PPT,这个是我08年写的疑难杂症分析案例培训PPT,哈哈,启明基本上没做改动。如有人对原PPT有兴趣,可给我留言。

阅读全文>>

标签: 疑难杂症 丢包 icmp差错 分片 sack 可选择性确认 tcpdump

评论(7) 引用(0) 浏览(4033)

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