FreeBSD 中文社区 2025 第二季度问卷调查
FreeBSD 中文社区(CFC)
VitePress 镜像站QQ 群 787969044视频教程Ⅰ视频教程Ⅱ
  • FreeBSD 从入门到追忆
  • 中文期刊
  • 状态报告
  • 发行说明
  • 手册
  • 网络文章集锦
  • 笔记本支持报告
  • Port 开发者手册
  • 架构手册
  • 开发者手册
  • 中文 man 手册
  • 文章
  • 书籍
  • FreeBSD 中文期刊
  • 编辑日志
  • 2025-123 下游项目
    • FreeBSD 发布工程:新主管上任
    • GhostBSD:从易用到挣扎与重生
    • BSD Now 与将来
    • 字符设备驱动教程(第三部分)
    • 学会走路——连接 GPIO 系统
    • FreeBSD 中对 SYN 段的处理
    • FreeBSD 2024 年秋季峰会
  • 2024-1112 虚拟化
    • 字符设备驱动程序教程(第二部分)
    • 面向 Linux 和 Windows 用户的 bhyve
    • Xen 与 FreeBSD
    • Wifibox:一种嵌入式虚拟化无线路由器
    • 嵌入式 FreeBSD:Fabric——起步阶段
    • DGP:一种新的数据包控制方法
    • 会议报告:我在都柏林的 EuroBSDCon 体验
  • 2024-0910 内核开发
    • 字符设备驱动程序教程
    • VPP 移植到了 FreeBSD:基础用法
    • 利用 Kyua 的 Jail 功能提升 FreeBSD 测试套件的并行效率
    • FreeBSD 上的 Valgrind
    • 嵌入式 FreeBSD:探索 bhyve
    • TCP/IP 历险记:FreeBSD TCP 协议栈中的 Pacing
    • 实用软件:实现无纸化(Paperless)
  • 2024-0708 存储与文件系统
    • FreeBSD 中的 NVMe-oF
    • FreeBSD iSCSI 入门
    • 使用 ZFS 原生加密保护数据
    • 嵌入式 FreeBSD:打造自己的镜像
    • TCP LRO 简介
    • 基于 Samba 的时间机器备份
  • 2024-0506 配置管理对决
    • 基本系统中的 mfsBSD
    • rdist
    • Hashicorp Vault
    • 在 GitHub 上向 FreeBSD 提交 PR
    • 悼念 Mike Karels
    • 2024 年 5-6 月来信
    • 嵌入式 FreeBSD 面包板
    • TCP/IP 历险记:TCP BBLog
    • 实用软件:开发定制 Ansible 模块
  • 2024-0304 开发工作流与集成
    • FreeBSD 内核开发工作流程
    • FreeBSD 与 KDE 持续集成(CI)
    • 更现代的内核调试工具
    • 从零开始的 ZFS 镜像及 makefs -t zfs
    • 提升 Git 使用体验
  • 2024-0102 网络(十周年)
    • FreeBSD 中的 RACK 栈和替代 TCP 栈
    • FreeBSD 14 中有关 TCP 的更新
    • if_ovpn 还是 OpenVPN
    • SR-IOV 已成为 FreeBSD 的重要功能
    • FreeBSD 接口 API(IfAPI)
    • BATMAN:更优的可移动热点网络方式
    • 配置自己的 VPN——基于 FreeBSD、Wireguard、IPv6 和广告拦截
    • 实用软件:使用 Zabbix 监控主机
  • 2023-1112 FreeBSD 14.0
    • LinuxBoot:从 Linux 启动 FreeBSD
    • FreeBSD 容器镜像
    • 现在用 Webhook 触发我
    • 新的 Ports 提交者:oel Bodenmann (jbo@freebsd.org)
  • 2023-0910 Port 与软件包
    • 回忆录:与 Warner Losh(@imp)的访谈
    • 在你自己的仓库中定制 Poudriere 源
    • Wazuh 和 MITRE Caldera 在 FreeBSD Jail 中的使用
    • PEP 517
    • CCCamp 2023 旅行报告
  • 2023-0708 容器与云
    • 在 Firecracker 上的 FreeBSD
    • 使用 pot 和 nomad 管理 Jail
    • 会议报告:C 与 BSD 正如拉丁语与我们——一位神学家的旅程
    • 抒怀之旅:与 Doug Rabson 的访谈
    • 基于 Jail 的广告拦截教程
    • 我们收到的来信
  • 2023-0506 FreeBSD 三十周年纪念特刊
    • CheriBSD 近十多年的历程
    • AArch64:成为 FreeBSD 新的一级架构
    • 岁月如梭:我个人的时间线
    • 安装 FreeBSD 1.0:回顾 30 年前
    • ZFS 是如何进入 FreeBSD 的呢?
    • 我不是来自约克郡的,我保证!
    • 回忆录:采访 David Greenman Lawrence
    • FreeBSD 和早期的 Unix 社区
    • 早期的 FreeBSD 移植
    • FreeBSD 30 周年:成功的秘诀
    • FreeBSD 在日本:回忆之旅与今日之实
  • 2023-0304 嵌入式
    • CheriBSD port 和软件包
    • 让我们来试试 ChatGPT
    • GPU 直通
  • 2023-0102 构建 FreEBSD Web 服务器
    • ZFS 的原子 I/O 与 PostgreSQL
    • 虚拟实验室——BSD 编程研讨会
    • ZFS 简介
    • 会议报告:落基山庆祝女性计算机科学家
    • 进行中的工作/征求反馈:数据包批处理
    • 基金会与 FreeBSD 桌面
  • 2022-1112 可观测性和衡量标准
    • 在 FreeBSD 的 DDB 内核调试器中编写自定义命令
    • DTrace:老式跟踪系统的新扩展
    • 基于证书的 Icinga 监控
    • 活动监控脚本(activitymonitor.sh)
    • 实用 IPv6(第四部分)
    • EuroBSDCon 会议报道
    • 实用 Port:Prometheus 的安装与配置
    • 书评:《用火解决问题:管理老化的计算机系统(并为现代系统保驾护航)》Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)
  • 2022-0910 安全性
    • CARP 简介
    • 重构内核加密服务框架
    • PAM 小窍门
    • SSH 小窍门
    • 实用 IPv6(第三部分)
    • 书评:Understanding Software Dynamics(深入理解软件性能——一种动态视角)—— Richard L. Sites 著
    • 访谈:保障 FreeBSD 安全性
    • MCH 2022 会议报告
  • 2022-0708 科研、系统与 FreeBSD
    • 在 FreeBSD 上构建 Loom 框架
    • 教授本科生 Unix 课程
    • FreeBSD 入门研讨会
    • 实用 IPv6(第二部分)
    • 在 2022 年及以后推广 FreeBSD
    • 进行中的工作/征求反馈:Socket 缓冲区
    • FreeBSD 开发者峰会报告
    • 支持 Electromagnetic Field 2022
  • 2022-0506 灾难恢复
    • 使用 FreeBSD 构建高弹性的私有云
    • LLDB 14 —— FreeBSD 新调试器
    • 实用 IPv6(第一部分)
    • 利用 netdump(4) 进行事后内核调试
    • 进行中的工作/征求反馈:FreeBSD 启动性能
    • 实用 Port:在 OpenZFS 上设置 NFSv4 文件服务器
  • 2022-0304 ARM64 是一级架构
    • FreeBSD/ARM64 上的数据科学
    • Pinebook Pro 上的 FreeBSD
    • 嵌入式控制器的 ACPI 支持
    • 进行中的工作/征求反馈:Lumina 桌面征集开发人员
    • 实用 Port:如何设置 Apple 时间机器
  • 2022-0102 软件与系统管理
    • 为 FreeBSD Ports 做贡献
    • 使用 Git 贡献到 FreeBSD Ports
    • CBSD:第一部分——生产环境
    • 将 OpenBSD 的 pf syncookie 代码移植到 FreeBSD 的 pf
    • 进行中的工作/征求反馈:mkjail
    • 《编程智慧:编程鬼才的经验和思考》(The Kollected Kode Vicious)书评
    • 会议报告:EuroBSDCon 2021 我的第一次 EuroBSDCon:一位新组织者的视角
  • 2021-1112 存储
    • 开放通道 SSD
    • 构建 FreeBSD 社区
    • 与完美操作系统同行 27 年
    • 进行中的工作/征求反馈:OccamBSD
    • 通过 iSCSI 导入 ZFS ZIL——不要在工作中这样做——就像我做的那样
  • 2021-0910 FreeBSD 开发
    • FreeBSD 代码审查与 git-arc
    • 如何为 FreeBSD 实现简单的 USB 驱动程序
    • 内核开发技巧
    • 程序员编程杂谈
  • 2021-0708 桌面/无线网
    • 通往 FreeBSD 桌面的直线路径
    • FreeBSD 13 中的人机接口设备 (HID) 支持
    • Panfrost 驱动程序
    • 用 Git 更新 FreeBSD
    • FreeBSD 的新面孔
    • 想给你的桌面加点佐料?
  • 2021-0506 安全
    • 七种提升新安装 FreeBSD 安全性的方法
    • copyinout 框架
    • 使用 TLS 改善 NFS 安全性
    • Capsicum 案例研究:Got
    • 对 Jail 进行安全扫描
  • 2021-0304 FreeBSD 13.0
    • 展望未来
    • FreeBSD 13.0 工具链
    • FreeBSD 13.0 中有新加载器吗?
    • TCP Cubic 准备起飞
    • OpenZFS 中的 Zstandard 压缩
    • 会议报告:FreeBSD 供应商峰会
    • Git 不够吗?
  • 2021-0102 案例研究
    • Tarsnap 的 FreeBSD 集群
    • BALLY WULFF
    • Netflix Open Connect
    • FreeBSD 的新面孔
    • 写作学者的 FreeBSD
    • 在世界之巅
  • 2020-1112 工作流/持续集成(CI)
    • FreeBSD Git 快速入门
    • 使用 syzkaller 进行内核 Fuzzing
    • Mastering Vim Quickly 书评
    • 线上会议实用技巧
    • 在控制台上进行网络监控
  • 2020-0910 贡献与入门
    • 采访:Warner Losh,第 2 部分
    • 代码审查
    • 撰写良好的提交消息
    • 如何在不是程序员的情况下做出贡献——成为 FreeBSD 译者
    • 如何成为文档提交者
    • 谷歌编程之夏
    • 为 FreeBSD 期刊撰写文章
    • 你为什么使用 FreeBSD
    • FreeBSD 的新面孔
  • 2020-0708 基准测试/调优
    • FreeBSD Friday
    • 采访:Warner Losh,第 1 部分
    • 构建和运行开源社区
    • 在 FreeBSD 上轻松搭建我的世界(Minecraft)服务器
    • FreeBSD 的新面孔
  • 2020-0506 网络性能
    • 内核中的 TLS 卸载
    • 访谈:Michael W Lucas
    • FreeBSD 桌面发行版
    • 使用 Poudriere 进行 Port 批量管理
    • FreeBSD 的新面孔
