Github地址：[https://github.com/fastos/tcpdive](https://github.com/fastos/tcpdive) ### 为什么要开发Tcpdive 在过去的几年里，随着移动互联网的飞速发展，整个基础网络已经发生了翻天覆地的变化。 用户接入网络的方式，除了宽带和光纤之外，还有2G/3G/4G/WiFi，5G也已经在路上了。 作为使用范围最广的传输层协议，TCP诞生于固网时代，在设计之初并没有考虑到上述种种情况， 这导致了它在某些场景下，性能并不是最优的。因此大多数的CDN厂商和一些规模较大的互联网公司都会 进行TCP协议的优化，以提供更好的用户体验，如更快的访问速度，更低的访问失败率，更流畅的视频播放等。 而当我们尝试优化TCP协议时，却面临着不少难点： - 可用的工具少。 和TCP相关的工具，比如tcpdump，netstat和ss，虽然很好用，但是使用场景并不是TCP协议的性能评测， 能够提供的性能信息实在有限。 - 依靠个人感觉，进行盲试。 不知道瓶颈在哪，盲目修改，或者直接套用已有的优化方法。 盲目修改常导致徒劳无功，直接套用现成的方法，由于大家的应用场景不尽相同，也不一定有效。 - 测试成本高。 对TCP协议的性能评测主要采用两种方法。 一种是通过对上层应用的测试，来评估TCP协议的性能。这种方法的评价指标有限，而且是上层应用相关的。 另一种是依靠第三方测试服务。这种方式的样本量有限，且成本较高。 - 无法准确地评价优化效果。 上述的两种测试方法，都涉及到应用层面，因此测量的不仅仅是TCP协议本身，还参杂了干扰因素。 ### Tcpdive的设计目标 针对上述问题，我们决定设计一个专门的TCP协议性能评测工具，也就是Tcpdive。 之所以起这个名字，是因为dive有深入研究的意思：） Tcpdive具有一些特性，实际上也是我们的设计目标： - 对TCP协议的性能进行较为全面的刻画，有助于发现瓶颈。 如此一来，就能找到痛点，不用再盲目地进行优化。 - 易于部署和使用，无需改动生产环境，使用成本低。 这一点非常重要，因为不需要修改内核或者应用程序，比较容易推广。 - 独立于上层应用，能够准确地评价优化效果。 直接对TCP协议的性能进行刻画，而不依赖于具体的应用。 因此能够排除上层应用的干扰，量化地评价优化效果。 ### Tcpdive的基本原理 Tcpdive是基于linux内核的探测点机制，使用systemtap脚本语言和内嵌C代码来实现的。 通过定义几类相互关联的探测点和库函数，来收集和处理运行中内核的数据，以及修改内核的处理逻辑。 为什么要基于systemtap呢？systemtap的神奇之处在于，不修改内核的情况下就能获取内核中的任何信息， 还可以修改内核的处理逻辑。所以虽然被它虐了千百遍，但还是觉得这套探测点机制非常有用。当然它也不是 十全十美的，比如作为一种调试语言，它是够用的，但是把它用作一种开发语言，则会遇到不少问题。通过不 断的尝试，大多数问题最终都获得比较好的解决。 目前Tcpdive已经部署到作为流量入口的负载均衡服务器上，在新浪的线上环境7*24h运行，可以说是比较稳定的。 ### Tcpdive的主要功能 作为一个TCP协议的性能评测工具，Tcpdive提供了大量的性能指标，从以下维度来对每条TCP连接进行刻画： - 传输情况 - 丢包和重传 - 拥塞控制 - HTTP处理 ### **1. 传输情况** 使用如下性能指标来描绘一条TCP连接的传输情况，是默认启用的功能。关于每个性能指标的含义可参考[Github](https://github.com/fastos/tcpdive/blob/master/doc/transmission.md)。  ### **2. 丢包和重传** TCP主要使用了两种丢包的检测和重传机制： - 快速重传，由重复的ACK触发 - 超时重传，由定时器触发 当收到一定数量的重复ACK后，TCP会判断有丢包发生了，马上重传丢失的数据包。从发送原始数据包， 到发送重传包，一般在1个RTT以内，所以称为快速重传。如果没有收到足够多的重复ACK，或者快速 重传失败了，就会使用超时重传。在等待RTO时间后，TCP才判断发生了丢包，接着会重传丢失的数据包。 作为快速重传的failover，超时重传会耗费更多的时间。  Tcpdive能够区分快速重传和超时重传，在一条TCP连接的生命周期内，分别统计这两种重传机制的触发次数、 重传的数据包个数、总的等待时间、总的恢复时间、虚假重传的次数。通过这些性能指标，我们能够清楚的描述 丢包和重传对一条TCP连接的影响。这部分功能是可选的，关于每个性能指标的含义可参考[Github](https://github.com/fastos/tcpdive/blob/master/doc/retransmission.md)。  ### **3. 拥塞控制** 目前Linux内核默认使用的拥塞控制算法为Cubic。 顾名思义，Cubic的拥塞控制窗口的增长曲线是一个条三次曲线，主要由三部分构成： - 第一个部是上凸的，拥塞控制窗口快速增长，以接近上次丢包时的大小，称之为查找阶段。 - 第二部分是平缓的，拥塞控制窗口的增长非常缓慢，基本上保持不变，称之为平稳阶段。 - 第三部分是下凹的，拥塞控制窗口快速增长，用于探索可用带宽的上限，称之为探索阶段。 Tcpdive通过一些针对Cubic的性能指标，来评测当前TCP协议的拥塞控制性能。这部分功能是可选的，关于每个 性能指标的含义可参考[Github](https://github.com/fastos/tcpdive/blob/master/doc/congestion.md)。  上图中的性能指标，很多都是一条TCP连接生命周期内的平均值。如果我们想更加准确的描绘一条TCP连接的具体波动呢？ 这时候另外一种方法就派上用场了，我们称之为Advanced CC。和之前基于连接的性能指标不同，它是基于数据包的， 通过记录5种不同类型的关键点，来描绘一条连接的具体波动。关于关键点的定义可参考[Github](https://github.com/fastos/tcpdive/blob/master/doc/congestion.md)。 （下图是手绘的，Tcpdive目前不支持自动画图… )  ### **4. HTTP处理** HTTP是一个基于请求和响应的协议，通常是客户端先发送一个请求，然后服务器返回一个响应（暂不考虑HTTP/2）。 Tcpdive能够在TCP层面上，对每个HTTP request和response进行监测，因而独立于具体的HTTP应用。 Tcpdive支持Per request级别的刻画，支持HTTP Keep-Alive，这部分功能是可选的。  在服务器端，把每个HTTP请求所花费的时间划分为三部分：等待请求的到来，服务器的处理时间，响应的传输时间。 对于每对HTTP request/response，都提供了如下性能指标：  当进行TCP协议优化时，我们关注的是响应文件的传输时间。值得注意的是，从传统的Web服务器中，是无法获取这 部分时间的，因为应用层只负责把响应数据交给TCP层，至于TCP层什么时候才把数据传完，应用程序并不知情。 至于其它两部分时间，作为干扰因素，是要剔除掉的。通过这一功能，Tcpdive可以准确的评价优化效果，并且做到了 独立于上层的具体应用。 ### Tcpdive的使用 如果你看到这里，说明对Tcpdive还是比较感兴趣的，赶紧用起来吧：） 关于Tcpdive的使用方法，在Github项目的[README](https://github.com/fastos/tcpdive)中写的比较详细，使用方法也不复杂，这里就不再赘述了。 ### Tcpdive的性能 关于Tcpdive的性能消耗，我们分别在实验室环境、新浪的线上环境进行了评测，具体可看Github项目的[README](https://github.com/fastos/tcpdive)。