3.应用层

一、DNS解析

二、HTTP版本差异

0.9版本：

1991年。只有GET，只支持纯文本。

1.0版本：

1996年。添加POST、HEAD请求，可以传所有格式的文件。可以手动设置Connection: keep-alive，保存长链接

1.1版本

1997年。

• 默认持久连接（keep-alive）
• 管道机制（在同一个TCP连接里，客户端可以同时发送多个请求，但是会引起队头堵塞）

队头堵塞：HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

• 新增方法：PUT、 PATCH、 OPTIONS、 DELETE。
• http协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度。
• http1.x在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，无法保证数据的安全性。

2.0版本

2015年。

安全高效：http2.0建立在https协议的基础上，高效是因为它是通过二进制分帧来进行数据传输。

• **帧：**http/2是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
• **多路复用：**复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，从而减少了队头堵塞的问题，此双向的实时通信称为多工（ Multiplexing）。（由帧首部的流标识符进行标识。）（实际上，队头堵塞是由HTTP层和TCP层，两个方面引起的，HTTP2.0只解决了HTTP层的对头堵塞。所以HTTP2.0也存在对头堵塞的问题）
• 服务器推送：HTTP/2 允许服务器未经请求，主动向客户端发送资源，
• **头部压缩：**引入头信息压缩机制（ header compression） , 头信息使用gzip或compress压缩后再发送，包括不会发送重复的字段。

3.0版本

HTTP3.0 (opens new window)

截至2021年6月，仍是草案阶段。

弃用TCP (opens new window)协议，改为使用基于UDP (opens new window)协议的QUIC (opens new window)（Quick UDP Internet Connections）协议实现。（为了解决HTTP2.0 的队头堵塞）

• 0RTT建立连接：第一个数据包就可以发送数据（也就是不需要建立链接）
• 支持连接迁移：切换网络不需要重连。
• 无对头堵塞

四、HTTP的长链接和短链接的区别

https://www.cnblogs.com/gotodsp/p/6366163.html

五、多路复用和长连接的区别

1. 同一个域名访问同一个文件的多个请求都可以复用一个tcp连接（不用像1.0一样 每次请求都需要重新建立连接）
2. 依然存在的问题：
   1. 多个请求只能被串行处理（数据基于文本，只能按顺序传输）；
   2. 访问多个不同的文件依然会建立多个请求。
3. 多路复用：同一个域名访问多个文件的请求也可以复用一个tcp连接，且多个请求可以被并行处理。
4. 并行实现原理：http2.0引入二进制数据帧和流的概念（数据帧对每一个数据进行标识，可以不按顺序传输，从而实现并行）

六、HTTPS加密过程

1. 客户端主要向服务器提供以下信息，同时索要服务端的证书
   1. 支持的协议版本号
   2. 一个客户端生成的随机数，稍后用于生成"对话密钥"。
   3. 客户端支持的加密算法
   4. 支持的压缩算法
2. 服务器回应
   1. 将自己的证书发送给客户端
   2. 私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。
   3. 证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。另外，证书还有个有效期。
   4. 服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。
3. 客户端回应
   1. 生成一个随机数，如果采用的是RSA加密方式则取出证书中的公钥，生成随机数。该随机数用服务器公钥加密，防止被窃听。
   2. 上面第一项的随机数，是整个握手阶段出现的第三个随机数，它是客户端使用一些加密算法
4. 服务器的最后回应

1、首先，客户端 A 访问服务器 B ，比如我们用浏览器打开一个网页 https://www.baidu.com (opens new window) ，这时，浏览器就是客户端 A ，百度的服务器就是服务器 B 了。这时候客户端 A 会生成一个随机数1，把随机数1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。

2、服务器 B 知道这些信息后，确认一下双方的加密算法，然后服务端也生成一个随机数 B ，并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。

3、 客户端 A 得到 CA 证书后，会去校验该 CA 证书的有效性，校验方法在上面已经说过了。校验通过后，客户端生成一个随机数3 ，然后用证书中的公钥加密随机数3 并传输给服务端 B 。服务端 B 得到加密后的随机数3，然后利用私钥进行解密，得到真正的随机数3。

4、最后，客户端 A 和服务端 B 都有随机数1、随机数2、随机数3，然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法。

5、 客户端 A 通知服务端 B ，指明后面的通讯用对话密钥来完成，同时通知服务器 B 客户端 A 的握手过程结束。

6、服务端 B 通知客户端 A，指明后面的通讯用对话密钥来完成，同时通知客户端 A 服务器 B 的握手过程结束。SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

七、简单介绍加密原理？

1. 客户端生成随机数A，保存本地，同时发送给服务端，告诉那边我支持的加密算法，并索要证书
2. 服务端生成随机数B，保存随机数A，确定加密算法，并发送证书。
3. 客户端用浏览器自带的证书进行检验是否过期，合格，从证书中取出公钥，生成随机数C，对C用公钥加密。发送给服务端。
4. 服务端对加密后的C用他的私钥解密，得到原来的C。
5. 客户端和服务端用ABC作为下一步通信的密钥，开始对称加密通信。