51学通信

06-网络性能分析实战

43分钟阅读

Wireshark数据包捕获与分析实战 第 6 篇：网络性能分析实战

摘要

本文将带你深入掌握网络性能分析的方法论和实战技巧，学会使用Wireshark定位和解决各类网络性能问题。你将学到延迟分析方法、吞吐量测试技巧、丢包诊断流程、带宽瓶颈识别策略，以及应用层性能优化的实战经验。

学习目标

阅读完本文后，你将能够：

  • 分析网络延迟：识别延迟的来源和影响，优化网络响应时间
  • 测量吞吐量：准确评估网络带宽，识别带宽瓶颈
  • 诊断丢包问题：找出丢包的根本原因，制定解决方案
  • 优化TCP性能：调整TCP参数，提升数据传输效率
  • 分析应用性能：从网络层面优化应用响应速度

51学通信提示：网络性能分析是Wireshark最有价值的应用场景之一。站长爱卫生常说：“网络通了只是第一步，网络快才是真正目标。“本文将教你如何系统性地分析和优化网络性能。

一、网络延迟分析

1.1 延迟的概念与类型

网络延迟（Latency）是指数据从源传输到目的地所需的时间。延迟是影响网络性能的关键因素，特别是对于实时应用（如语音、视频、在线游戏）。

延迟分为几种类型，理解这些类型有助于定位问题。

传播延迟（Propagation Delay）

传播延迟是信号在介质中传播所需的时间，取决于物理距离和介质特性。光在光纤中的传播速度约为200,000 km/s，因此传播延迟约为每公里5微秒。

传播延迟是物理限制，无法优化。如果服务器在北京，客户端在广州，物理距离约2000公里，传播延迟约为10毫秒。这是物理定律决定的。

传输延迟（Transmission Delay）

传输延迟是将数据推送到链路上所需的时间，取决于数据大小和链路带宽。传输延迟 = 数据大小 / 带宽。

例如，在100Mbps链路上传输1MB数据：传输延迟 = 1MB × 8bits/Byte / 100Mbps = 80毫秒。提高带宽可以减少传输延迟。

处理延迟（Processing Delay）

处理延迟是设备（路由器、交换机、服务器）处理数据包所需的时间。包括查表、路由决策、防火墙检查等。处理延迟取决于设备的性能和配置。

排队延迟（Queuing Delay）

排队延迟是数据包在设备缓冲区中等待的时间。当网络拥塞时，数据包需要在缓冲区排队等待传输。排队延迟是可变的，取决于网络拥塞程度。

flowchart TD
    A[数据包总延迟] --> B[传播延迟<br>物理距离决定]
    A --> C[传输延迟<br>带宽决定]
    A --> D[处理延迟<br>设备性能决定]
    A --> E[排队延迟<br>拥塞程度决定]

    B --> F[无法优化<br>物理限制]
    C --> G[提高带宽<br>可优化]
    D --> H[升级设备<br>优化配置]
    E --> I[减少拥塞<br>QoS策略]

    style F fill:#ffcdd2
    style G fill:#c8e6c9
    style H fill:#c8e6c9
    style I fill:#c8e6c9

图表讲解：

这张分类图展示了延迟的四个组成部分及其优化可能性。51学通信站长爱卫生认为，理解延迟的组成是定位问题的第一步。

传播延迟是物理限制，无法优化。如果客户端和服务器距离远，传播延迟就会大。这是无法改变的物理规律。

传输延迟可以通过提高带宽来优化。带宽越大，传输同样数据所需时间越短。但要注意，对于小数据包，传输延迟不是主要因素。

处理延迟可以通过升级设备或优化配置来改善。高性能的路由器和服务器处理速度更快。防火墙规则、QoS策略等配置也会影响处理延迟。

排队延迟是可变的，取决于网络拥塞程度。通过QoS策略、流量整形、增加带宽等方式，可以减少排队延迟。

在Wireshark中分析延迟时，首先需要确定是哪种类型的延迟。传播延迟通常很稳定，不会波动很大；传输延迟取决于数据大小；处理延迟相对固定；排队延迟变化最大，是性能问题的常见原因。

