USB over Network 远程设备枚举：不是转发数据，而是复刻一次“插拔”
你有没有遇到过这样的场景：
在实验室调试一款刚烧录固件的STM32开发板，串口日志是唯一可观测信号——但你的主力开发机在办公室，而设备却连在产线旁的树莓派上；
又或者，云桌面里的Windows虚拟机需要直通一个USB加密狗，可它物理上插在千里之外的数据中心服务器上；
再比如，某医疗设备厂商要求客户只能通过专用PC访问其USB接口的超声探头，但现场工程师手头只有笔记本……
这些都不是“把USB数据包发过去”就能解决的问题。
真正卡住90%远程USB方案的，从来不是带宽或延迟，而是——设备一插上去，主机根本不认。
设备管理器里显示“未知USB设备”，dmesg刷出一堆device descriptor read/64, error -71，lsusb里空空如也……
这时候你才意识到：枚举失败了。
而绝大多数所谓“USB over IP”工具，在这里就悄悄降级成了“USB数据透传器”——它们能转发bulk传输，却绕不开枚举这道铁闸。因为枚举不是通信，它是一场精密的、状态强耦合的握手仪式，由主机发起、设备响应、操作系统全程监礼。任何环节失真，整场仪式作废。
所以今天，我们不谈协议栈分层、不列RFC编号、也不堆砌术语。我们就盯着一件事：当远端那台树莓派上的CP2102芯片被插进USB口的一瞬间，到你本地Windows弹出“发现新硬件——COM5”的全过程，网络两端究竟发生了什么？
枚举不是请求，是六步闭环的“USB入职流程”
先放下“远程”二字，回到最原始的USB总线现场。
当你把一个U盘插进电脑，你以为OS只是“看到”了一个设备？错。它其实完成了一套近乎苛刻的入职审查：
Reset（复位）：主机拉低D+和D−线至少10ms，像拍一下桌子：“都安静，新同事来了！”
→ 设备清空所有状态，回到地址0的“待分配”状态。Set Address（分配工号）：主机发出
SET_ADDRESS=5——这是给设备发的第一个正式ID。
→ 此后所有通信必须用地址5，不能再用0。这是整个枚举中唯一不可逆、不可跳过的强制步骤。Get Device Descriptor（查档案）：主机以地址0（注意！是0！因为刚复位完）读取18字节设备描述符。
→ 为什么用地址0？因为此时设备还没拿到工号，只能靠默认通道应答。里面藏着idVendor（厂家ID）、idProduct（产品ID）、bDeviceClass（设备大类）等关键身份信息。Get Configuration Descriptor（调阅岗位说明书）：先读前9字节获知整份说明书长度（
wTotalLength），再按长度二次读取全部内容。
→ 这份说明书里写着：这个设备有几个接口（Interface）、每个接口是什么类型（CDC？HID？MSC？）、用了哪些端点（Endpoint）、支持什么传输方式（Control/Bulk/Interrupt/Isochronous）……Set Configuration（宣布上岗）：主机发送
SET_CONFIGURATION=1，告诉设备：“你被录用为配置1号员工。”
→ 此刻设备才真正启用它的USB功能逻辑，端点开始可收发数据。Set Interface & Driver Bind（分配具体工位 + 安排师傅）：对多接口设备（如带CDC ACM +
