快速掌握HTTP1.0 1.1 2.0 3.0的特点及其区别( 三 )


向前纠错牺牲了每个数据包可以发送数据的上限 , 但是带来的提升大于丢包导致的数据重传 , 因为数据重传将会消耗更多的时间(包括确认数据包丢失 , 请求重传 , 等待新数据包等步骤的时间消耗) 。
例如:

  • 我总共发送三个包 , 协议会算出这个三个包的异或值并单独发出一个校验包 , 也就是总共发出了四个包 。
  • 当其中出现了非校验包丢失的情况 , 可以通过另外三个包计算出丢失的数据包的内容 。
  • 当然这种技术只能使用在丢失一个包的情况下 , 如果出现丢失多个包 , 就不能使用纠错机制了 , 只能使用重传的方式了 。
问题归纳HTTP1.1的合并请求(如CSSsprites)是否适用于HTTP2.0没有必要 。
在头部压缩技术中 , 客户端和服务器均会维护两份相同的静态字典和动态字典 。
在静态字典中 , 包含了常见的头部名称与值的组合 。 静态字典在首次请求时可以使用 。 那么现在头部的字段就可以被简写成静态字典中相应字段的index 。
而动态字典跟连接的上下文相关 , 每个HTTP/2连接维护的动态字典不尽相同 。 动态字典可以在连接不停地进行更新 。
也就是说 , 原本完整的HTTP报文头部的键值或字段 , 由于字典的存在 , 现在可以转换成索引index , 在相应的端再进行查找还原 , 也就起到了压缩的作用 。
所以 , 同一个链接上产生的请求和响应越多 , 动态字典累积得越全 , 头部压缩的效果也就越好 , 所以针对HTTP/2网站 , 最佳实践是不要合并资源 。
另外 , HTTP2.0多路复用 , 使得请求可以并行传输 , 而HTTP1.1合并请求的一个原因也是为了防止过多的HTTP请求带来的阻塞问题 。 而现在HTTP2.0已经能够并行传输了 , 所以合并请求也就没有必要了 。
为什么要有HTTP3.0:HTTP/2底层TCP的局限带来的问题由于HTTP/2使用了多路复用 , 一般来说 , 同一个域名下只需要使用一个TCP链接 , 但当这个连接中出现了丢包的情况 , 就会导致HTTP/2的表现情况反倒不如HTTP/2了 。
原因是: 在出现丢包的额情况下 , 整个TCP都要开始等待重传 , 导致后面的所有数据都被阻塞 。
但是对于HTTP/1.1来说 , 可以开启多个TCP连接 , 出现这种情况只会影响其中一个连接 , 剩余的TCP链接还可以正常传输数据 。
由于修改TCP协议是不可能完成的任务 。
如何在Chrome中启用 QUIC 协议MTF在资源服务器和内容分发节点都已经启用了 HTTP3.0 协议 , 根据 用户浏览器 向下兼容 , 强烈建议您在Chrome浏览器开启实验性QUICK协议支持 , 体验加速效果:
  1. 在浏览器地址栏:输入chrome://flags
  2. 找到Experimental QUIC protocol , 将Default改为Enabled

快速掌握HTTP1.0 1.1 2.0 3.0的特点及其区别文章插图
总结HTTP 1.0
  • 无状态 , 无连接
  • 短连接:每次发送请求都要重新建立tcp请求 , 即三次握手 , 非常浪费性能
  • 无host头域 , 也就是http请求头里的host ,
  • 不允许断点续传 , 而且不能只传输对象的一部分 , 要求传输整个对象
HTTP 1.1
  • 长连接 , 流水线 , 使用connection:keep-alive使用长连接
  • 请求管道化
  • 增加缓存处理(新的字段如cache-control)
  • 增加Host字段 , 支持断点传输等
  • 由于长连接会给服务器造成压力
HTTP 2.0
  • 二进制分帧
  • 头部压缩 , 双方各自维护一个header的索引表 , 使得不需要直接发送值 , 通过发送key缩减头部大小
  • 多路复用(或连接共享) , 使用多个stream , 每个stream又分帧传输 , 使得一个tcp连接能够处理多个http请求
  • 服务器推送(Sever push)
HTTP 3.0


推荐阅读