计算机网络3

二十一、HTTPS、SSL、TLS

1、什么是安全

HTTP 是明文，不安全的，需要做安全性优化；

通信安全必须同时具备机密性、完整性，身份认证和不可否认这四个特性；

机密性：对数据的“保密”，只能由可信的人访问

完整性：数据在传输过程中没有被窜改，完整地保持着原状

身份认证：确认对方的真实身份

不可否认：不能否认已经发生过的行为

2、HTTPS

HTTPS 的语法、语义仍然是 HTTP，但把下层的协议由 TCP/IP 换成了 SSL/TLS（在HTTP层和TCP/IP层之间加了一层SSL/TLS）收发报文不再使用 Socket API，而是调用专门的安全接口

HTTPS 与 HTTP 最大的区别，它能够鉴别危险的网站，并且尽最大可能保证你的上网安全，防御黑客对信息的窃听、窜改或者“钓鱼”、伪造.

3、SSL/TLS

SSL 即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层）。是一个非常好的安全通信协议。TLS1.0 实际上就是 SSLv3.1

现在在用的是TLS1.2

TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）

TLS 的密码套件命名格式：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法

protools：TSLv1.2      表示使用的 TLS 是 1.2

server suite：ECDHE-RSA-AES256-GCM-SHA384    

握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用
AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和
产生随机数。

4、OpenSSL

OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，是 SSL/TLS 的具体实现。

课后问题：

1. 你能说出 HTTPS 与 HTTP 有哪些区别吗？
明文、不安全vs四个特性，端口80vs端口443，无加密解密流畅性vs一定的性能消耗

2. 你知道有哪些方法能够实现机密性、完整性等安全特性呢？

对称加密算法保证机密性，散列值算法保证完成性和安全

二十二、对称加密和非对称加密

实现机密性最常用的手段是“加密”（encrypt），就是把消息用某种方式转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再转换出原始文本。

这里的“钥匙”就叫做“密钥”（key），加密前的消息叫“明文”（plain text/cleartext），加密后的乱码叫“密文”（cipher text），使用密钥还原明文的过程叫“解密”（decrypt），是加密的反操作，加密解密的操作过程就是“加密算法”。

算法使用的“密钥”则必须保密。

密钥”就是一长串的数字，但约定俗成的度量单位是“位”（bit），而不是“字节”（byte）。比如，说密钥长度是 128，就是 16字节的二进制串，密钥长度 1024，就是 128 字节的二进制串。
按照密钥的使用方式，加密可以分为两大类：对称加密和非对称加密。

1、对称加密

对称加密：指加密和解密时使用的密钥都是同一个，是“对称”的。

TLS 里有非常多的对称加密算法可供选择，比如 RC4、DES、3DES、AES、ChaCha20等，但前三种算法都被认为是不安全的，通常都禁止使用，目前常用的只有 AES 和ChaCha20

AES ：“高级加密标准”，密钥长度可以是128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。
ChaCha20 ：密钥长度固定为 256 位

2、对称加密的加密分组模式

分组模式：可以让算法用固定长度的密钥加密任意长度的明文

最早有 ECB、CBC、CFB、OFB 等几种分组模式，但都陆续被发现有安全漏洞，所以现在基本都不怎么用了。最新的分组模式被称为 AEAD（Authenticated Encryption withAssociated Data），在加密的同时增加了认证的功能，常用的是 GCM、CCM 和Poly1305

上面这些组合起来，就可以得到 TLS 密码套件中定义的对称加密算法

AES128-GCM：密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM；
ChaCha20-Poly1305 ：ChaCha20 算法，使用的分组模式是 Poly1305

3、非对称加密

非对称加密（也叫公钥加密算法）：它有两个密钥，“公钥”和“私钥”。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密

公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密

非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

非对称加密算法在 TLS 里只有很少的几种，比如 DH、DSA、RSA、ECC 等。
RSA ：安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。推荐长度是2048 位
ECC：基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。常用的两个曲线是 P-256（secp256r1，在 OpenSSL 称为 prime256v1）和x25519。P-256 是 NIST（美国国家标准技术研究所）和 NSA（美国国家安全局）推荐使用的曲线，而 x25519 被认为是最安全、最快速的曲线

ECC比 RSA 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的RSA，而 224 位的 ECC 则相当于 2048 位的 RSA

