计算机网络——HTTP_计算机网络 chuck

网络基础TCP/IP协议

博客参考：太厉害了，终于有人能把TCP/IP 协议讲的明明白白了
OSI七层模型及各层功能概述
什么是TCP/IP：

1：实际中TCP/IP 是指 TCP 和 IP 两种协议。


2：然而在很多情况下，TCP/IP 是指利用 IP 进行通信时所必须用到的协议群的统称。

具体来说，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。
他们与 TCP 或 IP 的关系紧密，是互联网必不可少的组成部分。
TCP/IP 一词泛指这些协议，因此，有时也称 TCP/IP 为网际协议群。

3：互联网进行通信时，需要相应的网络协议，
TCP/IP 原本就是为使用互联网而开发制定的协议族。
因此，互联网的协议就是 TCP/IP，TCP/IP 就是互联网的协议。
1
2
3
4
5
6
7
8
9
10
11
12

HTTP

HyperText Transfer Protocol，超文本传输协议
HTTP 是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频、「超⽂本」数据的「约定和规范」。
两点：服务器 到 服务器。
不同服务器之间实现解耦合，谷歌可以自由访问火狐浏览器　因为遵从了HTTP协议
HTTP请求协议

请求头
请求行
空白行
请求体
1
2
3
4

HTTP响应协议

状态行　　即状态码　1ｘｘ　2ｘｘ　3ｘｘ　4ｘｘ　5ｘｘ
响应头　　即字段　告诉响应内容格式信息
空白行
响应体　　即实际效果
1
2
3
4

URL：统一资源定位符 ，是对可以从互联网上得到的资源的位置和访问方法的一种唯一标识，是互联网上标准资源的地址。

URI：统一资源标识符，是一个用于标识某个唯一互联网资源名称的字符串。

HTTP状态码

HTTP常见状态码（14种）


返回码-状态码详解及解决方案
1xx
提示信息，接受到的信息正在处理当中，是协议处理的中间过程状态
2xx
服务器成功处理了客户端发送的请求。

200
成功状态码，表示一切正常。
请求所希望的响应头或数据体将随此响应返回
1
2
3

204
成功状态码
返回的响应头没有body数据
1
2
3

206
应用于HTTP分块下载或断点续传，响应头的返回的body数据并不是全部资源，只是其中一部分，也是服务器的成功处理的状态
1
2

3xx
重定向：表示客户端请求的资源发生了变化，需要客户端用心的URL地址重新发生请求获取资源

301
表示永久重定向，请求资源已经不在，需要用新的URL来访问
1
2

302
表示临时重定向，请求资源还在，需要另一个URL访问
1
2

301 和 302 都会在响应头力加上字段Location，指明需要调整的URL

304
不具有跳转的含义，表示资源未修改，᯿定向已存在的缓冲⽂件，也称缓存᯿定向，⽤于缓
存控制
1
2
3

4xx
类状态码表示客户端发送的报文有错误，服务器无法处理，错误码

400
客户端发生的报文发生错误，是一个笼统的错误
1
2

403
服务器禁止访问资源 不是客户端的问题
1
2

404
请求资源在服务器上无法找到，无法提供给客户端
1
2

5xx
类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务端的错误码

500 一个笼统的错误码
1

501 客户端的请求功能无法达到 还不支持
1

502 表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误
1

503 表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后再试”的意思
1

Http常见的字段

HTTP请求中的请求字段
客户端发送请求时，⽤来指定服务器的域名。
如http：www.A.com A 就是一个字段
有了 Host 字段，就可以将请求发往「同⼀台」服务器上的不同⽹站。
Content-Length 字段

表明本次回应的数据⻓度
Content-Length: 1000
如上⾯则是告诉浏览器，本次服务器回应的数据⻓度是 1000 个字节，后⾯的字节就属于下⼀个回应了。
1
2
3

Content-Encoding字段

服务器通过这个头告诉浏览器数据的压缩格式，只接受固定格式数据
1

Content-Type字段

服务器通过这个头告诉浏览器回送数据的类型
1

Connection 字段

