[网络协议]性能之巅:洞悉系统、企业与云计算——网络

随着系统变得越来越分布化，尤其是云计算环境中，网络在性能方面扮演着的角色越来越重要。除了改进网络延时和吞吐量以外，另一个常见的任务是消除可能有丢包引起的延时异常。

网络分析是跨硬件和软件的。这里的硬件指的是物理网络，包括网络接口卡、交换机、路由器和网关。这里的系统软件指的是内核协议，通常是TCP/IP，以及每个所涉及的协议的行为。

术语

• 接口：术语 “接口端口”，interface port，指网络物理连接器。术语“接口” 或者 “连接” 指操作系统可见并且配置的网络接口端口的逻辑实例。
• 数据包：术语 “数据包” 通常指 IP 级可路由的报文。
• 帧：一个物理网络级的报文，例如以太网帧。
• 带宽：对应网络类型的最大数据传输率，通常以 b/s 为单位测量。10GbE 是带宽 10Gb/s 的以太网。
• 吞吐量：当前两个网络端点之间的数据传输率，以 b/s 或者 B/s 为单位测量。
• 延时：网络延时指一个报文往返端点所需的时间，或者值建立连接所需的时间（例如，TCP 握手），不包括之后的数据传输时间。

模型

网络接口

网络接口是网络连接的操作系统端点，它是系统管理员可以配置和管理的抽象层。

上图描绘了一个网络接口。作为网络接口配置的一部分，它被映射到物理网络端口。端口连接到网络上并且通常由分离的传输和接收通道。

控制器

网络接口卡（NIC）给系统提供一个或多个网络端口并且设有一个网络控制器：一个在端口与系统 I/O 传输通道间传输包的微处理器。一个带有四个端口的控制器示列如下图，图中展示了该控制器所含有的物理组件。

控制器可作为独立的板卡提供或内置于系统主板中。

协议栈

网络通信是由一组协议栈组成的，其中的每一层实现一个特定的目标。下图展示了包含协议示列的俩个协议栈模型。

图中的较低的层画的较宽以表明协议封装。传输的报文向下从应用程序移到到物理网络。接收的报文则向上移动。

尽管 TCP/IP 栈已成为标准，了解 OSI 模型也有帮助。例如 OSI会话层通常以BSD 套接字出现在 TCP/IP 栈里。“层” 这个术语源自 OS，这里第3层指网络协议层。

概念

以下是一些网络通信和网络性能的概念精选

网络和路由

网络是一组由网络协议地址联系在一起的相连主机。我们有多个网络——而非一个巨型的全球网络——是有许多原因的，其中特别有扩展性的原因。某些网络报文会广播到所有相邻的主机，通过建立更小的子网络，这类广播报文能隔离在本地从而不引起更大范围的广播的泛滥。这也是常规报文隔离的基础，使其仅在源和目标网络间传输，这样能更有效地使用网络基础架构。

路由管理称为包的报文跨网络传递。下图展示了路由的作用。

以主机 A 的视角来看，localhost是它自己，其他所有主机都是远程主机。

主机 A 可以通过本地网络连接到主机 B，这通常是由网络交换机驱动。主机 A 可路由器 1连接到主机 C，以及由路由器1、2和3连接到主机 D。类似路由器这样的网络组件是共享的，源自其他通信的竞争（例如主机 C 到主机 E）可能会影响性能。

成对主机件由单播（unicast）传输连接。多播（multicast）传输允许一个发送者可能跨多个网络同时传输给多个目标。它的传递依赖于路由器配置的支持。

路由包需要的地址信息包含在 IP 数据包头中。

协议

例如 IP、TCP 和 UDP 这样的网络协议标准是系统与设备间通信的必要条件。通信传输称为包的报文来实现，它通常包含封装的负载数据。

网络协议具有不同的性能特性，源自初始的协议设计、扩展，或者软硬件的特殊处理。

例如不同的 IP 协议版本 IPv4 和 IPv6，可能会由不同的内核代码路径处理，进而表现出不同的性能特性。

