HTTP协议的不足（HTTP/1.1）
-
同一时间，一个连接只能对应一个请求
针对同一个域名，大多数浏览器允许同时最多6个并发连接 -
只允许客户端主动发起请求
一个请求只能对应一个响应 -
同一个会话的多次请求中，头信息会被重复传输
通常会给每个传输增加500~ 800字节的开销
如果使用Cookie,增加的开销有时会达到上千字节
SPDY
-
SPDY (speedy的缩写)，是基于TCP的应用层协议，它强制要求使用SSL/TLS
2009年11月，Google宣布将SPDY作为提高网络速度的内部项目 -
SPDY与HTTP的关系
1、SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式
2、只需增加一个SPDY层，现有的所有服务端应用均不用做任何修改
3、SPDY是HTTP/2的前身
3、2015年9月，Google宣布移除对SPDY的支持， 拥抱HTTP/2
HTTP与SPDY.png
HTTP/2
-
HTTP/2，于2015年5月以RFC 7540正式发表
根据W3Techs的数据，截至2019年6月， 全球有36.5%的网站支持了HTTP/2 -
HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容
1、比如请求方法(如GET、 POST) 、Status Code、各种Headers等都没有改变
2、因此，要想升级到HTTP/2，开发者不需要修改任何代码，只需要升级服务器配置、升级浏览器
HTTP/2的特性
1.二进制格式
HTTP/2格式.png
-
HTTP/2采用二进制格式传输数据，而非HTTP/1.1的文本格式
-
二进制格式在协议的解析和优化扩展上带来更多的优势和可能
2.一些基本概念
-
数据流:已建立的连接内的双向字节流，可以承载一条或多条消息
所有通信都在一个TCP连接.上完成，此连接可以承载任意数量的双向数据流 -
消息:与逻辑HTTP请求或响应消息对应，由一系列帧组成
-
帧: HTTP/2通信的最小单位，每个帧都包含帧头( 会标识出当前帧所属的数据流)
来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装
发送帧.png
3.多路复用
多路复用可以在一个连接里，将多个数据流的帧交替发送，在接收的时候再将这些帧分成多个数据流。
多路复用.png
HTTP/2多路复用使用一个TCP连接就可以传输多个文件，而HTTP/1.1多个文件就需要多个TCP连接。
多路复用对比.png
-
客户端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一 端把它们重新组装起来
-
并行交错地发送多个请求，请求之间互不影响
-
并行交错地发送多个响应，响应之间互不干扰
-
使用一个连接并行发送多个请求和响应
-
不必再为绕过HTTP/1.1限制而做很多工作
1、比如image sprites、 合并CSS\JS、 内嵌CSS\JS\Base64图片、 域名分片等
2、这些做法都是为了减少请求数量，因为HTTP/1.1每个请求都是一个连接，每个连接都是耗费时间，浏览器最多同时处理6个连接。 -
image sprites (也叫做CSS Sprites) ，将多张小图合并成一张大图
最后通过CSS结合小图的位置、 尺寸进行精准定位
图片.png
4.优先级
-
HTTP/2标准允许每个数据流都有一个关联的权重和依赖关系
1、可以向每个数据流分配一个介于1至256之间的整数
2、每个数据流与其他数据流之间可以存在显式依赖关系 -
客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应
-
服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级
在资源数据可用之后,确保将高优先级响应以最优方式传输至客户端.
优先级树.png
- 应尽可能先给父数据流分配资源
- 同级数据流(共享相同父项)应按其权重比例分配资源
- A、B依赖于隐式“根数据流”，A获得的资源比例是12/16，B获得的资源比例是4/16
- D依赖于根数据流，C依赖于D，D应先于C获得完整资源分配
- D应先于C获得完整资源分配，C应先于A和B获得完整资源分配，B获得的资源是A所获资源的1/3
- D应先于E和C获得完整资源分配，E和C应先于A和B获得相同的资源分配，B获得的资源是A所获资源的1/3
5.头部压缩
-
HTTP/2使用HPACK压缩请求头和响应头
可以极大减少头部开销，进而提高性能 -
早期版本的HTTP/2和SPDY使用zlib压缩
可以将所传输头数据的大小减小85%~88%，但在2012年夏天，被攻击导致会话劫持，后被更安全的HPACK取代
头部压缩.png
图解：
第一个请求发送后，第二个请求再发送，会跟踪上一次的请求，使用压缩算法去掉同样的请求头部分，只会发送和上个请求头不同的部分。接收方再根据压缩算法通过上一次的请求来拿到去掉的部分。
压缩算法实现.png
图解：
发送方和接收方都会维护一个头信息的表，表由静态表和动态表2部分组成。静态表就放一些固定的头信息，动态表放一些变动的头信息。每个头信息有一个编号。那么在发送头信息时，根据之前已发送的请求，只需要把之前发送过的相同的头信息的编号还有不同的头信息发过去，接收方就可以根据编号组成完整的头信息。
6.服务器推送
-
服务器可以对一个客户端请求发送多个响应
除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求
发送多个响应.png
7.队头阻塞
QUIC解决阻塞.png
- 假设使用HTTP/2发送三个请求，其中最前面的红色数据包丢失
- SPDY方式：接收方会等待红色数据重新发送过来，从而导致阻塞。
- QUIC方式：不会阻塞。
QUIC原理示意图.png
-
QUIC底层使用的是UDP协议，只管发送，不会管是否接收到。
既然使用的是UDP协议，那么如何保证传输可靠性呢？可靠性由QUIC这层来处理。
8.握手延迟
握手时间对比.png
- RTT (Round Trip Time) :往返时延，可以简单理解为通信一来一回的时间
- QUIC使用的是UDP协议，不需要握手，直接发送数据。
HTTP/3
Google觉得HTTP/2仍然不够快， 于是就有了HTTP/3
HTTP/3由Google开发, 弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
QUIC (Quick UDP Internet Connections) ，译为:快速UDP网络连接,由Google开发, 在2013年实现
于2018年从HTTP-over-QUIC改为HTTP/3
各版本HTTP协议结构.png
HTTP/3特性
1.连接迁移
-
TCP基于4要素(源IP、源端口、目标IP、目标端口)
1、切换网络时至少会有一个要素发生变化，导致连接发生变化
2、当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时
3、所以我们有时候发现切换到一个新网络时，即使新网络状况良好,但内容还是需要加载很久
4、如果实现得好，当检测到网络变化时立刻建立新的TCP连接,即使这样,建立新的连接还是需要几百毫秒的时间 -
QUIC的连接不受4要素的影响，当4要素发生变化时,原连接依然维持
1、QUIC连接不以4要素作为标识，而是使用一组Connection ID (连接ID)来标识一个连接，Connection ID根据4要素得到。
2、即使IP或者端口发生变化，只要Connection ID没有变化，那么连接依然可以维持。
3、比如：
①当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
②当Wi- Fi连接不再可用时，将连接转移到蜂窝网络连接
HTTP/3的问题
-
据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量
1、Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
2、TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在
网友评论