【问题标题】:After HTTP Keep Alive timeout new HTTP request arrivesHTTP Keep Alive 超时后,新的 HTTP 请求到达
【发布时间】:2015-09-22 02:57:31
【问题描述】:

我们的应用程序是基于 ExtJS 3.4 的应用程序,我们经常在 UI 上收到“Communication Failure”错误,我们将应用程序部署在不同的域上,但在某些域上我们经常遇到这种情况。

如果没有 HTTP Keep Alive,我们不会收到该错误。

但在 1 秒和 5 秒的不同场景中,我们经常会得到它。

我们在 Wireshark 上观察到,由于 RTT(往返时间)较高,请求花费的时间比预期的要长。 场景是数据包流不一致:

如果存活时间为 5 秒:

  1. 成功处理请求后,它将返回 200 OK(成功响应)和 5 秒的超时参数(服务器试图告诉客户端服务器将在关闭此连接之前等待 5 秒)。

  2. 现在,只要 5 秒时间过去,服务器就会发送一个 FIN 数据包(用于关闭连接的完成数据包从服务器发送到客户端,在我们的例子中是浏览器)。

  3. 现在这里是捕获来自客户端的 ACK(确认数据包)关闭连接的时间很高(高 RTT)。

  4. 现在服务器已启动关闭,但由于在关闭连接之前 RTT 较高,客户端在服务器从客户端收到 FINISH 的 ACK 之前发送一个新的 HTTP 请求(例如 ExampleABC.do 请求)。

  5. 因为哪个服务器无法处理该请求,因为它已启动连接关闭。

将 1 秒设置为保持活动状态意味着我们正在减少服务器等待关闭连接的时间,因为我们希望在 1 秒后关闭一个连接,并为新请求设置新连接,以避免 5 秒后出现不需要的请求.

提前致谢 这是我的第一篇文章,如果需要请纠正我。 抱歉英语不好:)

通讯失败图片:

【问题讨论】:

  • 需要 TCP 专家的帮助,他们可以告诉我们造成这种不一致的原因。
  • 我们通过同步浏览器超时和服务器超时解决了这个问题。

标签: http https webserver keep-alive


【解决方案1】:

我们通过同步浏览器超时和服务器超时解决了这个问题。

修复是确保 TCP keepalive 时间和浏览器一致或同时出现,导致 TCP 连接完全断开。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-02-13
    • 2016-04-03
    • 1970-01-01
    • 2017-07-31
    • 1970-01-01
    相关资源
    最近更新 更多