计算机网络原理

bxnms.

已于 2024-04-09 14:05:45 修改

阅读量863

点赞数 39

文章标签：计算机网络网络

于 2024-03-24 18:57:05 首次发布

本文链接：https://blog.csdn.net/oxygen3000/article/details/136990274

版权

本篇通俗解释网络分层模型，TCP，IP等网络原理，适合新手，个人理解较多，虚心接受指教

网络分层模型（七层）

计算机网络是一个庞大的体系，但不是混沌的，我们将计算机网络分层处理，各层实现对应功能与协议，并完成与相邻接口通信

分层模型：物数网传会应表，如图描述了各层功能及常见协议

数据传输过程如下图：

IP

网际协议IP（Internet Protocol）是TCP/IP体系中最主要的协议之一，与地址解析协议ARP，网际控制协议ICMP和网际组管协议IGMP配套使用

在TCP/IP体系中IP地址是最基本的概念，是为互联网中每一个网络和主机分配的逻辑地址，整个互联网就是一个单一的，抽象的网络，IP地址就是给互联网的每一台主机（或路由器）的每一个接口。可以用快递体系代入，IP地址就相当于你家的地址，不过还包括快递运输途中经过的中转站，因为它们也有IP地址，也是主机

虽然IPv6现世了但IPv4（点分十进制）仍然是主流，关于IP地址分类，这里不作详细说明

本章我们将介绍两个概念：ping命令和ICMP

ICMP

ICMP（网际控制报文协议）用于更有效转发IP数据报和提高交付成功的机会。其允许主机或路由器报告差错情况和提供有关异常情况报告ICMP是IP层的协议，ICMP报文是装在IP数据报中的

ICMP报文分两种：

差错报告报文

「网络不可达」：IP地址可以表示一个网络，当主机号全为0时就表示的是某一个网络，如果整个网络不可达，就会报告一个类型为3，具体代码为0的ICMP协议报文
「主机不可达」：如果对端主机是关机状态，就会出现主机不可达的情况，报告类型3
「网络重定向」：传输给某一个网络的数据，可能不能走该网络了，需要进行重定向，报告类型5
「主机重定向」：如果发送的报文，主机告知不能处理，请发送到另外一个主机，报告类型5

询问报文

「回送请求或应答」：主要是验证网络是否通畅。例如给对端发送一个空数据，如果收到就回应
「时间戳请求或应答」：当需要进行时间同步时使用

ping

PING（Packet InterNet Groper）：分组网间探测，用来测试两台主机之间的连通性（就是查岗的）。PING使用了ICMP回送请求与回送回答报文，是应用层直接使用网络层ICMP的一个例子，没有通过运输层的TCP或UDP

ping命令的使用很简单：ping ip或域名。ping 命令的输出通常包括收发数据包数量、延迟信息和丢失数据包的百分比等信息，这些信息可以帮助用户了解连接和网络延迟的状态。

ping命令过程：

TCP

TCP( Transmission control protocol )即传输控制协议，是一种面向连接、可靠的数据传输协议，它是为了在不可靠的互联网上提供可靠的端到端字节流而专门设计的一个传输协议。

TCP特点如下：

面向连接的运输层协议。就像打电话前先拨号，打完电话要挂断
每一条TCP连接只能有两个端点
提供可靠交付服务。无差错，不丢失，不重复，按序到达
全双工通信。双方进程任何时候都能发送数据，两端都有发送缓存和接收缓存临时存放通信数据
面向字节流。TCP中的流是流入到进程或进程流出的字节序列

TCP把连接作为最基本的抽象：

TCP连接端点叫套接字（socket），就是主机IP地址与进程端口拼接。套接字对（socket pair）确定一条TCP连接

TCP三次握手和四次挥手

TCP是可靠连接，一听到可靠这两字就觉着没那么容易。TCP在建立连接与释放连接的时候会经历三次握手和四次挥手。三次握手是为了确定双方发送与接收能力正常，而四次挥手是为了确定双方都无数据需要发送。至于详情我们下文分析。

TCP三次握手

二话不说先上图：

详细过程：