1.2 ICMP延迟测量

ICMP Echo Request/Reply（ping）是最简单的延迟测量方法。

使用ping测量延迟

ping www.example.com

输出会显示每个ping的往返时间（RTT），例如：

Reply from 93.184.216.34: bytes=32 time=15ms TTL=118
Reply from 93.184.216.34: bytes=32 time=14ms TTL=118
Reply from 93.184.216.34: bytes=32 time=16ms TTL=118
Reply from 93.184.216.34: bytes=32 time=15ms TTL=118

RTT包括传播延迟、传输延迟、处理延迟和排队延迟的双倍（去程+回程）。正常情况下，RTT应该相对稳定。

在Wireshark中分析ping

在Wireshark中捕获ping流量，可以查看每个ICMP包的详细信息：

  1. 请求的发送时间（frame.time）
  2. 响应的接收时间
  3. 计算RTT = 响应时间 - 请求时间

可以使用过滤器icmp只显示ICMP包，然后查看时间戳列。

异常延迟分析

如果RTT波动很大（如10ms、50ms、15ms、100ms），说明有排队延迟。可能是网络拥塞或设备处理能力不足。

如果RTT持续很高（如>200ms），可能是：

  • 物理距离远
  • 路径上有卫星链路
  • 路径设备处理慢
  • 网络拥塞严重

如果ping超时（没有响应），可能是：

  • 目的主机离线
  • 防火墙拦截ICMP
  • 路径不可达
  • 网络严重拥塞

1.3 TCP往返时间分析

TCP连接建立后的数据传输过程提供了更精确的延迟测量。

TCP RTT计算

TCP使用累积确认机制，通过ACK的到达时间可以计算RTT。Wireshark自动计算并显示TCP RTT。

查看TCP RTT的方法：

  1. 选择任意TCP数据包
  2. 在数据包详情窗格中展开Transmission Control Protocol
  3. 查看[SEQ/ACK analysis]部分
  4. 显示RTT值和ACK数量

RTT样本

Wireshark为每个TCP连接维护RTT样本，包括：

  • 最小RTT
  • 最大RTT
  • 平均RTT
  • RTT方差

这些统计可以帮助评估网络质量：

  • 如果最小RTT和最大RTT相差很大，说明延迟不稳定
  • 如果平均RTT持续增长，可能网络拥塞加剧
  • 如果RTT方差很大，说明网络质量不稳定

使用tcp.analysis.ack_rtt

可以添加显示列来查看每个TCP段的RTT：

  1. 在数据包列表列标题上右键
  2. 选择”Column Preferences”
  3. 添加新列，类型选择”Custom”
  4. 字段输入tcp.analysis.ack_rtt
  5. 保存

然后按RTT排序，可以快速找到延迟最大的包。

51学通信经验：正常的局域网RTT应该<1ms，同城的RTT应该<10ms，跨国的RTT可能100-200ms。如果超出这个范围，需要检查网络路径。

1.4 应用层响应时间分析

应用层响应时间是用户最关心的指标，它包括网络延迟和服务器处理时间。

HTTP响应时间

Wireshark自动计算HTTP请求的响应时间。查看方法：

  1. 选择任意HTTP响应包
  2. 在数据包详情窗格中展开Hypertext Transfer Protocol
  3. 查看Time字段

这个时间是从请求到响应的时间间隔，包括：

  • 网络延迟（请求从客户端到服务器）
  • 服务器处理时间
  • 网络延迟（响应从服务器到客户端）

如果响应时间很长，需要分析是网络问题还是服务器问题。查看TCP RTT可以了解网络延迟，如果RTT很小但响应时间很长，说明服务器处理慢。

分析慢速HTTP请求

使用过滤器找到慢速HTTP请求：

http.time > 1.0

这会显示响应时间超过1秒的HTTP请求。查看这些请求的详细信息：

  • 请求的URL
  • 响应的状态码
  • 响应的内容长度
  • 是否有重传

如果慢速请求都指向特定的URL或服务器，可能是该服务器有问题。如果慢速请求都有重传，可能是网络质量问题。

二、吞吐量分析

2.1 吞吐量概念