由 GitBook 提供支持
LogoLogo

FreeBSD 中文社区(CFC) 2025

在本页
  • TCP Pacing
  • 高精度定时系统
  • 概念概述
  • 详细信息
  • sysctl变量
  • 在 RACK 堆栈中的流量控制优化
  • 快速路径传输
  • 快速路径重传
  • 结论
  • 参考文献
在GitHub上编辑
导出为 PDF
  1. 2024-0910 内核开发

TCP/IP 历险记:FreeBSD TCP 协议栈中的 Pacing

上一页嵌入式 FreeBSD:探索 bhyve下一页实用软件:实现无纸化(Paperless)

最后更新于1个月前

  • 原文地址:

  • 作者:Randall Stewart、Michael Tüxen

TCP 的发送和接收行为已经经历了 40 多年发展。在这期间,许多进展帮助 TCP 能够以非常高的速度传输可靠的数据流。然而,一些增强功能(无论是在协议栈中还是在网络中)也带来了负面影响。最初,TCP 协议栈会响应接收到的 TCP 段(ACK 应答)、上层提供的新数据或定时器到期时发送一个 TCP 段。TCP 发送方还实现了拥塞控制,以防止过快地向网络发送数据。这些特性结合在一起,可能会使得 TCP 端点大多数时间都受到“ACK 时钟”的影响,如下图所示。

