办公网络加速，我们遇到的那些真实问题

一次 MTU 引发的血案：德国用户 ERP 超时排查实录

去年 12 月 15 号，我们接到一个德国客户的工单。客户是一家汽车零部件公司，总部在上海，德国慕尼黑的研发中心有 30 多号工程师，全部要访问上海的 SAP 系统。

工单描述很简单："SAP 登录后所有查询操作超时，其他一切正常。"

第一步：缩小范围

我们先让 IT 做了几个对比测试：

• 同一台笔记本用 VPN 连，SAP 正常；用快连连，SAP 超时。
• 同一个工程师的账号，在上海本地登录 SAP 完全正常。
• 慕尼黑到上海的 ping 延迟 180ms，丢包 0%。

这就奇怪了。如果延迟稳定、丢包为 0，快连又比 VPN 更快，为什么 SAP 会超时？

第二步：抓包分析

我们在德国客户端抓了包，发现大量 ICMP Fragmentation Needed (Type 3, Code 4) 的报文。简单说就是：SAP 的数据库服务器发出的包太大，中间路由器装不下，需要分片，但 SAP 客户端"不好意思"回应，于是一直等，直到超时。

"这不就是典型的 PMTU 黑洞问题吗？" —— 团队里的实习生第一反应。

我们查了一下默认配置，快连默认 MTU 是 1500。德国电信和中国电信之间的某一跳链路，MTU 只有 1420。大于 1420 的包会被悄悄扔掉，而不是返回 ICMP 错误。SAP 的数据库查询（比如 BAPI 调用产生的大结果集）很容易就超过 1420 字节，所以超时。

第三步：解决

我们让客户把快连的 MTU 改成 1400，重启 SAP 客户端。5 秒后，所有查询恢复正常。

后来我们做了两件事：

• 把 MTU 测试做成快连的自动诊断功能，新用户注册时自动测量最优 MTU。
• 给所有 ERP 类应用（SAP、用友、金蝶）默认把 MTU 下调到 1400。

这个案例告诉我们：当一切参数看起来都正常，但应用就是卡，往往是某个我们"看不见"的协议细节出了问题。多抓包，少猜测。

为什么视频会议卡，但下载飞快？QoS 优先级的故事

这是我们被问得最多的问题之一："我下载 1080p 视频很顺畅，为什么一开 Zoom 就卡成 PPT？"

核心答案：QoS 优先级

网络设备（路由器、交换机）对不同类型的流量会给不同的优先级。这叫 QoS（Quality of Service）。

视频会议用的是 UDP 协议，而且是实时 UDP，对延迟敏感到毫秒级。一旦丢包，画面就会花、声音就会卡。而下载走的是 TCP，丢包会自动重传，用户感知不到。

真实案例：一个上海团队的全员视频故障

今年 2 月，一个上海客户（200 人团队）开跨国大会前 10 分钟，全员 Zoom 卡得无法入场。我们远程看了一眼他们的路由器配置，发现运营商的企业专线默认把 UDP 流量放在了最低优先级，所有下载、浏览都会抢占它的带宽。

解决方法：在快连"视频会议专线"里开启 UDP 优先级标记。具体说就是在我们的加速节点和客户端之间建立一条"专用 UDP 通道"，绕开运营商的 QoS 配置。

"整个切换过程 30 秒。大会如期进行。后来我们把 UDP 优先级作为视频会议类应用的默认选项。"

三个判断 QoS 问题的快速方法

• 下行卡（对方画面断）：多半是我们这边 QoS 没给 UDP 优先级。
• 上行卡（我们的画面对方收不到）：多半是本地有人在抢占带宽。
• 全员同时卡：八成是公司路由器或运营商的 QoS 配置问题。

下次视频会议前，记得先看一眼快连是不是开了"视频优化"线路。这一条解决 80% 的视频问题。

海外打开国内共享盘为什么那么慢？SMB 协议的大坑

一个很容易被忽略的事实：SMB 协议（也就是 Windows 文件共享用的协议），是为局域网设计的，不是为跨国网络设计的。

SMB 的致命缺陷

