服务器之家:专注于服务器技术及软件下载分享
分类导航

Linux|Centos|Ubuntu|系统进程|Fedora|注册表|Bios|Solaris|Windows7|Windows10|Windows11|windows server|

服务器之家 - 服务器系统 - Linux - Linux高性能网络编程十谈|性能优化(网络)

Linux高性能网络编程十谈|性能优化(网络)

2023-11-01 17:16未知服务器之家 Linux

上一篇文章讲了《性能优化(CPU和内存)》,这一节我们主要是聊聊网络优化。 第一部分:网络性能度量 1、设备度量 设备主要是指块设备,由于我们在开发过程中,需要磁盘操作,比如写日志等,所以对于块设备的I/O对于我们需要

上一篇文章讲了《性能优化(CPU和内存)》,这一节我们主要是聊聊网络优化。

第一部分:网络性能度量

1、设备度量

设备主要是指块设备,由于我们在开发过程中,需要磁盘操作,比如写日志等,所以对于块设备的I/O对于我们需要度量性能的一个重要指标。

(1)I/O等待

CPU等待I/O操作发生的时间,较高和持续的值很多时候表明IO有瓶颈,一般通过iostat -x命令查看:

[root@VM-0-11-centos ~]# iostat -x
Linux 3.10.0-1127.19.1.el7.x86_64 (VM-0-11-centos)  2023年09月23日  _x86_64_ (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.40    0.00    0.41    0.25    0.00   98.93

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    10.12    0.08   10.13     1.82    85.81    17.16     0.02    2.03    9.06    1.97   0.36   0.37
scd0              0.00     0.00    0.00    0.00     0.00     0.00     7.14     0.00    0.27    0.27    0.00   0.27   0.00

其中avgqu-sz,avgrq-sz,await,iowait,svctm等这些都需要关注,其含义如下:

  • avgqu-sz是平均每次IO操作的数据量(扇区数为单位)
  • avgrq-sz是平均等待处理的IO请求队列长度
  • await是平均每次IO请求等待时间(包括等待时间和处理时间,毫秒为单位)
  • svctm平均每次IO请求的处理时间(毫秒为单位)
  • iowait等待磁盘io所消耗的cpu比例

(2)平均队列长度

未完成的I/O请求数量,一般情况下,小于3个是合理的,如果超过表示I/O存储瓶颈,具体可以通过上面的iostat -x命令查看。

(3)平均等待时间

服务I/O请求所测量的平均时间,等待时间不能过长,如果平均等待过长,说明I/O繁忙,具体可以通过上面的iostat -x命令查看。

(4)每秒传输

描述每秒读写的性能,块设备的读写性能随着型号或者调度算法的不同存在比较大的差异,比如使用iostat -x可以看到rkB/s,wkB/s,rrqm/s,r/s和w/s,对于I/0满载的情况下,这些值越大越好。

  • rrqm/s是每秒对该设备的读请求被合并次数,文件系统会对读取同块(block)的请求进行合并
  • wrqm/s是每秒对该设备的写请求被合并次数
  • r/s是每秒完成的读次数
  • w/s是每秒完成的写次数
  • rkB/s是每秒读数据量(kB为单位)
  • wkB/s是每秒写数据量(kB为单位)

2、网络度量

高性能编程一般都离不开网络收发,对于RPC Server的开发,我们希望的收发和处理越快越好,那具体指标有哪些?

(1)接收和发送的数据包和字节

网络接口性能可以按照数据包或者字节大小来决定, TODO:

(2)丢包

丢包是指被内核丢弃的数据包,丢弃的原因如下:

  • 连接队列满了
  • 收发缓冲区满了
  • TCP底层重传次数超过设置
  • 开启了sync cookie等配置,阻止了一些攻击包
  • 防火墙设置等

查看丢包是否增长可以通过netstat -s|grep drop命令查看:

[root@VM-0-11-centos ~]# netstat -s|grep drop
    40 dropped because of missing route
    10 SYNs to LISTEN sockets dropped

(3)连接队列

这里连接队列是指TCP的三次握手连接队列(SYN半连接队列和ACCEPT连接队列),网络接收队列和网路发送队列。

我们通过netstat -s | grep "SYNs to LISTEN"查看:

[root@VM-0-11-centos ~]# netstat -s | grep "SYNs to LISTEN"
    11 SYNs to LISTEN sockets dropped

或者通过ss -lt查看:

[root@VM-0-11-centos ~]# ss -lt
State      Recv-Q Send-Q                    Local Address:Port                                     Peer Address:Port
LISTEN     0      128                                   *:ssh    
  • Recv-Q:表示收到的数据在接收队列中,但是还有多少没有被进程取走(非LISTEN的句柄),如果接收队列一直处于阻塞状态(这个值很高),可能缓存区太小了或者发包太快;
  • Send-Q:表示发送的数据在发送队列中未确认的字节数(非LISTEN的句柄),如果发送队列Send-Q不能很快的清零,可能是有应用向外发送数据包过快,或者是对方接收数据包不够快;

(4)其他异常

除了上述度量还有其他一些异常度量,比如大量reset包,大量重传包错误,或者能发包,但是不能收包等,网络相关的度量和排查其实相对复杂,如果大家有兴趣可以读读《Wireshark网络分析就这么简单》,可以通过自己抓包具体分析。

第二部分:网络层优化

1、零拷贝

在《Linux高性能网络编程十谈|系统调用》一文中,当时介绍了网络收发包需要经过多次系统调用和内存拷贝:

Linux高性能网络编程十谈|性能优化(网络)sendfile

为了高性能,Linux底层提供了一些零拷贝的系统调用如sendfile,以减少用户态和内核态的切换,原理是什么呢?

如果内核在读取文件后,直接把PageCache中的内容拷贝到socket缓冲区,待到网卡发送完毕后,再通知进程,这样就只有2次上下文切换,和3次内存拷贝;

如果网卡支持SG-DMA(The Scatter-Gather Direct Memory Access)技术,还可以再去除socket缓冲区的拷贝,这样一共只有2次内存拷贝;

除了上述说的sendfile这种零拷贝可以减少用户态到内核态切换和拷贝(因为网络调用),还有一种DirectIO,这种常用于大文件读写(比如FTP Server或者其他CDN下载服务器),原因是由于大文件拷贝难以命中PageCache,导致额外的内存拷贝,如果用DirectIO就可以直接操作磁盘,开发者自己控制缓存。

2、解决C1000K

在早期的服务器开发,从C10K(服务器同时处理1万个TCP连接),C100K(服务器同时处理10万个TCP连接)到C1000K(服务器同时处理100万TCP连接),其实原理上还是使用前面说的方式:事件驱动,异步IO或者协程等,具体的原理在《IO复用和模式》《协程》这两篇文章已经介绍了,如果有兴趣可以再回顾一下。而这里我们讨论一下可能面临的几个场景如何解决:

遇到计算任务,虽然内存、CPU 的速度很快,然而循环执行也可能耗时达到秒级,所以,如果一定要引入需要密集计算才能完成的请求,为了不阻碍其他事件的处理,要么把这样的请求放在独立的线程中完成,要么把请求的处理过程拆分成多段,确保每段能够快速执行完,同时每段执行完都要均等地处理其他事件,这样通过放慢该请求的处理时间,就保障了其他请求的及时处理,比如像Nginx;

读写文件,充分利用PageCache,小文件通过mmap加载到内存,而大文件拆分多个小文件处理;

所有socket操作全部都改为非阻塞,通过epoll或者kqueue来监听读写事件,并将事件拆分给对应的线程处理;

3、提升TCP握手和挥手性能

我们在前面网络篇中已经清楚了讲解了三次握手和四次挥手的流程,但是实际由于TCP的握手协议和挥手协议交互流程过多,会导致一些性能问题,该如何解决?

Linux高性能网络编程十谈|性能优化(网络)

(1)优化握手参数

正常情况下,握手环节客户端发送SYN开启握手,服务器会在几毫秒内返回ACK,但如果客户端迟迟没有收到ACK会怎么样呢?客户端会重发SYN,重试的次数由tcp_syn_retries参数控制,默认是6次:

net.ipv4.tcp_syn_retries = 6

同时每次传输时间是按照倍数递增(1,2,4,8,32,64 ... 秒),所以在网络繁忙情况下或者在业务明确不能太多超时情况下,调整这个时间到net.ipv4.tcp_syn_retries = 3,这样能减少服务端在网络繁忙情况下的连锁反应。

上述是客户端侧调整,而服务端可能会出现半连接队列满了的场景,控制半连接队列是net.ipv4.tcp_max_syn_backlog = 1024内核参数,可以适当的调大取值;同样服务端在从半连接队列转换到ESTABLISHED,也需要确认客户端回复的确认ACK,如果没有收到也会重发SYN+ACK,所以这里Linux也提供调整的参数net.ipv4.tcp_synack_retries = 5,减少重传次数,降低加剧的风险;

除了以上的调整,减少握手的RTT也是一种优化手段 —— TOF(TCP fast open),TFO到底怎样达成这一目的呢?它把通讯分为两个阶段,第一阶段为首次建立连接,这时走正常的三次握手,但在客户端的SYN报文会明确地告诉服务器它想使用TFO功能,这样服务器会把客户端IP地址用只有自己知道的密钥加密,作为Cookie携带在返回的SYN+ACK报文中,客户端收到后会将Cookie缓存在本地;

第二阶段就是每次TCP底层的报文都会带上Cookie,只要带上了Cookie的请求,服务端不需要收到客户端的确认包,就可以直接传输数据了,这样就减少了RTT;设置参数可以通过net.ipv4.tcp_fastopen = 3;

(2)优化挥手参数

握手优化有一些相应的方法,那挥手阶段是否也可以优化呢?我们应该在开发中经常遇到是TIME_WAIT状态,估计踩过坑的应该不少,TIME_WAIT过多会消耗系统资源,端口耗尽导致想新建连接失败,触发Linux内核查找可用端口导致循环问题等。如何解决?设置tcp_max_tw_buckets参数,当TIME_WAIT的连接数量超过该参数时,新关闭的连接就不再经历TIME_WAIT而直接关闭;或者快速复用端口tcp_tw_reuse,在安全条件下使用TIME_WAIT状态下的端口。

在回顾一下TCP挥手的图,被调方会有CLOSE_WAIT,如果在我们服务中有大量的CLOSE_WAIT时候,我们就得注意:

  • 是否在处理完调用方的时候后,忘记关闭连接
  • 服务负载太高,导致close调用被延时
  • 处理进程处于Pending状态,导致不能及时关闭连接

4、一些网络内核参数

"提升TCP握手和挥手性能"已经提到了一些优化参数,除了这些参数外还有一些对性能有帮助的参数:

  • net.ipv4.tcp_syncookies = 1减少SYN泛洪攻击
  • net.ipv4.tcp_abort_on_overflow = 1快速回复RST包,减缓accept队列满的情况
  • net.ipv4.tcp_orphan_retries = 5如果FIN_WAIT1状态连接有很多,考虑调小该值
  • net.ipv4.tcp_fin_timeout = 60调整该值可以减少FIN的确认时间
  • net.ipv4.tcp_window_scaling = 1调整滑动窗口的指数
  • net.ipv4.tcp_wmem = 4096 16384 4194304调整写缓冲区大小
  • net.ipv4.tcp_rmem = 4096 87380 6291456调整读缓冲区大小
  • net.ipv4.tcp_congestion_control = cubic调整拥塞控制的算法,可以分析具体网络场景,通过设置拥塞控制算法提升发包的效率

5、DPDK

在C1000K问题中,各种软件、硬件的优化很可能都已经做到头了,无论怎么调试参数,提升性能能力已经有限,根本的问题是,LINUX网络协议栈做了太多太繁重的工作。

于是英特尔公司的网络通信部门2008年提出DPDK,提供丰富、完整的框架,让CPU快速实现数据平面应用的数据包处理,高效完成网络转发等工作,具体细节大家可以查阅资料,这里我整理了DPDK高性能的大概原理:

跳过内核协议栈,直接由用户态进程通过轮询的方式,来处理网络接收,在PPS非常高的场景中,查询时间比实际工作时间少了很多,绝大部分时间都在处理网络包,而跳过内核协议栈后,就省去了繁杂的硬中断、软中断再到 Linux 网络协议栈逐层处理的过程,应用程序可以针对应用的实际场景,有针对性地优化网络包的处理逻辑,而不需要关注所有的细节;

通过大页、CPU 绑定、内存对齐、流水线并发等多种机制,优化网络包的处理效率;

Linux高性能网络编程十谈|性能优化(网络)DPDK网络图

第三部分:应用层协议优化

网络编程中除了设计一个好的底层server和调整内核参数外,其实应用层的协议选型和设计也很重要,那本小节讨论一下当前的优化方案。

1、HTTP/1.1

从互联网发展到现在,HTTP/1.1一直是最广泛使用的应用层协议,主要是使用简单,方便,但是缺点也很明显:HTTP头部使用 ASCII编码,信息冗余,协议滥用等,导致对其的优化都集中在业务层。那有哪些优化,我这里总结一些:

1.充分利用缓存

  • 客户端缓存:利用Cache-control,Expires,etags等HTTP/1.1特性,减少重复请求的次数;
  • CDN缓存:静态资源优先考虑使用CDN服务,本身CDN是边缘节点,同时已经充分考虑HTTP/1.1一些性能加速策略;
  • 3XX状态码:返回3XX状态码,让客户端根据状态码使用缓存策略

2.合并请求

  • 当多个访问小文件的请求被合并为一个访问大文件的请求时,这样虽然传输的总资源体积未变,但减少请求就意味着减少了重复发送的HTTP头部,同时也减少了TCP连接的数量,因而省去了TCP握手和慢启动过程消耗的时间
  • 由于浏览器限制同一个域名下并发请求数(如Chrome是6个),所以我们优先加载客户端急需的数据,其他数据可以懒加载

3.使用压缩算法

  • 利用HTTP的Accept-Encoding头部字段,让服务端知道客户端的压缩算法然后返回压缩后的数据给客户端
  • 对于图片请求,可以考虑使用webp,svg等格式,这些图片压缩后的数据较小

4.优化HTTPS

  • 优先使用TLS1.3,减少RTT次数
  • 明确某些静态资源不需要加密,或者可以自己通过预埋加密协议的,改为HTTP请求,减少握手次数
  • 使用长连接,缓解每次请求都需要走TLS的握手协议

2、HTTP/2

Linux高性能网络编程十谈|性能优化(网络)


Linux高性能网络编程十谈|性能优化(网络)

现在使用HTTP/2的服务越来越多了,包括gRPC框架的默认协议就是HTTP/2,对比HTTP/1,HTTP/2性能非常大的提升,可以从上图看出:

  • 图1 中HTTP/2使用的流式传输,在一条连接上可以有多个数据帧,这样就不需要再像HTTP/1一个请求需要新建一个连接了;
  • 图2 中HTTP/2使用HTTP Header静态和动态编码表的方式,这样每次请求不需要传递重复或者通用的一些Header信息,减少了包体的大小;

HTTP/1.1 不支持服务器主动推送消息,因此当客户端需要获取通知时,只能通过定时器不断地拉取消息,而HTTP/2的消息可以主动推送,可以节省大量带宽和服务器资源;

3、HTTP/3

Linux高性能网络编程十谈|性能优化(网络)HTTP3图3

上面介绍的HTTP/2虽然已经提升很多性能,减少了网络请求,但是底层使用TCP,避免不了握手,慢启动和拥塞控制等问题,于是HTTP/3通过使用UDP绕过这些限制来优化性能。

  • HTTP/3可以实现0 RTT建立连接,HTTP/2的连接建立需要3 RTT,如果考虑会话复用,即把第一次握手计算出来的对称密钥缓存起来,那也需要2 RTT,更进一步的,如果TLS升级到1.3,那么HTTP/2连接需要2 RTT,考虑会话复用需要1 RTT。而HTTP/3首次连接只需要1 RTT, 后面的链接只需要0 RTT,其原理和cookie类似,维持conntion id,实现连接迁移。
  • 解决队头阻塞,在HTTP/2中虽然是TCP多路复用,但是TCP的包确是顺序的,所以如果一个连接上的包在TCP层没有被确认,这个连接上HTTP/2请求都会被卡住,但是HTTP/3基于UDP就可以不存在这个问题,Packet可以发送给服务端,服务端根据需要自己组装包顺序,即使Packet丢了,可以重传当前Packet即可;

上述都是HTTP/3对比HTTP/2改进的地方,但是从目前看全面使用还是有一些局限,比如:防火墙对UDP包限制,连接迁移特性使情况变得更加复杂等问题,有兴趣的可以在客户端尝试,但是估计会要踩比较多的坑。

4、RPC协议

RPC协议包括很多(如HTTP JSON,XML,ProtoBuf等),框架也比较多(gRPC,Thrift,Brpc,Spring Cloud),随着微服务的架构被大家熟知,内网的RPC协议设计往往是网络框架的重要部分。当然RPC框架底层的架构还是前面介绍的异步,多路复用,多线程等设计,但是上层我们要考虑高性能,更多要解决如下问题:

  • 根据业务场景设计不同的协议,比如采用ProtoBuf能压缩编码,采用HTTP JSON协议方便支持各个客户端对接;
  • 报文的格式设计,好的报文格式能提升编码和解码效率;
  • 降低开发成本,考虑注册中心和负载均衡,让框架和RPC紧密结合,减少业务层的开发负担;
  • 充分考虑分布式场景,比如事务超时,消息幂等等等问题;

之前在业务中也开发了一些RPC框架,以上便是我对RPC协议的简单总结,不过RPC框架对于性能的考虑可能不是那么重要,更多的是考虑便利性,我们只需要把底层网络框架设计的足够高性能,并且选择与业务匹配的网络协议,这样基本能满足大部分业务需求。

延伸 · 阅读

精彩推荐