把家里的宽带从百兆提到千兆之后第一件事一定是测速。我身边不少朋友跑完测速软件都会发来同一个问题为什么明明显示链路是1.0Gbps下载文件最快也就一百一十几MB/s说好的“1000MB/s”去哪儿了这个误会的根源有两个第一是单位搞错了运营商说的“千兆”单位是Mbps也就是每秒百万比特不是每秒百万字节第二是就算把单位换对“除以8”得到的125MB/s依然只是理论毛算真正跑到的实际传输速率要因为协议开销、物理编码和中间设备的处理能力再打一个折扣。这篇博文把百兆、千兆、万兆背后的计算逻辑完整拆一遍顺便给出可参考的实际速率区间适合正在折腾宽带、有组网需求或者打算上万兆的读者收藏。1. 先从单位说起Mbps、MB/s和线速不是一回事1.1 大B和小b一字之差差出8倍网络工程师天天说的带宽单位是bit/s比特每秒运营商套餐里写的100M、1000M、10000M指的都是MbpsMegabits per second。而电脑系统和下载工具里显示的速度绝大多数是MB/s或MiB/s指的是Byte/s字节每秒。一个字节等于8个比特所以单纯从单位换算看100Mbps ÷ 8 12.5MB/s1000Mbps ÷ 8 125MB/s10000Mbps ÷ 8 1250MB/s这几乎是“入门第一课”但实际沟通中踩坑的人仍然很多。比如有人买了千兆交换机拿测速工具一看“94MB/s”第一反应是设备缩水其实94MB/s换算过来是752Mbps对于千兆环境来说完全正常。这个“8倍”只是起点后面还有更多隐藏损耗。1.2 线速、MAC速率和应用层吞吐的区别搞网络的人常听到“线速转发”这个概念。线速Wire Speed的意思是接口在物理层能承载的最快速率百兆线速就是100Mbps千兆线速就是1000Mbps万兆线速就是10Gbps。但线速不代表“全是用户数据”线速包含的是时钟、编码、同步信息、帧间隙、前导码、帧头帧尾以及内层协议头。真正落到我们应用层能用的部分叫“吞吐量”Throughput英文里有时专门叫Goodput。线速和吞吐量之间的差值就是协议开销。很多测试工具显示的速率已经是吞吐量比如迅雷显示的12MB/s是应用层好数据而不是物理层信号速率。标题里说的“实际传输速率”实际上指的就是吞吐量。因此“百兆宽带是不是能跑满100Mbps”这个问题答案是永远不可能因为100Mbps是物理层速率应用层相除下来能到90%出头已经很优秀。1.3 一个可以直接使用的估算原则在具体计算之前先给出一句经验结论在任何有线以太网链路上应用层TCP吞吐量大约是链路标称速率的85%95%。这个区间是千兆、万兆网络用iperf3实测的常见范围。比如百兆链路好的局域网能到11MB/s以上千兆链路能到110118MB/s万兆链路能到1.051.18GB/s。为什么不是100%接下来把账算清楚。2. 速率损耗从哪来以太网帧、TCP/IP头和物理编码2.1 以太网帧本身有多余开销标准以太网帧的最小结构为目标MAC地址6字节、源MAC地址6字节、类型/长度2字节、用户数据通常为IPv4包最大1500字节、帧校验FCS 4字节这已经1518字节。而在传输时每个帧之前还有8字节前导码Preamble SFD帧与帧之间还有至少12字节的帧间隙IPG。所以送到物理线上的总字节数最多为1538字节其中对上层真正有用的只有1500字节。由此可以算出链路层的最大载荷效率1500 ÷ 1538 ≈ 97.5%。这意味着单是二层包裹就已经吃掉线速2.5%左右的带宽。这2.5%和普通用户直觉里的“损耗”不太一样它不取决于路由器贵不贵、运营商良不良心而是以太网协议定义里的固定开销。无论网络设备多高端只要采用标准以太网帧这部分损耗就必然存在。2.2 TCP/IP协议头继续吃掉有效载荷互联网传输最常见的组合是IPv4 TCP。一个标准IPv4头部通常是20字节TCP头部同样是20字节加起来40字节。以太网帧最大能承载1500字节所以一个没有额外选项的TCP报文真正携带的应用数据最多是1500 - 20 - 20 1460字节。结合前面1538字节的线上总帧长来算应用层有效载荷1460字节占全部线上数据的比例是 1460 ÷ 1538 ≈ 94.9%。把这个比例乘到物理线速上就是理论上TCP吞吐能到的最高值百兆100Mbps × 94.9% ≈ 94.9Mbps ≈ 11.9MB/s千兆1000Mbps × 94.9% ≈ 949Mbps ≈ 118.6MB/s万兆10000Mbps × 94.9% ≈ 9.49Gbps ≈ 1186MB/s ≈ 1.16GB/s不加上任何“垃圾环境因素”账面上的硬件极限已经出来了。这是所有人都应该先记住的一组数。2.3 物理层编码从信令速率里挤掉的开销以太网在物理层并不是直接用电平代表数据流的。为了保证同步和抗干扰100BASE-TX采用4B/5B编码把4比特数据变成5比特符号再经过MLT-3调制后放在线缆上所以百兆电口的实际信令速率是125Mbps千兆光纤1000BASE-X采用8B/10B编码物理信令速率是1.25Gbps万兆接口10GBASE-R采用64B/66B编码物理信令速率是10.3125Gbps千兆电口1000BASE-T则采用PAM5调制用四对线并行传输。很多文章直接拿“1.25Gbps ÷ 8 156MB/s”来算千兆最高速度那是把编码前的线速当成了可用带宽。实际上网卡状态里显示的1.0Gbps已经是MAC层速率也就是已经扣掉编码开销后的结果。所以上一节的计算不用再重复扣除编码损耗但它能解释一个迷惑现象用光功率计或线路测试仪去看物理信令会发现实际信号速率比协议分析仪统计的数据速率高出一截这正是编码冗余在起作用。2.4 握手、流控和双工模式带来的“软开销”除了帧结构和编码这些硬开销实际链路还受传输协议本身行为影响。TCP需要ACK确认一个数据包送达后要等确认高速链路上如果时延太高、缓存窗口太小吞吐率会明显下降。交换机或路由器如果开启了流控IEEE 802.3x当缓冲队列满时会发送PAUSE帧这帧本身也占用带宽同时暂停发送端整体速率自然打折。半双工网络的冲突回退机制在现代全双工链路中已不存在但仍然有大量老旧设备、或接触不良时协商成百兆半双工的情况这时速度可能连标称的一半都达不到。后面排障部分会介绍如何发现这类问题。2.5 一个计算模型把损耗公式化把上面内容汇总成公式实际传输速率Mbps ≈ 标称线速 × 二层帧有效载荷率约0.975 × TCP/IP有效载荷率约0.949 × 环境系数0.850.95。其中环境系数包括CPU、磁盘、网卡驱动、中间设备转发能力、对端处理能力、并发连接数等。根据不同场景取值极限理论值环境系数取1.0用于前面小节的计算。正常局域网良好环境环境系数取0.90.97千兆可以跑110118MB/s。一般家用/办公环境经路由器NAT、多设备共享0.80.9千兆通常900Mbps左右即112MB/s左右。如果走了无线还可以再掉1/3甚至更多但这不是本次讨论范围。这个公式以后排障可以直接套用。只要看到结果在这个区间内链路就是健康的不用盲目怀疑设备。3. 百兆/千兆/万兆实际传输速率到底是多少3.1 百兆11MB/s是及格线百兆网络100BASE-TX是最基础的以太网。按前面公式算TCP极限约11.9MB/s实际文件拷贝中扣除系统调度和磁盘影响能稳定在10.511.5MB/s就非常正常。如果是经过家用路由器上网测速运营商侧进来的速度通常在8595Mbps即10.611.9MB/s这是公网环境中常见速率。只跑10MB/s以上就不算差。如果下载只有几MB/s先别怪运营商先考虑是不是路由器性能、多设备同时使用、或者无线信号问题。注意一点很多人用Wi-Fi连接千兆光猫看到的协商速率可能是“866Mbps”或“1200Mbps”但因为有无线半双工和信道竞争实际测速往往比千兆有线环境低30%50%。百兆宽带用无线还可能凑合跑满千兆宽带想靠无线跑满基本要看设备和距离。3.2 千兆118MB/s是天花板110MB/s是优秀千兆有线链路1000BASE-T或1000BASE-X是目前主流。理论TCP极限约118.6MB/s。用两台配置稍好的电脑直连网卡开默认设置用iperf3多线程测通常能跑到940980Mbps也就是117122MB/s。但文件拷贝一般稳定在110MB/s左右因为SMB/NFS等文件共享协议自身还有额外的会话管理开销。如果发现千兆速率只能跑到800Mbps以下就需要认真排查了。常见原因包括网卡协商成了百兆、中间交换机端口是百兆、网线只有四芯通路、或者路由器开启了QoS/流量监控。千兆网络的问题排查相对容易因为大多数瓶颈都集中在物理链路和中间设备。3.3 万兆1GB/s上下是常态但“能跑到”和“能稳定跑”是两码事万兆10GBASE-R等的应用层TCP极限约9.49Gbps换算约1.16GB/s。实测时在两台服务器上用高性能PCIe网卡、开启RSS多队列和TSO/GRO卸载、配合巨型帧MTU 9000端口速率能到9.8Gbps左右如果不开巨型帧用默认MTU 1500一般在9.09.5Gbps。文件拷贝用SMB/NFS大文件顺序读写能到1.051.15GB/s已经是很好的成绩。万兆和千兆的区别在于带宽高了10倍系统开销也更容易触发瓶颈。比如PCIe带宽一条PCIe 3.0 x1只有约8Gbps裸带宽约985MB/s跑万兆网卡至少需要PCIe 3.0 x4或PCIe 4.0 x2/x4否则网卡本身先掉速CPU单核处理能力、内存带宽、中断处理都会成为瓶颈。很多玩家组了两三千元的万兆方案结果因为主板PCIe通道不足只能跑出700MB/s这就是典型的接口瓶颈。3.4 附上一张参考速查表链路标称字节换算二层有效率TCP理论极限常见实际区间大文件拷贝参考值100Mbps12.5MB/s97.5%11.9MB/s1011.8MB/s1011MB/s1000Mbps125MB/s97.5%118.6MB/s110118MB/s100115MB/s10000Mbps1250MB/s97.5%1186MB/s10501150MB/s9001100MB/s注意这个表里的“大文件拷贝参考值”是大概范围因为SMB/NFS等协议开销不同、缓存不同、磁盘性能不同实际值波动很大。下一章会展开讲为什么文件拷贝经常低于网络吞吐。4. 为什么文件拷贝速度远低于网络速率4.1 磁盘是第一瓶颈网络测速达标、文件拷贝却慢绝大多数情况问题出在硬盘。机械硬盘的顺序写速度大约100200MB/s这意味着一块普通HDD在千兆网络中已经接近极限如果是小文件随机写IOPS不到100速度会跌破1MB/s。SATA SSD顺序写约400550MB/s千兆网络约118MB/s反而不会拖累它NVMe SSD顺序写通常1GB/s以上才勉强配得上万兆网络。测试万兆短板的正确姿势是用内存盘RAMDisk或高速NVMe否则网络先达标、磁盘跟不上得出“某宝网卡是垃圾”的结论就误判了。所以在评估网络速率之前要先分别验证磁盘的单机读写能力。Linux下可以用dd if/dev/zero of/tmp/testfile bs1M count10240 convfdatasyncWindows下可以用CrystalDiskMark。磁盘如果能跑到500MB/s以上再谈怎么调网络。4.2 小文件问题被协议轮询拖垮如果拷的是几万个几KB大小的图片或日志哪怕总数据量只有几百MB速度也会很难看。原因有两个一是每个文件都需要独立的创建、元数据写入和关闭操作文件系统元数据开销大二是网络上的每个小文件请求都要经过完整的协议交互SMB/NFS下RPC往返次数极多即使网络延迟只有0.2ms一万个小文件累积的等待时间也相当可观。跑大文件测速和大文件实际应用之间没有可比性这也是“为什么我拷照片只有20MB/s”最常见的答案。想直观验证这一点可以生成一个10GB的单一大文件和一个包含一万个1KB小文件的目录分别通过SMB拷贝前者可能轻松跑满千兆后者往往连十分之一都到不了。这不是网速问题是文件系统加协议交互的问题。4.3 网卡驱动的隐藏开关现代服务器网卡默认会开启TSOTCP Segmentation Offload、GROGeneric Receive Offload、RSSReceive Side Scaling等卸载功能。TSO和GRO让CPU不用逐包处理数据直接交给网卡硬件做大包拆分/合并RSS则把不同连接绑定到不同CPU队列多核分摊中断。如果这些功能被关闭跑满万兆时CPU会持续飙高吞吐上不去。还有MTU设置。默认标准以太网MTU是1500字节如果两端和多级交换机都支持巨型帧Jumbo Frame万兆链路建议把MTU调到9000。为什么因为帧更长帧头、前导码和IPG这些固定开销被分摊到更多数据上二层有效载荷率从94.9%提升到接近98.9%万兆网络可多出三四百Mbps的吞吐。这个优化在百兆千兆也有用但效果不如万兆明显。4.4 交换机、路由器转发性能不可忽略如果链路经过路由器NAT硬件转发能力就非常关键。很多家用路由器标称“千兆端口”但开启流量管理、QoS、家长控制或者一些安全过滤后转发全靠CPU的慢路径吞吐率会从900Mbps跌到两三百Mbps。软路由或者家用Mini PC跑的方案也有类似问题如果CPU主频低、单核弱同样可能跑不满万兆。交换机层数越多、广播域越大处理效率越不稳定。测试时最好用二层直连先排除三层设备影响。判断NAT设备转发性能的最直接方法把两台电脑接在同一台交换机/路由器下走内网IP互传速度不降就说明二层链路没问题如果通过路由器上公网或跨VLAN降速再往路由器性能上查。4.5 时延、丢包与TCP窗口的带宽时延积一个容易被忽略但很重要的概念是带宽时延积BDP。TCP能同时“在飞”的数据量受窗口大小限制最大吞吐 ≈ 窗口大小 ÷ RTT往返延迟。窗口默认在64KB的时候在一条RTT为50ms的链路上最大吞吐只有约10Mbps就算物理带宽是千兆也跑不满。现代系统普遍启用TCP窗口缩放Window Scale后可以自动调大窗口但高时延链路上仍然需要调优。局域网RTT通常低于1ms窗口影响不大但公网远程传输时延迟和丢包会大幅降低实际速度这部分并非设备和线材能解决。因此不要在远程服务器上用iperf3跨地域测试来衡量本机带宽更可靠的方式是局域网直连测试。远程测速看的不是带宽是RTT和丢包率。4.6 线材与物理链路质量千兆以上对线缆质量极其敏感。百兆只需要1、2、3、6四根芯线就能建立连接而千兆必须8根芯全部连通且线序正确如果网线只打了4芯网卡会协商成100Mbps。万兆对线缆要求更高Cat5e在短距离下勉强能跑万兆正规方案建议Cat6A或更高屏蔽层、水晶头接触、跳线长度都可能造成协商失败或大量CRC错误。物理链路质量不好最典型症状是网卡和交换机协商速率正常但速度偶尔掉到很低有时重插网线又能恢复——这通常不是软件问题而是接触不良或线序错误。5. 实测方法与排障顺序5.1 用iperf3做标准吞吐测试测局域网点到点吞吐首选工具是iperf3。服务端运行iperf3 -s客户端运行iperf3 -c 服务器IP -P 4 -t 20。-P 4是4个并发流目的是让多核CPU都能参与避免单核瓶颈误报-t 20表示测20秒。如果单线程和多线程结果差异极大说明网卡RSS或CPU多核处理有问题。测试时不要开下载任务、云同步、在线视频等占带宽的程序。要注意iperf3默认单线程只能跑一个TCP连接这在万兆测试中很难跑满用-P开多线程是惯例。另外服务端和客户端的版本最好一致否则某些功能不兼容会导致速率虚低。如果客户端显示结果只有标称的80%都不到先检查MTU、流控、网卡协商状态再考虑换线。5.2 文件拷贝测速的正确姿势文件拷贝是最贴近日常经验的测速方法但结果容易误导。正确做法是准备一个至少10GB的单一大文件Linux下可以dd if/dev/zero of/tmp/test.bin bs1M count10240在共享文件夹里拷贝观察Windows资源管理器或rsync的传输速度。如果目标是验证网络上限建议先把测试文件放在内存盘或NVMe上不要在机械盘上测否则磁盘会成为瓶颈。Windows下把MB/s换算成Mbps很简单乘以8即可。看到“112MB/s”其实就是896Mbps这对千兆来说属于正常偏高表现。另外Windows使用SMB传输时多线程效果往往不如预期因为SMB 3.0的多通道需要两个网卡或RDMA支持。如果测试结果不稳定把杀毒软件实时监控临时关掉再试文件过滤驱动的开销对速度影响很大。5.3 常见异常速率排查顺序如果网卡协商速度显示100Mbps而非1000Mbps先查网线是否8芯全通、水晶头是否压好再查交换机端口和电脑网卡是否只有百兆。如果协商速率正常iperf3只能跑两三百Mbps查网卡驱动、硬件加速是否关闭、交换机是否开了流控或背压。如果iperf3能跑满但文件拷贝只有几十MB/s查磁盘和文件系统换大文件再试。如果对端在不同城市或跨运营商优先看RTT和丢包ping -t IP连续测试丢包超过1%就别指望跑满。如果速度波动大检查链路是否被多条大流量占满、是否有全双工/半双工不匹配用ethtool -S eth0或交换机端口的CRC错误计数辅助判断。5.4 链路协商速度怎么看Windows任务管理器“性能 → 以太网”里能直接看到“链接速度”Linux执行ethtool eth0输出里的Speed字段就是协商结果。如果看到100Mb/s说明链路只协商上百兆通常不是“千兆被人为限制了”而是物理层或配置问题。万兆网卡协商万兆时还要确认交换机和网卡都支持并正确设置了速率和双工自协商参数强行固定速率在某些设备上反而会导致协商失败。写到这里我想把最基础的一点再拎出来强调一下这些计算最大的价值不是让你拿个数字去跟运营商battle而是帮你在排障时快速定位瓶颈。我在实际项目里练出来的习惯是先算理论值、再跑iperf、再跑文件拷贝三步下来基本能判断是线的问题、设备的问题还是存储的问题。如果你刚开始接触这类问题建议先拿自己的电脑和一台直连设备做一次千兆局域网测试把“实际传输速率”和“标称带宽”的关系彻底搞清楚以后再看任何网速不达标的情况都会淡定很多。最后送一个小技巧做任何测速前把MTU、巨型帧、TCP窗口这些参数保持一致否则得出的数字根本没有可比性。