通常系统的可调参数也能影响协议性能，如修改缓冲区大小、算法以及不同的计时器设置。

包的长度以及它们的负载也会影响性能，更大的长度增加吞吐量并且降低宝的系统开销。对于 TCP/IP 和以太网，包括封装数据在内的包长度介于54~9054B，其中包括54 B（或者更长，取决于选项或者版本）的协议包头。

封装

包封装会添加元数据到负载前（包头）、之后（包尾），或者两者。这不会修改负载数据，尽管它会轻微地增加报文总长度，而这也会增加一些传输的系统开销。

下图展示了以太网中的 TCP/IP 栈封装。

E.H. 是以太网包头而 E.F. 是可选的以太网包尾。

包长度

包的长度通常受限于网络接口的最大传输单元（MTU）长度，许多以太网中它设为为1500B。以太网支持接近9000B 的特大包（帧），也称为巨型帧。这能够提高网络吞吐性能，同时因为需要更少的包而降低了数据传输延时。

这两者的融合影响了巨型帧的接受程度：陈旧的网络硬件和未正确配置的防火墙。陈旧的不支持巨型帧的硬件可能会用 IP 协议分段包或者返回 ICMP “不能分段” 错误，来要求发送方减小包长度。现在未正确配置的防火墙开始起作用：对于过去基于 ICMP 的网络工具攻击（包括“死忙之ping”），防火墙管理员通常以阻塞所有 ICMP 包的方式应对。这会阻止有用的“不能分段” 报文到达发送方，并且一旦包长度超过1500 将导致网络包被静默地丢弃。为避免这个问题，许多系统坚持使用默认的1500 MTU。

网络接口卡功能已经提升了 1500MTU 帧的性能，这包括 TCP 卸载（TOE）和大块分段卸载（LSO）。大段的缓冲被发往网络接口卡，网卡利用优化过的专用硬件将缓冲分割为较小的帧。在某种程度上，缩短了 15000 与9000MTU 之间的性能差距

延时

延时是一个重要的网络性能指标并能用不同的方法测量，包括主机名解析延时、ping 延时、连接延时、首字节延时、往返时间，以及连接生命周期。这些都是以客户端连接到服务器的延时来描述的。

主机名解析延时

与远程主机建立连接时，主机名需要解析为IP 地址，例如用DNS 解析。该过程所需的时间独立计量为主机名解析延时。该延时最坏的情况是主机名解析超时，通常需要几十秒。

ping 延时

用 ping(1) 命令测量的 ICMP echo请求到 echo 响应所需的时间。该时间用来衡量主机对之间包括网络跳跃的网络延时，而且它测量的是包往返的总时间。因为简单并且随时可用，它的使用很普遍：许多操作系统默认会响应ping。

下表展示了ping 的延时示列。为了更好地展示其数量级，Scaled列显示了基于虚构的本机ping 延时为了 1s 时的一系列比较值。

在接收端，ICMP echo请求通常做中断处理并立即返回，这尽可能地减少了内核代码运行的世界。在发送端，由于时间戳由用户层测量，并且包括内核上下文切换和内核代码路径世界，它可能会包括少量附加的时间。

连接延时

连接延时是传输任何数据前建立网络连接所需的时间。对于 TCP 连接延时，这是 TCP 握手时间。从客户端测量，它是从发送 SYN 到接收到响应的 SYN-ACK 的时间。连接延时也许更适合被称作连接建立时，以清晰地区别于连接生命周期。

连接延时类似于 ping 延时，尽管它要运行更多内核代码以建立连接并且包括重新传输任何被丢弃的包所需的世界。尤其是 TCP SYN 包在队列已满的情况下会被服务器丢弃，引起客户端重新传输 SYN。由于发生在 TCP 握手阶段，连接延时包括重新传输延时，会增加 1s或更多
连接延时之后是首字节延时

首字节延时

也被称为第一字节到达时间（TTFB），首字节延时是从连接建立到接收到第一个字节数据所需的时间。这包括远程主机受连接、调度提供服务的线程，并且执行线程以及发送第一个字节所需的时间。

