国产USB转千兆网卡芯片CH398实测：对标RTL8153的兼容与性能深度评测

这两年做硬件选型，USB转千兆网卡这颗小芯片，居然成了最让我纠结的料之一。以前项目上要么直接用RTL8153，预算宽裕就往上升TI的LAN7800，稳定性确实没话说，但价格和交期在项目节点面前基本没有讨价还价的余地。今年拿到一颗国产USB转千兆网卡芯片CH398，官方定位就是RTL8153的软硬件兼容替代，我前后测了几周，从USB协议层的枚举抓包，到Windows、Linux、Android的驱动兼容，再到iperf3吞吐、延迟、功耗、发热表现，基本把它摸透了，样机已经进入量产评估阶段。这篇把整个实测和选型过程写下来，给正在看国产方案的同行一个直接参考。

1. 项目概述与选型背景

1.1 一颗“敢说对标RTL8153”的国产芯片

先交代一下CH398的基本身份。这是一颗国产的USB转10/100/1000M以太网控制芯片，采用的接口是USB 3.2 Gen1，也就是大家平时说的USB 3.0，同时向下兼容USB 2.0和USB 1.1。芯片内部集成了USB PHY、USB MAC、以太网MAC以及千兆PHY，外部只要挂一颗25MHz晶振、一组网络变压器和RJ45座子就能组成完整的转接方案。

对比标的RTL8153，瑞昱这颗料在USB千兆网卡领域的地位不用多说，各种扩展坞、便携网卡、开发板底板里十有八九都是它。RTL8153B和RTL8156（2.5G版）在全球出货量非常夸张，驱动已经进了Windows、Linux、macOS三大系统的inbox，用户插上就能用，几乎感知不到驱动存在。CH398敢说对标，主要打的就是“寄存器级兼容”这张牌：USB描述符结构和内部寄存器映射尽量向RTL8153靠拢，达到驱动程序层面的兼容效果。

我拿到的工程样品丝印是CH398-Q48，QFN48封装，手工焊在转接板上，上电后系统识别为USB以太网适配器。核心参数我整理了表格，方便后面测试对照。

1.2 为什么要做这个国产替代实测

说白了就两个字：卡脖子和成本。RTL8153在正常年份采购没什么大问题，但一旦遇到供应波动，交期能从4周拉到20周以上，价格也会被中间商抬得离谱。对于一个年出货几万片的项目来说，这颗料的成本波动直接影响整机毛利。

另外一个客观原因在于，USB转千兆网卡的需求场景在变。以前主要是笔记本用户买一个USB网卡解决没有网口的问题，现在更多出现在工业设备、POS机、视频会议终端、扩展坞、嵌入式开发板上，这些场景对长期稳定供货的要求远高于消费市场。一颗不受外部供货周期左右、技术支持能在微信群里直接对话的国产芯片，本身就是价值。

但国产替代最忌讳的就是“看手册很完美，上手全是坑”。所以我设计测试方案时，刻意把重心放在跟实际使用密切相关的几块：USB协议层是否正确、驱动兼容到底做到什么程度、千兆吞吐能不能跑满、长时间重负载是否掉链子、出问题的时候怎么排查。本文的内容基本就是按这个路径来的。

2. 板卡设计与测试环境搭建

2.1 最小系统硬件组成和物料注意

CH398的参考设计非常接近RTL8153，做板子的时候我直接用原来的封装改线，整体改动量不大。最小系统包含以下物料：

• CH398主芯片（QFN48）
• 25MHz石英晶振，负载电容按手册选18pF到22pF
• 网络变压器加RJ45一体式连接器
• 3.3V LDO，输入取USB 5V
• USB 3.0 A型连接器，或者Type-C母座
• 若干去耦电容、ESD防护器件

这里有几个工程细节值得展开说。第一，USB 3.0的SSTX/SSRX两组差分对和USB 2.0的D+/D-都要做90欧姆差分阻抗控制，PCB叠层不允许的话，至少保证差分对内等长控制在5mil以内。第二，千兆以太网的TX/RX差分对需要100欧姆阻抗，跟USB部分走线分开，避免串扰。第三，靠近RJ45的网络变压器中心抽头电容选择要严格按手册，常见的接法是2kV耐压的1000pF高压电容，用于共模噪声泄放。

