物理机端口能跑满1Gbps，为什么单线程传大文件只有几Mbps？

网卡显示“1000Mb/s”，多连接测速也能接近千兆，但用一个下载连接传大文件时，速度却只有几Mbps，这两种结果并不矛盾。前者说明某个接口或某组连接具备较高的传输能力，后者反映的是一条具体数据流在完整路径上的实际吞吐；两者测量的对象不同。

单连接传输不仅需要链路有容量，还需要TCP允许足够多的数据持续在途、网络及时返回确认，并且发送程序、接收程序、磁盘和CPU能够连续供数、收数。因此，端口能跑满1Gbps，不等于任意远端、任意协议、任意单连接都能跑满1Gbps。要解释“只有几Mbps”，关键是分清：带宽是否真的不足，还是单连接没有把可用带宽利用起来。

“千兆端口”和“大文件速度”究竟分别说明什么

物理机的网卡速率、服务器可用网络带宽和文件传输速度，是三个相关但不能互换的概念。

即使千兆能力已经通过测试确认，也要看测试是否与文件传输采用相同的端点、方向和路径。服务器向外上传正常，不代表外部向服务器上传同样正常；同机房互传正常，也不代表远距离下载正常。

先排除Mbps与MB/s的单位错觉

网络带宽通常用bit/s表示，文件下载软件常用Byte/s表示。本文按十进制口径计算，1Byte等于8bit：

• 1Gbps等于1000Mbps，理论上对应125MB/s。
• 5Mbps对应0.625MB/s。
• 5MB/s对应40Mbps，并不是5Mbps。

125MB/s只是把线路速率换算成字节速率，尚未扣除链路、IP、TCP等开销。以普通1500字节MTU、低丢包和端点性能充足的环境为例，千兆链路上的TCP有效吞吐常见在900～950Mbps量级，但这不是任何场景都应达到的固定值。

以10GB文件为例，按十进制计算，数据量为10×8×1000＝80000Mb。以5Mbps传输，理论耗时为16000秒，即4小时26分40秒；以1000Mbps传输，理论耗时为80秒。实际耗时还要计入协议开销和速率波动。

“单线程”不一定等于“一条TCP连接”

下载工具中的“单线程”，通常指不拆分文件、不启用多任务下载，但它未必严格等于一个操作系统线程或一条TCP连接。反过来，多线程程序也可能把数据集中在同一条连接上。

分析网络机制时，更准确的对象是单流吞吐：一条TCP连接能够持续传输多少有效数据。多连接下载则把文件分块，通过多条连接并行传输。

这个区别很重要，因为TCP的拥塞控制、接收窗口等状态通常按连接维护。多连接能跑快，可能是多条流共同填满了线路，并不代表其中任意一条流都足够快。

单连接为什么会“有带宽却发不满”

TCP不会因为网卡是千兆，就一直按千兆速率向网络塞数据。发送端必须控制尚未被确认的数据量，既不能超过接收端的承受能力，也不能持续压垮网络。

可以把链路理解为一条运输路线：带宽决定路上每秒能通过多少货物，往返时延决定发送一批货物后，多久才能收到确认。路线容量很大，但同时允许在路上的货物太少，路线依然会空着。

决定在途数据量的两个窗口

TCP发送端主要受到两个窗口约束：

• 拥塞窗口，通常记为cwnd：发送端根据确认、丢包等反馈，判断网络能够承受多少在途数据。
• 接收窗口，通常记为rwnd：接收端告诉发送端，自己当前还有多少接收空间。

实际可发送的在途数据，还要扣除已经发出但尚未确认的部分，并受应用供数、发送缓冲等条件影响。用于理解上限时，可以写成：

单流吞吐上限近似等于：可持续维持的有效在途数据量 ÷ RTT。

RTT是一次数据发送及其确认返回所经历的往返时间。这个关系不是完整的TCP性能预测公式，但能够解释“窗口不足为什么限制远距离传输”。

例如，一条连接的有效在途数据长期只有64KiB，RTT为100ms，那么估算吞吐为：

64×1024×8÷0.1＝5242880bit/s，约5.24Mbps。

此时，即使底层接口是1Gbps，单连接仍可能只跑到几Mbps。原因不是端口不够快，而是发送端在等待确认期间，缺少足够多的在途数据来持续填满链路。

这里的64KiB只是演示参数，不代表现代系统默认只能使用这么大的窗口。支持窗口扩大、缓冲自动调节的系统可以使用更大的窗口，但应用设置、接收端状态和网络反馈仍可能把实际有效窗口压小。

延迟越高，跑满带宽所需的窗口越大

带宽与RTT相乘，得到带宽时延积，通常简称BDP。它表示：为了让链路持续工作，大约需要保持多少数据在途中。

以下按1Gbps目标吞吐估算，不计协议开销：

同样一条千兆链路，在1ms RTT下，只需要较小的在途数据量；到了100ms RTT，想接近千兆，就需要持续维持约12.5MB的数据在途。

