一、ECS云服务器第七代高主频功能特性 阿里云ECS云服务器第七代高主频ECS云服务器各项指标全新升级： 计算性能提升260%：基于最新一代CPU，内存带宽大幅提升 存储延时下降70%：存储转发性能提升2倍，延迟进入微妙时代 网络转发2400万PPS：全面升级50GX2物理网络，容器网卡密度提升6倍，网络传输效率提升5倍 高稳定性SLA达99.995%：硬件级别QOS能力，性能抖动低 二、ECS云服务器第七代高主频性能参数 第七代高主频ECS云服务器拥有更强大的算力、更高的IO性能、更低的延时、更弹性的体验： 计算能力 基于最新一代CPU 支持3200Mhz内存， 进一步降低内存延迟 整机算力比第六代提升2.6倍 稳定性 单实例：99.975% 单地域多可用区部署： 99.995% 轻量虚拟化技术， 进一步降低计算性能抖动 硬件级别QOS能力， 多级调度， 业务更加稳定 网络能力 IO能力提升近3倍， 最高支持2400W PPS 带宽提升1倍以上, 小规格支持10Gbps突发带宽 平均低载延时最多下降20%以上 支持大帧传输， 传输效率提升近5倍 Trunking模式下网卡密度最多提升6倍，容器部署密度大幅提升 存储能力 转发性能提升2倍， 达60万 iops 吞吐提升1倍， 达4GB 整体延迟最多下降70% ESSD写延迟最多下降20% 三、第七代高主频典型业务场景 阿里云第七代高主频ECS实例强劲的整机算力配合领先的IO转发能力，为高性能计算场景提供业界领先的性价比和稳定性： EDA设计 高主频算力支撑，提升EDA软件设计效率，缩短研发周期，帮助企业节约成本、提升效益。 在线游戏 强劲的CPU编解码处理能力和网络转发能力，可以有效减少延迟和卡顿，提升玩家用户体验。 基因分析 基因测序的海量数据分析场景，往往需要通过各种类型生物信息学Pipeline对原始数据进行分析，而这些Pipeline中的软件对计算资源要求很高。通过大算力实例提升分析时效，可有效提升基因分析效率。 远程教育 教学视频编解码、转发以及大量的在线并发，对于实例提出了算力和稳定性的要求，高主频实例可以很好地支撑远程教育场景应用，提升用户使用教学平台的体验。 四、第七代高主频硬核技术 第七代ECS云服务器基于第三代神龙平台 芯片实现IO引擎：更高性能、更低延迟、更低抖动性 硬件级QoS管理：多级调度的网络和存储QoS，多维度精准调度 增强型融合网络：2x50GbE双上联网络，近裸机低延迟网络 增强型硬件队列：1024存储队列+1024网络队列，更强的隔离性本文仅供参考，关于阿里云ECS云服务器第七代高主频实例详细信息请以官方文档为准：ECS云服务器第七代高主频实例配置性能性详解 - 阿里云  

随着互联网的快速发展，基础网络环境也在发生变化，WEB网络协议也经历了HTTP1.0、HTTP1.1、HTTP2.0以及即将迎来HTTP3.0; HTTP3.0将以QUIC协议替代TCP作为传输层，具备stream多路复用、握手0RTT、连接迁移以及用户态拥塞算法诸多优势。CDN产品关注QUIC协议演进并实践落地，从gQUIC协议到标准IETF QUIC协议已经部署在CDN边缘节点，并在短视频和图片业务场景实践有不错的收益。在1月12日的「阿里云CDN产品发布会-新一代传输协议QUIC让CDN更快一步」之上，阿里云技术专家淮叶分享了QUIC技术及其应用落地实践。本文根据分享内容梳理，包括以下三个部分：QUIC协议介绍，包括协议诞生历史、基础特性、相比TCP有哪些优势，以及QUIC协议可以应用在哪些业务场景CDN QUIC技术落地实践，包括协议库选择，QUIC协议软件实现以及QUIC落地技术架构，以及QUIC性能优化，QUIC产品如何接入使用CDN QUIC技术落地场景，主要介绍阿里巴巴集团业务使用QUIC加速后的收益，以及背后的一些优化措施QUIC协议介绍当我们访问视频网站和APP应用时，经常会遇到各种各样的性能问题，网页加载慢、视频卡顿、网络出错，其中关键影响因素就是网络协议。HTTP 协议作为互联网web协议，经历了几次重要的升级：HTTP1.0 -> HTTP1.1：支持长连接，请求pipeline特性，通过减少了TCP三次握手，降低连接建立的开销HTTP -> HTTPS：增加TLS层握手，传输内容加解密，因增加安全特性，故增加建连延迟HTTP1.1 -> HTTP2：H2特性是请求数据流的多路复用与头部压缩，提高了单连接的并发能力从HTTP1.0升级到HTTP2，其中传输层协议没有变化都是基于TCP协议。TCP协议是可靠传输协议，需要三次握手状态，还有队头阻塞问题，为了解决这些问题，基于UDP设计实现的一种可靠传输协议——QUIC协议应运而生。因此，HTTP协议再次升级。HTTP2->HTTP3：HTTP3基于QUIC协议，因此具备QUIC协议的传输特性，解决TCP队头阻塞问题，具备TLS1.30-RTT、H2多路复用能力，还具备连接迁移能力。QUIC协议已于2021年5月正式标准化，编号为RFC9000。QUIC 协议解决了哪些问题1. 低连接延时QUIC 基于 UDP，无需 TCP 连接，最好情况下，QUIC 可以做到 0RTT 开启数据传输。而基于 TCP 的 HTTPS，即使在TLS1.3的early data下仍然需要 1RTT 开启数据传输。然而对于常见的 TLS1.2 完全握手的情况，则需要 3RTT 开启数据传输。2. 无队头阻塞虽然 HTTP2 实现了多路复用，但是传输层依然使用的是TCP，一旦出现某个报文丢包，将会影响多路复用下的所有请求流。然而QUIC 基于 UDP，在设计上就解决了队头阻塞问题。同时HTTP3使用 QPACK 编码替换 HPACK 编码，在一定程度上也减轻了 HTTP 请求头的队头阻塞问题。3. 用户态拥塞控制QUIC 的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上。这意味着可以根据不同的业务场景，实现配置不同的拥塞控制算法以及参数，甚至同一个业务的不同QUIC连接也可以使用不同的拥塞控制算法。4. 连接迁移当实际用户的网络发生变化时，从 WIFI 网络切换到 4G 网络时，用户地址发生变化，基于 TCP 的 HTTP 协议无法保持连接的存活；而QUIC 基于连接 CID 作为连接标识, 仍然可以保证连接存活和数据正常收发。QUIC协议与TCP协议对比既然QUIC协议设计初衷是解决传输层协议问题，与其竞对的就是TCP协议，那么从传输协议特性分析两种协议设计差异，可得出以下对比：QUIC为每个加密级别使用单独的包号空间，除了0-RTT和1-RTT密钥使用相同的包号空间，隔离的包号空间可以确保使用一种加密级别发送包的ACK, 不会引起使用其他加密级别发送的包的虚假重传问题。QUIC的包号严格按照包号空间递增，直接编码传输顺序。报文号越高表示报文发送时间越晚，报文号越低表示报文发送时间越早。当一个包含应答帧的包被检测到丢失时，QUIC会在一个新的包中包含必要的帧，并添加一个新的包号，从而消除了当收到应答时确认哪个包的不确定性。因此，可以进行更精确的进行RTT测量，可以轻松地检测到虚假重传。Quicack帧包含类似于TCP选择性应答(sack)的信息。然而QUIC不允许数据包的确认被违背，这大大简化了双方的实现，并降低了发送方的内存压力。与TCP的三个SACK范围相反，QUIC支持许多ACK范围。在高丢包环境中，这种方法可以加快恢复速度，减少虚假重传。TCPRTT测量使用发送包和确认包时间戳计算，未考虑主机延迟问题，QUIC使用ACKDelay机制，使得路径RTT测量更加准确。QUIC使用PTO探测超时机制，代替TCP的RTO&TLP。TCP使用一个包的最小拥塞窗口。如果丢失单个数据包意味着发送方需要等待PTO来恢复，当接收方延迟确认时，发送一个单一的ack-eliciting包也增加了引起额外延迟。因此，QUIC建议最小拥塞窗口为两个包。虽然这增加了网络负载，但它被认为是安全的，因为在持续拥塞的情况下，发送方仍然会以指数方式降低发送速率。QUIC协议可以加速哪些场景动态请求(API和信令传输场景)：降低动态交互耗时短视频：提升首屏秒开率，降低卡顿率图片文件下载：降低文件下载总耗时直播：降低播放卡顿率，提升推流稳定性CDN QUIC技术落地实践关于协议库如何选择？QUIC 协议栈的实现版本库很多，但协议功能实现的全面性各有不同，通过QUIC协议互通性测试报告，可以了解各协议库的QUIC特性支持程度。CDN在QUIC协议上的实践路线，是从gQUIC版本开始调研实现，然后跟进QUIC标准化进度，然后支持 IETFQUIC标准，并实现HTTP3接入服务。选择gQUIC的原因是GOOGLE是QUIC协议的开创者，基于chromium实现的QUIC协议栈最早，功能最齐，实现上也最为标准，因此选择了它。关于IETFQUIC协议版本，NGINX官方已实现了一个基础版本，生产环境使用仍然存在很多问题没解决，拥塞控制算法没有实现；但从QUIC协议互通测试报告看，QUIC协议实现比较全面，并且性能也不错，相信NGINX官方很快就会把QUIC分支合入主干。同时，补全了其缺失功能，比如拥塞算法。gQUIC&IETFQUIC兼容架构我们选择了两套不同的QUIC协议栈实现版本，来分别支持gQUIC和IETFQUIC，其中gQUIC版本支持Q039,Q043,Q046，IETFQUIC支持h3-29quicv1。gQUIC协议库，自从2018年调研嵌入到CDN服务，我们从chromium裁剪出net网络库部分，开发QUIC模块，以及自研拥塞算法。随着IETFQUIC协议草案逐渐成熟，2020年RFC草案基本定稿，CDN也开始IETFQUIC实现调研，我们基于NGINX官方QUIC版本进行深度开发，解决QUIC加密库、拥塞算法、资源运维等问题，达到CDN上线标准。现在CDN QUIC同时支持gQUIC和IETFQUIC两种版本，客户接入无需更换域名，更换调度域。（CDN实现已经做了协议分流）CDN QUIC技术架构实现技术架构实现分为两个组件：QUIC-LB 和 QUIC-ServerQUIC-LB: 主要实现根据QUIC连接CID选择后端QUIC-Server逻辑QUIC-Server：实现QUIC协议栈特性，并且根据连接CID选择已建立会话的worker进行服务在 CDN QUIC 技术落地实践中，我们面临一个难题是QUIC传输带来的CPU资源损耗高于TCP协议栈的CPU消耗，QUIC 协议将 TCP协议栈 的特性从内核移到了应用层，从目前开源 QUIC 实现版本来看，性能相比 TCP 还有差距。因为TCP长期使用以来，从协议栈到网卡经过了非常多的优化，相比之下，UDP的优化很少。除了内核和硬件外，QUIC 协议的性能也与其实现有关，不同的实现版本可能也会有很大的差距。所以对 QUIC 的传输性能，通过火焰图进行分析，找出了一些影响 QUIC 性能的关键点：SSL加密算法的开销：对称加解密也10%左右的开销；优化措施，不同场景选择不同加密算法，实验环境下对各加密算法进行性能测试，AES在cpu 指令优化下，性能提升20%，chacha20针对移动端有优化UDP 收发包的开销：针对大文件下载的情况，sendmsg占比很高，可以达到 30%以上；优化措施，开启GSO模式，相比单包发送，性能提升2-3倍QUIC协议栈开销：受协议栈自身实现的影响，如 ACK 的处理，MTU 探测和发包大小，内存拷贝等；优化措施，ACK 合并、调整udp payload sizeCDN QUIC协议如何接入使用1.CDN控制台，先申请开通，用户即可自助开启、关闭QUIC2.测试工具，浏览器或者一些QUIC开源库工具，curl已经支持HTTP33.QUIC监控，可以从CDN内部监控系统查看QUIC连接异常问题4.QUIC分析工具，wireshark最新版本已经支持QUIC协议分析CDN QUIC产品的应用效果CDN QUIC在阿里巴巴集团的一些业务上已经实践落地并取得了一些效果。例如：淘宝短视频业务在开启HTTP3后，客户端分片下载耗时下降 20%，播放器卡顿率下降 10%；支付宝图片下载业务在开启gQUIC后，小程序包下载耗时下降 25%，整体业务下载耗时下降 40%。从不同业务实践中，CDN QUIC服务针对业务场景进行了全面优化，包括4个方面：连接优化0-RTT连接复用率，降低连接的延迟。加解密优化明文传输，可以减少加解密造成的一些影响。传输优化乱序报文缓存，针对特殊数据优先级需求进行调整。针对线上的不同业务场景调整参数，利用拥塞算法，提升在不同业务场景下的效果。附录[1] HTTP1.0: https://datatracker.ietf.org/doc/html/rfc1945[2] HTTP1.1: https://datatracker.ietf.org/doc/html/rfc2616[3] HTTP Over TLS: https://datatracker.ietf.org/doc/html/rfc2818[4] HTTP/2: https://datatracker.ietf.org/doc/html/rfc7540[5] HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-quic-http[6] QUIC工作组文档集：https://quicwg.org/[7] chromium项目: https://chromium.googlesource.com/chromium/[8] nginx-quic项目: https://quic.nginx.org/[9] quic协议互通性测试站点：https://interop.seemann.io/点击回顾发布会直播：https://yqh.aliyun.com/live/quic 了解更多详情。

6. TCP与UDP的区别TCP 面向连接，UDP 是无连接的；TCP 提供可靠的服务，也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP 尽最大努力交付，即不保证可靠交付TCP 的逻辑通信信道是全双工的可靠信道；UDP 则是不可靠信道每一条 TCP 连接只能是点到点的；UDP 支持一对一，一对多，多对一和多对多的交互通信TCP 面向字节流（可能出现黏包问题），实际上是 TCP 把数据看成一连串无结构的字节流；UDP 是面向报文的（不会出现黏包问题）UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）TCP 首部开销20字节；UDP 的首部开销小，只有 8 个字节7.TCP的可靠性如何保证？确认和超时重传数据合理分片和排序流量控制拥塞控制数据校验10.  在浏览器中输入www.baidu.com后执行的全部过程现在假设如果我们在客户端（客户端）浏览器中输入http://www.baidu.com,而baidu.com为要访问的服务器（服务器），下面详细分析客户端为了访问服务器而执行的一系列关于协议的操作：  1、客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器，发起一个HTTP会话到220.181.27.48，然后通过TCP进行封装数据包，输入到网络层。  2、在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。  3、客户端的网络层不用关系应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，我不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。  4、客户端的链路层，包通过链路层发送到路由器，通过邻居协议【ARP协议】查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。

1. OSI，TCP/IP，五层协议的体系结构OSI分层（7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。TCP/IP分层（4层）：网络接口层、网际层、运输层、应用层。五层协议（5层）：物理层、数据链路层、网络层、运输层、应用层。每一层的作用如下：物理层：激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。该层为上层协议提供了一个传输数据的物理媒体。数据链路层：数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。网络层：网络层负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能。传输层：第一个端到端，即主机到主机的层次。传输层负责将上层数据分段 并 提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。会话层：会话层管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。表示层：表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。应用层：为操作系统或网络应用程序提供访问网络服务的接口。2. IP地址的分类A类地址：以0开头，第一个字节范围：0~127；B类地址：以10开头，第一个字节范围：128~191；C类地址：以110开头，第一个字节范围：192~223；D类地址：以1110开头，第一个字节范围为224~239；3. ARP协议的工作原理首先，每台主机都会在自己的ARP缓冲区中建立一个 ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址：如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括：源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址；源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。4. 路由设备与相关层物理层：中继器（Repeater，也叫放大器），集线器。数据链路层：网桥，交换机。网络层：路由器。网络层以上的设备：网关5.常见的路由选择协议，以及它们的区别常见的路由选择协议有：RIP协议、OSPF协议。RIP协议：路由信息协议, 底层是贝尔曼福特算法，它选择路由的度量标准（metric)是跳数，最大跳数是15跳，如果大于15跳，它就会丢弃数据包。OSPF协议：开放最短路径优先,  底层是迪杰斯特拉算法，是链路状态路由选择协议，它选择路由的度量标准是带宽，延迟。VPN 和 NATVPN（Virtual Private Network，虚拟专用网）NAT（Network Address Translation，网络地址转换）

随着互联网飞速发展，用户通过手机看到的内容越来越多，交互形式也愈发丰富。用户对于网络的响应、网络的传输效率提出了更高的要求。传统的TCP传输方式存在一些问题，比如：依赖于操作系统的实现，部署和升级的周期很长；握手时延无法避免；传输效率上会存在对头阻塞等等，这些问题是无法解决的。基于此，QUIC应运而生并且不断发展演进。QUIC全称Quick UDP Internet Connection，一种基于UDP实现可靠传输的低延时互联网传输协议。那么QUIC如何在CDN中应用？其技术应用场景可以为业务带来什么样的价值？1月12日，阿里云产品发布会154期，阿里云CDN重磅升级，为网友揭秘了新一代传输协议QUIC如何让CDN更快一步。QUIC 发展史回顾首先，让我们一起来回顾下QUIC的发展历史。QUIC是从2013年google开始基于UDP协议的一个研究，在经过2013年到2015年的一些公开的试验之后，2016年提交给IETF，也就是互联网标准，进行整体协议的标准化。众所周知，QUIC具备很多的优势，比如RTT、0RTT多路复用等，比较关键是它实现了从内核态到用户态的转变，整个算法的迭代从可以通过应用层去完成，实现一客一用，极大提升了更新效率。IETF QUIC最终在2021年7月份完成定稿，命名为RFC9000。QUIC时代，现在开始正式到来。阿里云CDN QUIC的演进阿里云CDN团队在2018年开始进行QUIC相关调研和支持，且在2019年已经支持了google QUIC的相关内容，包括google的比较广泛的版本，比如3943和46版本已经在支持。在2020年，随着IETF QUIC整个标准化进展加快，阿里云CDN也开始在对IETF QUIC进行兼容和适配。在2021年，阿里云CDN全部物理节点均支持IETF QUIC。为什么大家对QUIC会得到这么多的关注呢？通过互联网一些通用的场景，阿里云CDN产品专家容蓓介绍了QUIC的优势和其与TCP之间的差异化价值。QUIC 在CDN中的应用短视频是CDN加速的经典场景之一。对于平台而言，希望给用户创造更好的观看体验，视频卡顿、延迟都是不利因素，平台会监控播放完成率、互动率等指标，用于评估短视频是否具备吸引力。拆分到技术层面，要看一个视频平台技术好不好，指标就包括首屏时间、卡顿率、下载速率等等。QUIC为什么会在这些核心指标上面比TCP的效果更好？我们逐一来看。第一，首屏时间通常是指用户观看到视频或者是观看到图片的第一帧的时间。这个时间越快、延迟越小，用户的体感就会越好，就不会有延迟。从下图中里面来看到。如果通过HTTP的协议去访问视频，会有一次建联，建联之后再进行数据传输。此外，因为HTTP是明文传输，可能存在如数据篡改、劫持的风险，所以在客户端，大家倾向于选择使用HTTPS来传输。而HTTPS因为有证书存在，它的握手又会增加，至少要通过三个RTT才能获取到第一帧的内容。假设平均的握手时间是200毫秒，那这200毫秒首屏延迟是完全无法避免的。并且，在这一次访问结束之后，这个连接会关闭。下一次用户再访问同样的东西时，又要再去建联，这就意味着200毫秒是持续存在的，在TCP里面没有办法改善。而因为QUIC用的是这个UDP的协议，它的建联方式会更优化一些。QUIC中的握手从第一次开始就是加密的状态，第二次就可以传输一个数据，所以在QUIC中，用户第一次访问一个资源，那么需要一个RTT，就可以获取到数据内容。而再次访问同样的内容，数据如果已经存在本地，无需再建联，就能实现0RTT的逻辑。当然，首屏时间也会有其他的影响因素，但是这三个握手时间的节省，确实是QUIC在首屏时间上能拿到的实打实的性能提升。第二，在传输层面上，QUIC也比TCP相对改进。从下图中可以看到，假设TCP在传三张图片，会把它分成不同的报文去进行传输。图一是TCP的传输方式，可以看到1234报文都被成功传输完了，应用层也可以读取到客户端并进行展示了，那么5的报文丢掉了，实际上6789在服务端也已经传成功了，但因为5丢掉了，所以678应用层都是没有办法去接收的，必须要等到5重传之后，后面的数据才能被传完。在QUIC里面，通过多路复用的方式来进行数据传输，也就意味着1234传输成功之后，5丢掉了，678依旧可以被传输过去。这几个报文数据包中只有5需要重传，其他的都可以被应用层读取。那么在相同的网络吞吐量的前提下，在相同时间内会传更多的内容。所以，QUIC在下载耗时、卡顿率这个层面，会取得比较大的优势。第三，拥塞机制。QUIC基本上继承了TCP的拥塞算法在里边。但为什么QUIC会要比TCP的优势更明显呢？那是因为QUIC的控制层在应用层，应用层最大特性就是很灵活，比如说我客户A去配cubic，客户B去配BBR，这个都只需要在服务端去做一个配置，然后几个小时、几分钟快速生效。在TCP里边，整个算法的优化需要在内核层中去做更新，更新是非常缓慢和慎重的，并且内核层面部署时间、发布时间都很长。举个栗子，我们要把阿里云CDN 2800个节点的内核层都更新一次，这个时间是非常漫长的，并且可能会存在一些不可控的因素在里面。所以QUIC协议在拥塞控制层面非常灵活，这也是它的核心优势之一。第四，弱网优化。其实这也跟QUIC的建联方式有关系。TCP如果要建联，会有四要素，就是客户端这个源IP、端口，服务端的目的IP、目的端口。通常目的IP和目的端口相对来讲比较稳定，不太容易发生变化。但是源IP这一侧就不一定了。网络变了、设备变了都会导致IP和端口的变化，在发生变化之后，哪怕我们看的都是同样的内容，也肯定要重新建联。那么刚刚提到的TCP的握手又出来了，产生了中间的消耗和不确定性。那么，QUIC的建联方式是通过一个connection ID来完成的，connection ID是一个64位的随机数，相对更灵活。无论网络发生什么变化，只要connection ID不变，那连接就不会断掉，这就保证了用户在观看同样内容时更加顺畅，性能体感更好。阿里巴巴集团应用在QUIC在CDN的实践上已经取得了一些效果，比如：手淘今年双11已经将部分流量切到了IETF QUIC之上，短视频业务卡顿率比TCP降低10%，下载分片耗时降低20%；优酷长视频业务，平均播放卡顿时长降低15% - 32.5%（强弱网区分）；支付宝图片业务使用google QUIC，下载耗时降低25% - 40%以上。总结：QUIC的核心优势第一、快速建联0-RTT的握手，减少TCP握手和TLS的握手时间，提升首屏效率第二、多路复用相比于HTTP/2，真正的单通道并行传输，彻底解决TCP协议中队头阻塞问题第三、拥塞算法拥塞算法灵活，不需要基于内核或操作系统，可直接在应用层改造第四、持续在线频繁切换网络的情况下，不会断线，不需要重连，用户无任何感知如何开通CDN QUIC服务通过阿里云CDN控制台，在每个域名配置下都会有QUIC选项。如果用户已经申请过了白名单，即可直接操控开关来开启或者关闭QUIC服务。没有申请过白名单的用户则需要提交申请，后台审核通过后即可通过控制台来进行操控。在域名开启之后，用户可以在资源监控中选择相关的协议层，查看QUIC相关数据。同时，QUIC会按照每万次五分钱的一个计费逻辑按日出账，用户可以在用量中查询QUIC的请求数的总数量，来进行账单的核对。其他内容CDN产品关注QUIC协议演进并实践落地，从gQUIC协议到标准IETF QUIC协议已经部署在CDN边缘节点，并在短视频和图片业务场景实践有不错的收益。在发布会中，阿里云技术专家淮叶也带来了关于QUIC技术基础特性、应用场景及其技术落地实践中的协议库选择、QUIC协议软件实现、性能优化的内容分享。点击回顾发布会直播：https://yqh.aliyun.com/live/quic 了解更多详情。

