tl:dr：http 流量可靠且快速，而 https 流量不可靠或极慢（加载时间为 2-5 分钟）。详情如下。
嘿，服务器故障，我有个好消息要告诉你。这是新办公室的第二周开始，在我入职前一周，新办公室刚刚扩建到第 15 个地区办事处。
在我们等待工作人员接通硬线的同时，新办公室正在使用临时的蜂窝 MPLS 连接。新办公室使用与其他 14 个办公室相同的 mpls 硬件和固件，并经过多次验证。
网络过滤和防火墙在我们的 DC 中发生，而不是在这个新办公地点。我想称之为中心辐射网络，但由于我是在“清理”期间受聘的，文档很少，而且我以前从未在如此复杂的环境中工作过，所以我不能确定。
问题：
用户需要使用多个 https 网站来完成工作。这些网站不会定期加载，甚至不会全部加载。如果非要我给出一个数字，那就是它们每 50 次尝试中才会加载一次，然后无法加载下一页。奇怪的是，（浏览器）标头和 URL 几乎每次都会加载，但除此之外，其他任何内容都不会加载。
同时http加载正常。
该办公室（与所有其他分支机构一样）有一个服务器（DC、文件服务器、DNS），并且它确实存在可能与此问题相关的复制问题。
我们已检查以下内容：
- 主机上已禁用 AV/防火墙
- 我们可以随时 ping 有问题的网站
- 我们多次更改了 IE 中的 SSL/TLS 设置
- 在 Web 过滤器上，日志显示所有 HTTPS 站点都被允许访问此分支
- 在防火墙上，日志显示此分支的所有 HTTPS 流量均已通过/未经扫描
- 我们的 MPLS 提供商在 HQ MPLS 路由器中发现了一个配置错误，并“修复”了这个问题，但并没有带来任何变化
- 来自测试工作站的 pcap 流量；与这些站点的通信存在，但远程主机在重置连接之前发送了 5 分钟的保持活动，这时我们看到“无法显示页面”错误
我已经调整、修改、播放、阅读日志、仔细检查、给 ISP 打电话、用谷歌搜索了四天，尝试了所有能找到的方法，但没有任何变化（变糟或变好）。
我的最后一个想法是它可能是速度较慢的蜂窝 MPLS 连接（1-3 Mbps；12 个用户/12 部 VoIP 电话/1 台服务器），但我一直排除这种可能性，因为我觉得它也会出现在 HTTP 流量中。
答案1
很高兴你找到了一个可行的解决方案。根据你的描述，这听起来像是路径 MTU 发现黑洞问题。
本质上，您通往互联网的路由上可能有一个路由器，其 MTU 低于标准的 1500 字节（1500 字节可能由您的客户端和它们正在通信的 Web 服务器使用）。通常，这不是问题，因为当路由器收到太大而无法发送下一跳接口的数据包时，它会丢弃该数据包并向发送者发送 ICMP 需要分段数据包。此 ICMP 数据包包含正确的 MTU，因此发送者可以以正确的大小发送所有未来的数据包。
如果分段要求的数据包被丢弃，则会出现问题 - 转发路径中的路由器可能具有过于激进的访问控制策略。这会导致发送方发送较大的数据包，这些数据包被丢弃，但随后没有反馈 - 发送方将继续尝试重新传输数据包。
如果您在客户端查看此信息，您将看不到来自发送方的任何流量，因此您开始发送“保持活动”探测。
正如您所描述的，您经常会发现 TCP 握手和初始 GET 请求都顺利通过，因为这些数据包通常很小。直到发送方必须开始发送全尺寸数据包时，问题才会显现出来。
如果这是你遇到的问题，你应该强烈建议转发路径中路由器的负责人不是丢弃 ICMP Fragmentation 所需的数据包 - 这样做会破坏一些东西。
答案2
我们找到了一个解决方法（因为这是一个临时连接...为什么不呢）。将工作站和服务器 NIC 上的 MTU 降低到 1200 可以完全消除此问题，并将速度提高大约一倍（从 1-3 Mbps 提高到 5-7 Mbps）。