因此，高延迟本身不必然意味着低吞吐，但高延迟会提高单连接跑满带宽所需的窗口规模，并放大丢包恢复和应用等待的代价。

丢包会让发送端主动降速

如果只是窗口偏小，扩大有效窗口可能改善吞吐；如果网络持续丢包，发送端通常会降低拥塞窗口，之后再逐步恢复。

长RTT路径上，这个恢复过程更慢：发送端等待反馈的时间更长，窗口增长也要经历更多实际时间。如果窗口还没恢复到足以填满链路，又出现新的丢包，单流就可能长期停留在较低速率。

不同拥塞控制算法的表现并不相同。有些更依赖丢包判断拥塞，有些会结合交付速率和RTT估计。但任何算法都不能把真实容量不足、持续严重丢包或应用主动限速自动消除。

这也解释了一个常见现象：单连接很慢，增加到4条或8条连接后总速率明显上升。多个连接各自维护拥塞状态，聚合在途数据可能更大。不过，多连接也可能增加竞争和队列压力，不能把“连接越多越快”当成普遍规律。

除了窗口，还有哪些因素会把速度压到几Mbps

“只有几Mbps”通常不是由千兆链路上的正常协议开销造成的。从千兆降到个位数Mbps，意味着路径、传输机制或端点处理存在明显限制。

单流限制与聚合带宽不是一回事

网络中的队列策略、业务服务的连接限速，以及某些按流分配的资源，都可能让一条连接受限，而多条连接仍能取得较高聚合吞吐。

另一些环境存在共享出口竞争。服务器端口是千兆，但上联、跨网互联或接收端出口在某个时段拥塞，单连接便会受到影响。

两者不能只凭“多连接快、单连接慢”直接区分。这个现象至少可能对应三种机制：

• 一条连接的有效窗口不足，多条连接叠加后利用率提高。
• 单连接受到固定或近似固定的速率限制。
• 多条连接在拥塞链路中获得更多总份额。

因此，多连接测试是定位线索，不是原因判定。

接收端读得慢，也会让发送端停下来

文件传输不是“网卡收到数据”就结束。数据通常还要经过协议处理、解密、应用读取，最后写入磁盘。

如果接收程序来不及取走数据，接收缓冲会逐渐占满，TCP通告的接收窗口会缩小，极端情况下出现零窗口。发送端此时必须暂停或减少发送，即使网络路径十分空闲。

接收端写入繁忙磁盘、程序边接收边做校验、同步写入开销较大，都可能触发这种背压。发送端同样可能因为磁盘读取或应用处理太慢，无法持续向TCP供数。

所以，不能只看服务器总CPU使用率。一个关键线程占满单核时，多核机器的总体CPU占用仍可能很低；磁盘平均吞吐不高，也可能伴随较高延迟或频繁同步等待。

加密与应用协议会引入自己的瓶颈

带加密的文件传输需要消耗CPU。如果加密算法、实现方式或关键处理线程受限，吞吐可能先碰到计算瓶颈，而不是链路上限。

应用还可能主动设置每连接限速、每用户限速，或者采用“读一小块、发送、等待，再读下一块”的节奏。如果协议或程序对每个小块都等待应用层确认，长RTT会进一步放大停顿。

但“使用加密”并不自动意味着低速，“每次读取较小数据块”也不必然导致低速。关键在于能否形成连续流水，而不是每一轮都等待网络返回后再继续。

路径异常也可能伪装成一般性慢速

MTU不匹配、路径MTU发现异常、接口错误或设备丢包，都可能导致重传和停顿。它们未必表现为整条链路完全不可用，有时是小请求正常，大数据持续传输不稳定。

对于这类问题，需要结合接口统计、TCP重传和具体路径验证。不能只看到“大包传输慢”，就认定一定是MTU问题；也不应为了试错直接开启巨帧或盲目修改MTU。

用对照测试把瓶颈逐层分开

验证顺序应当从“排除对象混淆”开始，再区分网络与应用，最后检查TCP和端点状态。下面的命令以Linux环境为例，需要系统已安装相应工具，并且对两端服务器有测试授权。

第一步：确认测试口径和方向

先记录文件大小、传输时长、工具显示单位、发送端与接收端地址，以及是否启用了分块、多连接或应用限速。

如果文件大小为2GB，传输耗时800秒，那么平均有效吞吐是：

2×8×1000÷800＝20Mbps，也就是2.5MB/s。

同时确认服务器实际使用的接口，而不是只看某块未承载该连接的网卡：

ip route get 192.0.2.10
ip -br link

其中192.0.2.10是文档示例地址，执行时应替换为实际对端地址。查询到接口名称后，可以用ethtool检查该物理接口：

ethtool eno1

eno1同样需要替换。重点看协商速率、双工状态和链路状态；若业务经过bond、VLAN等逻辑接口，还应确认其对应的物理成员。网卡为千兆全双工，只完成了本地链路这一层的核验。

第二步：用内存网络测试与文件传输做对照

iperf3可以在不读写文件磁盘的情况下测试TCP吞吐。它仍会受到CPU、系统和网络影响，但有助于把文件协议与存储开销分离出来。

在一端启动服务：

iperf3 -s

在另一端依次执行：

iperf3 -c 192.0.2.10 -t 30 -P 1
iperf3 -c 192.0.2.10 -t 30 -P 4
iperf3 -c 192.0.2.10 -t 30 -P 1 -R
iperf3 -c 192.0.2.10 -t 30 -P 4 -R

默认方向是客户端向服务端发送，-R则让服务端向客户端发送。测试方向应与慢速文件传输方向对应，地址也应尽量使用同一路径上的实际端点。

这些测试可能占满可用带宽，应安排在允许的时段。服务端默认监听范围和端口暴露需要遵守已有访问控制，仅供授权测试端访问，结束后用Ctrl+C停止，不应为测试直接取消防火墙保护。

对比时优先关注接收端有效吞吐，同时观察重传和每条流的表现。一次短测可能受瞬时拥塞影响，宜在相近时段重复，并用更长测试确认是否达到稳定阶段。

下面是一组用于说明判断逻辑的示例，并非实测结果：

表中第二行也不能直接证明“每条流被限速到6Mbps”。需要继续检查窗口和重传，才能区分固定限速与TCP机制造成的近似线性增长。

第三步：在传输过程中观察TCP，而不是只看完成速度

Linux上可以使用ss查看活跃连接的TCP状态：

ss -tinp

输出字段随内核和工具版本有所不同。常见观察项包括RTT、拥塞窗口、MSS、重传以及发送队列；部分版本还提供接收窗口限制、发送缓冲限制等信息。

需要注意，cwnd常以报文段数量显示，估算字节数时要乘以该连接的MSS。比如cwnd约为45、MSS为1460字节，则拥塞窗口约为65700字节。RTT若为100ms，对应的窗口吞吐量级约为：

65700×8÷0.1＝5.256Mbps。

如果实际速度也在这个量级，就形成了“窗口不足可能限制吞吐”的证据链。但窗口会随时间变化，单个截图不能代表整段传输，应在稳定传输期间多次观察。

判断时可以把现象组合起来看：

• 重传持续增加、拥塞窗口反复下降：优先调查拥塞、丢包和路径质量。
• 重传不多，但连接频繁受接收窗口约束：优先调查接收端读取速度和缓冲状态。
• 应用应当持续发送，但发送队列常为空：关注应用供数、文件读取和业务限速，同时结合CPU、磁盘判断。
• TCP网络测试很快，文件传输很慢：优先调查应用层，而非直接调整网络参数。

ping能够辅助估计RTT，但ICMP响应丢失不等于业务TCP丢包。中间设备可能降低ICMP响应优先级，不能仅凭某一跳不回包就认定该处丢弃文件数据。

第四步：检查端点是否跟得上

在真实文件传输期间，可结合以下工具观察CPU线程和磁盘：

top -H
iostat -xz 1

iostat通常由sysstat软件包提供，未安装时应使用本机已有的监控工具，而不是把“命令不存在”理解为系统异常。

重点不是寻找某个通用阈值，而是看慢速发生时是否出现同步变化：关键线程持续占满单核、磁盘等待明显增加、接收进程阻塞，或者应用日志显示速率限制。

文件缓存也会影响对照结果。读取同一文件第二次变快，可能是数据进入了内存缓存，并不能直接证明网络改善。不要在生产机上为了测试随意清理全局缓存，以免影响其他业务。

哪些判断成立，哪些调整不应直接套用

完成上述对照后，优化应与证据对应，而不是先把缓冲、拥塞控制和并发数全部修改一遍。

如果证据指向高RTT下的窗口不足，可以检查系统缓冲上限、自动调节是否生效，以及应用是否主动设置了过小的套接字缓冲。增大缓冲上限不等于立即增大拥塞窗口，也不等于实际连接一定使用该上限。 修改前还应评估并发连接的内存需求，并通过同路径测试确认效果。

如果证据指向丢包或拥塞，应优先定位链路、接口、队列和时段差异。只增加缓冲可能让排队时延更高，未必提高有效吞吐。

如果内存网络测试已经接近千兆，而文件传输仍只有几Mbps，应检查应用限速、加密处理、存储和接收逻辑。此时继续更换TCP参数，通常不如先解释应用为什么没有持续发送或接收数据。

多连接下载适合服务端允许并发请求、文件可以独立分块且资源充足的场景。它不适用于所有顺序数据流，也不能修复磁盘吞吐不足、总带宽受限或严重丢包。提高并发还可能加重服务端负担，应在允许范围内验证。

实际判断可以收敛为三个问题：同路径、同方向的单流网络测试能否跑快；慢速期间是TCP在限制发送，还是应用无法连续供数、收数；增加连接后提高的是单流效率，还是仅仅叠加了多条流的吞吐。

只有这三个问题得到回答，“千兆端口却只有几Mbps”才从一个表面矛盾，变成可以定位的技术现象。端口速率说明本地接口的能力，单连接速度则取决于整条路径与端点共同形成的限制；验证时必须让两者处于同一测试口径下。