tcp加速技术解决方案

来源:个人博客     2021-09-06 11:24:46    人气:     我有话说( 0 人参与)

需求和现状行业需求近年来,随着互联网在全球的快速发展和普及,网民数量的增加,生活中各方面对互联网依赖的增强,带来互联网访问量的爆发性增长。 并且随着web页面内容元素越来

需求和现状

行业需求

近年来,随着互联网在全球的快速发展和普及,网民数量的增加,生活中各方面对互联网依赖的增强,带来互联网访问量的爆发性增长。 并且随着web页面内容元素越来越丰富,对交互延时的要求, 给服务端的并发能力和处理能力提出了新的要求。 横向上可以增加机器来提高web服务的可用性和解决并发量的增长。虽然硬件越来越便宜,但是一味增加机器会造成大量的维护成本和非高峰时候资源的闲置。 结合对现有机器的优化和合理的资源配置,提高网络带宽的利用率,才是更有效的解决方法。

现状

当前linux内核的TCP实现存在一些设计和实现上的缺陷, 虽然业界有很多相关的paper和方案,但是社区方面推动比较谨慎和缓慢。 同时随着网络的爆发性增长和C10M概念的出现,基于数据面的实现(绕过内核协议栈)也逐渐成为了业界关注之一。

目标

提高单台机器的新建连接并发能力, 减少访问延时, 提高网络带宽利用率。

单边加速

需要明确的是,本文的目标是tcp加速,目标场景是web server, 而不是路由设备
在峰值带宽的情况下,网络的配置是在高吞吐量和低延时之间的权衡

网卡性能调优

cpu offload

对于大量小包为主cpu密集型场景,可以使用网卡的offload特性,减小cpu的负载,让网卡计算校验和,利用网卡来执行tcp分段, 将小包组装成大包再交给内核协议栈等。可以使用ethtool工具来开启相应特性。

网卡驱动调优

默认的ixgbe配置是在是在高吞吐和低延时之际的权衡, 可以更改相应的硬编码的配置或者ethtool进行更改,对于本文我们的场景来说,意义不是太大

利用网卡MSI-X多队列特性

MSI方式的中断对cpu多核的利用不佳,网卡中断全都落在某个cpu核心上,MSI-X方式可以为每个队列申请一个中断号,然后设置中断亲和性,把该队列的中断映射到某个特定的cpu核心上, 分担了cpu的单核压力。
目前绝大多数网卡都支持该特性,并且该特性是本文其他优化方案的基础条件。

多队列网卡RSS特性

支持RSS的网卡,可以根据TCP头部的某些信息位,比如来源ip端口,目标ip端口等,计算一个hash值,然后通过hash值在一个表里找到该数据要排入的接收队列。
网卡rss特性

Intel Ethernet Flow Director

RSS解决了cpu的单核心负载高的问题,把不同的数据流分发到不同的cpu上, 但是有可能应用程序并不在该cpu上。
因此Flow Director就是因此而来,它有两种模式:EP(Externally Programed)模式和ATR (automated Application Targeting Routing)模式。
当系统管理员了解整个网络主要的数据包路径的时候可以配置EP模式, 否则应使用默认的ATR模式。ATR模式会采样发送流量,然后根据tcp头的来源与目标信息把数据包交给之前发送该数据流的cpu核心。
Flow Director支持配置一些action, 可以把满足action条件的数据包发到特定的接收队列或者drop。
因此也可以做一些负载均衡和硬件防火墙。

多核优化

多核和tcp新建连接的关系
通过上图可以看到随着cpu核心数的增加,tcp每秒连接数并不会线性增长。
因为内核实现的限制,多个核心会竞争一些全局性的锁, 比如listen socket锁,后面会看到具体锁的实现和优化方案。

多核优化原则

通过网卡多队列的支持, 就可以有效利用多核心。
网卡收到数据包后,把相同的tcp数据流发送到同一个cpu上, 同时可以设置应用程序的cpu亲和性绑定到cpu。
这样同一个tcp流都在同一个cpu上处理,大幅度提升cpu cache的命中。
如果服务端开启了irqbalance服务,系统会根据cpu的负载来动态的分发网卡中断,因此如果自己指定整个tcp处理路径,需要停止该服务。

