HTTP（HyperText Transfer Protocol，缩写：HTTP）
觉得现在对缩写的英文全部知道含义才行，乱糟糟的缩写很混乱。言归正传。
用于分布式、协作式和超媒体信息系统的应用层协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。
HTTP 协议是以 ASCII 码传输，基于请求与响应模式的、无状态的，建立在 TCP/IP 协议之上的应用层规范。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。
HTTP协议主要的版本有3个，分别是HTTP/1.0、HTTP/1.1和HTTP/2。HTTPS是另外一个协议，简单讲是HTTP的安全版。
现在最新的是HTTP/3,暂时未广泛使用
HTTP/1.0
规定浏览器与服务器
只保持短暂的连接连接无法复用。也就是说每个TCP连接只能发送一个请求。
TCP连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0版本的性能比较差。现在，随便打开一个网页，上面都会有很多图片、视频等资源，HTTP/1.0显然无法满足性能要求。
HTTP/1.1
- 引入了持久连接
所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
SPDY
谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。它的设计目标是降低 50% 的页面加载时间。SPDY主要提供了以下功能
- 多路复用（multiplexing）。多个请求共享一个tcp连接。
- header压缩。删除或者压缩HTTP头
- 服务端推送。提供服务方发起通信，并向客户端推送数据的机制。
SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议。(当前最新版本是 SPDY/3.1)
HTTP/2
HTTP/2相对于HTTP/1.1有哪些改进:
二进制分帧
在HTTP/2中，在应用层（HTTP2.0）和传输层（TCP或者UDP）之间加了一层：二进制分帧层。这是HTTP2中最大的改变。
``
多路复用允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。在HTTP1.1协议中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制，超过了这个限制的请求就会被阻塞。而多路复用允许同时通过单一的 HTTP2.0 连接发起多重的“请求-响应”消息。
HTTP2的请求的TCP的connection一旦建立，后续请求以stream的方式发送。每个stream的基本组成单位是frame（二进制帧）。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。
HTTP2.0 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。就好比，我请求一个页面 http://www.hollischuang.com 。页面上所有的资源请求都是客户端与服务器上的一条 TCP 上请求和响应的！
header压缩
HTTP/1.1的header带有大量信息，而且每次都要重复发送。HTTP/2 为了减少这部分开销，采用了HPACK 头部压缩算法对Header进行压缩。
服务端推送
简单来讲就是当用户的浏览器和服务器在建立连接后，服务器主动将一些资源推送给浏览器并缓存起来的机制。有了缓存，当浏览器想要访问已缓存的资源的时候就可以直接从缓存中读取了。
HTTP/2存在哪些问题，为什么要被弃用。
HTTP/2的诞生，主要是为了解决HTTP/1.1中的效率问题，HTTP/2中最核心的技术就是多路复用技术，即允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。
同时还实现了二进制分帧、header压缩、服务端推送等技术。
1 队头阻塞
早在HTTP/1.1时代，就一直存在着队头阻塞的问题。
只能说HTTP/2解决了HTTP的队头阻塞问题，但是并没有解决TCP队头阻塞问题！
- HTTP/1.1相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接（keep-alive）。
所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
- HTTP/1.1允许在持久连接上使用请求管道，是相对于持久连接的又一性能优化
所谓请求管道，就是在HTTP响应到达之前，可以将多条请求放入队列，当第一条HTTP请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。
HTTP/1.1 管道连接还是有一定的限制和要求: 比较关键的就是服务端必须按照与请求相同的顺序回送HTTP响应。如果一个响应返回发生了延迟，那么其后续的响应都会被延迟，直到队头的响应送达。这就是所谓的HTTP队头阻塞。
HTTP/2中得到了有效的解决: HTTP/2废弃了管道化的方式，而是创新性的引入了帧、消息和数据流等概念。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。因为没有顺序了，所以就不需要阻塞了，就有效的解决了HTTP对队头阻塞的问题。
但是，HTTP/2仍然会存在TCP队头阻塞的问题，那是因为HTTP/2其实还是依赖TCP协议实现的。
TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。
但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。
HTTP/1.1的管道化持久连接也是使得同一个TCP链接可以被多个HTTP使用，但是HTTP/1.1中规定一个域名可以有6个TCP连接。而HTTP/2中，同一个域名只是用一个TCP连接。
所以，在HTTP/2中，TCP队头阻塞造成的影响会更大，因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的，那如果某一个请求造成了TCP队头阻塞，那么多个请求都会受到影响。
2. TCP握手时长
提到TCP协议，大家最先想到的一定是他的三次握手与四次关闭的特性。
通过三次握手，TCP在传输过程中可以保证接收方收到的数据是完整，有序，无差错的。但是，问题是三次握手是需要消耗时间的，介绍一下关于网络延迟的概念.
TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。
如果使用的是安全的HTTPS协议，就还需要使用TLS协议进行安全数据传输，这个过程又要消耗一个RTT（TLS不同版本的握手机制不同，这里按照最小的消耗来算）
一个纯HTTP/2的连接，需要消耗1.5个RTT，如果是一个HTTPS连接，就需要消耗3-4个RTT。
如何解决？
如果TCP协议需要升级，那么意味着需要这些中间设备都能支持新的特性，我们知道路由器我们可以重新换一个，但是其他的那些中间设备呢？尤其是那些比较大型的设备呢？更换起来的成本是巨大的。
而且，除了中间设备之外，操作系统也是一个重要的因素，因为TCP协议需要通过操作系统内核来实现，而操作系统的更新也是非常滞后的。
放弃TCP，创造新的协议会和TCP的窘迫境界一样，那就是基于已有的协议做一些改造和支持，UDP就是一个绝佳的选择了。HTTP/3选择了一种新的技术方案，那就是基于UDP做改造，这种技术叫做QUIC。
