HTTP/0.9

1996年公布了HTTP/1.0，在这之前的协议成为HTTP/0.9

HTTP/0.9规范：

  1. request只有一行且只有一个GET命令，命令后跟着资源路径：GET /index.$html$
  2. response只包含文件内容本身

❌ 缺陷：

  1. 没有header的概念
  2. 没有Content-Type的概念，只能传递HTML文件
  3. 没有状态码statusCode，通过返回一个错误描述的html文件表示异常

HTTP/1.0

  1. 构建请求行和响应行
    1. 请求行增加schema和版本号
    2. 增加响应行：HTTP/1.0 200 Success
  2. 增加头部概念header：请求头，响应头
    1. 增加Content-Type来支持不同编码格式的文件传输
    2. 支持长连接Connection: keep-alive | close

  3. 请求方法增加了POST和HEAD命令

    请求头

    Content-Type

  4. text/plan

  5. text/html
  6. text/css
  7. image/jpeg
  8. image/png
  9. image/svg+xml
  10. application/javascript
  11. application/zip
  12. application/pdf

Content-encoding

  1. gzip采用LZ77压缩算法
  2. compress采用LZW压缩算法
  3. deflate采用zlib压缩算法

客户端传Accept-Encoding: gzip, deflate表示客户端支持此两种压缩算法
服务端传Content-Encoding: gzip表示实际采用了gzip的压缩算法

❌ 缺陷：

  1. 对头阻塞
    1. 每个TCP连接只能发送一个请求，请求响应结束则关闭连接。
    2. 如果要请求多个资源，需要新建多个连接
  2. 默认是短连接，每个资源请求都需要经过三次握手建立连接，四次挥手关闭连接

HTTP/1.1

  1. 可重复使用连接keep-alive，不再需要多次打开才能显示嵌入在单个原始文档中的资源
  2. 添加了Pipeline，允许在第一个请求完成之前发送第二个请求，降低了通信的延迟
  3. chunked机制，分块响应
    1. 动态资源，无法在传输之前知道待传递资源的大小
    2. Transfer-Encoding: chunked
  4. 引入缓存控制机制，及内容协商

  5. 增加了Host头部

    1. 从同一IP地址托管不同域的能力允许服务器搭配

    2. 1.0 默认每台服务器绑定一个唯一的IP，1.1 中加入Host处理一个IP地址上面多个虚拟主机的情况


      ⚠️ keep-alive中是默认关闭的（默认短连接）
      只属于程序员的自定义行为，在 1.0 中没有被纳入标准

❌ 缺陷：

  1. 高延迟，队头阻塞导致宽带无法被充分利用
  2. 无状态特性，巨大的http头部
  3. 明文传输，不安全

  4. 不支持服务器推送

    管道化持久连接

    🚫 管道化有几条限制：

  5. 客户端不支持成就连接，就不应该使用管道

  6. 必须按照请求相同的顺序响应，否则响应失序就无法与请求匹配
  7. 客户端必须做好随时连接关闭的准备，还要准备好重发所有未完成的管道化请求
    1. 比如客户端发出10个请求，服务端处理完5个之后就关闭了连接，剩下5个请求失败
  8. 管道化不应发送会产生副作用的请求（比如POST）

❌ 缺陷：

  1. 管道化持久连接，可以解决长肥管道的网络时延。但仍无法解决队头阻塞问题，因为响应顺序需要和请求顺序一致

长肥管道：拥有长RRT：Round Trip Time 往返时间和高的宽带
幂等：如果一个事物，不管是执行一次还是很多次，得到的结果都相同，这个事物就是幂等的

关闭连接的问题

服务器会在管道空闲的时候关闭它，可是如何判断管道是空闲呢？
可能服务器关闭时，客户端正在写入数据：此时客户端就会在写入半截请求报文时发现出现了连接错误

HTTP2和HTTP1.1的性能对比：地址
image.png