01 HTTP协议相关

应用层常见协议

• 超文本传输：HTTP、HTTPS
• 文件传输：FTP
• 电子邮件：SMTP、POP3、IMAP
• 动态主机配置：DHCP
• 域名系统：DNS

1.1 DNS

根据等级不同，域名可以分为

• 顶级域名（Top-level Domain，简称TLD）
• 二级域名
• 三级域名
• … …

1.1.1 顶级域名分类

• 通用顶级域名（General Top-level Doman，简称gTLD）

.com 公司， .net 网络机构， .org 组织机构， .edu 教育

.gov 政府部门， int 国际组织，等。

• 国家及地区顶级域名（Country Code Top-level Domain，简称ccTLD）

.cn 中国， .jp 日本， .uk 英国

• 新通用顶级域名（New gTLD）

.vip，.xyz，.top，.club，.shop 等。

二级域名：

• 在通用顶级域名之下，一般指域名注册人的名称。如Google和Baidu等。
• 在国家及地区顶级域名下，一般指注册类别，例如com、edu、gov、net等。

1.1.2 DNS协议

DNS全称是：Domain Name System，译为：域名系统。利用DNS协议，可以将域名解析称对应的IP地址。

DNS可以基于UDP，也可以基于TCP，服务器占用53端口

1.2.3 DNS服务器

• 客户端首先回访问最近的一台DNS服务器（也就是客户端自己配置的DNS服务器）。
• 所有的DNS服务器都记录了DNS根域名服务器的IP地址。
• 上级DNS服务器记录了下一级DNS服务器的IP地址。
• 全球一共13台IPv4的DNS根域名服务器，25台IPv6的DNS根域名服务器。

1.2 DHCP

IP地址的分配方式：

• 静态IP地址：手动设置。适用于不怎么挪动的台式机、服务器。
• 动态IP地址：从DHCP服务器自动获取IP地址，适用于移动设备、无线设备。

DHCP（Dynamic Host Configuration Protocol），译为：动态主机配置协议。

DHCP协议基于UDP，客户端时68端口，服务器时67端口。

DHCP服务器会从IP地址池中，挑选一个IP地址”出租“给客户端一段事件，时间到期就回收它们。

1.2.1 DHCP分配IP地址的4个阶段

• DISCOVER：发现服务器

发广播包（源IP是0.0.0.0，目标IP是255.255.255.255，目标MAC是FF:FF:FF:FF）。

• OFFER：提供租约

服务器返回可以租用的IP地址，以及租用期限、子网掩码、王国、DNS等信息。

注意：这里有可能会有多个服务器提供租约。

• REQUEST：选择IP地址

客户端先择一个OFFER，发送广播包进行回应

• ACKNOWLEDGE：确认

被选中的服务器发送ACK数据包给客户端。

DHCP服务器是可以跨网段分配IP地址的，可以借助DHCP中继代理（DHCP Relay Agent）实现跨网段分配IP地址。

自动续约：客户端会在租期不足的时候，自动像DHCP服务器发送REQUEST信息申请续约。

1.3 HTTP

HTTP（Hyper Text Transfer Protocol），超文本传输协议。

是互联网中应用最广发的应用层协议之一，涉及HTTP最初的目的是提供一种发布和接收HTML页面的方法，由URI来标识具体的资源。

后面用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛。

HTML（Hyper Text Markup Language），超文本标记语言。用于编写网页。

1.3.1 HTTP版本

• 1991年，HTTP/0.9

只支持GET请求方法获取文本数据（比如HTML文档），且不支持请求头、响应头等，无法向服务器传递太多信息。

• 1996年，HTTP/1.0

支持POST、HEAD等请求方法，支持请求头、响应头等，支持更多种数据类型。浏览器每次请求都需要与服务器建立一个TCP连接，请求处理完成后立即断开TCP连接。

• 1997年，HTTP/1.1

支持PUT、DELETE等请求方法，采用持久连接，多个请求可以共用一个TCP连接。

• 2015年，HTTP/2.0。
• 2018年，HTTP/3.0。

1.3.2 HTTP报文格式

• 请求报文

方法【空格】URL【空格】版本【回车换行】 //请求行

首部字段:【空格】值【回车换行】 //首部行

… …

首部字段:【空格】值【回车换行】

【回车换行】

实体主体

• 响应报文

