企业官网建设流程全解析

把家里的宽带从百兆提到千兆之后，第一件事一定是测速。我身边不少朋友跑完测速软件都会发来同一个问题：为什么明明显示链路是1.0Gbps，下载文件最快也就一百一十几MB/s，说好的“1000MB/s”去哪儿了？这个误会的根源有两个，第一是单位搞错了，运营商说的“千兆”单位是Mbps，也就是每秒百万比特，不是每秒百万字节；第二是就算把单位换对，“除以8”得到的125MB/s依然只是理论毛算，真正跑到的实际传输速率要因为协议开销、物理编码和中间设备的处理能力再打一个折扣。这篇博文把百兆、千兆、万兆背后的计算逻辑完整拆一遍，顺便给出可参考的实际速率区间，适合正在折腾宽带、有组网需求，或者打算上万兆的读者收藏。

1. 先从单位说起：Mbps、MB/s和线速不是一回事

1.1 大B和小b，一字之差差出8倍

网络工程师天天说的带宽，单位是bit/s（比特每秒），运营商套餐里写的100M、1000M、10000M，指的都是Mbps（Megabits per second）。而电脑系统和下载工具里显示的速度，绝大多数是MB/s或MiB/s，指的是Byte/s（字节每秒）。一个字节等于8个比特，所以单纯从单位换算看：

• 100Mbps ÷ 8 = 12.5MB/s
• 1000Mbps ÷ 8 = 125MB/s
• 10000Mbps ÷ 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以上；千兆链路能到110～118MB/s；万兆链路能到1.05～1.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.85～0.95）。其中环境系数包括CPU、磁盘、网卡驱动、中间设备转发能力、对端处理能力、并发连接数等。根据不同场景取值：

• 极限理论值：环境系数取1.0，用于前面小节的计算。
• 正常局域网良好环境：环境系数取0.9～0.97，千兆可以跑110～118MB/s。
• 一般家用/办公环境（经路由器NAT、多设备共享）：0.8～0.9，千兆通常900Mbps左右，即112MB/s左右。
• 如果走了无线，还可以再掉1/3甚至更多，但这不是本次讨论范围。

这个公式以后排障可以直接套用。只要看到结果在这个区间内，链路就是健康的，不用盲目怀疑设备。

3. 百兆/千兆/万兆实际传输速率到底是多少

3.1 百兆：11MB/s是及格线

百兆网络（100BASE-TX）是最基础的以太网。按前面公式算，TCP极限约11.9MB/s，实际文件拷贝中，扣除系统调度和磁盘影响，能稳定在10.5～11.5MB/s就非常正常。如果是经过家用路由器上网测速，运营商侧进来的速度通常在85～95Mbps，即10.6～11.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多线程测，通常能跑到940～980Mbps，也就是117～122MB/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.0～9.5Gbps。文件拷贝用SMB/NFS，大文件顺序读写能到1.05～1.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 附上一张参考速查表

注意，这个表里的“大文件拷贝参考值”是大概范围，因为SMB/NFS等协议开销不同、缓存不同、磁盘性能不同，实际值波动很大。下一章会展开讲为什么文件拷贝经常低于网络吞吐。

4. 为什么文件拷贝速度远低于网络速率

4.1 磁盘是第一瓶颈

网络测速达标、文件拷贝却慢，绝大多数情况问题出在硬盘。机械硬盘的顺序写速度大约100～200MB/s，这意味着一块普通HDD在千兆网络中已经接近极限；如果是小文件随机写，IOPS不到100，速度会跌破1MB/s。SATA SSD顺序写约400～550MB/s，千兆网络（约118MB/s）反而不会拖累它；NVMe SSD顺序写通常1GB/s以上，才勉强配得上万兆网络。测试万兆短板的正确姿势是用内存盘（RAMDisk）或高速NVMe，否则网络先达标、磁盘跟不上，得出“某宝网卡是垃圾”的结论就误判了。

所以在评估网络速率之前，要先分别验证磁盘的单机读写能力。Linux下可以用dd if=/dev/zero of=/tmp/testfile bs=1M count=10240 conv=fdatasync，Windows下可以用CrystalDiskMark。磁盘如果能跑到500MB/s以上，再谈怎么调网络。

4.2 小文件问题：被协议轮询拖垮

如果拷的是几万个几KB大小的图片或日志，哪怕总数据量只有几百MB，速度也会很难看。原因有两个：一是每个文件都需要独立的创建、元数据写入和关闭操作，文件系统元数据开销大；二是网络上的每个小文件请求都要经过完整的协议交互，SMB/NFS下RPC往返次数极多，即使网络延迟只有0.2ms，一万个小文件累积的等待时间也相当可观。跑大文件测速和大文件实际应用之间没有可比性，这也是“为什么我拷照片只有20MB/s”最常见的答案。

想直观验证这一点，可以生成一个10GB的单一大文件和一个包含一万个1KB小文件的目录，分别通过SMB拷贝，前者可能轻松跑满千兆，后者往往连十分之一都到不了。这不是网速问题，是文件系统加协议交互的问题。

4.3 网卡驱动的隐藏开关

现代服务器网卡默认会开启TSO（TCP Segmentation Offload）、GRO（Generic Receive Offload）、RSS（Receive 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 bs=1M count=10240），在共享文件夹里拷贝，观察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窗口这些参数保持一致，否则得出的数字根本没有可比性。