下载掌阅APP，畅读海量书库
立即打开
互联网软件应用系统的最大性能瓶颈在哪里？在很多情况下，限制因素是网络传输，也就是数据在互联网上在服务器和终端用户之间的来回传输时间。
如今，在设计网络应用时，服务端的基础设施往往受到较多的关注，这也是架构师能够控制的部分。良好的基础设施性能和可靠性似乎是一个相对容易理解和处理的问题。然而，从终端用户的角度来看，为了实现强大的应用性能和可靠性，服务端的基础设施只是一个必要但不足够的条件。
难以控制且常被忽视的是，互联网的“中间网络”将延时瓶颈、吞吐量限制和可靠性问题引入了软件应用系统的性能公式中。实际上，“中间网络”这个词本身就是模糊的，因为它指的是由许多竞争实体拥有的、可能跨越数百或数千千米的异构基础设施。
虽然我们通常将互联网视为一个单一实体，但实际上它是由数以万计的不同且互相竞争的网络组成的，每个网络都提供一部分终端用户的访问。随着市场需求的增长，承载服务器的数据中心（IDC）和用户的接入网络都得到了极大的提升，互联网的容量也在持续发展。
然而，由网络流量交换的对等节点和中转节点组成的互联网“中间网络”实际上是一片空白地带。在这里，从经济角度看，几乎没有动力去扩大其产能。相反，中间网络更希望减少流入其中的无偿流量。因此，对等节点通常负载过重，从而导致数据包丢失和服务质量下降。对等节点经济模型的脆弱性可能引发更严重的问题，其他的可靠性问题也困扰着它们。互联网中断的原因多种多样，包括跨洋电缆中断、断电和分布式拒绝服务攻击（DDoS）。互联网的主要路由算法协议是边界网关协议（BGP），它和物理网络基础设施一样容易受到影响。
互联网可靠性和对等节点问题的普遍存在，意味着数据在中间网络中的传输时间越长，就越容易出现网络拥塞、数据包丢失和性能下降的问题。
随着宽带和可用性需求的增长，用户对更快的网站、更丰富的媒体以及高度交互的软件的期待也在提高。这种持续增长的流量负荷和性能要求反过来又给互联网的“中间网络”带来了巨大的压力。
视频和富媒体文件的增大产生了一个有趣的副作用，即服务器和最终用户之间的距离对用户感知到的性能产生了更大的影响。
如果数据包可以以接近光速的速度穿过网络，那么在网络并不拥堵的情况下，为什么一个“大文件”需要这么长的时间才能穿过网络到达用户呢？这是由底层网络协议的工作方式决定的，延时和吞吐量是直接关联的。例如，TCP窗口一次只允许发送一小部分数据，然后必须暂停并等待接收端的确认。这意味着网络往返时间（延时）有效地限制了吞吐量，这可能成为文件下载速度和视频观看数量的瓶颈。
数据包丢失使问题变得更复杂，因为如果检测到数据包丢失，那么这些协议会在等待确认之前停止并发送更少的数据。较长的距离增加了拥塞和数据包丢失的可能性，从而进一步降低了吞吐量。
考虑到各种瓶颈和可扩展性的挑战，我们应如何通过互联网有效地传送内容？我们应如何提升软件所需的性能和可靠性？在内容分发体系中，主要有4种方法：集中托管、数据中心、分布式CDN以及P2P网络。这4种网络架构各有优缺点，为我们考虑优化内容分发性能提供了方向。
传统的Web站点通常使用一个或少数几个配置站点来承载内容。为了提供更高的性能、可靠性和可扩展性，商业站点通常至少会有两个地理分散的镜像站点。
这种方法对于只需要满足本地用户需求的小型网站来说已经足够了。然而，由于用户体验受到互联网“中间网络”不稳定性的影响，这种方法的性能和可靠性可能无法满足商业级网站和应用的需求。
此外，站点镜像既复杂又昂贵，并且难以管理。流量波动大，需要为峰值流量提供更多的冗余资源，导致昂贵的基础设施在大部分时间内无法得到充分利用。预测流量需求非常困难，集中托管无法灵活应对流量突增的情况。
内容分发网络通过将可缓存内容从源服务器转移到更大的共享网络，提供了更好的可伸缩性。一种常见的内容分发网络被描述为“数据中心”，它包括可能连接到主干网络的几十个高容量数据中心，用于缓存和分发资源。
尽管这种方法相比集中托管具有更多的性能优势和更好的规模经济性，但它的改进空间有限，因为数据中心的服务器仍离大多数用户较远，且受到中间网络瓶颈的影响。仅有自己的主干网络并不能实现商业级的性能，这似乎与常理相悖。事实上，即使是最大的网络控制终端的用户数量也有限，互联网用户在网络上呈现长尾分布。即使连接到主干网络，数据也必须穿过“中间网络”的泥潭，才能到达互联网的大多数用户。
高度分布式CDN拥有数千个网络服务器，而不是几十个。虽然这看似与CDN的“数据中心”类似，但实际上，它是一种完全不同的内容服务器部署方式，其分布程度远超过两个数量级。例如，通过将服务器放置在终端用户的ISP中，高度分布式CDN消除了对等、连接、路由和距离问题，并减少了依赖互联网组件的数量。此外，这种架构具有可扩展性。
然而，部署高度分布式CDN的成本高、耗时长，且伴有许多挑战。从部署和管理的角度来看，网络规模必须有效地设计，包括：
· 复杂的全球调度、映射和负载平衡算法。
· 复杂的缓存管理协议，以确保高缓存命中率。
· 分布式控制协议和可靠的自动监控和报警系统。
· 分布式内容更新机制、数据完整性保证和管理系统。
· 自动故障转移和恢复方法。
· 大规模数据聚合和分发技术。
· 健壮的全球软件部署机制。
这些都是CDN的核心技术，也是非常重要的挑战。
鉴于高度分布式架构在视频分发的可扩展性和性能中起着至关重要的作用，自然会考虑P2P（点对点）架构。P2P可以被视为将分布式架构推向了逻辑极限，理论上提供了近乎无限的可扩展性。此外，在当前的网络定价结构下，P2P提供了很有吸引力的经济效益。
然而，在实际应用中，P2P面临着一些严重的限制，主要是由于P2P网络的总下载容量受其总上传容量的限制。对于用户的宽带连接，上传速度通常远低于下载速度。这意味着在实时流媒体等场景中，上传（对等节点共享内容）的数量受到下载（对等节点请求内容）数量的限制。平均下载吞吐量等同于平均上传吞吐量，因此常常不能支持高质量的Web流量。采用混合方法，即利用P2P作为CDN的扩展，可以获得更好的结果，P2P可以在某些情况下降低总体分发成本。然而，由于P2P网络的容量有限，网络中非P2P的架构仍然决定了整体的性能和可扩展性。
在网络中，大量组件或其他部分可能会在任何时候发生故障。互联网系统会出现各种故障模式，如机器故障、数据中心故障、连接故障、软件故障和网络故障等。所有这些故障的发生频率都比我们想象的要高。尽管发生故障，我们仍希望网络能正常运行，不影响用户使用。
因此，在我们的应用系统中，需要选择一个健壮且高度分布式的CDN。下面是从技术层面给出的一些建议。
1.确保所有系统具有大量冗余，以便进行故障转移
拥有一个高度分布式的CDN可以带来大量的冗余。如果某个组件出现故障，那么可以有多种备份可用。然而，为了确保所有系统的健壮性，可能需要突破现有协议的限制并与第三方软件进行交互，这可能涉及成本的权衡。用户需要检查是否在每个级别都设定了适当的故障切换机制。
2.使用软件逻辑提供消息的可靠性
需要明确是否在数据中心之间建立了专用连接，还是通过公共互联网在CDN网络中传输数据，包括控制信息、配置信息、监控信息和客户内容，以及是否使用了UDP的多路复用和有限次重传在不牺牲延时的情况下实现可靠性。
3.使用分布式控制进行协调
在考虑服务器时，还要考虑错误容忍性和可扩展性，这涉及许多因素，包括机器状态、与网络中其他机器的连接以及监控能力。当本地主服务器的连接性降低时，系统是否会自动选择一个新的服务器来承担主服务器的角色？这一点非常重要。
4.简单故障，优雅重启
网络应当被设计为能够迅速及无缝地处理服务器故障，并且能够从最后一个已知的良好状态重新启动服务器，这样可以降低服务器在潜在故障状态下工作的风险。如果某一台服务器持续不断地重启，那么只需将其置于“休眠”模式，就能尽可能减少对整个网络的影响。
5.阶段性软件发布
用户需要确定CDN供应商是否会分阶段将网络软件发布到实时网络中，也就是先在单台服务器上部署，然后在执行适当的检查后进行单个区域的部署，接着部署到网络的其他部分，最后进行全网部署。发布的方式决定了每个阶段持续的时间和数量。
6.主动检查缺陷
隔离故障的能力，在面向恢复的计算/系统中可能是最具挑战性的问题之一。如果一组特定内容的罕见配置参数请求会引发潜在的Bug，那么仅仅让受影响的服务器失效是不够的，因为这些内容的请求将被定向到其他服务器，从而扩大故障范围。是否有缓存算法将每组内容限制在特定的服务器上？这些限制是否根据当前对内容的需求水平动态确定，同时确保网络安全？这两个问题需要明确回答。
考虑到CDN的规模巨大和异构性，以及地理、时区和语言的多样性，维护大型的、高度分布的、基于互联网的网络可能会非常困难。我们需要的是操作简单、成本低、易于扩展的CDN网络。
从历史角度看，CDN方案主要关注静态内容的卸载和交付。然而，随着Web应用变得越来越动态化和个性化，受业务逻辑驱动的趋势越来越明显。因此，提高处理非内容的速度对于提供优质的用户体验变得越来越重要。
加快数据往返的速度是一个复杂的问题，但是通过使用高分布式的基础设施，许多优化方案都有可能实现。
TCP存在较大的开销，数据需要在通信双方之间多次传输以建立连接，这使得初始数据交换速率非常缓慢，并且从数据包丢失状态恢复的速度也非常缓慢。相比之下，采用持久连接并优化参数以提高效率的网络，可以通过减少传输同一数据组所需的往返次数来显著提高网络性能。
除了减少往返的开销外，我们还希望缩短每次通过互联网数据往返的时间。乍一看，这似乎无法实现，因为所有的互联网数据必须通过BGP路由，并且必须通过许多自治网络进行传输。
尽管BGP简单且可扩展，但其效率和健壮性并不强。然而，通过利用CDN，我们可以选择更快、更少拥堵的路由，从而将通信速度提高30%甚至更多。此外，当默认路由中断时，我们还可以通过寻找替代路由来实现更高的通信可靠性。
我们可以在软件层面上执行许多操作，以提高终端用户的Web软件响应性。一种方法就是内容预取：当边缘服务器向用户提供资源时，它也可以解析并缓存相关资源，然后在用户浏览器发出请求之前检索所有预取的内容。
这种优化的有效性依赖于接近用户的服务器。尽管实际上一些预取的内容是通过长距离获取的，但用户感知到的软件响应性却类似于直接从附近服务器获取的。需要注意的是，与链接预取不同，内容预取不会消耗额外的带宽资源，也不会请求与用户请求无关的对象。在这些情况下，预取对于Web软件的用户感知响应能力有显著的影响。
对基于文本的组件进行压缩可以将内容减少到原始大小的十分之一。利用增量编码，也就是服务器仅发送缓存页面与动态生成页面之间的差异，可以大大减少必须在互联网上传输的内容量。
通过使用内容分发网络（CDN）控制“中间网络”的两个端点，无论使用何种浏览器，都可以成功应用压缩和增量编码。在这种情况下，性能得到了提升，因为只有少量的数据需要传输到中间网络。然后，边缘服务器解压缩内容，将完整且正确的内容交付给最终用户。
边缘组装是在边缘服务器上缓存页面片段，并在边缘节点动态地组装它们以响应最终用户请求的过程。页面可以包含个性化数据，如最终用户的位置、连接速度、Cookie值等。边缘组装页面不仅可以减轻源服务器的压力，还可以避免中间的延时，从而降低最终用户的响应时间。
将软件分发到边缘服务器可以极大地提高软件的性能和可扩展性。如同边缘页面组装，边缘计算支持全面的源服务器加载，这为终端用户带来了巨大的可扩展性和极低的软件延时。
虽然并不是所有类型的软件都适合使用边缘计算，但许多流行的应用（如产品目录、存储、产品配置、游戏等）都非常适合使用边缘计算。
如今，数据中心内部服务器的接入带宽逐年增大，各大互联网企业正在将接入带宽从万兆（10Gbit/s）升级到25Gbit/s，某些用于机器学习的服务器甚至已经使用了100Gbit/s的接入带宽。增大的接入带宽使传统的TCP/IP协议栈遇到了严重的性能瓶颈。
然而，100Gbit/s的接入带宽可能只能实现不到13Gbit/s的实际吞吐量。在当前的操作系统中，使用TCP传输数据需要大量的CPU参与，包括报文的封装解析、TCP的流量控制处理等。由于一个TCP流的报文由一个CPU核处理，因此单个TCP流的最大吞吐量受制于CPU单核的处理能力。遗憾的是，CPU单核计算能力的提升已经变得非常困难。这就意味着采用传统TCP/IP协议栈的数据传输必然会遇到吞吐量的上限。如果想充分利用25Gbit/s或100Gbit/s的接入带宽，就必须使用多流并行传输。多流并行传输一方面增加了程序的复杂度，另一方面也意味着必须将更多的、昂贵的计算资源投到网络传输的数据处理中。
除了带宽问题，时延也是使用传统TCP/IP协议栈的另一个困扰。假设一个软件要发送一段数据，必须先通过Socket API将数据从用户态进入内核态，经过内核的报文处理后，再交给网络协议栈发送出去。类似地，在接收端，内核先收到报文，处理后提取出数据，等待用户态取出。其中包含了内核态/用户态的转换、CPU的报文处理，以及操作系统的中断。因此，在一小段数据的传输时延中，真正占主要部分的并非在物理网络上的传输时延，而是在发送端和接收端软件协议栈中的处理时延。
传统的TCP/IP协议栈采用软件方式处理报文，无法解决上述问题。随着数据中心内通信的高带宽、低时延需求日益普遍，高性能网络应运而生。
在高性能计算集群中，广泛使用的网络并不是以太网+TCP/IP，而是Infiniband。Infiniband是一套从物理层到传输层的完整协议栈。事实上，Infiniband的物理接口与常见的以太网接口完全不同。Infiniband网络（简称IB网络）是一种完全不同于一般数据中心中常见的以太网架构的网络。
Infiniband的设计理念与以太网完全不同。首先，Infiniband基于集中控制的网络设计，这简化了交换设备的复杂性，有助于降低转发时延，但这也导致了Infiniband网络的扩展性不如Ethernet（以太网）。其次，Infiniband希望上层表现为一条计算机内的总线（这是超级计算机思想的自然延伸），因此Infiniband并不像Ethernet那样采用Best Effort的转发策略，而是采用了尽可能避免丢包的无损设计，并且上层编程接口开放了直接针对远程内存的读写。Infiniband传输层的协议就是RDMA，即远程直接内存访问，它利用了底层网络的无损特性，并向上层软件提供了一种称为Verbs API的编程接口。RDMA从设计之初就是让硬件网卡ASIC而非CPU来执行网络传输的相关操作。
2000年，首个Infiniband标准诞生，并在HPC领域得到广泛应用。然而，Infiniband网络并不适合一般的网络连接场景，因此，Ethernet一直主导着互联网数据中心。在Infiniband出现的10年里，Infiniband网络和以太网各自在其擅长的领域内得到发展。到了2010年，首个RDMA over Converged Ethernet（RoCE）标准形成，使得Infiniband网络的传输层协议RDMA能够以Overlay的形式运行于Ethernet之上。此时，Infiniband网络和以太网开始交汇，原本属于HPC的RDMA技术逐渐进入一般数据中心，为即将到来的AI计算和云计算的快速增长提供了关键的支持。
需要注意的是，与Infiniband相比，RoCE的性能稍逊一筹。近年来，一些AI计算集群也开始直接使用Infiniband，但这并非主流，原因如下：
· Infiniband网络的构建成本比以太网高出约一倍，如果再考虑到运维成本和运维难度，那么Infiniband网络的成本确实过高。
· Infiniband网络只适用于HPC（虽然IPoIB的方式可以让Infiniband网络支持原有的TCP/IP软件，但这就像在MAC计算机上安装Windows系统一样，毫无必要），并且与现有的以太网难以互联。
因此，出于兼容性的考虑，一般不会选择Infiniband。RoCE技术已经成为互联网企业数据中心使用RDMA的标准方式。RoCE的报文结构如图5-1所示。
图5-1 RoCE的报文结构
RoCE经历了两个版本——RoCEv1和RoCEv2。它们的主要区别在于，RoCEv1是MAC地址上的RDMA Overlay，不能跨子网，而RoCEv2则是基于UDP的RDMA Overlay，可以跨子网。目前，RoCEv2基本已替代RoCEv1。封装在UDP中的RoCE报文有特殊的目的端口号4791，源端口号则是任意的。这样，网络中的交换设备可以将RoCE报文视为普通的UDP报文，利用五元组ECMP进行流量负载均衡。在UDP的有效负载（Payload）中，RoCE报文还有一个Infiniband协议栈中传输层（即RDMA）的头部BTH，其中包含两端L4 endpoint等信息，用于识别后面的数据与哪个软件的哪段内存相关联。
如果读者稍微了解RDMA，就会发现有两个关键词经常与RDMA同时出现，即Kernel Bypass和Zero Copy。图5-2所示为RDMA与TCP/IP协议栈的处理对比。
在TCP/IP协议栈中，软件的数据首先通过Socket API复制进入操作系统内核，然后内核调用TCP/IP协议栈进行报文封装等处理，最后交给网卡发送。接收端则执行这一过程的逆向操作。而在使用RDMA时，软件的数据无须经过内核处理，也无须进行内存复制，而是由RDMA网卡（即RNIC）直接从用户态内存中获取数据并传送到网卡上，再由网卡硬件进行封装等处理。接收端从网卡解封装后，直接将数据从内存中取出并传送给用户态内存。这就是RDMA技术中Kernel Bypass和Zero Copy两个特性的真正含义。图5-2中，RDMA左边经过libibverbs的部分通常被称为Command Channel，这是软件调用Verbs API时的命令通道，并非真正的数据通道。
图5-2 RDMA与TCP/IP协议栈的处理对比
正是由于Kernel Bypass和Zero Copy的存在，RDMA获得了3个关键的衍生特性——低延时、高带宽和低CPU消耗。这3个衍生特性经常被提出作为RDMA相对于TCP/IP协议栈的主要优势。但这3个特性是由Kernel Bypass和Zero Copy带来的。需要特别注意的是，Kernel Bypass和Zero Copy都需要网卡的硬件支持，普通的以太网卡无法实现。这意味着想要使用RDMA，就必须拥有支持RDMA技术的网卡。没有硬件支持，RDMA就无法使用（当然，也有一些方案使用软件模拟RDMA网卡的行为，如Soft-RoCE，但这显然已经违背了RDMA的基本特性）。
软件通过使用Verbs API而非Socket API来实现RDMA。对于缺乏相关经验的开发人员来说，Verbs API可能会显得很陌生。为了更好地理解Verbs API，我们必须明白RDMA在主机端的操作机制。图5-3所示为RDMA主机端的一些重要概念。
RDMA具有3种队列——发送队列（SQ）、接收队列（RQ）和完成队列（CQ）。SQ和RQ通常成对出现，被统称为队列对（QP）。SQ是发送请求（即Send Work Request，Send WR）的队列，RQ是接收请求（即Recv Work Request，Recv WR）的队列，而CQ是记录发送请求和接收请求完成情况的队列。这些队列以及其他一些资源的创建（API：ibv_create_qp、ibv_create_cq等）是通过图5-2所示的libibverbs中的API（控制路径）实现的。
图5-3 RDMA主机端的一些重要概念
当软件需要发送数据时，它会向SQ提交一个发送请求（API：ibv_post_send）。请注意，此请求不包含数据本身，而只包含指向数据的指针和数据的长度。这个提交操作是通过图5-2所示的libibverbs API（数据路径）实现的。请求会传递到网卡，网卡根据地址和长度获取要发送的数据，然后通过网络发送。发送完成后，CQ中会生成一个发送完成说明。
在接收端，软件必须预先向RQ提交一个接收请求（API：ibv_post_recv），该请求包含了接收数据应存放的内存指针和最大接收数据长度。当数据到达时，网卡会把数据放在RQ队列头部的接收请求所指定的内存位置，然后在CQ中生成一个接收完成说明。
Verbs API的发送和接收都是异步非阻塞的调用。软件需要检查CQ中的完成情况说明（API：ibv_poll_cq）来判断请求是否完成。这里的QP可以视为类似于TCP/UDP中的Socket，标识一个L4的端点。如果采用基于可靠连接的RDMA模式，那么在开始建立连接时，需要绑定本端的QP和对端的QP。
图5-3中有一个名为“注册内存（Registered Memory）”的概念。SQ和RQ中的请求必须指向已经注册的内存位置。这里的“注册”是指将软件的虚拟地址和物理地址绑定，并将这个映射关系注册给RDMA网卡。软件需要自己负责内存的注册（API：ibv_reg_mr）。如果发送请求或接收请求指向了未注册的内存，那么请求就会失败，因为网卡无法判断请求中指定的虚拟地址在物理内存中的具体位置。
实际上，在RDMA中，除了Send/Recv外，还有RDMA Write/Read两种特别的请求，它们可以直接访问远端软件的虚拟内存。RDMA Write/Read请求也是提交给发起端的SQ（如图5-3中的RDMA WR所示），但是与Send/Recv不同的是，另一端并不需要事先提交接收请求到RQ。这种单边的RDMA传输方式通常会比Send/Recv有更好的性能，但是挑战在于必须事先知道数据在对端的确切地址。
以上就是Verbs API的核心内容。当然，在实际的RDMA程序中，使用会更复杂。
Infiniband网络是无丢包的底层网络，这意味着没有交换机或网卡Buffer溢出的丢包，但是链路中断、传输物理错误等丢包是无法避免的。丢包是网络传输性能的杀手，为了从丢包中快速恢复，需要引入复杂且难以用硬件实现的处理逻辑。然而，以太网是有丢包的，那么以太网上的RDMA（RoCE）是如何实现的呢？实际上，以太网可以通过Pause机制变成无丢包的，图5-4所示为Pause的作用机制。
图5-4 Pause的作用机制
假设服务器E和G同时以最大速率向F发送数据，交换机C连接到F端口的出队列将首先出现Buffer堆积。此时，交换机C会通知其余两个端口停止向其转发报文。因此，剩下的两个端口的入队列将会紧接着出现Buffer堆积。
进一步说，两个端口会向上游发送一个暂停帧（一种以太网二层帧）。这将导致交换机B的右端口和服务器G停止发送数据，交换机B右端口的出队列会出现Buffer堆积，而服务器G的网卡则会停止发送报文。
交换机B会继续向服务器E发送暂停状态，导致E也停止发送报文。这种停止只在一段时间内有效。实际上，服务器E和G会在暂停的调控下，断断续续地以最大速率向F发送数据，从而避免Buffer溢出丢包。
需要注意的是，不同的交换芯片对出入队列的管理方法是不同的，这里并没有进行区分。
虽然这种逐跳的流控机制看似很好地解决了丢包问题，但在一般情况下并不适用，因为它对无关流有负面影响。以图5-4为例，假设服务器D也在向其他交换机下的某服务器发送数据，数据流通过交换机A的上联端口。由于交换机A的上联端口被暂停，来自服务器D的数据也被无差别地暂停。问题是，服务器D并不是导致拥塞的相关方，这种不公平的限速使Pause机制默认不启用。但是，无丢包是RDMA的关键，因此我们在RoCE中启用Pause机制，尽可能限制其副作用。例如，可以在网络中分出不同的优先级队列，只在特定的队列上开启暂停，这就是以太网的优先级流控（PFC）机制，已经作为DCB标准的一部分。现在大多数的数据中心交换机都支持PFC。在PFC配置生效时，让RDMA流量在开启了Pause机制的优先级下运行，而让TCP流量在没有开启Pause的优先级下运行，从而尽可能限制Pause机制的副作用。尽管有了PFC，Pause机制的副作用在实际中仍不可忽视。因此，新版的RoCE网卡已开始支持相对简单的端到端拥塞控制机制，这种机制依赖于网络的ECN配置，也就是要求交换机可以进行显式拥塞通告。
虽然RDMA可以在特殊设计的前提下放弃PFC配置，但由于这样的设备并没有真正诞生，所以我们仍然假定RDMA需要无损的底层网络支持。需要牢记的是，RDMA的正常使用高度依赖于网络内交换设备以及网卡的正确配置（TCP/IP中没有的配置）。因此，不要期望插上RDMA网卡就可以开始运行RDMA程序。如果要顺利使用RDMA，应确保服务器所在的网络进行了RDMA相关配置。
RDMA技术的优势究竟有多大？如果以带宽和延时作为评估标准，对于100Gbit/s的网卡带宽，其吞吐量可以达到11000MB/s，大约相当于88Gbit/s。此时，CPU的消耗几乎为零，RDMA下的单程延时平均值只有几微秒。
RDMA目前主要有两类应用场景：一是高性能计算，包括分布式机器学习训练，特别是在使用GPU的时候；二是计算存储分离。前者主要关注高带宽，代表案例有Tensorf low、Paddlepaddle、Mpi、Nccl等。后者主要关注低延时，代表案例有Nvmf、Smb Direct以及阿里的盘古2.0等。除了以上两类场景，RDMA在大数据处理（如Spark）和虚拟化（如虚拟机迁移）等场景中也有应用。
随着微服务架构的日益流行，其下的一些问题也日益凸显。例如，一个请求可能会涉及多个服务，而这些服务本身可能还依赖于其他多个业务，因此整个请求路径就形成了一个网状的网络调用链。在这个调用链中，一旦某个节点发生异常，就可能影响整个调用链的稳定性。因此，当网络出现故障或性能问题时，如何更好地发现和定位问题成了需要解决的关键问题。
网络可观测性基于网络监控收集的数据。它能帮助用户维护网络健康，提供一种更高效且可扩展的方法。可观测性可以对各种系统形态和实时状态进行结构化的收集，并提供一系列观察和测量手段。简而言之，它利用各种技术，使开发人员、测试人员、运维人员能实时了解系统运行状态，而非仅仅进行“监控”。
网络可观测性主要包括收集、组织和分析3个步骤。
收集的目的是了解网络的实时延时情况。这些网络延时指标包括外部网络的延时和软件的延时数据。通常，互联网用户从远程访问公司的4层代理，然后转发到7层代理，最后到达软件。软件内部可能会存在多个RPC和数据库调用。我们应该重点采集各个阶段的延时情况，特别是软件内部的调用延时。这部分通常是故障发生的主要区域。除了软件层面的延时指标，还需要关注以下网络指标。
· 吞吐量：网络吞吐量是在一定时间内通过网络传输的数据量，也可以理解为网络传输的速率。吞吐量反映了网络的数据传输效率，越高则网络传输数据的速度越快，可以更快地传输大量的数据。网络吞吐量直接影响用户的体验，并且是衡量网络性能是否能满足业务需求的重要指标。如果网络吞吐量不能满足业务需求，那么它会影响工作效率和生产力。因此，我们需要关注并监控网络吞吐量，针对吞吐量不足的情况进行优化和升级，以提高网络的性能和效率。
· 连接数：连接数是服务器能同时处理的点对点连接数量，这个参数的大小直接影响服务器所能支持的最大连接数。过多的连接数可能导致网络拥塞、内存压力、系统负载过高等问题。为避免此类问题，我们应该采集连接数量指标，并根据负载情况和系统容量控制连接数大小。如果需要处理大量连接，则可以考虑使用负载均衡、缓存技术等方式来分散压力，提高系统性能。
· 错误：常见的错误包括网卡发送和接收队列丢包、网络错误等。
· TCP重传：重传机制是TCP实现可靠传输的方式之一。常见的重传方式有超时重传、快速重传、SACK、D-SACK。重传可能会导致时延上升，我们应该把TCP重传作为衡量网络性能指标的方式之一。
· TCP乱序数据包：TCP乱序是指TCP数据包在传输过程中的顺序与发送顺序不一致的现象。这通常是由于网络中的报文分片和重组、网络设备的缓存队列或者网络拥塞导致的。TCP在重组数据包时会依据数据包的序号进行重组，因此，如果一些数据包在网络中延时了，那么这些延时的数据包可能先于其他数据包到达目的地，从而导致数据包的顺序错误。TCP乱序是由网络环境所带来的，无法完全避免，但是，可以通过采集乱序数据包指标，然后改进网络算法等方式来减小其发生的频率和影响。
网络请求数据是典型的时间序列数据，我们通常使用时序数据库（Time Series Database，TSDB）来存储网络指标。这种方法通过在时间维度上压缩存储监控数据，降低了写入开销。另外，时序数据库通常具有丰富的统计和计算能力，如中位数、平均值、概率分布等。
我们组织数据的目的是将网络延时和软件内部延时进行上下文化，建立指标、日志、链路系统之间的关联。这会使我们更容易理解网络性能趋势如何影响软件或业务场景。在组织数据时，必须保证数据的统一性。否则，如果日志系统、链路追踪系统、指标系统是分开的，就很难实现数据与数据之间的关联。例如，如果日志中的字段在主机系统中被称为Host，在监控指标系统中被称为Host Name，而业务系统使用IP地址，那么在进行自动化关联分析和连接查询时就会发现无从下手。
分析数据是网络可观测性的最后一步。我们可以利用可观测性平台进行性能问题的剖析和故障原因的排查。
网络通常因其潜在的拥塞和固有的复杂性而被指责性能不佳或频繁故障。当可观测性平台无法解释某些问题时，网络分析工具可以通过使用其提供的关键指标来找出问题的根源，排除网络的“责任”，使分析能够继续进行。
对于网络通信，以下是常用网络分析工具可以检查的一些内容。
· tcpdump、Wireshark、tshark。 tcpdump是一款运行在Linux平台上的强大网络抓包工具，能够分析和调试网络数据。要想掌握tcpdump，必须对网络报文（如TCP/IP）有一定的理解。Wireshark是一款网络数据包分析软件，可以打开网络数据包，显示出尽可能详细的网络数据包内容。我们通常使用tcpdump抓取网络数据包并保存到本地，然后导入Wireshark中进行分析。tshark是Wireshark的命令行版本，它不仅有过滤抓包的功能，还有网络分析的能力。巧妙运用tshark提取数据包可以节约大量的网络分析时间。
· traceroute/ping。 traceroute命令用于测试数据包从发送主机到目的地所经过的设备，主要检查网络连接是否可达，以及网络的哪个部分出现了故障。ping命令可以告诉用户目标是否可达以及一次请求往返所花费的总时间。
· Netperf/iperf。 Netperf和iperf都是网络性能的测量工具。Netperf主要对基于TCP或UDP的传输进行测试。根据应用的不同，Netperf可以进行不同模式的网络性能测试，即批量数据传输模式和请求/应答模式。iperf可以测试最大TCP和UDP带宽性能，具有多种参数和特性，可以根据需要进行调整，可以报告带宽、时延抖动和数据包丢失。
· ss/netstat。 ss命令可以用来获取Socket统计信息，如网络连接、路由表、接口统计状态、无效连接等。它可以显示和netstat类似的内容，但ss的优势在于它能够显示更详细的有关网络连接的状态信息，而且比netstat更快速、更高效。
在互联网的软件应用系统中，许多优化技术都依赖于高度分布式的CDN网络。路由优化依赖于大规模地覆盖网络的可用性，这个网络包含了许多不同网络上的机器。如果交付服务器靠近最终用户，那么内容预取和页面动态组装的优化方法将最有效。另外，许多传输层和应用层的优化需要在网络中使用双节点连接。为了最大化这种优化连接的效果，端点应尽可能接近源服务器和最终用户。
这些优化是协同工作的。TCP开销在很大程度上是保证在不确定的网络条件下的可靠性的结果。由于路由优化为我们提供了高性能、无拥塞的路径，所以它允许我们采用更积极、更有效的方法来优化传输层。
在数据中心内部或计算密集型应用中，性能提升通常依赖于高性能网络。RDMA通过内核绕过和零拷贝实现了网络传输的低延时、高带宽和低CPU消耗。软件需要通过Verbs API使用RDMA，而RDMA则需要底层网络具备无丢包配置。RDMA技术降低的延时通常在微秒级到百微秒级。如果延时在毫秒级，则应首先分析这些延时的具体构成，很可能瓶颈并不在网络传输上。