想对于 ping 和链接延时测量的是产生于网络的延时，首字节延时包括目标服务器的处理时间。这可能包括当服务器过载时需要时间处理请求（例如 TCP 积压队列）以及调度服务器（CPU队列处理延时）造成的延时。

往返时间

往返时间指网络包往返两个端点所需的时间。

连接生命周期

连接生命周期指一个网络连接从建立到关闭所需的时间。一些协议支持长连接策略因而之后的操作可以利用现有的连接，进而避免这种系统开销以及建立连接的延时。

缓冲

尽管存在多种网络延时，利用发送端和接收端的缓冲，网络吞吐量扔能保持高速率。较大的缓冲可以通过在阻塞和等待确认前持续传输数据缓存高往返延时带来的影响。

TCP利用缓存以及可变的发送窗口提升吞吐量。网络套接字也保有缓冲，并且应用程序可能也会利用它们自己的缓冲在发送前聚集数据。

外部的网络组件，如交换机和路由器，也会利用缓冲提高它们的吞吐量。遗憾的是在这些组件中使用的高缓冲，如果包长时间在队列中，会导致被称为缓冲膨胀的问题。这会引发主机中的 TCP 阻塞避免（功能），它会限制性能。

缓冲（或者最大缓冲）功能有端点（主机）提供效果最佳，它通常遵守端到端争论（end-to-end arguments）原则。

连接积压队列

另一类型的缓冲用于最初的连接请求。TCP 的积压队列实现会把 SYN 请求在用户级进程接收前队列于内核中。过多的 TCP 连接请求超过进程当前的处理能力，积压队列会达到极限而丢弃客户端可以迟些时候再重新传输的 SYN 包。这些包的重新传输会增加客户端连接的时间。

测量因积压队列导致的丢包是一种衡量网络连接饱和度的方法。

接口协商

通过与对端的自动协商，网络接口能够工作于不同的模式。一些实例如下：

• 带宽：例如，10、100、1000、10000MB/s。
• 双工（模式）：半双工或者全双工。

这些示例来自以太网，它用十进制数作为带宽极限。其他的物理层协议，例如SONET，使用一组不同的可能带宽。

网络接口通常用它们的最大带宽及协议描述，例如，1GB/s 以太网（1GbE）。必要时，这个接口可以协商使用较低的速率。如果对端不能支持更高的速率，或者不能处理连接介质的物理问题（线路故障）时，这就可能发生。

全双工模式允许双向同时传输，利用分离的通道传输和接收能利用全部带宽。半双工模式仅允许单向的传输。

使用率

网络接口的使用可以用当前的吞吐量除以最大带宽来计算。考虑到可变的带宽和自动协商的双工模式，计算它不像看上去这么直接。

对于全双工，使用率使用于每个方向并且用该方向当前的吞吐量除以当前协商的带宽来计量。通常只有一个方向最重要，因为主机通常是非对称的：服务器偏重传输，而客户端偏重接收。

一旦网络接口方向达到100%的使用率，它就会成为瓶颈，限制性能。

一些操作系统性能统计仅按包而不是字节报告活动。因为包的长度可变性很大，不可能通过吞吐量或者（基于吞吐量的）使用率将包与字节数建立联系。

本地连接

网络连接可以发送于同一个系统的两个应用程序间。这就是本地连接而且会使用一个虚拟的网络接口：回送接口。

分布式的应用程序环境常常会划分为通过网络通信的逻辑模块。这包括 Web 服务器、数据库服务器和应用服务器。如果它们运行于同一个主机，它们的连接通过本机实现。

通过 IP 与本机通信是 IP 套接字的进程间通信技巧。另一个技巧是 UNIX 域套接字（UDS），它在文件系统中建立一个用于通信的文件。由于省略了 TCP/IP 栈的内核代码以及协议包封装的系统开销，UDS的性能会更好。

对于TCP/IP 套接字，内核能够在握手后检测到本地连接，进而为数据传输短路 TCP/IP 栈以提高性能。

架构

协议

TCP

