2. 延迟的基本概念

各位同学好，我是老张。在光通信系统里摸爬滚打了十几年，今天咱们来聊聊延迟这个事儿。

说实话，我刚入行那会儿，对延迟的理解特别肤浅。总觉得不就是信号从A点到B点花的时间嘛，有啥好研究的？直到有一次，我在调试一个40Gbps的传输系统时，发现接收端的数据老是出错。查了三天三夜，最后发现是延迟计算差了那么几个纳秒。嗯，从那以后，我再也不敢小看延迟了。

2.1 延迟的定义

延迟，说白了就是一个数据包从发送端到接收端所经历的总时间。你想想看，就像你寄快递，从下单到签收，中间经历了多少环节？光通信也是一样。

我个人习惯把延迟拆成三部分来看：

• 传输延迟：信号在光纤里跑的时间
• 处理延迟：设备处理数据花的时间
• 排队延迟：数据在缓冲区等着被处理的时间

这三部分加起来，就是端到端的延迟。我在项目中遇到过不少新人，一上来就只盯着传输延迟看，结果系统设计出来根本跑不通。为什么？因为处理延迟和排队延迟往往才是大头。

2.2 传输延迟

传输延迟是最直观的。光在光纤里的速度大约是2×10⁸ m/s，比真空中的光速慢一些。为什么？因为光纤的折射率不是1，一般在1.45到1.5之间。

举个例子：

光纤长度：100公里
光速在光纤中：2×10⁸ m/s
传输延迟 = 100,000 / 200,000,000 = 0.5 ms

你看，100公里的光纤，光跑过去就要0.5毫秒。这个数字看着不大，但在高频交易系统里，0.5毫秒可能就意味着几百万的盈亏。

我记得有个项目，客户要求延迟必须控制在1微秒以内。我们算了一下，光在光纤里跑1微秒只能走200米。所以整个系统的物理距离必须控制在200米以内。这就是传输延迟的硬约束。

2.3 处理延迟

处理延迟就复杂多了。它包括了：

• 串并转换时间
• FEC编解码时间
• 时钟数据恢复时间
• 协议处理时间

我曾经调试过一个100Gbps的系统，发现处理延迟占了总延迟的80%。当时我特别纳闷，光纤才跑了10公里，怎么延迟这么大？后来一查，原来是FEC解码芯片的处理时间太长。

为什么会这样？因为现在的光通信系统，为了纠错能力，FEC算法越来越复杂。比如常用的SD-FEC，解码延迟可能达到几百纳秒。你想想看，光在光纤里跑100公里才500微秒，一个芯片就吃掉了几百纳秒，这比例可不小。

2.4 排队延迟

排队延迟是最容易被忽视的。数据包到了交换机或路由器，如果出口正忙，就得在缓冲区里等着。这个等待时间就是排队延迟。

排队延迟的计算公式是：

排队延迟 = 队列长度 / 出口速率

举个例子：

参数	数值
队列长度	100个数据包
每个数据包大小	1500字节
出口速率	10 Gbps
排队延迟	100 × 1500 × 8 / 10⁹ = 1.2 ms

1.2毫秒！这比100公里光纤的传输延迟还大。所以，在数据中心里，网络拥塞导致的排队延迟往往是最大的延迟来源。

我个人习惯在设计系统时，给排队延迟留出足够的余量。一般建议按峰值流量的1.5倍来设计缓冲区大小。这样即使遇到突发流量，排队延迟也不会失控。

2.5 三种延迟的关系

这三种延迟不是孤立的，它们之间会相互影响。比如：

• 处理延迟大了，数据在缓冲区里等的时间就长，排队延迟也跟着变大
• 排队延迟大了，接收端可能超时重传，又增加了处理延迟

这就是个恶性循环。我在项目中见过太多这样的案例了。

下面这张图展示了三种延迟在光通信系统中的位置和关系：

从图上可以看得很清楚：数据从发送端出来，先经过处理延迟（编码、调制），然后在光纤里跑（传输延迟），到了中间节点可能还要排队（排队延迟），最后在接收端再经过一次处理延迟（解码、解调）。

而且，排队延迟和处理延迟之间还有反馈关系。处理慢了，排队就长了；排队长了，处理就更慢了。这就是为什么我总说，设计光通信系统时，一定要把这三个延迟放在一起考虑。

好了，这一章就讲到这里。记住，延迟不是简单的"光速问题"，它是个系统工程问题。下一章咱们聊聊怎么测量这些延迟，到时候我会分享一些我在实验室里踩过的坑。

---

公众号:蓝海资料掘金营，微信deep3321