USB4 正在变成一条 PCIe 通道：Intel 的 USB4STREAM 协议进入 Linux 7.2——这是 USB4 从’外设总线’变成’主机互联’的关键一步

USB 这个技术从 1996 年诞生到现在，核心架构假设从未改变过：一端是主机，另一端是设备。键盘、鼠标、硬盘、打印机——所有的外设都处于从属地位，主机发起命令，设备响应。Thunderbolt 把带宽拉到了 40Gbps，USB4 把协议整合了，但”主机-设备”的不对称关系基本延续了下来。

两台主机之间如果想用 USB 线互传数据，一直都要绕一个弯：把 USB4 隧道里再塞一层网络协议，配 IP 地址，走以太网栈，然后才能 scp 或者 rsync。带宽浪费在协议开销上，配置摩擦耗在网络设置上，一根 40Gbps 的线最终可能只跑出网卡速度的一部分。

Intel 的 Linux 内核 Thunderbolt 维护者 Mika Westerberg 提交的 USB4STREAM 驱动，绕过了这整个弯路。

Thunderbolt 的隧道架构：USB4 的线里跑的是什么

要理解 USB4STREAM 做了什么，先得知道 USB4/Thunderbolt 线缆里实际在运输的是什么。

USB4 规范定义了一套隧道协议：一条物理线缆可以同时承载多种流量，互相隔离——PCIe 隧道（用于 eGPU、NVMe 扩展坞等 PCIe 设备）、DisplayPort 隧道（用于外接显示器）、USB 3.2 隧道（向后兼容 USB 设备）。这三类流量在同一根线里并行，互不干扰，由 Thunderbolt 控制器在端点做路由。

这个架构使得 Thunderbolt 本质上是一条多路复用总线，而不只是”很快的 USB 线”。连接一个 Thunderbolt 扩展坞时，它会同时建立 PCIe 隧道（扩展坞里的 NVMe 和 GPU）、DP 隧道（外接显示器）、USB 隧道（键鼠等 USB 设备）。用户看到的”一根线连一切”，背后是这三条隧道并行运作。

USB4STREAM 是在这个架构上新增了第四类隧道——一条原始数据流隧道，不关联任何设备抽象，不需要枚举，不关心对端连着什么。它就是一条管道，两端各有一个文件描述符，写进去什么，另一端就读出什么。

IP over Thunderbolt 的问题：协议栈是一层不必要的抽象

现有的主机间 Thunderbolt 互联方案——Apple 的 Thunderbolt Bridge 和 Linux 的 thunderbolt-net——都选择了在 Thunderbolt 上模拟以太网接口。两台主机连上之后，系统里会出现一块虚拟网卡，然后用标准的 IP 配置走 DHCP 或手动配地址，之后就是普通的网络连接了。

这个方案的优点是兼容性极好——所有现有的网络应用和工具都可以直接用，开发者不需要学任何新东西。但它有三个代价：

第一，协议开销。以太网帧头、IP 头、TCP/UDP 头，每一层都有固定的开销，在高带宽场景下累积显著。Thunderbolt 4 理论带宽 40Gbps，实际跑 TCP 文件传输能达到多少，取决于 CPU 处理协议栈的速度，而不仅仅是物理介质。

第二，配置摩擦。配 IP 地址、处理 ARP、配置路由、有时还要处理防火墙规则——在 Linux 上配 thunderbolt-net 一直不算开箱即用。在 initramfs 等最小化启动环境里，这些步骤的摩擦更高，因为很多网络工具不一定可用。

第三，攻击面。一旦建立了网络连接，就意味着端口暴露、服务可达，在安全策略严格的环境里需要额外的访问控制。

USB4STREAM 绕过了所有这些。它不是网络连接，不需要 IP 地址，不开放端口，不走 TCP 栈。两台机器之间只有一个字符设备在读写，Thunderbolt 控制器在内核的 DMA 环（DMA ring）里直接搬数据，用 HopID 标识流的端点（相当于在 Thunderbolt 路由域里的”地址”）。

字符设备、DMA 环和 HopID：它在内核里如何工作

USB4STREAM 的内核驱动叫 thunderbolt_stream ，提交者是 Intel 的 Thunderbolt 维护者 Mika Westerberg，代码当前在 thunderbolt.git 的 next 分支。

两台主机用 USB4 线直连后，USB4STREAM 驱动会在每台机器上创建 /dev/tbstream0 、 /dev/tbstream1 等字符设备，数量取决于可用的 DMA 环。一条流需要两个 DMA 环（收发各一）和一对 HopID（用于 Thunderbolt 路由——类似于 PCIe 的 BDF 地址，标识数据包从哪条路径走到哪个端点）。