传输控制协议（TCP）是一个常用的用于建立可靠网络连接的互联网标准。TCP由（RFC 793）以及之后的增补定义。

就性能而言，即使在高延时的网络中，利用缓冲和可变窗口，TCP 也能够提供高吞吐量。TCP 还会利用阻塞控制以及由发送方设置的阻塞窗口，因而不仅能保持高速而且跨越不同并变化的网络中保持合适的传输速率。阻塞控制能避免会导致网络阻塞进而损害性能的过渡发送。

以下是TCP 性能特性的总结，包括了自最初定义以后的增补：

• 可变窗口：允许在收到确认前在网络上发送总和小于窗口大小的多个包，以在高延时的网络中提供高吞量。窗口的大小由接收方通知以表明当前意愿接收的包的数量。
• 阻塞避免：阻止发送过多的数据进而导致饱和，它会导致丢包而损害性能。
• 缓启动：TCP 阻塞控制的一部分，它会以较小的阻塞窗口开始而后按一定时间内接收到的确认（ACK）逐渐增加。如果没有收到，阻塞窗口会降低。
• 选择性确认（SACK）：允许 TCP 确认非连续的包，以减少需要重传输的数量。
• 快速重传输：通过重设连接开始慢启动，以在检测到重复确认后恢复 TCP 性能。

一些情况下这些是利用附加于协议头的TCP 扩展选项实现的。

关于 TCP 性能的重要内容包括三次握手、重复确认检测、阻塞控制算法、Nagle算法、延时确认、SACK和FACK。

三次握手

连接的建立需要主机间的三次握手。一个主机被动地等待连接，另一方主动地发起连接。作为术语的澄清：被动和主动源自 [RFC 793]，然而它们通常按套接字 API 分别被称为侦听和连接。按客户端/服务器模型，服务器侦听而客户端发起连接。下图描绘了三次握手。

上图指出客户端的连接延时，它截止于收到最终的 ACK，之后数据传输开始。上图展示的是最佳状况下的握手延时。包可能被丢弃，并由于超时和重新传输而增加延时。

重复确认检测

快速重传输和快速恢复会利用重复确认检测算法。它允许于发送方，其工作方式如下：

1. 发送方发送一个序号为10的包。
2. 接收方返回一个序号为11 的确认包。
3. 发送方发送包11、12和13。
4. 包 11 被丢弃。
5. 接收方发送序号为11的确认包以响应包12和13，表明它仍然在等待（包11）。
6. 发送方收到重复的序号为 11 的确认包。

TCP Reno和 Tahoe 阻塞避免算法也会利用重复确认检测。

阻塞控制：Reno 和 Tahoe

• Reon：三次重复确认触发器，即阻塞窗口减半、慢启动阀值减半、快速重传输和快速恢复。
• Tahoe：三次重复确认触发器，即快速重传输、慢启动阀值减半、阻塞窗口设置为最大报文段长度（MSS）和慢启动状态。

Nagle 算法

该算法通过推迟小尺寸包的传输以减少网络中的这些包的数量，从而使得更多的数据能到达与合并。仅当有数据进入数据通道并且已经发送延时时，它才会推迟数据包。

系统可能会提供禁用 Nagle 的可调参数。当它的运行与延时 ACK 发送冲突时该参数就显得必要了。

延时 ACK

该算法推迟最多500ms 发送 ACK，从而能合并多个 ACK。其他 TCP控制报文也能合并，进而减少网络中的包的数量。

SACK 与 FACK

TCP 选择性确认（SACK）算法允许接收方通知发送方收到非连续的数据块。如果缺乏这一特性，为保留顺序确认的结构，一个丢包会最终导致整个发送窗口被重新传输。这会损害性能，大多数支持 SACK 的现代操作系统都会避免这种情况。

Linux默认支持由SACK扩展而来的向前确认（FACK）。FACK 跟踪更多的状态并且能更好地控制网络中未完成的数据传输，并提高整体性能。

UDP

用户数据报协议（UDP）是一个常用于发送网络数据报文的互联网标准。就性能而言，UDP 提供如下特性：