吞吐量（Throughput）是指单位时间内成功传输的数据量，通常以bps（bits per second）或Bps（bytes per second）为单位。

吞吐量与带宽（Bandwidth）不同。带宽是链路的理论最大传输速率，吞吐量是实际达到的传输速率。由于各种开销和损耗，吞吐量通常小于带宽。

影响吞吐量的因素

  1. 带宽限制：链路的物理带宽是吞吐量的上限
  2. 网络延迟：延迟高会降低TCP的传输效率
  3. 丢包率：丢包会导致TCP重传，降低有效吞吐量
  4. 窗口大小：TCP窗口限制在途数据量
  5. 协议开销：协议头部、确认、重传等开销
  6. 应用限制：服务器或客户端的处理能力

2.2 测量吞吐量

使用I/O图表测量

Wireshark的I/O图表可以显示吞吐量随时间的变化：

  1. Statistics → I/O Graph
  2. 显示单位选择”Bytes/Tick”
  3. 时间间隔选择合适的值（如1秒）
  4. 应用过滤器（如ip.addr == 192.168.1.100）

图表会显示每秒传输的字节数，即吞吐量。

查看TCP吞吐量

对于特定的TCP连接，可以查看其吞吐量：

  1. Statistics → Conversations → TCP
  2. 找到目标连接
  3. 查看该连接的统计信息

TCP会话统计显示：

  • 两个方向的数据包数和字节数
  • 连接持续时间
  • 可以计算：吞吐量 = 字节数 / 持续时间

51学通信建议：测量吞吐量时，注意测量时间窗口。短时间测量可能不准确，建议测量至少30秒到1分钟。另外，要注意区分单向吞吐量和双向吞吐量总和。

2.3 吞吐量问题分析

低吞吐量的原因

如果测量的吞吐量远低于带宽，可能的原因有：

  1. 网络拥塞：其他流量占用带宽

    • 查看协议层次统计，确认是否有其他高带宽流量
    • 查看会话统计，找出占用带宽最多的连接

  2. 高延迟：延迟高会降低TCP效率

    • 查看TCP RTT，确认延迟大小
    • 如果RTT很大，考虑优化路由或使用CDN

  3. 丢包：丢包导致重传，降低有效吞吐量

    • 查看TCP重传统计
    • 如果重传比例>1%，网络质量有问题

  4. 窗口限制：TCP窗口太小，限制了在途数据量

    • 查看TCP窗口大小
    • 如果窗口很小，考虑启用窗口缩放

  5. 应用限制：服务器或客户端处理能力不足

    • 查看服务器负载
    • 查看是否有应用层瓶颈

分析示例

假设测量到某连接的吞吐量只有10Mbps，而带宽是100Mbps。分析步骤：

  1. 查看TCP RTT：如果RTT是200ms，窗口是64KB，理论最大吞吐量 = 窗口 / RTT = 64KB / 0.2s = 320KBps = 2.56Mbps。这是窗口限制导致的。

  2. 解决方案：启用TCP窗口缩放，增大窗口。如果窗口增加到256KB，理论吞吐量可达10.24Mbps。

  3. 如果窗口已经很大，仍然只有10Mbps，检查是否有丢包。查看重传统计，如果重传很多，需要解决网络质量问题。

2.4 优化吞吐量

启用窗口缩放

TCP窗口最大只有65535字节（64KB），在高延迟网络中会限制吞吐量。窗口缩放选项允许更大的窗口。

检查是否启用窗口缩放：

  1. 查看TCP三次握手包
  2. 在TCP选项中查找”Window scale”
  3. 如果有，说明启用了窗口缩放

如果未启用，可以在操作系统配置中启用。

调整TCP参数

操作系统有各种TCP参数可以调整，以优化性能：

  • 初始拥塞窗口
  • 慢启动阈值
  • 拥塞避免算法
  • 快速重传和恢复

这些参数的调整需要深入了解TCP协议，不当调整可能导致性能下降。

使用并行连接

应用层可以使用多个并行TCP连接，提高总吞吐量。浏览器加载网页时会并行打开多个连接，同时下载多个资源。

使用UDP或QUIC