服务器先运行服务端程序，进入监听状态，准备接受客户端连接请求
客户端向服务端发送同步报文（消耗掉一个序号seq=x，SYN置为1），客户端状态转为同步已发送。服务端接收到同步报文后，向客户端发送确认和同步报文（消耗一个序号seq=y，SYN置为1，ACK置为1，确认号ack=x+1也就是传过来的序号+1），服务端转为同步接收状态。第一次握手完毕
客户端接收到服务端报文（确认报文段和同步报文段）后，要回复服务端，也就是再发送一个确认报文给服务端，至此客户端已建立连接。第二次握手完毕
服务端接收到客户端发来的确认报文段后就建立了连接。第三次握手完毕

白话文：

客户端向服务端发送连接请求，请求自己建立向服务端传输数据的通道
服务端接收到讯号，向客户端发送允许建立连接确认，并且向客户端发送连接请求，请求建立服务端向客户端传输数据的通道
客户端接收到服务端要建立来向数据传输通道请求，给予回应确认。服务端收到后，这个全双工的可靠TCP连接就完成

白白话文：

客户端：你好了没
服务端：收到！我好了，你呢
客户端：收到！我好了
服务端：收到！

为什么要三次握手而不是两次？

上文，SYN是同步的意思，在同步报文段中我们看到双发互发了一个初始序号，这是为了保证数据传输的完整性。
那么我们来看，客户端告诉了服务端自己的初始序号，服务端回答了，说明服务端收到了，damn是！！！！服务端告诉客户端自己的初始序号，客户端是不是也要告诉服务端自己收到了？？？作为正常人都应该能理解。
咱还是考虑如果不进行第三次握手会发生什么：假设只有前两次握手，那么客户端收没收到服务端的初始序号，只有客户端知道，服务端呢？说好的双向奔赴呢？假设客户端没收到，又不告诉服务端，那么客户端就无法处理之后到达客户端的数据，那还建立个集贸啊。再者，如果客户端请求连接的报文堵车了（网络滞留），另外开了一个请求连接，这个连接释放后，滞留的那个连接来了，服务端以为这是新连接，连上后又没什么要干的，这不浪费服务端牢大资源吗？假设有三次握手，那么就算滞留报文来了，给客户端确认，但还有一次握手，客户端需要给服务端确认，那不就好说了，我不再建立连接了，所以客户端不确认，服务端第三次握手没成，不就好说了

TCP四次挥手

老规矩，上图：

怎么个事儿：

客户端没有数据向服务端传输了，向服务端发送终止报文（FIN置1，seq=u），要断开客户端向服务端的连接，进入终止等待1状态
服务端收到终止报文后，向客户端发送确认报文（ACK置1，ack=u+1），服务端进入关闭等待状态。由于服务端可能还有数据向客户端传输，所以不急于发送终止报文。第一次挥手完毕
客户端接收到服务端的确认报文后，进入终止等待2状态。第二次挥手完毕
在服务端没有数据向客户端传输后，向客户端发送连接释放报文（包括终止报文段和确认报文段），重复上次发送的确认报文，进入最后确认状态
客户端收到服务端发来的释放连接报文后，向服务端发送确认报文，进入时间等待状态。第三次挥手完毕
服务端收到确认报文后TCP连接释放。第四次挥手完毕
客户端经过2MSL后关闭，客户端TCP连接释放

我看看怎么个事儿：

客户端没有数据传输了，就向服务端申请释放去向连接
服务端收到申请并给与回复确认，怕自己还有数据传给客户端就先等一下
客户端收到确认后就等服务端发来释放来向连接的请求
服务端没有数据传给客户端了，就发送释放服务端向客户端的连接的请求
客户端收到释放连接请求和重复确认后，发送服务端一个确认回复，进入等待状态
服务端收到确认，释放连接
客户端等待时间到，释放连接

到底怎么个事儿？

客户端：我先不说了，拜拜
服务端：哦哦好，哦对了还有......
服务端：那我走了
客户端：嗯，好

为什么客户端要等2MSL再释放连接？

一是为了保证确认报文能够送达服务端，如果在服务端LAST-ACK状态时不能收到确认报文，服务端会超时重传FIN+ACK报文，也就是上次发送过去的报文
二是防止网络滞留的连接报文出现在本连接中MSL是报文最长时间寿命，经过2MSL后滞留报文必死无疑咯