SMB 在传输任何数据之前，要进行至少 6 次握手协商。每一次握手都要一个来回（RTT）。跨国 RTT 假设 200ms，光是打开一个文件夹就要 1.2 秒。

更糟的是，SMB 的 TCP 窗口非常小，默认只有 64KB。也就是说，每传 64KB 数据就要停下来确认一次。一个 100MB 的文件，要确认 1600 次……

我们遇到的最极端案例

一个巴西客户，圣保罗到上海，共享盘下载速度 稳定在 30-50KB/s。IT 部门一开始以为是带宽不够，结果测出来的专线带宽有 100Mbps，完全没跑满。

我们做了两件事：

1. 在快连里打开"传输优化"，把 TCP 窗口动态调到 4MB。
2. 告诉巴西的同事：大文件让国内同事先压缩成单个 zip 再传，减少握手次数。

一周后回访，速度稳定在 3-5 MB/s，提升了 100 倍。

更彻底的解决方案

长期来看，我们建议客户把 SMB 共享迁移到 WebDAV 或 S3 兼容对象存储。这两种协议是基于 HTTP 的，对延迟不敏感，跨国传输效率高一个数量级。

但很多企业已经用 SMB 十几年了，迁移成本高。所以我们的态度是：短期用加速工具凑合，长期必须迁移。

飞书国际版一加速就掉线？IP 漂移检测的另类故障

去年 12 月，一个澳洲客户联系我们。工单内容："团队飞书国际版正常，一开快连加速，飞书就掉线，提示账号异地登录。"

这是我们遇到过的最诡异的故障之一。

排查过程

第一反应是快连的出口 IP 被飞书判定为异常。但我们检查了所有出口 IP，都是干净的企业 IP 段，没问题。

然后我们让客户做了一个对比：用快连加速其他应用（ERP、邮箱）都正常，只有飞书国际版异常。

抓包看了两天，终于发现端倪：飞书国际版的登录服务器，在登录后的前 30 秒内会检测客户端的源 IP 是否稳定。而快连会根据网络状况动态切换加速节点，导致源 IP 在短时间内发生变化。飞书把这种切换判定为"异地登录"，强制踢出。

解决方案

最简单的方法：把飞书域名加入"不加速列表"。飞书的海外节点在澳洲本地访问速度本来就不错，不需要加速。真正需要加速的是国内的 OA、ERP 这些。

• 添加 *.larksuite.com 到不加速列表。
• 添加 *.feishu.cn 到不加速列表。
• 其他办公系统继续加速。

切换后飞书稳定了。这个解决方案后来被我们整理进了配置文档，叫"飞书例外规则"。

延伸思考

这次故障让我们意识到：任何有"IP 漂移检测"的产品（包括部分银行系统、风控严格的 SaaS），都不适合开启动态节点切换。我们后来在快连里加了一个"静态节点模式"，允许用户为指定应用锁定一个固定出口 IP。

所以下次遇到"一加速就掉线"的诡异情况，先排查一下是不是应用本身的 IP 检测机制。

TCP 窗口与 BDP：为什么带宽够但速度上不去

工程师圈子里流传一句话："带宽是水管粗细，延迟是水管长度，BDP 是水管能装多少水。"

BDP（Bandwidth-Delay Product）= 带宽 × 延迟。决定一个 TCP 连接能达到的最大吞吐量。

一个真实的计算

假设你的专线是 100Mbps，到国内延迟 200ms：

• BDP = 100Mbps × 0.2s / 8 = 2.5MB
• 意思是：你的 TCP 窗口至少要开到 2.5MB，才能用满 100Mbps 带宽。

而 Windows 默认的 TCP 窗口只有 64KB。所以即使你有 100Mbps 的专线，实际吞吐量也只有：

• 64KB / 0.2s = 256KB/s

是不是很熟悉？很多人说"我的专线明明 100M 为什么下载只有几百 KB"，这就是原因。

快连的解决方法

我们的传输优化模块会根据实时测量的 BDP 动态调整 TCP 窗口，最大可以开到 16MB。这样即使跨国延迟 300ms，也能跑满 Gbps 级带宽。

这个优化对 SMB、FTP、对象存储下载等所有基于 TCP 的应用都有效。一旦打开，你会发现文件传输速度直接翻 10 倍。