LinHuijuan's Blog

HTTP发展

# HTTP发展

[TOC]

# 一、HTTP/0.9

简单的文本协议，只能获取文本资源。

# 二、HTTP/1.0

确立了大部分现在使用的技术，但不是正式标准。

# 三、HTTP/1.1

目前互联网使用最广泛的协议，功能也非常完善。

# 3.1 持久连接/长连接/连接复用（HTTP Persistent Connections， 也称为 HTTP keep-alive 或HTTP connection reuse）

建立 1 次 TCP 连接后进行多次请求和响应的交互。

成本均摊：既然TCP的连接和关闭非常耗时间，那么就把这个时间成本由原来的一个请求应答均摊到多个请求应答上。

请求头使用字段:Connection:keep-alive。

persistent-connections

  • 好处：
    1. 减少了 TCP 连接的重复建立和断开所造成的额外开销。
    2. 减轻了服务器端的负载。
    3. 使HTTP 请求和响应能够更早地结束， Web 页面显示速度提高了。
    4. 更容易实现全速传输，因为新开一个 TCP 连接需要慢慢提升传输速度。
  • 不足：
    • 因为TCP连接长时间不关闭，服务器必须在内存里保存它的状态，这就占用了服务器的资源。如果有大量的空闲长连接只连不发，就会很快耗尽服务器资源，导致服务器无法为真正有需要的用户提供服务。
    • 解决：服务端和客户端都可以在恰当的时间关闭长连接。
      • 客户端的请求头Connection:close，告诉服务器这次通信后就关闭连接。

# 3.2 问题

# 3.2.1 高延迟带来页面加载速度的降低

为了尽可能减少请求数，需要做合并文件、雪碧图、资源内联等优化工作，但是这无疑造成了单个请求内容变大延迟变高的问题，且内嵌的资源不能有效地使用缓存机制。

  • 现状

    • 随着带宽的增加，延迟并没有显著下降。
    • 并发连接有限。（浏览器限制）
    • 线头阻塞问题：同一连接同时只能在完成一个HTTP事务（请求/响）才能处理下一个事务。

  • 解决策略

    • 理想中的长肥管道：源源不断地发送，源源不断地接收，而不是单连接上地串行请求（一次发送一次接收，一次发送一次接收...）。
    • http1.1还做不到这一点。

# 3.2.2 无状态特性带来地巨大HTTP头部

  • 每一次请求都要加上完整的HTTP头部。
  • Header 内容多，而且每次请求 Header 不会变化太多，没有相应的压缩传输优化方案。

# 3.2.3 服务器不能主动推送

要通过轮询来获取服务器改动的文件，而服务器不能主动推送。

# 3.2.4 明文传输不安全

# 3.3 为解决性能做过的努力

  1. Spriting 合并多张小图为一张大图，供浏览器JS切割使成小图用。
  2. Inlining内联，将图片嵌入到CSS或者HTML文件中，减少网络请求次数。
    • 将图片压缩成base64格式。
  3. Concatenation 拼接，将多个体积较小的 JavaScript 使用 webpack 等工具打包成一个体积更大的J avaScript文件。
    • 1个文件的改动导致用户重新下载多个文件。
  4. 域名分片，将同一页面的资源分散到不同域名（比如二级子域名）下，提升连接上限。
    • 对于同一个域名，浏览器最多只能同时创建 6~8 个 TCP 连接 (不同浏览器不一样)。

# 四、HTTP/2

参考教程：HTTP2 详解 (opens new window)

  • 仅在应用层上修改，基于且充分挖掘TCP协议性能。
  • 客户端向server发送request这种模型不会变。
  • 老的scheme不会变，没有http2://，还是http://和https://。
  • 使用http/1.x的客户端和服务器可以无缝的通过代理方式转接到http/2上。
  • 不识别http/2的代理服务器可以将请求降级到http/1.x。

# 4.1 主要特性

# 4.1.1 支持服务端推送

  • 浏览器发送一个请求，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求。
  • 并行推送。
  • Server-Push 主要是针对资源内联做出的优化，相较于 http/1.1 资源内联的优势:
    • 客户端可以缓存推送的资源
    • 客户端可以拒收推送过来的资源
    • 推送资源可以由不同页面共享
    • 服务器可以按照优先级推送资源

# 4.1.2 支持TCP多路复用（管线化-pipelining)

  • TCP多路复用，就是使用同一个TCP连接就可以源源不断传输多个HTTP请求。 把 HTTP/1.1 每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方。
  • 流的概念实现了单连接上多请求 - 响应并行，解决了线头阻塞的问题，减少了 TCP 连接数量和 TCP 连接慢启动造成的问题。

Note: 其实很多优化涉及更下层的协议。IP层的分包情况，和物理层的建连时间是需要被考虑的。

# 4.1.3 传输数据量的大幅减小

  • 以二进制方式传输。
    • 帧是数据传输的最小单位，以二进制传输代替原本的明文传输，原本的报文消息被划分为更小的数据帧。
  • Header压缩。
    • 使用HPACK算法来压缩首部内容。

# 4.2 可弃用的HTTP/1优化方案

合并文件、内联资源、雪碧图、域名分片对于 HTTP/2 来说是不必要的，使用 h2 尽可能将资源细粒化，文件分解地尽可能散，不用担心请求数多。

# 五、HTTP/3

必知的HTTP协议