为什么要四次挥手？

其实很简单，全双工的通道，双方双向奔赴的，我不爱你了，不代表你不爱我了，等到双方都不爱了才是彻彻底底结束了。同样，我没有数据传输给你了，然后我说我这边到你那边的通道可以关了，你说ok，但不代表你没有数据传输给我了，你说你到我这边的通道可以关了，我说ok。这样就算有始有终了

TCP头部格式

说了这么多TCP，我们来揭开TCP报文段的面纱。图来：

字段意义：

端口号：还记得刚开始介绍TCP的最基本的抽象吗，这里只有端口号，IP呢？IP由IP协议负责传递。再回顾一下：TCP连接端点叫套接字（socket），就是主机IP地址与进程端口拼接。套接字对（socket pair）确定一条TCP连接
序号：也就是我们在讲TCP三次握手四次挥手时里面提到的seq，TCP是面向字节流的，其传送的每一个字节都按顺序编号，seq是指发送的数据的第一个字节的序号。比如报文段序号为201，携带100字节序号，那么下一个报文段序号应该是301
确认号：期望收到对方下一个报文段的第一个数据的序号。收到数据段的头一个字节序号和数据段长度后，就能知道下一个报文段的第一个数据序号。若确认号是N，表明到序号N-1为止的所有数据都已正确收到，例如把确认号置为301，那么就表明对端发来的序号300为止的数据都收到了
数据偏移：指出TCP首部长度，为什么要有这个？看图，报文段首部有一个变长选项，所以需要指出首部长度以便找到数据段
窗口：接收方允许发送方发送的数据量，作为接收方让发送方设置其发送窗口，介绍流量控制的时候会用到
URG：紧急标志位，表明紧急指针字段有效，紧急指针指出了紧急数据末尾在报文段中的位置，所以紧急数据处理完后TCP就告诉应用程序恢复正常操作，类似于vip（你懂的）
ACK：确认标志位，ACK置为1确认号字段才有效，也就是ack，置为0则无效
PSH：推送标志位，就是插队，PSH置为1后此报文段就会被TCP往前移，优先传送，而不会是等缓存填满后再交付。相当于svip
RST：复位标志位，RST=1，表明TCP连接出错，必须释放连接，重新建立连接
SYN：同步标志位，用来同步序号，在握手时置为1表示这是一个连接请求或连接接收报文
FIN：终止标志位，用于释放连接标志

经过以上简单枯燥但有用的格式，字段学习，建议再回头看看三次握手和四次挥手，定茅塞顿开

TCP可靠传输

想知道TCP怎么实现可靠传输的吗？

要实现可靠传输，也就是不出差错，TCP有四大法宝：重传机制，滑动窗口，拥塞控制，流量控制

重传机制

TCP重传机制主要是为了防止网络丢包，其依赖于TCP头部中的确认号和序列号来判定是否重传，我们来看四种情况：超时重传，快速重传，SACK，D-SACK

超时重传

超时重传就是发送方在发送数据时设置一个定时器，规定时间内没有收到对方的ACK就重新发送数据包

超时重传时间该如何设置？

我们先了解一个概念：RTT。报文段往返时间。但由于网络通畅性未知，TCP就保留了一个加权平均往返时间RTTs：RTTs_new=(1-a)*(RTTs_last)+a*(RTT)；就是参考以往的RTT预判更接近真实网络情况的RTTs
有了RTTs就可以设置超时重传时间（RTO）了，RTO=RTTs+4*RTTd；RTTd是RTT的偏差的加权平均值

加入网络阻塞严重，重传时间不变的话将会发送频繁重传，就需要将RTO*2

快速重传

快速重传不将时间作为衡量标准，而是要求接收方不等待自己发送数据时才捎带确认，而是立即发送确认，一旦收到了失序报文就对自己曾经收到的报文重复确认，这样在发送端收到三个重复确认后就能知道出来差错并且哪部分开始重传，且立即重传

那我到底重传M2之后的所有报文还是只重传M2？

SACK

选择性重传（SACK）解决了上述问题，但前提是收到的报文段无差错，只是未按序号

