OPNsense FQ-CoDel：从基线测量到缓冲膨胀调优

当路由器来不及把数据送过较慢的链路时，数据包会进入缓冲区。缓冲太深，新到的交互流量就可能排在大量下载或上传数据后面，出现游戏延迟、语音卡顿，甚至数秒的等待。这就是缓冲膨胀（bufferbloat）。FQ-CoDel 将按流排队和受控延迟结合起来，让小流量更及时地发送，也让大流量公平分享瓶颈带宽。

本文根据 OPNsense／Deciso 官方的 Fighting Bufferbloat with FQ_CoDel 译写并整理，并合并 Control Plane Shaping。两页未见个人作者署名。本文未登录设备、运行测速或验证调优效果。

FQ-CoDel 如何控制排队延迟

算法并行完成三件事：先将到达的数据包按流分入队列；然后轮流从队列取出一批数据，通过瓶颈链路发送；最后对超过合理份额的流施加反馈。

关键指标是数据包在队列中停留的时间（sojourn time）。当排队延迟在一个 interval 内持续超过 target，CoDel 会开始丢弃部分数据包，或对支持 ECN 的流进行标记，促使发送端减速。target 不是“所有数据包绝不会超过的最大延迟”，而是控制持续排队的目标值。有关算法本身，参阅 RFC 8290 与 RFC 8289 §4.2。

先测基线，准备可恢复的变更

在启用整形之前，选一个测速工具，多次记录下载、上传、空载延迟和负载期间延迟。原文列举 Waveform、Cloudflare 和 Speedtest；选择其中一个并在后续一直使用它，减少测试条件差异。测速会消耗带宽和流量，应取得网络使用授权，并考虑计费与其他业务负载。

菜单名称和界面可能随版本变化，操作前请对照设备当前文档；本文不要求更改 NAT。变更前导出受保护的配置备份（如加密 XML），保留独立控制台或其他不会被整形规则影响的管理入口。恢复后还要复查接口映射、服务状态和同一套验证结果。

原文使用 ISP 宣称下载 530 Mbit/s、上传 30 Mbit/s 的示例，并建议从宣称速率的 85% 开始。原文下载表填了 495，却标注为 85%，两者算术不一致。本文采用明确公式：530 × 0.85 = 450.5 Mbit/s，30 × 0.85 = 25.5 Mbit/s。它们仅是这个示例的起点；你的最终值取决于实测。

建立双向管道、队列和规则

进入 Firewall → Shaper → Pipes，切换到高级模式，点击加号创建下载管道。下表把源文下载／上传的重复操作合并：

然后在 Queues 页创建 Download-Queue 和 Upload-Queue，分别关联 Download 与 Upload 管道。两者均勾选 enabled，weight 填 100，mask 留空。FQ-CoDel 不使用该 weight 来决定公平性；公平排队由管道调度器处理。队列里的 Enable CoDel、target、interval、ECN 都留空，因为这些字段针对队列层 CoDel，不应与管道层 FQ-CoDel 重复混用。

在 Rules 页建立以下两条规则。源与目的地址、源与目的端口都为 any，enabled 勾选：

方向是从 WAN 接口观察：进入 WAN 的流量是下载，离开 WAN 的流量是上传。完成后点击 Apply 生效。若同时部署下文控制平面规则，它们必须排在这些宽泛规则之前，届时要调整 sequence。

用迭代找到可用带宽

应用设置后再次测速。先小幅提高下载管道 bandwidth，再测负载延迟；若延迟仍低，可以继续提高。出现明显上升后回退设置。上传方向重复同样过程。目标是让上下行分别达到不显著增加负载延迟的最高可用速率，而不是把数字设成套餐标称值。

FQ-CoDel 的其他默认参数通常已经能提供良好效果。原文建议先用一天，再决定是否进一步调参。保留每次设置和结果，避免同时修改多个参数后无法判断原因。以上是方法，不是本文的性能结论。

