tl：dr：httpstream量在httpsstream量不可靠或非常缓慢（2-5分钟加载时间）的情况下可靠，快速地工作。 下面的细节。
嘿服务器故障，我有一个很好的给你。 这是第二个星期开始的一个新的地方，在我雇用前一周刚刚扩大到第15个地区办事处。
新办公室正在使用一个临时的蜂窝MPLS连接，而我们等待机组人员进入强制线路。新办公室正在使用与另外14个办公室相同的硬件和固件，用于mpls，经过多次validation。
Web过滤和防火墙发生在我们的DC中，而不在这个新的办公地点。 我想把它称为中心和辐射networking，但是由于我在“清理”过程中被雇佣了，而且文档很less，而且我从来没有在这个复杂的环境中工作，所以我无法确定。
问题：
用户有一些他们需要用来完成工作的https站点。 这些网站将不会定期加载，如果这一切。 如果我不得不在上面写上一个数字，他们会在50次尝试中加载一次，然后加载下一页。 奇怪的是，（浏览器）头和URL几乎每次都会加载，但没有其他的东西会加载过去的。
同时http加载正常。
在这个办公室里有一个服务器（DC，文件服务器，DNS）（就像所有其他的分支一样），它的复制问题可能与这个问题有关。
我们检查了以下内容：
我一直在调整，调整，播放，阅读日志，双倍/三重检查，称ISP和谷歌search4天现在尝试我能find的一切，没有任何改变（更糟或更好）。
我最后的想法是，它可能是缓慢的蜂窝MPLS连接（1-3 Mbps; 12个用户/ 12个VoIP电话/ 1个服务器），但我坚持认为，因为我觉得它也会出现在HTTPstream量中。
很高兴你有一个工作的解决scheme。 根据你所描述的，这听起来像是一个pathMTU发现黑洞问题。
从本质上讲，你的路由器可能在你的路由器上，MTU低于标准的1500字节（1500字节可能被你的客户和他们正在使用的networking服务器使用）。 通常情况下，这不是一个问题，因为当路由器收到一个太大而不能发送其下一跳接口的数据包时，它会丢弃数据包，并将ICMP Fragmentation Needed数据包发送回发送者。 这个ICMP数据包包含正确的MTU，因此发送者可以以正确的大小发送所有将来的数据包。
如果需要分段的数据包被丢弃，则会出现问题 – 也许转发path中的路由器具有过度激进的访问控制策略。 这会导致发送者发送被丢弃的大包，但是没有反馈被发回 – 发送者将只是继续尝试重传包。
如果你在客户端看这个，你没有看到来自发送者的任何stream量，所以你开始发送Keep Alive探针。
正如你所描述的，你经常会发现TCP握手和初始的GET请求经过了OK，因为这些数据包通常很小。 直到发送者不得不开始发送全尺寸的数据包，这个问题才变得明显。
如果遇到这个问题，您应该强烈build议负责转发path中的路由器的任何人不要丢弃ICMP Fragmentation Required数据包 – 这样做会破坏事情。
我们find了一个工作（因为这是一个临时连接…为什么不）。 将工作站和服务器网卡上的MTU降低到1200，完全消除了这个问题，速度提高了一倍（从1-3 Mbps到5-7 Mbps）。