如果接收方收到了两段不连续的字节块，那么它要将已收到的字节块信息（数据包序列号范围）准确告诉发送方让其不要重复发送这些数据，这样发送方通过SACK信息与重传机制加持就能找到丢失的数据包重传此数据包。

D-SACK

D-SACK可以让发送方知道是发出去的包丢了还是接收方回应的ACK包丢了，是不是发送方的数据包被网络延迟

我们都知道，如果丢包了，回应的ACK会一直卡在丢包的那段开头，而SACK会回复已收到的报文段信息。D-SACK其实是在SACK基础上，通过判断SACK的值，将其与ACK比较来确定发送包是网络延时迟到还是丢失：

如果SACK<ACK，表示这个SACK是D-SACK
如果SACK是上一段，就表示是回应的ACK包丢了
如果SACK是以往的一段，就表示是网络延时

滑动窗口（效率机制）

由于一对一的发送与应答效率实在低下，TCP采用段对段的发送与应答，啥意思？就是一次能发送多个数据包，而不是一个一个的等上一个确认来了再发下一个。那是不是等多个数据包确认都来了再发送多个数据包呢？非也！滑动窗口就是干这行的

滑动窗口的大小是无需等待确认应答而可以继续发送数据的最大值，还记得TCP头部格式中的窗口字段吗？发送端的窗口值就是接收方限制的，滑动窗口大小一定不能超过接收方规定的窗口值

对于滑动窗口的运作，看图：

发送端可以把滑动窗口内的数据发送出去。
如果发送出去的数据未收到新的确认，滑动窗口左边界将无法右移，且数据将保留以便超时重传。如果收到了新的确认，将右移
发送窗口右边界一般是一直右移。也可能不移动（没有收到新的确认且对方通知的新窗口大小不变；收到新的确认但对方通知的窗口变小）

接收端也设定一个固定大小的窗口，当收到一个包并且发送确认，交付给主机后，窗口就可以右移，并且不用保留这些数据
如果其中有数据包未按序收到，重传机制上场，该怎样就怎样

值得一提的是，TCP有发送缓存和接收缓存的机制，滑动窗口大小在缓存范围之内，缓存空间和序号空间都是有限的，并且循环使用

流量控制（安全机制）

上文我们讲到窗口字段限定发送窗口的大小，流量控制其实只是利用这个字段限制发送方的发送速度，防止发送方发送过快而超过接收方处理数据的速度，进而造成接收缓存区过满而丢包的现象。所以流量控制是滑动窗口的延申，是TCP根据接收端的处理能力来控制发送端的发送速度的安全机制

拥塞控制（安全机制）

拥塞控制是滑动窗口的延申，它根据网络拥塞程度动态设置滑动窗口的大小，这个窗口叫拥塞窗口（cwnd）。最后的滑动窗口=MIN{流量控制窗口，拥塞窗口，接收方窗口}。拥塞控制是TCP可靠传输的大杀器，它由四个算法作支柱：慢开始，拥塞避免，快重传，快恢复。

我们先来看这四种算法：

慢开始：当主机建立连接并开始传输数据时，并不知道当前网络的负荷情况，如果立即发送大量数据，很可能引发网络拥塞，要判断杯子里面的水烫不烫，就得小心翼翼地试探，所以由小到大逐渐增大发送的数据字节，即逐渐增大拥塞窗口。但慢开始时候窗口不是直线增大，而是指数规律增大，比如一开始窗口值设置为1，那么在不出意外的情况下，窗口值之后增大为2，4，8，16，32。其实慢开始指的是慢热，一开始拘谨，熟了之后就大开大合。所以“慢开始不慢”，只是相对于把大量数据直接注入网络的速度慢很多
拥塞避免：在网络不出问题的情况下，理论上慢开始能让拥塞窗口一直增大，但实际上那肯定会引起网络拥塞的。所以为了防止这种情况，设定一个最大门限（慢开始门限）ssthresh。当cwnd<ssthresh时使用慢开始算法，而cwnd>ssthresh时使用拥塞避免算法。拥塞避免就是让cwnd线性增大，小于慢开始的速率。此后，若发生网络拥塞，重新开始设置窗口值cwnd=初始值，ssthresh=cwnd/2，从头开始
快重传：见前文重传机制。就是发送方收到三个重复的确认ACK，重传
快恢复：当发生快重传时，将不重新开始慢开始算法，而是直接将cwnd置为ssthresh，开始拥塞避免算法
不论是发生网络拥塞，还是重传，必将ssthresh的值置为当前cwnd值的1/2