从今天开始我们来聊聊Netty的那些事儿，我们都知道Netty是一个高性能异步事件驱动的网络框架。它的设计异常优雅简洁，扩展性高，稳定性强。拥有非常详细完整的用户文档。同时内置了很多非常有用的模块基本上做到了开箱即用，用户只需要编写短短几行代码，就可以快速构建出一个具有高吞吐，低延时，更少的资源消耗，高性能（非必要的内存拷贝最小化）等特征的高并发网络应用程序。本文我们来探讨下支持Netty具有高吞吐，低延时特征的基石----netty的网络IO模型。由Netty的网络IO模型开始，我们来正式揭开本系列Netty源码解析的序幕：网络包接收流程 当网络数据帧通过网络传输到达网卡时，网卡会将网络数据帧通过DMA的方式放到环形缓冲区RingBuffer中。RingBuffer是网卡在启动的时候分配和初始化的环形缓冲队列。当RingBuffer满的时候，新来的数据包就会被丢弃。我们可以通过ifconfig命令查看网卡收发数据包的情况。其中overruns数据项表示当RingBuffer满时，被丢弃的数据包。如果发现出现丢包情况，可以通过ethtool命令来增大RingBuffer长度。当DMA操作完成时，网卡会向CPU发起一个硬中断，告诉CPU有网络数据到达。CPU调用网卡驱动注册的硬中断响应程序。网卡硬中断响应程序会为网络数据帧创建内核数据结构sk_buffer，并将网络数据帧拷贝到sk_buffer中。然后发起软中断请求，通知内核有新的网络数据帧到达。sk_buff缓冲区，是一个维护网络帧结构的双向链表，链表中的每一个元素都是一个网络帧。虽然 TCP/IP 协议栈分了好几层，但上下不同层之间的传递，实际上只需要操作这个数据结构中的指针，而无需进行数据复制。内核线程ksoftirqd发现有软中断请求到来，随后调用网卡驱动注册的poll函数，poll函数将sk_buffer中的网络数据包送到内核协议栈中注册的ip_rcv函数中。每个CPU会绑定一个ksoftirqd内核线程专门用来处理软中断响应。2个 CPU 时，就会有 ksoftirqd/0 和 ksoftirqd/1这两个内核线程。这里有个事情需要注意下： 网卡接收到数据后，当DMA拷贝完成时，向CPU发出硬中断，这时哪个CPU上响应了这个硬中断，那么在网卡硬中断响应程序中发出的软中断请求也会在这个CPU绑定的ksoftirqd线程中响应。所以如果发现Linux软中断，CPU消耗都集中在一个核上的话，那么就需要调整硬中断的CPU亲和性，来将硬中断打散到不通的CPU核上去。在ip_rcv函数中也就是上图中的网络层，取出数据包的IP头，判断该数据包下一跳的走向，如果数据包是发送给本机的，则取出传输层的协议类型（TCP或者UDP)，并去掉数据包的IP头，将数据包交给上图中得传输层处理。传输层的处理函数：TCP协议对应内核协议栈中注册的tcp_rcv函数，UDP协议对应内核协议栈中注册的udp_rcv函数。当我们采用的是TCP协议时，数据包到达传输层时，会在内核协议栈中的tcp_rcv函数处理，在tcp_rcv函数中去掉TCP头，根据四元组（源IP，源端口，目的IP，目的端口）查找对应的Socket，如果找到对应的Socket则将网络数据包中的传输数据拷贝到Socket中的接收缓冲区中。如果没有找到，则发送一个目标不可达的icmp包。内核在接收网络数据包时所做的工作我们就介绍完了，现在我们把视角放到应用层，当我们程序通过系统调用read读取Socket接收缓冲区中的数据时，如果接收缓冲区中没有数据，那么应用程序就会在系统调用上阻塞，直到Socket接收缓冲区有数据，然后CPU将内核空间（Socket接收缓冲区）的数据拷贝到用户空间，最后系统调用read返回，应用程序读取数据。性能开销 从内核处理网络数据包接收的整个过程来看，内核帮我们做了非常之多的工作，最终我们的应用程序才能读取到网络数据。随着而来的也带来了很多的性能开销，结合前面介绍的网络数据包接收过程我们来看下网络数据包接收的过程中都有哪些性能开销：应用程序通过系统调用从用户态转为内核态的开销以及系统调用返回时从内核态转为用户态的开销。网络数据从内核空间通过CPU拷贝到用户空间的开销。内核线程ksoftirqd响应软中断的开销。CPU响应硬中断的开销。DMA拷贝网络数据包到内存中的开销。网络包发送流程 当我们在应用程序中调用send系统调用发送数据时，由于是系统调用所以线程会发生一次用户态到内核态的转换，在内核中首先根据fd将真正的Socket找出，这个Socket对象中记录着各种协议栈的函数地址，然后构造struct msghdr对象，将用户需要发送的数据全部封装在这个struct msghdr结构体中。调用内核协议栈函数inet_sendmsg，发送流程进入内核协议栈处理。在进入到内核协议栈之后，内核会找到Socket上的具体协议的发送函数。比如：我们使用的是TCP协议，对应的TCP协议发送函数是tcp_sendmsg，如果是UDP协议的话，对应的发送函数为udp_sendmsg。在TCP协议的发送函数tcp_sendmsg中，创建内核数据结构sk_buffer,将struct msghdr结构体中的发送数据拷贝到sk_buffer中。调用tcp_write_queue_tail函数获取Socket发送队列中的队尾元素，将新创建的sk_buffer添加到Socket发送队列的尾部。Socket的发送队列是由sk_buffer组成的一个双向链表。发送流程走到这里，用户要发送的数据总算是从用户空间拷贝到了内核中，这时虽然发送数据已经拷贝到了内核Socket中的发送队列中，但并不代表内核会开始发送，因为TCP协议的流量控制和拥塞控制，用户要发送的数据包并不一定会立马被发送出去，需要符合TCP协议的发送条件。如果没有达到发送条件，那么本次send系统调用就会直接返回。如果符合发送条件，则开始调用tcp_write_xmit内核函数。在这个函数中，会循环获取Socket发送队列中待发送的sk_buffer，然后进行拥塞控制以及滑动窗口的管理。将从Socket发送队列中获取到的sk_buffer重新拷贝一份，设置sk_buffer副本中的TCP HEADER。sk_buffer 内部其实包含了网络协议中所有的 header。在设置 TCP HEADER的时候，只是把指针指向 sk_buffer的合适位置。后面再设置 IP HEADER的时候，在把指针移动一下就行，避免频繁的内存申请和拷贝，效率很高。为什么不直接使用Socket发送队列中的sk_buffer而是需要拷贝一份呢？因为TCP协议是支持丢包重传的，在没有收到对端的ACK之前，这个sk_buffer是不能删除的。内核每次调用网卡发送数据的时候，实际上传递的是sk_buffer的拷贝副本，当网卡把数据发送出去后，sk_buffer拷贝副本会被释放。当收到对端的ACK之后，Socket发送队列中的sk_buffer才会被真正删除。当设置完TCP头后，内核协议栈传输层的事情就做完了，下面通过调用ip_queue_xmit内核函数，正式来到内核协议栈网络层的处理。检查Socket中是否有缓存路由表，如果没有的话，则查找路由项，并缓存到Socket中。接着在把路由表设置到sk_buffer中。通过route命令可以查看本机路由配置。将sk_buffer中的指针移动到IP头位置上，设置IP头。执行netfilters过滤。过滤通过之后，如果数据大于 MTU的话，则执行分片。如果你使用 iptables配置了一些规则，那么这里将检测是否命中规则。 如果你设置了非常复杂的 netfilter 规则，在这个函数里将会导致你的线程 CPU 开销会极大增加。内核协议栈网络层的事情处理完后，现在发送流程进入了到了邻居子系统，邻居子系统位于内核协议栈中的网络层和网络接口层之间，用于发送ARP请求获取MAC地址，然后将sk_buffer中的指针移动到MAC头位置，填充MAC头。经过邻居子系统的处理，现在sk_buffer中已经封装了一个完整的数据帧，随后内核将sk_buffer交给网络设备子系统进行处理。网络设备子系统主要做以下几项事情：选择发送队列（RingBuffer）。因为网卡拥有多个发送队列，所以在发送前需要选择一个发送队列。将sk_buffer添加到发送队列中。循环从发送队列（RingBuffer）中取出sk_buffer，调用内核函数sch_direct_xmit发送数据，其中会调用网卡驱动程序来发送数据。以上过程全部是用户线程的内核态在执行，占用的CPU时间是系统态时间(sy)，当分配给用户线程的CPU quota用完的时候，会触发NET_TX_SOFTIRQ类型的软中断，内核线程ksoftirqd会响应这个软中断，并执行NET_TX_SOFTIRQ类型的软中断注册的回调函数net_tx_action，在回调函数中会执行到驱动程序函数 dev_hard_start_xmit来发送数据。注意：当触发NET_TX_SOFTIRQ软中断来发送数据时，后边消耗的 CPU 就都显示在 si这里了，不会消耗用户进程的系统态时间（sy）了。从这里可以看到网络包的发送过程和接受过程是不同的，在介绍网络包的接受过程时，我们提到是通过触发NET_RX_SOFTIRQ类型的软中断在内核线程ksoftirqd中执行内核网络协议栈接受数据。而在网络数据包的发送过程中是用户线程的内核态在执行内核网络协议栈，只有当线程的CPU quota用尽时，才触发NET_TX_SOFTIRQ软中断来发送数据。在整个网络包的发送和接受过程中，NET_TX_SOFTIRQ类型的软中断只会在发送网络包时并且当用户线程的CPU quota用尽时，才会触发。剩下的接受过程中触发的软中断类型以及发送完数据触发的软中断类型均为NET_RX_SOFTIRQ。 所以这就是你在服务器上查看 /proc/softirqs，一般 NET_RX都要比 NET_TX大很多的的原因。现在发送流程终于到了网卡真实发送数据的阶段，前边我们讲到无论是用户线程的内核态还是触发NET_TX_SOFTIRQ类型的软中断在发送数据的时候最终会调用到网卡的驱动程序函数dev_hard_start_xmit来发送数据。在网卡驱动程序函数dev_hard_start_xmit中会将sk_buffer映射到网卡可访问的内存 DMA 区域，最终网卡驱动程序通过DMA的方式将数据帧通过物理网卡发送出去。当数据发送完毕后，还有最后一项重要的工作，就是清理工作。数据发送完毕后，网卡设备会向CPU发送一个硬中断，CPU调用网卡驱动程序注册的硬中断响应程序，在硬中断响应中触发NET_RX_SOFTIRQ类型的软中断，在软中断的回调函数igb_poll中清理释放 sk_buffer，清理网卡发送队列（RingBuffer），解除 DMA 映射。无论硬中断是因为有数据要接收，还是说发送完成通知，从硬中断触发的软中断都是 NET_RX_SOFTIRQ。这里释放清理的只是sk_buffer的副本，真正的sk_buffer现在还是存放在Socket的发送队列中。前面在传输层处理的时候我们提到过，因为传输层需要保证可靠性，所以 sk_buffer其实还没有删除。它得等收到对方的 ACK 之后才会真正删除。性能开销 前边我们提到了在网络包接收过程中涉及到的性能开销，现在介绍完了网络包的发送过程，我们来看下在数据包发送过程中的性能开销：和接收数据一样，应用程序在调用系统调用send的时候会从用户态转为内核态以及发送完数据后，系统调用返回时从内核态转为用户态的开销。用户线程内核态CPU quota用尽时触发NET_TX_SOFTIRQ类型软中断，内核响应软中断的开销。网卡发送完数据，向CPU发送硬中断，CPU响应硬中断的开销。以及在硬中断中发送NET_RX_SOFTIRQ软中断执行具体的内存清理动作。内核响应软中断的开销。内存拷贝的开销。我们来回顾下在数据包发送的过程中都发生了哪些内存拷贝：在内核协议栈的传输层中，TCP协议对应的发送函数tcp_sendmsg会申请sk_buffer，将用户要发送的数据拷贝到sk_buffer中。在发送流程从传输层到网络层的时候，会拷贝一个sk_buffer副本出来，将这个sk_buffer副本向下传递。原始sk_buffer保留在Socket发送队列中，等待网络对端ACK，对端ACK后删除Socket发送队列中的sk_buffer。对端没有发送ACK，则重新从Socket发送队列中发送，实现TCP协议的可靠传输。在网络层，如果发现要发送的数据大于MTU，则会进行分片操作，申请额外的sk_buffer，并将原来的sk_buffer拷贝到多个小的sk_buffer中。再谈(阻塞，非阻塞)与(同步，异步) 在我们聊完网络数据的接收和发送过程后，我们来谈下IO中特别容易混淆的概念：阻塞与同步，非阻塞与异步。网上各种博文还有各种书籍中有大量的关于这两个概念的解释，但是笔者觉得还是不够形象化，只是对概念的生硬解释，如果硬套概念的话，其实感觉阻塞与同步，非阻塞与异步还是没啥区别，时间长了，还是比较模糊容易混淆。所以笔者在这里尝试换一种更加形象化，更加容易理解记忆的方式来清晰地解释下什么是阻塞与非阻塞，什么是同步与异步。经过前边对网络数据包接收流程的介绍，在这里我们可以将整个流程总结为两个阶段：数据准备阶段： 在这个阶段，网络数据包到达网卡，通过DMA的方式将数据包拷贝到内存中，然后经过硬中断，软中断，接着通过内核线程ksoftirqd经过内核协议栈的处理，最终将数据发送到内核Socket的接收缓冲区中。数据拷贝阶段： 当数据到达内核Socket的接收缓冲区中时，此时数据存在于内核空间中，需要将数据拷贝到用户空间中，才能够被应用程序读取。阻塞与非阻塞 阻塞与非阻塞的区别主要发生在第一阶段：数据准备阶段。当应用程序发起系统调用read时，线程从用户态转为内核态，读取内核Socket的接收缓冲区中的网络数据。阻塞如果这时内核Socket的接收缓冲区没有数据，那么线程就会一直等待，直到Socket接收缓冲区有数据为止。随后将数据从内核空间拷贝到用户空间，系统调用read返回。从图中我们可以看出：阻塞的特点是在第一阶段和第二阶段都会等待。非阻塞阻塞和非阻塞主要的区分是在第一阶段：数据准备阶段。在第一阶段，当Socket的接收缓冲区中没有数据的时候，阻塞模式下应用线程会一直等待。非阻塞模式下应用线程不会等待，系统调用直接返回错误标志EWOULDBLOCK。当Socket的接收缓冲区中有数据的时候，阻塞和非阻塞的表现是一样的，都会进入第二阶段等待数据从内核空间拷贝到用户空间，然后系统调用返回。从上图中，我们可以看出：非阻塞的特点是第一阶段不会等待，但是在第二阶段还是会等待。同步与异步 同步与异步主要的区别发生在第二阶段：数据拷贝阶段。前边我们提到在数据拷贝阶段主要是将数据从内核空间拷贝到用户空间。然后应用程序才可以读取数据。当内核Socket的接收缓冲区有数据到达时，进入第二阶段。同步同步模式在数据准备好后，是由用户线程的内核态来执行第二阶段。所以应用程序会在第二阶段发生阻塞，直到数据从内核空间拷贝到用户空间，系统调用才会返回。Linux下的 epoll和Mac 下的 kqueue都属于同步 IO。异步异步模式下是由内核来执行第二阶段的数据拷贝操作，当内核执行完第二阶段，会通知用户线程IO操作已经完成，并将数据回调给用户线程。所以在异步模式下 数据准备阶段和数据拷贝阶段均是由内核来完成，不会对应用程序造成任何阻塞。基于以上特征，我们可以看到异步模式需要内核的支持，比较依赖操作系统底层的支持。在目前流行的操作系统中，只有Windows 中的 IOCP才真正属于异步 IO，实现的也非常成熟。但Windows很少用来作为服务器使用。而常用来作为服务器使用的Linux，异步IO机制实现的不够成熟，与NIO相比性能提升的也不够明显。但Linux kernel 在5.1版本由Facebook的大神Jens Axboe引入了新的异步IO库io_uring 改善了原来Linux native AIO的一些性能问题。性能相比Epoll以及之前原生的AIO提高了不少，值得关注。IO模型 在进行网络IO操作时，用什么样的IO模型来读写数据将在很大程度上决定了网络框架的IO性能。所以IO模型的选择是构建一个高性能网络框架的基础。在《UNIX 网络编程》一书中介绍了五种IO模型：阻塞IO,非阻塞IO,IO多路复用,信号驱动IO,异步IO，每一种IO模型的出现都是对前一种的升级优化。下面我们就来分别介绍下这五种IO模型各自都解决了什么问题，适用于哪些场景，各自的优缺点是什么？阻塞IO（BIO） 经过前一小节对阻塞这个概念的介绍，相信大家可以很容易理解阻塞IO的概念和过程。既然这小节我们谈的是IO，那么下边我们来看下在阻塞IO模型下，网络数据的读写过程。阻塞读当用户线程发起read系统调用，用户线程从用户态切换到内核态，在内核中去查看Socket接收缓冲区是否有数据到来。Socket接收缓冲区中有数据，则用户线程在内核态将内核空间中的数据拷贝到用户空间，系统IO调用返回。Socket接收缓冲区中无数据，则用户线程让出CPU，进入阻塞状态。当数据到达Socket接收缓冲区后，内核唤醒阻塞状态中的用户线程进入就绪状态，随后经过CPU的调度获取到CPU quota进入运行状态，将内核空间的数据拷贝到用户空间，随后系统调用返回。阻塞写当用户线程发起send系统调用时，用户线程从用户态切换到内核态，将发送数据从用户空间拷贝到内核空间中的Socket发送缓冲区中。当Socket发送缓冲区能够容纳下发送数据时，用户线程会将全部的发送数据写入Socket缓冲区，然后执行在《网络包发送流程》这小节介绍的后续流程，然后返回。当Socket发送缓冲区空间不够，无法容纳下全部发送数据时，用户线程让出CPU,进入阻塞状态，直到Socket发送缓冲区能够容纳下全部发送数据时，内核唤醒用户线程，执行后续发送流程。阻塞IO模型下的写操作做事风格比较硬刚，非得要把全部的发送数据写入发送缓冲区才肯善罢甘休。阻塞IO模型 由于阻塞IO的读写特点，所以导致在阻塞IO模型下，每个请求都需要被一个独立的线程处理。一个线程在同一时刻只能与一个连接绑定。来一个请求，服务端就需要创建一个线程用来处理请求。当客户端请求的并发量突然增大时，服务端在一瞬间就会创建出大量的线程，而创建线程是需要系统资源开销的，这样一来就会一瞬间占用大量的系统资源。如果客户端创建好连接后，但是一直不发数据，通常大部分情况下，网络连接也并不总是有数据可读，那么在空闲的这段时间内，服务端线程就会一直处于阻塞状态，无法干其他的事情。CPU也无法得到充分的发挥，同时还会导致大量线程切换的开销。适用场景 基于以上阻塞IO模型的特点，该模型只适用于连接数少，并发度低的业务场景。比如公司内部的一些管理系统，通常请求数在100个左右，使用阻塞IO模型还是非常适合的。而且性能还不输NIO。该模型在C10K之前，是普遍被采用的一种IO模型。非阻塞IO（NIO） 阻塞IO模型最大的问题就是一个线程只能处理一个连接，如果这个连接上没有数据的话，那么这个线程就只能阻塞在系统IO调用上，不能干其他的事情。这对系统资源来说，是一种极大的浪费。同时大量的线程上下文切换，也是一个巨大的系统开销。所以为了解决这个问题，我们就需要用尽可能少的线程去处理更多的连接。，网络IO模型的演变也是根据这个需求来一步一步演进的。基于这个需求，第一种解决方案非阻塞IO就出现了。我们在上一小节中介绍了非阻塞的概念，现在我们来看下网络读写操作在非阻塞IO下的特点：非阻塞读当用户线程发起非阻塞read系统调用时，用户线程从用户态转为内核态，在内核中去查看Socket接收缓冲区是否有数据到来。Socket接收缓冲区中无数据，系统调用立马返回，并带有一个 EWOULDBLOCK 或 EAGAIN错误，这个阶段用户线程不会阻塞，也不会让出CPU，而是会继续轮训直到Socket接收缓冲区中有数据为止。Socket接收缓冲区中有数据，用户线程在内核态会将内核空间中的数据拷贝到用户空间，注意这个数据拷贝阶段，应用程序是阻塞的，当数据拷贝完成，系统调用返回。非阻塞写前边我们在介绍阻塞写的时候提到阻塞写的风格特别的硬朗，头比较铁非要把全部发送数据一次性都写到Socket的发送缓冲区中才返回，如果发送缓冲区中没有足够的空间容纳，那么就一直阻塞死等，特别的刚。相比较而言非阻塞写的特点就比较佛系，当发送缓冲区中没有足够的空间容纳全部发送数据时，非阻塞写的特点是能写多少写多少，写不下了，就立即返回。并将写入到发送缓冲区的字节数返回给应用程序，方便用户线程不断的轮训尝试将剩下的数据写入发送缓冲区中。非阻塞IO模型 基于以上非阻塞IO的特点，我们就不必像阻塞IO那样为每个请求分配一个线程去处理连接上的读写了。我们可以利用一个线程或者很少的线程，去不断地轮询每个Socket的接收缓冲区是否有数据到达，如果没有数据，不必阻塞线程，而是接着去轮询下一个Socket接收缓冲区，直到轮询到数据后，处理连接上的读写，或者交给业务线程池去处理，轮询线程则继续轮询其他的Socket接收缓冲区。这样一个非阻塞IO模型就实现了我们在本小节开始提出的需求：我们需要用尽可能少的线程去处理更多的连接适用场景 虽然非阻塞IO模型与阻塞IO模型相比，减少了很大一部分的资源消耗和系统开销。但是它仍然有很大的性能问题，因为在非阻塞IO模型下，需要用户线程去不断地发起系统调用去轮训Socket接收缓冲区，这就需要用户线程不断地从用户态切换到内核态，内核态切换到用户态。随着并发量的增大，这个上下文切换的开销也是巨大的。所以单纯的非阻塞IO模型还是无法适用于高并发的场景。只能适用于C10K以下的场景。IO多路复用 在非阻塞IO这一小节的开头，我们提到网络IO模型的演变都是围绕着---如何用尽可能少的线程去处理更多的连接这个核心需求开始展开的。本小节我们来谈谈IO多路复用模型，那么什么是多路？，什么又是复用呢？我们还是以这个核心需求来对这两个概念展开阐述：多路：我们的核心需求是要用尽可能少的线程来处理尽可能多的连接，这里的多路指的就是我们需要处理的众多连接。复用：核心需求要求我们使用尽可能少的线程，尽可能少的系统开销去处理尽可能多的连接（多路），那么这里的复用指的就是用有限的资源，比如用一个线程或者固定数量的线程去处理众多连接上的读写事件。换句话说，在阻塞IO模型中一个连接就需要分配一个独立的线程去专门处理这个连接上的读写，到了IO多路复用模型中，多个连接可以复用这一个独立的线程去处理这多个连接上的读写。好了，IO多路复用模型的概念解释清楚了，那么问题的关键是我们如何去实现这个复用，也就是如何让一个独立的线程去处理众多连接上的读写事件呢？这个问题其实在非阻塞IO模型中已经给出了它的答案，在非阻塞IO模型中，利用非阻塞的系统IO调用去不断的轮询众多连接的Socket接收缓冲区看是否有数据到来，如果有则处理，如果没有则继续轮询下一个Socket。这样就达到了用一个线程去处理众多连接上的读写事件了。但是非阻塞IO模型最大的问题就是需要不断的发起系统调用去轮询各个Socket中的接收缓冲区是否有数据到来，频繁的系统调用随之带来了大量的上下文切换开销。随着并发量的提升，这样也会导致非常严重的性能问题。那么如何避免频繁的系统调用同时又可以实现我们的核心需求呢？这就需要操作系统的内核来支持这样的操作，我们可以把频繁的轮询操作交给操作系统内核来替我们完成，这样就避免了在用户空间频繁的去使用系统调用来轮询所带来的性能开销。正如我们所想，操作系统内核也确实为我们提供了这样的功能实现，下面我们来一起看下操作系统对IO多路复用模型的实现。select select是操作系统内核提供给我们使用的一个系统调用，它解决了在非阻塞IO模型中需要不断的发起系统IO调用去轮询各个连接上的Socket接收缓冲区所带来的用户空间与内核空间不断切换的系统开销。select系统调用将轮询的操作交给了内核来帮助我们完成，从而避免了在用户空间不断的发起轮询所带来的的系统性能开销。首先用户线程在发起select系统调用的时候会阻塞在select系统调用上。此时，用户线程从用户态切换到了内核态完成了一次上下文切换用户线程将需要监听的Socket对应的文件描述符fd数组通过select系统调用传递给内核。此时，用户线程将用户空间中的文件描述符fd数组拷贝到内核空间。这里的文件描述符数组其实是一个BitMap，BitMap下标为文件描述符fd，下标对应的值为：1表示该fd上有读写事件，0表示该fd上没有读写事件。文件描述符fd其实就是一个整数值，在Linux中一切皆文件，Socket也是一个文件。描述进程所有信息的数据结构task_struct中有一个属性struct files_struct *files，它最终指向了一个数组，数组里存放了进程打开的所有文件列表，文件信息封装在struct file结构体中，这个数组存放的类型就是struct file结构体，数组的下标则是我们常说的文件描述符fd。当用户线程调用完select后开始进入阻塞状态，内核开始轮询遍历fd数组，查看fd对应的Socket接收缓冲区中是否有数据到来。如果有数据到来，则将fd对应BitMap的值设置为1。如果没有数据到来，则保持值为0。注意这里内核会修改原始的fd数组！！内核遍历一遍fd数组后，如果发现有些fd上有IO数据到来，则将修改后的fd数组返回给用户线程。此时，会将fd数组从内核空间拷贝到用户空间。当内核将修改后的fd数组返回给用户线程后，用户线程解除阻塞，由用户线程开始遍历fd数组然后找出fd数组中值为1的Socket文件描述符。最后对这些Socket发起系统调用读取数据。select不会告诉用户线程具体哪些fd上有IO数据到来，只是在IO活跃的fd上打上标记，将打好标记的完整fd数组返回给用户线程，所以用户线程还需要遍历fd数组找出具体哪些fd上有IO数据到来。由于内核在遍历的过程中已经修改了fd数组，所以在用户线程遍历完fd数组后获取到IO就绪的Socket后，就需要重置fd数组，并重新调用select传入重置后的fd数组，让内核发起新的一轮遍历轮询。API介绍当我们熟悉了select的原理后，就很容易理解内核给我们提供的select API了。 int select(int maxfdp1,fd_set *readset,fd_set *writeset,fd_set *exceptset,const struct timeval *timeout)从select API中我们可以看到，select系统调用是在规定的超时时间内，监听（轮询）用户感兴趣的文件描述符集合上的可读,可写,异常三类事件。maxfdp1 ： select传递给内核监听的文件描述符集合中数值最大的文件描述符+1，目的是用于限定内核遍历范围。比如：select监听的文件描述符集合为{0,1,2,3,4}，那么maxfdp1的值为5。fd_set *readset： 对可读事件感兴趣的文件描述符集合。fd_set *writeset： 对可写事件感兴趣的文件描述符集合。fd_set *exceptset：对可写事件感兴趣的文件描述符集合。这里的fd_set就是我们前边提到的文件描述符数组，是一个BitMap结构。const struct timeval *timeout：select系统调用超时时间，在这段时间内，内核如果没有发现有IO就绪的文件描述符，就直接返回。上小节提到，在内核遍历完fd数组后，发现有IO就绪的fd，则会将该fd对应的BitMap中的值设置为1，并将修改后的fd数组，返回给用户线程。在用户线程中需要重新遍历fd数组，找出IO就绪的fd出来，然后发起真正的读写调用。下面介绍下在用户线程中重新遍历fd数组的过程中，我们需要用到的API：void FD_ZERO(fd_set *fdset)：清空指定的文件描述符集合，即让fd_set中不在包含任何文件描述符。void FD_SET(int fd, fd_set *fdset)：将一个给定的文件描述符加入集合之中。每次调用select之前都要通过FD_ZERO和FD_SET重新设置文件描述符，因为文件描述符集合会在内核中被修改。int FD_ISSET(int fd, fd_set *fdset)：检查集合中指定的文件描述符是否可以读写。用户线程遍历文件描述符集合,调用该方法检查相应的文件描述符是否IO就绪。void FD_CLR(int fd, fd_set *fdset)：将一个给定的文件描述符从集合中删除性能开销虽然select解决了非阻塞IO模型中频繁发起系统调用的问题，但是在整个select工作过程中，我们还是看出了select有些不足的地方。在发起select系统调用以及返回时，用户线程各发生了一次用户态到内核态以及内核态到用户态的上下文切换开销。发生2次上下文切换在发起select系统调用以及返回时，用户线程在内核态需要将文件描述符集合从用户空间拷贝到内核空间。以及在内核修改完文件描述符集合后，又要将它从内核空间拷贝到用户空间。发生2次文件描述符集合的拷贝虽然由原来在用户空间发起轮询优化成了在内核空间发起轮询但select不会告诉用户线程到底是哪些Socket上发生了IO就绪事件，只是对IO就绪的Socket作了标记，用户线程依然要遍历文件描述符集合去查找具体IO就绪的Socket。时间复杂度依然为O(n)。大部分情况下，网络连接并不总是活跃的，如果select监听了大量的客户端连接，只有少数的连接活跃，然而使用轮询的这种方式会随着连接数的增大，效率会越来越低。内核会对原始的文件描述符集合进行修改。导致每次在用户空间重新发起select调用时，都需要对文件描述符集合进行重置。BitMap结构的文件描述符集合，长度为固定的1024,所以只能监听0~1023的文件描述符。select系统调用 不是线程安全的。以上select的不足所产生的性能开销都会随着并发量的增大而线性增长。很明显select也不能解决C10K问题，只适用于1000个左右的并发连接场景。poll poll相当于是改进版的select，但是工作原理基本和select没有本质的区别。int poll(struct pollfd *fds, unsigned int nfds, int timeout)struct pollfd {    int   fd;         /* 文件描述符 */    short events;     /* 需要监听的事件 */    short revents;    /* 实际发生的事件 由内核修改设置 */};select中使用的文件描述符集合是采用的固定长度为1024的BitMap结构的fd_set，而poll换成了一个pollfd结构没有固定长度的数组，这样就没有了最大描述符数量的限制（当然还会受到系统文件描述符限制）poll只是改进了select只能监听1024个文件描述符的数量限制，但是并没有在性能方面做出改进。和select上本质并没有多大差别。同样需要在内核空间和用户空间中对文件描述符集合进行轮询，查找出IO就绪的Socket的时间复杂度依然为O(n)。同样需要将包含大量文件描述符的集合整体在用户空间和内核空间之间来回复制，无论这些文件描述符是否就绪。他们的开销都会随着文件描述符数量的增加而线性增大。select，poll在每次新增，删除需要监听的socket时，都需要将整个新的socket集合全量传至内核。poll同样不适用高并发的场景。依然无法解决C10K问题。epoll 通过上边对select,poll核心原理的介绍，我们看到select,poll的性能瓶颈主要体现在下面三个地方：因为内核不会保存我们要监听的socket集合，所以在每次调用select,poll的时候都需要传入，传出全量的socket文件描述符集合。这导致了大量的文件描述符在用户空间和内核空间频繁的来回复制。由于内核不会通知具体IO就绪的socket，只是在这些IO就绪的socket上打好标记，所以当select系统调用返回时，在用户空间还是需要完整遍历一遍socket文件描述符集合来获取具体IO就绪的socket。在内核空间中也是通过遍历的方式来得到IO就绪的socket。下面我们来看下epoll是如何解决这些问题的。在介绍epoll的核心原理之前，我们需要介绍下理解epoll工作过程所需要的一些核心基础知识。Socket的创建服务端线程调用accept系统调用后开始阻塞，当有客户端连接上来并完成TCP三次握手后，内核会创建一个对应的Socket作为服务端与客户端通信的内核接口。在Linux内核的角度看来，一切皆是文件，Socket也不例外，当内核创建出Socket之后，会将这个Socket放到当前进程所打开的文件列表中管理起来。下面我们来看下进程管理这些打开的文件列表相关的内核数据结构是什么样的？在了解完这些数据结构后，我们会更加清晰的理解Socket在内核中所发挥的作用。并且对后面我们理解epoll的创建过程有很大的帮助。进程中管理文件列表结构struct tast_struct是内核中用来表示进程的一个数据结构，它包含了进程的所有信息。本小节我们只列出和文件管理相关的属性。其中进程内打开的所有文件是通过一个数组fd_array来进行组织管理，数组的下标即为我们常提到的文件描述符，数组中存放的是对应的文件数据结构struct file。每打开一个文件，内核都会创建一个struct file与之对应，并在fd_array中找到一个空闲位置分配给它，数组中对应的下标，就是我们在用户空间用到的文件描述符。对于任何一个进程，默认情况下，文件描述符 0表示 stdin 标准输入，文件描述符 1表示stdout 标准输出，文件描述符2表示stderr 标准错误输出。进程中打开的文件列表fd_array定义在内核数据结构struct files_struct中，在struct fdtable结构中有一个指针struct fd **fd指向fd_array。由于本小节讨论的是内核网络系统部分的数据结构，所以这里拿Socket文件类型来举例说明：用于封装文件元信息的内核数据结构struct file中的private_data指针指向具体的Socket结构。struct file中的file_operations属性定义了文件的操作函数，不同的文件类型，对应的file_operations是不同的，针对Socket文件类型，这里的file_operations指向socket_file_ops。我们在用户空间对Socket发起的读写等系统调用，进入内核首先会调用的是Socket对应的struct file中指向的socket_file_ops。比如：对Socket发起write写操作，在内核中首先被调用的就是socket_file_ops中定义的sock_write_iter。Socket发起read读操作内核中对应的则是sock_read_iter。static const struct file_operations socket_file_ops = {  .owner =  THIS_MODULE,  .llseek =  no_llseek,  .read_iter =  sock_read_iter,  .write_iter =  sock_write_iter,  .poll =    sock_poll,  .unlocked_ioctl = sock_ioctl,  .mmap =    sock_mmap,  .release =  sock_close,  .fasync =  sock_fasync,  .sendpage =  sock_sendpage,  .splice_write = generic_splice_sendpage,  .splice_read =  sock_splice_read,};Socket内核结构在我们进行网络程序的编写时会首先创建一个Socket，然后基于这个Socket进行bind，listen，我们先将这个Socket称作为监听Socket。当我们调用accept后，内核会基于监听Socket创建出来一个新的Socket专门用于与客户端之间的网络通信。并将监听Socket中的Socket操作函数集合（inet_stream_ops）ops赋值到新的Socket的ops属性中。const struct proto_ops inet_stream_ops = {  .bind = inet_bind,  .connect = inet_stream_connect,  .accept = inet_accept,  .poll = tcp_poll,  .listen = inet_listen,  .sendmsg = inet_sendmsg,  .recvmsg = inet_recvmsg,  ......}这里需要注意的是，监听的 socket和真正用来网络通信的 Socket，是两个 Socket，一个叫作监听 Socket，一个叫作已连接的Socket。接着内核会为已连接的Socket创建struct file并初始化，并把Socket文件操作函数集合（socket_file_ops）赋值给struct file中的f_ops指针。然后将struct socket中的file指针指向这个新分配申请的struct file结构体。内核会维护两个队列：一个是已经完成TCP三次握手，连接状态处于established的连接队列。内核中为icsk_accept_queue。一个是还没有完成TCP三次握手，连接状态处于syn_rcvd的半连接队列。然后调用socket->ops->accept，从Socket内核结构图中我们可以看到其实调用的是inet_accept，该函数会在icsk_accept_queue中查找是否有已经建立好的连接，如果有的话，直接从icsk_accept_queue中获取已经创建好的struct sock。并将这个struct sock对象赋值给struct socket中的sock指针。struct sock在struct socket中是一个非常核心的内核对象，正是在这里定义了我们在介绍网络包的接收发送流程中提到的接收队列，发送队列，等待队列，数据就绪回调函数指针，内核协议栈操作函数集合根据创建Socket时发起的系统调用sock_create中的protocol参数(对于TCP协议这里的参数值为SOCK_STREAM)查找到对于 tcp 定义的操作方法实现集合 inet_stream_ops 和tcp_prot。并把它们分别设置到socket->ops和sock->sk_prot上。这里可以回看下本小节开头的《Socket内核结构图》捋一下他们之间的关系。socket相关的操作接口定义在inet_stream_ops函数集合中，负责对上给用户提供接口。而socket与内核协议栈之间的操作接口定义在struct sock中的sk_prot指针上，这里指向tcp_prot协议操作函数集合。struct proto tcp_prot = {  .name      = "TCP",  .owner      = THIS_MODULE,  .close      = tcp_close,  .connect    = tcp_v4_connect,  .disconnect    = tcp_disconnect,  .accept      = inet_csk_accept,  .keepalive    = tcp_set_keepalive,  .recvmsg    = tcp_recvmsg,  .sendmsg    = tcp_sendmsg,  .backlog_rcv    = tcp_v4_do_rcv,   ......}之前提到的对Socket发起的系统IO调用，在内核中首先会调用Socket的文件结构struct file中的file_operations文件操作集合，然后调用struct socket中的ops指向的inet_stream_opssocket操作函数，最终调用到struct sock中sk_prot指针指向的tcp_prot内核协议栈操作函数接口集合。将struct sock 对象中的sk_data_ready 函数指针设置为 sock_def_readable，在Socket数据就绪的时候内核会回调该函数。struct sock中的等待队列中存放的是系统IO调用发生阻塞的进程fd，以及相应的回调函数。记住这个地方，后边介绍epoll的时候我们还会提到！当struct file，struct socket，struct sock这些核心的内核对象创建好之后，最后就是把socket对象对应的struct file放到进程打开的文件列表fd_array中。随后系统调用accept返回socket的文件描述符fd给用户程序。阻塞IO中用户进程阻塞以及唤醒原理在前边小节我们介绍阻塞IO的时候提到，当用户进程发起系统IO调用时，这里我们拿read举例，用户进程会在内核态查看对应Socket接收缓冲区是否有数据到来。Socket接收缓冲区有数据，则拷贝数据到用户空间，系统调用返回。Socket接收缓冲区没有数据，则用户进程让出CPU进入阻塞状态，当数据到达接收缓冲区时，用户进程会被唤醒，从阻塞状态进入就绪状态，等待CPU调度。本小节我们就来看下用户进程是如何阻塞在Socket上，又是如何在Socket上被唤醒的。理解这个过程很重要，对我们理解epoll的事件通知过程很有帮助首先我们在用户进程中对Socket进行read系统调用时，用户进程会从用户态转为内核态。在进程的struct task_struct结构找到fd_array，并根据Socket的文件描述符fd找到对应的struct file，调用struct file中的文件操作函数结合file_operations，read系统调用对应的是sock_read_iter。在sock_read_iter函数中找到struct file指向的struct socket，并调用socket->ops->recvmsg，这里我们知道调用的是inet_stream_ops集合中定义的inet_recvmsg。在inet_recvmsg中会找到struct sock，并调用sock->skprot->recvmsg,这里调用的是tcp_prot集合中定义的tcp_recvmsg函数。整个调用过程可以参考上边的《系统IO调用结构图》熟悉了内核函数调用栈后，我们来看下系统IO调用在tcp_recvmsg内核函数中是如何将用户进程给阻塞掉的int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t len, int nonblock, int flags, int *addr_len){    .................省略非核心代码...............   //访问sock对象中定义的接收队列  skb_queue_walk(&sk->sk_receive_queue, skb) {    .................省略非核心代码............... //没有收到足够数据，调用sk_wait_data 阻塞当前进程  sk_wait_data(sk, &timeo);}int sk_wait_data(struct sock *sk, long *timeo){ //创建struct sock中等待队列上的元素wait_queue_t //将进程描述符和回调函数autoremove_wake_function关联到wait_queue_t中 DEFINE_WAIT(wait); // 调用 sk_sleep 获取 sock 对象下的等待队列的头指针wait_queue_head_t // 调用prepare_to_wait将新创建的等待项wait_queue_t插入到等待队列中，并将进程状态设置为可打断 INTERRUPTIBLE prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE); set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags); // 通过调用schedule_timeout让出CPU，然后进行睡眠，导致一次上下文切换 rc = sk_wait_event(sk, timeo, !skb_queue_empty(&sk->sk_receive_queue)); ...首先会在DEFINE_WAIT中创建struct sock中等待队列上的等待类型wait_queue_t。#define DEFINE_WAIT(name) DEFINE_WAIT_FUNC(name, autoremove_wake_function)#define DEFINE_WAIT_FUNC(name, function)    \ wait_queue_t name = {      \  .private = current,    \  .func  = function,    \  .task_list = LIST_HEAD_INIT((name).task_list), \ }等待类型wait_queue_t中的private用来关联阻塞在当前socket上的用户进程fd。func用来关联等待项上注册的回调函数。这里注册的是autoremove_wake_function。调用sk_sleep(sk)获取struct sock对象中的等待队列头指针wait_queue_head_t。调用prepare_to_wait将新创建的等待项wait_queue_t插入到等待队列中，并将进程设置为可打断 INTERRUPTIBL。调用sk_wait_event让出CPU，进程进入睡眠状态。用户进程的阻塞过程我们就介绍完了，关键是要理解记住struct sock中定义的等待队列上的等待类型wait_queue_t的结构。后面epoll的介绍中我们还会用到它。下面我们接着介绍当数据就绪后，用户进程是如何被唤醒的在本文开始介绍《网络包接收过程》这一小节中我们提到：当网络数据包到达网卡时，网卡通过DMA的方式将数据放到RingBuffer中。然后向CPU发起硬中断，在硬中断响应程序中创建sk_buffer，并将网络数据拷贝至sk_buffer中。随后发起软中断，内核线程ksoftirqd响应软中断，调用poll函数将sk_buffer送往内核协议栈做层层协议处理。在传输层tcp_rcv 函数中，去掉TCP头，根据四元组（源IP，源端口，目的IP，目的端口）查找对应的Socket。最后将sk_buffer放到Socket中的接收队列里。上边这些过程是内核接收网络数据的完整过程，下边我们来看下，当数据包接收完毕后，用户进程是如何被唤醒的。当软中断将sk_buffer放到Socket的接收队列上时，接着就会调用数据就绪函数回调指针sk_data_ready，前边我们提到，这个函数指针在初始化的时候指向了sock_def_readable函数。在sock_def_readable函数中会去获取socket->sock->sk_wq等待队列。在wake_up_common函数中从等待队列sk_wq中找出一个等待项wait_queue_t，回调注册在该等待项上的func回调函数（wait_queue_t->func）,创建等待项wait_queue_t是我们提到，这里注册的回调函数是autoremove_wake_function。即使是有多个进程都阻塞在同一个 socket 上，也只唤醒 1 个进程。其作用是为了避免惊群。在autoremove_wake_function函数中，根据等待项wait_queue_t上的private关联的阻塞进程fd调用try_to_wake_up唤醒阻塞在该Socket上的进程。记住wait_queue_t中的func函数指针，在epoll中这里会注册epoll的回调函数。现在理解epoll所需要的基础知识我们就介绍完了，唠叨了这么多，下面终于正式进入本小节的主题epoll了。epoll_create创建epoll对象epoll_create是内核提供给我们创建epoll对象的一个系统调用，当我们在用户进程中调用epoll_create时，内核会为我们创建一个struct eventpoll对象，并且也有相应的struct file与之关联，同样需要把这个struct eventpoll对象所关联的struct file放入进程打开的文件列表fd_array中管理。熟悉了Socket的创建逻辑，epoll的创建逻辑也就不难理解了。struct eventpoll对象关联的struct file中的file_operations 指针指向的是eventpoll_fops操作函数集合。static const struct file_operations eventpoll_fops = {     .release = ep_eventpoll_release;     .poll = ep_eventpoll_poll,}struct eventpoll {    //等待队列，阻塞在epoll上的进程会放在这里    wait_queue_head_t wq;    //就绪队列，IO就绪的socket连接会放在这里    struct list_head rdllist;    //红黑树用来管理所有监听的socket连接    struct rb_root rbr;    ......}wait_queue_head_t wq：epoll中的等待队列，队列里存放的是阻塞在epoll上的用户进程。在IO就绪的时候epoll可以通过这个队列找到这些阻塞的进程并唤醒它们，从而执行IO调用读写Socket上的数据。这里注意与Socket中的等待队列区分！！！struct list_head rdllist：epoll中的就绪队列，队列里存放的是都是IO就绪的Socket，被唤醒的用户进程可以直接读取这个队列获取IO活跃的Socket。无需再次遍历整个Socket集合。这里正是epoll比select ，poll高效之处，select ，poll返回的是全部的socket连接，我们需要在用户空间再次遍历找出真正IO活跃的Socket连接。 而epoll只是返回IO活跃的Socket连接。用户进程可以直接进行IO操作。struct rb_root rbr : 由于红黑树在查找，插入，删除等综合性能方面是最优的，所以epoll内部使用一颗红黑树来管理海量的Socket连接。select用数组管理连接，poll用链表管理连接。epoll_ctl向epoll对象中添加监听的Socket当我们调用epoll_create在内核中创建出epoll对象struct eventpoll后，我们就可以利用epoll_ctl向epoll中添加我们需要管理的Socket连接了。首先要在epoll内核中创建一个表示Socket连接的数据结构struct epitem，而在epoll中为了综合性能的考虑，采用一颗红黑树来管理这些海量socket连接。所以struct epitem是一个红黑树节点。struct epitem{      //指向所属epoll对象      struct eventpoll *ep;      //注册的感兴趣的事件,也就是用户空间的epoll_event           struct epoll_event event;      //指向epoll对象中的就绪队列      struct list_head rdllink;       //指向epoll中对应的红黑树节点      struct rb_node rbn;          //指向epitem所表示的socket->file结构以及对应的fd      struct epoll_filefd ffd;                   }这里重点记住struct epitem结构中的rdllink以及epoll_filefd成员，后面我们会用到。在内核中创建完表示Socket连接的数据结构struct epitem后，我们就需要在Socket中的等待队列上创建等待项wait_queue_t并且注册epoll的回调函数ep_poll_callback。通过《阻塞IO中用户进程阻塞以及唤醒原理》小节的铺垫，我想大家已经猜到这一步的意义所在了吧！当时在等待项wait_queue_t中注册的是autoremove_wake_function回调函数。还记得吗？epoll的回调函数ep_poll_callback正是epoll同步IO事件通知机制的核心所在，也是区别于select，poll采用内核轮询方式的根本性能差异所在。这里又出现了一个新的数据结构struct eppoll_entry，那它的作用是干什么的呢？大家可以结合上图先猜测下它的作用!我们知道socket->sock->sk_wq等待队列中的类型是wait_queue_t，我们需要在struct epitem所表示的socket的等待队列上注册epoll回调函数ep_poll_callback。这样当数据到达socket中的接收队列时，内核会回调sk_data_ready，在阻塞IO中用户进程阻塞以及唤醒原理这一小节中，我们知道这个sk_data_ready函数指针会指向sk_def_readable函数，在sk_def_readable中会回调注册在等待队列里的等待项wait_queue_t -> func回调函数ep_poll_callback。在ep_poll_callback中需要找到epitem，将IO就绪的epitem放入epoll中的就绪队列中。而socket等待队列中类型是wait_queue_t无法关联到epitem。所以就出现了struct eppoll_entry结构体，它的作用就是关联Socket等待队列中的等待项wait_queue_t和epitem。struct eppoll_entry {   //指向关联的epitem   struct epitem *base; // 关联监听socket中等待队列中的等待项 (private = null  func = ep_poll_callback)   wait_queue_t wait;     // 监听socket中等待队列头指针   wait_queue_head_t *whead;    .........  }; 这样在ep_poll_callback回调函数中就可以根据Socket等待队列中的等待项wait，通过container_of宏找到eppoll_entry，继而找到epitem了。container_of在Linux内核中是一个常用的宏，用于从包含在某个结构中的指针获得结构本身的指针，通俗地讲就是通过结构体变量中某个成员的首地址进而获得整个结构体变量的首地址。这里需要注意下这次等待项wait_queue_t中的private设置的是null，因为这里Socket是交给epoll来管理的，阻塞在Socket上的进程是也由epoll来唤醒。在等待项wait_queue_t注册的func是ep_poll_callback而不是autoremove_wake_function，阻塞进程并不需要autoremove_wake_function来唤醒，所以这里设置private为null当在Socket的等待队列中创建好等待项wait_queue_t并且注册了epoll的回调函数ep_poll_callback，然后又通过eppoll_entry关联了epitem后。 剩下要做的就是将epitem插入到epoll中的红黑树struct rb_root rbr中。这里可以看到epoll另一个优化的地方，epoll将所有的socket连接通过内核中的红黑树来集中管理。每次添加或者删除socket连接都是增量添加删除，而不是像select，poll那样每次调用都是全量socket连接集合传入内核。避免了频繁大量的内存拷贝。epoll_wait同步阻塞获取IO就绪的Socket用户程序调用epoll_wait后，内核首先会查找epoll中的就绪队列eventpoll->rdllist是否有IO就绪的epitem。epitem里封装了socket的信息。如果就绪队列中有就绪的epitem，就将就绪的socket信息封装到epoll_event返回。如果eventpoll->rdllist就绪队列中没有IO就绪的epitem，则会创建等待项wait_queue_t，将用户进程的fd关联到wait_queue_t->private上，并在等待项wait_queue_t->func上注册回调函数default_wake_function。最后将等待项添加到epoll中的等待队列中。用户进程让出CPU，进入阻塞状态。这里和阻塞IO模型中的阻塞原理是一样的，只不过在阻塞IO模型中注册到等待项wait_queue_t->func上的是autoremove_wake_function，并将等待项添加到socket中的等待队列中。这里注册的是default_wake_function，将等待项添加到epoll中的等待队列上。前边做了那么多的知识铺垫，下面终于到了epoll的整个工作流程了：当网络数据包在软中断中经过内核协议栈的处理到达socket的接收缓冲区时，紧接着会调用socket的数据就绪回调指针sk_data_ready，回调函数为sock_def_readable。在socket的等待队列中找出等待项，其中等待项中注册的回调函数为ep_poll_callback。在回调函数ep_poll_callback中，根据struct eppoll_entry中的struct wait_queue_t wait通过container_of宏找到eppoll_entry对象并通过它的base指针找到封装socket的数据结构struct epitem，并将它加入到epoll中的就绪队列rdllist中。随后查看epoll中的等待队列中是否有等待项，也就是说查看是否有进程阻塞在epoll_wait上等待IO就绪的socket。如果没有等待项，则软中断处理完成。如果有等待项，则回到注册在等待项中的回调函数default_wake_function,在回调函数中唤醒阻塞进程，并将就绪队列rdllist中的epitem的IO就绪socket信息封装到struct epoll_event中返回。用户进程拿到epoll_event获取IO就绪的socket，发起系统IO调用读取数据。再谈水平触发和边缘触发 网上有大量的关于这两种模式的讲解，大部分讲的比较模糊，感觉只是强行从概念上进行描述，看完让人难以理解。所以在这里，笔者想结合上边epoll的工作过程，再次对这两种模式做下自己的解读，力求清晰的解释出这两种工作模式的异同。经过上边对epoll工作过程的详细解读，我们知道，当我们监听的socket上有数据到来时，软中断会执行epoll的回调函数ep_poll_callback,在回调函数中会将epoll中描述socket信息的数据结构epitem插入到epoll中的就绪队列rdllist中。随后用户进程从epoll的等待队列中被唤醒，epoll_wait将IO就绪的socket返回给用户进程，随即epoll_wait会清空rdllist。水平触发和边缘触发最关键的区别就在于当socket中的接收缓冲区还有数据可读时。epoll_wait是否会清空rdllist。水平触发：在这种模式下，用户线程调用epoll_wait获取到IO就绪的socket后，对Socket进行系统IO调用读取数据，假设socket中的数据只读了一部分没有全部读完，这时再次调用epoll_wait，epoll_wait会检查这些Socket中的接收缓冲区是否还有数据可读，如果还有数据可读，就将socket重新放回rdllist。所以当socket上的IO没有被处理完时，再次调用epoll_wait依然可以获得这些socket，用户进程可以接着处理socket上的IO事件。边缘触发： 在这种模式下，epoll_wait就会直接清空rdllist，不管socket上是否还有数据可读。所以在边缘触发模式下，当你没有来得及处理socket接收缓冲区的剩下可读数据时，再次调用epoll_wait，因为这时rdlist已经被清空了，socket不会再次从epoll_wait中返回，所以用户进程就不会再次获得这个socket了，也就无法在对它进行IO处理了。除非，这个socket上有新的IO数据到达，根据epoll的工作过程，该socket会被再次放入rdllist中。如果你在边缘触发模式下，处理了部分socket上的数据，那么想要处理剩下部分的数据，就只能等到这个socket上再次有网络数据到达。在Netty中实现的EpollSocketChannel默认的就是边缘触发模式。JDK的NIO默认是水平触发模式。epoll对select，poll的优化总结epoll在内核中通过红黑树管理海量的连接，所以在调用epoll_wait获取IO就绪的socket时，不需要传入监听的socket文件描述符。从而避免了海量的文件描述符集合在用户空间和内核空间中来回复制。select，poll每次调用时都需要传递全量的文件描述符集合，导致大量频繁的拷贝操作。epoll仅会通知IO就绪的socket。避免了在用户空间遍历的开销。select，poll只会在IO就绪的socket上打好标记，依然是全量返回，所以在用户空间还需要用户程序在一次遍历全量集合找出具体IO就绪的socket。epoll通过在socket的等待队列上注册回调函数ep_poll_callback通知用户程序IO就绪的socket。避免了在内核中轮询的开销。大部分情况下socket上并不总是IO活跃的，在面对海量连接的情况下，select，poll采用内核轮询的方式获取IO活跃的socket，无疑是性能低下的核心原因。根据以上epoll的性能优势，它是目前为止各大主流网络框架，以及反向代理中间件使用到的网络IO模型。利用epoll多路复用IO模型可以轻松的解决C10K问题。C100k的解决方案也还是基于C10K的方案，通过epoll 配合线程池，再加上 CPU、内存和网络接口的性能和容量提升。大部分情况下，C100K很自然就可以达到。甚至C1000K的解决方法，本质上还是构建在 epoll 的多路复用 I/O 模型上。只不过，除了 I/O 模型之外，还需要从应用程序到 Linux 内核、再到 CPU、内存和网络等各个层次的深度优化，特别是需要借助硬件，来卸载那些原来通过软件处理的大量功能（去掉大量的中断响应开销，以及内核协议栈处理的开销）。信号驱动IO 大家对这个装备肯定不会陌生，当我们去一些美食城吃饭的时候，点完餐付了钱，老板会给我们一个信号器。然后我们带着这个信号器可以去找餐桌，或者干些其他的事情。当信号器亮了的时候，这时代表饭餐已经做好，我们可以去窗口取餐了。这个典型的生活场景和我们要介绍的信号驱动IO模型就很像。在信号驱动IO模型下，用户进程操作通过系统调用 sigaction 函数发起一个 IO 请求，在对应的socket注册一个信号回调，此时不阻塞用户进程，进程会继续工作。当内核数据就绪时，内核就为该进程生成一个 SIGIO 信号，通过信号回调通知进程进行相关 IO 操作。这里需要注意的是：信号驱动式 IO 模型依然是同步IO，因为它虽然可以在等待数据的时候不被阻塞，也不会频繁的轮询，但是当数据就绪，内核信号通知后，用户进程依然要自己去读取数据，在数据拷贝阶段发生阻塞。信号驱动 IO模型 相比于前三种 IO 模型，实现了在等待数据就绪时，进程不被阻塞，主循环可以继续工作，所以理论上性能更佳。但是实际上，使用TCP协议通信时，信号驱动IO模型几乎不会被采用。原因如下：信号IO 在大量 IO 操作时可能会因为信号队列溢出导致没法通知SIGIO 信号是一种 Unix 信号，信号没有附加信息，如果一个信号源有多种产生信号的原因，信号接收者就无法确定究竟发生了什么。而 TCP socket 生产的信号事件有七种之多，这样应用程序收到 SIGIO，根本无从区分处理。但信号驱动IO模型可以用在 UDP通信上，因为UDP 只有一个数据请求事件，这也就意味着在正常情况下 UDP 进程只要捕获 SIGIO 信号，就调用 read 系统调用读取到达的数据。如果出现异常，就返回一个异常错误。这里插句题外话，大家觉不觉得阻塞IO模型在生活中的例子就像是我们在食堂排队打饭。你自己需要排队去打饭同时打饭师傅在配菜的过程中你需要等待。IO多路复用模型就像是我们在饭店门口排队等待叫号。叫号器就好比select,poll,epoll可以统一管理全部顾客的吃饭就绪事件，客户好比是socket连接，谁可以去吃饭了，叫号器就通知谁。##异步IO（AIO）以上介绍的四种IO模型均为同步IO，它们都会阻塞在第二阶段数据拷贝阶段。通过在前边小节《同步与异步》中的介绍，相信大家很容易就会理解异步IO模型，在异步IO模型下，IO操作在数据准备阶段和数据拷贝阶段均是由内核来完成，不会对应用程序造成任何阻塞。应用进程只需要在指定的数组中引用数据即可。异步 IO 与信号驱动 IO 的主要区别在于：信号驱动 IO 由内核通知何时可以开始一个 IO 操作，而异步 IO由内核通知 IO 操作何时已经完成。举个生活中的例子：异步IO模型就像我们去一个高档饭店里的包间吃饭，我们只需要坐在包间里面，点完餐（类比异步IO调用）之后，我们就什么也不需要管，该喝酒喝酒，该聊天聊天，饭餐做好后服务员（类比内核）会自己给我们送到包间（类比用户空间）来。整个过程没有任何阻塞。异步IO的系统调用需要操作系统内核来支持，目前只有Window中的IOCP实现了非常成熟的异步IO机制。而Linux系统对异步IO机制实现的不够成熟，且与NIO的性能相比提升也不明显。但Linux kernel 在5.1版本由Facebook的大神Jens Axboe引入了新的异步IO库io_uring 改善了原来Linux native AIO的一些性能问题。性能相比Epoll以及之前原生的AIO提高了不少，值得关注。再加上信号驱动IO模型不适用TCP协议，所以目前大部分采用的还是IO多路复用模型。IO线程模型 在前边内容的介绍中，我们详述了网络数据包的接收和发送过程，并通过介绍5种IO模型了解了内核是如何读取网络数据并通知给用户线程的。前边的内容都是以内核空间的视角来剖析网络数据的收发模型，本小节我们站在用户空间的视角来看下如果对网络数据进行收发。相对内核来讲，用户空间的IO线程模型相对就简单一些。这些用户空间的IO线程模型都是在讨论当多线程一起配合工作时谁负责接收连接，谁负责响应IO 读写、谁负责计算、谁负责发送和接收，仅仅是用户IO线程的不同分工模式罢了。Reactor Reactor是利用NIO对IO线程进行不同的分工：使用前边我们提到的IO多路复用模型比如select,poll,epoll,kqueue,进行IO事件的注册和监听。将监听到就绪的IO事件分发dispatch到各个具体的处理Handler中进行相应的IO事件处理。通过IO多路复用技术就可以不断的监听IO事件，不断的分发dispatch，就像一个反应堆一样，看起来像不断的产生IO事件，因此我们称这种模式为Reactor模型。下面我们来看下Reactor模型的三种分类：单Reactor单线程Reactor模型是依赖IO多路复用技术实现监听IO事件，从而源源不断的产生IO就绪事件，在Linux系统下我们使用epoll来进行IO多路复用，我们以Linux系统为例：单Reactor意味着只有一个epoll对象，用来监听所有的事件，比如连接事件，读写事件。单线程意味着只有一个线程来执行epoll_wait获取IO就绪的Socket，然后对这些就绪的Socket执行读写，以及后边的业务处理也依然是这个线程。单Reactor单线程模型就好比我们开了一个很小很小的小饭馆，作为老板的我们需要一个人干所有的事情，包括：迎接顾客（accept事件），为顾客介绍菜单等待顾客点菜(IO请求)，做菜（业务处理），上菜（IO响应），送客（断开连接）。单Reactor多线程随着客人的增多（并发请求），显然饭馆里的事情只有我们一个人干（单线程）肯定是忙不过来的，这时候我们就需要多招聘一些员工（多线程）来帮着一起干上述的事情。于是就有了单Reactor多线程模型：这种模式下，也是只有一个epoll对象来监听所有的IO事件，一个线程来调用epoll_wait获取IO就绪的Socket。但是当IO就绪事件产生时，这些IO事件对应处理的业务Handler，我们是通过线程池来执行。这样相比单Reactor单线程模型提高了执行效率，充分发挥了多核CPU的优势。主从Reactor多线程做任何事情都要区分事情的优先级，我们应该优先高效的去做优先级更高的事情，而不是一股脑不分优先级的全部去做。当我们的小饭馆客人越来越多（并发量越来越大），我们就需要扩大饭店的规模，在这个过程中我们发现，迎接客人是饭店最重要的工作，我们要先把客人迎接进来，不能让客人一看人多就走掉，只要客人进来了，哪怕菜做的慢一点也没关系。于是，主从Reactor多线程模型就产生了：我们由原来的单Reactor变为了多Reactor。主Reactor用来优先专门做优先级最高的事情，也就是迎接客人（处理连接事件），对应的处理Handler就是图中的acceptor。当创建好连接，建立好对应的socket后，在acceptor中将要监听的read事件注册到从Reactor中，由从Reactor来监听socket上的读写事件。最终将读写的业务逻辑处理交给线程池处理。注意：这里向从Reactor注册的只是read事件，并没有注册write事件，因为read事件是由epoll内核触发的，而write事件则是由用户业务线程触发的（什么时候发送数据是由具体业务线程决定的），所以write事件理应是由用户业务线程去注册。用户线程注册write事件的时机是只有当用户发送的数据无法一次性全部写入buffer时，才会去注册write事件，等待buffer重新可写时，继续写入剩下的发送数据、如果用户线程可以一股脑的将发送数据全部写入buffer，那么也就无需注册write事件到从Reactor中。主从Reactor多线程模型是现在大部分主流网络框架中采用的一种IO线程模型。我们本系列的主题Netty就是用的这种模型。Proactor Proactor是基于AIO对IO线程进行分工的一种模型。前边我们介绍了异步IO模型，它是操作系统内核支持的一种全异步编程模型，在数据准备阶段和数据拷贝阶段全程无阻塞。ProactorIO线程模型将IO事件的监听，IO操作的执行，IO结果的dispatch统统交给内核来做。Proactor模型组件介绍：completion handler 为用户程序定义的异步IO操作回调函数，在异步IO操作完成时会被内核回调并通知IO结果。Completion Event Queue 异步IO操作完成后，会产生对应的IO完成事件，将IO完成事件放入该队列中。Asynchronous Operation Processor 负责异步IO的执行。执行完成后产生IO完成事件放入Completion Event Queue 队列中。Proactor 是一个事件循环派发器，负责从Completion Event Queue中获取IO完成事件，并回调与IO完成事件关联的completion handler。Initiator 初始化异步操作（asynchronous operation）并通过Asynchronous Operation Processor将completion handler和proactor注册到内核。Proactor模型执行过程：用户线程发起aio_read，并告诉内核用户空间中的读缓冲区地址，以便内核完成IO操作将结果放入用户空间的读缓冲区，用户线程直接可以读取结果（无任何阻塞）。Initiator 初始化aio_read异步读取操作（asynchronous operation）,并将completion handler注册到内核。在Proactor中我们关心的IO完成事件：内核已经帮我们读好数据并放入我们指定的读缓冲区，用户线程可以直接读取。 在Reactor中我们关心的是IO就绪事件：数据已经到来，但是需要用户线程自己去读取。此时用户线程就可以做其他事情了，无需等待IO结果。而内核与此同时开始异步执行IO操作。当IO操作完成时会产生一个completion event事件，将这个IO完成事件放入completion event queue中。Proactor从completion event queue中取出completion event，并回调与IO完成事件关联的completion handler。在completion handler中完成业务逻辑处理。Reactor与Proactor对比 Reactor是基于NIO实现的一种IO线程模型，Proactor是基于AIO实现的IO线程模型。Reactor关心的是IO就绪事件，Proactor关心的是IO完成事件。在Proactor中，用户程序需要向内核传递用户空间的读缓冲区地址。Reactor则不需要。这也就导致了在Proactor中每个并发操作都要求有独立的缓存区，在内存上有一定的开销。Proactor 的实现逻辑复杂，编码成本较 Reactor要高很多。Proactor 在处理高耗时 IO时的性能要高于 Reactor，但对于低耗时 IO的执行效率提升并不明显。Netty的IO模型 在我们介绍完网络数据包在内核中的收发过程以及五种IO模型和两种IO线程模型后，现在我们来看下netty中的IO模型是什么样的。在我们介绍Reactor IO线程模型的时候提到有三种Reactor模型：单Reactor单线程，单Reactor多线程，主从Reactor多线程。这三种Reactor模型在netty中都是支持的，但是我们常用的是主从Reactor多线程模型。而我们之前介绍的三种Reactor只是一种模型，是一种设计思想。实际上各种网络框架在实现中并不是严格按照模型来实现的，会有一些小的不同，但大体设计思想上是一样的。下面我们来看下netty中的主从Reactor多线程模型是什么样子的？Reactor在netty中是以group的形式出现的，netty中将Reactor分为两组，一组是MainReactorGroup也就是我们在编码中常常看到的EventLoopGroup bossGroup,另一组是SubReactorGroup也就是我们在编码中常常看到的EventLoopGroup workerGroup。MainReactorGroup中通常只有一个Reactor，专门负责做最重要的事情，也就是监听连接accept事件。当有连接事件产生时，在对应的处理handler acceptor中创建初始化相应的NioSocketChannel（代表一个Socket连接）。然后以负载均衡的方式在SubReactorGroup中选取一个Reactor，注册上去，监听Read事件。MainReactorGroup中只有一个Reactor的原因是，通常我们服务端程序只会绑定监听一个端口，如果要绑定监听多个端口，就会配置多个Reactor。SubReactorGroup中有多个Reactor，具体Reactor的个数可以由系统参数 -D io.netty.eventLoopThreads指定。默认的Reactor的个数为CPU核数 * 2。SubReactorGroup中的Reactor主要负责监听读写事件，每一个Reactor负责监听一组socket连接。将全量的连接分摊在多个Reactor中。一个Reactor分配一个IO线程，这个IO线程负责从Reactor中获取IO就绪事件，执行IO调用获取IO数据，执行PipeLine。Socket连接在创建后就被固定的分配给一个Reactor，所以一个Socket连接也只会被一个固定的IO线程执行，每个Socket连接分配一个独立的PipeLine实例，用来编排这个Socket连接上的IO处理逻辑。这种无锁串行化的设计的目的是为了防止多线程并发执行同一个socket连接上的IO逻辑处理，防止出现线程安全问题。同时使系统吞吐量达到最大化由于每个Reactor中只有一个IO线程，这个IO线程既要执行IO活跃Socket连接对应的PipeLine中的ChannelHandler，又要从Reactor中获取IO就绪事件，执行IO调用。所以PipeLine中ChannelHandler中执行的逻辑不能耗时太长，尽量将耗时的业务逻辑处理放入单独的业务线程池中处理，否则会影响其他连接的IO读写，从而近一步影响整个服务程序的IO吞吐。当IO请求在业务线程中完成相应的业务逻辑处理后，在业务线程中利用持有的ChannelHandlerContext引用将响应数据在PipeLine中反向传播，最终写回给客户端。netty中的IO模型我们介绍完了，下面我们来简单介绍下在netty中是如何支持前边提到的三种Reactor模型的。配置单Reactor单线程EventLoopGroup eventGroup = new NioEventLoopGroup(1);ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(eventGroup);配置单Reactor多线程EventLoopGroup eventGroup = new NioEventLoopGroup();ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(eventGroup);配置主从Reactor多线程EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup();ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(bossGroup, workerGroup);总结 本文是一篇信息量比较大的文章，用了25张图，22336个字从内核如何处理网络数据包的收发过程开始展开，随后又在内核角度介绍了经常容易混淆的阻塞与非阻塞，同步与异步的概念。以这个作为铺垫，我们通过一个C10K的问题，引出了五种IO模型，随后在IO多路复用中以技术演进的形式介绍了select,poll,epoll的原理和它们综合的对比。最后我们介绍了两种IO线程模型以及netty中的Reactor模型。感谢大家听我唠叨到这里，哈哈，现在大家可以揉揉眼，伸个懒腰，好好休息一下了。

从今天开始我们来聊聊Netty的那些事儿，我们都知道Netty是一个高性能异步事件驱动的网络框架。它的设计异常优雅简洁，扩展性高，稳定性强。拥有非常详细完整的用户文档。同时内置了很多非常有用的模块基本上做到了开箱即用，用户只需要编写短短几行代码，就可以快速构建出一个具有高吞吐，低延时，更少的资源消耗，高性能（非必要的内存拷贝最小化）等特征的高并发网络应用程序。本文我们来探讨下支持Netty具有高吞吐，低延时特征的基石----netty的网络IO模型。由Netty的网络IO模型开始，我们来正式揭开本系列Netty源码解析的序幕：网络包接收流程 当网络数据帧通过网络传输到达网卡时，网卡会将网络数据帧通过DMA的方式放到环形缓冲区RingBuffer中。RingBuffer是网卡在启动的时候分配和初始化的环形缓冲队列。当RingBuffer满的时候，新来的数据包就会被丢弃。我们可以通过ifconfig命令查看网卡收发数据包的情况。其中overruns数据项表示当RingBuffer满时，被丢弃的数据包。如果发现出现丢包情况，可以通过ethtool命令来增大RingBuffer长度。当DMA操作完成时，网卡会向CPU发起一个硬中断，告诉CPU有网络数据到达。CPU调用网卡驱动注册的硬中断响应程序。网卡硬中断响应程序会为网络数据帧创建内核数据结构sk_buffer，并将网络数据帧拷贝到sk_buffer中。然后发起软中断请求，通知内核有新的网络数据帧到达。sk_buff缓冲区，是一个维护网络帧结构的双向链表，链表中的每一个元素都是一个网络帧。虽然 TCP/IP 协议栈分了好几层，但上下不同层之间的传递，实际上只需要操作这个数据结构中的指针，而无需进行数据复制。内核线程ksoftirqd发现有软中断请求到来，随后调用网卡驱动注册的poll函数，poll函数将sk_buffer中的网络数据包送到内核协议栈中注册的ip_rcv函数中。每个CPU会绑定一个ksoftirqd内核线程专门用来处理软中断响应。2个 CPU 时，就会有 ksoftirqd/0 和 ksoftirqd/1这两个内核线程。这里有个事情需要注意下： 网卡接收到数据后，当DMA拷贝完成时，向CPU发出硬中断，这时哪个CPU上响应了这个硬中断，那么在网卡硬中断响应程序中发出的软中断请求也会在这个CPU绑定的ksoftirqd线程中响应。所以如果发现Linux软中断，CPU消耗都集中在一个核上的话，那么就需要调整硬中断的CPU亲和性，来将硬中断打散到不通的CPU核上去。在ip_rcv函数中也就是上图中的网络层，取出数据包的IP头，判断该数据包下一跳的走向，如果数据包是发送给本机的，则取出传输层的协议类型（TCP或者UDP)，并去掉数据包的IP头，将数据包交给上图中得传输层处理。传输层的处理函数：TCP协议对应内核协议栈中注册的tcp_rcv函数，UDP协议对应内核协议栈中注册的udp_rcv函数。当我们采用的是TCP协议时，数据包到达传输层时，会在内核协议栈中的tcp_rcv函数处理，在tcp_rcv函数中去掉TCP头，根据四元组（源IP，源端口，目的IP，目的端口）查找对应的Socket，如果找到对应的Socket则将网络数据包中的传输数据拷贝到Socket中的接收缓冲区中。如果没有找到，则发送一个目标不可达的icmp包。内核在接收网络数据包时所做的工作我们就介绍完了，现在我们把视角放到应用层，当我们程序通过系统调用read读取Socket接收缓冲区中的数据时，如果接收缓冲区中没有数据，那么应用程序就会在系统调用上阻塞，直到Socket接收缓冲区有数据，然后CPU将内核空间（Socket接收缓冲区）的数据拷贝到用户空间，最后系统调用read返回，应用程序读取数据。性能开销 从内核处理网络数据包接收的整个过程来看，内核帮我们做了非常之多的工作，最终我们的应用程序才能读取到网络数据。随着而来的也带来了很多的性能开销，结合前面介绍的网络数据包接收过程我们来看下网络数据包接收的过程中都有哪些性能开销：应用程序通过系统调用从用户态转为内核态的开销以及系统调用返回时从内核态转为用户态的开销。网络数据从内核空间通过CPU拷贝到用户空间的开销。内核线程ksoftirqd响应软中断的开销。CPU响应硬中断的开销。DMA拷贝网络数据包到内存中的开销。网络包发送流程 当我们在应用程序中调用send系统调用发送数据时，由于是系统调用所以线程会发生一次用户态到内核态的转换，在内核中首先根据fd将真正的Socket找出，这个Socket对象中记录着各种协议栈的函数地址，然后构造struct msghdr对象，将用户需要发送的数据全部封装在这个struct msghdr结构体中。调用内核协议栈函数inet_sendmsg，发送流程进入内核协议栈处理。在进入到内核协议栈之后，内核会找到Socket上的具体协议的发送函数。比如：我们使用的是TCP协议，对应的TCP协议发送函数是tcp_sendmsg，如果是UDP协议的话，对应的发送函数为udp_sendmsg。在TCP协议的发送函数tcp_sendmsg中，创建内核数据结构sk_buffer,将struct msghdr结构体中的发送数据拷贝到sk_buffer中。调用tcp_write_queue_tail函数获取Socket发送队列中的队尾元素，将新创建的sk_buffer添加到Socket发送队列的尾部。Socket的发送队列是由sk_buffer组成的一个双向链表。发送流程走到这里，用户要发送的数据总算是从用户空间拷贝到了内核中，这时虽然发送数据已经拷贝到了内核Socket中的发送队列中，但并不代表内核会开始发送，因为TCP协议的流量控制和拥塞控制，用户要发送的数据包并不一定会立马被发送出去，需要符合TCP协议的发送条件。如果没有达到发送条件，那么本次send系统调用就会直接返回。如果符合发送条件，则开始调用tcp_write_xmit内核函数。在这个函数中，会循环获取Socket发送队列中待发送的sk_buffer，然后进行拥塞控制以及滑动窗口的管理。将从Socket发送队列中获取到的sk_buffer重新拷贝一份，设置sk_buffer副本中的TCP HEADER。sk_buffer 内部其实包含了网络协议中所有的 header。在设置 TCP HEADER的时候，只是把指针指向 sk_buffer的合适位置。后面再设置 IP HEADER的时候，在把指针移动一下就行，避免频繁的内存申请和拷贝，效率很高。为什么不直接使用Socket发送队列中的sk_buffer而是需要拷贝一份呢？因为TCP协议是支持丢包重传的，在没有收到对端的ACK之前，这个sk_buffer是不能删除的。内核每次调用网卡发送数据的时候，实际上传递的是sk_buffer的拷贝副本，当网卡把数据发送出去后，sk_buffer拷贝副本会被释放。当收到对端的ACK之后，Socket发送队列中的sk_buffer才会被真正删除。当设置完TCP头后，内核协议栈传输层的事情就做完了，下面通过调用ip_queue_xmit内核函数，正式来到内核协议栈网络层的处理。检查Socket中是否有缓存路由表，如果没有的话，则查找路由项，并缓存到Socket中。接着在把路由表设置到sk_buffer中。通过route命令可以查看本机路由配置。将sk_buffer中的指针移动到IP头位置上，设置IP头。执行netfilters过滤。过滤通过之后，如果数据大于 MTU的话，则执行分片。如果你使用 iptables配置了一些规则，那么这里将检测是否命中规则。 如果你设置了非常复杂的 netfilter 规则，在这个函数里将会导致你的线程 CPU 开销会极大增加。内核协议栈网络层的事情处理完后，现在发送流程进入了到了邻居子系统，邻居子系统位于内核协议栈中的网络层和网络接口层之间，用于发送ARP请求获取MAC地址，然后将sk_buffer中的指针移动到MAC头位置，填充MAC头。经过邻居子系统的处理，现在sk_buffer中已经封装了一个完整的数据帧，随后内核将sk_buffer交给网络设备子系统进行处理。网络设备子系统主要做以下几项事情：选择发送队列（RingBuffer）。因为网卡拥有多个发送队列，所以在发送前需要选择一个发送队列。将sk_buffer添加到发送队列中。循环从发送队列（RingBuffer）中取出sk_buffer，调用内核函数sch_direct_xmit发送数据，其中会调用网卡驱动程序来发送数据。以上过程全部是用户线程的内核态在执行，占用的CPU时间是系统态时间(sy)，当分配给用户线程的CPU quota用完的时候，会触发NET_TX_SOFTIRQ类型的软中断，内核线程ksoftirqd会响应这个软中断，并执行NET_TX_SOFTIRQ类型的软中断注册的回调函数net_tx_action，在回调函数中会执行到驱动程序函数 dev_hard_start_xmit来发送数据。注意：当触发NET_TX_SOFTIRQ软中断来发送数据时，后边消耗的 CPU 就都显示在 si这里了，不会消耗用户进程的系统态时间（sy）了。从这里可以看到网络包的发送过程和接受过程是不同的，在介绍网络包的接受过程时，我们提到是通过触发NET_RX_SOFTIRQ类型的软中断在内核线程ksoftirqd中执行内核网络协议栈接受数据。而在网络数据包的发送过程中是用户线程的内核态在执行内核网络协议栈，只有当线程的CPU quota用尽时，才触发NET_TX_SOFTIRQ软中断来发送数据。在整个网络包的发送和接受过程中，NET_TX_SOFTIRQ类型的软中断只会在发送网络包时并且当用户线程的CPU quota用尽时，才会触发。剩下的接受过程中触发的软中断类型以及发送完数据触发的软中断类型均为NET_RX_SOFTIRQ。 所以这就是你在服务器上查看 /proc/softirqs，一般 NET_RX都要比 NET_TX大很多的的原因。现在发送流程终于到了网卡真实发送数据的阶段，前边我们讲到无论是用户线程的内核态还是触发NET_TX_SOFTIRQ类型的软中断在发送数据的时候最终会调用到网卡的驱动程序函数dev_hard_start_xmit来发送数据。在网卡驱动程序函数dev_hard_start_xmit中会将sk_buffer映射到网卡可访问的内存 DMA 区域，最终网卡驱动程序通过DMA的方式将数据帧通过物理网卡发送出去。当数据发送完毕后，还有最后一项重要的工作，就是清理工作。数据发送完毕后，网卡设备会向CPU发送一个硬中断，CPU调用网卡驱动程序注册的硬中断响应程序，在硬中断响应中触发NET_RX_SOFTIRQ类型的软中断，在软中断的回调函数igb_poll中清理释放 sk_buffer，清理网卡发送队列（RingBuffer），解除 DMA 映射。无论硬中断是因为有数据要接收，还是说发送完成通知，从硬中断触发的软中断都是 NET_RX_SOFTIRQ。这里释放清理的只是sk_buffer的副本，真正的sk_buffer现在还是存放在Socket的发送队列中。前面在传输层处理的时候我们提到过，因为传输层需要保证可靠性，所以 sk_buffer其实还没有删除。它得等收到对方的 ACK 之后才会真正删除。性能开销 前边我们提到了在网络包接收过程中涉及到的性能开销，现在介绍完了网络包的发送过程，我们来看下在数据包发送过程中的性能开销：和接收数据一样，应用程序在调用系统调用send的时候会从用户态转为内核态以及发送完数据后，系统调用返回时从内核态转为用户态的开销。用户线程内核态CPU quota用尽时触发NET_TX_SOFTIRQ类型软中断，内核响应软中断的开销。网卡发送完数据，向CPU发送硬中断，CPU响应硬中断的开销。以及在硬中断中发送NET_RX_SOFTIRQ软中断执行具体的内存清理动作。内核响应软中断的开销。内存拷贝的开销。我们来回顾下在数据包发送的过程中都发生了哪些内存拷贝：在内核协议栈的传输层中，TCP协议对应的发送函数tcp_sendmsg会申请sk_buffer，将用户要发送的数据拷贝到sk_buffer中。在发送流程从传输层到网络层的时候，会拷贝一个sk_buffer副本出来，将这个sk_buffer副本向下传递。原始sk_buffer保留在Socket发送队列中，等待网络对端ACK，对端ACK后删除Socket发送队列中的sk_buffer。对端没有发送ACK，则重新从Socket发送队列中发送，实现TCP协议的可靠传输。在网络层，如果发现要发送的数据大于MTU，则会进行分片操作，申请额外的sk_buffer，并将原来的sk_buffer拷贝到多个小的sk_buffer中。再谈(阻塞，非阻塞)与(同步，异步) 在我们聊完网络数据的接收和发送过程后，我们来谈下IO中特别容易混淆的概念：阻塞与同步，非阻塞与异步。网上各种博文还有各种书籍中有大量的关于这两个概念的解释，但是笔者觉得还是不够形象化，只是对概念的生硬解释，如果硬套概念的话，其实感觉阻塞与同步，非阻塞与异步还是没啥区别，时间长了，还是比较模糊容易混淆。所以笔者在这里尝试换一种更加形象化，更加容易理解记忆的方式来清晰地解释下什么是阻塞与非阻塞，什么是同步与异步。经过前边对网络数据包接收流程的介绍，在这里我们可以将整个流程总结为两个阶段：数据准备阶段： 在这个阶段，网络数据包到达网卡，通过DMA的方式将数据包拷贝到内存中，然后经过硬中断，软中断，接着通过内核线程ksoftirqd经过内核协议栈的处理，最终将数据发送到内核Socket的接收缓冲区中。数据拷贝阶段： 当数据到达内核Socket的接收缓冲区中时，此时数据存在于内核空间中，需要将数据拷贝到用户空间中，才能够被应用程序读取。阻塞与非阻塞 阻塞与非阻塞的区别主要发生在第一阶段：数据准备阶段。当应用程序发起系统调用read时，线程从用户态转为内核态，读取内核Socket的接收缓冲区中的网络数据。阻塞如果这时内核Socket的接收缓冲区没有数据，那么线程就会一直等待，直到Socket接收缓冲区有数据为止。随后将数据从内核空间拷贝到用户空间，系统调用read返回。从图中我们可以看出：阻塞的特点是在第一阶段和第二阶段都会等待。非阻塞阻塞和非阻塞主要的区分是在第一阶段：数据准备阶段。在第一阶段，当Socket的接收缓冲区中没有数据的时候，阻塞模式下应用线程会一直等待。非阻塞模式下应用线程不会等待，系统调用直接返回错误标志EWOULDBLOCK。当Socket的接收缓冲区中有数据的时候，阻塞和非阻塞的表现是一样的，都会进入第二阶段等待数据从内核空间拷贝到用户空间，然后系统调用返回。从上图中，我们可以看出：非阻塞的特点是第一阶段不会等待，但是在第二阶段还是会等待。同步与异步 同步与异步主要的区别发生在第二阶段：数据拷贝阶段。前边我们提到在数据拷贝阶段主要是将数据从内核空间拷贝到用户空间。然后应用程序才可以读取数据。当内核Socket的接收缓冲区有数据到达时，进入第二阶段。同步同步模式在数据准备好后，是由用户线程的内核态来执行第二阶段。所以应用程序会在第二阶段发生阻塞，直到数据从内核空间拷贝到用户空间，系统调用才会返回。Linux下的 epoll和Mac 下的 kqueue都属于同步 IO。异步异步模式下是由内核来执行第二阶段的数据拷贝操作，当内核执行完第二阶段，会通知用户线程IO操作已经完成，并将数据回调给用户线程。所以在异步模式下 数据准备阶段和数据拷贝阶段均是由内核来完成，不会对应用程序造成任何阻塞。基于以上特征，我们可以看到异步模式需要内核的支持，比较依赖操作系统底层的支持。在目前流行的操作系统中，只有Windows 中的 IOCP才真正属于异步 IO，实现的也非常成熟。但Windows很少用来作为服务器使用。而常用来作为服务器使用的Linux，异步IO机制实现的不够成熟，与NIO相比性能提升的也不够明显。但Linux kernel 在5.1版本由Facebook的大神Jens Axboe引入了新的异步IO库io_uring 改善了原来Linux native AIO的一些性能问题。性能相比Epoll以及之前原生的AIO提高了不少，值得关注。IO模型 在进行网络IO操作时，用什么样的IO模型来读写数据将在很大程度上决定了网络框架的IO性能。所以IO模型的选择是构建一个高性能网络框架的基础。在《UNIX 网络编程》一书中介绍了五种IO模型：阻塞IO,非阻塞IO,IO多路复用,信号驱动IO,异步IO，每一种IO模型的出现都是对前一种的升级优化。下面我们就来分别介绍下这五种IO模型各自都解决了什么问题，适用于哪些场景，各自的优缺点是什么？阻塞IO（BIO） 经过前一小节对阻塞这个概念的介绍，相信大家可以很容易理解阻塞IO的概念和过程。既然这小节我们谈的是IO，那么下边我们来看下在阻塞IO模型下，网络数据的读写过程。阻塞读当用户线程发起read系统调用，用户线程从用户态切换到内核态，在内核中去查看Socket接收缓冲区是否有数据到来。Socket接收缓冲区中有数据，则用户线程在内核态将内核空间中的数据拷贝到用户空间，系统IO调用返回。Socket接收缓冲区中无数据，则用户线程让出CPU，进入阻塞状态。当数据到达Socket接收缓冲区后，内核唤醒阻塞状态中的用户线程进入就绪状态，随后经过CPU的调度获取到CPU quota进入运行状态，将内核空间的数据拷贝到用户空间，随后系统调用返回。阻塞写当用户线程发起send系统调用时，用户线程从用户态切换到内核态，将发送数据从用户空间拷贝到内核空间中的Socket发送缓冲区中。当Socket发送缓冲区能够容纳下发送数据时，用户线程会将全部的发送数据写入Socket缓冲区，然后执行在《网络包发送流程》这小节介绍的后续流程，然后返回。当Socket发送缓冲区空间不够，无法容纳下全部发送数据时，用户线程让出CPU,进入阻塞状态，直到Socket发送缓冲区能够容纳下全部发送数据时，内核唤醒用户线程，执行后续发送流程。阻塞IO模型下的写操作做事风格比较硬刚，非得要把全部的发送数据写入发送缓冲区才肯善罢甘休。阻塞IO模型 由于阻塞IO的读写特点，所以导致在阻塞IO模型下，每个请求都需要被一个独立的线程处理。一个线程在同一时刻只能与一个连接绑定。来一个请求，服务端就需要创建一个线程用来处理请求。当客户端请求的并发量突然增大时，服务端在一瞬间就会创建出大量的线程，而创建线程是需要系统资源开销的，这样一来就会一瞬间占用大量的系统资源。如果客户端创建好连接后，但是一直不发数据，通常大部分情况下，网络连接也并不总是有数据可读，那么在空闲的这段时间内，服务端线程就会一直处于阻塞状态，无法干其他的事情。CPU也无法得到充分的发挥，同时还会导致大量线程切换的开销。适用场景 基于以上阻塞IO模型的特点，该模型只适用于连接数少，并发度低的业务场景。比如公司内部的一些管理系统，通常请求数在100个左右，使用阻塞IO模型还是非常适合的。而且性能还不输NIO。该模型在C10K之前，是普遍被采用的一种IO模型。非阻塞IO（NIO） 阻塞IO模型最大的问题就是一个线程只能处理一个连接，如果这个连接上没有数据的话，那么这个线程就只能阻塞在系统IO调用上，不能干其他的事情。这对系统资源来说，是一种极大的浪费。同时大量的线程上下文切换，也是一个巨大的系统开销。所以为了解决这个问题，我们就需要用尽可能少的线程去处理更多的连接。，网络IO模型的演变也是根据这个需求来一步一步演进的。基于这个需求，第一种解决方案非阻塞IO就出现了。我们在上一小节中介绍了非阻塞的概念，现在我们来看下网络读写操作在非阻塞IO下的特点：非阻塞读当用户线程发起非阻塞read系统调用时，用户线程从用户态转为内核态，在内核中去查看Socket接收缓冲区是否有数据到来。Socket接收缓冲区中无数据，系统调用立马返回，并带有一个 EWOULDBLOCK 或 EAGAIN错误，这个阶段用户线程不会阻塞，也不会让出CPU，而是会继续轮训直到Socket接收缓冲区中有数据为止。Socket接收缓冲区中有数据，用户线程在内核态会将内核空间中的数据拷贝到用户空间，注意这个数据拷贝阶段，应用程序是阻塞的，当数据拷贝完成，系统调用返回。非阻塞写前边我们在介绍阻塞写的时候提到阻塞写的风格特别的硬朗，头比较铁非要把全部发送数据一次性都写到Socket的发送缓冲区中才返回，如果发送缓冲区中没有足够的空间容纳，那么就一直阻塞死等，特别的刚。相比较而言非阻塞写的特点就比较佛系，当发送缓冲区中没有足够的空间容纳全部发送数据时，非阻塞写的特点是能写多少写多少，写不下了，就立即返回。并将写入到发送缓冲区的字节数返回给应用程序，方便用户线程不断的轮训尝试将剩下的数据写入发送缓冲区中。非阻塞IO模型 基于以上非阻塞IO的特点，我们就不必像阻塞IO那样为每个请求分配一个线程去处理连接上的读写了。我们可以利用一个线程或者很少的线程，去不断地轮询每个Socket的接收缓冲区是否有数据到达，如果没有数据，不必阻塞线程，而是接着去轮询下一个Socket接收缓冲区，直到轮询到数据后，处理连接上的读写，或者交给业务线程池去处理，轮询线程则继续轮询其他的Socket接收缓冲区。这样一个非阻塞IO模型就实现了我们在本小节开始提出的需求：我们需要用尽可能少的线程去处理更多的连接适用场景 虽然非阻塞IO模型与阻塞IO模型相比，减少了很大一部分的资源消耗和系统开销。但是它仍然有很大的性能问题，因为在非阻塞IO模型下，需要用户线程去不断地发起系统调用去轮训Socket接收缓冲区，这就需要用户线程不断地从用户态切换到内核态，内核态切换到用户态。随着并发量的增大，这个上下文切换的开销也是巨大的。所以单纯的非阻塞IO模型还是无法适用于高并发的场景。只能适用于C10K以下的场景。IO多路复用 在非阻塞IO这一小节的开头，我们提到网络IO模型的演变都是围绕着---如何用尽可能少的线程去处理更多的连接这个核心需求开始展开的。本小节我们来谈谈IO多路复用模型，那么什么是多路？，什么又是复用呢？我们还是以这个核心需求来对这两个概念展开阐述：多路：我们的核心需求是要用尽可能少的线程来处理尽可能多的连接，这里的多路指的就是我们需要处理的众多连接。复用：核心需求要求我们使用尽可能少的线程，尽可能少的系统开销去处理尽可能多的连接（多路），那么这里的复用指的就是用有限的资源，比如用一个线程或者固定数量的线程去处理众多连接上的读写事件。换句话说，在阻塞IO模型中一个连接就需要分配一个独立的线程去专门处理这个连接上的读写，到了IO多路复用模型中，多个连接可以复用这一个独立的线程去处理这多个连接上的读写。好了，IO多路复用模型的概念解释清楚了，那么问题的关键是我们如何去实现这个复用，也就是如何让一个独立的线程去处理众多连接上的读写事件呢？这个问题其实在非阻塞IO模型中已经给出了它的答案，在非阻塞IO模型中，利用非阻塞的系统IO调用去不断的轮询众多连接的Socket接收缓冲区看是否有数据到来，如果有则处理，如果没有则继续轮询下一个Socket。这样就达到了用一个线程去处理众多连接上的读写事件了。但是非阻塞IO模型最大的问题就是需要不断的发起系统调用去轮询各个Socket中的接收缓冲区是否有数据到来，频繁的系统调用随之带来了大量的上下文切换开销。随着并发量的提升，这样也会导致非常严重的性能问题。那么如何避免频繁的系统调用同时又可以实现我们的核心需求呢？这就需要操作系统的内核来支持这样的操作，我们可以把频繁的轮询操作交给操作系统内核来替我们完成，这样就避免了在用户空间频繁的去使用系统调用来轮询所带来的性能开销。正如我们所想，操作系统内核也确实为我们提供了这样的功能实现，下面我们来一起看下操作系统对IO多路复用模型的实现。select select是操作系统内核提供给我们使用的一个系统调用，它解决了在非阻塞IO模型中需要不断的发起系统IO调用去轮询各个连接上的Socket接收缓冲区所带来的用户空间与内核空间不断切换的系统开销。select系统调用将轮询的操作交给了内核来帮助我们完成，从而避免了在用户空间不断的发起轮询所带来的的系统性能开销。首先用户线程在发起select系统调用的时候会阻塞在select系统调用上。此时，用户线程从用户态切换到了内核态完成了一次上下文切换用户线程将需要监听的Socket对应的文件描述符fd数组通过select系统调用传递给内核。此时，用户线程将用户空间中的文件描述符fd数组拷贝到内核空间。这里的文件描述符数组其实是一个BitMap，BitMap下标为文件描述符fd，下标对应的值为：1表示该fd上有读写事件，0表示该fd上没有读写事件。文件描述符fd其实就是一个整数值，在Linux中一切皆文件，Socket也是一个文件。描述进程所有信息的数据结构task_struct中有一个属性struct files_struct *files，它最终指向了一个数组，数组里存放了进程打开的所有文件列表，文件信息封装在struct file结构体中，这个数组存放的类型就是struct file结构体，数组的下标则是我们常说的文件描述符fd。当用户线程调用完select后开始进入阻塞状态，内核开始轮询遍历fd数组，查看fd对应的Socket接收缓冲区中是否有数据到来。如果有数据到来，则将fd对应BitMap的值设置为1。如果没有数据到来，则保持值为0。注意这里内核会修改原始的fd数组！！内核遍历一遍fd数组后，如果发现有些fd上有IO数据到来，则将修改后的fd数组返回给用户线程。此时，会将fd数组从内核空间拷贝到用户空间。当内核将修改后的fd数组返回给用户线程后，用户线程解除阻塞，由用户线程开始遍历fd数组然后找出fd数组中值为1的Socket文件描述符。最后对这些Socket发起系统调用读取数据。select不会告诉用户线程具体哪些fd上有IO数据到来，只是在IO活跃的fd上打上标记，将打好标记的完整fd数组返回给用户线程，所以用户线程还需要遍历fd数组找出具体哪些fd上有IO数据到来。由于内核在遍历的过程中已经修改了fd数组，所以在用户线程遍历完fd数组后获取到IO就绪的Socket后，就需要重置fd数组，并重新调用select传入重置后的fd数组，让内核发起新的一轮遍历轮询。API介绍当我们熟悉了select的原理后，就很容易理解内核给我们提供的select API了。 int select(int maxfdp1,fd_set *readset,fd_set *writeset,fd_set *exceptset,const struct timeval *timeout)从select API中我们可以看到，select系统调用是在规定的超时时间内，监听（轮询）用户感兴趣的文件描述符集合上的可读,可写,异常三类事件。maxfdp1 ： select传递给内核监听的文件描述符集合中数值最大的文件描述符+1，目的是用于限定内核遍历范围。比如：select监听的文件描述符集合为{0,1,2,3,4}，那么maxfdp1的值为5。fd_set *readset： 对可读事件感兴趣的文件描述符集合。fd_set *writeset： 对可写事件感兴趣的文件描述符集合。fd_set *exceptset：对可写事件感兴趣的文件描述符集合。这里的fd_set就是我们前边提到的文件描述符数组，是一个BitMap结构。const struct timeval *timeout：select系统调用超时时间，在这段时间内，内核如果没有发现有IO就绪的文件描述符，就直接返回。上小节提到，在内核遍历完fd数组后，发现有IO就绪的fd，则会将该fd对应的BitMap中的值设置为1，并将修改后的fd数组，返回给用户线程。在用户线程中需要重新遍历fd数组，找出IO就绪的fd出来，然后发起真正的读写调用。下面介绍下在用户线程中重新遍历fd数组的过程中，我们需要用到的API：void FD_ZERO(fd_set *fdset)：清空指定的文件描述符集合，即让fd_set中不在包含任何文件描述符。void FD_SET(int fd, fd_set *fdset)：将一个给定的文件描述符加入集合之中。每次调用select之前都要通过FD_ZERO和FD_SET重新设置文件描述符，因为文件描述符集合会在内核中被修改。int FD_ISSET(int fd, fd_set *fdset)：检查集合中指定的文件描述符是否可以读写。用户线程遍历文件描述符集合,调用该方法检查相应的文件描述符是否IO就绪。void FD_CLR(int fd, fd_set *fdset)：将一个给定的文件描述符从集合中删除性能开销虽然select解决了非阻塞IO模型中频繁发起系统调用的问题，但是在整个select工作过程中，我们还是看出了select有些不足的地方。在发起select系统调用以及返回时，用户线程各发生了一次用户态到内核态以及内核态到用户态的上下文切换开销。发生2次上下文切换在发起select系统调用以及返回时，用户线程在内核态需要将文件描述符集合从用户空间拷贝到内核空间。以及在内核修改完文件描述符集合后，又要将它从内核空间拷贝到用户空间。发生2次文件描述符集合的拷贝虽然由原来在用户空间发起轮询优化成了在内核空间发起轮询但select不会告诉用户线程到底是哪些Socket上发生了IO就绪事件，只是对IO就绪的Socket作了标记，用户线程依然要遍历文件描述符集合去查找具体IO就绪的Socket。时间复杂度依然为O(n)。大部分情况下，网络连接并不总是活跃的，如果select监听了大量的客户端连接，只有少数的连接活跃，然而使用轮询的这种方式会随着连接数的增大，效率会越来越低。内核会对原始的文件描述符集合进行修改。导致每次在用户空间重新发起select调用时，都需要对文件描述符集合进行重置。BitMap结构的文件描述符集合，长度为固定的1024,所以只能监听0~1023的文件描述符。select系统调用 不是线程安全的。以上select的不足所产生的性能开销都会随着并发量的增大而线性增长。很明显select也不能解决C10K问题，只适用于1000个左右的并发连接场景。poll poll相当于是改进版的select，但是工作原理基本和select没有本质的区别。int poll(struct pollfd *fds, unsigned int nfds, int timeout)struct pollfd {    int   fd;         /* 文件描述符 */    short events;     /* 需要监听的事件 */    short revents;    /* 实际发生的事件 由内核修改设置 */};select中使用的文件描述符集合是采用的固定长度为1024的BitMap结构的fd_set，而poll换成了一个pollfd结构没有固定长度的数组，这样就没有了最大描述符数量的限制（当然还会受到系统文件描述符限制）poll只是改进了select只能监听1024个文件描述符的数量限制，但是并没有在性能方面做出改进。和select上本质并没有多大差别。同样需要在内核空间和用户空间中对文件描述符集合进行轮询，查找出IO就绪的Socket的时间复杂度依然为O(n)。同样需要将包含大量文件描述符的集合整体在用户空间和内核空间之间来回复制，无论这些文件描述符是否就绪。他们的开销都会随着文件描述符数量的增加而线性增大。select，poll在每次新增，删除需要监听的socket时，都需要将整个新的socket集合全量传至内核。poll同样不适用高并发的场景。依然无法解决C10K问题。epoll 通过上边对select,poll核心原理的介绍，我们看到select,poll的性能瓶颈主要体现在下面三个地方：因为内核不会保存我们要监听的socket集合，所以在每次调用select,poll的时候都需要传入，传出全量的socket文件描述符集合。这导致了大量的文件描述符在用户空间和内核空间频繁的来回复制。由于内核不会通知具体IO就绪的socket，只是在这些IO就绪的socket上打好标记，所以当select系统调用返回时，在用户空间还是需要完整遍历一遍socket文件描述符集合来获取具体IO就绪的socket。在内核空间中也是通过遍历的方式来得到IO就绪的socket。下面我们来看下epoll是如何解决这些问题的。在介绍epoll的核心原理之前，我们需要介绍下理解epoll工作过程所需要的一些核心基础知识。Socket的创建服务端线程调用accept系统调用后开始阻塞，当有客户端连接上来并完成TCP三次握手后，内核会创建一个对应的Socket作为服务端与客户端通信的内核接口。在Linux内核的角度看来，一切皆是文件，Socket也不例外，当内核创建出Socket之后，会将这个Socket放到当前进程所打开的文件列表中管理起来。下面我们来看下进程管理这些打开的文件列表相关的内核数据结构是什么样的？在了解完这些数据结构后，我们会更加清晰的理解Socket在内核中所发挥的作用。并且对后面我们理解epoll的创建过程有很大的帮助。进程中管理文件列表结构struct tast_struct是内核中用来表示进程的一个数据结构，它包含了进程的所有信息。本小节我们只列出和文件管理相关的属性。其中进程内打开的所有文件是通过一个数组fd_array来进行组织管理，数组的下标即为我们常提到的文件描述符，数组中存放的是对应的文件数据结构struct file。每打开一个文件，内核都会创建一个struct file与之对应，并在fd_array中找到一个空闲位置分配给它，数组中对应的下标，就是我们在用户空间用到的文件描述符。对于任何一个进程，默认情况下，文件描述符 0表示 stdin 标准输入，文件描述符 1表示stdout 标准输出，文件描述符2表示stderr 标准错误输出。进程中打开的文件列表fd_array定义在内核数据结构struct files_struct中，在struct fdtable结构中有一个指针struct fd **fd指向fd_array。由于本小节讨论的是内核网络系统部分的数据结构，所以这里拿Socket文件类型来举例说明：用于封装文件元信息的内核数据结构struct file中的private_data指针指向具体的Socket结构。struct file中的file_operations属性定义了文件的操作函数，不同的文件类型，对应的file_operations是不同的，针对Socket文件类型，这里的file_operations指向socket_file_ops。我们在用户空间对Socket发起的读写等系统调用，进入内核首先会调用的是Socket对应的struct file中指向的socket_file_ops。比如：对Socket发起write写操作，在内核中首先被调用的就是socket_file_ops中定义的sock_write_iter。Socket发起read读操作内核中对应的则是sock_read_iter。static const struct file_operations socket_file_ops = {  .owner =  THIS_MODULE,  .llseek =  no_llseek,  .read_iter =  sock_read_iter,  .write_iter =  sock_write_iter,  .poll =    sock_poll,  .unlocked_ioctl = sock_ioctl,  .mmap =    sock_mmap,  .release =  sock_close,  .fasync =  sock_fasync,  .sendpage =  sock_sendpage,  .splice_write = generic_splice_sendpage,  .splice_read =  sock_splice_read,};Socket内核结构在我们进行网络程序的编写时会首先创建一个Socket，然后基于这个Socket进行bind，listen，我们先将这个Socket称作为监听Socket。当我们调用accept后，内核会基于监听Socket创建出来一个新的Socket专门用于与客户端之间的网络通信。并将监听Socket中的Socket操作函数集合（inet_stream_ops）ops赋值到新的Socket的ops属性中。const struct proto_ops inet_stream_ops = {  .bind = inet_bind,  .connect = inet_stream_connect,  .accept = inet_accept,  .poll = tcp_poll,  .listen = inet_listen,  .sendmsg = inet_sendmsg,  .recvmsg = inet_recvmsg,  ......}这里需要注意的是，监听的 socket和真正用来网络通信的 Socket，是两个 Socket，一个叫作监听 Socket，一个叫作已连接的Socket。接着内核会为已连接的Socket创建struct file并初始化，并把Socket文件操作函数集合（socket_file_ops）赋值给struct file中的f_ops指针。然后将struct socket中的file指针指向这个新分配申请的struct file结构体。内核会维护两个队列：一个是已经完成TCP三次握手，连接状态处于established的连接队列。内核中为icsk_accept_queue。一个是还没有完成TCP三次握手，连接状态处于syn_rcvd的半连接队列。然后调用socket->ops->accept，从Socket内核结构图中我们可以看到其实调用的是inet_accept，该函数会在icsk_accept_queue中查找是否有已经建立好的连接，如果有的话，直接从icsk_accept_queue中获取已经创建好的struct sock。并将这个struct sock对象赋值给struct socket中的sock指针。struct sock在struct socket中是一个非常核心的内核对象，正是在这里定义了我们在介绍网络包的接收发送流程中提到的接收队列，发送队列，等待队列，数据就绪回调函数指针，内核协议栈操作函数集合根据创建Socket时发起的系统调用sock_create中的protocol参数(对于TCP协议这里的参数值为SOCK_STREAM)查找到对于 tcp 定义的操作方法实现集合 inet_stream_ops 和tcp_prot。并把它们分别设置到socket->ops和sock->sk_prot上。这里可以回看下本小节开头的《Socket内核结构图》捋一下他们之间的关系。socket相关的操作接口定义在inet_stream_ops函数集合中，负责对上给用户提供接口。而socket与内核协议栈之间的操作接口定义在struct sock中的sk_prot指针上，这里指向tcp_prot协议操作函数集合。struct proto tcp_prot = {  .name      = "TCP",  .owner      = THIS_MODULE,  .close      = tcp_close,  .connect    = tcp_v4_connect,  .disconnect    = tcp_disconnect,  .accept      = inet_csk_accept,  .keepalive    = tcp_set_keepalive,  .recvmsg    = tcp_recvmsg,  .sendmsg    = tcp_sendmsg,  .backlog_rcv    = tcp_v4_do_rcv,   ......}之前提到的对Socket发起的系统IO调用，在内核中首先会调用Socket的文件结构struct file中的file_operations文件操作集合，然后调用struct socket中的ops指向的inet_stream_opssocket操作函数，最终调用到struct sock中sk_prot指针指向的tcp_prot内核协议栈操作函数接口集合。将struct sock 对象中的sk_data_ready 函数指针设置为 sock_def_readable，在Socket数据就绪的时候内核会回调该函数。struct sock中的等待队列中存放的是系统IO调用发生阻塞的进程fd，以及相应的回调函数。记住这个地方，后边介绍epoll的时候我们还会提到！当struct file，struct socket，struct sock这些核心的内核对象创建好之后，最后就是把socket对象对应的struct file放到进程打开的文件列表fd_array中。随后系统调用accept返回socket的文件描述符fd给用户程序。阻塞IO中用户进程阻塞以及唤醒原理在前边小节我们介绍阻塞IO的时候提到，当用户进程发起系统IO调用时，这里我们拿read举例，用户进程会在内核态查看对应Socket接收缓冲区是否有数据到来。Socket接收缓冲区有数据，则拷贝数据到用户空间，系统调用返回。Socket接收缓冲区没有数据，则用户进程让出CPU进入阻塞状态，当数据到达接收缓冲区时，用户进程会被唤醒，从阻塞状态进入就绪状态，等待CPU调度。本小节我们就来看下用户进程是如何阻塞在Socket上，又是如何在Socket上被唤醒的。理解这个过程很重要，对我们理解epoll的事件通知过程很有帮助首先我们在用户进程中对Socket进行read系统调用时，用户进程会从用户态转为内核态。在进程的struct task_struct结构找到fd_array，并根据Socket的文件描述符fd找到对应的struct file，调用struct file中的文件操作函数结合file_operations，read系统调用对应的是sock_read_iter。在sock_read_iter函数中找到struct file指向的struct socket，并调用socket->ops->recvmsg，这里我们知道调用的是inet_stream_ops集合中定义的inet_recvmsg。在inet_recvmsg中会找到struct sock，并调用sock->skprot->recvmsg,这里调用的是tcp_prot集合中定义的tcp_recvmsg函数。整个调用过程可以参考上边的《系统IO调用结构图》熟悉了内核函数调用栈后，我们来看下系统IO调用在tcp_recvmsg内核函数中是如何将用户进程给阻塞掉的int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t len, int nonblock, int flags, int *addr_len){    .................省略非核心代码...............   //访问sock对象中定义的接收队列  skb_queue_walk(&sk->sk_receive_queue, skb) {    .................省略非核心代码............... //没有收到足够数据，调用sk_wait_data 阻塞当前进程  sk_wait_data(sk, &timeo);}int sk_wait_data(struct sock *sk, long *timeo){ //创建struct sock中等待队列上的元素wait_queue_t //将进程描述符和回调函数autoremove_wake_function关联到wait_queue_t中 DEFINE_WAIT(wait); // 调用 sk_sleep 获取 sock 对象下的等待队列的头指针wait_queue_head_t // 调用prepare_to_wait将新创建的等待项wait_queue_t插入到等待队列中，并将进程状态设置为可打断 INTERRUPTIBLE prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE); set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags); // 通过调用schedule_timeout让出CPU，然后进行睡眠，导致一次上下文切换 rc = sk_wait_event(sk, timeo, !skb_queue_empty(&sk->sk_receive_queue)); ...首先会在DEFINE_WAIT中创建struct sock中等待队列上的等待类型wait_queue_t。#define DEFINE_WAIT(name) DEFINE_WAIT_FUNC(name, autoremove_wake_function)#define DEFINE_WAIT_FUNC(name, function)    \ wait_queue_t name = {      \  .private = current,    \  .func  = function,    \  .task_list = LIST_HEAD_INIT((name).task_list), \ }等待类型wait_queue_t中的private用来关联阻塞在当前socket上的用户进程fd。func用来关联等待项上注册的回调函数。这里注册的是autoremove_wake_function。调用sk_sleep(sk)获取struct sock对象中的等待队列头指针wait_queue_head_t。调用prepare_to_wait将新创建的等待项wait_queue_t插入到等待队列中，并将进程设置为可打断 INTERRUPTIBL。调用sk_wait_event让出CPU，进程进入睡眠状态。用户进程的阻塞过程我们就介绍完了，关键是要理解记住struct sock中定义的等待队列上的等待类型wait_queue_t的结构。后面epoll的介绍中我们还会用到它。下面我们接着介绍当数据就绪后，用户进程是如何被唤醒的在本文开始介绍《网络包接收过程》这一小节中我们提到：当网络数据包到达网卡时，网卡通过DMA的方式将数据放到RingBuffer中。然后向CPU发起硬中断，在硬中断响应程序中创建sk_buffer，并将网络数据拷贝至sk_buffer中。随后发起软中断，内核线程ksoftirqd响应软中断，调用poll函数将sk_buffer送往内核协议栈做层层协议处理。在传输层tcp_rcv 函数中，去掉TCP头，根据四元组（源IP，源端口，目的IP，目的端口）查找对应的Socket。最后将sk_buffer放到Socket中的接收队列里。上边这些过程是内核接收网络数据的完整过程，下边我们来看下，当数据包接收完毕后，用户进程是如何被唤醒的。当软中断将sk_buffer放到Socket的接收队列上时，接着就会调用数据就绪函数回调指针sk_data_ready，前边我们提到，这个函数指针在初始化的时候指向了sock_def_readable函数。在sock_def_readable函数中会去获取socket->sock->sk_wq等待队列。在wake_up_common函数中从等待队列sk_wq中找出一个等待项wait_queue_t，回调注册在该等待项上的func回调函数（wait_queue_t->func）,创建等待项wait_queue_t是我们提到，这里注册的回调函数是autoremove_wake_function。即使是有多个进程都阻塞在同一个 socket 上，也只唤醒 1 个进程。其作用是为了避免惊群。在autoremove_wake_function函数中，根据等待项wait_queue_t上的private关联的阻塞进程fd调用try_to_wake_up唤醒阻塞在该Socket上的进程。记住wait_queue_t中的func函数指针，在epoll中这里会注册epoll的回调函数。现在理解epoll所需要的基础知识我们就介绍完了，唠叨了这么多，下面终于正式进入本小节的主题epoll了。epoll_create创建epoll对象epoll_create是内核提供给我们创建epoll对象的一个系统调用，当我们在用户进程中调用epoll_create时，内核会为我们创建一个struct eventpoll对象，并且也有相应的struct file与之关联，同样需要把这个struct eventpoll对象所关联的struct file放入进程打开的文件列表fd_array中管理。熟悉了Socket的创建逻辑，epoll的创建逻辑也就不难理解了。struct eventpoll对象关联的struct file中的file_operations 指针指向的是eventpoll_fops操作函数集合。static const struct file_operations eventpoll_fops = {     .release = ep_eventpoll_release;     .poll = ep_eventpoll_poll,}struct eventpoll {    //等待队列，阻塞在epoll上的进程会放在这里    wait_queue_head_t wq;    //就绪队列，IO就绪的socket连接会放在这里    struct list_head rdllist;    //红黑树用来管理所有监听的socket连接    struct rb_root rbr;    ......}wait_queue_head_t wq：epoll中的等待队列，队列里存放的是阻塞在epoll上的用户进程。在IO就绪的时候epoll可以通过这个队列找到这些阻塞的进程并唤醒它们，从而执行IO调用读写Socket上的数据。这里注意与Socket中的等待队列区分！！！struct list_head rdllist：epoll中的就绪队列，队列里存放的是都是IO就绪的Socket，被唤醒的用户进程可以直接读取这个队列获取IO活跃的Socket。无需再次遍历整个Socket集合。这里正是epoll比select ，poll高效之处，select ，poll返回的是全部的socket连接，我们需要在用户空间再次遍历找出真正IO活跃的Socket连接。 而epoll只是返回IO活跃的Socket连接。用户进程可以直接进行IO操作。struct rb_root rbr : 由于红黑树在查找，插入，删除等综合性能方面是最优的，所以epoll内部使用一颗红黑树来管理海量的Socket连接。select用数组管理连接，poll用链表管理连接。epoll_ctl向epoll对象中添加监听的Socket当我们调用epoll_create在内核中创建出epoll对象struct eventpoll后，我们就可以利用epoll_ctl向epoll中添加我们需要管理的Socket连接了。首先要在epoll内核中创建一个表示Socket连接的数据结构struct epitem，而在epoll中为了综合性能的考虑，采用一颗红黑树来管理这些海量socket连接。所以struct epitem是一个红黑树节点。struct epitem{      //指向所属epoll对象      struct eventpoll *ep;      //注册的感兴趣的事件,也就是用户空间的epoll_event           struct epoll_event event;      //指向epoll对象中的就绪队列      struct list_head rdllink;       //指向epoll中对应的红黑树节点      struct rb_node rbn;          //指向epitem所表示的socket->file结构以及对应的fd      struct epoll_filefd ffd;                   }这里重点记住struct epitem结构中的rdllink以及epoll_filefd成员，后面我们会用到。在内核中创建完表示Socket连接的数据结构struct epitem后，我们就需要在Socket中的等待队列上创建等待项wait_queue_t并且注册epoll的回调函数ep_poll_callback。通过《阻塞IO中用户进程阻塞以及唤醒原理》小节的铺垫，我想大家已经猜到这一步的意义所在了吧！当时在等待项wait_queue_t中注册的是autoremove_wake_function回调函数。还记得吗？epoll的回调函数ep_poll_callback正是epoll同步IO事件通知机制的核心所在，也是区别于select，poll采用内核轮询方式的根本性能差异所在。这里又出现了一个新的数据结构struct eppoll_entry，那它的作用是干什么的呢？大家可以结合上图先猜测下它的作用!我们知道socket->sock->sk_wq等待队列中的类型是wait_queue_t，我们需要在struct epitem所表示的socket的等待队列上注册epoll回调函数ep_poll_callback。这样当数据到达socket中的接收队列时，内核会回调sk_data_ready，在阻塞IO中用户进程阻塞以及唤醒原理这一小节中，我们知道这个sk_data_ready函数指针会指向sk_def_readable函数，在sk_def_readable中会回调注册在等待队列里的等待项wait_queue_t -> func回调函数ep_poll_callback。在ep_poll_callback中需要找到epitem，将IO就绪的epitem放入epoll中的就绪队列中。而socket等待队列中类型是wait_queue_t无法关联到epitem。所以就出现了struct eppoll_entry结构体，它的作用就是关联Socket等待队列中的等待项wait_queue_t和epitem。struct eppoll_entry {   //指向关联的epitem   struct epitem *base; // 关联监听socket中等待队列中的等待项 (private = null  func = ep_poll_callback)   wait_queue_t wait;     // 监听socket中等待队列头指针   wait_queue_head_t *whead;    .........  }; 这样在ep_poll_callback回调函数中就可以根据Socket等待队列中的等待项wait，通过container_of宏找到eppoll_entry，继而找到epitem了。container_of在Linux内核中是一个常用的宏，用于从包含在某个结构中的指针获得结构本身的指针，通俗地讲就是通过结构体变量中某个成员的首地址进而获得整个结构体变量的首地址。这里需要注意下这次等待项wait_queue_t中的private设置的是null，因为这里Socket是交给epoll来管理的，阻塞在Socket上的进程是也由epoll来唤醒。在等待项wait_queue_t注册的func是ep_poll_callback而不是autoremove_wake_function，阻塞进程并不需要autoremove_wake_function来唤醒，所以这里设置private为null当在Socket的等待队列中创建好等待项wait_queue_t并且注册了epoll的回调函数ep_poll_callback，然后又通过eppoll_entry关联了epitem后。 剩下要做的就是将epitem插入到epoll中的红黑树struct rb_root rbr中。这里可以看到epoll另一个优化的地方，epoll将所有的socket连接通过内核中的红黑树来集中管理。每次添加或者删除socket连接都是增量添加删除，而不是像select，poll那样每次调用都是全量socket连接集合传入内核。避免了频繁大量的内存拷贝。epoll_wait同步阻塞获取IO就绪的Socket用户程序调用epoll_wait后，内核首先会查找epoll中的就绪队列eventpoll->rdllist是否有IO就绪的epitem。epitem里封装了socket的信息。如果就绪队列中有就绪的epitem，就将就绪的socket信息封装到epoll_event返回。如果eventpoll->rdllist就绪队列中没有IO就绪的epitem，则会创建等待项wait_queue_t，将用户进程的fd关联到wait_queue_t->private上，并在等待项wait_queue_t->func上注册回调函数default_wake_function。最后将等待项添加到epoll中的等待队列中。用户进程让出CPU，进入阻塞状态。这里和阻塞IO模型中的阻塞原理是一样的，只不过在阻塞IO模型中注册到等待项wait_queue_t->func上的是autoremove_wake_function，并将等待项添加到socket中的等待队列中。这里注册的是default_wake_function，将等待项添加到epoll中的等待队列上。前边做了那么多的知识铺垫，下面终于到了epoll的整个工作流程了：当网络数据包在软中断中经过内核协议栈的处理到达socket的接收缓冲区时，紧接着会调用socket的数据就绪回调指针sk_data_ready，回调函数为sock_def_readable。在socket的等待队列中找出等待项，其中等待项中注册的回调函数为ep_poll_callback。在回调函数ep_poll_callback中，根据struct eppoll_entry中的struct wait_queue_t wait通过container_of宏找到eppoll_entry对象并通过它的base指针找到封装socket的数据结构struct epitem，并将它加入到epoll中的就绪队列rdllist中。随后查看epoll中的等待队列中是否有等待项，也就是说查看是否有进程阻塞在epoll_wait上等待IO就绪的socket。如果没有等待项，则软中断处理完成。如果有等待项，则回到注册在等待项中的回调函数default_wake_function,在回调函数中唤醒阻塞进程，并将就绪队列rdllist中的epitem的IO就绪socket信息封装到struct epoll_event中返回。用户进程拿到epoll_event获取IO就绪的socket，发起系统IO调用读取数据。再谈水平触发和边缘触发 网上有大量的关于这两种模式的讲解，大部分讲的比较模糊，感觉只是强行从概念上进行描述，看完让人难以理解。所以在这里，笔者想结合上边epoll的工作过程，再次对这两种模式做下自己的解读，力求清晰的解释出这两种工作模式的异同。经过上边对epoll工作过程的详细解读，我们知道，当我们监听的socket上有数据到来时，软中断会执行epoll的回调函数ep_poll_callback,在回调函数中会将epoll中描述socket信息的数据结构epitem插入到epoll中的就绪队列rdllist中。随后用户进程从epoll的等待队列中被唤醒，epoll_wait将IO就绪的socket返回给用户进程，随即epoll_wait会清空rdllist。水平触发和边缘触发最关键的区别就在于当socket中的接收缓冲区还有数据可读时。epoll_wait是否会清空rdllist。水平触发：在这种模式下，用户线程调用epoll_wait获取到IO就绪的socket后，对Socket进行系统IO调用读取数据，假设socket中的数据只读了一部分没有全部读完，这时再次调用epoll_wait，epoll_wait会检查这些Socket中的接收缓冲区是否还有数据可读，如果还有数据可读，就将socket重新放回rdllist。所以当socket上的IO没有被处理完时，再次调用epoll_wait依然可以获得这些socket，用户进程可以接着处理socket上的IO事件。边缘触发： 在这种模式下，epoll_wait就会直接清空rdllist，不管socket上是否还有数据可读。所以在边缘触发模式下，当你没有来得及处理socket接收缓冲区的剩下可读数据时，再次调用epoll_wait，因为这时rdlist已经被清空了，socket不会再次从epoll_wait中返回，所以用户进程就不会再次获得这个socket了，也就无法在对它进行IO处理了。除非，这个socket上有新的IO数据到达，根据epoll的工作过程，该socket会被再次放入rdllist中。如果你在边缘触发模式下，处理了部分socket上的数据，那么想要处理剩下部分的数据，就只能等到这个socket上再次有网络数据到达。在Netty中实现的EpollSocketChannel默认的就是边缘触发模式。JDK的NIO默认是水平触发模式。epoll对select，poll的优化总结epoll在内核中通过红黑树管理海量的连接，所以在调用epoll_wait获取IO就绪的socket时，不需要传入监听的socket文件描述符。从而避免了海量的文件描述符集合在用户空间和内核空间中来回复制。select，poll每次调用时都需要传递全量的文件描述符集合，导致大量频繁的拷贝操作。epoll仅会通知IO就绪的socket。避免了在用户空间遍历的开销。select，poll只会在IO就绪的socket上打好标记，依然是全量返回，所以在用户空间还需要用户程序在一次遍历全量集合找出具体IO就绪的socket。epoll通过在socket的等待队列上注册回调函数ep_poll_callback通知用户程序IO就绪的socket。避免了在内核中轮询的开销。大部分情况下socket上并不总是IO活跃的，在面对海量连接的情况下，select，poll采用内核轮询的方式获取IO活跃的socket，无疑是性能低下的核心原因。根据以上epoll的性能优势，它是目前为止各大主流网络框架，以及反向代理中间件使用到的网络IO模型。利用epoll多路复用IO模型可以轻松的解决C10K问题。C100k的解决方案也还是基于C10K的方案，通过epoll 配合线程池，再加上 CPU、内存和网络接口的性能和容量提升。大部分情况下，C100K很自然就可以达到。甚至C1000K的解决方法，本质上还是构建在 epoll 的多路复用 I/O 模型上。只不过，除了 I/O 模型之外，还需要从应用程序到 Linux 内核、再到 CPU、内存和网络等各个层次的深度优化，特别是需要借助硬件，来卸载那些原来通过软件处理的大量功能（去掉大量的中断响应开销，以及内核协议栈处理的开销）。信号驱动IO 大家对这个装备肯定不会陌生，当我们去一些美食城吃饭的时候，点完餐付了钱，老板会给我们一个信号器。然后我们带着这个信号器可以去找餐桌，或者干些其他的事情。当信号器亮了的时候，这时代表饭餐已经做好，我们可以去窗口取餐了。这个典型的生活场景和我们要介绍的信号驱动IO模型就很像。在信号驱动IO模型下，用户进程操作通过系统调用 sigaction 函数发起一个 IO 请求，在对应的socket注册一个信号回调，此时不阻塞用户进程，进程会继续工作。当内核数据就绪时，内核就为该进程生成一个 SIGIO 信号，通过信号回调通知进程进行相关 IO 操作。这里需要注意的是：信号驱动式 IO 模型依然是同步IO，因为它虽然可以在等待数据的时候不被阻塞，也不会频繁的轮询，但是当数据就绪，内核信号通知后，用户进程依然要自己去读取数据，在数据拷贝阶段发生阻塞。信号驱动 IO模型 相比于前三种 IO 模型，实现了在等待数据就绪时，进程不被阻塞，主循环可以继续工作，所以理论上性能更佳。但是实际上，使用TCP协议通信时，信号驱动IO模型几乎不会被采用。原因如下：信号IO 在大量 IO 操作时可能会因为信号队列溢出导致没法通知SIGIO 信号是一种 Unix 信号，信号没有附加信息，如果一个信号源有多种产生信号的原因，信号接收者就无法确定究竟发生了什么。而 TCP socket 生产的信号事件有七种之多，这样应用程序收到 SIGIO，根本无从区分处理。但信号驱动IO模型可以用在 UDP通信上，因为UDP 只有一个数据请求事件，这也就意味着在正常情况下 UDP 进程只要捕获 SIGIO 信号，就调用 read 系统调用读取到达的数据。如果出现异常，就返回一个异常错误。这里插句题外话，大家觉不觉得阻塞IO模型在生活中的例子就像是我们在食堂排队打饭。你自己需要排队去打饭同时打饭师傅在配菜的过程中你需要等待。IO多路复用模型就像是我们在饭店门口排队等待叫号。叫号器就好比select,poll,epoll可以统一管理全部顾客的吃饭就绪事件，客户好比是socket连接，谁可以去吃饭了，叫号器就通知谁。##异步IO（AIO）以上介绍的四种IO模型均为同步IO，它们都会阻塞在第二阶段数据拷贝阶段。通过在前边小节《同步与异步》中的介绍，相信大家很容易就会理解异步IO模型，在异步IO模型下，IO操作在数据准备阶段和数据拷贝阶段均是由内核来完成，不会对应用程序造成任何阻塞。应用进程只需要在指定的数组中引用数据即可。异步 IO 与信号驱动 IO 的主要区别在于：信号驱动 IO 由内核通知何时可以开始一个 IO 操作，而异步 IO由内核通知 IO 操作何时已经完成。举个生活中的例子：异步IO模型就像我们去一个高档饭店里的包间吃饭，我们只需要坐在包间里面，点完餐（类比异步IO调用）之后，我们就什么也不需要管，该喝酒喝酒，该聊天聊天，饭餐做好后服务员（类比内核）会自己给我们送到包间（类比用户空间）来。整个过程没有任何阻塞。异步IO的系统调用需要操作系统内核来支持，目前只有Window中的IOCP实现了非常成熟的异步IO机制。而Linux系统对异步IO机制实现的不够成熟，且与NIO的性能相比提升也不明显。但Linux kernel 在5.1版本由Facebook的大神Jens Axboe引入了新的异步IO库io_uring 改善了原来Linux native AIO的一些性能问题。性能相比Epoll以及之前原生的AIO提高了不少，值得关注。再加上信号驱动IO模型不适用TCP协议，所以目前大部分采用的还是IO多路复用模型。IO线程模型 在前边内容的介绍中，我们详述了网络数据包的接收和发送过程，并通过介绍5种IO模型了解了内核是如何读取网络数据并通知给用户线程的。前边的内容都是以内核空间的视角来剖析网络数据的收发模型，本小节我们站在用户空间的视角来看下如果对网络数据进行收发。相对内核来讲，用户空间的IO线程模型相对就简单一些。这些用户空间的IO线程模型都是在讨论当多线程一起配合工作时谁负责接收连接，谁负责响应IO 读写、谁负责计算、谁负责发送和接收，仅仅是用户IO线程的不同分工模式罢了。Reactor Reactor是利用NIO对IO线程进行不同的分工：使用前边我们提到的IO多路复用模型比如select,poll,epoll,kqueue,进行IO事件的注册和监听。将监听到就绪的IO事件分发dispatch到各个具体的处理Handler中进行相应的IO事件处理。通过IO多路复用技术就可以不断的监听IO事件，不断的分发dispatch，就像一个反应堆一样，看起来像不断的产生IO事件，因此我们称这种模式为Reactor模型。下面我们来看下Reactor模型的三种分类：单Reactor单线程Reactor模型是依赖IO多路复用技术实现监听IO事件，从而源源不断的产生IO就绪事件，在Linux系统下我们使用epoll来进行IO多路复用，我们以Linux系统为例：单Reactor意味着只有一个epoll对象，用来监听所有的事件，比如连接事件，读写事件。单线程意味着只有一个线程来执行epoll_wait获取IO就绪的Socket，然后对这些就绪的Socket执行读写，以及后边的业务处理也依然是这个线程。单Reactor单线程模型就好比我们开了一个很小很小的小饭馆，作为老板的我们需要一个人干所有的事情，包括：迎接顾客（accept事件），为顾客介绍菜单等待顾客点菜(IO请求)，做菜（业务处理），上菜（IO响应），送客（断开连接）。单Reactor多线程随着客人的增多（并发请求），显然饭馆里的事情只有我们一个人干（单线程）肯定是忙不过来的，这时候我们就需要多招聘一些员工（多线程）来帮着一起干上述的事情。于是就有了单Reactor多线程模型：这种模式下，也是只有一个epoll对象来监听所有的IO事件，一个线程来调用epoll_wait获取IO就绪的Socket。但是当IO就绪事件产生时，这些IO事件对应处理的业务Handler，我们是通过线程池来执行。这样相比单Reactor单线程模型提高了执行效率，充分发挥了多核CPU的优势。主从Reactor多线程做任何事情都要区分事情的优先级，我们应该优先高效的去做优先级更高的事情，而不是一股脑不分优先级的全部去做。当我们的小饭馆客人越来越多（并发量越来越大），我们就需要扩大饭店的规模，在这个过程中我们发现，迎接客人是饭店最重要的工作，我们要先把客人迎接进来，不能让客人一看人多就走掉，只要客人进来了，哪怕菜做的慢一点也没关系。于是，主从Reactor多线程模型就产生了：我们由原来的单Reactor变为了多Reactor。主Reactor用来优先专门做优先级最高的事情，也就是迎接客人（处理连接事件），对应的处理Handler就是图中的acceptor。当创建好连接，建立好对应的socket后，在acceptor中将要监听的read事件注册到从Reactor中，由从Reactor来监听socket上的读写事件。最终将读写的业务逻辑处理交给线程池处理。注意：这里向从Reactor注册的只是read事件，并没有注册write事件，因为read事件是由epoll内核触发的，而write事件则是由用户业务线程触发的（什么时候发送数据是由具体业务线程决定的），所以write事件理应是由用户业务线程去注册。用户线程注册write事件的时机是只有当用户发送的数据无法一次性全部写入buffer时，才会去注册write事件，等待buffer重新可写时，继续写入剩下的发送数据、如果用户线程可以一股脑的将发送数据全部写入buffer，那么也就无需注册write事件到从Reactor中。主从Reactor多线程模型是现在大部分主流网络框架中采用的一种IO线程模型。我们本系列的主题Netty就是用的这种模型。Proactor Proactor是基于AIO对IO线程进行分工的一种模型。前边我们介绍了异步IO模型，它是操作系统内核支持的一种全异步编程模型，在数据准备阶段和数据拷贝阶段全程无阻塞。ProactorIO线程模型将IO事件的监听，IO操作的执行，IO结果的dispatch统统交给内核来做。Proactor模型组件介绍：completion handler 为用户程序定义的异步IO操作回调函数，在异步IO操作完成时会被内核回调并通知IO结果。Completion Event Queue 异步IO操作完成后，会产生对应的IO完成事件，将IO完成事件放入该队列中。Asynchronous Operation Processor 负责异步IO的执行。执行完成后产生IO完成事件放入Completion Event Queue 队列中。Proactor 是一个事件循环派发器，负责从Completion Event Queue中获取IO完成事件，并回调与IO完成事件关联的completion handler。Initiator 初始化异步操作（asynchronous operation）并通过Asynchronous Operation Processor将completion handler和proactor注册到内核。Proactor模型执行过程：用户线程发起aio_read，并告诉内核用户空间中的读缓冲区地址，以便内核完成IO操作将结果放入用户空间的读缓冲区，用户线程直接可以读取结果（无任何阻塞）。Initiator 初始化aio_read异步读取操作（asynchronous operation）,并将completion handler注册到内核。在Proactor中我们关心的IO完成事件：内核已经帮我们读好数据并放入我们指定的读缓冲区，用户线程可以直接读取。 在Reactor中我们关心的是IO就绪事件：数据已经到来，但是需要用户线程自己去读取。此时用户线程就可以做其他事情了，无需等待IO结果。而内核与此同时开始异步执行IO操作。当IO操作完成时会产生一个completion event事件，将这个IO完成事件放入completion event queue中。Proactor从completion event queue中取出completion event，并回调与IO完成事件关联的completion handler。在completion handler中完成业务逻辑处理。Reactor与Proactor对比 Reactor是基于NIO实现的一种IO线程模型，Proactor是基于AIO实现的IO线程模型。Reactor关心的是IO就绪事件，Proactor关心的是IO完成事件。在Proactor中，用户程序需要向内核传递用户空间的读缓冲区地址。Reactor则不需要。这也就导致了在Proactor中每个并发操作都要求有独立的缓存区，在内存上有一定的开销。Proactor 的实现逻辑复杂，编码成本较 Reactor要高很多。Proactor 在处理高耗时 IO时的性能要高于 Reactor，但对于低耗时 IO的执行效率提升并不明显。Netty的IO模型 在我们介绍完网络数据包在内核中的收发过程以及五种IO模型和两种IO线程模型后，现在我们来看下netty中的IO模型是什么样的。在我们介绍Reactor IO线程模型的时候提到有三种Reactor模型：单Reactor单线程，单Reactor多线程，主从Reactor多线程。这三种Reactor模型在netty中都是支持的，但是我们常用的是主从Reactor多线程模型。而我们之前介绍的三种Reactor只是一种模型，是一种设计思想。实际上各种网络框架在实现中并不是严格按照模型来实现的，会有一些小的不同，但大体设计思想上是一样的。下面我们来看下netty中的主从Reactor多线程模型是什么样子的？Reactor在netty中是以group的形式出现的，netty中将Reactor分为两组，一组是MainReactorGroup也就是我们在编码中常常看到的EventLoopGroup bossGroup,另一组是SubReactorGroup也就是我们在编码中常常看到的EventLoopGroup workerGroup。MainReactorGroup中通常只有一个Reactor，专门负责做最重要的事情，也就是监听连接accept事件。当有连接事件产生时，在对应的处理handler acceptor中创建初始化相应的NioSocketChannel（代表一个Socket连接）。然后以负载均衡的方式在SubReactorGroup中选取一个Reactor，注册上去，监听Read事件。MainReactorGroup中只有一个Reactor的原因是，通常我们服务端程序只会绑定监听一个端口，如果要绑定监听多个端口，就会配置多个Reactor。SubReactorGroup中有多个Reactor，具体Reactor的个数可以由系统参数 -D io.netty.eventLoopThreads指定。默认的Reactor的个数为CPU核数 * 2。SubReactorGroup中的Reactor主要负责监听读写事件，每一个Reactor负责监听一组socket连接。将全量的连接分摊在多个Reactor中。一个Reactor分配一个IO线程，这个IO线程负责从Reactor中获取IO就绪事件，执行IO调用获取IO数据，执行PipeLine。Socket连接在创建后就被固定的分配给一个Reactor，所以一个Socket连接也只会被一个固定的IO线程执行，每个Socket连接分配一个独立的PipeLine实例，用来编排这个Socket连接上的IO处理逻辑。这种无锁串行化的设计的目的是为了防止多线程并发执行同一个socket连接上的IO逻辑处理，防止出现线程安全问题。同时使系统吞吐量达到最大化由于每个Reactor中只有一个IO线程，这个IO线程既要执行IO活跃Socket连接对应的PipeLine中的ChannelHandler，又要从Reactor中获取IO就绪事件，执行IO调用。所以PipeLine中ChannelHandler中执行的逻辑不能耗时太长，尽量将耗时的业务逻辑处理放入单独的业务线程池中处理，否则会影响其他连接的IO读写，从而近一步影响整个服务程序的IO吞吐。当IO请求在业务线程中完成相应的业务逻辑处理后，在业务线程中利用持有的ChannelHandlerContext引用将响应数据在PipeLine中反向传播，最终写回给客户端。netty中的IO模型我们介绍完了，下面我们来简单介绍下在netty中是如何支持前边提到的三种Reactor模型的。配置单Reactor单线程EventLoopGroup eventGroup = new NioEventLoopGroup(1);ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(eventGroup);配置单Reactor多线程EventLoopGroup eventGroup = new NioEventLoopGroup();ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(eventGroup);配置主从Reactor多线程EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup();ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(bossGroup, workerGroup);总结 本文是一篇信息量比较大的文章，用了25张图，22336个字从内核如何处理网络数据包的收发过程开始展开，随后又在内核角度介绍了经常容易混淆的阻塞与非阻塞，同步与异步的概念。以这个作为铺垫，我们通过一个C10K的问题，引出了五种IO模型，随后在IO多路复用中以技术演进的形式介绍了select,poll,epoll的原理和它们综合的对比。最后我们介绍了两种IO线程模型以及netty中的Reactor模型。感谢大家听我唠叨到这里，哈哈，现在大家可以揉揉眼，伸个懒腰，好好休息一下了。

云计算是一种按需分配、按使用量收费的使用模式，提供了一个可配置的资源共享池，用户可以通过网络访问，获取存储空间、网络带宽、服务器、应用软件等等服务。   NFV，即网络功能虚拟化，Network Function Virtualization。通过使用x86等通用性硬件以及虚拟化技术，来承载很多功能的软件处理。从而降低网络昂贵的设备成本。可以通过软硬件解耦及功能抽象，使网络设备功能不再依赖于专用硬件，资源可以充分灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。  所以说云计算其实就是虚拟化出资源池以后的应用，是以虚拟化技术为基础的。云计算、虚拟化都需要集中化控制，而SDN最重要的三个概念是：可编程（开放的API接口）、控制平面与数据平面分离，以及集中式控制模型。基于SDN的网络架构可以更容易地实现网络虚拟化。  云计算平台本身的基础架构中，所用到的网络功能相对简单，就是普通的桥接技术，但是一般都会有用来集成第三方程序的接口，第三方的网络虚拟化平台一旦集成到云计算平台中，就可以大大增强云计算平台网络自动化部署的能力。当云计算平台部署网络服务的时候，先通过插件向这些网络虚拟化平台内置的Controller发送配置消息，然后Controller通过跟虚拟交换机或者硬件交换机之间的南向接口，比如 OpenFlow或者OF-Config、NetConf或者别的接口，去配置交换机。（比如要在两个Hypervisor（管理程序）之间创建Tunnel，并将一 些VM绑定到这个Tunnel上去，以及配置一些网络安全策略或者QoS策略等）  Overlay是通过在现有网络上叠加一个虚拟的逻辑网络，让原有网络尽量不做改造，通过定义的逻辑网络来实现业务逻辑，解决原有数据中心的网络问题。实际上就是一种隧道封装技术，将二层网络封装在三层/四层报文中进行传递，提供了一种解决数据平面转发和多租户隔离的技术手段，VXLAN（Virtual eXtensible LAN）是当前最为主流的Overlay标准。从数量上讲，它把 12 bit 的 VLAN tag 扩展成了 24 bit。从实现上讲，它是 MAC in UDP的封装方式，可以跨 L3 边界，很巧妙地解决了 GRE tunnel 和 VLAN 存在的不足，让组网变得更加灵活，有很好的扩展性。  网络虚拟化主要用在提供云服务的网络中。在实际部署中，有使用虚拟交换机来做Tunnel Overlay网络终结的方案，也有出于性能考虑使用硬件交换机做Tunnel Overlay网络终结的方案。  1）(OpenStack+) OVS 的纯软件方案，会遭受严重的性能问题，因为一台服务器里面虚拟机一多，随着网络流量的增大，网络交换部分带给CPU的压力就太大了。  2），(OpenStack+) SDN+硬件网络虚拟化的方案。用SDN硬件交换机代替了OVS纯软件方案，将Tunnel加解封装，安全过滤，基于VM的 QoS策略等网络功能放到了硬件交换机中，性能得到大幅度提升。（一）云计算介绍云计算是一种按需分配、按量收费的使用模式，提供了一个可配置的资源共享池，用户可以通过网络访问，获取服务器、存储、网络、应用软件等等服务。1：云计算的特点及优势1,资源池化；2,网络访问；3,自助式服务；4,可衡量的服务量（弹性计算、按需计费）；5,资源灵活调度2：云计算的服务模式1，SaaS 【software as a service】 软件即服务 – 用户通过网络租用基于Web的软件使用。（虚拟桌面，在线游戏等）2，PaaS 【platform as a service】 平台即服务 – 指将软件研发的平台作为一种服务。(数据库，开发工具，web服务器，软件运行环境等)3，IaaS 【infrastructure as a service】 基础架构即服务 – 用户通过网络直接访问底层的计算、存储和网络资源。(虚拟机，服务器，存储空间，网络带宽等)

【新智元导读】GPU共享，是指在同一张GPU卡上同时运行多个任务。本文详细论述深度学习GPU的资源隔离与并行模式，并提出对于深度学习与GPU的展望。当前机器学习训练中，使用GPU提供算力已经非常普遍，对于GPU-based AI system的研究也如火如荼。在这些研究中，以提高资源利用率为主要目标的GPU共享(GPU sharing)是当下研究的热点之一。本篇文章希望能提供一个对GPU共享工作的分享，希望能和相关领域的研究者们共同讨论。GPU共享，是指在同一张GPU卡上同时运行多个任务。优势在于：（1）集群中可以运行更多任务，减少抢占。（2）资源利用率（GPU/显存/e.t.c.）提高；GPU共享后，总利用率接近运行任务利用率之和，减少了资源浪费。（3）可以增强公平性，因为多个任务可以同时开始享受资源；也可以单独保证某一个任务的QoS。（4）减少任务排队时间。（5）总任务结束时间下降；假设两个任务结束时间分别是x,y，通过GPU共享，两个任务全部结束的时间小于x+y。想要实现GPU共享，需要完成的主要工作有：（1）资源隔离，是指共享组件有能力限制任务占据算力（线程/SM）及显存的比例，更进一步地，可以限制总线带宽。（2）并行模式，主要指时间片模式和MPS模式。资源隔离资源隔离是指共享组件有能力限制任务占据算力/显存的比例。限制的方法就是劫持调用。图一是在Nvidia GPU上，机器学习自上而下的视图。由于Cuda和Driver不开源，因此资源隔离层一般处在用户态。在内核态做隔离的困难较大，但也有一些工作。顺带一提，Intel的Driver是开源的，在driver层的共享和热迁移方面有一些上海交大和Intel合作的工作。图一/使用Nvidia GPU机器学习自上而下视图来自腾讯的Gaia(ISPA'18)[1]共享层在Cuda driver API之上，它通过劫持对Cuda driver API的调用来做到资源隔离。劫持的调用如图二所示。具体实现方式也较为直接，在调用相应API时检查：（1）对于显存，一旦该任务申请显存后占用的显存大小大于config中的设置，就报错。（2）对于计算资源，存在硬隔离和软隔离两种方式，共同点是当任务使用的GPU SM利用率超出资源上限，则暂缓下发API调用。不同点是如果有资源空闲，软隔离允许任务超过设置，动态计算资源上限。而硬隔离则不允许超出设置量。该项目代码开源在[2]。实测即使只跑一个任务也会有较大JCT影响，可能是因为对资源的限制及守护程序的资源占用问题。KubeShare（HPDC '20）[3]的在资源隔离方面也是类似的方案。图二/ Gaia限制的CUDA driver API发了44篇论文（截止2020年3月）的rCuda[4]和Gaia有相似之处，他们都是在Cuda driver API之上，通过劫持调用来做资源隔离。不同的是，rCuda除了资源隔离，最主要的目标是支持池化。池化简单来讲就是使用远程访问的形式使用GPU资源，任务使用本机的CPU和另一台机器的GPU，两者通过网络进行通信。也是因为这个原因，共享模块需要将CPU和GPU的调用分开。然而正常情况下混合编译的程序会插入一些没有开源的Cuda API，因此需要使用作者提供的cuda，分别编译程序的CPU和GPU部分。图三显示了rCuda的架构。如果使用该产品，用户需要重新编译，对用户有一定的影响。该项目代码不开源。另外vCUDA（TC '12）[5]和qCUDA(CloudCom '19)[18]也采用了和rCuda相似的技术。图三/rCuda架构GPUShare（IPDPSW' 16）[6]也是劫持的方式，但不同的是,它采用预测执行时间的方式来实现计算资源的公平性。作者认为比切换周期还小的短kernel不会影响公平使用，因此只限制了较大的kernel。来自阿里的cGPU[7]，其共享模块在Nvidia driver层之上，也就是内核态。由于是在公有云使用，相对于用户态的共享会更加安全。它也是通过劫持对driver的调用完成资源隔离的，通过设置任务占用时间片长度来分配任务占用算力，但不清楚使用何种方式精准地控制上下文切换的时间。值得一提的是，由于Nvidia driver是不开源的，因此需要一些逆向工程才可以获得driver的相关method的name和ioctl参数的结构。该方案在使用上对用户可以做到无感知，当然JCT是有影响的。代码没有开源，也没有论文。图四是cGPU的架构图。图四/cgpu架构图来自Nvidia的vGPU[8]其共享模块在Nvidia driver里面。vGPU通过vfio-mdev提供了一个隔离性非常高的的硬件环境，主要面向的是虚拟机产品，无法动态调整资源比例。来自Nvidia的产品当然没有开源。图五是vGPU的架构图。图五/vGPU架构图Fractional GPU（RTAS' 19）[9]是一篇基于MPS的资源隔离方案。其共享模块在Nvidia driver里面。该方案的隔离非常硬，核心就是绑定。在计算隔离方面，它通过给任务绑定一定比例的可使用SM，就可以天然地实现计算隔离。MPS的计算隔离是通过限制任务的thread数，相较于Fractional GPU会限制地更加不准确。在显存隔离方面，作者深入地研究Nvidia GPU内存架构（包括一些逆向工程）图六是Fractional GPU通过逆向得到的Nvidia GPU GTX 970的存储体系架构。通过页面着色（Page Coloring）来完成显存隔离。页面着色的思想也是将特定的物理页分配给GPU SM分区，以限制分区间互相抢占的问题。该隔离方案整体上来说有一定损耗，而且只能使用规定好的资源比例，不能够灵活地检测和使用全部空闲资源。另外使用该方案需要修改用户代码。代码开源在[10]。图六/Fractional GPU通过逆向得到的Nvidia GPU GTX 970的存储体系架构Mig（ MULTI-INSTANCE GPU）[21]是今年A100机器支持的资源隔离方案，Nvidia在最底层硬件上对资源进行了隔离，可以完全地做到计算/通信/配置/错误的隔离。它将SM和显存均匀地分给GPU instance，最多支持将SM分7份（一份14个），显存分8份（1份5GB）。顺带一提A100有SM108个，剩下的10个将无法用上。它可选的配置也是有限制的，如图七所示。图七/Mig GPU Instance配置并行模式并行模式指任务是以何种方式在同一个GPU上运行的。目前有两种方式：（1）分时复用。指划分时间片，让不同的任务占据一个独立的时间片，需要进行上下文切换。在这种模式下，任务实际上是并发的，而不是并行的，因为同一时间只有一个任务在跑。（2）合并共享。指将多个任务合并成一个上下文，因此可以同时跑多个任务，是真正意义上的并行。在生产环境中，更多使用分时复用的方式。分时复用分时复用的模式大家都较为熟悉，CPU程序的时间片共享已经非常常见和易用，但在GPU领域还有一些工作要做。如果在Nvidia GPU上直接启动两个任务，使用的就是时间片共享的方式。但该模式存在多任务干扰问题：即使两个机器学习任务的GPU利用率和显存利用率之和远小于1，单个任务的JCT也会高出很多。究其原因，是因为计算碰撞，通信碰撞，以及GPU的上下文切换较慢。计算碰撞很好理解，如果切换给另一个任务的时候，本任务正好在做CPU计算/IO/通信，而需要GPU计算时，时间片就切回给本任务，那么就不会有JCT的影响。但两个任务往往同时需要使用GPU资源。通信碰撞，是指任务同时需要使用显存带宽，在主机内存和设备显存之间传输数据。GPU上下文切换慢，是相对CPU而言的。CPU上下文切换的速度是微秒级别，而GPU的切换在毫秒级别。在此处也会有一定的损耗。图八是分时复用模式的常见架构。图八/分时复用架构图上文提到的Gaia，KubeShare，rCuda，vCuda，qCuda，cGPU，vGPU均为分时复用的模式。由于上文所述的问题，他们的单个任务完成时间（JCT）都会受到较大的影响。V100测试环境下，两个任务同时运行，其JCT是单个任务运行时的1.4倍以上。因此在生产环境下，我们需要考虑如何减少任务之间互相影响的问题。上述方案都没有考虑机器学习的特性，只要共享层接收到kernel下发，检查没有超过设置上限，就会继续向下传递。另外也限制任务显存的使用不能超过设置上限，不具备弹性。因此针对特定的生产场景，有一些工作结合机器学习任务的特性，进行了资源的限制及优化。服务质量（QoS）保障在生产环境的GPU集群中常会有两类任务，代称为高优先级任务和低优先级任务。高优任务是时间敏感的，在它需要资源时需要立刻提供给它。而低优任务是时间不敏感的，当集群有资源没被使用时，就可以安排它填充资源缝隙以提高集群利用率。因此共享模块需要优先保障高优先级任务的JCT不受影响，以限制低优任务资源占用的方式。Baymax（ASPLOS '16）[11]通过任务重排序保障了高优任务的QoS。Baymax作者认为多任务之间的性能干扰通常是由排队延迟和PCI-e带宽争用引起的。也就是说，当高优任务需要计算或IO通信时，如果有低优的任务排在它前面，高优任务就需要等待，因此QoS无法保障。针对这两点Baymax分别做了一些限制：（1）在排队延迟方面，Baymax利用KNN/LR模型来预测持续时间。然后Baymax对发给GPU的请求进行重新排序。简单来说，就是共享模块预测了每个请求的执行时间，当它认为发下去的请求GPU还没执行完时，新下发的请求就先进入队列里。同时将位于队列中的任务重排序，当需要下发请求时，先下发队列中的高优任务请求。（2）在PCI-e带宽争用方面，Baymax限制了并发数据传输任务的数量。Baymax作者在第二年发表了Prophet（ASPLOS '17）[12]，用于预测多任务共置时QoS的影响程度。在论文最后提到的实验中，表示如果预测到多个任务不会影响QoS，就将其共置，但此处共置使用的是MPS，也就是没有使用分时复用的模式了。在该研究中，预测是核心。预测准确性是否能适应复杂的生产环境，预测的机器负载是否较大，还暂不清楚。来自阿里的AntMan（OSDI '20）[13]也认为排队延迟和带宽争用是干扰的原因，不同的是，它从DL模型的特点切入，来区分切换的时机。在算力限制方面，AntMan通过限制低优任务的kernel launch保证了高优任务的QoS。图九是AntMan算力共享机制的对比。AntMan算力调度最小单元，在论文中描述似乎有些模糊，应该是Op（Operator），AntMan“会持续分析GPU运算符的执行时间“，并在空隙时插入另一个任务的Op。但如何持续分析，论文中并没有详细描述。在显存隔离方面，AntMan没有限制显存的大小，而是尽力让两个任务都能运行在机器上。但两个或多个任务的显存申请量可能会造成显存溢出，因此AntMan做了很多显存方面的工作。首先需要了解任务在显存中保存的内容：首先是模型，该数据是大小稳定的，当它在显存中时，iteration才可以开始计算。论文中表示90%的任务模型使用500mb以内的显存。其次是iteration开始时申请的临时显存，这部分显存理论上来说，在iteration结束后就会释放。但使用的机器学习框架有缓存机制，申请的显存不会退回，该特性保障了速度，但牺牲了共享的可能性。因此AntMan做了一些显存方面最核心的机制是，当显存放不下时，就转到内存上。在此处论文还做了很多工作，不再尽述。论文描述称AntMan可以规避总线带宽争用问题，但似乎从机制上来说无法避免。除此之外，按照Op为粒度进行算力隔离是否会需要大量调度负载也是一个疑问，另外Op执行时间的差异性较大，尤其是开启XLA之后，这也可能带来一些不确定性。该方案需要修改机器学习框架（Tensorflow和Pytorch），对用户有一定的影响。代码开源在[20]，目前还是WIP项目（截止2020/11/18），核心部分（local-coordinator）还没能开源。图九/AntMan算力共享机制的对比如果最小调度单元是iteration，则会更加简单。首先需要了解一下DL训练的特征：训练时的最小迭代是一个iteration，分为四个过程：IO，进行数据读取存储以及一些临时变量的申请等；前向，在此过程中会有密集的GPU kernel。NLP任务在此处也会有CPU负载。后向，计算梯度更新，需要下发GPU kernel；更新，如果非一机一卡的任务，会有通信的过程。之后更新合并后的梯度，需要一小段GPU时间。可以看出前向后向和通信之后的更新过程，是需要使用GPU的，通信和IO不需要。因此可以在此处插入一些来自其他任务的kernel，同时还可以保证被插入任务的QoS。更简单的方式是，通过在iteration前后插入另一个任务的iteration来完成共享。当然这样就无法考虑通信的空隙，可以被理解是一种tradeoff。另外也因为iteration是最小调度单元，避免了计算资源和显存带宽争用问题。另外，如果不考虑高优任务，实现一个退化版本，贪心地放置iteration而不加以限制。可以更简单地提高集群利用率，也可以让任务的JCT/排队时间减小。针对推理的上下文切换在上文中描述了分时复用的三个问题，其中上下文切换是一个耗时点。来自字节跳动的PipeSwitch（OSDI '20）[14]针对推理场景的上下文切换进行了优化。具体生产场景是这样的：训练推理任务共享一张卡，大多数时候训练使用资源。当推理请求下发，上下文需要立刻切换到推理任务。如果模型数据已经在显存中，切换会很快，但生产环境中模型一般较大，训练和推理的模型不能同时加载到显存中，当切换到推理时，需要先传输整个模型，因此速度较慢。在该场景下，GPU上下文切换的开销有：（1）任务清理，指释放显存。（2）任务初始化，指启动进程，初始化Cuda context等。（3）Malloc。（4）模型传输，从内存传到显存。在模型传输方面，PipeSwitch作者观察到，和训练不同的是推理只有前向过程，因此只需要知道上一层的输出及本层的参数就可以开始计算本层。目前的加载方式是，将模型数据全部加载到显存后，才会开始进行计算，但实际上如果对IO和计算做pipeline，只加载一层就开始计算该层，就会加快整体速度。当然直接使用层为最小粒度可能会带来较大开销，因此进行了grouping合并操作。图十显示了pipeline的对比。在任务清理和初始化方面，设置了一些常驻进程来避免开销。最后在Malloc方面也使用了统一的内存管理来降低开销。可以说做的非常全面。由于需要获知层级结构，因此需要对Pytorch框架进行修改，对用户有一定影响。代码开源在[19].图十/PipeSwitch pipeline的对比合并共享合并共享是指，多个任务合并成一个上下文，因此可以共享GPU资源，同时发送kernel到GPU上，也共同使用显存。最具有代表性的是Nvidia的MPS[15]。该模式的好处是显而易见的，当任务使用的资源可以同时被满足时，其JCT就基本没有影响，性能可以说是最好的。可以充分利用GPU资源。但坏处也是致命的：错误会互相影响，如果一个任务错误退出（包括被kill），如果该任务正在执行kernel，那么和该任务共同share IPC和UVM的任务也会一同出错退出。目前还没有工作能够解决这一问题，Nvidia官方也推荐使用MPS的任务需要能够接受错误影响，比如MPI程序。因此无法在生产场景上大规模使用。另外，有报告称其不能支持所有DL框架的所有版本。在资源隔离方面，MPS没有显存隔离，可以通过限制同时下发的thread数粗略地限制计算资源。它位于Nvidia Driver之上。图十一是MPS的架构图。图十一/MPS架构图Salus（MLSys '20）[16]也采取了合并共享的方式，作者通过Adaptor将GPU请求合并到同一个context下，去掉了上下文切换。当然，和MPS一样会发生错误传播，论文中也没有要解决这一问题，因此无法在生产环境中使用。但笔者认为这篇论文中更大的价值在显存和调度方面，它的很多见解在AntMan和PipeSwitch中也有体现。调度方面，以iteration为最小粒度，并且诠释了原因：使用kernel为粒度，可以进一步利用资源，但会增加调度服务的开销。因此折中选择了iteration，可以实现性能最大化。显存方面，一些观察和AntMan是一致的：显存变化具有周期性；永久性显存（模型）较小，只要模型在显存中就可以开始计算；临时性显存在iteration结束后就应该释放。也描述了机器学习框架缓存机制的死锁问题。不过Salus实现上需要两个任务所需的显存都放到GPU显存里，没有置换的操作。论文中也提到了推理场景下的切换问题：切换后理论上模型传输时间比推理延迟本身长几倍。除此之外论文中也有一些其他的观察点，值得一看。图十二展示了Salus架构。该项目代码开源在[17]。Salus也需要修改DL框架。作者也开源了修改后的tensorflow代码。图十二/Salus架构图如果在合并共享模块之上做分时复用，应可以绕过硬件的限制，精准地控制时间片和切换的时机，也可以去除上下文切换的开销。但在这种情况下是否还会有错误影响，还需要进一步验证。场景展望目前GPU共享已经逐渐开始进入工业落地的阶段了，若需要更好地满足用户对使用场景的期待，除了更高的性能，笔者认为以下几点也需要注意。1、能够提供稳定的服务，运维便捷。比如MPS的错误影响是不能被接受的，另外对于带有预测的实现，也需要更高的稳定性。共享工作负载尽量降低。2、更低的JCT时延，最好具有保障部分任务QoS的能力。对于一个已有的GPU集群进行改造时，需要尽量减少对已有的用户和任务的影响。3、不打扰用户，尽量不对用户的代码和框架等做修改，另外也需要考虑框架和其他库的更新问题。参考：1]J. Gu, S. Song, Y. Li and H. Luo, "GaiaGPU: Sharing GPUs in Container Clouds," 2018 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Ubiquitous Computing & Communications, Big Data & Cloud Computing, Social Computing & Networking, Sustainable Computing & Communications (ISPA/IUCC/BDCloud/SocialCom/SustainCom), Melbourne, Australia, 2018, pp. 469-476, doi: 10.1109/BDCloud.2018.00077.[2]github.com/tkestack/vcu[3]Ting-An Yeh, Hung-Hsin Chen, and Jerry Chou. 2020. KubeShare: A Framework to Manage GPUs as First-Class and Shared Resources in Container Cloud. In Proceedings of the 29th International Symposium on High-Performance Parallel and Distributed Computing (HPDC '20). Association for Computing Machinery, New York, NY, USA, 173–184. DOI:doi.org/10.1145/3369583[4]José Duato, Francisco D. Igual, Rafael Mayo, Antonio J. Peña, Enrique S. Quintana-Ortí, and Federico Silla. An efficient implementation of GPU virtualization in high performance clusters. In Euro-Par 2009, Parallel Processing - Workshops, volume 6043 of Lecture Notes in Computer Science, pages 385-394. Springer-Verlag, 2010.[5]L. Shi, H. Chen, J. Sun and K. Li, "vCUDA: GPU-Accelerated High-Performance Computing in Virtual Machines," in IEEE Transactions on Computers, vol. 61, no. 6, pp. 804-816, June 2012, doi: 10.1109/TC.2011.112.[6]A. Goswami et al., "GPUShare: Fair-Sharing Middleware for GPU Clouds," 2016 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), Chicago, IL, 2016, pp. 1769-1776, doi: 10.1109/IPDPSW.2016.94.[7]alibabacloud.com/help/z[8] docs.nvidia.com/grid/10[9]S. Jain, I. Baek, S. Wang and R. Rajkumar, "Fractional GPUs: Software-Based Compute and Memory Bandwidth Reservation for GPUs," 2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), Montreal, QC, Canada, 2019, pp. 29-41, doi: 10.1109/RTAS.2019.00011.[10]github.com/sakjain92/Fr[11]Quan Chen, Hailong Yang, Jason Mars, and Lingjia Tang. 2016. Baymax: QoS Awareness and Increased Utilization for Non-Preemptive Accelerators in Warehouse Scale Computers. In Proceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '16). Association for Computing Machinery, New York, NY, USA, 681–696. DOI:doi.org/10.1145/2872362[12]Quan Chen, Hailong Yang, Minyi Guo, Ram Srivatsa Kannan, Jason Mars, and Lingjia Tang. 2017. Prophet: Precise QoS Prediction on Non-Preemptive Accelerators to Improve Utilization in Warehouse-Scale Computers. In Proceedings of the Twenty-Second International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '17). Association for Computing Machinery, New York, NY, USA, 17–32. DOI:doi.org/10.1145/3037697[13]Xiao, Wencong, et al. "AntMan: Dynamic Scaling on {GPU} Clusters for Deep Learning." 14th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 20). 2020.[14]Bai, Zhihao, et al. "PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications." 14th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 20). 2020.[15]docs.nvidia.com/deploy/[16]Yu, Peifeng, and Mosharaf Chowdhury. "Salus: Fine-grained gpu sharing primitives for deep learning applications." arXiv preprint arXiv:1902.04610 (2019).[17]github.com/SymbioticLab[18]Y. Lin, C. Lin, C. Lee and Y. Chung, "qCUDA: GPGPU Virtualization for High Bandwidth Efficiency," 2019 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), Sydney, Australia, 2019, pp. 95-102, doi: 10.1109/CloudCom.2019.00025.[19]netx-repo/PipeSwitch[20]alibaba/GPU-scheduler-for-deep-learning[21]NVIDIA Multi-Instance GPU User Guide