最常⽤于客户端要求服务器使⽤ TCP 持久连接，以便其他请求复⽤
HTTP/1.1 版本的默认连接都是持久连接，但为了兼容⽼版本的 HTTP，需要指定 Connection ⾸部字段的值为
Keep-Alive
1
2
3

GET与POST

HTTP请求方法最常用的有两种方法：GET 和 POST
最常用的方法有四种Put，Delete、post，get，即增删改查。
Put 和Delete可以通过Get/Post来实现。用的不多。

1如何设置POST请求方法：

在html中  在form表单中 设置method=post
1

2可见性
GET：
请求数据信息在请求行上，浏览器地址栏上可见 即在URL（统一资源定位符上） ？后面跟着数据
POST：
请求数据信息在请求体上，浏览器地址栏上不可见

3安全性 对服务器来说
GET：
绝对安全
get只是为了获取数据，查询数据，不会对服务器造成威胁
POST：
会修改提交服务器上的数据，所以一般拦截请求的时候会大部分拦截（监听）POST请求。
关于注册登录的时候肯定使用GET不然信息会暴露到浏览器上。

但整的来说 都不安全，因为HTTP在网络上都是明文传输的，只要在网络节点上捉包，就能完整的获取数据报文。

4请求内容
GET：
只能发送普通字符串，且长度有限，无法发送大量数据
所以GET是获取数据，查询数据，不会修改服务器上的数据
POST：
能请求发送任何类型数据包括字符串 图片 音视频，可以发送大量数据，理论上没有限制
POST请求时可以修改数据、传送数据，如在博客上回帖、评论

5如何衡量选择GET还是POST
向服务器获取查询数据选择GET
向服务器发送数据，提交数据，选POST

大部分表单form使用的是post，因为要修改数据，收集信息
如果涉及敏感信息 如密码 那么请求方式建议post 因为get会显示信息（在浏览器url中）

6缓存不缓存
GET：
支持缓存 可收藏为书签
如访问浏览器 第一次很慢，然后后面刷新 会很快 因为GET请求方式 支持了缓存。
*** 任何一个GET请求的响应结果都会被浏览器缓存起来
只要发送GET 浏览器先缓存，避免重复缓存时的多余操作。

get如何避免被缓存： 在url路径后面加上系统时间  那么每次请求的路径都会发生变化，就不会使用缓存的结果。
1

POST：
响应结果不缓存 ，不支持缓存 不可收藏为书签

6长度限制
HTTP对URL没有长度的限制 ，有所限制也是浏览器等第三方加的，避免过多消耗，保证性能和安全。并不是因为GET的数据在请求头中，而POST的数据在请求体中。

HTTP特点

无状态，明文传输，不安全

Session Cookie JWT

看完这篇 Session、Cookie、Token，和面试官扯皮就没问题了
彻底了解Cookie和Session的区别（面试）

做web开发，怎么能不懂cookie、session和token呢？
01无状态
服务器不会记录HTTP的状态（登陆）。

好处：减少服务器资源去记录状态信息
不足：当涉及账号的关联操作时需要验证身份 如添加购物车、下单、结算、支付
1
2

解决办法

Session：
客户端请求服务端，服务端会为这次请求开辟一块内存空间，
这个对象便是 Session 对象，存储结构为 ConcurrentHashMap。
Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。

服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），
同时生成一个 sessionId ，并通过响应头的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，
向客户端发送要求设置 Cookie 的响应； 
客户端收到响应后，在本机客户端设置了一个 **JSESSIONID=XXXXXXX **的 Cookie 信息，
该 Cookie 的过期时间为浏览器会话结束；
接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ）， 
然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。


Cookie： 通过在请求和响应报⽂中写⼊ Cookie 信息来控制客户端的状态
相当于，在客户端第⼀次请求后，服务器会下发⼀个装有客户信息的「⼩贴纸」，后续客户端请求服务器的时候，
带上「⼩贴纸」，服务器就能认得了了
Cookie分为永久性Cookie和会话Cookie 用来定义相对时间
HttpOnly 是微软对 Cookie 做的扩展，该值指定 Cookie 是否可通过客户端脚本访问 确保安全性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