TCP半连接队列和全连接队列

Linux会在TCP连接三次握手时创建两个队列：半连接队列（SYN队列）和全连接队列（Accept队列）

首先客户端发起请求连接
服务端收到请求后，将这个连接信息放入半连接队列，返回同步确认
待服务端收到客户端的ACK后，将半连接队列的一个连接放入全连接队列，这时就等待服务端处理连接

TCP半连接队列和全连接队列都是为了有效管理连接请求和已建立的连接而设计的。半连接队列用于暂时保存尚未建立完全连接的请求，全连接队列则用于存储已经建立的连接，以便进行数据传输和通信。队列的限制大小有助于防止服务器过载和拒绝服务情况的发生。半连接队列相当于餐厅的前台，负责接待客户，全连接队列就是后厨，真正服务客户。如果没有前台，一大堆客户端请求来到，连接队列满则会丢弃或拒绝连接，这里的半连接队列可以视为缓冲区

TCP粘包

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。由于TCP传输协议面向流的，没有消息保护边界。一方发送的多个报文可能会被合并成一个大的报文进行传输，这就是粘包；也可能发送的一个报文，可能会被拆分成多个小报文，这就是拆包。

造成TCP粘包的原因

发送方原因：TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量。只有上一个分组得到确认，才会发送下一个分组，收集多个小分组，在一个确认到来时一起发送）
接收方原因：TCP接收到数据包时，应用层并不会立即处理。TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

解决办法

当我们处理的数据是内容相关的一大段时可以对粘包现象置之不理。可一旦我们处理的多组数据毫不相关，就要解决粘包问题了：发送方可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。

应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

采用固定长度的报文。发送端一次发送定长报文，接收端一次处理定长报文
在报文前加上报文长度。报文长度（4Btyes int）+报文内容
报文之间使用分隔符。http协议\r\n\r\n

UDP

UDP 是面向报文的，所谓面向报文，是指面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会是IP太小。

UDP 是不具有可靠性的数据报协议，细微的处理它会交给上层的应用去完成。在 UDP 的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会到达。因此，应用有时会根据自己的需要进行重发处理。

UDP使用场景

由于UDP具有低延迟和高效性的特点，它适用于以下场景：

视频流和音频流传输：由于UDP的低延迟，它常用于视频流和音频流的实时传输，如在线直播、视频会议等。
实时游戏：UDP的快速传输和低延迟使其成为在线游戏中常用的协议，可以实现实时的游戏数据传输。
DNS（域名系统）：UDP广泛用于域名系统中，用于域名解析和查询。
实时传感器数据：UDP适用于需要快速传输实时传感器数据的场景，如工业自动化、物联网等。

UDP特性

无连接性：UDP不需要在通信之前建立连接。
不可靠性：UDP不提供确认和重传机制，数据传输可能丢失或乱序。
低延迟：由于不需要建立连接和进行确认，UDP具有较低的传输延迟。
高效性：UDP头部较小，传输效率高。
适用于实时应用：UDP适合实时应用，如音视频传输、游戏等。

HTTP

在讨论http前，我们先来了解一些基本概念

web服务：web服务其实就是将浏览器当成客户端，浏览器向服务端发送请求，服务端接收到请求后给浏览器返送数据的B/S体系结构。大致流程是：

浏览器通过HTTP/HTTPS协议发送请求
服务端接收请求返回响应
服务端把HTML文件内容发送给浏览器
浏览器渲染界面

万维网（WWW）：万维网（World Wide Web）是一个大规模，联机式的信息储藏所，简称Web。万维网是一个分布式的超媒体系统，我们常说的网站就是万维网的一个站点，里面存储了多种多样的大量信息