对于实时应用，可以考虑使用UDP或QUIC协议。QUIC是UDP上的可靠传输协议，比TCP有更好的性能。

三、丢包诊断

3.1 丢包的影响

丢包是网络性能的头号杀手。丢包会触发TCP重传，不仅浪费带宽，还会降低有效吞吐量，增加延迟。

丢包对TCP的影响

当发送方检测到丢包时，会重传丢失的数据包。重传有两种方式：

  • 超时重传：等待RTO（重传超时）后重传
  • 快速重传：收到3个重复ACK后立即重传

无论是哪种方式，都会降低传输效率：

  • 超时重传会空闲等待，浪费带宽
  • 快速重传虽然更快，但仍然浪费带宽重传数据

丢包对应用的影响

丢包对不同应用的影响不同：

  • 文件传输：会降低吞吐量，但不会导致错误（TCP保证可靠性）
  • 实时应用（语音、视频）：会导致卡顿、花屏、丢音（UDP不重传）
  • 在线游戏：会导致操作延迟、跳帧

3.2 识别丢包

查看TCP重传

Wireshark会将重传包标记为”[TCP Retransmission]“。使用过滤器查看所有重传：

tcp.analysis.retransmission

查看重传统计：

  1. Statistics → Conversations → TCP
  2. 找到目标连接
  3. 查看”Retransmission”列

查看TCP乱序

丢包会导致乱序，因为后续的包先到达。Wireshark会标记为”[TCP Out-of-Order]“。使用过滤器查看：

tcp.analysis.out_of_order

查看ICMP错误

某些网络设备会发送ICMP错误消息，报告丢包。例如：

  • “Destination Unreachable”：目的不可达
  • “Time Exceeded”：TTL超时
  • “Source Quench”：源抑制（已废弃）

使用过滤器查看ICMP错误：

icmp.type == 3

3.3 定位丢包位置

定位丢包发生在网络路径的哪个位置，是解决问题的关键。

使用traceroute

traceroute可以显示到目的主机的网络路径，每跳的延迟和丢包率。

traceroute www.example.com

输出会显示每一跳的路由器地址和延迟。如果某一跳的延迟突然增大，或出现* * *（超时），说明该跳有问题。

使用路径ping

Windows的pathping命令结合了ping和traceroute的功能，可以显示每跳的丢包率。

pathping www.example.com

pathping会向每一跳发送多个ping，计算丢包率。

在Wireshark中分析TTL

查看IP数据包的TTL值，可以了解数据包经过了多少跳。初始TTL通常是64或128，每经过一个路由器减1。

如果TTL很小（如<10），说明经过了多跳，可能路径不合理。如果TTL变为1或0，数据包会被丢弃。

51学通信经验：大多数丢包发生在”最后一公里”（接入网络）。检查本地网络、Wi-Fi信号、网关设备，往往能找到问题所在。局域网内部应该是无丢包的，如果有丢包，通常是设备故障或配置错误。

3.4 解决丢包问题

检查物理链路

物理层问题是最常见的丢包原因：

  • 网线损坏或质量差
  • 光纤断裂或接头脏污
  • 无线信号弱或干扰
  • 接口速度不匹配（如100M连到1G口）

使用ping测试本地链路：

ping -n 1000 192.168.1.1

如果有丢包，检查物理链路：

  1. 更换网线
  2. 清洁光纤接头
  3. 调整无线天线位置
  4. 检查接口速度设置

检查网络设备

网络设备（交换机、路由器）的问题也会导致丢包：

  • 设备性能不足，无法处理流量
  • 缓冲区溢出
  • 配置错误（如MTU不匹配）
  • 硬件故障

检查设备的CPU使用率、端口错误统计。如果有大量错误（CRC错误、 Giants、Runts），可能是硬件问题。

优化网络配置

某些网络配置可以减少丢包：

  • 启用流量控制（Flow Control）
  • 调整缓冲区大小
  • 配置QoS，优先保证重要流量
  • 使用链路聚合（LACP），增加带宽

升级带宽

如果丢包是由于带宽不足导致的拥塞，解决方案是升级带宽。但要注意，升级带宽可能只是暂时缓解问题，如果流量持续增长，问题会再次出现。