不安全
HTTP的不安全问题通过HTTPS的方式解决也就是通过引⼊ SSL/TLS 层，使得在安全上达到了极致。
窃听⻛险，⽐如通信链路上可以获取通信内容
篡改⻛险，⽐如强制植⼊垃圾⼴告，视觉污染
冒充⻛险，⽐如冒充淘宝⽹站

HTTPS解决HTTP不安全问题

HTTPS、SSL、TLS三者之间的联系和区别

HTTPS 在 HTTP 与 TCP 层之间加⼊了 SSL——Secure Socket Layer 安全套接层/TLS——Transport Layer Security 协议——传输层安全协议，可以很好的解决了上述的⻛险：
信息加密、校验机制、身份证书
SSL 是指安全套接字层，简而言之，它是一项标准技术，可确保互联网连接安全，保护两个系统之间发送的任何敏感数据，防止网络犯罪分子读取和修改任何传输信息，包括个人资料。两个系统可能是指服务器和客户端（例如，浏览器和购物网站），或两个服务器之间（例如，含个人身份信息或工资单信息的应用程序）。

TLS/SSL是一种加密通道的规范
它利用对称加密、公私钥不对称加密及其密钥交换算法，CA系统进行加密且可信任的信息传输
TLS与SSL在传输层对网络连接进行加密。
TLS是SSL的标准化后的产物

SSL分为两层：

 SSL记录协议（SSL Record Protocol）：
 它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持
1
2

SSL握手协议（SSL Handshake Protocol）：
它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
1
2

TLS分两层：用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。
TLS 的最大优势就在于：
TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而，TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。

混合加密

对称加密： 只有一个秘钥 ，不能保证安全
非对称加密： 公钥和私钥
私有秘钥是持有方才有的秘钥
私钥一般放在服务器中，
数据通过客户端的公钥加密就只能被接收端服务器的私钥解密（md5加密）

摘要算法
摘要算法用于保证数据的完整性
在客户端为服务器发送明文的时候，会通过摘要算法根据数据生成对应的密码，再将密码和明文一同加密成密文，发送给服务器，服务器接收到解密之后，会通过相同的摘要算法得到一个密码2，然后比较客户端携带的密码，如果一致，说明数据完整

数字证书
在对称加密中，客户端和服务器通过公匙来加密信息、解密信息，虽然摘要算法可以确保数据的一致性，但不能保证公匙是否正确，万一公匙被替换，那么数据也是假的，所以会通过数字认证机构CV颁发的证书来确定服务器是否有备案。即公匙是否可信。

SSL四次握手
在此之前要先学一下TCP的三次握手（目前没学 不过可以先看SSL）。

SSL/TLS协议基本流程（建立在可靠的TCL层上）

客户端向服务器索要并验证服务器公匙
双方协商产生会话密匙
双方采样会话密匙进行加密通信
1
2
3

第一步：
Client hello

客户端向服务器发送：
TLS支持版本
第一个随机数
加密套件（加密算法）
1
2
3
4

第二步
Server Hello

服务器给客户端响应：
支持的TLS版本号
第二个随机数
加密套件

之后再次响应：
出示CV认证的证书

再次响应：
服务器发送自己的公钥
（当然 服务器也可以向客户端索要证书）

再次响应回复：server Hello Done
1
2
3
4
5
6
7
8
9
10
11
12
13

以上两步 过程没有加密。

第三步
Client Key Exchange

客户端处理响应:
第三个随机数：预主秘钥
预主秘钥通过服务器发送的公钥进行加密，并发送给服务器。
并响应一个：Change Cipher Spec 告诉服务器后面用商议好的加密算法和秘钥进行加密
响应：Encrypted Handshake Message表示客户端协商成功可以加密传输
1
2
3
4
5

第四步

服务器响应：Encrypted Handshake Message表示服务器协商成功可以加密传输
1

四步总结：

第一次握手：客户端发送第一个随机数给服务端——C/S都有了第一个随机数
第二次握手：服务器给与客户端响应发送第二个随机数+服务器公匙——C/S都有了两个一样的随机数
第三次握手：客户端再次生成第三个随机数（预主秘钥）并使用服务器公匙进行加密传输给服务器——C/S有了三个一样的随机数
通过三个随机数+加密算法，生成了一个会话密匙——第三步中，双方用了公匙加密传输