因此多核优化的原则主要如下:

  • 相同的数据流在相同的cpu上处理,避免cache bouncing
  • 尽量使用percpu本地变量,避免或减少全局锁的粒度
  • CPU负载均衡,在保持cpu本地化处理的基础上,避免单核压力过高

RPS/RFS/XPS google patch

RPS(Receive Packet Steering):数据包被网卡RSS发送到对应接收队列后,
RPS就会选择特定的cpu做协议栈处理, 映射关系可以通过/sys/class/net//queues/rx-/rps_cpus来配置。 但是RPS并不清楚应用程序在哪个cpu上。

RFS(Receive Flow Steering):RFS是在RPS的基础上, 解决了RPS的问题。 当应用程序调用recvmsg的时候,会记录所在的cpu到hash表中,hash表的key是网卡RSS计算的hash值。 因此下一次数据包来的时候就可以直接发到应用程序所在cpu进行处理。

XPS(Transmit Packet Streering):xps维护了发送队列和cpu的映射关系。网卡发送队列发送数据包完成后,可以中断到特定的cpu上, 因此可以让更少的cpu竞争该发送队列,减少中断造成的cache miss减少。
可以通过/sys/class/net//queues/tx-/xps_cpus配置映射关系。

内核优化

由于目前的linux发行版本依然存在很多TCP方面的性能问题, 因此优化内核是比较直接且有效的方式。
但是需要对内核上游源码持续跟踪,关注bug和新特性,需要长期维护, 并且未来新版本很可能也会推出类似方面的优化patch。

内核新建连接瓶颈

linux tcp新建连接瓶颈
在tcp三次握手的过程中,syn包连接请求会查找全局的一个listen表,找到后就会和应用程序accept的时候竞争该锁。
每个listen socket都有一个accept队列,三次握手完成后会把连接放到accept队列,等待用户程序accept的时候获取listener自旋锁并出队连接,最后通过VFS虚拟文件系统分配文件描述符后返回。

SO_REUSEPORT和SO_INCOMING_CPU

  • REUSEPORT: 每个listener只有一个accept队列, reuseport通过多个不同的socket文件描述符 listen在同一个地址端口,增加可以竞争的锁的数量,提升并发度,避免accept锁和惊群,并且内核提供负载均衡能力。

  • SO_INCOMING_CPU:内核4.4版本提供的socket选项,
    如果启用RPS/RFS或者根据网卡的RSS和中段亲和等, 数据包在cpu0上接收, 但是accept()后, 使用在cpu1上的reuseport listener,
    accept()后通过调用SO_INCOMING_CPU选项就能得到数据包被处理的cpu, 这时候应用程序做一定的调整,比如说把这个socket分发到绑定到该cpu上的worker进程处理。
    这样就不需要通过启用rps/rfs,来发送IPI中断,在协议栈的层次变更处理路线。 尤其在长连接中,应该有较好的性能提升。

    
    		

    1

    
    		

    getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);

SO_ATTACH_REUSEPORT_EBPF和SO_ATTACH_REUSEPORT_CBPF

如上述SO_INCOMING_CPU需要应用程序调正处理逻辑, 那有没办法直接在reuseport选择listener的时候直接选择当前协议栈所在cpu上的reuseport listener呢?
通过SO_ATTACH_REUSEPORT_EBPF和SO_ATTACH_REUSEPORT_CBPF选项可以指定自己reuseport算法。

内核4.4 lockless listener

老版本的内核,在每个listener里都有一个request队列,每收到一个syn包后都要锁listener并创建一个新的request插入。 4.4版本在listener之外维护了request,使用tcp的ehash表,这样就大幅度减少了listener锁的竞争。