更好的方案是：

  1. 分析流量特征，找出高带宽应用
  2. 优化应用，减少带宽需求
  3. 使用缓存，减少重复传输
  4. 使用CDN，就近访问内容
flowchart TD
    A[发现丢包] --> B{检查物理链路}
    B --> C[网线/光纤正常?]
    C -->|否| C1[更换线缆/清洁接头]
    C -->|是| D{检查设备状态}

    D --> E[CPU/内存正常?]
    E -->|否| E1[升级设备/优化配置]
    E -->|是| F{检查带宽使用}

    F --> G[带宽充足?]
    G -->|否| G1[升级带宽/实施QoS]
    G -->|是| H{检查MTU配置}

    H --> I[MTU匹配?]
    I -->|否| I1[调整MTU]
    I -->|是| J{检查应用}

    J --> K[应用正常?]
    K -->|否| K1[优化应用]
    K -->|是| L[持续监控]

    C1 --> L
    E1 --> L
    G1 --> L
    I1 --> L
    K1 --> L

图表讲解：

这张诊断流程图展示了系统化解决丢包问题的方法。51学通信站长爱卫生建议，按照从底层到高层的顺序检查，不要一开始就怀疑是复杂的问题。

首先检查物理链路，这是最常见的问题来源。网线损坏、光纤接头脏污、无线信号弱，这些都会导致丢包。物理层问题很容易检查，也容易解决。

如果物理层正常，检查网络设备。设备的CPU使用率、内存使用率、端口错误统计，这些都能指示设备是否有问题。如果设备过载，需要升级设备或优化流量分布。

如果设备正常，检查带宽使用。如果带宽使用接近上限，拥塞会导致丢包。解决方案包括升级带宽、实施QoS策略优化流量分配、使用缓存减少重复传输。

如果带宽充足，检查MTU配置。如果路径上某个链路的MTU较小，而数据包较大，会被分片或丢弃。调整MTU或启用MSS clamping可以解决。

如果以上都正常，可能是应用层的问题。某些应用的实现有问题，会导致丢包。需要分析应用的行为，优化实现。

最后，无论问题解决与否，都要持续监控网络，确保问题不再出现，或及时发现新的问题。

四、应用性能优化

4.1 HTTP性能优化

HTTP是应用最广泛的协议，优化HTTP性能能显著提升用户体验。

减少HTTP请求

每个HTTP请求都有开销（连接建立、请求头传输、服务器处理）。减少请求数量可以减少这些开销。

方法：

  1. 合并CSS和JavaScript文件
  2. 使用CSS Sprites合并图片
  3. 使用内联资源（小图片、CSS、JavaScript）
  4. 使用HTTP/2的多路复用

启用压缩

文本资源（HTML、CSS、JavaScript）压缩后可以减少70-80%的传输量。

在Wireshark中检查HTTP响应：

  1. 查看响应头部的Content-Encoding字段
  2. 如果有”gzip”或”deflate”，说明启用了压缩
  3. 查看压缩前后的Content-Length，评估压缩效果

使用缓存

缓存可以避免重复传输相同的内容，减少网络流量和服务器负载。

HTTP缓存机制：

  • Expires：过期时间
  • Cache-Control：缓存控制
  • ETag：内容验证
  • Last-Modified：最后修改时间

在Wireshark中检查缓存使用情况：

  1. 查看HTTP请求头部的If-None-Match或If-Modified-Since
  2. 如果有，说明客户端使用了缓存
  3. 查看响应的状态码，如果是304 Not Modified，说明使用了缓存

优化连接

HTTP连接建立有开销（三次握手、TLS协商）。重用连接可以减少这些开销。

HTTP/1.1支持持久连接（Connection: keep-alive），可以在一个连接上发送多个请求。

HTTP/2支持多路复用，可以在一个连接上并发发送多个请求，进一步减少连接开销。

在Wireshark中检查连接使用：

  1. 统计HTTP请求数和TCP连接数
  2. 如果请求数远大于连接数，说明连接被重用
  3. 查看连接的持续时间，长连接更高效

4.2 DNS性能优化