QFN48封装底部的大焊盘一定要接好地。我测试板第一版就是因为底部焊盘接地不良，导致芯片发热严重，千兆长时间满载直接热保护掉线，后面重新开钢网才解决。QFN这种封装底部焊盘不仅是散热通道，也是数字地与模拟地汇流的地方，焊接空洞会导致局部高温点积累。

2.2 USB D+/D-与Type-C角色设计里的两个坑

很多入门工程师第一次画USB设备，容易忽略D+/D-和Type-C的CC引脚。按照USB 2.0规范，设备端的D+或D-上要有一个1.5k欧姆的上拉电阻，用来向主机宣告自己是全速设备（D+上拉）还是低速设备（D-上拉）。但CH398这类高速设备，芯片内部已经集成了D+上拉和终端匹配电阻，外部不要再乱加并联电容，否则会影响信号眼图。

有朋友问过“USB的CC引脚有一个5.1k下拉，那怎么切换到主机模式”，这是个典型混淆。Type-C里的CC1/CC2下拉到地5.1k欧姆，表示这颗芯片默认身份是UFP，也就是设备模式（Device），插到电脑上时电脑作为DFP提供5V电源，设备回答CC下拉信号握手。如果想让板子当主机去接U盘或者手机，CC上必须改成上拉电阻，而不是下拉。一个USB转网卡是纯粹的设备，CC保持5.1k下拉是对的。至于双角色切换，需要额外加DRP控制芯片或者用MCU动态切换上拉/下拉电阻，不能用简单固定电阻解决。

D+/D-上面到底要放多大电容这个问题，我在网上看到过不少回答，容易把新手带偏。D+/D-差分本来就是90欧姆阻抗的传输线，不需要额外并联电容去“滤波”，真正要做的是控制走线阻抗和寄生电容。如果要加ESD防护，务必选择寄生电容小于0.5pF的TVS管，并尽量靠近连接器放置，否则高速信号的眼图会被电容拉跨，出现USB枚举失败或者降速到USB 1.1的怪问题。

2.3 测试平台的搭建

为了公平对比，我搭了两套独立的上位机测试平台，避免两块网卡在同一个系统里互相抢资源。

测试主机配置：

• CPU：Intel i5，内存16GB
• 系统盘：NVMe SSD
• 系统：Windows 10 22H2、Ubuntu 22.04 LTS双启动
• 被测网卡：CH398测试板、RTL8153B参考板各一块
• 远端对测主机：千兆网口台式机，系统Ubuntu 22.04
• 连接方式：六类屏蔽网线直连交换机，避免无线干扰

Windows下安装好对应驱动后，通过Get-NetAdapter命令确认网卡枚举状态，Linux下用dmesg | grep -i usb和ethtool eth0检查链路协商结果。性能压测工具用iperf3，丢包和时延用ping统计，USB包层面用Wireshark加USBPcap做抓包分析。这套环境基本覆盖了从物理层到协议层、再到应用层吞吐的完整评测链路。

3. USB协议层实测：枚举、抓包和驱动兼容

3.1 枚举过程与描述符检查

CH398插上Windows后，设备管理器里第一眼看到的是“USB Composite Device”，然后枚举出“USB Ethernet Adapter”节点。这一点跟RTL8153的枚举结构非常接近，都是通过一个复合设备挂Ethernet控制接口和以太网数据接口。

我手动看了设备描述符，关键信息如下：

• bcdUSB：0x0320，表示USB 3.2协议
• bDeviceClass：0x00，表示类型在接口描述符中定义
• idVendor：按芯片厂商预设值
• idProduct：CH398相关PID，具体数值这里不贴，量产前厂家允许自定义
• bNumConfigurations：1

用USBlyzer检查配置描述符时，能看到标准的CDC类结构，控制接口使用CDC ECM或者NCM模型，数据接口使用批量传输端点。Linux下加载模块后，lsusb -v也能清晰看到接口描述符。整体枚举流程没有出现异常重试、地址分配失败这些问题，说明CH398的USB协议栈实现得比较扎实。

描述符这里有个隐藏知识点：USB设备在上电后默认地址是0，主机通过控制传输向地址0发送GET_DESCRIPTOR请求读取设备描述符的前8个字节，然后发送SET_ADDRESS分配新的地址，再完整读取所有描述符。如果中间任何一步超时，主机就会报“USB设备描述符请求失败”。CH398在工程样阶段就能稳定过这一整套流程，说明底层固件没有大问题。