需要时再调整高级参数

quantum：不要机械套带宽比例

quantum 是一个队列本次轮转能发送的字节量。原文反对“每 100 Mbit/s 配 300”的网络传言，通常建议按 WAN MTU 设置。对低于 100 Mbit/s 的较慢线路，原文也提到可尝试 300，让小包更快获得发送机会，但这会增加轮转和 CPU 开销；高速链路收益可能有限。1514 的默认值与界面上 IP MTU 1500 的差异来自原文采用的二层头计数，应按实际链路与实现理解，不能把两者随意混为同一计量。

target 与 interval：考虑序列化时间和反馈周期

target 至少要考虑一个 MTU 大小的数据包在 WAN 出口发送所需的时间，否则在低带宽链路上可能过于激进。原文一般建议 target 约为 interval 的 5%—10%；interval 默认 100 ms 通常有效，其讨论范围为 10 ms—1 s，特别是 10—300 ms。进一步调 interval 时，应考虑穿过瓶颈后的较差 RTT 情况。

原文另给出了利用下一跳探测调整 target 的经验方法。先通过 traceroute 识别 OPNsense WAN 之后的 ISP 设备，再用大包 ping 观察 RTT。以下是原文命令及输出摘录，地址和数值属于原作者示例，不是可直接用于你的网络的目标，也不是本次测试：

traceroute 1.1.1.1
1  192.168.0.1  0.463 ms  0.453 ms  0.480 ms
2  10.205.5.1  10.879 ms  11.010 ms  11.079 ms

ping -s 1472 -c 1000 -D 10.205.5.1
1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.800/11.429/45.992/4.796 ms

原文把平均 RTT 11.429 ms 向上取整为 12 ms 作为其例子的 target。译写补充：RTT 包括路径、设备处理和 ICMP 行为，不等于本机队列时延，所以这是经验调参例子，不能替代前述序列化时间和负载验证。仅对获授权的下一跳进行有界探测；首次验证可减少次数，而不是盲目复制 1000 次。-D 等 ping 参数具有操作系统差异，原例环境为 OPNsense／FreeBSD，不能原样推广为 Linux 命令。

limit：保留版本边界

源文认为 10240 个包的默认 limit 对低于 10 Gbit/s 的连接偏大，并引用建议值 1000。较大的硬上限可能影响某些慢启动基准，过低又可能影响新流启动。因此应先采用默认值完成带宽调优，再按版本和负载谨慎尝试。

原文链接了 FreeBSD 中队列超过 limit 导致日志过多、CPU 占用升高的问题，并说明 OPNsense 开发者在 25.7.8 修复了相应日志问题。这一说明适用于源文所述修复边界，不能反推更旧版本安全，也不能证明任意低 limit 都合适。更改前核对设备实际版本和修复说明。

flows 与 ECN

flows 设置哈希分类队列数；多个流仍可能哈希到同一槽。当前源文所述实现只在初始化时分配哈希表，修改需重启设备。过大的值可能使设备卡住，应保留默认值，除非有可验证的理由及恢复通道。

原文建议低于 4 Mbit/s 的上行在追求良好 VoIP 性能时关闭 ECN，并指出 1 Mbit/s 下发送一个大包约需 13 ms。对家用路由器的下行，若终端离路由器仅一两跳且正确处理 ECN，ECN 可能有帮助；如果出现慢启动问题，可以对照测试关闭 ECN。它们是源文经验建议，应结合实际端点和链路验证。

为 IPv6 控制流量留出独立通道

如果使用 IPv6 或动态路由协议，还要考虑控制平面。官方把网络设备功能区分为：控制平面负责拓扑和协议交换，例如 OSPF、IS-IS、BGP、PIM、IGMP、ICMP、ARP、BFD、LACP 与路由信息库；管理平面负责监控与设备访问，例如 SNMP、SSH；数据平面负责转发用户流量。原文也列举了 Telnet、FTP 等管理协议，这是分类举例，不是推荐使用明文协议。

