TCP协议的性能评测工具

Github地址：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。

2. 丢包和重传

TCP主要使用了两种丢包的检测和重传机制：

快速重传，由重复的ACK触发
超时重传，由定时器触发

当收到一定数量的重复ACK后，TCP会判断有丢包发生了，马上重传丢失的数据包。从发送原始数据包，

到发送重传包，一般在1个RTT以内，所以称为快速重传。如果没有收到足够多的重复ACK，或者快速

重传失败了，就会使用超时重传。在等待RTO时间后，TCP才判断发生了丢包，接着会重传丢失的数据包。

作为快速重传的failover，超时重传会耗费更多的时间。

Tcpdive能够区分快速重传和超时重传，在一条TCP连接的生命周期内，分别统计这两种重传机制的触发次数、

重传的数据包个数、总的等待时间、总的恢复时间、虚假重传的次数。通过这些性能指标，我们能够清楚的描述

丢包和重传对一条TCP连接的影响。这部分功能是可选的，关于每个性能指标的含义可参考Github。

3. 拥塞控制

目前Linux内核默认使用的拥塞控制算法为Cubic。

顾名思义，Cubic的拥塞控制窗口的增长曲线是一个条三次曲线，主要由三部分构成：

第一个部是上凸的，拥塞控制窗口快速增长，以接近上次丢包时的大小，称之为查找阶段。
第二部分是平缓的，拥塞控制窗口的增长非常缓慢，基本上保持不变，称之为平稳阶段。
第三部分是下凹的，拥塞控制窗口快速增长，用于探索可用带宽的上限，称之为探索阶段。

Tcpdive通过一些针对Cubic的性能指标，来评测当前TCP协议的拥塞控制性能。这部分功能是可选的，关于每个

性能指标的含义可参考Github。

上图中的性能指标，很多都是一条TCP连接生命周期内的平均值。如果我们想更加准确的描绘一条TCP连接的具体波动呢？

这时候另外一种方法就派上用场了，我们称之为Advanced CC。和之前基于连接的性能指标不同，它是基于数据包的，

通过记录5种不同类型的关键点，来描绘一条连接的具体波动。关于关键点的定义可参考Github。

（下图是手绘的，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中写的比较详细，使用方法也不复杂，这里就不再赘述了。

Tcpdive的性能

关于Tcpdive的性能消耗，我们分别在实验室环境、新浪的线上环境进行了评测，具体可看Github项目的README。