版本【空格】状态码【空格】短语【回车换行】 //状态行

首部字段:【空格】值【回车换行】 //首部行

… …

首部字段:【空格】值【回车换行】

【回车换行】

实体主体

ABNF（Augmented BNF）

• 是BNF（Backus-Naur Form，译为巴科斯-瑙尔范式）的修改、增强版；
• 在RFC 5234文档中表明：ABNF左右Internet中通信协议的定义语言；
• ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是片面的、不严谨的。

HTTP-message = start-line
			   *(header-field CRLF)
			   CRLF
			   [message-body]
			   
------------------------------------------
header-field = field-name":" OWS field-value OWS
field-name = token
field-value = *(field-content/obs-fold)
------------------------------------------
message-body = *OCTET  (OCTET指一个字节)
########################################
/	任选一个；
*	0个或多个，2*表示至少2个；
()	组成一个整体；
[]	可有可无的选项。
OWS = *(SP/HTAB)

start-line：开始行，start-line = request-line/status-line；

start-line是内置的CRLF。

请求行：

# SP = 空格    DIGIT = 数字
# %x48.54.54.50 = HTTP
request-line = method SP request-target SP HTTP-version CRLF
HTTP-version = HTTP-name"/"DIGIT"."DIGIT
HTTP-name = %x48.54.54.50

状态行：

# HTAB = Tab   VCHAR = 字符串
status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase = *(HTAB/SP/VCHAR/obs-text)

1.3.3 请求方法

8种请求方法：GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE;

额外的1种：PATCH

• GET：常用于读取操作，请求参数直接拼接再URL后面（浏览器对URL长度是有限制的）。
• POST：常用于添加、修改、删除的操作，请求阐述剋放到请求体中（没有长度限制）。
• HEAD：请求得到与GET相同的响应，但是没有响应体。（使用场景，在下载文件前先获取其大小，再决定是否要下载）。
• OPTIONS：用于获取目的资源所支持的通信选项，比如服务器支持的请求方法
• PUT：用于已存在的资源进行整体覆盖（不安全，已经不怎么用了）。
• PATCH：用于对资源进行部分修改（资源不存在，会创建新的资源）。
• DELETE：用于删除指定的资源。
• TRACE：请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断。
• CONNECT：可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道（tunnel）可以用来访问采用了SSL（HTTPS）协议的站点。

1.3.4 头部字段

头部字段可以分为4种类型：

• 请求头字段（Request Header Fields）：有关要获取资源或客户端本身的消息头。
• 响应头字段（Response Header Fields）：有关响应的补充信息，比如服务器本身（名称和版本等）的消息头。
• 实体头字段（Entity Header Fields）：有关实体主题的更多信息，比如主题长度（Content-Length）或其MIME类型。
• 通用头字段（General Header Fields）：同时适用于请求和响应消息，但与消息主体无关的消息头。

• 请求头字段（Request Header Fields）

• 响应头字段（Response Header Fields）

1.3.5 状态码

状态码指示HTTP请求是否已经成功完成，状态码可以分为5类：

• 信息响应：100-199
• 成功响应：200-299
• 重定向：300-399
• 客户端错误：400-499
• 服务器错误：500-599

常见状态码：

• 100：continue （请求的初始部分已经被服务器收到，并且没有被服务器拒绝。客户端应该继续发送剩余的请求，如果请求已经完成，就忽略这个响应）。

• 200：OK （请求成功）。

• 302：Found （重定向，请求的资源暂时被移动到了由Location头部指定的URL上）。
• 304：Not Modified （说明无需再次传输请求的内容，也就是说可以使用缓存的内容）。

• 400：Bad Request （由于语法无效（由开发人员设置主动发400），服务器无法理解该请求）。
• 401：Unauthorized （由于缺乏目标资源要求的身份验证凭证）。
• 403：Forbidden （服务器端由能力处理该请求，但是拒绝授权访问）。
• 404：Not Found （服务器端无法找到所请求的资源）。
• 405：Method Not Allowed （服务器禁止了使用当前HTTP方法的请求）。
• 406：Not Acceptable （服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应）。
• 408：Req Timeout （服务器想要将没有在使用的连接关闭）。

