2. 延迟基础概念
今天我们来聊聊延迟——网络里最基础、也最容易被忽视的概念。说白了，延迟就是数据从 A 点飞到 B 点所花的时间。我经常跟刚入行的同事说：别把带宽和延迟搞混，带宽是管道有多粗，延迟是水从这头到那头要多久。
举个例子，你 ping 一个服务器，返回的 RTT（往返时间）是 30ms。这个 30ms 就是双向延迟。但很多场景下，我们真正关心的是单向延迟——比如语音通话，你这边说一句话，对方听到的时间差。
2.1 单向延迟 vs 双向延迟
单向延迟：数据从发送端到接收端的单程时间。双向延迟（RTT）：数据去一趟再回来的总时间。看起来很简单对吧？但实际工程里，单向延迟很难直接测，因为你需要两边的时钟同步。
我做过一个跨国专线的项目，客户抱怨视频会议卡顿。拉出 ping 的 RTT 只有 80ms，按理说挺好。但单向延迟测量发现，从上海到洛杉矶是 75ms，回来却只有 5ms。为什么？因为去程路由多绕了一个节点，排队也严重。只看 RTT 的话，80ms 很平均，但单向不对称导致了视频卡顿。
| 类型 | 定义 | 测量方式 | 典型应用场景 |
|---|---|---|---|
| 单向延迟 | 源到目的的单程时间 | 需要时钟同步（PTP/NTP） | 实时语音、在线游戏、工业控制 |
| 双向延迟（RTT） | 发送到接收再返回的时间 | 直接 ping 即可 | 简单连通性检查、TCP 超时计算 |
2.2 延迟的四驾马车
一个数据包从网卡发出到对端收完，中间经过的时间可以拆成四部分。你想想看，每个环节都可能成为瓶颈。我按典型顺序来拆：
- 处理延迟（Processing Delay）——路由器、交换机检查包头、查路由表、做 ACL 过滤的时间。一般是微秒级，但如果你用了深度包检测（DPI），可能飙升到毫秒级。
- 排队延迟（Queuing Delay）——数据包在出口队列里等的时长。这是最不稳定的部分，流量一拥塞它就变大。我记得有个客户，核心交换机突然出现周期性抖动，排查下来是因为一个端口的出队列策略被改成了 FIFO，背景流量一冲，VoIP 包被堵在尾部。
- 传输延迟（Transmission Delay）——把数据比特推到链路上去的时间。公式很简单：帧长 / 带宽。10GE 发一个 1500 字节的包，传输延迟约 1.2μs；要是 1.5M 的旧链路，同样的包要 8ms。差距就在这里。
- 传播延迟（Propagation Delay）——信号在介质上跑的时间。取决于物理距离和介质中的光速。光纤里大约是 5μs/km。跨洋海底光缆 10000km，单程传播延迟就是 50ms。这玩意你换再大的带宽也减不了，除非挖隧道。
2.3 从端到端看延迟叠加
一个包从源主机到目的主机，通常要经过多个网络节点。在每个节点上，这四个延迟都会出现。最终端到端延迟是沿途所有节点各部分延迟之和。
我画了一张图，把整个路径的延迟组成可视化出来。这样才能一目了然地看出哪个环节是瓶颈。
从图里能看出，每个网络节点都会贡献一段处理、排队、传输和传播延迟。加起来就是总延迟。我在做延迟预算表的时候，习惯把所有节点列出来，逐段估算：比如接入交换机处理 10μs + 排队可能 0~5ms……最后加起来，心里就有底了。
2.4 几个容易混淆的细节
- 传输延迟 vs 传播延迟——传输延迟取决于包大小和链路速率，传播延迟取决于距离。两者独立，不能混为一谈。我曾经遇到一个客户，坚信把带宽从 100M 升到 1G 就能解决跨洋延迟问题。我只好拿出公式算给他看：传播延迟 55ms 纹丝不动，升带宽只减少了传输延迟（几百微秒），对他那种大文件传输场景毫无帮助。
- 排队延迟的不可预测性——它跟瞬时流量负载强相关。做 QoS 时，我们通过配置拥塞管理算法（比如 WFQ、LLQ）来给关键业务“插队”，本质上就是牺牲其他流的排队延迟来保证关键流的低延迟。
- 处理延迟的隐藏成本——除了路由器转发，还要考虑宿主机协议栈的处理（TCP 卸载、中断合并等）。在 10G+ 网卡上，主机处理延迟甚至可能超过网络转发延迟。
嗯，基础概念先到这。记住这四驾马车的特性和区别，后面讲延迟计算模型和 Qci 过滤的时候，你会反复用到它们。