小丸子学习HTTP2

多路复用

在同一个tcp连接上，有多个stream，由各个stream发送和接收http请求，各个steam相互独立，互不阻塞。

一个TCP连接开销有多大

我们知道计算机网络五层协议。网络层的IP协议是无连接的，不可靠的，一言不合就丢包。

而传输层的TCP协议是可靠的面向连接的字节流服务。在TCP协议中，接收方会设定一个定时器，在规定时间内得不到发送方的数据，就要求发送方重传。

那岂不是，在一个网络不好的环境中，会有大量要求重传的包和正在重传的包，堵塞网络，致使路由器缓存不足，导致包全部丢失，再次进入恶性循环，整个网络陷入瘫痪。

所以，TCP协议有一个防止网络阻塞的算法：拥塞避免。

是怎么避免的呢。

1. TCP协议首先认为网络是不堵塞的。
2. 然后等一个TCP连接建立之后，发送方先去发一个包，假设定时器超时之内接到接收方的ACK，发送方开始发两个包，又接到了ACK，发送方发4个包，8个包，16个包等等，指数增长。这个阶段叫慢启动。
3. 直到发送n个包的时候，
   
   • 如果这个时候发送方接收到了重复确认，也就是说某一个包丢了，这时候发送方认为网络环境比较差了，进入拥塞避免阶段。开始设定一个值m=n/2。从m个包开始发，每次加1。比如第一次m个包，第二次发m+1个包。
   • 如果定时器超时了，还是没有接收到任何ACK，接收方就知道现在网络极其差劲，重新进入慢启动状态。即2。

实际上，TCP的性能在拥塞避免阶段还是很高的。在慢启动阶段，性能利用率很低呀。但是每一个TCP连接都要经历一个慢启动过程。

所以使用多路复用，让多个包复用一个TCP连接，响应速度的提升是很客观的。

http1.1 pipeling的服务端队首阻塞问题

对于同一个tcp连接，http1.1允许一次发送多个http1.1请求。但是，http1.1规定，服务器端的响应的发送要根据请求被接收的顺序排队，也就是说，先接收到的请求的响应也要先发送。这样造成的问题是，如果最先收到的请求的处理时间长的话，响应生成也慢，就会阻塞已经生成了的响应的发送。也会造成 队首阻塞问题。

而HTTP2无论在客户端还是在服务器端都不需要排队，在同一个tcp连接上，有多个stream，由各个stream发送和接收http请求，各个steam相互独立，互不阻塞。
——–https://www.cnblogs.com/hustdc/p/8487366.html

只有幂等的请求（GET，HEAD）能使用pipelining，非幂等请求比如POST不能使用，因为请求之间可能会存在先后依赖关系。

同一个源的资源共用同一个TCP连接

这个建立多路复用的基础上。大大减小了TCP的连接数。

头部压缩

只有第一次发请求的时候，发送完整的头部，接下来的请求就会发送省略的头部信息，依靠服务端的头部缓存在识别喽。这个是压缩了包的体积。

服务器推送

我还米有试过，我们还没上HTTP2喵。

权重

不同的资源可以有不同的权重。

二进制分帧

既然又要保证HTTP的各种动词，方法，首部都不受影响，那就需要在应用层(HTTP2.0)和传输层(TCP or UDP)之间增加一个二进制分帧层。

在二进制分帧层上，HTTP 2.0 会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码 ，其中HTTP1.x的首部信息会被封装到Headers帧，而我们的request body则封装到Data帧里面。

然后，HTTP 2.0通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。相应地，每个数据流以消息的形式发送，而消息由一或多个帧组成，这些帧可以乱序发送，然后再根据每个帧首部的流标识符重新组装。
——-https://blog.csdn.net/u011904605/article/details/53012844