• 500：Internal Server Error （所请求的服务器遇到意外的情况并阻止其执行请求）。
• 501：Not Implemented （请求的方法不被服务器支持，因此无法被处理，服务器必须支持的方法GET和HEAD不会返回这个状态码）。
• 502：Bad Gateway （作为网关或代理角色的服务器，从上游服务器中收到的响应是无效的）。
• 503：Service Unavailable （服务器尚未处于可以接收请求的状态，通常造成这种情况的原因市由于服务器停机维护或者已超载）。

1.3.6 表单提交 Form

常用属性

• action：请求的URI。

• method：请求的方法（GET、POST）。

• enctype：POST请求时，请求体的编码方式（默认值：application/x-www-urlencoded：用&分隔参数，用=分隔键和值，字符用URL编码方式进行编码）。

  （multipart/form-data：适用于复杂的内容提交，请求头会多一个boundary，请求体会被boundary包围，然后分块，文件上传必须使用这种方式。）

1.4 跨域 CORS

前后端分离：从形式上来说，就是前端和后端的内容分离出来，作为两个项目分别开发。跨域受同源策略影响，规定默认情况下，AJAX请求只能发送给同源的URL（同源是指三个相同：协议、域名（IP），端口）。

跨域资源共享

• 解决AJAX跨域请求的常用方法

CORS （Cross-Origin Resoure Sharing），跨域资源共享。

• CORS的实现需要客户端和服务端同时支持

• 客户端

  所有的浏览器都支持（IE至少IE10版本）。

• 服务端

  需要返回响应的响应头（比如Access-Control-Allow-Origin）。

  告知浏览器这是一个允许跨域访问的请求。

1.5 Cookie 和 Session

• Cookie：在客户端（浏览器）存储一些数据，服务器可以返回Cookie交给客户端去存储，存储到本地磁盘中。
• Session：在服务器存储一些数据，一般存在内存中。

Cookie身份验证过程：

• 登录成功后，服务器，创建一个Session，存储一个id和用户信息，并通过响应头Set-Cookie：JSEESIONID=xxx发送给客户端；

• 客户端收到响应头的内容后会将Cookie：JSEESIONID=xxx的信息存储起来，Cookie中一般会带有两个字段（domain和path，一般由服务器设置），作用是将来请求那些路径时会携带cookie。

• 客户端下次直接请求内容页面时，发现Cookie中的domain和path与请求的相同，就会在请求头中携带cookie。

• 服务器收到请求头后检查cookie，发现携带有会话id，然后去Session匹配，匹配成功后，即通过身份验证。

这种技术常常用于会话跟踪。

1.6 代理 （Proxy）和 CDN

代理服务器（Proxy Server）

• 本身不产生内容；
• 处于中间位置转发上下游的请求和响应；
• 面向下游的客户端：它是服务器；
• 面向上有的服务器；它是客户端。

1.6.1 正向代理和反向代理

• 正向代理：代理的对象是客户端；
• 反向代理：代理的对象是服务器。

正向代理：

• 隐藏客户端身份；
• 绕过防火墙（突破访问限制）；
• Internet访问控制；
• 数据过滤。

反向代理：

• 隐藏服务器身份；
• 安全防护；
• 负载均衡。

1.6.2 代理服务器相关头部字段

略。

1.6.3 CDN 内容分发网络

CDN（Content Delivery Network 或 Content Distributed Network），译为：内容分发网络。

CDN：利用最靠近每位用户的服务器，更快更可靠地将音乐、图片、视频等资源文件（一般是静态资源）传递给用户。

1.7 网络通信中面临地4中安全威胁

被动攻击：

截获：被窃听通信内容。

主动攻击：

中断：中断网络通信。

篡改：篡改通信内容。

伪造：伪造通信内容。

1.7.1 网络层-ARP欺骗

ARP欺骗（ARP spoofing），又称ARP毒化（ARP poisoning）、ARP病毒、ARP攻击。

• ARP欺骗可以造成地效果：
  • 可以让攻击者获取局域网上地数据包甚至可篡改数据包；
  • 可让网络上特定电脑之间无法正常通信（例如网络执法官这样地软件）；
  • 让送至特定IP地址地流量被错误送到攻击者所取代地地方

ARP欺骗的核心步骤：