3.2 USB抓包验证关键节点

为了看得更细，我用Wireshark + USBPcap在Windows下抓了CH398从插入到枚举完成的完整USB包。抓包结果能清楚看到以下几个关键节点：

1. 设备插入，主机检测到D+上拉，产生reset
2. 主机向地址0发送GET_DESCRIPTOR(Device)
3. 设备返回18字节设备描述符
4. 主机设置地址为1，设备返回ACK
5. 主机再次GET_DESCRIPTOR(Device)确认新地址
6. 主机读取配置描述符集合
7. 主机发送SET_CONFIGURATION(1)，设备进入配置状态

这个过程的packet序列跟标准USB教科书完全一致，没有多余的bus reset或者超时重传。我还对比了同一主机上RTL8153的抓包结果，两者在控制传输阶段的行为几乎一样，只是VID/PID和厂商字符串不同。这说明CH398在USB协议层确实下了功夫，不是简单拿一个USB转串口芯片改个名字硬上。

批量传输阶段我也看了。数据从主机到网卡的发送端点用的是bulk OUT，网卡到主机的接收端点是bulk IN，端点大小都是1024字节，符合USB 3.0规范对bulk端点的配置。在iperf3跑满速的时候抓包，可以看到端点处于BUSY状态，事务处理没有出现NAK风暴，说明内部FIFO和USB带宽调度配合得不错。

3.3 驱动兼容性实测

驱动兼容性单独说，因为这是国产替代最容易被卡住的地方。

• Windows 10/11：CH398官方提供自己的数字签名驱动包，安装后设备名称显示为厂商名加型号。我测试了把驱动卸载后再插拔，系统能自动通过Windows Update找到兼容驱动，说明驱动包inf已经做了WHQL兼容。另外我也试过强行加载RTL8153的inbox驱动，结果是设备能识别，但网络属性里看不到任何有效链路状态，说明“寄存器级兼容”不等于100%驱动混用，量产阶段还是应该用官方自带的签名驱动，不要自作聪明去共用瑞昱的驱动文件。
• Ubuntu 22.04：Linux内核里有r8152模块，它匹配的是RTL8153的VID/PID。CH398因为没有使用瑞昱的VID/PID，直接插上时r8152不会自动绑定。官方给的方案是加载自带驱动源码编译的模块，或者用modprobe参数把设备和r8152绑定。我在内核5.15上实测，手动绑定后网口能正常up，ethtool显示1000baseT全双工，吞吐也正常。这条路能走通，但度有点高。
• Android（Type-C接口）：部分Android设备支持外接USB网卡，CH398的CDC NCM接口被系统识别为以太网设备，能够直接获得IP。这个场景我同事在平板上验证过，免驱，比较省心。

需要提醒的是，国产芯片在系统驱动的“最后一公里”上，永远不要只看手册上写的“兼容”，必须在自己目标系统上实际装一遍。尤其是Windows签名驱动，工程样阶段可能没有签名，需要在高级启动模式下禁用驱动强制签名才能安装，量产样阶段再让原厂提供微软签名的正式驱动。

4. 网络性能实测数据

4.1 千兆满速测试

性能测试是大家最关心的环节。两台主机通过千兆交换机连接，CH398测试板在Ubuntu下用iperf3发起TCP传输。

实测数据如下：

千兆以太网的线速理论值受限于TCP/IP和以太网帧头开销，实际最高就在940Mbps附近。CH398能跑到936Mbps以上，说明USB链路没有成为瓶颈，芯片内部的DMA搬运效率达到了应有的水平。在Windows下的iperf3结果也接近，没有再出现桥接或驱动层的额外性能损耗。

64字节小包是很多人忽略的测试项。我用iperf3 -u -b 100M -l 64跑小包UDP，CH398大约能维持120kpps的接收速率，RTL8153B稍微高一点到150kpps上下。这个差异对普通办公和视频流媒体没任何影响，但如果你的设备要承担高频小包采集或者工控协议转发，就需要考虑这个差距。我理解原因是CH398的收包中断合并策略跟RTL8153B不同，后续固件版本可能优化。

4.2 USB 2.0模式下的降级表现

很多实际使用场景里，用户会把USB转千兆网卡插在USB 2.0口上，比如老笔记本、扩展坞的USB 2.0端口。USB 2.0的理论带宽只有480Mbps，实际批量传输能拿到的净带宽大约在300到400Mbps之间。

