iOS 12.5.1 正式版发布

由于HTTP / 2不需要适应网站和应用程序，因此这种快速的采用率很可能是：使用HTTP / 1.1或HTTP / 2对它们是透明的。使用最新的服务器与最新的浏览器进行通信就足以启用它：仅需要有限的一组组即可触发采用，并且随着旧版浏览器和服务器版本的更新，使用量自然增加了，而无需使用其他Web开发人员的努力。

Http2.0必须建立在TLS的基础上，也就是必须是Https的请求。

问题

1.http1.1长连接keep-alive和http2.0的多路复用有什么区别?

• http1.1 keep-alive 是不关闭 TCP 连接，也就是长连接;
  • 在不使用管道机制的情况下，交互是单工的，即客户端必须要等前一个请求的响应返回之后，新的请求才能发过去。
  • 在使用管道机制的情况下，请求发送可以非阻塞，但是响应返回必须依然严格按照请求的顺序。

http2.0多路复用则是基于流的，那么在传输的时候，无论请求还是响应，只要逻辑上允许就可以传输，如果两个请求没有依赖关系可以不必等待前一个返回而直接发送，虽说用的是同一条连接。

2.什么是流水线(管道机制)?

默认情况下，HTTP 请求是按顺序发出的。下一个请求只有在当前请求收到应答过后才会被发出。由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上发出连续的请求，而不用等待应答返回。这样可以避免连接延迟。理论上讲，性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。就算 HTTP 请求不断的继续，尺寸会增加，但设置 TCP 的 MSS(Maximum Segment Size) 选项，仍然足够包含一系列简单的请求。

并不是所有类型的 HTTP 请求都能用到流水线：只有 idempotent 方式，比如 GET、HEAD、PUT 和 DELETE 能够被安全的重试：如果有故障发生时，流水线的内容要能被轻易的重试。

今天，所有遵循 HTTP/1.1 的代理和服务器都应该支持流水线，虽然实际情况中还是有很多限制：一个很重要的原因是，目前没有浏览器默认启用这个特性。

问题RFC 2616 中规定了：

一个支持持久连接的客户端可以在一个连接中发送多个请求(不需要等待任意请求的响应)。收到请求的服务器必须按照请求收到的顺序发送响应。

至于标准为什么这么设定，我们可以大概推测一个原因：由于 HTTP/1.1 是个文本协议，同时返回的内容也并不能区分对应于哪个发送的请求，所以顺序必须维持一致。比如你向服务器发送了两个请求 GET/query?q=A 和 GET/query?q=B，服务器返回了两个结果，浏览器是没有办法根据响应结果来判断响应对应于哪一个请求的。

Pipelining 这种设想看起来比较美好，但是在实践中会出现许多问题：

• 一些代理服务器不能正确的处理 HTTP Pipelining。
• 正确的流水线实现是复杂的。
• Head-of-line Blocking 连接头阻塞：在建立起一个 TCP 连接之后，假设客户端在这个连接连续向服务器发送了几个请求。按照标准，服务器应该按照收到请求的顺序返回结果，假设服务器在处理首个请求时花费了大量时间，那么后面所有的请求都需要等着首个请求结束才能响应。

所以现代浏览器默认是不开启 HTTP Pipelining 的。

由于这些原因，流水线已经被更好的算法给代替，如multiplexing多路复用，已经用在 HTTP/2。

HTTP1.X链接管理

• 左边短链接
• 中间长连接
• 右边管道机制

（编辑：济宁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!