可以做来电名片的网站,青岛做网站皆赴青岛博采,全国建设建管中心网站,建设自己网站需要多钱连接管理是一个 HTTP 的关键话题#xff1a;打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有多种模型#xff1a;短连接、_长连接_和 HTTP 流水线。 下面分别来详细解释
短连接
HTTP 协议最初#xff08;0.9/1.0#xff09;是个非常简单的…连接管理是一个 HTTP 的关键话题打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有多种模型短连接、_长连接_和 HTTP 流水线。 下面分别来详细解释
短连接
HTTP 协议最初0.9/1.0是个非常简单的协议通信过程也采用了简单的 “请求 - 应答” 方式。 它底层的数据传输基于 TCP/IP每次发送请求前需要先与服务器建立连接收到响应报文后会立即关闭连接。 因为客户端与服务器的整个连接过程很短暂不会与服务器保持长时间的连接状态所以就被称为 “短连接”short-lived connections。早期的 HTTP 协议也被称为是 “无连接” 的协议。
这是 HTTP/1.0 的默认模型如果没有指定 Connection 协议头或者是值被设置为 close。而在 HTTP/1.1 中只有当 Connection 被设置为 close 时才会用到这个模型。
问题
在 TCP 协议里建立连接和关闭连接都是非常 “昂贵” 的操作。TCP 建立连接要有“三次握手”发送 3 个数据包需要 1 个 RTT关闭连接是“四次挥手”4 个数据包需要 2 个 RTT。 而 HTTP 的一次简单 “请求 - 响应” 通常只需要 4 个包如果不算服务器内部的处理时间最多是 2 个 RTT。这么算下来浪费的时间就是“3÷560%”有三分之二的时间被浪费掉了传输效率低得惊人。
长连接
针对短连接暴露出的缺点HTTP 协议就提出了 “长连接” 的通信方式也叫 “持久连接”persistent connections、“连接保活”keep alive、“连接复用”connection reuse。 把 TCP 的连接和关闭时间成本由原来的一个 “请求 - 应答” 均摊到多个 “请求 - 应答” 上。 这样虽然不能改善 TCP 的连接效率但基于 “分母效应”每个 “请求 - 应答” 的无效时间就会降低不少整体传输效率也就提高了。 短连接与长连接的对比示意图。
缺点
就算是在空闲状态它还是会消耗服务器资源而且在重负载时还有可能遭受 DoS 攻击。这种场景下可以使用非长连接即尽快关闭那些空闲的连接也能对性能有所提升。
HTTP/1.0 里默认并不使用长连接。把 Connection 设置成 close 以外的其他参数都可以让其保持长连接通常会设置为 retry-after。 在 HTTP/1.1 里默认就是长连接的不再需要标头但我们还是会把它加上万一某个时候因为某种原因要退回到 HTTP/1.0 呢。
HTTP 流水线
默认情况下HTTP 请求是按顺序发出的。下一个请求只有在当前请求收到响应过后才会被发出。由于会受到网络延迟和带宽的限制在下一个请求被发送到服务器之前可能需要等待很长时间。 流水线是在同一条长连接上发出连续的请求而不用等待应答返回。这样可以避免连接延迟。理论上讲性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。就算 HTTP 请求不断的继续尺寸会增加但设置 TCP 的最大分段大小MSS选项仍然足够包含一系列简单的请求。
并不是所有类型的 HTTP 请求都能用到流水线只有幂等方式比如 GET、HEAD、PUT 和 DELETE 能够被安全地重试。如果有故障发生时流水线的内容要能被轻易的重试。 今天所有遵循 HTTP/1.1 标准的代理和服务器都应该支持流水线虽然实际情况中还是有很多限制一个很重要的原因是目前没有现代浏览器默认启用这个特性。
缺点
● 正确的实现流水线是复杂的传输中的资源大小、多少有效的 RTT 会被用到以及有效带宽都会直接影响到流水线提供的改善。不知道这些的话重要的消息可能被延迟到不重要的消息后面。这个重要性的概念甚至会演变为影响到页面布局因此 HTTP 流水线在大多数情况下带来的改善并不明显。 ● 流水线受制于队头阻塞HOL问题。
由于这些原因流水线已被 HTTP/2 中更好的算法——多路复用multiplexing所取代。