Fastsocket

  • Fastsocket是新浪开源的,并在生产环境部署的一个内核优化版本
  • 使用的时候,只需要启动时指定LD_PRELOAD环境变量,使用它的动态库来替换原生socket接口。 容易回滚到原生接口。
  • 基于centos-6.5, kernel 2.6.32版本,(对docker支持不好,高版本内核发行版使用systemd管理服务,不容易降级)
  • 根据官方报告,跟原生centos-6.5相比,提升260%-620%(24核以上)

fastsocket官方测试报告

Fastsocket架构

fastsocket技术架构

上图可以很清楚的看到, 它也是利用本文前述的技术原理和多核优化原则。

  • 通过在网卡多队列RSS, 使用flow director或者google的rps/rfs/xps把数据包都发送到应用程序所在的cpu上,应用程序启动时也设置cpu亲和性绑定到特定的cpu上,让相同的数据流都在同一个cpu上处理。
  • 每个cpu维护一份本地的Established表和Local Listen表, 在reuseport的基础上,进一步减少listener锁的竞争。
  • 优化VFS文件系统,因为socket不需要inode和dentry,可以忽略一些需要同步的代码路径。
Fastsocket优化收益

fastsocket收益分析

可以看到VFS的优化空间很大,其次多核tcp路径的优化,然后是增加cpu本地listen表。

使用数据面方案-绕过内核协议栈

内核本身不可避免的开销

  • 系统调用,陷入内核态,上下文切换
  • 内核态到用户态的数据拷贝
  • 中断处理
    还有诸如不容易调试, 代码比较复杂等等都会增加开发和维护难度。

使用DPDK

  • DPDK是intel推出的快速的数据包处理框架
  • 通过内核uio机制,使数据包直接dma发送到用户态内存中
  • 因为不走内核协议栈,需要结合其他用户态协议栈一起使用
  • 支持intel网卡,其他网卡支持有限
  • 根据官方数据转发一个包大概80个时钟周期(一次ddr3访问就需要近200个时钟周期)
基于DPDK的应用架构

dpdk应用架构

上图可以看到dpdk应用为每个网卡队列启动了一个线程,每个线程绑定到一个cpu上, 通过内核的uio驱动机制,网卡队列的数据包可以直接发送到用户态的缓存中,然后dpdk线程循环拉取该缓存,之后递交到用户态协议栈处理。

DPDK的内存优化
  • 所有内存资源启动时一次性分配完毕
  • 支持numa, cpu就近分配内存
  • 使用hugepage,减少tlb miss的时候,访问多级页表的开销
  • 在cache line的基础上,支持多通道和内存条rank级并行优化。一个内存通道一般使用64位数据总线,双通道同时工作提供了128位传输能力。Rank是指DIMM上几个内存颗粒共同提供的64位数据,同一条内存上的不同rank因为共享数据总线而不能被同时访问,但内存可以利用交错的片选信号来访问不同rank中数据。

Two Channels and Quad-ranked DIMM Example

上图可以看到通过数据包对象位于不同的channel和rank, 使对象并行加载。

支持DPDK的用户态协议栈问题
  • 有mtcp,seastar等等
  • 接口不兼容, 分配的fd描述符不是内核分配的,不能和内核文件接口通用。 比如mtcp实现的epoll就不能加入内核文件描述符。因此大多数开源软件要转到dpdk协议栈接口就有这方面的设计问题。
  • 生产环境稳定性有待验证
  • 因为不走内核了,不支持netstat等工具链

总之做tcp webserver的考虑各方面研发运维成本,目前使用dpdk并不十分合适

DPDK DNS缓存系统

虽然DPDK的tcp协议栈有比较多工作要做,但是目前DPDK在网络监控快速的数据包分旁路阻断, 或者在DNS方面还是有很多公司在跟进。
我们可以利用DPDK来做一个DNS的缓存系统, 实时解析DNS的数据包,其他所有的包或者缓存中未命中的包都通过kni机制重新走内核协议栈。 既利用了DPDK快速处理能力,又避免了DPDK在TCP协议栈方面的坑。
但是写本文的时候kni只支持单队列,需要修改底层模块来进行支持

