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

Posted IEEE

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TCP协议的性能评测工具 — 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,超时重传会耗费更多的时间。

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,这部分功能是可选的。

在服务器端,把每个HTTP请求所花费的时间划分为三部分:等待请求的到来,服务器的处理时间,响应的传输时间。 

对于每对HTTP request/response,都提供了如下性能指标:

当进行TCP协议优化时,我们关注的是响应文件的传输时间。值得注意的是,从传统的Web服务器中,是无法获取这 

部分时间的,因为应用层只负责把响应数据交给TCP层,至于TCP层什么时候才把数据传完,应用程序并不知情。 

至于其它两部分时间,作为干扰因素,是要剔除掉的。通过这一功能,Tcpdive可以准确的评价优化效果,并且做到了 

独立于上层的具体应用。


Tcpdive的使用

如果你看到这里,说明对Tcpdive还是比较感兴趣的,赶紧用起来吧:) 

关于Tcpdive的使用方法,在Github项目的README中写的比较详细,使用方法也不复杂,这里就不再赘述了。


Tcpdive的性能

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

 



以上是关于TCP协议的性能评测工具 — Tcpdive开源啦的主要内容,如果未能解决你的问题,请参考以下文章

ethr 微软开源的tcp udp http 网络性能测试工具

Zlib和Zstd 性能对比评测

Zlib和Zstd 性能对比评测

Zlib和Zstd 性能对比评测

优秀的国产高性能TCP/UDP/HTTP开源网络通信框架——HP-Socket

51.使用TCP协议检测网络性能