我们有一个Akamai背后的应用程序，这意味着所有流量首先流向Akamai，然后流向我们的Web服务器，然后是我们的应用服务器。有一些URL在我们的应用程序中进行冗长的更新，并且可能需要4分钟，具体取决于用户提交的内容（是的，我知道这很糟糕，但这是遗留代码 - 我没有写，但我必须处理它） 。如果重要，此URL使用发布请求而不是获取。我们注意到的是，如果URL超过2分钟，我们会看到每2分钟就会在我们的应用服务器上调用URL，即使浏览器本身在网络选项卡中只有一个请求（在IE11和chrome 45中也是如此）所以不要认为这是一个浏览器问题）。所以假设URL需要6分钟，我们实际上会在访问日志中看到3个调用。
我们联系了Akamai支持，他们否认他们造成了这个问题。他们提供了他们的日志，显示从他们的服务器发送到我们的3个呼叫（每个呼叫相隔2分钟）。所以现在我需要证明它实际上是Akamai引起的问题（因为技术支持不相信1 + 1 = 2，除非你向他们证明）。
我还试图用fiddler（一个http数据包嗅探器）调试它。我看到一个来自浏览器的请求，但我也看到一个提琴手每1分钟保持一次保持通话。我认为这并不意味着浏览器重新提交请求，这是一些http标准，以保持插入连接的活跃。
我搜索了Akamai文档并且我搜索了谷歌，但无法找到任何涉及此问题的内容。我真的有两个问题：
1）。是否有任何方式浏览器本身以某种方式每2分钟重新提交一次请求，即使它只在网络选项卡中显示1个请求（IE11和chrome都必须这样做）
2）。有没有人在Akamai之前听说过这个问题？
答案 0 :(得分：0)
我不知道我是否从你的帖子中得到了一切，但据我所知，很可能是边缘服务器在请求超时并尝试每隔几分钟重新发送一次事实上在元数据配置中，http-read的默认值应该是120秒，您应该请求您的支持人员检查这一点，并可能进行配置更改以支持特定需要在该URL上进行冗长的超时。希望有所帮助！