在USB 2.0模式下，CH398的iperf3 TCP下载大约是352Mbps，RTL8153B大约380Mbps，两者的差距主要来自USB微帧调度效率和端点FIFO大小。352Mbps对百兆宽带来说绰绰有余，但如果你把USB 2.0口插上千兆网卡去访问内网NAS，这个速度会让传输大文件变得煎熬。选型时如果明知道用户大概率插在USB 2.0环境，千兆芯片的这部分性能就必须纳入考量。

4.3 时延、功耗与发热

时延方面，ping网关地址的RTT，CH398平均在0.3ms到0.5ms，RTL8153B在0.2ms到0.4ms，都属于正常范围。使用TCP_NODELAY跑小包请求时，两者都稳定在1ms以内。这个量级对远程桌面、在线视频会议感知不到差别。

功耗和发热是便携设备比较在意的点。用USB电流表测试，空闲状态下CH398约0.9W，满载千兆传输约1.8W；RTL8153B空闲约0.8W，满载约1.6W。差的不多，但满载时芯片表面温度有区别：CH398在25度室温下测到约62度，RTL8153B约55度。对于金属外壳扩展坞来说，62度还在可接受范围，如果是塑料密闭外壳，长时间满载就要考虑增加散热过孔或者贴导热垫，避免芯片过热触发降速或者断链。

4.4 长时间稳定性与恢复测试

网卡最怕的不是性能低，而是用着用着掉线。我做了48小时连续传输测试，CH398在千兆TCP连续传大文件的情况下没有出现一次链路断开，网络接口的RX/TX错误计数几乎没有增长。期间我故意把交换机断电再恢复，CH398能在链路恢复后自动重新协商到千兆，没有出现卡死在100M或者协商失败的情况。

还测试了Windows休眠唤醒后的行为。默认状态下，系统可能允许USB设备休眠以省电，唤醒后CH398有概率出现设备管理器里的错误码10或者网络连接“未识别的网络”。解决办法是到设备管理器里找到网卡，在电源管理选项卡中取消勾选“允许计算机关闭此设备以节约电源”，同时把USB根集线器的选择性暂停关掉。RTL8153B在相同设置下也有类似表现，这不是CH398独有的问题，但国产芯片的技术支持资料里这块写得比较简单，容易被忽视。

5. 常见问题与排查技巧实录

5.1 USB设备描述符请求失败

这个报错在Windows设备管理器里非常常见，出现的原因五花八门，我在CH398上实际排查过三次，总结下来优先级从高到低是：

• 供电不足：USB 3.0口最大能提供900mA，但部分前置面板或者老化台式机接口只能到500mA。CH398满载需要约360mA，加上周边电路如果超过供电能力，枚举就会失败。解决：换一个USB口，或者用带辅助供电的HUB。
• D+/D-信号质量：ESD保护管寄生电容太大，或者Type-C母座走线过长，导致高速信号眼图闭合。解决：拿掉ESD管测试，或改用低电容TVS。
• 晶振起振异常：25MHz晶振如果负载电容选错，芯片内部时钟频率偏移超过规格，上游USB PHY无法锁定，就会表现为描述符请求失败。解决：用示波器测晶振波形，或者换一颗标称负载电容匹配的晶振。

还有一个低级错误是芯片焊接虚焊，尤其是QFN48底部焊盘没有充分过锡，导致芯片上电后部分引脚没接通。这种情况设备管理器可能显示“未知USB设备（设备描述符请求失败）”，但用万用表量晶体和电源又都正常，因为部分内部模块没工作。焊接问题用热风枪补焊一次就能确认。

5.2 网速跑不满和网卡掉线

如果CH398在Windows下只能跑到100Mbps，第一步先看设备和交换机的协商结果：Get-NetAdapter | Select Name, LinkSpeed，或者Linux下ethtool eth0。出现100Mbps协商通常是因为网线劣质或者接触不良，六类线跑千兆的要求是四对线芯全部导通，很多五类线只有两对线可用，就只能协商到100M。

排除物理线路后，如果仍只有100M，检查网络变压器引脚方向是否接反，尤其是中心抽头。CH398参考设计里TX和RX的极性跟主芯片有对应关系，接反会出现链路能通但速度上不去的表现。

