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

HTTP chunked编码异常导致业务下载附件慢故障案例

作者:易隐者 发布于:2012-12-18 9:32 Tuesday 分类:案例讨论

故障现象

       某业务应用系统基于B/S架构开发,其应用页面打开正常,但是该应用在下载附件时,速度非常慢。

故障分析

       在下载附件很慢时,在服务器上捕获客户端与服务器业务交互的报文。其TCP会话交互的情况如下图所示: 

点击查看原图

       我们首先分析客户端与服务器三次握手建立连接的情况,查看客户端、服务器协商的MSS值是否正常,我们首先查看客户端SYN报文,其TCP MSS协商为1460,如下图所示: 

点击查看原图

       接下来查看服务器SYN/ACK报文,其TCP MSS也为1460,如下图所示: 

点击查看原图

       这说明双方协商的MSS值不存在问题,另服务器对客户端的get请求的第一个应用响应报文长度为248B,如下图所示: 

点击查看原图

       这也充分说明业务服务器在给客户端发送报文时并不是一直只能发送9字节的报文。那么是什么原因导致业务服务器突然之间只能每次发送9字节的应用层数据呢?

       我们注意到服务器给客户端的第一个HTTP应用响应报文,如下图所示: 

点击查看原图

        其Transfer-Enconding是chunked

        HTTP为什么会使用chunked传输编码?我直接引用《HTTP1.1中CHUNKED编码解析》一文中的描述来说明:一般HTTP通信时,会使用Content-Length头信息性来通知用户代理(通常意义上是浏览器)服务器发送的文档内容长度,该头信息定义于HTTP1.0协议RFC  1945  10.4章节中。浏览器接收到此头信息后,接受完Content-Length中定义的长度字节后开始解析页面,但如果服务端有部分数据延迟发送吗,则会出现浏览器白屏,造成比较糟糕的用户体验。
        解决方案是在HTTP1.1协议中,RFC  2616中14.41章节中定义的Transfer-Encoding: chunked的头信息,chunked编码定义在3.6.1中,所有HTTP1.1 应用都支持此使用trunked编码动态的提供body内容的长度的方式。进行Chunked编码传输的HTTP数据要在消息头部设置:Transfer-Encoding: chunked表示Content Body将用chunked编码传输内容。根据定义,浏览器不需要等到内容字节全部下载完成,只要接收到一个chunked块就可解析页面.并且可以下载html中定义的页面内容,包括js,css,image等。”

        “Chunked编码一般使用若干个chunk串连而成,最后由一个标明长度为0的chunk标示结束。每个chunk分为头部和正文两部分,头部内容指定下一段正文的字符总数(非零开头的十六进制的数字)和数量单位(一般不写,表示字节).正文部分就是指定长度的实际内容,两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的chunk中的内容是称为footer的内容,是一些附加的Header信息(通常可以直接忽略)。”

       《HTTP1.1中CHUNKED编码解析》一文中使用了下图作为chunked解码的示意: 

点击查看原图

       通过这张示意图,我们可以清晰的了解到,chunked解码主要由2块组成,一块为指定数据块长度,以\r\n回车换行作为结束符,另一块为实际的应用数据,也以\r\n回车换行作为结束符。
       知道了chunked解码的组成,我们再来看看业务服务器给客户端发送的应用层长度仅9字节的报文解码: 

点击查看原图

       根据这9个字节的应用字段解码,我们将其十六进制换算为正常的十进制,如下表所示:

点击查看原图

        我们根据上图即可解码服务器发往客户端的chunked编码报文,其意义为:
1,指明长度为0001,即为1字节;
2,该报文真正的应用数据仅为1字节的“R”!

       服务器每次仅传输一个字节给客户端!其报文的有效载荷率仅为:   1/63=0.015873015873015873015873015873016!
       如果客户端下载一个1MB大小的附件,服务器端将产生1*1024*1024=1048576个报文,如果客户端每个报文都确认的话,一个下载将产生1048576次交互,即使往返时间RTT值非常小,再乘以1048576的基数之后,也将是个难以接收的数值。
       如此,我们终于明白下载附件慢的原因了。

分析结论

       此为业务服务器HTTP chunked编码传输时,自己指定的数据块长度值太小(为1字节)导致的故障。

参考文档

1,《HTTP1.1中CHUNKED编码解析》
2,RFC 2616《超文本传输协议》

阅读全文>>

标签: 疑难故障 MSS RTT 往返时间 HTTP chunked编码 交互次数

评论(3) 引用(0) 浏览(11483)

糟糕的业务网络行为

作者:易隐者 发布于:2012-12-11 15:40 Tuesday 分类:网络分析

       我之前在讲解业务应用分析评估时,重点分析业务应用的网络行为特征、业务基线、响应时间等内容。很多人认为:我的业务应用操作我们自己都是非常熟悉的,为什么还要这么复杂的来分析业务应用的网络行为呢?这是因为业务应用系统在开发的时候,由于各种原因,可能导致业务应用本身在交互的过程中,存在一些不合理的网络行为,进而影响业务运行的效率,造成网络资源的消耗和浪费。我们对业务应用系统进行网络交互行为的分析和评估,可以发现这些不合理的网络行为,帮助改进完善业务应用系统,提高业务应用交互的效率。

       近日正好在Laura Chappell的网站上下载了一个应用异常网络行为的数据包文件,这是一个FTP登录交互的报文,其交互过程如下: 

点击查看原图

       客户端与服务器三次握手建立TCP连接之后,服务器端应用响应:220 FTP Service ,此时客户端发出应用请求“USER  FRED”,但我们可以清晰的看到其请求过程是:先将第一个字符发送过去,在收到服务器的确认之后,客户端再传输第二个字符,如此一个字符一个字符的传输。

       在后续的客户端密码传输过程中,客户端的网络行为跟传输用户名的网络行为一样。如下图所示: 

点击查看原图

       服务器与客户端之间几十毫秒的RTT往返时间,加上客户端本身动辄数百毫秒甚至几秒的延时,造成整个FTP登录过程持续近14秒,如下图所示:

点击查看原图

        我们再来一起看一个正常的FTP登录过程: 

点击查看原图

       从这个FTP登录的过程我们可以清晰的看到,FTP客户端是将用户名、密码放在一个报文中一次性传送给服务器的。

       一个最为常见的FTP应用,一个最为普通的登录操作,正常情况下,数秒内完成,但是由于这个FTP应用不合理的网络行为,共消耗了近14秒的时间。

       什么是糟糕的应用网络行为?这个就是!为什么需要分析评估业务应用的网络行为特征,这个就是明证!

阅读全文>>

标签: FTP 行为特征 网络行为 应用分析 RTT 业务评估 往返时间

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

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