更改一下接口的MTU值试试，

mtp mss 1400

1400可以再换小一点的数字。

一、先把核心疑问讲透：带宽超了为什么不是只变慢，反而会丢包？

1. 基础带宽换算先明确

2. 为什么超带宽会丢包，不只是变慢？

1. 你内网业务 + 服务器映射上传，瞬时总流量持续跑满、超过 100Mbps
2. 千兆接口物理能跑，但运营商链路已经满载，流量进路由器后往公网转发时出口带宽瓶颈堵死
3. 路由器报文排队缓存有上限，队列塞满之后，新进来的报文直接尾部丢弃（Tail-Drop）
4. TCP 上传文件虽然有重传机制，但频繁丢包 → 不停重传、超时、窗口缩小
   表现就是：上传卡顿、中断、进度条卡住、感知明显丢包，而不是单纯慢。

二、你最关心的问题：路由器做出口限速压在 100M 以内，会怎样？

结论

1. 在路由器出口配置严格限速 / 整形，把整体公网出带宽限制在 100Mbps 以内
   → 只会变慢、限流平滑转发，基本不会主动丢包
2. 原理：
   路由器提前把超出 100M 的流量做缓存排队、平滑发送，不往运营商口硬塞，不会触发运营商侧和本地路由器的队列溢出丢弃。
3. 前提：
   限速不能只做单 IP 限速，要做全局出口总带宽限速 + QoS 队列调度，否则某一个映射上传占满，其他业务还是卡。

三、为什么现在会频繁超 100M 带宽？

• 公网映射服务器上传
• 内网还有核心、汇聚、接入一大片内网业务流量
• 所有流量共享同一条 100M 专线出口
  只要：服务器大文件上传 + 内网其他上网业务叠加，瞬时很容易冲破 100Mbps，直接触发队列满→丢包。

四、落地优化方案（按优先级从简单到专业）

方案 1：路由器全局出口限速（必做，最简单有效）

• 带宽整形 / 限速 上行严格限制为 95～98Mbps（留一点余量防瞬时突发）
• 不要限满 100M，留 2~5M 冗余，避免脉冲流量顶满

方案 2：QoS 流量调度（优先级保障）

1. 服务器映射上传业务 分配固定带宽配额
2. 普通内网上网业务 占用剩余带宽
3. 做队列带宽抢占、限流隔离
   避免单一服务器上传把整个 100M 专线吃满，导致全网丢包。

方案 3：对映射服务器单独限速

方案 4：更换扩容运营商带宽（治本）

方案 5：开启 TCP 优化 / 队列调度机制

五、总结一句话答疑

1. 超运营商 100M 带宽时：设备队列溢出→主动丢包，不只是变慢；
2. 路由器把出口整体限速压制在 100M 以内：流量被平滑调度，只会变慢、基本不丢包；
3. 最优做法：全局出口限速 95M 左右 + 服务器单独限速 + QoS 队列隔离，彻底解决上传丢包、全网挤占问题。

一、为什么明明只是超过 100M，却会丢包？

1. 根本原因：出口发生了队列溢出（Bufferbloat / 尾丢弃）

• 服务器以千兆线速疯狂发包，流量全部堆在路由器的出口队列里；
• 但出口到运营商的链路只有 100Mbps，路由器转发不出去，队列瞬间被打满；
• 路由器的端口缓存是有限的，一旦队列满了，新来的包就会被直接丢弃（尾丢弃 Tail Drop），不是变慢，是直接丢包；
• 上传变慢是 TCP 的流量控制和拥塞控制在丢包后自动降速的结果，但在降速之前，已经发生了丢包，所以用户会感知到卡顿、重传甚至上传失败。

2. 为什么不是 “只会变慢”？

1. 队列溢出 → 丢包 → 发送方收不到 ACK；
2. 发送方超时重传，同时触发拥塞控制，降低发送速率；
3. 整个过程会伴随大量重传和乱序，用户体感就是：上传速度忽快忽慢、进度条卡住、文件校验失败，而不是稳定的低速传输。

二、核心问题：路由器没有对出口带宽做限速 / 整形，导致内网流量直接冲爆运营商链路

三、怎么解决？三种方案，按效果排序

方案 1：在出口路由器配置流量整形（Shaping），限制出口带宽≤100Mbps

原理

配置示例（H3C / 华为风格）

• 这里的关键是用qos car（承诺访问速率）对出方向做限速，把出口带宽锁死在运营商给的速率以内，避免队列溢出。
• 为什么用 95Mbps 而不是 100Mbps？因为要预留突发流量的余量，避免流量尖峰瞬间超过 100M 导致丢包。

