1. HTTP1.0，HTTP1.X到HTTP3.0
HTTP连接在很长一段时间有都是基于TCP的。
HTTP1.0中，没发起一次HTTP请求，就要经历一次TCP三次握手，四次挥手的连接过程。
HTTP1.X(X>0)，采用了keep-alive应用层长连接。这种长连接是串形的，即一个文件传输完后，下一个文件才能复用这个连接。
另外，HTTP1.X还有如下特性：
- 文本传输
- 支持协议扩展切换
Upgrade，从而可以支持webscoket协议。 - 新增缓存控制
Cache-Control和Etag，在强缓存和协商缓存中支持了相对过期时间判断（参考文章前端网络高级篇（三）浏览器缓存）。 - 部分内容传输优化：可以支持超文本文件的部分传输。HTTP请求在消息的正文中除了可携带文本内容，也可以传输二进制数据。例如表单中使用formData提交上传文件时携带的就是二进制数据。
HTTP2.0相对HTTP1.X有如下的优点：
- 采用二进制格式传输数据
- 采用TCP多路复用来降低网络请求连接建立和关闭的开销。
keep-alive是应用层连接，而TCP多路复用发生在传输层，即不同文件的传输帧可以在同一个TCP连接中同时进行流式传输。
- 支持服务端推送
- 支持传输流的优先级和流量控制。这样，可以通过优先级TAG保证先传输CSS文件，那我们就不需要一定将CSS文件加载写在HTML顶部了。
HTTP2.0 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。
基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP3.0 上。
同一条 QUIC 连接上可以创建多个 stream，来发送多个 HTTP 请求，但是，QUIC 是基于 UDP 的，一个连接上的多个 stream 之间没有依赖。比如下图中 stream2 丢了一个 UDP 包，不会影响后面跟着 Stream3 和 Stream4，不存在 TCP 队头阻塞。虽然 stream2 的那个包需要重新传，但是 stream3、stream4 的包无需等待，就可以发给用户。
2. 物联网的宠儿-MQTT协议
和HTTP类似，MQTT也是基于TCP /IP，为OSI 7层模型的【应用层协议】。
MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。所以，它非常适合应用在物联网、小型设备、移动场景等。
MQTT特点
使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合（这种模式增强了整个系统的可靠性。当一个客户端出现故障时，整个系统可以继续正常工作）；
- 对负载内容屏蔽的消息传输；
- 使用 TCP/IP 提供网络连接；
- 有三种消息发布服务质量：
服务质量类型 | 描述 | 例子 |
|---|---|---|
至多一次 | 消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复 | 可用于设备信息上报，丢失一次读记录无所谓，因为不久后还会有第二次发送 |
至少一次 | 确保消息到达，但消息重复可能会发生 | 可用于聊天系统 |
只有一次 | 确保消息到达一次 | 可用于计费系统中（消息重复或丢失会导致不正确的结果） |
3. TCP的三次握手和四次挥手
名词解释：
- SYN：同步序列编号（Synchronize Sequence Numbers）
- ACK ：确认字符 (Acknowledge character）