• 假设主机C是攻击者，主机A、B是被攻击者；
• C只要收到过A、B发送的ARP请求，就会拥有A、B的IP、MAC地址，就可以进行欺骗活动；
• C发送一个ARP响应给B，把相应包里的源IP设置为A的IP地址，源MAC设为C的MAC地址；
• B收到ARP响应后，更新它的ARP表，把A的MAC地址（IP_A,MAC_A）改为（IP_A,MAC_C）；
• 当B要发送数据包给A时，根据此包的目标MAC地址MAC_C，就会把数据包发送给C；
• C收到数据包后，可以把它存起来后在发送给A，达到窃听效果。C也可以篡改数据后在发送给A。

ARP欺骗的防护：

• 静态ARP；
• DHCP Snooping：
  • 网络设备可由DHCP保留网络上各个电脑的MAC地址，在伪造的ARP数据包发出时即可侦测到。
• 利用一些软件监听ARP的不正常变动

1.7.2 DoS、DDoS

• DoS攻击（拒绝服务攻击，Denial-of-Service attack）

使目标电脑的网络或系统资源耗尽，使服务中断或停止，导致器正常用户无法访问。

• DDoS攻击（分布式拒绝服务攻击，Distributed Denial-of-Service attack）

黑客使用网络上两个或以上被贡献的电脑作为“僵尸”向特定的目标发动DoS攻击。

DoS分类：

• 带宽消耗型：UDP洪水攻击、ICMP洪水攻击。
• 资源消耗型：SYN洪水攻击、LAND（局域网拒绝服务攻击）攻击。
  • LAND攻击：通过持续发送相同源地址和目标地址的欺骗数据包，使目标试图与自己建立连接，消耗系统资源直至崩溃。

1.7.3 DNS劫持

• DNS劫持：又称域名劫持

• 攻击者篡改了某个域名的解析结果，是的指向改域名的IP变成了另一个IP。
• 导致相对应万只的访问被劫持到另一个不可达的或者假冒的网址。
• 从而实现非法窃取用户信息或者破坏正常网络服务的目的。

• HTTP劫持：对HTTP数据包进行拦截处理，比如插入JS代码。

1.8 HTTP协议的安全问题

• HTTP协议默认是采用明文传输的，因此会有很大的安全隐患。
• 常见加密方式：

不可逆：单向散列函数：（MD5、SHA等）。

可逆：对称加密（DES、3DES、AES等）、非对称加密（RSA等）。

其他：混合密码系统、数字签名、证书。

• 网络上的密码通信所用的SSL/TLS都运用了混合密码系统。

1.8.1 混合密码

混合密码的加密过程：

• 会话密钥：为本次通信随机生成的临时密钥，作为对称加密的密钥，用于加密消息，提高速度。

• 加密步骤：

（1）伪随机数生成器，生成会话密钥；

（2）用会话密钥对称加密明文；

（3）用接收者的公钥加密会话密钥；

（4）将密文和加密的密钥组合发送给接收者；

混合密码的解密过程：

• 加密过程的逆过程，先用私钥解出会话密钥，在对密文进行解密。

1.8.2 数字签名

为了确定消息的真实性，识别篡改、伪装、否认。

要求：内容无所谓被窃听，但是要求来源可信。

数字签名的行为：

• 生成签名：由消息的发送者完成，通过**“签名密钥”**生成；
• 验证签名：由消息的接收者完成，通过**“验证密钥”**验证。

消息构成：消息+签名；

• 签名用消息发送者的私钥进行 签名 (保证不会被伪造)；
• 接收者用发送者的公钥解密签名与消息内容比对即可。
• 由于消息可能很大，所以一般使用消息的单向散列值进行签名，验签时同样与消息的单向散列值比对。

1.8.3 证书

公钥的合法性：如果遭遇了中间人攻击，那么公钥将可能时伪造的。

如何验证公钥的合法性？——证书。

密码学中的证书，全称叫公钥证书（Pub-key Certificate，PKC）

• 证书里有姓名、邮箱等个人信息，以及此人的公钥，还有CA的数字签名；
• 由认证机构（Certificate Authority，CA）施加数字签名；
• CA就是能够认定**“公钥确实属于此人”**并能够生成数字签名的个人或组织。

1.9 HTTPS

HTTPS（HyperText Transfer Protocol Secure），译为，超文本传输安全协议。

常称为 HTTP over TLS、 HTTP over SSL、 HTTP Secure。

HTTPS默认端口是443（HTTP是80）。

1.9.1 SSL/TLS

• HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供合理的防护。
• SSL/TLS也可以使用在其他协议上，如：FTP----FTPS、SMTP----SMTPS。

• TSL（Transport Layer Security），译为：传输层安全性协议；
• 前身是SSL（Secure Sockets Layer），译为：安全套接层。

SSL/TLS——工作在那一层？

SSL/TLS工作在应用层和传输层之间，SSL/TLS本身又分为HandShake Layer和Record Layer：

• HandShake Layer：包含HandShake、Change CipherSpec、Alert靠近应用层；
• Record Layer：包含一个Record靠近传输层。

OpenSSL：是SSL/TLS协议的开源实现。

HTTPS的通信过程：

• TCP的三次握手；
• TLS的连接；
• HTTP请求和响应。

1.9.2 TLS 1.2的连接

连接过程：（其中省略了大量的ACK确认）

（0）Client Client Hello >> Server；

（1）Client << Server Hello Server；

（2）Client << Certificate Server；

（3）Client << Server Key Exchange Server；

（4）Client << Server Hello Done Server；

（5）Client Client Key Exchange >> Server；

（6）Client Change Cipher Spec >> Server；

（7）Client Finished >> Server；

（8）Client << Change Cipher Spec Server；

（9）Client << Finished Server；

（0）Client Client Hello >> Server：

TLS版本号；

支持的加密组件(Cipher Suite)列表（加密组件是指所使用的加密算法及密钥长度等）；

一个随机数（Client Random）。

（1）Client << Server Hello Server：

TLS版本号；

选择的加密套件（从列表里选一个）；

一个随机数（Server Random）；

（2）Client << Certificate Server：

服务器的公钥证书（被CA签名过的）

（3）Client << Server Key Exchange Server：

用以实现ECDHE算法的其中一个参数（Server Params），ECDHE是一种密钥交换算法；

为了防止伪造Server Params是被签名过的。

（4）Client << Server Hello Done Server： （以上全部为明文发送）

告知客户端：协商部分结束。

（5）Client Client Key Exchange >> Server：

用以实现ECDHE算法的另一个参数（Client Params）。

客户端和服务端根据Server Params和Client Params利用ECDHE算法计算出一个新的随机密钥串：Pre-master secret。

然后结合Client Random和Server Random以及Pre-master secret生成用以加密会话的会话密钥。

（6）Client Change Cipher Spec >> Server：

告知服务器：之后的通信会采用计算出来的会话密钥进行加密。

（7）Client Finished >> Server：

包含连接至今的全部报文的整体校验值（摘要），加密之后发送给服务器。

这次握手协商是否能成功，要以服务器是否能够正确解密该报文作为判断标准。

（8）Client << Change Cipher Spec Server：

（9）Client << Finished Server：

到此为止，客户端和服务器都验证加密解密没问题，握手正式结束；

后面开始传输加密的HTTP请求和响应。（与前边的对称）。

1.9.3 HTTP改进

HTTP协议的不足（HTTP/1.1）

• 同一个时间，一个连接自能对应一个请求；
• 针对同一个域名，大多数浏览器只允许同时最多6个并发连接；
• 只允许客户端主动发起请求；
• 一个请求只能对应一个响应；
• 同一个会话的多次请求中，头信息会被重复传输。

SPDY

SPDY（speedy的缩写），是基于TCP的应用层协议，它强制要求使用SSL/TLS；

SPDY与HTTP的关系：

SPDY并不是用于取代HTTP，它只是修改了HTTP请求与响应的传输方式；

			            HTTP         SPDY
			       +------------+------------+
			       |            |    HTTP    |
			       |            +------------+
			       |    HTTP    |    SPDY    |
			       |            +------------|
Application Layer  |            |     TLS    |
-------------------+------------+------------+
Transport Layer    |     TCP    |     TCP    |
-------------------+------------+------------+
Internet Layer     |     IP     |     IP     |
			       +------------+------------+

只需要增加一个SPDY层，现有的所有服务均不用修改。

SPDY是HTTP/2的前身，现在已经停止对SPDY的支持了，采用HTTP/2.

HTTP/2

• HTTP/2在底层传输做了很多改进和优化，但是在语义上完全与HTTP/1.1兼容；
• 比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变；
• 因此升级到HTTP/2，只需要升级服务器和浏览器的配置即可，无需修改代码。
• HTTP/2不强制要求使用SSL/TLS。