第四次握手：服务器响应协商成功，后续都用会话密匙传输。

在这个过程中都使用非对称加密，即每次秘钥都不同，
协议协商成功后，C/S使用一个共同的会话密匙进行加密。

HTTPS协议详解(四)：TLS/SSL握手过程

HTTP1.0、1.1、2.0的区别

连接方面：HTTP1.1的改进

HTTP1.0规定浏览器和服务器保持短暂连接。
每次访问都需要建立一个TCP连接，然后再断开，服务器不会跟踪、记录客户过去的请求

比较浪费资源和时间
1
2
3
4

HTTP1.1
支持管道网络传输—和持久连接
即在同一个TCP连接里面，客户端可以同时发送多个请求——TCP连接默认不关闭，可以被多个请求复用

1
2
3
4

HTTP1.1的缺点
队头阻塞

只能压缩请求/响应体Body，不能压缩请求头
Head过大会造成延迟，相同的head会造成资源浪费

服务器是按照请求顺序响应，会造成客户端一直得不到响应————队头阻塞
传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了
1
2
3
4
5

HTTP2.0的改进

保留1：兼容HTTP1.1
在url协议方面：明文传输http://   加密传输https://
保留2：应用层基于TCP协议传输
HTTP2把HTTP分为语义和语法   语法方面——请求方法 状态码 字段保持不变
1
2
3
4

改变之处

01压缩响应/请求头，同时消除重复的head

HTTP1可以对请求体进行压缩，但对于请求头没有压缩，HTTP2针对请求头进行压缩
1

HTTP2使用HPACK算法进行请求头的压缩：

HPACK算法分文三个：
静态字典、动态字典、哈夫曼编码压缩。
主要功能：客户端和服务器共同维护一张head信息表（字典），所有字段都存入此表，并有对应的索引号，哈夫曼用来压缩。

02Stream 二进制流

将报文转化为二进制格式进行数据传输——头信息帧、数据帧。
帧头的最后 4 个字节是流标识符（Stream ID）,
接收⽅可以根据这个信息从乱序的帧
⾥找到相同 Stream ID 的帧增加了数据传输的效率.
1
2
3
4

03对数据流做标记，客户端指定数据流的优先级，优先级高，服务器先处理

04多路复用——移除了 HTTP/1.1 中的串⾏请求，可以对一个连接中的多个响应或请求作出处理，解决了队头阻塞问题*（前提是二进制分帧）

05并发传输

HTTP/2 实现了 Stream 并发，多个 Stream 只需复⽤ 1 个 TCP 连接，节约了 TCP 和 TLS 握⼿时间，
以及减少了 TCP 慢启动阶段对流ᰁ的影响。
1
2

不同的 Stream ID 才可以并发，即时乱序发送帧也没问题，但是同⼀个
Stream ⾥的帧必须严格有序。

06服务器可以主动给客户端发送消息

HTTP2.0的缺点
HTTP2.0基于 TCP连接
队头阻塞多个请求复⽤⼀个TCP连接，⼀旦发⽣TCP丢包，就会阻塞住所有的 HTTP （TCP连接中的）请求。

TCP 与 TLS 的握⼿时延迟

TCP 由于具有「拥塞控制」的特性，所以刚建⽴连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接
产⽣"减速"效果。
1
2

⽹络迁移需要重新连接
TCP连接是基于 源IP 源端口 目标IP 目标端口
一旦有一个变动，那么需要重新握手连接

HTTP/1.1的优化

-----01短连接变为长链接
使用KeepAlive将HTTP/1.1从短连接改为长连接，减少TCP的建立和断开的次数。

-----02避免发送HTTP请求
why： 避免重复性的HTTP请求，如数据都是一样的时候。
how：通过缓存技术将 请求-响应 的数据都缓存在本地。
数据保存在本地磁盘上：URL作为Key 响应 作为 Value(包含时间信息 避免响应过期)

-----03减少HTTP的请求次数