• 简单：简单而短小的协议头降低了计算与长度带来的系统开销。
• 无状态：降低连接与传输控制带来的系统开销。
• 无重新传输：这些给 TCP 增加了大量的连接延时。

尽管简单并且通常能提供高性能，但 UDP 并不可靠，而且数据可能会丢失或者乱序发送。因此它不适合许多类型的连接。UDP 也缺乏阻塞避免因而因为网络阻塞。

一些服务可以按需配置使用 TCP 或者 UDP，这包括某些版本的 NFS。其他需要广播或者多播数据的服务只能使用 UDP。

硬件

网络硬件包括接口、控制器、交换机和路由器。尽管这些组件由其他工作人员来管理，但是我们还是需要理解它们的运行。

接口

物理网络接口在连接的网络上发送并接收称为帧的报文。它们处理包括传输错误在内的电器、光学或者无线信号。

接口类型基于第 2 层网络标准。每个类型都存在最大带宽。高带宽接口通常延时更低，而成本更高。这也是设计新服务器的一个关键选择，要平衡服务器的售价与期望的网络性能。

对于以太网，备选包括铜缆或者光迁，而最大速率是 1GB/s（1GbE）、10GbE、40GbE 或者100GbE。众多供应商生产以太网接口控制器，尽快操作系统不一定有驱动程序支持。

接口使用率用当前吞吐量除以当前协商的带宽来测量。多数接口分离传输与接收通道，因此当处于全双工模式时，每个通道的使用率必须分布研究。

控制器

物理网络接口控制器提供给系统。它集成于系统扳或者利用扩展卡。

控制器由微处理器驱动并通过 I/O 传输通道（例如 PCI）接入系统。其中任意一个都可能成为网络吞吐量或者IOPS 的瓶颈。

交换机、路由器

交换机提供两个连入的主机专用的通信路径，允许多个主机间的多个传输不受影响。此技术取代了集线器，它在所有主机间共享所有包。当主机同时传输时，这种共享会导致竞争。接口以“载波侦听多路访问/碰撞检测”（CSMA/CD）算法发现这种冲突，并按指数方式推迟知道重新传输成功。在高负载情况下这种行为会导致性能问题。自使用交换机之后就不再存在这种问题了，不过观测工具仍然提供碰撞计数器——尽管这些通常仅在故障情况（协商或者故障路线）下出现。

路由器在网络传递数据包，并且用网路协议和路由表来确认最佳的传递路径。在两个城市间发送一个数据包可能涉及十多个甚至更多的路由器，以及其他的网络硬件。路由器和路由经常是设置为动态更新的，因此网络能够自动响应网络和路由器的停机，以及平衡负载。在意味着在任意时点，不可能确认一个数据包的实际路径。由于多个可能的路径，数据包有可能被乱序送达，这会引起 TCP 性能问题。

这个网络中的神秘元素时常因糟糕的性能备受指责：可能是大量的网络通信— —源自其他不相关的主机— —使源与目标网络间的一个路由器饱和。网络管理员团队因此经常需要免除他们基础设施的责任。他们用高级的实时监控工具检查所有的路由器及其他相关的网络组件。

路由器和交换机都包含微处理器，它们本身在高负载情况下会成为性能瓶颈。作为一个极端例子，因为有限的 CPU 处理能力，一个早期10GbE 以太网交换机只能在所有端口上驱动 11Gb/s。

其他

我们的环境可能会包括其他物理网络设备，例如集线器、网桥、中继器和调制解调器。其中任何一个都可能成为性能瓶颈的源头并且丢包。

软件

网络通信软件包括网络栈、TCP和设备驱动程序。

网络栈

涉及的组件和层依操作系统的类型、版本、协议以及使用的接口而不同。下图描绘了一个通用的模型，展示其软件组件。

现代内核中网络栈是多线程的，并且传入的包能被多个 CPU 处理。传入的包与 CPU 的映射可用多个方法完成：可能基于源 IP 地址哈希以平均分布负载，或者基于最近处理的 CPU 以有效利用 CPU 缓存热度以及内存本地性。

Linux

