性能文章>wireshark分析tcp传输之文件上传速率问题>

wireshark分析tcp传输之文件上传速率问题原创

294758

网络性能问题排查思路那一节里,我提到了查看系统网络瓶颈的方法以及排查丢包问题的手段。
但就此分析网络问题还不够精细,有时网络资源并没有达到瓶颈,或者并没有丢包产生,但是网络传输速率就是很慢,或者有丢包产生,但无法知道丢包的详细过程,无法知道整个tcp传输过程的具体情况。

如何更加精细的查看网络包传输过程,答案就是抓包。

这一节我将用上传文件的抓包文件举例,用wireshark来分析tcp的传输过程以及文件传输速率慢的问题。

概念模型

传输过程简单的可概括为,三次握手,慢启动,拥塞避免,快速恢复,四次挥手。三次握手,四次挥手的过程一般我们都比较熟,这里我不会特别来讲,着重来看下其他几个阶段。

其他几个阶段涉及到tcp里的窗口概念,我们首先来分下。

滑动窗口

tcp的发送和接收数据是一个滑动窗口的模型,在tcp协议里,发送数据的滑动窗口叫发送窗口,接收数据的滑动窗口叫接收窗口。

发送窗口大小受制于对端接收窗口的大小和拥塞窗口的大小。

发送窗口大小 = min(对端的接收窗口,拥塞窗口)

拥塞窗口

tcp发送窗口受对端接收窗口的大小能动态调整,这种情况在局域网里面是可行的,但是在广域网里,数据传输过程中很有可能经过很多路由器或者交换机,如果中途设备网络处理能力变差,即使对端接收窗口能力大依然会造成严重的丢包,此时发送端即不应该继续发送数据包。

所以,拥塞窗口产生了,它有着能够动态感知网络拥塞情况来调整发送窗口的功能。

如何衡量拥塞情况

当发送重传的时候即认为此时网络产生了拥塞的情况。重传又分为快速重传和超时重传,拥塞窗口的大小会根据这两种重传方式做出不同的策略

超时重传
数据包在发送数据到对端时,会收到一个ack标志的数据包回来,当在一定时间内,发送端没有收到对端的ack包,那么发送端就会认为数据包丢掉了,会重新传递相同数据包到对端。这样的重传叫做超时重传。

快速重传
每次都等到超时再重传,会增大端与端的时延, 所以快速重传认为如果收到对端三次重复的ack,那么即认为包丢失了,然后将丢失的包马上传递到对端,不用等超时定时器触发。

对端重复ack是如何产生的?

tcp发包是一组一组的发往对端,如果一组当中某个包丢失了,对端接收到的是丢失后的包,那么回应的ack将会是丢包前最大的ack序号。

图片

慢启动阶段

连接建立后,每次收到一个ack,那么拥塞窗口能发送的最大MSS(一个tcp包最大发送的字节数)就会翻倍。当最大发送数据到达ssthresh,就会进入拥塞避免阶段。

拥塞避免

每过一个RTT(往返延时) ,拥塞窗口就会新增一个MSS大小。当碰到拥塞时,传输又会进入慢启动或者快速恢复阶段。那么如何衡量拥塞,当发生重传时即认为发送了拥塞。

快速恢复

快速恢复是为了避免每次碰到拥塞时,就进入慢启动阶段,让传输效率极剧降低这种情况出现。所以快速恢复采用遇到快速重传时,让拥塞窗口减半,然后MSS增长方式采用和拥塞避免阶段一样的低斜率线性增长的方式。然后当遇到超时重传时,整个传输过程依然会进入慢启动阶段。

图片

tcp stream graphs 分析tcp传输过程

慢启动阶段

慢启动阶段的特点,单位时间内,发包的数量在呈现指数级的增长。wireshark 可以通过tcp 时序图 Stevens来看到这种增长的变化。x轴是时间,y轴是包的序列号。

图片

为什么慢启动之后会有比之前seq num 还低的点出现图片

因为发生了重传,发送的是之前发过的数据包。可以看到这第一波慢启动之后,又出现了好几次斜率比较陡的曲线,说明整个传输过程又经历了几次慢启动的过程,经过抓包,在5s到7.5s的这段期间,发生了大量的超时重传。

图片

拥塞对传输速率的影响

io graph 查看整个过程的传输速率。

以100ms的间隔去看整个过程传输速率变化,可以看到在拥塞发生之前,传输速率呈指数级别的上涨,在好几次超时重传后,传输速率直至降低到0以后又开始了指数级别的上涨,虽然斜率没有第一次那么急速,但依然是指数级别,所以可以认为实际上是在经历慢启动阶段。

在第二个波峰之后,又经过了一次传输速率的下降,没有第一次下降那么陡峭,然后速率呈现固定斜率的上涨趋势,这和快速恢复阶段的特定极其相似,可能整个tcp传输就是在进行快速恢复阶段。

图片

传输速率除了拥塞带来的影响,还有接收窗口大小也会影响,接收窗口太小,传输速率也会提升不上去。

那么如何肯定这里传输速率的下降不是接收窗口的影响呢?

第一,tcp 时序图 Stevens找到对应速率下降的时间点附近在发生大量的超时重传,说明有大量丢包,进而说明网络状况不好。

第二,可以通过wireshark window scaling 去看接收窗口随时间的变化情况。

图片

绿色代表接收窗口的大小,蓝色的点叫 bytes out 也就是在途数据(指已经发送但是还未被确认的数据。在途数据越多,说明发送端发送的数据就越多,整个过程,接收窗口在达到4M的时候就基本不变了。

发送端发送数据只是在差不多5s的时候达到了接收窗口的瓶颈,但由于网络拥塞,发送端发现之前发的包丢了,所以没有继续发送新的数据。而旧的数据包在慢慢ack过程中,所以bytes out变小了。

并且后续,发送的数据量大小都远远小于接收窗口的大小。如果接收窗口是瓶颈,在5s后,整个图应该是 bytes out和接收窗口处于一条基本重合的水平直线上,这里显然不是这样

深入思考 如果接收窗口如果是瓶颈,该如何办?

接收窗口大小受什么影响?

TCP接收窗口的大小在Linux系统中取决于TCP receive buffer的大小,而TCP receive buffer的大小默认由内核根据系统可用内存的情况和内核参数net.ipv4.tcp_rmem动态调节。

同时,不是TCP receive buffer的大小就等于TCP接收窗口的大小。有bytes/2^tcp_adv_win_scale的大小分配给应用。如果net.ipv4.tcp_adv_win_scale的大小为2,表示有1/4的TCP buffer给应用,TCP把其余的3/4给TCP接窗口。

在tcp报文里,留给窗口的表达式只有16位,这样导致,tcp的窗口最大只能表示64kb,所以在tcp窗口大于64kb时 需要利用TCP Options的Window scale字段。在系统内核参数设置里,对应的就是net.ipv4.tcp_window_scaling参数,这个参数会将window字段乘以2的scale次方作为实际窗口大小。

这个字段在握手的时候会告诉对方。

图片

所以如果接收窗口是瓶颈,那么可以调大接收方的receive buffer 以及tcp_window_scaling参数。

总结

这一节 主要用了 tcp stream graphs 宏观的去分析了文件上传时tcp的传输过程,wireshark提供的高级功能,这一节只是冰山一角,希望能抛砖引玉。

我认为,网络抓包无处不在,其实随手就可以抓取上网浏览的包去进行分析,然后通过wireshark把包传输过程的表现都用理论知识找到对应的解释,不断深挖下去,便会融会贯通。

点赞收藏
蓝胖子的编程梦
请先登录,查看5条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
8
5