-
我的接口传小数据一切正常,可一旦传稍大的数据,在某些客户端那里就偶发卡死、超时,换个网络又好了,抓包发现大包发出去对方根本没收到、也没人告诉我为什么:一次 MTU 路径黑洞的深度复盘
我有个接口平时好好的,直到某些用户反馈:小数据没问题,可一旦传稍大的数据就偶发卡死、超时,更诡异的是同样的请求换一个网络环境(比如从 VPN 切到普通网络)就好了。抓包越看越懵:大请求的数据包发出去了可对端根本没收到,而且没有任何错误返回,就那么静静卡着到超时。查了很久才搞懂根因冷门:网络每条链路都有 MTU(一个包最大尺寸,以太网 1500),一个连接经过多跳,整条路径能传的最大包取决于路径上最…- 2
- 0
-
跨 VPC VPN MTU 黑洞导致大请求 60 秒 timeout 的 4 天复盘:Path MTU Discovery 被 ICMP 拦截 + MSS clamping 修法 + 8 条网络配置纪律
业务跨 VPC 调用偶发 60 秒 timeout,小请求正常、大请求必挂。4 天根因定位:IPsec VPN 隧道 MTU 1400,主路径 1500,Path MTU Discovery 依赖的 ICMP type 3 code 4 被对端业务防火墙误判为攻击全部丢弃,DF=1 的大包陷入黑洞。复盘包含 ping -M do 二分定位、tcpdump ICMP 抓包、Calico/Cilium…- 7
- 0
-
ping 通了 scp 大文件却卡死:一次 Linux MTU 路径黑洞排查复盘
两个机房之间拉了一条 VPN 隧道,ping 通、SSH 登录正常、敲小命令流畅,可 scp 传大文件卡在某个进度死住,curl 下大页面、git clone 全卡。一条小数据全过大数据全卡的通一半的网络。排查梳理:ping 通只证明小包能往返完全不证明大包能过,网络连通性是有包大小这个维度的;小操作正常大操作卡死第一个怀疑 MTU;用 ping -M do -s N 测路径 MTU,-M do …- 4
- 0
MTU
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×