http，https，spdy，http2等协议的主要区别详解
SPDY、HTTP/2、QUIC协议
SPDY, HTTP/2, QUIC protocol
幂等和非幂等的关系与区别
技术分享之http2和quic的那些事儿
HTTP发展史（HTTP1.1，HTTPS，SPDY，HTTP2.0，QUIC，HTTP3.0）
程序员面试必考题（二十五）—SPDY与HTTP/2协议
HTTP协议篇(一)：多路复用、数据流
HTTTP 2.0原理解析
一文读懂HTTP/2及HTTP/3特性
试图取代 TCP 的 QUIC 协议到底是什么?
一、总结
要了解HTTP2.0，先了解一下HTTP超文本传输协议的历史（HyperText Transfer Protocol），这是为了实现互联网上内容传输提出的协议，其历史伴随着互联网的发展。整个HTTP协议发展历程如下：
一句话介绍：
HTTP 0.9：基于GET请求的文本传输协议
HTTPS：安全的HTTP传输协议
HTTP 1.0：增加HTTP头、扩展PUT、POST等方法
HTTP 1.1：长连接、流水线支持，最广泛使用的HTTP传输协议
SPDY：针对HTTP的增强，工作在SSL层之上、HTTP层之下
HTTP 2.0：安全高效的下一代HTTP传输协议
根据W3Techs统计，到现在为止，互联网上前1000万的网站，已经有27.9%支持了HTTP2.0。
HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷
HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的
QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议
二、HTTP1.0和HTTP1.1的一些区别
缓存处理： 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
1、带宽优化及网络连接的使用： HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
2、错误通知的管理： 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3、Host头处理： 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
4、长连接： HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，其中长连接也就是对应在HTTP1.1中的Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
三、HTTP2.0和SPDY的区别
HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
HTTP2.0 消息头的压缩算法采用 HPACK，而 SPDY 采用的是 DEFLATE
四、HTTPS与HTTP的一些区别
HTTPS与HTTP的一些区别
HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的TLS加密传输协议。
HTTP和HTTPS使用的是完全不同的连接方式，用的默认端口也不一样，前者是80，后者是443。
HTTPS的连接很简单，HTTPS协议是由TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题
五、SPDY对比HTTP的优势：
复用连接，可在一个TCP连接上传送多个资源。应对了TCP慢启动的特性。
请求分优先级，重要的资源优先传送。
HTTP头部数据也被压缩，省流量。
服务器端可主动连接客户端来推送资源（Server Push）。
缺点：
单连接会因TCP线头阻塞（head-of-line blocking）的特性而传输速度受限。加上存在可能丢包的情况，其负面影响已超过压缩头部和优先级控制带来的好处。
由于这些缺点，SPDY在小网站（资源文件数量较少）的效果不明显，有可能比多并发连接更慢。（由此催生了QUIC）
六、多路复用
虽然 HTTP 1.1 默认启用长TCP连接，但所有的请求-响应都是按序进行的(这里的长连接可理解成半双工协议。即便是HTTP 1.1引入了管道机制，也是如此)。复用同一个TCP连接期间，即便是通过管道同时发送了多个请求，服务端也是按请求的顺序依次给出响应的；而客户端在未收到之前所发出所有请求的响应之前，将会阻塞后面的请求(排队等待)，这称为"队头堵塞"（Head-of-line blocking）。
HTTP/2复用TCP连接则不同，虽然依然遵循请求-响应模式，但客户端发送多个请求和服务端给出多个响应的顺序不受限制，这样既避免了"队头堵塞"，又能更快获取响应。在复用同一个TCP连接时，服务器同时(或先后)收到了A、B两个请求，先回应A请求，但由于处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。HTTP/2长连接可以理解成全双工的协议。
** 七、http1.1问题：**
1、管道机制(Pipelining)
HTTP 1.1 引入了管道机制（Pipelining），即客户端可通过同一个TCP连接同时发送多个请求。如果客户端需要请求两个资源，以前的做法是在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求；而管道机制则允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。
HTTP 1.1 管线化是将多个 HTTP 请求整批提交的技术，而在传送过程中不需先等待服务端的回应。管线化机制须通过永久连接（persistent connection）完成。浏览器将HTTP请求大批提交可大幅缩短页面的加载时间，特别是在传输延迟（lag/latency）较高的情况下。有一点需要注意的是，只有幂等的请求可以使用 pipeline，如 GET，HEAD 方法。
2、存在的问题
head of line blocking会导致带宽无法被充分利用，以及后续健康请求被阻塞。假设有5个请求同时发出，如下图。 对于http1.0的实现，在第一个请求没有收到回复之前，后续从应用层发出的请求只能排队，请求2，3，4，5只能等请求1的response回来之后才能逐个发出。网络通畅的时候性能影响不大，一旦请求1的request因为什么原因没有抵达服务器，或者response因为网络阻塞没有及时返回，影响的就是所有后续请求，问题就变得比较严重了。
八、HTTP3.0是什么？
HTTP3.0，也称作HTTP over QUIC。HTTP3.0的核心是QUIC(读音quick)协议，由Google在2015年提出的SPDY v3演化而来的新协议，传统的HTTP协议是基于传输层TCP的协议，而QUIC是基于传输层UDP上的协议，可以定义成：HTTP3.0基于UDP的安全可靠的HTTP2.0协议。
虽然 HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，主要是底层支撑的 TCP 协议造成的。
上文提到 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。
因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。
那么可能就会有人考虑到去修改 TCP 协议，其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统实现的，更新起来不大现实。
基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，HTTP/3 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。
QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能，接下来我们重点介绍几个QUIC新功能。
2. QUIC新功能
0-RTT
通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢？
这里面有两层含义:
传输层 0RTT 就能建立连接。
加密层 0RTT 就能建立加密连接。
上图左边是 HTTPS 的一次完全握手的建连过程，需要 3 个 RTT。就算是会话复用也需要至少 2 个 RTT。
而 QUIC 呢？由于建立在 UDP 的基础上，同时又实现了 0RTT 的安全握手，所以在大部分情况下，只需要 0 个 RTT 就能实现数据发送，在实现前向加密的基础上，并且 0RTT 的成功率相比 TLS 的会话记录单要高很多。
多路复用
虽然 HTTP/2 支持了多路复用，但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。
同HTTP2.0一样，同一条 QUIC连接上可以创建多个stream，来发送多个HTTP请求，但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。比如下图中stream2丢了一个UDP包，不会影响后面跟着 Stream3 和 Stream4，不存在 TCP 队头阻塞。虽然stream2的那个包需要重新传，但是stream3、stream4的包无需等待，就可以发给用户。
另外QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。
加密认证的报文
TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。
但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。
这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。
如上图所示，红色部分是 Stream Frame 的报文头部，有认证。绿色部分是报文内容，全部经过加密。
向前纠错机制
QUIC协议有一个非常独特的特性，称为向前纠错 (Forward Error Correction，FEC)，每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传，因为数据重传将会消耗更多的时间(包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗)
假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包。当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了。
3、总结
（1）QUIC 协议有哪些优点，如何实现 0-RTT？
a、QUIC 协议在传输层就支持多路复用，避免了队头阻塞问题。
b、QUIC 协议基于 UDP，更自由更高效
c、QUIC 协议借鉴了 TFO 的思想，支持会话上下文缓存，方便恢复， 具备实现 0-RTT 的可能
（2）传统的 HTTP2 + SSL + TCP 协议栈有哪些缺点？
a、SSL 的会话恢复依然需要一个 RTT，而且难以合并到 TCP 层
b、TCP 的滑动窗口存在队头阻塞问题
c、TCP 的重传纠错会浪费一个 RTT
（3）为什么 Google 要另起炉灶，基于 UDP 去做？
a、TCP 由操作系统实现，很难更新
b、UDP 非常高效，几乎没有性能负担
c、将 QUIC 嵌入到 Chrome 中可以方便后续的升级迭代