Linux系统中，TCP、IP 以及通用网络驱动软件是内核的核心组件，而设备驱动程序是附加模块。数据包以 struct sk_buff 数据类型穿过这些内核组件。

下图展示了包括新 API（NAPI）接口在内的通用网络驱动的具体信息，它能通过合并中断提供性能。

数据包的高处理率能够通过调用多个 CPU 处理包和 TCP/IP 栈来实现。

• RSS，接收端缩放：现代的 NIC 能支持多个队列并且计算包哈希以置入不同队列，而后依次按直接中断由不同的CPU 处理。这个哈希值可能基于 IP 地址以及 TCP 端口号，因此源自同一个连接的包能被同一个 CPU 处理。
  -RPS，接收数据包转向：对于不支持多个队列的 NIC 的RSS 软件实现。一个短中断服务例行程序映射传入的数据包给CPU 处理，用一个类型的哈希按数据包头的字段樱色数据包包到CPU。
• PFS，接收流转向：这类似RPS，不过偏向前一个处理套接字的CPU，以调高 CPU 缓存命中率以及内存本地性。
• 加速接收数据流转向：对于支持该功能的 NIC，这是 RFS 的硬件实现。它用流信息更新 NIC 以确定中断哪个CPU。
• XPS，传输数据包转向：对于支持多个传输队列的 NIC，这支持多个 CPU 传输队列。

当缺乏数据包的 CPU 负载均衡策略时，NIC 会中断同一个 CPU，进而达到 100%使用率并成为瓶颈、

基于例如 RFS 实现的缓存一致性等因素而映射中断到多个 CPU，能够显著提升网络性能。这也能够通过 irqbalancer 进程实现，它能分配中断请求（IRQ）给CPU。

方法

网络性能方法：

这些方法可以单独使用或者混合使用。建议是从这些方法开始，按如下次序使用：性能监测、USE方法、静态性能调优和工作负载特征归纳。

工具法

工具法是一个可用工具的遍历，检查它们提供的关键指标。它有可能忽视这些工具不可见或者能见度低的问题，并且操作比较费时。

对于网络通信来说，应用工具法可以检查如下内容：

• netstat -s：查找高流量的重新传输和乱序数据包。哪些是“高” 重新传输率依客户端而不同，面向互联网的系统因具有不稳定的远程客户会比仅拥有同数据中心客户的内部系统具有更高的重新传输率。
• netstat -i：检查接口的错误计数器。
• ifconfig：检查错误、丢弃、超限。
• 吞吐量：检查传输和接收的字节率—在Linux中 ip(8)。高吞吐量可能会因为到达协商的线速率而受到限制，它也可能导致系统中网络用户的竞争延时。
• tcpdump / snoop：尽管需要大量的 CPU 开销，短期使用可能就足以发现谁在使用网络并且定位可以消除的不必要的操作。
• dtrace / stap /perf：用来检查包括内核状态在内的应用程序与线路间选中的数据。

USE 方法

USE 方法可以用来定位瓶颈和跨所有组件的错误。对于每个网络接口，及每个方向— —传输（TX）与接收（RX）— —检查下列内容。

• 使用率：接口忙于发送或接收帧的时间。
• 饱和度：由于接口满负载，额外的队列，缓冲或者阻塞的程度。
• 错误：对于接收、效验错误、帧过短（小于数据链路报文头）或者过长、冲突（在交换网络中不大可能）；对于传输、延时碰撞（线路故障）。

可以先检查错误，因为错误通常能被快速检查到并且最容易理解。

操作系统或者监视工具通常不直接提供使用率。对于每个方向（RX、TX），它能用当前的吞吐量除以当前的协商速度。当前的网络吞吐量以 B/s 测量并且包括所有协议报文头。

对于实施了网络带宽限制（资源控制）的环境，如出现在一些云计算环境中。除去物理限制之外，网络使用率或许需要按应用的限制来测量。