配置通过 ConfigFS 完成。接收端先在
/sys/kernel/config/usb4streams/ 下创建配置节点，写入 HopID（或者写 -1 让内核自动分配）；发送端对应配置，绑定到同一个 HopID 对。之后的使用完全透明：

# 主机间原始块设备备份（无 SSH、无网络）
# dd if=/dev/tbstream0 of=/tmp/disk-backup.img bs=256k

# dd if=/dev/nvme0n1 of=/dev/tbstream0 bs=256k

# 目录传输
# gunzip < /dev/tbstream0 | tar xf -

# tar cf - mydir | gzip > /dev/tbstream0

# 摄像头流共享
# gst-launch-1.0 filesrc location=/dev/tbstream0 ! jpegdec ! videoconvert ! autovideosink

# gst-launch-1.0 v4l2src device=/dev/video0 ! \

 video/x-raw,width=1920,height=1080 ! jpegenc quality=90 ! \

 filesink location=/dev/tbstream0

Westerberg 的补丁说明里写得直白：”任何支持 read(2) 和 write(2) 的应用都可以直接使用这个接口，不需要任何修改。”这是字符设备作为 Unix 抽象的优势——管道、重定向、tar、dd、gstreamer，所有这些工具都直接可用。

initramfs 场景：它解决的是一个真实的系统管理痛点

这个功能的最典型受益场景是系统恢复。当一台 Linux 机器的文件系统损坏或操作系统无法正常启动，管理员需要先备份数据再重装。传统做法：启动到 initramfs 或 live USB 环境，配置网络，启动 SSH 服务，从另一台机器连接，然后 rsync 或 nc 传数据。

在 initramfs 里，这些步骤每一个都是摩擦：网络驱动不一定加载了，DHCP 客户端不一定有，SSH 更不用说。手动配静态 IP 在 shell 里当然可以，但它依赖对目标机器网络环境的了解，而且在某些环境（VLAN、防火墙）下可能根本不通。

USB4STREAM 把这个流程缩减到： 用 USB4 线把出问题的机器连到另一台机器，两端 dd，备份完毕。 initramfs 只需要内核有 thunderbolt_stream 模块，不需要网络，不需要 SSH，不需要任何外部依赖。有多台 Thunderbolt 机器的开发者或系统管理员，可以从中获得实质性的工作流改善。

类似的思路在 NVMe over Fabrics（NVMeoF）里出现过：把 NVMe 块设备通过网络（RDMA、TCP、FC）共享给另一台主机，绕过文件系统层，直接传块层数据。USB4STREAM 做的是更简单的版本——不需要 NVMeoF 的服务端配置，不需要 initiator/target 角色，两端对等，插上线就能用。

它指向的方向：USB4 作为点对点 PCIe 总线

USB4STREAM 更深层的意义，在于它进一步确认了 USB4 的演化方向：这不是”更快的 USB 3.0″，而是把一条 PCIe 总线装进了一根消费级线缆。

Thunderbolt 3 和 4 已经有 PCIe 隧道——eGPU、NVMe 扩展坞都是走 PCIe 隧道接入主机的。USB4STREAM 在这之上加了一个用户态的直接数据通道，不通过设备驱动抽象，不通过文件系统，只是内存到内存的搬运，由 DMA 完成，开销最小化。这个模型和主机间 PCIe 直连（如 NVLink、PCIe over 光纤）的概念很接近，差别只在于它走的是消费级接口，不需要数据中心级的专用硬件。

这个方向如果继续延伸，下一步可以是什么？一个推论是：AI 推理加速卡的直接 USB4 挂接，不通过 PCIe 标准设备枚举，而是通过 USB4STREAM 做批量推理数据的搬运——对外置 AI 加速器而言，这可能比走 eGPU 的 PCIe 隧道延迟更可控（少了 GPU 驱动层）。这还只是可能性，USB4STREAM 驱动本身没有限制到特定用途。

驱动目前在 Intel 的 thunderbolt.git next 分支 ，配套文档在 。按 Linux 合并节奏，预计在 6 月通过 USB/Thunderbolt 子系统维护者，然后在 7 月中旬的 Linux 7.2 合并窗口进入主线。Windows 目前没有对应的实现——这是一个纯 Linux 内核驱动，也是目前消费级硬件能直接用到这个能力的唯一途径。