随着客户转向云端和安全服务，对SD-WAN分析技术的依赖也在增长。分析已从可有可无的功能变为必备的功能，尤其是在不断发展的SD-WAN领域，为了应对威胁和不断变化的网络状况，快速处理大量数据变得越来越重要。“目前，要让SD-WAN发挥其作用，并实现其自动化和智能属性，这就需要具备实时的洞察力，而这种洞察力通常是通过目前许多解决方案所提供的可视性和分析工具实现的，这些解决方案或者是提供一些集成选项，或者通过第三方或生态系统合作伙伴提供。”国际数据公司(IDC)网络基础架构副总裁罗希特·麦赫拉(Rohit Mehra)说。随着SD-WAN为不断增长的远程办公员工提供服务，这方面现在变得更加重要。国际数据公司最近的调查显示，95%的企业将在两年内使用SD-WAN技术，42%的企业已经部署了该技术。国际数据公司还表示，到2022年，SD-WAN基础设施市场规模将达到45亿美元，从现在到2022年，每年的增长率将超过40%。麦赫拉说：“随着包括视频和物联网应用等云服务使用的迅速增加，同时在全球持续蔓延的疫情也加速了这些服务和应用的发展，广域网和远程连接仍然是企业IT部门的关键任务。”“具体来说，SD-WAN是从企业路由和WAN优化发展而来的，并为解决与这些不断发展的应用需求相关的更动态、更智能化架构的要求。”麦赫拉说。供应商的SD-WAN软件包中的探测工具或代理工具会收集网络、性能、安全性和其他遥测数据，并将其与老客户和供应商收集的数据结合起来。对这些数据进行分析后，会生成一些建议、策略调整或其他措施，以帮助IT部门使整个WAN环境正常运行。分析程序还可以减少IT团队所处理的总体警报数量，因为这些程序会关注于企业认为最重要的事情。诸如思科、VMware、Versa、Silver Peak、思杰(Citrix)、Cato等供应商在其SD-WAN软件包中都含有不同程度的分析技术，但他们都在转向支持云连接的客户。“许多(即使不是大多数)SD-WAN供应商确实在他们的解决方案中都内置了一些核心分析和可视性功能，这有助于实现SD-WAN架构的动态性能，”麦赫拉说。“然而，从终端到云端对可视性和分析能力以及洞察力的更高需求，正在推动解决方案提供商的业务路线图，并且在许多情况下，还增加了行业内与并购相关的对话。”其中一家公司Versa(其Secure SD-WAN软件包中提供一些分析功能)表示，由于IT客户需要了解其日益分散的办公环境状况，因此居家办公人员的增加推动了分析功能的使用。Versa公司的联合创始人兼首席开发官库马尔·梅塔(Kumar Mehta)说：“无论您的流量是用于公共云还是SaaS，客户都希望全面了解分析功能可帮助解决的性能和安全问题。”“借助我们的SD-WAN分析功能，IT部门可以看到用户的状况，无论他位于云端，还是在数据中心，并全面了解网络或应用程序的问题所在，然后迅速解决问题。”由于许多员工在家工作，因此分析这些链接并查找相关问题已经成为一个问题。梅塔说，这种能力在未来将变得更加重要，而分析技术可以做到这一点。思科公司的产品管理、企业路由和SD-WAN产品高级总监罗瀚·格罗弗(Rohan Grover)说：“企业目前正在经历一次最大的转型，其背后最大的推动因素是云和多云接入以及分散式办公的新常态。”企业IT部门面临的挑战之一是将SD-WAN具有的可视性带入到众多客户所使用的多云环境中。格罗弗表示，其中一些客户拥有20多家SaaS提供商，这非常复杂，但除此之外，云连接一直都是盲点。思科的SD-WAN vManage软件包及其基于Meraki的SD-WAN产品中的分析功能可在SD-WAN平台与云供应商(特别是亚马逊和谷歌)之间交换遥测信息，并帮助客户确保一切工作正常运行。格罗弗表示，分析技术可以帮助客户确定哪些连接(如MPLS电路或直接互联网链接等)更适合于某一特定应用。格罗弗表示，其他正在逐步普及的分析用例可以为分支网络找出带宽和容量规划的最佳使用方式，这变得前所未有的重要。“虽然如今在多个IT领域已成功实现了可视性和分析技术的提升，但随着各种数字化转型计划加速推进，进而要求网络进行转型，在后疫情阶段渐进式的SD-WAN智能化和自动化的情况只会变得越来越多，”国际数据公司的麦赫拉说。VMware公司SD-WAN副总裁兼首席技术官克雷格·康纳斯(Craig Connors)表示，SD-WAN分析工具可以帮助企业监控终端用户的行为，并可发送有关连接断开、ISP中断和QoS问题等方面的警报。“基于实时数据，网络运营商不仅能够检测到这些问题，还可以远程修复这些问题。”提高企业安全性是SD-WAN分析功能的另一个发展中的用例，该功能可以跟踪用户在做什么，无论他们身在何处。这种基于分析技术的安全性适用于较大型的安全访问服务边缘(SASE)架构，该架构可通过云端安全服务来保护关键网络节点。康纳斯说：“显而易见，各种威胁在不断变化，现在我们的物联网和各种其他移动端设备加入到网络中，对IT部门而言，管理和确保所有这些设备安全变得更难。”“传统的安全系统可能不会关注到趋势发展，但分析引擎可以检测并标记一些安全问题。将安全性和SD-WAN进行整合的想法也是SASE架构所承诺的内容。”分析引擎可以了解目前的网络趋势是什么，并可以发现网络中何时发生异常情况。Versa公司工程总监鲁帕·巴亚尔(Roopa Bayar)表示，分析技术可以标记异常情况和威胁事件，然后帮助客户了解问题所在，并帮助解决问题。“分析技术可以建立一些安全模式和行为，”巴亚尔说。专家说，客户将来会看到更多的人工智能和机器学习技术被添加到分析软件包中，以提高网络性能和应用管理，还可以提高智能化，缩短对问题的响应时间。