方案 2：配置 WRED（加权随机早期检测），缓解丢包但无法根治

• WRED 会在队列即将满的时候，提前随机丢弃少量包，而不是等队列全满了再尾丢弃；
• 作用是让 TCP 提前感知拥塞，降速更平滑，减少大面积丢包；
• 但如果流量长期超过 100M，还是会丢包，只是丢包更均匀，不会一下子全崩。

配置示例

方案 3：优化服务器侧上传配置（配合限速效果更好）

1. 限制服务器的 TCP 发送窗口大小，避免瞬间发送大量数据；
2. 上传软件开启 “限速” 功能，设置最大上传速度不超过 90Mbps；
3. 关闭服务器的 “巨帧（Jumbo Frame）”，避免大报文被分片丢包。

四、你的疑问解答

比如在路由器上配置限速在 100M 以内，那么用户上传文件是只会变慢不丢包，还是一样会有丢包情况？

• 正确配置限速（流量整形）后，只要流量不超过限速值，就不会出现队列溢出丢包，用户只会觉得上传速度被限制住了，不会再出现丢包、重传和上传失败的情况。
• 关键是要把限速值设为略低于运营商带宽（比如 90-95Mbps），而不是正好 100Mbps，这样能吸收掉流量突发，避免尖峰导致的丢包。

五、额外排查点（防止配置了限速还是丢包）

1. 运营商的 100M 专线是对称带宽还是上传受限？很多 100M 宽带的上传只有 30-50Mbps，你按 100M 限速还是会超；
2. 路由器的 CPU / 内存是否过高？如果设备性能不足，限速配置也会失效；
3. 检查是否有其他业务（比如备份、监控）也在占用出口带宽，和上传文件抢资源。

这个问题非常典型。简单来说，接口带宽占用超过运营商100M限制时，丢包是必然结果，而不是单纯变慢。但如果在你的路由器上实施精准的限速，就能实现“只变慢、不丢包”。

为什么超带宽会丢包，而不仅仅是变慢？

关键区别在于是谁在丢包。

• 你的路由器：如果没做限速，它会尽力用千兆速率发送数据。但数据到达运营商网络边缘时，会被运营商的限速策略（比如令牌桶算法）直接丢弃超出100M的部分。这种“硬丢弃”是完全随机的，会对所有基于TCP的应用（包括你的文件上传）造成无差别伤害。

• TCP协议的反应：TCP检测到丢包后，会启动拥塞控制机制，不仅重传数据，还会大幅降低发送速度，然后缓慢恢复。这就像高速上发生车祸，不仅导致车祸车辆受阻，还会引发几公里的拥堵，用户体验就是“卡一下，再缓过来”，也就是你感知到的丢包。

因此，不加限制地发送数据，必然导致运营商侧丢包，从而引发TCP性能问题。

 在路由器上配置限速：效果如何？

非常推荐，这是最直接有效的优化方案。 在路由器上进行流量整形，可以实现“只变慢、不丢包”，效果和原因如下：

• 实现“只变慢”：开启流量整形后，路由器会主动将数据发送速率控制在100M以下。它会用缓存来容纳突发流量，再以平滑的速度发出。这样操作完全避免了运营商的丢包，文件上传变成一条稳定的“慢车道”，而不是走走停停。

• 为什么可能还会丢包：如果你的100M带宽持续满载，数据队列会在路由器缓存中积压。如果缓存满了，路由器本身也不得不丢包。但即便如此，这种丢包也是可控的，你可以通过WRED（加权随机早期检测）等技术在队列快满时主动丢弃少量新包，来确保队列不溢出，从而让整个上传过程更平滑。

 优化方案：不止是限速

1. 精准限速（首要操作）：在路由器出接口（连运营商侧）上做层级式限速。先限制总上行带宽不超过100M（比如95M），再在总带宽内为这台服务器做保障或限制。

   # 示例：为服务器上传流量单独限速 100M (H3C路由器)

   qos car inbound server_traffic cir 102400 cbs 6400000 ebs 512000 green pass yellow pass red discard注意：配置时要将100M换算为Kbps，即100 * 1024 = 102400，并合理设置突发缓冲区。

2. 应用层优化（从服务器入手）：

   • 改用流式传输：将FTP/HTTP上传改为流式协议（如RTMP/WebRTC）。

   • 启用压缩和断点续传：减少文件体积并避免失败重传整个文件。

3. 物理层检查（排查次生问题）：

   • 接口双工模式：检查路由器接口是否因协商问题处于半双工状态，这会导致严重丢包。

   • 更换网线：劣质网线在高负载下也可能引发物理层错误。