HTTP/2的特性——二进制格式

• HTTP/2采用二进制格式传输数据，而非HTTP/1.1的文本格式；

• 头部信息转成头部帧，数据部分转换成数据帧。

HTTP/2的特性——基本概念

• 数据流：已经建立的连接内的双向字节流可以承载一条或多条消息：
  • 所有通信都在一个TCP连接上完成，此连接可以承载任意数量的双向数据流。
• 消息：与逻辑HTTP请求或响应消息对应，有一系列帧组成。
• 帧：HTTP/2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）：
  • 来自不同数据流的帧可以交错发送，然后再根据每个枕头的数据流标识符重新组装。

HTTP/2的特性——多路复用（Multiplexing）

• 客户端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来；
• 并行交错地发送多个请求，请求之间互不影响；
• 并行交错地发送多个响应，响应之间互不影响；
• 使用同一个连接并行发送多个请求和响应；
• 不必再为绕过HTTP/1.1限制而做很多工作：
• 比如image sprites合并CSS/JS、内嵌CSS/JS/Base64图片、域名分片等。

HTTP/2的特性——优先级

• HTTP/2标准允许每一个数据流都有一个关联地权重和依赖搞关系：
  • 可以向每一个数据流分配一个介于1-256之间地整数；
  • 每个数据流与其他数据流之间可以存在显示依赖关系。
• 客户端可以构建和传输”优先级树“，表明它倾向于如何接收响应。
• 服务器可以使用此信息给控制CPU、内存和其他资源地分配设定数据流处理地优先级。
  • 在资源数据可用之后，确保将高优先级响应以最有方式传输至客户端；
• 尽可能先给父数据流分配资源；
• 同级数据流（共享相同父项）应按其权重比例分配资源配置。

HTTP/2的特性——头部压缩

• HTTP/2使用HPACK压缩请求头和响应头，可以极大减少头部开销，进而提高性能；

HTTP/2的特性——服务推送（Server Push）

• 服务器可以对一个客户端请求发送多个响应：
  • 除了最初的响应外，服务器还可与i向客户端推送额外资源。

HTTP/2的问题——队头阻塞（head of line blocking）

• 由于TCP有序接收的问题，一旦中间出现数据包丢包会导致整个数据流阻塞，直到丢包的数据重传成功。这个问题是TCP导致的。

解决方案：QUIC协议（底层UDP）。

HTTP/2的问题——握手延迟

• 这个问题还是TCP导致的，由于TCP建立连接需要1.5个RTT。

HTTP/3

• HTTP/3 弃用了TCP协议，改为使用基于UDP协议的QUIC协议实现；
• QUIC（Quic UDP Internet Connections），译为快速UDP网络连接；
• HTTP over QUIC 改名为 HTTP/3。

    HTTP/1        HTTPS         HTTP/2           HTTP/3
+------------+------------+----------------+----------------+
|            |            |      HTTP      |      HTTP      |
|            |    HTTP    +----------------+----------------+
|    HTTP    |            | HPack + Stream | QPack + Stream |
|            +------------+----------------+----------------+
|            |  SSL/TLS   |    TLS 1.2+    | QUIC + TLS1.3+ |
+------------+------------+----------------+----------------+
|     TCP    |     TCP    |       TCP      |       UDP      |
+------------+------------+----------------+----------------+
|     IP     |     IP     |       IP       |       IP       |
+------------+------------+----------------+----------------+

Q:HTTP/3如何保证可靠传输？

A:由QUIC来保证。

HTTP/3的特性——连接迁移

• TCP基于4要素（源IP、源端口、目标IP、目标端口）
  • 切换网络时至少会有一个要素发生变化，导致连接发生变化；
  • 当连接发生变化时，如果还是用原来的TCP连接，则会导致连接失败；
  • 所以千幻网络时会出现超时重传，等待新连接建立。
• QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持：
  • QUUIC连接使用一组Connection ID来标识一个连接。

HTTP/3的特性——操作系统内核、CPU负载

与基于TLS的HTTP/2相比，HTTP/3大规模部署的QUIC需要仅2倍的CPU使用量：

Linux内核的UDP部分没有得到像TCP那样的优化；

TCP和TLS有硬件加速，而这对UDP很罕见，对于QUIC则根本不存在。