非对称加密：

第一种用法：公钥加密，私钥解密。---用于加解密
第二种用法：私钥签名，公钥验签。---用于签名

签名：使用私钥加密,公钥解密,用于让所有公钥所有者验证私钥所有者的身份并且用来防止私钥所有者发布的内容被篡改.但是不用来保证内容不被他人获得。
加密：用公钥加密,私钥解密,用于向公钥所有者发布信息,这个信息可能被他人篡改,但是无法被他人获得。

4、混合加密

非对称加密没有“密钥交换”的问题，但因为它们都是基于复杂的数学难题，运算速度很慢

混合加密：用随机数产生对称算法使用的“会话密钥”，再用非对称算法的公钥加密，私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。

二十三、数字签名与证书

机密性：混合机密

完整性：

身份认证：

不可否认：

1、摘要算法

实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）

摘要算法：近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文

可能会有两份不同的原文对应相同的摘要；摘要算法对输入具有“单向性”和“雪崩效应”，输入的微小不同会导致输出的剧烈变化，所以也被 TLS 用来生成伪随机数（PRF，pseudo random function）
MD5（Message-Digest 5）、SHA-1（SecureHash Algorithm 1），最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。安全强度比较低，在 TLS 里已经被禁止使用

推荐使用的是 SHA-2：SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要

2、完整性

摘要算法保证了“数字摘要”和原文是完全等价。在原文后附上它的摘要，就能够保证数据的完整性

过程：网站收到消息计算一下摘要与附带的摘要进行对比，确保消息的完整性

摘要算法不具有机密性，所以在混合加密系统里用会话密钥加密消息和摘要

3、数字签名

加密算法结合摘要算法，我们的通信过程可以说是比较安全了。但这里还有漏洞，就是通信的两个端点（endpoint）

非对称加密里的“私钥”，使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”。

私钥只加密原文的摘要

签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解
开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的

只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥
保密，黑客不能伪造签名，就能够保证通信双方的身份

4、数字证书与CA

CA（Certificate Authority，证书认证机构）：来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。

“数字证书”：序列号、用途、颁发者、有效时间等等，打成一个包再签名，完整地证明公钥关联的各种信息

公钥的分发需要使用数字证书，必须由 CA 的信任链来验证，否则就是不可信的；
作为信任链的源头 CA 有时也会不可信，解决办法有 CRL、OCSP，还有终止信任。

二十四、TLS1.2连接过程解析

二十五、TLS1.3特性解析

二十六、HTTPS的优化

二十七、应该迁移到HTTPS吗？

1、迁移的顾虑

慢：惯性思维，拿以前的数据来评估 HTTPS 的性能，认为 HTTPS 会增加服务器的成本，增加客户端的时延，影响用户体验

贵：主要是指证书申请和维护的成本太高，网站难以承担

难：指 HTTPS 涉及的知识点太多、太复杂，有一定的技术门槛，不能很快上手

2、迁移的步骤

a、申请证书：升级 HTTPS 首先要申请数字证书，可以选择免费好用的“Let’s Encrypt

b、配置HTTPS：需要注意选择恰当的 TLS 版本和密码套件，强化安全

c、配置 HTTPS 服务时还有一个“虚拟主机”的问题需要解决：

虚拟主机：HTTP 协议里，多个域名可以同时在一个 IP 地址上运行

HTTPS 里，因为请求头只有在 TLS 握手之后才能发送，在握手时就必须选择“虚拟主机”对应的证书，TLS 无法得知域名的信息，就只能用 IP 地址来区分；给协议加个SNI（Server Name Indication）的“补充条款”。它的作用和 Host 字段差不多，客户端会在“Client Hello”时带上域名信息，这样服务器就可以根据名字而不是 IP 地址来选择证书

d、重定向跳转：原有的 HTTP 站点可以保留作为过渡，使用 301 重定向到 HTTPS

总结：

HTTPS传输过程：

1. 客户端先从服务器获取到证书，证书中包含公钥
2. 客户端将证书进行校验
3. 客户端生成一个对称密钥，用证书中的公钥进行加密，发送给服务器
4. 服务器得到这个请求后用私钥进行解密，得到该密钥
5. 客户端以后发出后续的请求，都使用这个对称密钥进行加密。
6. 服务器收到这个密文也用这个密钥进行解密。

