TCP协议的性能评测工具 — Tcpdive开源啦

jopen 6年前

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

TCP协议的性能评测工具 — Tcpdive开源啦


2. 丢包和重传

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

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

当收到一定数量的重复ACK后,TCP会判断有丢包发生了,马上重传丢失的数据包。从发送原始数据包,
到发送重传包,一般在1个RTT以内,所以称为快速重传。如果没有收到足够多的重复ACK,或者快速
重传失败了,就会使用超时重传。在等待RTO时间后,TCP才判断发生了丢包,接着会重传丢失的数据包。
作为快速重传的failover,超时重传会耗费更多的时间。

TCP协议的性能评测工具 — Tcpdive开源啦

Tcpdive能够区分快速重传和超时重传,在一条TCP连接的生命周期内,分别统计这两种重传机制的触发次数、
重传的数据包个数、总的等待时间、总的恢复时间、虚假重传的次数。通过这些性能指标,我们能够清楚的描述
丢包和重传对一条TCP连接的影响。这部分功能是可选的,关于每个性能指标的含义可参考Github

TCP协议的性能评测工具 — Tcpdive开源啦

3. 拥塞控制

目前Linux内核默认使用的拥塞控制算法为Cubic。
顾名思义,Cubic的拥塞控制窗口的增长曲线是一个条三次曲线,主要由三部分构成:

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

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

TCP协议的性能评测工具 — Tcpdive开源啦

上图中的性能指标,很多都是一条TCP连接生命周期内的平均值。如果我们想更加准确的描绘一条TCP连接的具体波动呢?
这时候另外一种方法就派上用场了,我们称之为Advanced CC。和之前基于连接的性能指标不同,它是基于数据包的,
通过记录5种不同类型的关键点,来描绘一条连接的具体波动。关于关键点的定义可参考Github
(下图是手绘的,Tcpdive目前不支持自动画图… )

TCP协议的性能评测工具 — Tcpdive开源啦

4. HTTP处理

HTTP是一个基于请求和响应的协议,通常是客户端先发送一个请求,然后服务器返回一个响应(暂不考虑HTTP/2)。
Tcpdive能够在TCP层面上,对每个HTTP request和response进行监测,因而独立于具体的HTTP应用。
Tcpdive支持Per request级别的刻画,支持HTTP Keep-Alive,这部分功能是可选的。

TCP协议的性能评测工具 — Tcpdive开源啦

在服务器端,把每个HTTP请求所花费的时间划分为三部分:等待请求的到来,服务器的处理时间,响应的传输时间。
对于每对HTTP request/response,都提供了如下性能指标:

TCP协议的性能评测工具 — Tcpdive开源啦


当进行TCP协议优化时,我们关注的是响应文件的传输时间。值得注意的是,从传统的Web服务器中,是无法获取这
部分时间的,因为应用层只负责把响应数据交给TCP层,至于TCP层什么时候才把数据传完,应用程序并不知情。
至于其它两部分时间,作为干扰因素,是要剔除掉的。通过这一功能,Tcpdive可以准确的评价优化效果,并且做到了
独立于上层的具体应用。


Tcpdive的使用

如果你看到这里,说明对Tcpdive还是比较感兴趣的,赶紧用起来吧:)
关于Tcpdive的使用方法,在Github项目的README中写的比较详细,使用方法也不复杂,这里就不再赘述了。


Tcpdive的性能

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

来自: http://blog.csdn.net/zhangskd/article/details/50529254