image

图 1:ACK 时钟的示例

为简化说明,假设数据包已编号并 ACK,并且接收方每 ACK 一个数据包后,跳过一个包(以减少开销)。图中底部的 ACK“1”ACK 了之前发送的 0 和 1 号包(图中未显示),移除了两个未确认的包,并允许发送两个新的包,即包 8 和 9。此时,由于拥塞控制,发送方被阻塞,等待 ACK“3”的到来,这会 ACK 包 2 和包 3,并再次发送下两个包。这种 ACK 时钟现象在早期互联网的许多数据流中普遍存在,今天在某些情况下仍能看到。ACK 时钟形成了一种自然的数据传输 Pacing,允许数据包通过瓶颈发送,而通常在发送方的下一个数据包到达瓶颈时,前一个数据包已经被传输了。

然而,随着时间的推移,网络和 TCP 的优化已改变了这种行为。一个例子可以在有线网络中看到。在这种网络中,下行带宽很大,但上行带宽较小(通常只有下行带宽的一部分)。

由于回传路径带宽的稀缺,有线调制解调器通常会仅保持最后一个已发送的 ACK(假设它看到的 ACK 是按顺序的),直到决定发送。因此,在上述示例中,有线调制解调器可能只会发送 ACK-5,而不是允许发送 ACK-1、ACK-3 和 ACK-5。这将导致发送方发送一个较大的数据包突发,而不是将三次两个数据包的突发分开。

