“网络慢”可能发生在 DNS、握手、路由、链路、内核协议栈、套接字队列或服务端处理。ping 正常不能证明连接建立和首字节正常，吞吐没跑满也不一定是链路问题。本章用端到端时间线和协议栈指标，把物理错误、拥塞重传、缓冲限制与应用供给不足区分开。

1. 带宽是上限，吞吐量是实际速率。链路使用率应按 RX、TX 方向分别用吞吐量除以当前协商速率。
2. 延时不是一个数字。DNS、ping/RTT、TCP 连接、首字节和会话寿命覆盖不同路径，必须选对测量点。
3. 丢包与重传是结果，不是根因；接口错误、队列溢出、中间网络拥塞、远端过载都可能触发它们。
4. 缓冲可支撑高带宽时延积，但过大队列会造成缓冲膨胀。要同时看吞吐、队列、RTT 和限制状态。
5. 先观测配置与负载，再调整 MTU、积压队列、套接字缓冲或拥塞算法；局部改动可能与整条路径不兼容。

应用数据经套接字进入 TCP/UDP、IP、数据链路和物理层；接收方向则反向上行。封装增加头部，MTU 限制帧大小，路径中的交换机、路由器、防火墙和隧道都可能改变延时与可用 MTU。TCP 还通过发送/接收窗口、拥塞窗口、重传与控速决定实际吞吐。

1. 明确慢在解析、连接、首字节、传输还是长连接期间，并记录源、目的、协议、端口与时间窗。
2. 检查路由、接口状态、协商速率、双工和 MTU；先处理错误、丢包、载波和超限计数的增长。
3. 归纳 RX/TX 吞吐、包速率、平均包大小和连接率，对照链路或云配额，而不是只看总字节。
4. 检查 TCP 重传、SYN 重传、套接字队列、RTT 与限制标志，区分网络拥塞、远端积压和本地应用读写不及时。
5. 用 ping、traceroute 或应用计时缩小路径；必要时短时、带过滤抓包，把重传和握手与时间线对齐。
6. 在负载下复测。空闲时网络正常，不代表高包速率、突发连接或缓冲积压时仍正常。

以下命令均为只读；把 eth0、目标地址和过滤条件替换为实际值。进程信息、驱动统计和抓包可能需要管理员权限。

ss -tinp

ip -s link

ip route

nstat -s

sar -n DEV 1 5

sar -n EDEV 1 5

ethtool eth0

ethtool -S eth0

tc -s qdisc show dev eth0

ping -c 5 HOST

traceroute HOST

tcpdump -ni eth0 -c 100 "host HOST"

ss、ip、nstat 来自 iproute2，字段随内核功能变化。nstat 不同版本对基线计数的默认处理可能不同，脚本采集前应查手册。tcpdump 会消耗 CPU 并可能捕获敏感负载，只应在获授权的接口上短时、限量、带过滤使用，不把抓包文件发布到课程站。

RX 或 TX 吞吐接近当前协商速率且队列与 RTT 同时上升，支持链路饱和假设。包速率很高但字节吞吐不高，可能是小包导致每包处理开销。接口 dropped、overrun 或 FIFO 持续增长，更像本机接收处理跟不上；carrier 或帧错误则需要检查链路、对端与硬件。

ss 中 app_limited 表示应用没有填满拥塞窗口，不应继续怪网络；rwnd_limited 指接收窗口限制，sndbuf_limited 指发送缓冲限制。SYN 重传而已建立连接数据正常，可能是服务端监听积压队列溢出。ping RTT 正常而 TTFB 高，问题更可能在远端调度或应用处理。

计数器必须转成时间窗内的增量。自开机以来累计一万次重传，在运行数月的主机上可能很低；一分钟新增一万次则完全不同。把重传段与发送段、丢包与总包数配对，并按源端、目的端和接口拆分。若 RTT 与队列同步上升而吞吐没有增加，要怀疑排队或缓冲膨胀；若 RTT 稳定但连接率下降，则检查应用接受连接的能力、文件描述符和积压队列。多路径环境还应保留路由变化证据，避免把路径切换误当作服务器退化。

• 用 ping 正常证明 HTTP 一定正常；ICMP 路径、优先级和服务端处理都不同。
• 只看包数推算带宽，忽略包大小可从小包到巨型帧差异巨大。
• 看到重传就认定本机网卡坏了，未检查远端和中间路径。
• 直接把 MTU 改为 9000；路径任一设备或防火墙不支持都可能丢包或分片。
• 一开始就放大所有缓冲；这可能增加内存消耗和排队延时。
• 无过滤长时间抓包，把诊断本身变成 CPU、存储与隐私问题。

1. 全双工接口使用率应如何计算？答：RX、TX 分别用当前吞吐除以协商带宽。
2. ping 与 TTFB 的关键区别是什么？答：TTFB 还包含服务端接受、调度和处理时间。
3. ss 显示 app_limited 说明什么？答：应用供数不足，拥塞窗口未被充分使用。
4. SYN 重传可能指向什么？答：远端监听积压溢出、丢包或路径问题。
5. 为什么巨型帧必须端到端核对？答：路径任一环节不支持都会导致分片、错误或静默丢包。

网络分析要把端到端延时拆成可验证的阶段，并同时观察链路、协议栈、套接字与应用。低开销计数器用来发现方向，抓包只用于验证具体假设；任何调优都要在真实负载、完整路径和明确服务目标下复测。

健康时的同路径基线，是判断延时和重传是否异常的必要参照。

• PDF 549-573 页：协议栈、包大小、延时、缓冲、连接积压、接口与 Linux 网络架构。
• PDF 573-582 页：USE、负载特征、延时、监测、抓包、TCP 与静态检查方法。
• PDF 582-609 页：ss、ip、nstat、sar、ethtool、TCP 跟踪与抓包工具。
• PDF 610-627 页：ping、traceroute、iperf、tc、系统与套接字调优、练习和参考资料。