网络接口的饱和度难以测量。由于应用程序能比接口传输能力更快地发送数据，一定程序的网络缓冲是正常的。因为应用程序线程阻塞于网络传输的时间会随饱和度的增加而增加，这有可能是可以测量的。同时检查是否有其他与接口饱和度紧密相关的内核统计信息，如 Linux中的 overruns。

TCP 层的重传输统计信息通常是现成的并且可以作为饱和度的指标。然而，它们是跨服务器与客户端衡量的，并且可能出现于任何一跳。

USE方法可用于网络控制器，以及它们与处理器之间的传输通道。由于这些组件的观察工具比较少见，基于网络接口统计信息和网络拓补推测指标可能更容易。例如，假设控制器 A 提供端口 A0 和 A1，该网络控制器的吞吐量能用 A0 和 A1 接口的吞吐量总和来计算。由于最大吞吐量已知，网络控制器的使用率就能够计算了。

工作负载特征归纳

做容量规划、基准测试和负载模拟时，分析应用负载的特征是一项重要的演练。经由定位可削减的不必要操作，它可能促成一些最丰厚的性能提升。

以下用于分析网络工作负载特征的基础属性，能共同提供网络性能需求的近似值：

• 网络接口吞吐量：RX 和 TX，B/s。
• 网络接口 IOPS：RX 和 TX，帧每秒。
• TCP 连接率：主动和被动，每秒连接数。

以下工作负载示列描述如何表达这些属性：

网络吞吐量随用户而变化并且写（TX）多于读（RX）。峰值写速率是 200MB/s 和210 000包/s，而峰值读速率是 10MB/s 和70 000 包/s。入站（被动）TCP 连接率能达到3 000连接/s。

除了描述这些系统级的特征，也可以用每个接口描述它们。如果观察到吞吐量达到线速率，就能够发现接口的瓶颈。如果应用了网络带宽限制（资源控制），可能达到线速率前就节流网络吞吐量。

高级工作负载特征 / 核对清单

分析工作负载特征归纳可以涵盖更多具体信息。这里列举一些供参考的问题。需要缜密的研究 CPU 问题时，这可作为核对清单：

• 平均数据包的大小是多少？RX、TX？
• 协议是什么？TCP 还是 UDP？
• 活跃的 TCP/UDP 端口是多少？B/s、每秒连接数？
• 哪个进程在主动地使用网络？

延时分析

研究不同的时间（延时）有助于理解和表述网络性能。这包括网络延时— — 一个有些模棱两可的术语，通常指的是连接初始化时间。下表总结了多种网络延时。

延时可能显示如下：

• 单位时间间隔平均：以客户端/服务器计量最佳，以便隔离中间网络的差别。
• 完整分布：直方图或者热度图。
• 每操作延时：列出每个事件包括源与目的 IP 地址的具体信息。

一个场景的问题源是出现 TCP 重传输所导致的延时异常值。使用包括最小延时阀值过滤在内的完整分布或者每操作延时跟踪能发现它们。

性能检测

性能检测能发现当前的问题以及随着时间的推移的行为模式。它能捕捉最终用户数量变化，包括分布式系统监测在内的定时活动，以及包括网络备份在内的应用程序活动。

关键的网络指标如下：

• 吞吐量：网络接口与传输的每秒字节数，最好能够包括每个接口。
• 连接数：TCP 每秒连接数，它是另一个网络负载的指标。
• 错误：包括丢包计数器。
• TCP 重传输：计量它是有帮组的，能与网络问题相关联。
• TCP 乱序数据包：也会导致性能问题。

对于使用了网络带宽限制（资源控制）的环境，例如云计算环境，应用的限额统计数据也要收集。

数据包嗅探

数据包嗅探（也称为数据包捕捉）从网络捕捉数据包，因而能以检查每一个数据包的方式检查协议报文头和数据。就 CPU 和存储系统开销而言，它的代价高昂，对于观测性分析这可能是最后收到。由于需要每秒处理数百万的数据包并且对任何系统开销都敏感，网络内核代码路径通常是对周期优化。为试图减少这种系统开销，内核可能会利用环形缓冲区通过共享内存映射向用户级跟踪工具传递包数据。

