【计算机网络】OSI七层模型、TCP协议、HTTP协议

【计算机网络】OSI七层模型、TCP协议、HTTP协议

• 1、介绍一下OSI七层模型？
• • [1.1 路由器与交换机的区别是什么？](#1.1 路由器与交换机的区别是什么？)
• 2、TCP协议
• • [2.1 什么是TCP的粘包、拆包问题？](#2.1 什么是TCP的粘包、拆包问题？)
  • [2.2 什么是TCP三次握手、四次挥手？](#2.2 什么是TCP三次握手、四次挥手？)
  • • [2.2.1 三次握手](#2.2.1 三次握手)
    • [2.2.2 为啥三次握手](#2.2.2 为啥三次握手)
    • [2.2.3 四次挥手](#2.2.3 四次挥手)
    • [2.2.4 为啥四次挥手](#2.2.4 为啥四次挥手)
  • [2.3 TCP是如何保证可靠传输的？](#2.3 TCP是如何保证可靠传输的？)
  • [2.4 TCP和UDP的区别是什么？](#2.4 TCP和UDP的区别是什么？)
• 3、什么是正向代理和反向代理？
• 4、HTTP
• • [4.1 为什么需要HTTP/2，他解决了什么问题？](#4.1 为什么需要HTTP/2，他解决了什么问题？)
  • • [4.1.1 HTTP](#4.1.1 HTTP)
    • [4.1.2 HTTP/1.0](#4.1.2 HTTP/1.0)
    • [4.1.3 HTTP/1.1](#4.1.3 HTTP/1.1)
  • [4.2 HTTP/2](#4.2 HTTP/2)
  • • [4.2.1 二进制分帧](#4.2.1 二进制分帧)
    • [4.2.2 多路复用](#4.2.2 多路复用)
    • [4.2.3 header压缩](#4.2.3 header压缩)
    • [4.2.4 HTTP队头阻塞](#4.2.4 HTTP队头阻塞)
  • [4.3 HTTP/2存在什么问题，为什么需要HTTP/3？](#4.3 HTTP/2存在什么问题，为什么需要HTTP/3？)
  • • [4.3.1 TCP队头阻塞问题](#4.3.1 TCP队头阻塞问题)
    • [4.3.2 升级TCP是否可行？](#4.3.2 升级TCP是否可行？)
    • [4.3.3 放弃TCP？](#4.3.3 放弃TCP？)
  • [4.4 什么是HTTP/3的QUIC协议？](#4.4 什么是HTTP/3的QUIC协议？)

1、介绍一下OSI七层模型？

OSI（Open System Interconnection，开放式系统互联）七层模型是计算机网络中一种通信协议的分类方式，分为以下七个层次：

1. 物理层（Physical Layer）：主要规定传输介质的传输方式，包括电信号、电压、光脉冲等。该层的主要协议是物理媒介相关协议，如RS232、V.35、以太网等。
2. 数据链路层（Data Link Layer）：在物理层上建立数据链路，对数据进行分帧、差错校验等处理，确保数据可靠地传输。该层的主要协议有点对点协议PPP（Point-to-Point Protocol）、高级数据链路控制协议HDLC（High-Level Data Link Control）、以太网协议等。
3. 网络层（Network Layer）：主要解决数据在网络中的传输问题，包括寻址、路由选择等。该层的主要协议有IP协议、网关协议（ARP）、路由协议（RIP、OSPF、BGP等）等。
4. 传输层（Transport Layer）：提供端到端的可靠传输服务，包括数据传输控制、流量控制等。该层的主要协议有TCP协议、UDP协议、SCTP协议等。
5. 会话层（Session Layer）：提供会话管理功能，负责建立、维护和结束会话。该层主要实现了不同计算机之间的会话控制，为高层协议提供一个传输数据的会话环境，该层的主要协议有NetBIOS等。
6. 表示层（Presentation Layer）：负责数据格式的转换，确保应用层数据的格式一致。该层主要实现了数据格式的转换和数据加密解密等功能，如JPEG、MPEG等。
7. 应用层（Application Layer）：提供应用程序之间的交互，包括文件传输、电子邮件、远程登录等。该层的主要协议有HTTP、FTP、SMTP、DNS、TELNET、SNMP等。

1.1 路由器与交换机的区别是什么？

在OSI七层模型中，交换机主要工作在数据链路层（第二层），路由器工作在网络层（第三层）。

交换机转发所依据的对象是物理地址，也就是MAC地址，而路由器转发所依据的对象时网络地址，也就是IP地址。

交换机主要用于组建局域网，而路由主要功能是将由交换机组好的局域网相互连接起来，或者接入互联网。

2、TCP协议

2.1 什么是TCP的粘包、拆包问题？

TCP粘包和拆包问题是指在进行TCP通信时，因为TCP是面向流的，所以发送方在传输数据时可能会将多个小的数据包粘合在一起发送，而接收方则可能将这些数据包拆分成多个小的数据包进行接收，从而导致数据接收出现错误或者数据粘连的问题。

TCP粘包和拆包问题主要出现在以下两种情况下：

1. 发送方连续发送多个小数据包：由于TCP是基于流的协议，发送方在传输数据时可能会将多个小数据包组合成一个大数据包进行发送，从而导致接收方在接收数据时无法区分不同数据包之间的界限。
2. 接收方缓存区大小限制：接收方在接收数据时，如果接收缓存区的大小有限，可能会将一个大的数据包拆分成多个小数据包进行接收，从而导致粘包和拆包问题的出现。

解决方案

对于粘包和拆包问题，一般都是对包的格式进行约束，常见的解决方案有四种：

● 将业务层协议包的长度固定下来，每个包都固定长度 ，比如512个字节大小，如果客户端发送的数据长度不足512个字节，则通过补充空格的方式补全到指定长度；

● 在每个包的末尾使用固定的分隔符 ，如换行符/n，如果一个包被拆分了，则等待下一个包发送过来之后找到其中的\n，然后对其拆分后的头部部分与前一个包的剩余部分进行合并即可；

● 仿照TCP/IP协议栈，将消息分为header和body ，在head中保存有当前整个消息的长度，只有在读取到足够长度的消息之后才算是读到了一个完整的消息；

● 通过自定义协议进行粘包和拆包的处理。

2.2 什么是TCP三次握手、四次挥手？

2.2.1 三次握手

1. 你（客户端）给一个朋友（服务器）打电话，告诉他你想开始对话。这就像是发送一个SYN（同步序列编号）信号，表示你想开始建立连接。（client向server发送syn，seq=x，此时client验证client发送能力正常。client置为SYN_SENT状态）
2. 你的朋友接到电话，明白你想开始对话。他回应说"好的，我准备好了"，同时也告诉你他也想说些话。这就相当于服务器发送SYN-ACK（同步和确认）信号，既确认收到了你的请求，也表明它准备好了并想建立连接。（server收到syn，此时server验证client发送能力正常，server接收能力正常。server向client发送ack = x + 1,seq = y，此时server验证server发送能力正常。server置为SYN_RCVD状态）
3. 最后，你回复你的朋友说你收到了他的确认，现在可以开始对话了。这就是发送ACK（确认）信号，确认你已经准备好进行通信。（client收到ack，此时client验证client接收能力正常，server接收发送能力正常。client向server发送ack = y + 1， seq = x + 1，server接收到后验证client接收能力正常。client置为ESTABLISHED状态）

2.2.2 为啥三次握手

TCP三次握手验证了client和server的收包和发包能力。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

所以，只有三次握手才能确认双方的接收与发送能力是否正常。

如果是两次握手，服务端无法确定客户端是否已经接收到了自己发送的初始序列号，如果第二次握手报文丢失，那么客户端就无法知道服务端的初始序列号，那 TCP 的可靠性就无从谈起。

客户端由于某种原因发送了两个不同序号的 SYN 包，我们知道网络环境是复杂的，旧的数据包有可能先到达服务器。如果是两次握手，服务器收到旧的 SYN 就会立刻建立连接，那么会造成网络异常。

如果是三次握手，服务器需要回复 SYN+ACK 包，客户端会对比应答的序号，如果发现是旧的报文，就会给服务器发 RST 报文，直到正常的 SYN 到达服务器后才正常建立连接。

所以三次握手才有足够的上下文信息来判断当前连接是否是历史连接。

2.2.3 四次挥手

1. 你（客户端）和朋友（服务器）通话结束后，告诉他你想挂电话了。这就像是发送一个FIN（结束）信号，表示你想结束这次连接。（client向server发送fin。client置为FIN_WAIT_1）
2. 朋友听到你想挂电话了，他回应说"知道了，但我还有点事情要处理"，即使他知道对话即将结束。这就相当于服务器发送ACK（确认）信号，确认收到了你想结束连接的请求，但可能还需要一些时间来处理剩余的数据。（server向client发送ack。server置为CLOSE_WAIT，client置为FIN_WAIT_2）
3. 一段时间后，你的朋友处理完了他的事情，这时他打电话告诉你他也准备好挂电话了。这是服务器端发送第二个FIN信号，表明他现在也准备好结束这次连接。（等server传输数据完毕后，向client发送fin。server置为LAST_ACK）
4. 最后，你回复说你收到了他的消息，并同意现在可以挂电话了。这就是发送最后一个ACK信号，确认收到服务器端的结束请求。（client向server发送ack。client置为TIME_WAIT。之后等待2MSL，client关闭。server接收到后置为CLOSED）

2.2.4 为啥四次挥手

其实在 TCP 握手的时候，接收端发送 SYN+ACK 的包是将一个 ACK 和一个 SYN 合并到一个包中，所以减少了一次包的发送，三次完成握手。

对于四次挥手，因为 TCP 是全双工通信，在主动关闭方发送 FIN 包后，接收端可能还要发送数据，不能立即关闭服务器端到客户端的数据通道，所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送，只能先确认 ACK，然后服务器待无需发送数据时再发送 FIN 包，所以四次挥手时必须是四次数据包的交互。

2.3 TCP是如何保证可靠传输的？

描述一个网络协议可靠，至少要满足以下几点：

1、数据完整性，我传给你的是123，你收到的也得是123，不能是13

2、数据顺序，我是按照123给你的，你不能按照213收到。

3、不能重复，我传给你的是123，你不能给我接收成1223

4、不被篡改，我传给你的是123，你不能接收成12`3

所以，要保证以上几点，TCP主要做了以下几个事情：

应用数据被分割成 TCP 认为最适合发送的数据块。TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

三次握手&四次挥手：TCP通过三次握手建立连接和四次挥手关闭连接，确保通信的可靠性和数据的可靠传输。

流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）

拥塞控制： TCP使用拥塞控制算法来确保网络中不会因为过多的数据而导致拥塞。当网络拥塞时，发送端会减少发送速率，以避免进一步加重网络拥塞。常用的拥塞控制算法包括慢启动、拥塞避免和快速重传等。

ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

2.4 TCP和UDP的区别是什么？

TCP（Transmission Control Protocol，传输控制协议）和UDP（User Datagram Protocol，用户数据报协议）是两种主要的网络传输协议，都位于传输层。

他们主要有以下区别：

1. 连接类型
   ○ TCP 是一种面向连接的协议。在发送数据之前，它需要建立连接，这通过三次握手过程完成。结束后通过四次挥手断开连接。
   ○ UDP 是无连接的协议。它发送数据而不预先建立连接。
2. 可靠性
   ○ TCP 提供可靠的数据传输，通过确认和重传机制来确保数据的正确送达。
   ○ UDP 不保证数据的可靠送达。它发送数据但不确认接收方是否收到，因此可能会丢失数据包。
3. 速度和效率
   ○ TCP 由于其握手和确认机制，速度通常比UDP慢，但更可靠。
   ○ UDP 由于缺乏复杂的错误检查和恢复机制，通常比TCP更快，适用于对实时性要求较高的应用。
4. 数据流控制和拥塞控制
   ○ TCP 有流量控制和拥塞控制机制，可以调整数据传输速率以避免网络拥堵。
   ○ UDP 没有内置的流量控制或拥塞控制机制。
5. 头部大小
   ○ TCP 头部较大，最小为20字节，因为它包含更多的控制信息。
   ○ UDP 头部较小，仅8字节，使得其开销更小。

在使用场景上，TCP 通常用于需要高可靠性的应用，如网页浏览、电子邮件、文件传输等。UDP 适用于实时应用，如视频流、在线游戏和语音通话，其中一些数据丢失是可以接受的。

3、什么是正向代理和反向代理？

正向代理（forward proxy）：是一个位于客户端和目标服务器之间的服务器(代理服务器)，为了从目标服务器取得内容，客户端向代理服务器发送一个请求并指定目标，然后代理服务器向目标服务器转交请求并将获得的内容返回给客户端。

正向代理，其实是"代理服务器"代理了"客户端"，去和"目标服务器"进行交互。

通过正向代理服务器访问目标服务器，目标服务器是不知道真正的客户端是谁的，甚至不知道访问自己的是一个代理。

反向代理（reverse proxy）：是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

对于常用的场景，就是我们在Web开发中用到的负载均衡服务器，客户端发送请求到负载均衡服务器上，负载均衡服务器再把请求转发给一台真正的服务器来执行，再把执行结果返回给客户端。

所以，反向代理，其实是"代理服务器"代理了"目标服务器"，去和"客户端"进行交互。

通过反向代理服务器访问目标服务器时，客户端是不知道真正的目标服务器是谁的，甚至不知道自己访问的是一个代理。

正向代理和反向代理的区别

虽然正向代理服务器和反向代理服务器所处的位置都是客户端和真实服务器之间，所做的事情也都是把客户端的请求转发给服务器，再把服务器的响应转发给客户端，但是二者之间还是有一定的差异的。

1、正向代理其实是客户端的代理，帮助客户端访问其无法访问的服务器资源。反向代理则是服务器的代理，帮助服务器做负载均衡，安全防护等。

2、正向代理，一般是客户端架设的，比如在自己的机器上安装一个代理软件。而反向代理一般是服务器架设的，比如在自己的机器集群中部署一个反向代理服务器。

3、正向代理中，服务器不知道真正的客户端到底是谁，以为访问自己的就是真实的客户端。而在反向代理中，客户端不知道真正的服务器是谁，以为自己访问的就是真实的服务器。

4、正向代理和反向代理的作用和目的不同。正向代理主要是用来解决访问限制问题。而反向代理则是提供负载均衡、安全防护等作用。二者均能提高访问速度。

4、HTTP

4.1 为什么需要HTTP/2，他解决了什么问题？

HTTP/2主要是解决HTTP中存在的效率问题。它主要引入了二进制分帧、多路复用、header压缩、以及服务端推送的新特性，大大的提升了效率。

而且，在HTTP/2中还解决了一个重要的问题，那就是HTTP的队头阻塞问题。

4.1.1 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的安全版。

4.1.2 HTTP/1.0

1996年5月，HTTP/1.0 版本发布，为了提高系统的效率，HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

请注意上面提到的HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

我们知道TCP连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0版本的性能比较差。现在，随便打开一个网页，上面都会有很多图片、视频等资源，HTTP/1.0显然无法满足性能要求。

4.1.3 HTTP/1.1

为了解决HTTP/1.0存在的缺陷，HTTP/1.1于1999年诞生。相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接。所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

引入了持久连接之后，在性能方面，HTTP协议有了明显的提升，基本可以用于日常使用，这也是这一版本一直延用至今的原因。

4.2 HTTP/2

下图是Akamai 公司建立的一个官方的演示，主要用来说明在性能上HTTP/1.1和HTTP/2在性能升的差别。同时请求 379 张图片，HTTP/1.1加载用时4.54s，HTTP/2加载用时1.47s。

HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。由互联网工程任务组（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论，于2015年2月17日被批准。HTTP/2标准于2015年5月以RFC 7540正式发表。

下面来看下，HTTP/2相对于HTTP/1.1有哪些改进：

4.2.1 二进制分帧

在HTTP/2中，在应用层（HTTP2.0）和传输层（TCP或者UDP）之间加了一层：二进制分帧层。这是HTTP2中最大的改变。HTTP2之所以性能会比HTTP1.1有那么大的提高，很大程度上正是由于这一层的引入。

在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。

这种单连接多资源的方式，减少了服务端的压力，使得内存占用更少，连接吞吐量更大。而且，TCP连接数的减少使得网络拥塞状况得以改善，同时慢启动时间的减少，使拥塞和丢包恢复速度更快。

4.2.2 多路复用

多路复用允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。在HTTP1.1协议中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制，超过了这个限制的请求就会被阻塞。而多路复用允许同时通过单一的 HTTP2.0 连接发起多重的"请求-响应"消息。

HTTP2的请求的TCP的connection一旦建立，后续请求以stream的方式发送。每个stream的基本组成单位是frame（二进制帧）。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。

4.2.3 header压缩

HTTP/1.1的header带有大量信息，而且每次都要重复发送。HTTP/2 为了减少这部分开销，采用了HPACK 头部压缩算法对Header进行压缩。

4.2.4 HTTP队头阻塞

队头阻塞翻译自英文head-of-line blocking，这个词并不新鲜，因为早在HTTP/1.1时代，就一直存在着队头阻塞的问题。

但是很多人在一些资料中会看到有论点说HTTP/2解决了队头阻塞的问题。但是这句话只对了一半。

只能说HTTP/2解决了HTTP的队头阻塞问题，但是并没有解决TCP队头阻塞问题！

如果大家对于HTTP的历史有一定的了解的话，就会知道。HTTP/1.1相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接（keep-alive）。

所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

引入了持久连接之后，在性能方面，HTTP协议有了明显的提升。

另外，HTTP/1.1允许在持久连接上使用请求管道，是相对于持久连接的又一性能优化。

所谓请求管道，就是在HTTP响应到达之前，可以将多条请求放入队列，当第一条HTTP请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。

但是，对于管道连接还是有一定的限制和要求的，其中一个比较关键的就是服务端必须按照与请求相同的顺序回送HTTP响应。

这也就意味着，如果一个响应返回发生了延迟，那么其后续的响应都会被延迟，直到队头的响应送达。这就是所谓的HTTP队头阻塞。

但是HTTP队头阻塞的问题在HTTP/2中得到了有效的解决。HTTP/2废弃了管道化的方式，而是创新性的引入了帧、消息和数据流等概念。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。

因为没有顺序了，所以就不需要阻塞了，就有效的解决了HTTP队头阻塞的问题。

4.3 HTTP/2存在什么问题，为什么需要HTTP/3？

4.3.1 TCP队头阻塞问题

HTTP/2虽然解决了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队头阻塞，那么多个请求都会受到影响。

4.3.2 升级TCP是否可行？

基于上面我们提到的这些问题，很多人提出来说：既然TCP存在这些问题，并且我们也知道这些问题的存在，甚至解决方案也不难想到，为什么不能对协议本身做一次升级，解决这些问题呢？

其实，这就涉及到一个"协议僵化"的问题。

这样讲，我们在互联网上浏览数据的时候，数据的传输过程其实是极其复杂的。

我们知道的，想要在家里使用网络有几个前提，首先我们要通过运行商开通网络，并且需要使用路由器，而路由器就是网络传输过程中的一个中间设备。

中间设备是指插入在数据终端和信号转换设备之间，完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。

在我们看不到的地方，这种中间设备还有很多很多，一个网络需要经过无数个中间设备的转发才能到达终端用户。

如果TCP协议需要升级，那么意味着需要这些中间设备都能支持新的特性，我们知道路由器我们可以重新换一个，但是其他的那些中间设备呢？尤其是那些比较大型的设备呢？更换起来的成本是巨大的。

而且，除了中间设备之外，操作系统也是一个重要的因素，因为TCP协议需要通过操作系统内核来实现，而操作系统的更新也是非常滞后的。

所以，这种问题就被称之为"中间设备僵化"，也是导致"协议僵化"的重要原因。这也是限制着TCP协议更新的一个重要原因。

所以，近些年来，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用！

4.3.3 放弃TCP？

上面提到的这些问题的根本原因都是因为HTTP/2是基于TCP实现导致的，而TCP协议自身的升级又是很难实现的。

那么，剩下的解决办法就只有一条路，那就是放弃TCP协议。

放弃TCP的话，就又有两个新的选择，是使用其他已有的协议，还是重新创造一个协议呢？

看到这里，聪明的读者一定也想到了，创造新的协议一样会受到中间设备僵化的影响。近些年来，因为在互联网上部署遭遇很大的困难，创造新型传输层协议的努力基本上都失败了！

所以，想要升级新的HTTP协议，那么就只剩一条路可以走了，那就是基于已有的协议做一些改造和支持，UDP就是一个绝佳的选择了。

4.4 什么是HTTP/3的QUIC协议？

HTTP/2之所以"被弃用"，是因为他使用的传输层协议仍然是TCP，所以HTTP/3首要解决的问题就是绕开TCP。

那么如果研发一种新的协议，同样还是会因为受到中间设备僵化的影响，导致无法被大规模应用。所以，研发人员们想到了一种基于UDP实现的方式。

于是，Google是最先采用这种方式并付诸于实践的，他们在2013年推出了一种叫做QUIC的协议，全称是Quick UDP Internet Connections，这是一种完全基于UDP的协议。所以，现在所提到的HTTP/3，其实就是HTTP over QUIC，即基于QUIC协议实现的HTTP。

那么，想要了解HTTP/3的原理，只需要了解QUIC就可以了。

QUIC协议有以下特点：

● 基于UDP的传输层协议：它使用UDP端口号来识别指定机器上的特定服务器。

● 可靠性：虽然UDP是不可靠传输协议，但是QUIC在UDP的基础上做了些改造，使得他提供了和TCP类似的可靠性。它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些TCP中存在的特性。

● 实现了无序、并发字节流：QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序，这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！

● 快速握手：QUIC提供0-RTT和1-RTT的连接建立

● 使用TLS 1.3传输层安全协议：与更早的TLS版本相比，TLS 1.3有着很多优点，但使用它的最主要原因是其握手所花费的往返次数更低，从而能降低协议的延迟。

那么，QUIC到底属于TCP/IP协议族中的那一层呢？我们知道，QUIC是基于UDP实现的，并且是HTTP/3的所依赖的协议，那么，按照TCP/IP的分层来讲，他是属于传输层的，也就是和TCP、UDP属于同一层。

如果更加细化一点的话，因为QUIC不仅仅承担了传输层协议的职责，还具备了TLS的安全性相关能力，所以，可以通过下图来理解QUIC在HTTP/3的实现中所处的位置。

参考链接：

1、https://www.yuque.com/hollis666/wk6won/kymufaxbs2dhq87q

2、https://www.yuque.com/hollis666/wk6won/oa7mt1

3、https://www.yuque.com/hollis666/wk6won/hiqe1d

4、https://www.yuque.com/hollis666/wk6won/pg5ika

5、https://www.yuque.com/hollis666/wk6won/pl7sgw2v9iu60dep