另一个修改行为的例子可以在其他时隙技术中看到(这些技术会等到自己的时间片到达时才发送数据包,然后一次性发送所有排队的包),在这些技术中,ACK 会被排队,然后一次性以三个 ACK 包的突发形式发送。这种类型的技术与 TCP-LRO(在上期中提到)相互作用,从而可能会将 ACK 合并成一个单一的 ACK(如果使用的是旧的方式),或者在发送函数调用之前,将所有 ACK 排队一起处理。在任何情况下,又会发送一个大数据包突发,而不是一系列的小两包突发,这些小包之间有小的时间间隔(大致接近瓶颈带宽加上一些传播延迟)。

我们的示例显示了六个数据包,但实际上在一次tcp_output()调用中,可能会有数十个数据包突发。这对 CPU 优化有好处,但可能会导致网络中的数据包丢失,因为路由器的缓冲区有限,大量突发数据包更容易导致尾丢失。这种丢包会减少拥塞窗口,从而影响整体性能。

除了上述两个例子外,还有其他原因可能导致 TCP 变得突发(其中一些在 TCP 中始终存在),例如应用程序受限的时段。这种情况是指发送应用程序由于某种原因暂停,延迟几毫秒才发送数据。在此期间,ACK 会到达,但没有数据需要发送。在网络中的所有数据尚未传输完之前(这可能由于空闲而导致拥塞控制减少),应用程序会发送另一个较大的数据块。此时,拥塞窗口是打开的,因此可以生成较大的发送突发。

另一个突发性源可能来自对等 TCP 实现,它们可能决定每 ACK 第八个或第十六个包,而不是遵循 TCP 标准每 ACK 一个包。这种较大范围的 ACK 会再次导致对应的突发。TCP Pacing 控制(在下一节中描述)是一种改进 TCP 段发送的方式,用以平滑这些突发。

TCP Pacing

以下示例说明了 TCP Pacing 控制。假设使用 TCP 连接以 12 兆比特每秒的速度向对等方传输数据,包括 IP 和 TCP 头。假设最大 IP 数据包大小为 1500 字节(即 12000 位),这将导致每秒发送 1000 个 TCP 段。在使用 Pacing 控制时,将每毫秒发送一个 TCP 段。可以使用一个每毫秒触发的定时器来实现这一点。以下图形展示了这种发送行为。