二十八、HTTP/2特性概览

1、HTTP缺点及HTTP/2的改进

HTTP 有两个主要的缺点：安全不足和性能不高

HTTP/2 的唯一目标就是改进性能

HTTP/2的改进：HTTP/2 把 HTTP 分解成了“语义”和“语法”两个部分，

语义层不做改动，与 HTTP/1 完全一致；比如请求方法、URI、状态码、头字段等概念都保留不变

语法层：a、使用“HPACK”算法压缩头部信息，消除冗余数据节约带宽；（HPACK算法：在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还釆用哈夫曼编码来压缩整数和字符串，可以达到 50%~90% 的高压缩率）

b、HTTP/2 的消息不再是“Header+Body”的形式，而是分散为多个二进制“帧”（把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据）

c、使用虚拟的“流”传输消息，解决了困扰多年的“队头阻塞”问题，同时实现了“多路复用”，提高连接的利用率（流（Stream）是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的流 ID。你可以想象把它成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是 HTTP/1 里的请求报文和响应报文。流”同时发送多个“碎片化”的消息，这就是常说的“多路复用”（ Multiplexing）——多个往返通信都复用一个连接来处理）

2、对比一下HTTP/2和HTTP/1、HTTPS的相同点不同点。

 http1.1解决的是在万维网中，计算机之间的信息通信的一套规范，包括定义其属于应用层协议，建立在tcp/ip之上，请求响应的报文结构等。

https不改变http1.1的原有属性，是在其之上新增了对数据安全性和有效性的特性，解决的是数据安全的问题，通过使用加密解密，数字证书，TLS握手等过程保证了这一点。

http2解决的是性能问题，通过头部压缩，使用二进制传输，多路复用，服务器推送等策略使得http的性能更好。http2和https本质上都是对http1.1的扩展和延伸。

课后作业：

1. 你觉得明文形式的 HTTP/2（h2c）有什么好处，应该如何使用呢？

明文传输时不需要进行加密解密动作，不需要TLS握手，能节约性能。适用于对数据传输安全性要求不高的场景。
2. 你觉得应该怎样理解 HTTP/2 里的“流”，为什么它是“虚拟”的？

http2改变了http1.1的“请求-应答”模式，将head+body的请求报文在传输过程中改为 head帧 + data帧，在同一个TCP/IP中，可以将多个请求分解为多个帧，从连接层面来看，这些帧是无序的，为了让接受端准确的将这些帧还原为一个一个独立的请求或响应，就给了每一个帧分配了streamid，streamid相同的即为同一个请求或响应的数据。因此，此处的流并不是真实有序的二进制字节，所以叫‘虚拟流’。

1. HTTP 协议取消了小版本号，所以 HTTP/2 的正式名字不是 2.0；
2. HTTP/2 在“语义”上兼容 HTTP/1，保留了请求方法、URI 等传统概念；
3. HTTP/2 使用“HPACK”算法压缩头部信息，消除冗余数据节约带宽；
4. HTTP/2 的消息不再是“Header+Body”的形式，而是分散为多个二进制“帧”；
5. HTTP/2 使用虚拟的“流”传输消息，解决了困扰多年的“队头阻塞”问题，同时实现了“多路复用”，提高连接的利用率；
6. HTTP/2 也增强了安全性，要求至少是 TLS1.2，而且禁用了很多不安全的密码套件

二十九、HTTP/2内核剖析

1、连接前言（TLS握手成功之后）

HTTP/2“事实上”是基于 TLS，在正式收发数据之前，会有 TCP 握手和 TLS 握手。

连接前言”是标准的 HTTP/1 请求报文，使用纯文本的 ASCII 码格式，请求方法是特别注册的一个关键字“PRI”，全文只有 24 个字节

HTTP/2 的“连接前言”被称为“Magic”，服务器通过magic就知道客户端在 TLS 上想要的是HTTP/2 协议

2、头部压缩

建立连接之后，HTTP/2 开始准备请求报文

报文还是由“Header+Body”构成的，，在请求发送之前用“HPACK”算法来压缩头部数据。

HPACK算法：专门为压缩 HTTP 头部定制的算法，与 gzip、zlib 等压缩算法不同，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”（静态表和动态表），也可以说是“字典”（这有点类似 brotli），压缩和解压缩就是查表和更新表的操作