dpdk dns cache

  • 通过DPDK收到本机DNS请求的包后,解析请求,查询缓存(无阻塞)。
  • 所有非本机DNS查询的数据包或缓存未命中的包,通过DPDK的kni机制,重新走内核协议栈。(会增加一点延时,但是通过缓存的高命中率确保整体的收益非常高)

拥塞控制

tcp拥塞控制

拥塞控制是分布式异步算法来共享带宽,它有两部分组成:

  • TCP:发送窗口=min(rwnd, cwnd)
  • AQM:网络中间设备调整和反馈拥塞信息,在高吞吐和低延时之间做出平衡,如设备队列满主动丢包等
    期望达到一个高吞吐,公平,稳定的带宽利用

传统拥塞算法弊端

tcp AIMD

  • 慢启动,指数增加(有可能被推迟确认),http/2.0通过减少连接数来避免慢启动,上图经过4个RTT时间cwnd从1个MSS增加到慢启动阈值16
  • 增加到慢启动阈值后,线性增加慢。 在一个RTT时间内收到所有确认只能增加1个MSS
  • 丢包的后阈值减半,重新进入慢启动,空闲一个重传超时RTO后也会重新慢启动(net.ipv4.tcp_slow_start_after_idle=1), 抖动非常严重
  • 收到3个相同ACK后,会进入快重传阶段,不降低阈值,线性增加

上述算法是把丢包作为拥塞信号,但是丢包不一定拥塞, 比如在无线/移动环境中。 并且经常性的慢启动和降阈值造成的抖动,造成带宽利用率大幅度降低。

如何优化拥塞算法

  • 增加延时作为拥塞反馈信号
  • 建立更好的数学模型, 更快达到网络最大利用率(减少慢启动和线性增加所做的逐步探测网络带宽的过程)。
    根据丢包和延时动态计算一个网络的均衡点(在这个点实现了网络利用率的最大化,并且能尽量保证各方的公平性)。 离均衡点越远,拥塞窗口调整越快, 否则越慢。
    以上就是FAST TCP的思路。

FAST TCP

  • FAST TCP首先被Fastsoft公司商业化,后被Akamai收购。
  • Akamai是全球最大cdn服务商,承载全球15%-30%流量
  • 需要稳定性公平性等多维度测试, 确定经验值的选取
    fast tcp带宽利用
    以上可以看到FAST TCP的带宽利用率最高,抖动最少。

Zeta TCP

  • 华夏创新推出的基于传输历史学习的算法
  • 成功案例: 爱奇艺,蓝汛cdn/腾讯视频
  • 适用于网络链路比较差或延迟带宽积比较高的网络环境(导致大量国外vps的客户购买), 并且需要大部分tcp包在50kb以上的场景, 否则效果更差。

Google BBR

  • google bbr算法已经被merge到linux 4.9中,并且效果不错,并经过Google大规模测试
  • 主要的缺点就是新版内核的拥塞框架回调点和旧版本有很大区别,并不容易移植到低版本

双边加速

由于内核TCP实现的以上各种问题,所以目前大多数双边加速都是在UDP的基础上,增加应用层的TCP的可靠性机制(确认,重传,按序等等)。
因为客户端和服务端都需要调用该协议SDK, 如果要对现有的软件接入该SDK,基本上需要对软件进行重构和重写, 因此开发成本还是比较大的。

QUIC

可以认为是tcp+tls+http/2.0在udp上的实现,目前是chrome上的实验特性, 仍处于快速迭代过程中。
https://www.chromium.org/quic

UDT

Yunhong GU(tech lead of google public dns)实现的一个reliable udp。
http://udt.sourceforge.net

MPTCP

也就是MultiPath TCP

kcp

https://github.com/skywind3000/kcp
也是一个udp隧道
这些自己玩玩就好了,在生产环境中使用需要谨慎。

本文作者: bhpike65

本文链接: http://www.cnhalo.net/2016/03/13/tcp-accelerate-report/

tcp accelerate

本文源自互联网,采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可,
版权归原作者,如有问题请联系service@tsingfun.com (编辑:admin)
分享到: