带宽没跑满，第一件事不是打运营商电话，而是分清当前数据流是发送端在推，还是接收端在拉，多数卡顿发生在两端设备本身，而不是接入网。
发送端和接收端，到底谁在限速
一个TCP数据流有两个角色：发送端负责把数据推出去，接收端负责收下来并确认，下载大文件时，服务器是发送端，你的电脑是接收端；上传视频到网盘时，方向反过来，你的电脑变成发送端。
很多人把带宽跑不满当成一个笼统问题,其实要先问一句：现在是谁在发，谁在收？
下载慢不等于运营商偷工减料
下载场景下,发送端可能是CDN节点或某台服务器，接收端是你的PC或手机，如果接收端网卡协商在百兆、磁盘写入只有几十MB/s、或者接收窗口设置过小，就算运营商给了千兆接入，实际速率也上不去。
上传慢时，发送端往往是自己的设备
上传场景下,你的设备是发送端，机械硬盘读取速度、CPU处理TCP卸载的能力、发送缓冲区大小，都会限制带宽，很多用户测下载正常，一上传文件就掉到几MB/s，第一反应是宽带不行，实际上是发送端根本没能力把数据推满。
带宽跑不满是什么原因？接收端三个高频陷阱
网卡协商速率降到了百兆
先做一步验证：在Windows打开PowerShell，输入：
Get-NetAdapter | Select-Object Name,LinkSpeed
如果结果显示 100 Mbps，说明网卡没有协商到千兆，原因可能是网线质量差、水晶头氧化、路由器和电脑之间某个口是百兆、或者网卡驱动太旧。
- 六类非屏蔽网线在短距离内通常可以稳定跑千兆
- 五类线如果质量一般,长距离容易被协商成百兆
- 更换网线后,用
wmic nic where NetEnabled=true get Name,Speed再确认一次
接收窗口和TCP实现把速度卡住
行业共识认为,TCP吞吐量受接收窗口和丢包的双重约束，而非只由链路带宽决定，如果接收端窗口太小，发送端必须等确认，带宽自然跑不满。
在Linux服务器上,可以用：
sysctl net.ipv4.tcp_rmem
查看接收缓冲区,若数值偏小，可以适度调大：
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
这是接收端优化,不是玄学。
磁盘写入速度跟不上，网络再快也没用
下载速度大约 100 MB/s 时，如果写入的是机械硬盘碎片区，实际写入可能只有 80 MB/s，甚至会卡在 40-60 MB/s，此时网络带宽明明有剩余，接收端却无法继续收数据。
- 下载大文件前先测磁盘顺序写速度
- 用CrystalDiskMark或
dd做基准 - 如果磁盘写入明显低于带宽对应的字节数,瓶颈就在接收端磁盘
上传速度慢下载正常是什么问题：发送端瓶颈比想象中多
发送缓冲区不够，小文件传输尤其吃亏
上传很多小文件时,每个文件都要建立连接、等待确认，发送缓冲区过小，会让数据发送频繁停顿。
在Linux服务器上检查：
sysctl net.ipv4.tcp_wmem
如果默认值较低,可以调整：
sysctl -w net.ipv4.tcp_wmem="4096 16384 4194304"
这个值影响发送窗口,直接影响上传吞吐。
发送端磁盘读取慢，CPU单核被占满
上传时,发送端需要从磁盘读数据，再交给网卡，如果磁盘是机械盘，同时又在跑数据库或备份任务，读取速度会断崖式下降，CPU单核负责处理中断，如果被其他进程占满，网卡队列处理不过来，速度也会掉。
拥塞控制和丢包让发送端主动降速
TCP发送端遇到丢包会减小拥塞窗口,如果你上传到远端服务器经过的路径有丢包，发送端会主动收着发，带宽自然不满，这时远端接收端再强也没用。
三步用命令定位：发送端还是接收端在拖后腿
第一步：先测本地磁盘顺序读写
排除磁盘瓶颈是第一优先级,下载要看写入速度，上传要看读取速度。
Linux下：
dd if=/dev/zero of=./testfile bs=1M count=2000 oflag=direct
测写速度,
dd if=./testfile of=/dev/null bs=1M count=2000
测读速度,Windows下用CrystalDiskMark即可，不用记命令。
如果测得速度低于带宽对应速度的八到九成,磁盘就可能顶不住满速率传输。
第二步：用iperf3双向打流
在发送端和接收端分别安装iperf3。
接收端启动服务：
iperf3 -s
发送端测下载方向：
iperf3 -c <接收端IP> -t 30 -i 2
再反向测上传方向：
iperf3 -c <接收端IP> -t 30 -i 2 -R
重点看两个方向的TCP吞吐是否接近物理带宽,如果正向接近、反向差很多，说明瓶颈在反向的发送端或正接收端配置。
第三步：抓包看TCP零窗口和重传
用Wireshark在接收端抓包,过滤：
tcp.analysis.zero_window
出现大量零窗口,说明接收端处理不过来，窗口被填满，过滤：
tcp.analysis.retransmission
出现较多重传,说明链路有丢包或质量欠佳，发送端被拥塞控制压制，根据这两个信号基本能定位责任端。
三个真实场景：为什么换了千兆宽带还是跑不满
千兆宽带测速只有几百兆：接收端设备要背锅
很多用户升级了千兆宽带,但测速只有几百兆，问题多半出在接收端设备上。
- 路由器WAN口是千兆,LAN口是百兆
- 光猫桥接后,路由器没有开启硬件加速
- 电脑网卡虽然是千兆,但驱动太老或省电模式在降速
- 测速时后台有迅雷、网盘、Windows更新在抢占连接
先排除上述问题,再下结论说是运营商问题。
上海千兆宽带测速只有500兆？先换根六类线再下结论
经常有人搜索“上海千兆宽带测速只有500兆”，其实多数情况下不是上海宽带骨干网的问题，而是最后一米设备不给力，五类线、超五类线在长距离、弯折多、水晶头质量差的情况下，协商速率会掉到百兆或数百兆，换一根六类非屏蔽线，很多测速就正常了。
公司专线带宽价格不低，为什么上传还是跑不满？
公司光纤专线带宽价格通常比家用宽带高出不少,但如果上传还是跑不满，先不要着急加钱扩带宽。
- 检查防火墙或路由器的QoS策略,是否限速了上传
- 检查服务器网卡是否千兆、磁盘读取是否成为瓶颈
- 检查公司出口是否存在会话数超限或运营商限制并发连接数
业内专家指出,公司专线上传慢的案例中，相当一部分是内部设备或策略造成，而不是接入带宽本身不够。
带宽没跑满,先分清发送端还是接收端，再动手，盲目升级带宽、换路由器、打客服电话，往往解决不了真问题，先看方向，再查磁盘、网卡、窗口和丢包，大多数瓶颈都会有答案。
Q&A
带宽跑不满时，怎么判断是发送端还是接收端？
先用iperf3双向测试,下载方向接近带宽、上传方向差很多，优先查发送端磁盘读取和发送缓冲区；两个方向都差，优先查接收端窗口和网卡协商；单方向大量重传，查链路质量。
接收端和发送端都有哪些典型瓶颈？
接收端常见：网卡协商速率低、TCP接收窗口小、磁盘写入慢、CPU处理能力不足，发送端常见：磁盘读取慢、发送缓冲区过小、拥塞控制被丢包触发、应用层队列太短。
为什么带宽测试正常，实际传输文件还是慢？
因为测速跑的是单纯TCP连接,实际文件传输可能涉及大量小文件、多线程竞争、磁盘随机读写、远端服务器限速等因素，测速正常只能说明链路带宽够，不能代表业务场景一定能跑满，最终还是要回到发送端和接收端各自的能力上排查。