使用xTCP进行大规模套接字性能监控

背景

CDN和云提供商在互联网上提供大量流量，并采用广泛的监控工具来确保性能和可靠性。 这些工具包括涵盖网络，服务器，应用程序等各种流量交付层的工具 TCP/IP占此流量的大部分(虽然基于UDP的QUIC在全球范围内呈上升趋势，但与TCP相比，它在总流量中仍占一小部分)。

套接字是操作系统抽象，用于链接传输数据的客户端和服务器连接。 因此，网络问题直接反映在每个套接字存储的数据中。 例如，网络拥塞可能导致响应时间缓慢和往返时间(RTT)增加。 网络带宽可用，但应用程序被过多请求淹没，无法在缓冲区中填充足够的数据以充分利用可用带宽，从而导致应用程序受限的异常。 服务器通常同时处理多个套接字，这会导致资源争用，给CPU和内存等系统资源带来压力。

因此，大规模监控TCP套接字的性能可以提供对流量行为(例如响应时间过慢或连接中断)的重要理解，并确定需要改进的情况。

现有工具

Linux中的”ss”实用程序是用于获取套接字统计信息的常用工具。 与”netstat”类似，ss通过允许筛选套接字状态，协议和地址，提供更快，更灵活的获取信息的机制。 我们还与ss一起开始了套接字监控之旅。 虽然它是一个快速获取插槽列表和相关指标的强大工具,但ss的主要挑战是它会消耗大量资源,尤其是在具有大量插槽的系统上使用时。 这会影响系统性能并减慢其他进程的速度。 此外，由于密钥：值使用不一致，ss输出不适合解析，并大大增加了从数千台服务器收集到的数据流的能力。

我们使用ss收集套接字的第一个版本是在选定的缓存服务器上运行的bash脚本，我们将”ss–tcp–info”的输出导出到文件中。 然后,该文件将被rsync到堡垒主机, python脚本将从中读取该文件,解析并将其插入到ElasticSearch中。 这项工作已经完成，但与我们所需的规模相比，还差强人意。 这项工作的下一个迭代是在缓存服务器上运行一个python脚本,该脚本将从HTTP接口调用,并返回聚合的统计数据以插入ElasticSearch集群。 此方法将解析瓶颈从中央后台位置扩展到单个缓存服务器，但导致服务器上具有大量套接字的内存利用率。 最终，我们认识到需要轻量级更换系统的主要部分。

我们对这款新工具的关键要求是，它应该是轻量级的，可扩展到我们CDN服务器拥有的大量插槽，并且能够使用协议缓冲等高效机制将数据流回传。 来自MeasurementLab的TCP-info工具是在Golang实现的一个很好的实用工具。 但是，它的设计目的是随着时间的推移跟踪相同的插槽。 鉴于我们的插座连接量很大，我们做出了不跟踪单个插座的设计选择。 相反，请让每个轮询环路都是独立的，以提供打开套接字的当前状态的快照。 这里的主要目标是跟踪系统的整体性能，而不是单个插槽。

xtcp

为了解决这些挑战,我们引入和开源xTCP (提取,导出, Xray TCP )。 xTCP是一个Golang实用程序，用于大规模捕获和传输套接字数据。 xTCP使用Netlink捕获套接字信息,将数据打包到protobufs中,然后通过UDP端口(最终发送到卡夫卡等)或写入NSQ。

NetLink为用户空间和内核空间之间的通信提供了通用接口。 套接字监视工具ss, tcp-info使用NetLink_iNet_DIAG (Netlink协议系列的一部分)将套接字信息从内核传入用户空间(手册页中的注释：NetLink_iNet_DIAG是在Linux 2.6.14中引入的，仅支持AF_iNet和AF_inet6套接字。在Linux 3.3中，它被重命名为NetLink_SOCK_DIAG并扩展到支持AF_UNIX套接字。)

xTCP以高速率提取内核TCP iNet_DIAG数据，并通过protobuf导出该数据。 在一台~120k套接字的计算机上，Netlink消息约为~5-6MB，但是ss的ASCII输出约为~60MB。 此外，默认情况下，ss以~3KB块的格式从内核读取。 xTCP读取32KB块，从而最大限度地减少系统调用。 xTCP使用多个工作者同时读取Netlink套接字数据，以尽可能快地排出队列，并同时解析Netlink消息以进行流式传输。 所有这些优化使xTCP的占用空间更小，无法在生产缓存服务器上运行。

在Edgio的使用

我们大量利用xTCP数据来分析客户端性能。 通常，我们跟踪RTT和通过入网点(POP)和ASN聚合的重新传输。