DNS解析是每个网络连接的第一步，优化DNS可以加速连接建立。

减少DNS查询

每个DNS查询有延迟（通常几十毫秒），减少查询数量可以加速页面加载。

方法：

  1. 减少外部资源（减少跨域请求）
  2. 使用预解析：<link rel="dns-prefetch" href="//example.com">
  3. 使用预连接：<link rel="preconnect" href="//example.com">

使用DNS缓存

DNS缓存可以避免重复查询。浏览器、操作系统都有DNS缓存。

在Wireshark中检查DNS缓存使用：

  1. 查看DNS查询
  2. 如果同一个域名被重复查询，说明缓存没有生效
  3. 检查DNS响应的TTL值，TTL太短会导致频繁重新查询

优化DNS服务器

选择响应快的DNS服务器可以减少DNS延迟。

公共DNS服务器：

  • Google DNS：8.8.8.8, 8.8.4.4
  • Cloudflare DNS：1.1.1.1
  • 阿里DNS：223.5.5.5, 223.6.6.6

在Wireshark中测量DNS响应时间：

  1. 查看DNS查询和响应的时间戳
  2. 计算响应时间 = 响应时间 - 查询时间
  3. 如果响应时间>100ms，考虑更换DNS服务器

4.3 TCP性能优化

TCP是大多数应用的基础协议，优化TCP可以提升整体网络性能。

启用TCP Fast Open

TCP Fast Open（TFO）允许在三次握手期间传输数据，减少延迟。

在Wireshark中检查TFO：

  1. 查看TCP选项
  2. 如果有”Fast Open”选项，说明启用了TFO

调整初始拥塞窗口

初始拥塞窗口（IW）决定了TCP慢启动的起始速率。较大的IW可以加快慢启动过程。

Linux系统可以调整IW：

echo "net.ipv4.tcp_slow_start_after_idle=0" >> /etc/sysctl.conf
echo "net.ipv4.tcp_initial_cwnd=10" >> /etc/sysctl.conf

启用选择性确认

选择性确认（SACK）允许TCP更精确地报告丢失的数据，提高重传效率。

在Wireshark中检查SACK：

  1. 查看TCP选项
  2. 如果有”SACK Permitted”选项，说明启用了SACK

51学通信站长爱卫生的提醒：TCP优化需要深入了解协议，不当调整可能导致性能下降或网络不稳定。建议在测试环境中验证优化效果，再应用到生产环境。

五、核心概念总结

概念名称定义测量方法优化策略
延迟数据传输所需时间ping、TCP RTT、HTTP响应时间优化路由、升级带宽、缓存
吞吐量单位时间传输的数据量I/O图表、TCP会话统计增加带宽、减少拥塞、并行连接
丢包率丢失包的比例重传统计、ICMP错误修复物理链路、升级设备
带宽链路的理论最大速率链路规格升级链路
RTT往返时间TCP分析优化路由、CDN
窗口大小TCP在途数据量TCP头部启用窗口缩放
拥塞窗口TCP发送速率限制TCP选项调整拥塞控制算法
缓存存储副本避免重复传输HTTP头部配置缓存策略
压缩减少数据传输量HTTP响应头启用gzip/deflate
持久连接重用TCP连接HTTP头部使用keep-alive、HTTP/2

常见问题解答

Q1：如何区分网络延迟和应用延迟？

答：区分网络延迟和应用延迟是性能分析的关键一步。方法是比较TCP RTT和HTTP响应时间。

TCP RTT是网络层的往返时间，不包括应用处理时间。HTTP响应时间是从请求到响应的总时间，包括网络延迟和应用处理时间。

如果HTTP响应时间远大于TCP RTT，说明应用处理时间长，问题在服务器或客户端应用。如果HTTP响应时间与TCP RTT接近，说明应用处理时间短，问题在网络。

具体分析方法：在Wireshark中选择HTTP请求包，查看其对应的TCP连接。计算TCP RTT（在TCP分析部分），然后查看HTTP响应时间。如果响应时间 = RTT × 2 + 少量处理时间，说明主要是网络延迟；如果响应时间 >> RTT × 2，说明有大量应用处理时间。