图 2:以 12Mbps 速率传输的 TCP 连接 Pacing 控制

以这种方式进行 Pacing 控制是可行的,但由于需要较高的 CPU 成本,这并不理想。因此,为了提高效率,TCP 在进行 Pacing 控制时,通常会发送小的突发数据包,并且这些数据包之间会有一定的时间间隔。突发包的大小通常与协议栈希望的 Pacing 速度相关。如果以较高的速率进行 Pacing 控制,则需要较大的突发数据包;如果以较低的速率进行 Pacing 控制,则使用较小的突发数据包。

在设计 TCP 协议栈的 Pacing 控制方法时,可以采取多种方法。常见的做法是让 TCP 协议栈在较低层设置一个速率,然后将大批量数据的发送交给该层处理。较低层再通过合适的定时器来多路复用来自不同 TCP 连接的数据包,从而实现数据的间隔发送。然而,这不是 FreeBSD 协议栈采用的方法,特别是因为这种方法限制了 TCP 协议栈对发送过程的控制。如果连接需要发送重传数据包,重传数据包将排在所有待发送的队列包之后。

在 FreeBSD 中,采用了不同的方法,让 TCP 协议栈控制发送,并创建了一个专门的定时系统,当 Pacing 间隔结束时,该系统会调用 TCP 协议栈发送数据。这种方法将发送控制完全交给 TCP 协议栈,但可能会带来一些性能问题,需要进行相应的补偿。下一节将介绍为 FreeBSD 创建的这一新子系统。

高精度定时系统

概念概述

高精度定时系统(HPTS)是一个可加载的内核模块,提供了一个简单的接口,供任何希望使用它的 TCP 协议栈调用。基本上,TCP 协议栈会调用两个主要函数来使用 HPTS 提供的服务:

  • tcp_hpts_insert():将 TCP 连接插入到 HPTS 中,在指定的时间间隔内调用tcp_output(),或者在某些情况下,调用 TCP 的入站数据包处理函数tfb_do_queued_segments()。

  • tcp_hpts_remove():要求 HPTS 从 HPTS 中移除一个连接。通常在连接关闭或不再需要发送数据时使用。

HPTS 中还提供了一些其他辅助功能,帮助进行定时和其他管理任务,但上述两个函数是 TCP 协议栈用于实现 Pacing 控制的基本构建块。

详细信息

在内部,每个 CPU 都有一个 HPTS 轮盘,这是一个连接列表的数组,表示在不同时间点需要服务的连接。轮盘中的每个槽位代表 10 微秒。当一个 TCP 连接被插入时,它会被分配一个从现在开始的槽位数量(即 10 微秒的时间间隔),直到调用tcp_output()函数。这个轮盘由系统定时器(即 FreeBSD 的调用系统)和一个软定时器(如[1]中提议的)共同管理。基本上,每次系统调用返回时,在返回用户空间之前,HPTS 可能会被调用,以查看是否需要服务某个 HPTS 轮盘。

HPTS 系统还会自动调优 FreeBSD 的系统定时器,首先设置最小值(默认为 250 微秒)和最大值,如果 HPTS 轮盘中有更多连接且调用频繁,则 FreeBSD 系统超时期间的小量处理将增加系统定时器的长度。如果连接数低于某个阈值,则仅使用基于系统定时器的方法。这有助于避免通过在轮盘上保持连接时间过长而导致连接饿死。HPTS 尝试提供定时器最小精度(即 250 微秒),但这并不保证。