满载过程中掉线，优先怀疑温度。用红外测温枪测芯片表面，如果超过80度，就要考虑散热设计。我在测试中发现CH398的降级保护逻辑比较“温柔”，温度刚过阈值会先降低链路速率而不是直接断链，所以看到“速率偶尔掉到100M又恢复”的现象，大概率是热问题。

5.3 驱动签名、自定义VID/PID与多网卡共存

自定义VID/PID是OEM项目常有的需求。CH398允许通过配置工具修改USB Vendor ID和Product ID，这对品牌产品来说很有必要，可以避免跟公模驱动和第三方软件冲突。但改完VID/PID后，Windows下必须用对应VID/PID重新生成并签名inf文件，如果直接沿用公版驱动，插上后系统会提示驱动不匹配。

多网卡共存的问题也提一下。有些设备主板上本来有有线网卡，又外接CH398 USB网卡，系统里会出现两个网关路由，导致访问外网走错网卡。解决方法是设置接口跃点优先级：Windows的Set-NetIPInterface -InterfaceMetric把USB网卡的metric调低，或者直接禁用主板网卡，让USB网卡作为主网卡。这不是芯片问题，但国产方案的技术支持经常被问到这个，说明实际使用中确实常见。

5.4 固件升级与“变砖”恢复

CH398支持通过USB接口升级固件，升级工具原厂会提供。工程样阶段我刷过一次新固件，升级过程中拔掉USB线会导致设备无响应，重新插入后系统完全无法识别。好在芯片支持BootROM引导模式，通过硬件引脚进入烧录模式重新写入即可恢复。量产时如果固件放在外部Flash，务必要在产测里增加固件版本校验步骤，防止升级失败的产品流到用户手里。

6. 选型结论与实践建议

6.1 适合用CH398的场景

我自己的判断标准很简单：如果你的项目主赛道是工业设备、商业终端、消费类配件，对成本敏感，对供货稳定性要求高，同时又不想在软件适配上面花太多精力，CH398可以作为RTL8153的一级替代方案。特别是扩展坞、视频会议一体机、嵌入式开发板、工控机配件这类产品，linux和Android驱动跟着内核走，Windows驱动官方提供签名，基本能做到无缝切换。

成本方面，CH398目前的样品报价比RTL8153B低一截，量产后差距会更明显。对于一年几万片的出货量，省下来的成本非常可观，这也是项目立项做国产替代最直接的动力。

6.2 仍然需要谨慎评估的场景

如果你正在做的是超低功耗的便携设备，RTL8153B仍然有优势，空闲和满载功耗都更低一点。如果应用场景对64字节小包处理能力的要求极高，边缘工业网关、金融交易终端这类，我建议量产前要拿真实的业务报文做压测，不要只看iperf3的TCP大包成绩。CH398的小包转发能力目前跟RTL8153B有差距，但差距不算大，后续固件有机会补齐。

另外，如果你的产品面向海外市场，设备的驱动认证和WHQL要求会更严格。CH398的海外认证案例相对RTL8153毕竟少，苹果生态的兼容性测试数据也还不够充分，这些需要跟原厂要到认证报告再做决定。

6.3 除了芯片本身，还要看原厂支持能力

选国产芯片，我越来越觉得技术规格只占一半，另一半看原厂支持力度。CH398整个测试过程中，原厂工程师能直接拉到微信群里改寄存器配置，遇到驱动问题能当天给测试固件。这种贴身支持是RTL8153这种全球大厂给不了的。尤其在国内做量产项目，一个能随叫随到的技术支持，可能比芯片便宜的那几块钱更值钱。

我还注意到CH398原厂会提供完整的量产工具链，包括产测软件、固件升级工具、自定义VID/PID配置工具，这些细节在选型评估时往往被忽视，真到了批量生产阶段才发现工具不顺手，返工成本极高。

最后说点个人体会。测完这两个芯片，我的结论是：USB转千兆网卡的国产替代已经过了“能不能用”的阶段，进入“怎么选”的阶段。CH398这种寄存器兼容方案，最大的价值不是硬件参数上全面反超，而是让老项目用最小改动完成供应链转移。如果你手里现在就有用RTL8153的产品，建议找原厂要样品，按我上面那套流程跑一遍，用实际数据说话，比看任何评测都靠谱。实测过程中我自己踩得最深的一个坑就是：别急着焊正式板，先用转接板在目标系统上把驱动和枚举这关过了，再动PCB设计，顺序反了，后面每一轮改板都是成本。