URL：统一资源定位符。用于表示从互联网上得到的资源位置和访问这些资源的方法，互联网上的所有资源都有一个唯一确定的URL，可以把URL当成任意互联网上相连机器的可访问对象的指针。URL形式：协议://主机名:端口/路径

协议：以何种协议来获取这个万维网文档，例如http
主机名：万维网存放文档的主机域名或IP地址，如www.baidu.com
端口：端口号，常被省略，HTTP默认80
路径：较长的字符串，区分大小写，指定内容的路径

HTTP

HTTP协议(超文本传输协议HyperText Transfer Protocol)，是使用TCP协议的应用层传输协议，是客户端和服务端进行数据传输的一种规则，定义了浏览器如何向万维网服务器请求万维网文档，以及服务器如何把文档传送给浏览器。

HTTP特性

无状态：就是不保存通信记录，任何一次发送HTTP请求与响应请求都不会记录下来，每个请求都是独立的，这样简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求
简便：在用户向服务器请求服务时，只需传送请求方法（GET，POST等）和路径，不需要发送额外过多的数据。由于结构简单，自然通信效率高
灵活：允许传输任意类型的数据对象
无连接：HTTP使用面向连接的TCP可靠传输，但其本身是无连接的。当服务器对客户的请求处理完毕并收到客户的应答后流程就结束了。

HTTP1.1/HTTP2/HTTP3的演变

HTTP/1.1---标准化协议

HTTP/1.1 消除了大量歧义内容并引入了多项改进：

连接可以复用，节省了多次打开 TCP 连接加载网页文档资源的时间。
增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。
支持响应分块。
引入额外的缓存控制机制。
引入内容协商机制，包括语言、编码、类型等。并允许客户端和服务器之间约定以最合适的内容进行交换。
凭借host标头，能够使不同域名配置在同一个 IP 地址的服务器上。

HTTP/2---为了更优异的表现

这些年来，网页愈渐变得的复杂，甚至演变成了独有的应用，可见媒体的播放量，增进交互的脚本大小也增加了许多：更多的数据通过 HTTP 请求被传输。HTTP/1.1 链接需要请求以正确的顺序发送，理论上可以用一些并行的链接（尤其是 5 到 8 个），带来的成本和复杂性堪忧。比如，HTTP 管线化（pipelining）就成为了 Web 开发的负担。为此，在 2010 年早期，谷歌通过实践了一个实验性的 SPDY 协议。这种在客户端和服务器端交换数据的替代方案引起了在浏览器和服务器上工作的开发人员的兴趣。明确了响应数量的增加和解决复杂的数据传输，SPDY 成为了 HTTP/2 协议的基础。

HTTP/2 在 HTTP/1.1 有几处基本的不同：

HTTP/2 是二进制协议而不是文本协议。不再可读，也不可无障碍的手动创建，改善的优化技术现在可被实施。
这是一个多路复用协议。并行的请求能在同一个链接中处理，移除了 HTTP/1.x 中顺序和阻塞的约束。
压缩了标头。因为标头在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。
在 2015 年 5 月正式标准化后，HTTP/2 取得了极大的成功，在 2022 年 1 月达到峰值，占所有网站的 46.9%，高流量的站点最迅速的普及，在数据传输上节省了可观的成本和支出。
这种迅速的普及率很可能是因为 HTTP2 不需要站点和应用做出改变：使用 HTTP/1.1 和 HTTP/2 对他们来说是透明的。拥有一个最新的服务器和新点的浏览器进行交互就足够了。只有一小部分群体需要做出改变，而且随着陈旧的浏览器和服务器的更新，而不需 Web 开发者做什么，用的人自然就增加了。

HTTP/3---基于QUIC的HTTP

HTTP 的下一个主要版本，HTTP/3 有着与 HTTP 早期版本的相同语义，但在传输层部分使用 QUIC而不是 TCP。

QUIC 旨在为 HTTP 连接设计更低的延迟。类似于 HTTP/2，它是一个多路复用协议，但是 HTTP/2 通过单个 TCP 连接运行，所以在 TCP 层处理的数据包丢失检测和重传可以阻止所有流。QUIC 通过 UDP运行多个流，并为每个流独立实现数据包丢失检测和重传，因此如果发生错误，只有该数据包中包含数据的流才会被阻止。