HTTP（超文本传输协议）是浏览器与服务端之间最主要的通信协议。这里将介绍http各版本解决的核心问题。
http 0.9
http最初的版本是http 0.9，如它的名字定义，主要是为了解决超文本（Html）内容传输问题
协议定义了客户端发起请求、服务端响应请求的通信模式。
- 客户端通过发送向服务器get请求，请求文本内容
- 服务器收到请求后，返回ASCII字符流编码的html
http 1.0
随着浏览器和互联网的发展，单文本类型的传输已经无法满足通信的需求，浏览器希望可以通过http请求不同类型的文件，比如脚本、样式、图片、音视频等。
为了解决这个问题，出现了http 1.0，它主要是通过 增加头部设定 （即请求头和响应头）来解决不同类型文件的传输问题：
- 浏览器每次请求时，通过accept请求头，告诉服务器它能接收的文件类型；
- 服务器响应时，通过content-type响应头，告诉浏览器它返回的文件类型
这也为后来实现很多功能奠定了基础，比如缓存、认证信息等，都是通过请求头和响应头来实现的。
虽然http1.0解决了不同类型文件的传输问题，但它还有很大的局限性，就是它每次通信都要经过三个阶段：
- 连接阶段
- 数据传输阶段
- 断开阶段
存在的问题：
- 当页面引用较多外部资源时，每次连接和断开的过程都会增加大量网络开销；
- 每次连接断开后，下一次连接时，服务器是没法区分这次连接和上次连接是不是同一个身份，所以说是无状态的
http 1.1
为了解决http 1.0的问题，增加了一个创建持久连接的方法。主要实现是当一个连接传输完成时，并不是马上进行关闭，而是继续复用它传输其他请求的数据，这个连接保持到浏览器或者服务器要求断开连接为止。
TCP创建连接和断开连接的过程
http是基于tcp来创建连接和断开连接，其过程分别是由 三次握手 和 四次挥手 实现的。
三次握手
在tcp创建连接之前，是通过三次握手来确认双方有发送和接收的能力：
第一次握手
刚开始客户端处于closed状态，服务端处于listen状态。由客户端发送一个syn报文给服务端，并将自己的序列号seq同步发送给服务端，此时客户端变为 syn_send 状态第二次握手
服务端接收到客户端的syn包，并将客户端的序列号seq + 1作为ack响应包的序列号，表示自己接收到了客户端请求；同时服务端发送自己的序列号syn包（ack+syn）给客户端，此时服务端状态变为 syn_revd 状态-
第三次握手
客户端接收到服务端的ack+syn包，同样会将服务端的序列号syn + 1作为自己ack响应包的序列号值，表示自己接收到服务端的响应，把ack发送给服务端，此时客户端变为 established 状态。当服务端收到ack响应报文时，也变为established状态，此时，双方成功建立了连接。
三次握手.png
为什么是三次握手建立连接？
因为第1次握手让服务端知道客户端有发送的能力；第2次握手是为了让客户端知道服务端有接收和发送的能力；第3次是为了让服务端知道客户端有接收的能力。当通过3次握手后，双方才能确认对方都有发送和接收的能力，此时连接才能正式建立
四次挥手
当客户端和服务端断开连接时要发送四次数据，这个过程称之为四次挥手。
第一次挥手
在挥手之前服务端与客户端都处于 established 状态。客户端发送一个 fin 报文，用来告知服务端，客户端要关闭到服务器的数据传输，此时客户端处于 fin_wait_1 状态。第二次挥手
当服务端收到 fin 之后，会发送 ack 报文，并且把客户端的序列号seq值加 1 作为 ack 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 close_wait 状态。 当客户端收到 ack 报文后，会处于 fin_wait_2状态，等待服务端发送断开请求。第三次挥手
当服务端将之前的请求都响应完后，此时，服务端向客户端发送 fin 报文，并指定一个自己的序列号 seq ，告诉客户端自己已经准备好可以断开请求了，此时服务端变为 last_ack 状态-
第四次挥手
当客户端接收到 fin 报文后，也会向服务端发送一个 ack 报文，并将服务端的 seq + 1作为自己序列号发送，此时，客户端变为 time_wait 状态，等过一段时间后会自动变为 closed 状态。当服务端接收到客户端的ack报文时，此时变为 closed 状态，至此，连接正式断开。
四次挥手.png
为什么是四次挥手？
因为在第二次服务端响应时，只是告诉客户端自己接收到了断开请求，并不能立即断开连接，而是要等服务端将所有请求都响应完毕后，才能发送响应告诉客户端自己准备好可以断开了。所以要经过四次挥手才能断开。
http 1.1的局限性
HTTP/1.1 虽然通过长连接减少了大量创建/断开连接造成的性能消耗，但由于它的并发能力受到限制，所以传输性能还有很大提升空间。
- 浏览器为了减轻服务器的压力，限制了同一个域下的 HTTP 连接数，即 6 ~ 8 个，所以在 HTTP/1.1 下很容易看到资源文件等待加载的情况，对应优化的方式就是使用多个域名来加载图片资源；
- HTTP/1.1 本身的问题，虽然 HTTP/1.1 中使用持久连接时，多个请求能共用一个 TCP 连接，但在一个连接中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态，这种情况被称为 “队头阻塞” 。
http2
HTTP/2 中新增了一个二进制分帧的机制来提升传输效率。
HTTP/2 将默认不再使用 ASCII 编码传输，而是改为二进制数据。
- 客户端在发送请求时会将每个请求的内容封装成不同的带有编号的二进制帧，然后将这些帧同时发送给服务端。
- 服务端接收到数据之后，会将相同编号的帧合并为完整的请求信息。
- 同样，服务端返回结果、客户端接收结果也遵循这个帧的拆分与组合的过程。
受益于二进制分帧，对于同一个域，客户端只需要与服务端建立一个连接即可完成通信需求，自然也不再受限于浏览器的连接数限制了，这种利用一个连接来发送多个请求的方式称为“多路复用”。
http3
当然 HTTP/2 也并非完美，考虑一种情况，如果客户端或服务端在通信时出现数据包丢失，或者任何一方的网络出现中断，那么整个 TCP 连接就会暂停。
HTTP/2 由于采用二进制分帧进行多路复用，通常只使用一个 TCP 连接进行传输，在丢包或网络中断的情况下后面的所有数据都被阻塞。
但对于 HTTP/1.1 来说，可以开启多个 TCP 连接，任何一个 TCP 出现问题都不会影响其他 TCP 连接，剩余的 TCP 连接还可以正常传输数据。这种情况下 HTTP/2 的表现就不如 HTTP/1 了。
针对数据丢包或网络中断的问题，http3将 TCP 改成 UDP，从而彻底解决了这个问题。
UDP 相对于 TCP 而言最大的特点是传输数据时不需要建立连接，可以同时发送多个数据包，所以传输效率很高，缺点就是没有确认机制来保证对方一定能收到数据。