使用 HPTS 进行 Pacing 控制的 TCP 协议栈有一些特定的责任,以便与 HPTS 协作,实现所需的 Pacing 速率,包括:

  • 待启动了 Pacing 定时器,协议栈必须禁止任何发送或其他对tcp_output()的调用,直到 Pacing 定时器到期。协议栈可以查看t_flags2字段中的TF2_HPTS_CALLS标志。当 HPTS 调用tcp_output()函数时,该标志将被设置,协议栈应在其tcp_output()函数内进行清除。

  • 在 Pacing 定时器到期后,HPTS 的调用中,协议栈需要验证它的空闲时间。HPTS 可能会比预期稍晚调用协议栈,甚至可能提前调用协议栈(尽管这种情况非常罕见)。协议栈需要将晚到或早到的时间纳入下一个 Pacing 超时计算中,之后再发送数据。

  • 如果协议栈决定使用 FreeBSD 定时器系统,它还必须阻止定时器调用发送数据。RACK 和 BBR 协议栈不会使用 FreeBSD 定时器系统进行超时,而是直接使用 HPTS。

  • 如果协议栈从 LRO 队列中排队数据包,则 HPTS 可能会调用输入函数,而不是tcp_output()。如果发生这种情况,则不会再调用tcp_output(),因为假设协议栈会在需要时调用其输出函数。

HPTS 还提供了一些工具来协助 TCP 协议栈,包括:

  • tcp_in_hpts():告诉协议栈是否已在 HPTS 系统中。

  • tcp_set_hpts():设置连接将使用的 CPU,这是一个可选调用,如果协议栈未调用此函数,HPTS 会为该连接执行此操作。

  • tcp_tv_to_hptstick():将struct timeval转换为 HPTS 槽位数。

  • tcp_tv_to_usectick():将struct timeval转换为 32 位无符号整数。

  • tcp_tv_to_lusectick():将struct timeval转换为 64 位无符号整数。

  • tcp_tv_to_msectick():将struct timeval转换为 32 位无符号毫秒定时器。

  • get_hpts_min_sleep_time():返回 HPTS 强制执行的最小睡眠时间。

  • tcp_gethptstick():可选地填充一个struct timeval并返回当前的单体时间,作为 32 位无符号整数。

  • tcp_get_u64_usecs():可选地填充一个struct timeval并返回当前的单体时间,作为 64 位无符号整数。

sysctl变量

HPTS 系统可以通过sysctl变量进行配置,以改变其性能特征。默认情况下,这些值设置为一组“合理”的值,但根据应用的不同,可能需要进行更改。值可以在net.inet.tcp.hpts系统控制节点下进行设置。

以下是可用的调优参数:

名称
默认值
描述

no_wake_over_thresh

1

当将连接插入 HPTS 时,如果此布尔值为真且连接数大于cnt_thresh,则不允许调度 HPTS 运行。如果值为 0(假),则在将连接插入 HPTS 时,可能会导致 HPTS 系统运行连接,即调用tcp_output()以调度的连接。

less_sleep

1000

当 HPTS 完成运行时,它会知道它运行了多少个槽。如果运行的槽数超过此值,则需要减少动态定时器。

more_sleep

100

当 HPTS 完成运行时,如果运行的槽数少于此值,则动态睡眠时间将增加。

min_sleep

250

这是 HPTS 定时器可以降低到的绝对最小值。减小此值会导致 HPTS 运行更多,使用更多的 CPU。增大它会导致 HPTS 运行更少,使用更少的 CPU,但会负面影响精度。

max_sleep

51200

这是定时器可以达到的最大睡眠值(以 HPTS 槽位为单位)。通常仅在没有连接被服务时使用,即 HPTS 每 51200 x 10 微秒(大约半秒)唤醒一次。

loop_max

10

此值表示 HPTS 在尝试为所有需要服务的连接提供服务时将循环的次数。当 HPTS 启动时,它会将需要服务的连接列表集合在一起,然后开始对每个连接调用tcp_output()。如果花费的时间太长,可能还需要服务更多的连接,因此它将再次循环以提供服务。此值表示 HPTS 在被强制休眠之前最多可以执行多少次此循环。注意,从函数调用返回时不会导致任何循环发生;只有 FreeBSD 定时器调用会受到此参数的影响。

dyn_maxsleep

5000

当调整调用时间并看到更多睡眠需求时,动态定时器可以提高的最大值。

dyn_minsleep

250

当调整调用时间并看到较少睡眠时,动态定时器可以降低的最小值。

cnt_thresh

100