a减少重定向次数使用代理服务器，这样避免了HTTP的多次请求。
302资源还在，但是需要更换URL

b合并请求
如果把多个访问⼩⽂件的请求合并成⼀个⼤的请求，虽然传输的总资源还是⼀样，但是减少请求，也就意味着减少
了重复发送的 HTTP 头部。

c延迟发送请求
一般HTML中 有多个URL，对于当前不用的资源，我们可以进行按需获取
如页面中 下滑不断获取新的资源以达到延迟请求。

-----04减少HTTP响应大小
一般如果所需响应过大，服务器返回的资源也较大
有损压缩-无损压缩

HTTPS解决HTTP不安全问题——RSA算法

HTTPS、SSL、TLS三者之间的联系和区别

HTTPS 在 HTTP 与 TCP 层之间加⼊了 SSL——Secure Socket Layer 安全套接层/TLS——Transport Layer Security 协议，可以很好的解决了上述的⻛险：
信息加密、校验机制、身份证书
SSL 是指安全套接字层，简而言之，它是一项标准技术，可确保互联网连接安全，保护两个系统之间发送的任何敏感数据，防止网络犯罪分子读取和修改任何传输信息，包括个人资料。两个系统可能是指服务器和客户端（例如，浏览器和购物网站），或两个服务器之间（例如，含个人身份信息或工资单信息的应用程序）。

TLS/SSL是一种加密通道的规范
它利用对称加密、公私钥不对称加密及其密钥交换算法，CA系统进行加密且可信任的信息传输
TLS与SSL在传输层对网络连接进行加密。
TLS是SSL的标准化后的产物

SSL分为两层：

 SSL记录协议（SSL Record Protocol）：
 它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持
1
2

SSL握手协议（SSL Handshake Protocol）：
它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
1
2

TLS分两层：用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。
TLS 的最大优势就在于：
TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而，TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。

混合加密

对称加密： 只有一个秘钥 ，不能保证安全
非对称加密： 公钥和私钥
私有秘钥是持有方才有的秘钥
私钥一般放在服务器中，
数据通过客户端的公钥加密就只能被接收端服务器的私钥解密（md5加密）

摘要算法
摘要算法用于保证数据的完整性
在客户端为服务器发送明文的时候，会通过摘要算法根据数据生成对应的密码，再将密码和明文一同加密成密文，发送给服务器，服务器接收到解密之后，会通过相同的摘要算法得到一个密码2，然后比较客户端携带的密码，如果一致，说明数据完整

数字证书
在对称加密中，客户端和服务器通过公匙来加密信息、解密信息，虽然摘要算法可以确保数据的一致性，但不能保证公匙是否正确，万一公匙被替换，那么数据也是假的，所以会通过数字认证机构CV颁发的证书来确定服务器是否有备案。即公匙是否可信。

SSL四次握手
在此之前要先学一下TCP的三次握手（目前没学 不过可以先看SSL）。

SSL/TLS协议基本流程（建立在可靠的TCL层上）

客户端向服务器索要并验证服务器公匙
双方协商产生会话密匙
双方采样会话密匙进行加密通信
1
2
3

第一步：
Client hello

客户端向服务器发送：
TLS支持版本
第一个随机数
加密套件（加密算法）
1
2
3
4

第二步
Server Hello

服务器给客户端响应：
支持的TLS版本号
第二个随机数
加密套件

之后再次响应：
出示CV认证的证书

再次响应：
服务器发送自己的公钥
（当然 服务器也可以向客户端索要证书）

再次响应回复：server Hello Done
1
2
3
4
5
6
7
8
9
10
11
12
13

以上两步 过程没有加密。

第三步
Client Key Exchange

客户端处理响应:
第三个随机数：预主秘钥
预主秘钥通过服务器发送的公钥进行加密，并发送给服务器。
并响应一个：Change Cipher Spec 告诉服务器后面用商议好的加密算法和秘钥进行加密
响应：Encrypted Handshake Message表示客户端协商成功可以加密传输
1
2
3
4
5

第四步

服务器响应：Encrypted Handshake Message表示服务器协商成功可以加密传输
1

四步总结：