51学通信建议：还可以查看服务器的时间戳。如果服务器在收到请求后很快返回（响应的发送时间接近请求的到达时间），但客户端很久才收到，说明是网络延迟。如果服务器很久才返回，说明是应用处理时间。

Q2：为什么实际吞吐量远低于理论带宽？

答：实际吞吐量低于理论带宽是正常现象，原因有很多。首先要理解带宽是理论最大值，实际有很多开销和限制。

协议开销是主要原因之一。以太网帧有前导码、帧头、FCS，IP和TCP有头部，这些开销占总带宽的5-10%。对于小包，开销比例更高。

ACK流量也占用带宽。TCP是双向通信，ACK虽然没有应用数据，但仍然消耗带宽。ACK流量通常占总带宽的5-10%。

拥塞控制会限制发送速率。TCP的拥塞控制算法会根据网络状况调整发送速率，避免拥塞。如果网络有丢包或高延迟，TCP会降低发送速率。

应用限制也是因素。如果服务器或客户端处理能力不足，无法快速发送或接收数据，也会限制吞吐量。磁盘I/O、CPU性能、应用逻辑都可能成为瓶颈。

如果吞吐量远低于带宽（如<50%），需要检查是否有其他高带宽流量占用网络。使用协议层次统计查看流量分布，使用会话统计找出占用带宽最多的连接。

如果单条连接的吞吐量低，可能是窗口限制。高延迟网络中，如果TCP窗口较小，会限制在途数据量，从而限制吞吐量。查看TCP窗口大小，如果窗口小，考虑启用窗口缩放。

Q3：如何分析间歇性的网络性能问题？

答：间歇性问题是网络诊断中最难的问题，因为问题发生时可能不在现场。51学通信建议采用长期监控的方法。

使用环形缓冲区配置长期捕获。例如，配置为每100MB创建一个新文件，保留最近的10个文件。这样总是保留最近的流量，当问题发生时，可以保存当前的捕获文件。

使用I/O图表查看流量模式。间歇性问题可能有时间模式，如每天下午3点变慢。I/O图表能显示吞吐量随时间的变化，帮助识别模式。

使用统计工具建立基准。在网络正常时测量各种指标：吞吐量、延迟、丢包率等，建立性能基准。当问题发生时，对比基准值，更容易识别异常。

结合监控系统。Wireshark捕获网络流量，但服务器监控（CPU、内存、磁盘）和应用监控（响应时间、错误率）也重要。结合多种监控数据，更容易定位问题。

记录问题发生的详细信息。当用户报告问题时，记录：

  • 问题发生的具体时间
  • 问题的症状（慢、断线、错误）
  • 影响的范围（单个用户、所有用户、特定应用）
  • 之前是否有变化（配置更改、软件更新）

这些信息有助于缩小问题范围，提高诊断效率。

Q4：如何优化视频会议的网络性能？

答：视频会议对网络质量敏感，需要低延迟、低丢包、足够带宽。优化需要从多个方面入手。

首先保证足够的带宽。视频会议的带宽需求取决于分辨率和帧率：

  • 720p@30fps：需要1-2Mbps
  • 1080p@30fps：需要2-4Mbps
  • 1080p@60fps：需要4-8Mbps

使用I/O图表测量实际带宽使用，确保带宽充足。

优先保证视频会议流量。配置QoS策略，给予视频会议流量高优先级。大多数视频会议应用使用特定的端口或协议，可以基于这些配置QoS。

优化Wi-Fi连接。如果使用Wi-Fi，确保：

  • 使用5GHz频段（干扰少、带宽大）
  • 信号强度良好（RSSI > -60dBm）
  • 使用Wi-Fi 5（802.11ac）或Wi-Fi 6（802.11ax）
  • 避免信道拥塞

使用有线连接。如果可能，使用以太网连接，避免Wi-Fi的不稳定性。

检查网络质量。在视频会议期间捕获流量，查看：

  • 丢包率（应该<1%）
  • 抖动（延迟变化，应该<30ms）
  • 延迟（单向延迟应该<150ms）

如果丢包严重，使用tcp.analysis.lost_segment过滤器查看丢失的段，定位丢包位置。

