上一期《网络诊断指南：发生丢包与乱序问题，如何定位？》中我们说了围绕丢包和乱序，本文将继续围绕时序图的RTO与重传，和大家探讨TCP相关内容。
什么是RTO？
RTO（Retransmission TimeOut）是指在TCP协议中，当发送方发送数据后，如果在一定的时间内没有收到接收方的确认（ACK）包，就会超时并触发重传的时间，这个预定的时间就是RTO。
在Linux系统中，RTO的时间分别由/proc/sys/net/ipv4/的tcp_rto_min、tcp_rto_max、tcp_rtoInitial这三个文件控制，三个文件分别描述了RTO的最小值、最大值和默认值。看到这里，聪明的读者应该能猜到，RTO是一个动态更新的数值，并不是固定不变的。
RTO的数值对网络性能会有很大影响：如果RTO太短，可能会导致额外不必要的重传；如果太长，则可能不能及时发现丢包。因此，RTO的数值是基于网络的往返时间（RTT）动态调整的，动态调整的RTT可以适应网络状况的变化。
发送方TCP为每一条TCP连接设置一个RTO计时器。如果RTO时间到了，发送方还没收到确认包，就会认为数据包丢失或出现问题，触发TCP的超时重传机制。发送方将重新发送未被确认的数据包，然后更新RTO的时长并重新启动RTO计时器。重传包在CSNA系统中，被标记为红色，表示异常重传。关于重传包的判定和标记方法，在《高效排障：不同情况下的重传根因及处置建议》文章中已经有详细描述，本文不再赘述异常流量判定和标记的相关内容。
RTO计时器如何实现动态更新？
关于RTO的动态更新，其计算方法相对复杂，根据RFC 6298文档的描述，关于RTO参考RTT计算的动态更新，主要是依靠下面两个公式：
图1 RFC 6298中的RTO计算方式
为了避免长篇大论的描述计算公式，关于本公式的内容这里就不展开细聊了。简而言之，该算法是一种自适应机制，它通过动态计算平滑往返时间（SRTT）和往返时间变化（RTTVAR），并结合这些值来确定一个针对当前RTT相对合适的RTO。
需要注意的是，RTO无论计算为何值，其下限值为1秒。当计算得出的RTO为0.8秒时，RTO将会取下限值1秒。在旧版本RFC 1122和RFC 1988中，这个下限值被定义为3秒。因此，我们在一些主机中能够观察到RTO为3秒，有些主机RTO为1秒，如下图所示：
图2发送方RTO时长为3秒
图3 发送方RTO时长为1秒
根据图2可以看出，第一个SYN包与重传的第二个SYN包时间差为3秒，说明RTO为3秒，该截图来自旧版的CSNA系统，这也侧面证实在一些较早的系统TCP实现中，RTO下限确实是3秒。根据图3进行观察，第一个SYN包与第二个SYN包时间差为1秒，说明RTO为1秒，该截图来自一个较新版本的CSNA系统，分析了Windows 10客户端的SYN包超时重传流量。
如果RTO过短，则会引发一些不必要的重传，同样的道理，如果RTO过长，则会失去一些合适的超时重传机会，因此RTO同样存在上限值，一般的RTO上限值为60秒。超过60秒的重传在流量分析过程中很难看到，因为在实际环境中，如果某条会话超过60秒没有交互，那么估计这条会话早已该被其它设备或机制判断故障并中断了。
总而言之，RTO是一个动态更新的数值，最短时长为1秒，最长时长为60秒。
时序图如何体现RTO？
时序图中是如何体现RTO和重传的？先看一张图：
图4 RTO超时
如图4所示，客户端发送SYN包请求连接服务器的21端口，但笔者设置了服务器防火墙丢弃21端口流量，因此SYN包无法到达服务器。该数据包是从客户端抓取，因此可以看到客户端RTO重传SYN包的过程：
- 1号SYN包为初次连接，相对时间为会话的第0秒；
- 2号SYN包为第一次RTO超时重传，相对时间为会话的第1秒；
- 3号SYN包为第二次RTO超时重传，相对时间为会话的第3秒；
- 4号SYN包为第三次RTO超时重传，相对时间为会话的第7秒；
- 5号SYN包为第四次RTO超时重传，相对时间为会话的第15秒。
上述案例中RTO计时器一共超时了4次，每次超时都进行重传：
第1次RTO超时时间为2号包与1号包的时间差：1秒；
第2次RTO超时时间为3号包与2号包的时间差：2秒；
第3次RTO超时时间为4号包与3号包的时间差：4秒；
第4次RTO超时时间为5号包与4号包的时间差：8秒。
在这条会话中。RTO计时器被重启了4次，每次重启，新的RTO计时器超时时间均被设置为上次超时时间的2倍，这种计算方法被称为指数退避。
如何分析RTO超时重传流量？
如何在科来CSNA系统中的时序图功能中找到超时重传流量？首先，由于超时重传数据包已经被CSNA系统标记为异常流量，因此可以在CSNA系统的TCP会话视图中，通过右侧的“重传包数”一列来寻找存在重传的异常TCP会话，如下图所示：
图5 存在异常重传的TCP会话
选中存在重传的会话，在下方的数据包子视图中使用如下语句过滤超时重传数据包：
tcpanalysis.retransmission = 1
过滤结果如下图所示：
图6 详细的重传包列表
通过分析，发现这些重传出现在会话结束阶段，包括一些FIN包和一些“服务不可用，关闭控制连接”包。双击这条会话，启动TCP时序图功能，观察这些重传包的时序图，如下图所示：
图7 FIN包的重传
如图6所示，会话22号包与23号包之间空闲了31.9秒，空闲后，客户端主动发送FIN包，但服务器未响应，于是客户端分别在0.3秒、0.6秒、1.2秒、2.4秒后尝试重传FIN包，时间规律是非常明显的指数退避，通过指数退避可以明显看出此时的超时计时器与超时重传机制正在生效工作，会话在23号包时的RTO计时器时长为0.3秒。
超时重传可能预示的故障
由于TCP具备超时重传和快速重传这两种重传机制，因此如果网络中只出现超时重传，那么大概率意味着网络不通或该数据包无法接收了。
导致网络不通的原因可能包括设备故障、线路故障、防火墙Drop等，例如前文中图4和图6的情况。导致图4的情况为笔者启用了系统防火墙，禁止该端口流量进入服务器，导致图6的情况为笔者为服务器一侧增加了100%的入向丢包率，模拟光纤单向故障。
导致无法接收的原因可能包括MTU限制、序列号异常等情况。关于MTU问题导致数据包无法发送问题，可参考前文《从时序图看TCP：有关MSS分析技巧，让故障排查事半功倍》中的描述。序列号异常情况，可参考前文《TCP的核心组件（下）：确认号与确认机制》中图5描述的异常情况。
实际分析过程中，导致数据包无法到达对端的原因可能千奇百怪，具体情况还要具体结合实际情况进行分析。
超时重传相关的实际故障分析
接下来观察一个经典的超时重传相关案例，老规矩，读者可以先从图中尝试分析故障：
图8：故障抓包
读者可以尝试分析图中的重传的是否属于RTO重传，该图中绿色ACK包为连接断开“四次挥手中”的“第四次”ACK包，由客户端发出，四次挥手完成后，服务器多次重传连接断开“第三次”FIN包（图中红色FIN包），请读者试着分析原因。这次的实例分析稍微有些难，但故障分析过程相当精彩。
结语
本文介绍了TCP的RTO计时器和超时重传机制，深入探讨了超时重传的流量现象、故障的根因分析，以及在CSNAS时序图中对于此类问题的分析方法，通过深入理解和掌握此类分析技巧，能够提升流量分析工程师在工作中快速分析解决此类故障的能力。
暂无评论