趣谈网络协议干货-HTTP
正常一条网络请求需要经过的流程是这样：
1.DNS 解析，请求DNS服务器，获取域名对应的 IP 地址。
2.与服务端建立连接，包括 tcp 三次握手，安全协议同步流程。
3.连接建立完成，发送和接收数据，解码数据。
HTTP的请求的发送
HTTP 协议是基于TCP协议的（不了解TCP的可以看下这篇文章趣谈网络协议干货-TCP和UDP）。所以它使用的是面向连接的方式发送，通过stream二进制流的方式传送给对方。当然，到了TCP层，它会把二进制流变成一个的报文段发送给服务器。
keep-alive
HTTP 协议里有个 keep-alive，HTTP1.1默认开启，一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接，而是放入连接池中，若这时有另一个请求要发出，请求的域名和端口是一样的，就直接拿出连接池中的连接进行发送和接收数据，少了建立连接的耗时。
实际上现在无论是客户端还是浏览器都默认开启了keep-alive，对同个域名不会再有每发一个请求就进行一次建连的情况，纯短连接已经不存在了。但有个问题，就是这个 keep-alive 的连接一次只能发送接收一个请求，在上一个请求处理完成之前，无法接受新的请求。若同时发起多个请求，就有两种情况：
若串行发送请求，可以一直复用一个连接，但速度很慢，每个请求都要等待上个请求完成再进行发送。
若并行发送这些请求，那么首次每个请求都要进行tcp三次握手建立新的连接，虽然第二次可以复用连接池里这堆连接，但若连接池里保持的连接过多，对服务端资源产生较大浪费，若限制了保持的连接数，并行请求里超出的连接仍每次要建连。
对这个问题，新一代协议 HTTP2 提出了多路复用去解决。
多路复用
HTTP1.1的协议里，在一个连接里传送数据都是串行顺序传送的，必须等上一个请求全部处理完后，下一个请求才能进行处理，导致这些请求期间这条连接并不是满带宽传输的，即使是HTTP1.1的pipelining可以同时发送多个request，但response仍是按请求的顺序串行返回，只要其中一个请求的response稍微大一点或发生错误，就会阻塞住后面的请求。
HTTP2 这里的多路复用协议解决了这些问题，它把在连接里传输的数据都封装成一个个stream，每个stream都有标识，stream的发送和接收可以是乱序的，不依赖顺序，也就不会有阻塞的问题，接收端可以根据stream的标识去区分属于哪个请求，再进行数据拼接，得到最终数据。
分帧 二进制编码
HTTP1.1在应用层以纯文本的形式进行通信。每次通信都要带完整的HTTP头。在实时性并发性上都存在问题。
为了解决这些问题，HTTP2.0 会对HTTP的头进行一定的压缩，将原来每次都要携带的大量的key value 在两端建议一个索引表，对相同的头只发送索引表中的索引。
HTTP2.0还将所有的传输数据切割为更小的消息和帧。并对他们采用二进制格式编码。常见的帧的Header帧，用于传输Header流，并且会开启一个新的流。再就是Data帧，用来传输正文实体。
通过这两种机制，HTTP2.0将多个请求分到不同的流中，然后将请求内容拆成帧，进行二进制传输。这些帧可以打散乱序发送，然后根据每个帧首部的流标示符重新组装，并且可以根据优先级，决定先处理哪个流
TCP队头阻塞
HTTP2 的多路复用看起来是完美的解决方案，但还有个问题，就是队头阻塞，这是受限于 TCP 协议，TCP 协议为了保证数据的可靠性，若传输过程中一个 TCP 包丢失，会等待这个包重传后，才会处理后续的包。HTTP2的多路复用让所有请求都在同一条连接进行，中间有一个包丢失，就会阻塞等待重传，所有请求也就被阻塞了。
对于这个问题不改变 TCP 协议就无法优化，但 TCP 协议依赖操作系统实现以及部分硬件的定制，改进缓慢，于是 GOOGLE 提出 QUIC 协议，相当于在 UDP 协议之上再定义一套可靠传输协议，解决 TCP 的一些缺陷，包括队头阻塞。
QUIC 协议通过基于UDP的自定义类似于TCP的连接、重试、多路复用、流量控制技术进一步提升性能
机制一：自定义连接机制
不再以四元组标识而是以一个64位的随机数作为ID来标示，而且UDP是无连接的。所以当IP或者端口号变化的时候，只要ID不变，就不需要重新建立连接
机制二：自定义重传机制
定义了一个offset概念。可以通过offset查看数据发送到了哪里，这样只要offset的包没有来，就要重发，如果来了，按照offset拼接，还是能够拼接一个流。
