别具匠心的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 应用行为
应用响应时间（ART）
作者：易隐者 发布于：2012-9-13 18:38 Thursday 分类：网络分析
在实际的业务应用操作中，客户端向服务器的操作主要分为两类，一类为客户端向服务器上传数据，如HTTP应用中的“post”操作，另一类为客户端从服务器取数据，如HTTP应用中的“get”操作。应用程序对这两个操作的处理机制不同，因此有必要把应用响应时间按照客户端的这两类操作进行划分，下面分别针对服务器端的这两种响应时间进行阐述。
“get ”操作应用响应时间
“Get”操作主要是指客户端向服务器端发送取数据的请求。应用程序对“Get”操作的响应时间主要是指服务器收到get请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。其响应时间的计算如下图所示：
Get操作应用响应时间计算示意图（一）
应用程序在处理客户端请求的时候会消耗一定的时间，并不一定能够及时响应请求的数据，为了不让客户端等待过长的时间（时间过长，很可能导致客户端重传数据），服务器很可能首先对客户端的TCP数据段进行响应（Delay ACK）。在上面的图示中，第二个包是TCP层的响应，其应用层的数据的长度len=0，第三个包包含有应用层数据，其数据长度len=n，因此，该应用响应时间就是T3-T1。而下图中，应用程序很快的响应了客户端的请求，第二个包中就已经包含有应用层数据，其长度为len=n，其应用响应时间的计算就是从第二个数据包开始，为T2-T1。
Get操作应用响应时间计算示意图（二）
我们再看一下实际应用中的get操作应用响应时间的计算。下图为web应用中某“get”操作的数据交互过程：
web应用中GET 操作的交互过程
在上图中，我们可以看到，当客户端向服务器发送取数据的get请求后，服务器的传输层首先针对客户端的TCP数据段进行了响应，其应用层数据长度为0，接下来第三个数据报是服务器应用程序对客户端get请求的响应，其包含应用数据。在这个过程中，“get”操作应用响应时间就是第三个数据包与第一个数据包的时间间隔，在该例子中为0.08149秒。
“Post”操作应用响应时间
“post”操作主要是指客户端向服务器上传数据的操作。“Post”操作应用响应时间主要指服务器端接收到客户的post操作数据包与服务端处理完这些数据后对客户端做出相应响应的时间。关于这种应用响应时间计算的方法请参见本博客《关于client push操作应用响应时间的计算方式的讨论》一文。这篇文章较为详细的描述了客户端向服务器递交数据时的服务器应用响应时间测量的方法。
在实际的应用中，存在两种常见的应用场景，一种是服务器端在收到客户端的数据，应用进程处理完毕后，需要向客户端发送响应数据；另外一种情况是服务器端接收并处理来自客户端的数据，但是应用进程并不会发送响应数据给客户端。下面我们分别针对这两种类型的应用进行描述。
1，有应用层响应数据的
当客户端向服务器发送“post”操作数据后，应用层如果有应用数据的响应，那么计算应用响应时间的方法与计算“get”操作应用响应时间的方法一致。就是指服务器收到post请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。下图展现的就是一个针对客户端的 “post”操作，应用进程产生应用层响应数据的交互过程：
有应用层响应数据的“post”操作交互过程
在这个“post”操作数据交互过程中，我们可以分析出应用响应时间为12.847148秒。
2，无应用层响应数据
在客户端向服务器发送数据时，如果服务器端应用进程没有应用数据响应，那么服务端仅仅只在TCP层面响应客户端数据的ACK，如下图所示的应用层数据交互的过程：
无应用响应数据的“post”操作数据交互
既然无应用数据响应，那么就说明站在网络数据交互的角度，无法测量应用程序的响应时间，即使测量了，也无法真正反映应用程序的响应时间，在实际应用中，我们就没有测量的必要了。
标签: 响应时间 应用响应时间 ART get client push delay ack POST
经受时延的确认（Delay ACK）
作者：易隐者 发布于：2012-9-12 21:05 Wednesday 分类：网络分析
通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带ACK），这样做的目的是尽量减少发往网络的报文，以提高传输的效率，节省网络资源。
下图清晰的展示了Delay ACK的工作过程：
我们一起来看一个实际环境中的Delay ACK实例：
在实际工作环境下，我们做应用性能分析时，有时会遇到应用程序处理时间较长（一般超过200ms）时，我们经常会看到服务器先向对端发送了TCP ACK报文（无应用层数据），这个确认的报文一般就是TCP的Delay ACK，如下图所示：
我们在遇到此类现象时，千万不能简单的将此处的Delay ACK当成应用响应时间。
Delay ACK的可能影响
另外需要注意的是，Delay ACK虽然能够提高传输效率，节约网络资源，但是在某些情况下，其会给应用带来难以想象的延时问题（假想一下这样的场景：服务器单向向客户端间歇发送一些数据，但是客户端无应用数据需要提交给对方，此时，如果客户端每收到对端包含有应用字段的报文时，都等待200ms才对其进行确认，那么如果服务器与客户端的交互次数为1000的话，那么整个应用交易或应用会话将要持续1000*200=200S，而200秒对于绝大多数的应用来说是不可接受的）。
Delay ACK补充
1，绝大多数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送，但是这个200ms的值并不是必须的，开发者可以根据自己的需要来设定这个数值，因此，我们在实际工作过程如果发现非200ms但是工作机制与Delay ACK一致的TCP交互过程，那基本上就是Delay ACK机制了。
2，如果连续收到对端两个数据段，则一般立即回应ACK数据包，如下图所示：
-
QQ邮箱订阅
-
搜索
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情，那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道，真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望，它终归还是把我们引到我们看不见的目的地。（茨威格《昨日世界》）
2019-03-16 21:27
- 如果你渴望得到某样东西，你得让它自由，如果它回到你身边，它就是属于你的，如果它不会回来，你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧：一个是没有得到你心爱的东西；另一个是得到了你心爱的东西。人生有两大快乐：一个是没有得到你心爱的东西，于是可以寻求和创造；另一个是得到了你心爱的东西，于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想，发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)
标签
blogger
