【问题标题】:Browsers and HTTP 1.1 Peristent Connections浏览器和 HTTP 1.1 持久连接
【发布时间】:2014-07-24 21:49:27
【问题描述】:

我了解 HTTP/1.1 持久连接的价值:浏览器可以在单个连接中获取 CSS/Javascript/Image 文件等辅助资源。

我不明白的是 HTTP 协议如何指示何时应关闭持久连接。是否由客户端或服务器来结束会话?

客户端似乎更容易知道会话何时“结束”,因为客户端可能正在解析主要的 HTML 资源,并识别各种子资源(javascript/css/images 等) .) 当客户端完成解析并识别出最后一个“子资源”时,它可以向服务器发送一个“连接:关闭”。然而,在实践中,使用 Firefox HTTP Live-headers 插件证明这实际上不会发生。

那么 HTTP/1.1 协议如何指示没有更多内容可下载,会话应该终止?

【问题讨论】:

    标签: html http


    【解决方案1】:

    根据RFC 2616, Section 8

    第 8.1.2 节总体操作

    (强调我的)

    持久连接提供了一种机制,通过该机制客户端和服务器可以发出 TCP 连接关闭的信号。 此信号使用 Connection 标头字段14.10 部分)进行。发出关闭信号后,客户端不得再在该连接上发送任何请求。

    第 8.1.4 节实际考虑

    当客户端或服务器希望超时时,它应该在传输连接上发出正常关闭。客户端和服务器都应该不断地观察传输关闭的另一端,并在适当的时候做出响应。如果客户端或服务器没有及时检测到对方的关闭,可能会导致网络上不必要的资源消耗。

    请注意,RFC 中的“应该”与“必须”不同 - 客户端没有义务发送 close 标头。继续第 8.1.4 节(强调我的):

    这意味着客户端、服务器和代理必须能够从异步关闭事件中恢复。客户端软件应该在没有用户交互的情况下重新打开传输连接并重新传输中止的请求序列,只要请求序列是幂等的(参见第 9.1.2 节)。非幂等方法或序列不得自动重试,尽管用户代理可以为人工操作员提供重试请求的选择。具有应用程序语义理解的用户代理软件的确认可以替代用户确认。如果第二个请求序列失败,则不应重复自动重试。

    在实践中:

    服务器在客户端的最后一次请求之后在预设超时后通过发送Connection: close 标头来关闭连接,客户端只是处理它。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-05-28
      • 1970-01-01
      • 2014-01-12
      • 1970-01-01
      • 2021-12-12
      相关资源
      最近更新 更多