第一次握手：客户端发送第一个随机数给服务端——C/S都有了第一个随机数
第二次握手：服务器给与客户端响应发送第二个随机数+服务器公匙——C/S都有了两个一样的随机数
第三次握手：客户端再次生成第三个随机数（预主秘钥）并使用服务器公匙进行加密传输给服务器——C/S有了三个一样的随机数
通过三个随机数+加密算法，生成了一个会话密匙——第三步中，双方用了公匙加密传输

第四次握手：服务器响应协商成功，后续都用会话密匙传输。

在这个过程中都使用非对称加密，即每次秘钥都不同，
协议协商成功后，C/S使用一个共同的会话密匙进行加密。

HTTPS协议详解(四)：TLS/SSL握手过程

HTTPS的优化

HTTPS性能消耗较大——通过非对称加密和对称加密算法，传输之后应用数据又需要解密
01性能损坏—— 握手过程 和 加密报文传输

解决：改善加密算法。

02硬件优化——HTTPS 协议是计算密集型，⽽不是 I/O 密集型（计算量大，而不是传输多）

解决：提高CPU

03软件优化

04协议优化
ECDHE密匙交换优于RSA算法

05TLS升级

06证书优化
01证书传输优化 02证书验证优化 03OCSP——在线证书状态协议

07会话复用——保存会话密匙
a利用SessionID服务器端的SessionID保存会话密匙，
下次连接时，请求的消息里会带有SessionID，就可以建立通信，当然为了安全性。有个时间限制。
缺点：服务器压力大，服务器如果保存很多客户端的会话密匙，内存压力大
现在服务器有多台，下次服务器-客户端 不一定保持一致
b利用Session Ticket
会话密匙作为Ticket保存，下次访问连接 服务器解密即可。

但二者都不安全，容易重放攻击破解所以也应该设置一个过期时间。

HTTP3.0

HTTP2.0的缺点

HTTP2.0基于 TCP连接
队头阻塞多个请求复⽤⼀个TCP连接，⼀旦发⽣TCP丢包，就会阻塞住所有的 HTTP （TCP连接中的）请求。

TCP 与 TLS 的握⼿时延迟

TCP 由于具有「拥塞控制」的特性，所以刚建⽴连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接
产⽣"减速"效果。
1
2

⽹络迁移需要重新连接
TCP连接是基于 源IP 源端口 目标IP 目标端口
一旦有一个变动，那么需要重新握手连接

解决HTTP2的方法就是使用HTTP3——传输层协议–>UDP

HTTP3在传输层上使用的是UDP（用户数据报协议），在应用层使用了QUIC协议（低时延的互联网传输层协议）

HTTP3——UDP–QUIC

无队头阻塞
QUIC也有和HTTP2类似的多路复用/Stream，既可以在一条TCP连接上传输多个STream

QUIC的传输协议是UDP——UDP不关心数据包的顺序，发生数据包丢失也不会发生队头阻塞
但QUIC有个数据可靠性：即使发生了数据包丢失，即使其他数据包传输到服务器，服务器也不会读取，直到读取到丢失的数据包，才会读取其他数据。（只是不影响传输）

更快的连接建立
原TCP、TLS是分层的，分别属于 传输层和表示层，所以要分批次握手，即先TCP握手，在TLS握手。

而HTTP3 中的QUIC协议与TLS协议不分层，QUIC包含TLS层。（不太理解）
连接前移
QUIC没有通过四元组（源 IP、源端⼝、⽬的 IP、⽬的端⼝）进行连接，而是通过连接ID来标记两个通信的端点。
后续哪怕四元组变化了，只要双方还有会话密匙，还可以通过ID来进行连接。

HTTP3——其他特点

STream

不需要和HTTP2.0一样，自身定义Stream，
QUIC中有Stream，所以HTTP3的帧结构变简单了

压缩算法PACK

HTTP2——HPACK（静态字典、动态字典、哈夫曼编码）
HTTP3——QPACK（静态表扩大）

解决队头阻塞

（原理不知）
QUIC 连接上的多个 Stream 之间并没有依赖，都是独⽴的，也不会有底层协议限制，某个流发
⽣丢包了，只会影响该流，其他流不受影响