HTTP/2废除了原有的起始行里的版本号和错误说明，把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式，叫做伪头字段，名字前加：区分

HTTP/2 报文头全都是“Key-Value”形式的字段

定义静态表和动态表：查表就可以知道字段名和对应的值

动态表（Dynamic Table），它添加在静态表后面，结构相同，但会在编码解码的时候随时更新

过程：第一次发送请求时的“user-agent”字段长是一百多个字节，用哈夫曼压缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号“65”。那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号就好

3、二进制帧

头部数据压缩之后，HTTP/2 就要把报文拆成二进制的帧准备发送

帧长度：三个字节，表示数据长度

帧类型：数据帧和控制帧；HEADERS 帧和 DATA帧属于数据帧，存放的是 HTTP 报文，而 SETTINGS、PING、PRIORITY（设置了流的优先级） 等则是用来管理流的控制帧

标志位：可以保存 8 个标志位，携带简单的控制信息。END_HEADERS表示头数据结束，相当于 HTTP/1 里头后的空行（“\r\n”），END_STREAM表示单方向数据发送结束（即 EOS，End of Stream），相当于 HTTP/1 里 Chunked 分块结束标志（“0\r\n\r\n”）

流标识符：接收方使用它就可以从乱序的帧里识别出具有相同流 ID 的帧序列，按顺序组装起来就实现了虚拟的“流”

4、流与多路复用

流是二进制帧的双向传输序列

帧是乱序收发的，但只要它们都拥有相同的流 ID，就都属于一个流，而且在这个流里帧不是无序的，而是有着严格的先后顺序。

一个 HTTP/2 的流就等同于一个 HTTP/1 里的“请求 - 应答”

HTTP/2流的特点：

1. 流是可并发的，也就是并发多请求，实现“多路复用”；
2. 客户端和服务器都可以创建流，双方互不干扰；
3. 流是双向的，一个流里面客户端和服务器都可以发送或接收数据帧，也就是一个“请求- 应答”来回；
4. 流之间没有固定关系，彼此独立，但流内部的帧是有严格顺序的；
5. 流可以设置优先级，让服务器优先处理，比如先传 HTML/CSS，后传图片，优化用户体验；
6. 流 ID 不能重用，只能顺序递增，客户端发起的 ID 是奇数，服务器端发起的 ID 是偶数；
7. 在流上发送“RST_STREAM”帧可以随时终止流，取消接收或发送；
8. 第 0 号流比较特殊，不能关闭，也不能发送数据帧，只能发送控制帧，用于流量控制
 

HTTP/2 在一个连接上使用多个流收发数据，那么它本身默认就会是长连接，所以永远不需要“Connection”头字段（keepalive 或 close）

下载大文件的时候想取消接收，在 HTTP/1 里只能断开 TCP 连接重新“三次握手”，成本很高，而在 HTTP/2 里就可以简单地发送一个“RST_STREAM”中断流，而长连接会继续保持

ID 用完了，再发一个控制帧“GOAWAY”，真正关闭 TCP 连接

5、流状态转换

根据帧的标志位实现流状态转换

流关闭就是一次通信结束

过程：
流（空闲状态）—客户端发送数据帧—有了流ID—流（打开状态）—客户端发送“END_STREAM”标志位的帧（客户端的请求数据已经发送完）—流（半关闭状态）—服务器端发送响应数据带“END_STREAM”标志位（表示数据发送完毕）—流（关闭状态）

下一次再发请求就要开一个新流（而不是新连接），流 ID 不断增加，直到到达上限，发送“GOAWAY”帧开一个新的 TCP 连接，流 ID 就又可以重头计数。

课后问题：

1. HTTP/2 的动态表维护、流状态转换很复杂，你认为 HTTP/2 还是“无状态”的吗？

1.还是无状态,流状态只是表示流是否建立，单次请求响应的状态。并非会话级的状态保持

2. HTTP/2 的帧最大可以达到 16M，你觉得大帧好还是小帧好？

小帧好，少量多次，万一拥堵重复的的少。假设大帧好，只要分流不用分帧了。

3. 结合这两讲，谈谈 HTTP/2 是如何解决“队头阻塞”问题的

http/1里的请求都是排队处理的，所以有队头阻塞。
http/2的请求是乱序的，彼此不依赖，所以没有队头阻塞