数据包捕捉日志可以创建于服务器端，然后用其他工具分析。一些工具仅仅输出内容，其他的能做高级的包数据分析。尽管通读数据包捕捉日志非常耗时，但它可能非常有启发性— —显示当前网络中正在发生什么，以及数据包对间的延时。这使得应用工作负载特征归纳和延时分析方法成为可能。

每个数据包捕捉的日志包括如下信息：

• 时间戳
• 整个数据包，包括：所有协议头（例如，以太网、IP、TCP），部分或全部负载数据
• 元数据：数据包数量、丢包数量

TCP 分析

能够调查的具体的 TCP 行为如下：

• TCP 发送 / 接收缓冲的使用。
• TCP 积压队列的使用。
• 积压队列满导致的内核丢包。
• 阻塞窗口大小，包括零长度通知。
• TCP TIME-WAIT 间隔接收到的 SYN。

当一个服务器频繁地使用相同的源和目的 IP 地址连接另一个服务器的同一个目标端口时，最后一个行为可能成为一个可扩展性的问题。每个连接唯一的区别要素是客户端的源端口— —一个短暂的端口— — 对于TCP 它是一个 16位的值并且可能进一步收到操作系统参数的现在（最小和最大值）。综合可能是 60s 的TCP TIME-WAIT 间隔，高速率的连接（60s内多余65 5636）会与新连接碰撞。这种情况下，发送一个 SYN 包，而那个短暂的端口仍然与前一个处于TIME-WAIT 的TCP 会话关联。如果被误认为是旧连接的一部分（碰撞），这个新的 SYN包可能被拒收。为了避免这种问题，Linux内核试图快速地重利用或者回收连接（这通常管用）。

挖掘分析

通过挖掘每个处理数据包的层次直到网络接口驱动，能按需研究内核网络栈的内部运行。内部运行往往非常复杂，所以这是一个非常消耗时间的操作。

执行这个操作的理由如下：

• 检查网络可调参数是否需要调整（而不通过实验来修改）
• 确认内核网络性能特性是否生效，例如包括 CPU 扇出和中断合并。
• 解释内核丢包。

这通常采用动态跟踪审查内核网络栈函数的执行。

静态性能调优

静态性能调优注重解决配置完成的环境中的问题。对于网络性能，检查静态配置中的如下方面：

• 有多少网络接口可供使用？当前使用中的有哪些？
• 网络接口的最大速度是多少？
• 当前协商的网络接口速度是多少？
• 网络接口协商为半双工还是全双工？
• 网络接口配置的 MTU 是多少？
• 网络接口是否使用了链路聚合？
• 有哪些适用于设备驱动的可调参数？IP层? TCP层？
• 有哪些可调参数已不再是默认值？
• 路由是如何配置的？默认路由是什么？
• 数据路径中网络组件的最大吞吐量是多少（是有组件，包括交换机和路由器背板）？
• 数据转发是否启用？该系统是否作为路由器使用？
• DNS 是如何设置的？它距离服务器有多远？
• 改版本的网络接口固件是否有已知的性能问题（bug）？
• 该网络设备驱动是否有已知的性能问题（bug）？内核 TCP/IP 栈呢？
• 是否存在软件施加的网络吞吐量现在（资源控制）？它们是什么？

回答这些问题可能会揭示被忽视的配置选择。

资源控制

操作系统可能按连接类型、进程或者进程组，设置控制以限制网络资源、控制可能包括如下类型：

• 网络带宽限制：由内核应用的针对不同协议或者应用程序的允许带宽（最大吞吐量）
• IP 服务品质：由网络组件（例如路由器）应用的网络流量优先排序。有多种实现方式，如 IP 报文头包括业务类型（ToS）位。其中包括优先级，这些位已在新 QoS 方案中重定义，其中包括区分服务。可能会存在其他协议层为同样目的应用的优先排序。

网络可能存在高低优先级混合的流量。低优先级可能包括传输备份以及性能监视流量。高优先级可能是生产服务器与客户机见的流量。任意一个资源控制方案都能节流低优先级流量，而为高优先级流量提供更令人满意的性能。