未分類
30 10 月 2020

MTU 设置不合理，部分 https 网站打不开

MTU 设置不合理，部分 https 网站打不开

資深大佬 : doveyoung 2

装完虚拟机（ win ）之后发现无法打开部分网站，以百度为例 www.baidu.com可以看到 302 消息，跳转后https://www.baidu.com就超时了，而另外一部分网站是正常的。

使用curl -v可以看到在收到服务器发来的 hello 后卡住不响应。

wireshark 抓包发现百度回复了几个包，其中有一条警告是Ignored Unknown Record ，猜测是包被拆分后出现了点问题所以不认识。搜索这个警告信息确实有类似的案例 HTTPS Websites Not Reachable

修改 MTU 后问题解决，同样的，在其他某些虚拟机上如果有不合适的 MTU 也会打不开百度。

我理解的 MTU 不是只会影响性能速度吗，怎么这都影响到功能了，有没有大佬解惑

大佬有話說 (14)

  • 資深大佬 : tankren

    MTU 貌似会影响很多的 比如盒子看视频卡什么的 一般是 1492

  • 資深大佬 : barathrum

    MTU 不合适会直接丢掉包，不只是影响速度。
    不过我见过的一般是丢掉第一个包，收到一条 ICMP 消息后重新协商。
    你给的链接似乎是用了他家的产品才会有这样的问题。

  • 主 資深大佬 : doveyoung

    @barathrum 对，我是看到有类似的案例，所以改了 MTU 试了一下，没想到搞定了

  • 資深大佬 : bclerdx

    @doveyoung 你在哪里改的 MTU ？

  • 資深大佬 : geekvcn

    家用所有设备设置 1480 保持 MTU 对齐就行了，1492 没必要提升不了什么网速，其实更希望运营商把局端和光猫之间的 MTU 改为 1528，这样直接 MTU1500+8pppoe 头，最标准的 MTU 了

  • 資深大佬 : fovecifer

    我碰到过因为 MTU 问题导致 https 地址不能访问的问题

    大致的问题是中间链路上某个设备不支持这么大的 MTU 的时候，会给源地址发一个 icmp 协议的包，
    让源拆成小包之后再发，但是很多设备对这个 icmp 的报文支持的并不好
    从抓包上看到一直重传，超过次数之后就放弃了

  • 主 資深大佬 : doveyoung

    @bclerdx #4 改的虚拟机自己的 MTU
    @fovecifer #6 可能就是这个原因
    @geekvcn #5 主要是 MTU 没有标准一说，都是根据以往的经验去定的。我遇见的是新创建的这个虚拟机有问题，刚好 MTU 又跟其他虚拟机又不一样。测了一下改成合适的了。为什么这个虚拟机的 MTU 跟其他的不一样，我得再去看看。。。

  • 資深大佬 : sinoricky

    北京联通环境，前段时间折腾 Ubnt ER-X 发现 IPv4 和 IPv6 的 MTU/MSS 是不同的。
    我遇到的故障表现就是 WiFi 环境下，无法打开某些微信的公众号的网页。

  • 資深大佬 : tankren

    @sinoricky #8 https://www.v2ex.com/t/710855#reply16

  • 資深大佬 : joshu

    我遇到的一般是去向路由的 mtu 高于回向路由 mtu，导致 tcp 包被丢弃或不完整。。。

  • 資深大佬 : marsteel

    MTU 协调失败会导致 SSL 协商故障

  • 資深大佬 : bclerdx

    @sinoricky 那么你北京联通环境下，IPv4 和 IPv6 的 MTU 和 MSS 配置的数值是多少呢？

  • 資深大佬 : brMu

    @bclerdx 根据爱快的默认配置，1400 的 mss 应该适合绝大多数环境，此时 mtu 是 1440

  • 資深大佬 : maybeonly

    双栈？
    如果是 ipv6 的话可能会出现这个问题
    因为 ipv6 在超出 mtu 以后不会像 ipv4 一样拆包重传，而是回一个 toobig 给发送方
    如果发送方（网站）配置不合理（特别是负载均衡配置不合理）不能正确转发 /处理 toobig
    同时你的运营商没有做 mssfix，就可能出现这个问题
    去年让我们公司改了，专门给阿里云反馈，那边也改了，看来百度还没改，或者又弄坏了。

    ========

    （去年）某天早上发现我家宽带没给我的宽带上 v6 设置 mss
    这样我出去的 mss=1440 （ MTU=1500 ）
    按理说 PPPoE 的话 mss=1432 （ MTU=1492 ）才是对的

    结果就是，发送到服务端的 SYN 上 MSS=1440，然后 LVS 转给 realserver
    rs 按照 MSS=1440 回包，但是到了 PPPoE 的局端设备太肥了过不去
    发送 ICMPv6 TOO BIG （ Type=2 ）给 lvs
    但是 lvs 没有理会这个东西
    所以 rs 是不知情的，继续按照 MSS=1440 发，被丢弃

    如果 IPv6 没通，没收到 SYN/ACK，是无所谓的，很多客户端包括浏览器会自动尝试 IPv4，但是这里 [email protected] 确实恋上了，那么最终结果就
    只能是，届不到，届不到，无法传达的数据包