三十、HTTP/3展望

1、HTTP/2 的“队头阻塞”

HTTP/2 虽然使用“帧”“流”“多路复用”，没有了“队头阻塞”，都是在应用层里，而在下层，也就是 TCP 协议里，还是会发生“队头阻塞”

HTTP/2 把多个“请求 - 响应”分解成流，交给TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是“段”）。但是TCP传输会受网络质量的影响，为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来

队头阻塞是 TCP 协议固有的。

2、QUIC 协议

HTTP/3：HTTP over QUIC，真正“完美”地解决了“队头阻塞”问题

HTTP/3 把下层的 TCP换成了 UDP。因为 UDP 是无序的，包之间没有依赖关系，所以就从根本上解决了“队头阻塞”

UDP 是一个简单、不可靠的传输协议，只是对 IP 协议的一层很薄的包装；不需要建连和断连，通信成本低，也就非常灵活、高效，“可塑性”很强

QUIC 就选定了 UDP，在它之上把 TCP 的那一套连接管理、拥塞窗口、流量控制等“搬”了过来，“去其糟粕，取其精华”，打造出了一个全新的可靠传输协议，可以认为是“新时代的 TCP

gQUIC： 混合了 UDP、TLS、HTTP，是一个应用层的协议

iQUIC：对 gQUIC 做了“清理”，把应用部分分离出来，形成了 HTTP/3，原来的 UDP 部分“下放”到了传输层，所以 有时候也叫“QUIC-transport”。是一个传输层的协议，和 TCP 是平级的

3、QUIC 的特点

a、QUIC 基于 UDP 实现了可靠传输，保证数据一定能够抵达目的地。引入了类似 HTTP/2 的“流”和“多路复用”，单个“流”是有序的，可能会因为丢包而阻塞，但其他“流”不会受到影响

b、QUIC 全面采用加密通信，可以很好地抵御窜改和“协议僵化

c、QUIC 内部“包含”了 TLS1.3。它使用自己的帧“接管”了TLS 里的“记录”，握手消息、警报消息都不使用 TLS 记录，直接封装成 QUIC 的帧发送，省掉了一次开销

4、QUIC 内部细节

QUIC 在协议栈里比较偏底层
a、QUIC 的基本数据传输单位是包（packet）和帧（frame），一个包由多个帧组成，包面向
的是“连接”，帧面向的是“流”

b、QUIC 使用不透明的“连接 ID”来标记通信的两个端点，客户端和服务器可以自行选择一组 ID 来标记自己，这样就解除了 TCP 里连接对“IP 地址 + 端口”（即常说的四元组）的强绑定，支持“连接迁移”

QUIC 的帧里有多种类型，PING、ACK 等帧用于管理连接，而 STREAM 帧专门用来实现流

HTTP/2里的流都是双向的，而 QUIC 则分为双向流和单向流

QUIC 帧普遍采用变长编码；流 ID 还保留了最低两位用作标志，第 1 位标记流的发起者，0 表示客户端，1 表示服务器；第 2 位标记流的方向，0 表示双向流，1 表示单向流；客户端的 ID 是偶数，从 0 开始计数

5、HTTP/3 协议

QUIC 本身就已经支持了加密、流和多路复用，所以 HTTP/3 的工作减轻了很多，把流控制都交给 QUIC 去做。调用的不再是 TLS 的安全接口，也不是 Socket API，而是专门的 QUIC 函数。不过这个“QUIC 函数”还没有形成标准，必须要绑定到某一个具体的实现库

HTTP/3 里仍然使用流来发送“请求 - 响应”，直接使用 QUIC 的流。

HTTP/3 里的“双向流”可以完全对应到 HTTP/2 的流，而“单向流”在 HTTP/3 里用来实现控制和推送，近似地对应 HTTP/2 的 0 号流。

HTTP/3 里帧的结构：

帧头只有两个字段：类型和长度，而且同样都采用变长编码，最小只需要两个字节

HTTP/3 里的帧仍然分成数据帧和控制帧两类，HEADERS 帧和 DATA 帧传输数据，但其他一些帧因为在下层的 QUIC 里有了替代，所以在 HTTP/3 里就都消失了

 头部压缩算法在 HTTP/3 里升级成了“QPACK”，使用方式上也做了改变。虽然也分成静