关闭其他高带宽应用。视频会议期间，避免下载大文件、流媒体等占用带宽的应用。

使用专用的视频会议设备。专业设备有更好的网络适配和错误恢复能力，能提供更好的用户体验。

51学通信站长爱卫生的经验：大多数视频会议问题其实是Wi-Fi问题。有线连接往往能解决大部分问题。如果必须使用Wi-Fi，确保路由器位置合理，避免物理障碍，使用较少拥挤的信道。

Q5：Wireshark显示的TCP Window Full是什么意思，如何解决？

答：TCP Window Full表示接收方的TCP接收窗口已满，发送方无法继续发送数据。这是流量控制机制，防止发送方发送过多数据导致接收方缓冲区溢出。

当接收方的应用程序处理数据慢于数据到达速度时，接收缓冲区会逐渐填满。当缓冲区满了，TCP会通告窗口大小为0，发送方必须停止发送，直到窗口重新打开。

在Wireshark中，这类包会被标记为”[TCP Window Full]“，同时窗口大小（tcp.window_size_value）会是0或很小。

解决方法取决于根本原因：

如果接收方应用程序处理慢，需要优化应用程序性能。查看服务器的CPU、内存、磁盘I/O使用率，找出瓶颈。如果是数据库查询慢，优化数据库；如果是计算密集，增加CPU或优化算法。

如果接收方的TCP缓冲区太小，可以增大缓冲区。Linux系统可以通过调整以下参数增大缓冲区：

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

第一个值是最小缓冲区，第二个值是默认值，第三个值是最大值。

如果网络延迟高，小窗口会限制吞吐量。启用TCP窗口缩放选项，允许更大的窗口。在Wireshark中查看TCP选项，确认有”Window scale”选项。

如果发送方发送太快，可以实施流量整形。在发送方的路由器或网关上配置流量整形，限制发送速率，避免 overwhelms 接收方。

51学通信建议：首先确定是哪个方向的问题。如果A→B方向Window Full，说明B的接收窗口满了，问题在B。如果双向都有Window Full，可能是双方的处理能力都不足。根据问题位置采取相应的优化措施。

总结

本文全面讲解了网络性能分析的方法论和实战技巧，从延迟分析到吞吐量测试，从丢包诊断到应用优化，涵盖了网络性能问题的各个方面。

网络性能分析需要系统化的方法。首先理解性能指标的含义和测量方法，然后使用Wireshark的各种工具收集数据，最后分析数据定位问题根源。延迟、吞吐量、丢包是三个核心指标，大多数性能问题都可以通过分析这三个指标来诊断。

延迟分析需要区分不同类型的延迟：传播延迟是物理限制，传输延迟取决于带宽，处理延迟取决于设备性能，排队延迟取决于拥塞程度。理解延迟的组成，才能找到正确的优化方向。

吞吐量分析需要理解带宽与吞吐量的区别。带宽是理论最大值，吞吐量是实际达到的速率。协议开销、拥塞控制、窗口限制都会降低吞吐量。通过测量和分析，可以找出限制吞吐量的瓶颈。

丢包诊断需要系统化的排查流程。从物理层开始，逐层向上检查。大多数丢包发生在物理层或接入网络，检查网线、Wi-Fi、设备接口往往能找到问题。

应用性能优化涉及多个层面。HTTP优化包括减少请求、启用压缩、使用缓存；DNS优化包括减少查询、使用缓存、选择快速服务器；TCP优化包括调整窗口、启用高级功能。

51学通信认为，网络性能优化是一个持续的过程。网络环境在变化，应用在更新，流量模式在演进。需要持续监控网络性能，及时发现问题，不断优化调整。

下篇预告

下一篇我们将深入探讨故障排查与安全分析，带你了解网络故障的系统性排查方法、常见安全威胁的检测技术、以及使用Wireshark进行安全分析的实战技巧。你将学会快速定位网络故障，检测和防范安全威胁。

本文由”51学通信”（公众号：51学通信，站长：爱卫生）原创分享。如需深入交流或获取更多通信技术资料，欢迎添加微信：gprshome201101。

关系图谱