拥塞时，关键控制消息受阻可能破坏网络运行。官方方案要求控制流量使用独立管道和队列，不与其他类别共享。控制管道推荐 WFQ 或 QFQ，以便按队列权重分配带宽；原文不推荐 FIFO（无权重）、DRR（延迟）、FQ-CoDel／FQ-PIE（主动队列管理的反馈机制）承担此任务。

控制平面保留量按已调好带宽的约 1% 起步，最低 1 Mbit/s，可根据需要增加。原文控制平面章节另外假定调优后的下载／上传为 495／30 Mbit/s，据此保留 5／1 Mbit/s。这是独立假设，不是前文 530／30 套餐的 85% 起点。分给独立控制管道的带宽要从现有数据管道扣除：在这个假设中数据管道变成 490／29 Mbit/s，总预算仍为 495／30。

控制管道和队列

在 Pipes 高级模式分别创建 Control-plane-Pipe-Download 和 Control-plane-Pipe-Upload。启用它们，bandwidth 在上述假设下分别为 5 和 1 Mbit/s，调度器选 WFQ（或 QFQ），queue、mask、CoDel 开关以及 target、interval、ECN、quantum、limit、flows 字段均留空。

在 Queues 中创建 Control-plane-IPv6-Queue-Download 和 Control-plane-IPv6-Queue-Upload，分别关联对应控制管道，启用并把 weight 设为 100；mask、CoDel 及其参数留空。在 WFQ／QFQ 下，权重用于决定同一控制管道内多个协议队列的带宽比例，这与前文 FQ-CoDel 忽略 weight 的情况不同。

控制流量规则必须先匹配

建立 WAN 入方向与出方向两条控制规则，协议均为 ipv6-icmp，源、目的地址及端口为 any，目标分别为对应控制队列。原文分别命名 Control-plane-IPv6-Rule-Download 和 Control-plane-IPv6-Rule-Upload，sequence 为 1 和 2。任何可能提前匹配同一流量的宽泛规则都要后移；例如将前文普通下载／上传规则改为 3 和 4，然后 Apply。

这里的 any 是整形分类的匹配范围，不是防火墙放行授权；仍由既有访问规则决定流量能否通过。需要 BGP、PIM 等其他控制协议时，可在已建立的控制管道下增加独立队列和适当权重，并用对应规则匹配，不能假设一条 ipv6-icmp 规则覆盖全部控制平面。

完成后的核对与出处

按同一工具重测上下行与负载延迟，同时检查 IPv6 连通性、相关邻居和路由状态、管理可达性及设备 CPU。调整失败时用备份恢复，并复查接口映射和服务状态。本次只做文档与配置的静态审核；没有执行原文探测、测速、设备重启或任何规则写入，没有把原作者结果写成自己的测试结论。

原文外部参考还包括 FreeBSD ipfw 手册、CoDel／FQ-CoDel 基准实践、FreeBSD 问题 276890及 Linux tc-fq_codel 手册。它们是原文延伸阅读，不意味着本文验证了这些不同平台的全部实现。

为保留两篇原文的引用链，其他延伸阅读包括 OPNsense 社区讨论 4949、OPNsense 社区讨论 39046、FreeBSD FQ-CoDel 实现讨论、Cisco Press：网络设备操作平面、数据、控制与管理平面说明、OPNsense 控制平面社区讨论，以及控制平面原页列出的 ipfw 手册入口。这些链接按原文保留，本文没有把社区讨论或其他平台文档作为已测试结果。

本文为中文译写，合并控制平面章节，修正带宽算例的算术不一致，并补充版本、命令、回退与验证边界。文档许可为 BSD 2-Clause，完整文本也可下载 LICENSE-OPNsense-Documentation-BSD-2-Clause.txt；以下保留完整声明：

Deciso B.V. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPNSENSE DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.