态表和动态表，但在流上发送 HEADERS 帧时不能更新字段，只能引用，索引表的更新需
要在专门的单向流上发送指令来管理，解决了 HPACK 的“队头阻塞”问题。

QPACK 的字典也做了优化，静态表由之前的 61 个增加到了 98 个，而且序号从 0开始，也就是说“:authority”的编号是 0。

6、HTTP/3 服务发现

HTTP/3 没有指定默认的端口号，也就是说不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服务。

浏览器需要先用 HTTP/2 协议连接服务器，然后服务器可以在启动 HTTP/2 连接后发送一个“Alt-Svc”帧，包含一个“h3=host:port”的字符串，告诉浏览器在另一个端点上提供等价的 HTTP/3 服务。浏览器收到“Alt-Svc”帧，会使用 QUIC 异步连接指定的端口，如果连接成功，就会断开HTTP/2 连接，改用新的 HTTP/3 收发数据。

课后作业：

1. IP 协议要比 UDP 协议省去 8 个字节的成本，也更通用，QUIC 为什么不构建在 IP 协
议之上呢？

传输层TCP和UDP就够了，在多加会提高复杂度，基于UDP向前兼容会好一些。

2. 说一说你理解的 QUIC、HTTP/3 的好处。

在传输层解决了队首阻塞，基于UDP协议，在网络拥堵的情况下，提高传输效率

3. 对比一下 HTTP/3 和 HTTP/2 各自的流、帧，有什么相同点和不同点。

http3在传输层基于UDP真正解决了队头阻塞。http2只是部分解决

三十一、应该迁移到HTTP/2吗？

1、HTTP/2的优点

HTTP/2 完全兼容 HTTP/1，是“更安全的 HTTP、更快的 HTTPS”，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验

2、HTTP/2的缺点

TCP 协议存在“队头阻塞”，所以 HTTP/2 在弱网或者移动网络下的性能表现会不如HTTP/1

3、应该迁移到HTTP/2吗？

HTTP/2 的侧重点是“性能”，所以“是否迁移”就需要在这方面进行评估。如果网站的流量很大，那么 HTTP/2 就可以带来可观的收益；反之，如果网站流量比较小，那么升级到 HTTP/2 就没有太多必要了，只要利用现有的 HTTP 再优化就足矣

4、配置HTTP/2

5、应用层协议协商（ALPN）

在 URI 里用的都是 HTTPS 协议名，没有版本标记，浏览器怎么知道服务器支持 HTTP/2 呢？为什么上来就能用 HTTP/2，而不是用 HTTP/1 通信呢？

在 TLS 的扩展里，有一个叫“ALPN”（Application Layer Protocol Negotiation）的东西，用来与服务器就 TLS 上跑的应用协议进行“协商”。

客户端在发起“Client Hello”握手的时候，后面会带上一个“ALPN”扩展，里面按照优先顺序列出客户端支持的应用协议。

服务器看到 ALPN 扩展以后就可以从列表里选择一种应用协议，在“Server Hello”里也带上“ALPN”扩展，告诉客户端服务器决定使用的是哪一种。

这样在 TLS 握手结束后，客户端和服务器就通过“ALPN”完成了应用层的协议协商，后面
就可以使用 HTTP/2 通信了
 

课后问题：

1. 和“安全篇”的第 29 讲类似，结合自己的实际情况，分析一下是否应该迁移到HTTP/2，有没有难点？

分情况吧，在 HTTPS 的基础上，迁移很简单。

2. 精灵图（Spriting）、资源内联（inlining）、域名分片（Sharding）这些手段为什么会对 HTTP/2 的性能优化造成反效果呢？

因为 HTTP/2 中使用小颗粒化的资源，优化了缓存，而使用精灵图就相当于传输大文件，但是大文件会延迟客户端的处理执行，并且缓存失效的开销很昂贵，很少数量的数据更新就会使整个精灵图失效，需要重新下载(http1 中使用精灵图是为了减少请求)

HTTP1 中使用内联资源也是为了减少请求，内联资源没有办法独立缓存，破坏了 HTTP/2 的多路复用和优先级策略；

域名分片在 HTTP1 中是为了突破浏览器每个域名下同时连接数，但是这在 HTTP/2 中使用多路复用解决了这个问题，如果使用域名分片反而会限制 HTTP2 的自由发挥