这是轮盘上需要的连接数,用于开始更多依赖系统调用返回的情况。超过此阈值时,系统调用返回和超时都会导致 HPTS 运行;低于此阈值时,我们更依赖调用系统来运行 HPTS。

在 RACK 堆栈中的流量控制优化

使用 HPTS 系统进行流量控制时,与运行在 TCP 堆栈之下的流量控制系统相比,可能会有一些性能损失。这是因为每次调用tcp_output()时,会做出很多关于发送内容的决策。这些决策通常会引用多个缓存行,并涉及大量代码。例如,默认的 TCP 堆栈在tcp_output()路径中有超过 1500 行代码,其中不包括任何关于流量控制或突发流量缓解的代码。对于没有流量控制的默认堆栈,通过这么多行代码和大量缓存未命中的影响,仍然能够通过一次发送多个数据段来进行补偿。然而,当实现一个低层流量控制系统时,它可以通过追踪接下来需要发送的数据以及发送的数量,轻松地优化它必须发送的各种数据包的发送过程。这使得低层流量控制系统减少了许多缓存未命中。

为了在像 HPTS 这样的高级系统中获得类似的性能,TCP 堆栈必须找到优化发送路径(包括传输和重传)的方式。堆栈可以通过创建“快速路径”发送通道来实现。RACK 堆栈已经实现了这些快速路径,以使流量控制的成本降低。BBR 堆栈当前也进行流量控制,符合已实现的 BBRv1 规范,但它尚未实现以下所述的快速路径。

快速路径传输

当 RACK 首次进行流量控制时,发送调用会通过它的tcp_output()路径,并计算出可以发送的字节数。然后将其降低到符合已建立的流量微突发大小,但在这一过程中,会设置一个“快速发送块”,记录剩余要发送的字节数以及这些数据在套接字发送缓冲区中的位置。同时还设置一个标志,以便 RACK 在下次知道快速路径处于活动状态。请注意,如果发生超时,快速路径标志会被清除,以便做出正确的决策,决定哪个重传需要发送。

在 RACK 的tcp_output()例程入口处,在验证可以发送数据后,会检查快速路径标志。如果标志被设置,则会使用之前保存的信息发送新数据,而不进行通常的输出路径检查。这大大降低了流量控制的成本,因为大部分代码和缓存未命中都从这个快速输出路径中消除了。

快速路径重传

RACK 中的重传也有一个快速路径。这得益于 RACK 的发送映射(sendmap),它跟踪所有已发送的数据。当某个数据块需要重传时,发送映射条目会精确告诉快速路径需要发送的数据的位置和大小。这跳过了典型的套接字缓冲区查找和其他开销,即使在发送重传时也能提供一定的效率。

结论

HPTS 为 TCP 堆栈提供了一种新颖的服务,使其能够实现流量控制。为了实现与竞争设计方法相当的效率,TCP 堆栈和 HPTS 需要合作,减少开销并实现高效的包突发发送。本文讨论了流量控制的必要性以及 FreeBSD 中为此提供的基础设施。未来的文章将探讨 TCP 堆栈进行流量控制时的另一个关键问题,即选择合适的流量控制速率。

参考文献


Mohit Aron, Peter Druschel: Soft Timers: Efficient Microsecond Software Timer Support for Network Processing. In: ACM Transactions on Computer Systems, Vol. 18, No. 3, August 2000, pp 197-228. .

RANDALL STEWART () 已从事操作系统开发四十余年年,自 2006 年以来一直是 FreeBSD 的开发者。他专注于传输协议,包括 TCP 和 SCTP,但也曾涉及操作系统的其他领域。目前他是独立顾问。

MICHAEL TÜXEN () 是明斯特应用科技大学的教授,Netflix 的兼职承包商,自 2009 年以来是 FreeBSD 源代码的提交者。他专注于传输协议,如 SCTP 和 TCP,及其在 IETF 的标准化以及在 FreeBSD 中的实现。

https://dl.acm.org/doi/pdf/10.1145/319344.319167
rrs@freebsd.org
tuexen@freebsd.org
Adventures in TCP/IP: Pacing in the FreeBSD TCP Stack