【计算机网络】八股文 | 第二章

零、前言
五、应用层之HTTP各版本与HTTPS区别
- [0. 推荐阅读博客](#0. 推荐阅读博客)
- [1. HTTP 1.0、 HTTP 1.1 、HTTP2.0、HTTP3.0之间的区别？🌟🌟🌟🌟🌟](#1. HTTP 1.0、 HTTP 1.1 、HTTP2.0、HTTP3.0之间的区别？🌟🌟🌟🌟🌟)
- [2. 说一下HTTP 3.0](#2. 说一下HTTP 3.0)
- [3. 队头堵塞？](#3. 队头堵塞？)
- [4. 为什么HTTP3要弃用TCP协议？QUIC的优势？](#4. 为什么HTTP3要弃用TCP协议？QUIC的优势？)
- [5. 为什么 HTTP1.1 不能实现多路复用🌟🌟🌟](#5. 为什么 HTTP1.1 不能实现多路复用🌟🌟🌟)
- [6. 简单讲解一下HTTP2 的多路复用（网易）🌟🌟🌟](#6. 简单讲解一下HTTP2 的多路复用（网易）🌟🌟🌟)
- [7. HTTP1.1 是如何复用 tcp 连接的？](#7. HTTP1.1 是如何复用 tcp 连接的？)
- [8. HTTP/TCP中如何实现多路复用](#8. HTTP/TCP中如何实现多路复用)
- [9. HTTP2/3的头部压缩算法是怎样的？](#9. HTTP2/3的头部压缩算法是怎样的？)
六、应用层之HTTPS
- [0. HTTP和HTTPS协议的区别？](#0. HTTP和HTTPS协议的区别？)
- [1. 什么是HTTPS协议？](#1. 什么是HTTPS协议？)
- [2. HTTPS的特点/优缺点](#2. HTTPS的特点/优缺点)
- [3. HTTPS 的工作/通信（握手）过程（HTTPS原理）](#3. HTTPS 的工作/通信（握手）过程（HTTPS原理）)
- [4. 身份验证过程中会涉及到密钥，对称加密，非对称加密，摘要的概念，请解释一下](#4. 身份验证过程中会涉及到密钥，对称加密，非对称加密，摘要的概念，请解释一下)
- [5. 对称加密和非对称加密](#5. 对称加密和非对称加密)
- [6. 数字证书是什么](#6. 数字证书是什么)
- [7. 数字签名是什么](#7. 数字签名是什么)
- [7. TLS/SSL？工作原理？](#7. TLS/SSL？工作原理？)
- [8. HTTPS是如何保证安全的？](#8. HTTPS是如何保证安全的？)
- [9. 客户端如何验证证书的合法性](#9. 客户端如何验证证书的合法性)
- [10. HTTPS 验证身份](#10. HTTPS 验证身份)
下一章笔记

零、前言

承接前面第一章的笔记：【计算机网络】八股文 | 第一章

笔记链接：【计算机网络】八股文 | 第一章笔记
主要内容：
- 计算机网络层次结构
- 应用层之HTTP协议、URL/URI
- 应用层之HTTP请求，响应，状态码
- 应用层之HTTP请求方法

PS ：下面部分图来源于之前看的博客及视频，之前做笔记没有记录来源，如果知道可以留，我把链接放上。

五、应用层之HTTP各版本与HTTPS区别

0. 推荐阅读博客

推荐博客：

1. HTTP 1.0、 HTTP 1.1 、HTTP2.0、HTTP3.0之间的区别？🌟🌟🌟🌟🌟

从HTTP协议角度上来看，POST 和 PUT 都是用于提交数据给服务器常用的请求方法，两者主要区别在于它们的作用和提交数据的方式。

HTTP1.0（第一个正式版本，短连接，连接无法复用....）
HTTP第一个正式版本，HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用，不支持缓存。也就是说每个TCP连接只能发送一个请求。每次请求和响应完毕后都会销毁 TCP 连接，同时规定前一个响应完成后才能发送下一个请求。这样可能导致队头阻塞的问题。
HTTP1.1（引入长连接，管道机制和Host字段, 支持虚拟机，缓存，支持跨域请求和流水线工作....，新增请求方法，如PUT,HEAD等）

相较于HTTP1.0，HTTP1.1主要的改进是引入了长连接和管道机制（pipelining），并且支持流水线，支持缓存和跨域请求。所谓长连接即TCP连接默认不关闭，可以被多个请求复用。此外，HTTP1.1还可以支持虚拟机，但HTTP1版本都不压缩首部字段，也不支持资源优先级设置，这导致HTTP1版本中的流量和利用率浪费。同时，HTTP1.1并没有解决多路复用的问题。
HTTP2.0（引入二进制分帧，多路复用，头部压缩，服务器推送....）

相较于HTTP1.x版本的文本（字符串）传送， HTTP2.0 采用二进制传送。客户端和服务器传输数据时把数据分成帧，帧组成了数据流，流具有流 ID 标识和优先级，通过优先级以及流依赖能够一定程度上解决关键请求被阻塞的问题。
基于二进制分帧，HTTP2.0实现了多路复用。即在一个TCP连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。

此外，HTTP2.0采用了头部压缩算法（HPACK）和服务器推送。HTTP2.0通过gzip 和 compress 压缩头部，大大减少了流量浪费。HTTP/2 允许服务器未经请求，主动向客户端发送静态资源，这样可以相对减少一些延迟时间。
HTTP3.0（引入安全传输协议TLS/SSL，UDP协议，新的头部压缩算法....）

HTTP/3是基于QUIC协议发展起来的，它完全抛弃了 TCP 协议，在底层使用UDP协议进行数据传输，上层仍然使用 HTTP/2.0。所以，HTTP3.0也被称之为基于UDP的安全可靠的HTTP2.0协议。在 UDP与HTTP2.0之间存在一个 QUIC 层，在该层建立连接过程中会完成TLS加密握手。使用 QPACK 进行头部压缩，因为在 HTTP/2 中的 HPACK 要求传输过程有序，这会导致队头阻塞，而 QPACK 不存在这个问题。

虽然 HTTP2.0进行了大量的优化，但它无法摆脱 TCP 协议本身的问题，比如建立连接时间长、对头阻塞问题等等。为了保证传输的可靠性，HTTP3.0 使用了 QUIC 协议。HTTP3.0基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议。

2. 说一下HTTP 3.0

HTTP 3.0 是 Web 协议的一种新的最终协议，与前一个HTTP协议版本HTTP2.0相比，HTTP3.0摒弃以TCP协议中作为传输层通信，而在底层中采用UDP协议进行数据传输，具有快速握手的优点，在其上层仍然可以看出采用HTTP2.0协议。因此，HTTP3.0综合了UDP和TCP的优势，可以看为是基于UDP的安全可靠的HTTP2.0协议。同时，在UDP和HTTP2.0之间存在一个QUIC层，该层集成了安全加密的功能，如TLS和SSL，可以实现可靠安全的传输。同时QUIC具有多路数据流的优点，可以实现多路复用，解决了TCP队头阻塞的问题。此外，HTTP3.0采用新的头部压缩算法，也可以避免队头阻塞的问题。

3. 队头堵塞？

队头阻塞是指在网络通信过程中，由于队首的数据包发送接收或处理存在较大时延，而队列中后面的数据包也需要跟着一起等待，结果导致其他请求承担不应该有的时间成本（这里是指不能及时接收到数据，而不是不能接收数据），造成一种"队头阻塞"的现象。队头阻塞一般发生在HTTP层和TCP层，因此可以分为两种类型，即HTTP队头阻塞和TCP队头阻塞。两者虽然不相同，但存在一定联系，毕竟HTTP 是建立在 TCP 协议之上的应用层协议。队头阻塞与短连接/长连接无关，而是由HTTP基本的"请求-应答"模式所导致的

TCP队头阻塞

TCP采用了"顺序控制"和"重发控制"机制，另外还使用"流量控制"和"拥塞控制"来提高网络利用率。这里的"顺序控制"指的是最终顺序是按序排列的，也就是说每当有一个或几个Packet丢失的时候，会等待它到达后合并，然后再向上交付。因此，很容易可以理解，当一个流的第一个数据包丢失了，那么即使后面的数据包都到达了，后面的这些数据包也不能被处理，而是要等第一个数据包到了之后才能被上层接收处理，那么这个时候不止是第一个数据包需要额外等待一个或多个RTT，后面的第二个Packet、第三个Packet...都需要同样多等待那么多时间才能处理，但实际上他们是按时到达了的，这也就是所谓的TCP队头阻塞。

TCP 的阻塞问题是因为传输阶段可能会丢包，TCP是一个按序传输的通道,一旦丢包就会等待重新发包，阻塞后续内容传输
HTTP队头阻塞

对于每一个HTTP请求，会被放入一个任务队列中串行执行，一旦队首任务请求太慢时，就会阻塞后面的请求处理。

HTTP1.x有非管道化和管道化，两种方式。
- 非管道化，完全串行执行，请求->响应->请求->响应...，后一个请求必须在前一个响应之后发送。
- 管道化，请求可以并行发出，但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是，没有序号标明顺序，只能串行接收。所以，由于这个原因，目前大部分浏览器和Web服务器，都关闭了管道化，采用非管道化模式。
- 无论是非管道化还是管道化，都会造成队头阻塞(请求阻塞)。因为虽然管道化能够多次同时发送多个请求，但是相应却是必须要等前面的返回才能继续返回其余的响应。
  - HTTP队头阻塞的解决方法：
    1. 并发TCP连接（浏览器一个域名采用6-8个TCP连接，并发HTTP请求）
    2. 域名分片（多个域名，可以建立更多的TCP连接，从而提高HTTP请求的并发）
    3. HTTP2方式（多路复用特性）

4. 为什么HTTP3要弃用TCP协议？QUIC的优势？

在HTTP3之前，HTTP协议都是基于TCP协议进行通信的，而基于TCP协议会引起队头堵塞等问题。队头堵塞问题可能存在于HTTP层和TCP层，在HTTP1.x时两个层次都存在该问题。HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题，但是在TCP层仍然存在队头阻塞问题。虽然TCP协议是面向连接的可靠传输，但TCP协议建立接连时间（三次握手时间）相对较长，通信速度相对缓慢，而且基于TCP协议栈是Linux系统内部的核心部分，修改和升级成本比较大，开发的协议和设备较多，需要考虑的兼容也比较多。因此，谷歌选择UDP（无连接，速度快，耗时第等优点）来改造升级HTTP，但由于UDP本身不可靠，又不能直接用，所以谷歌基于UDP，添加了具备TCP可靠安全的属性，成为新的协议QUIC。
HTTP/3 抛弃 TCP 后，基于 UDP 实现的可靠传输 QUIC 协议，带来这四点好处：

降低连接耗时：在客户端有缓存的情况下实现0-RTT建立连接
更灵活的拥塞控制：在用户态可以为每个请求配置不同的拥塞控制策略
无队头阻塞的多路复用：每个请求流独立拥有滑动窗口，互不影响
连接迁移：网络切换不会中断数据传输

5. 为什么 HTTP1.1 不能实现多路复用🌟🌟🌟

前提知识：

HTTP多路复用指在HTTP协议中，通过将多个请求和响应同时放在一个 TCP 连接中，从而提高网站的性能和吞吐量。它可以在不增加 TCP 连接数的情况下，增加网站的处理能力，同时减少网络延迟和带宽浪费。多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。

回答：

根据HTTP/1.1 协议的定义，TTP1.1 协议是基于请求 - 响应模型的，每个请求和响应都是通过独立的 TCP 连接传输的。这种独立性使得 HTTP1.1 协议无法实现多路复用，因为每个请求和响应都需要独立的 TCP 连接。

同时，HTTP1.1采用文本进行传输，没有流的概念。文本传输是一种非实时的数据传输模式，也就是说无法保证连接的实时性，数据到达的顺序，若文本传输采用多路复用则在接收端无法区分多个响应分别对应的请求，所以无法将多个响应的结果重新进行组装，也就实现不了多路复用。

6. 简单讲解一下HTTP2 的多路复用（网易）🌟🌟🌟

在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。当多个请求或响应被同时传输时，HTTP/2 的多路复用使用称为"流"的机制来管理这些连接。每个流都有自己的头部和数据，并且可以独立传输。服务器可以在多个流之间动态分配资源，以便同时处理多个客户端的请求。
HTTP2 的多路复用是指在 HTTP2 协议中，通过使用多个流来实现多个请求和响应的同时传输。在 HTTP2 中，每个请求和响应都被封装在一个流中，并且可以在不同的流之间进行切换，以实现并发传输。
HTTP2 的多路复用相对于 HTTP1.1 的区别在于，HTTP2 的多路复用不需要建立连接，而 HTTP1.1 的多路复用需要建立连接。HTTP2 的多路复用可以通过服务器的推送 (push) 来实现，而 HTTP1.1 的多路复用只能通过客户端的拉取 (pull) 来实现。

7. HTTP1.1 是如何复用 tcp 连接的？

客户端请求服务器时，通过请求行告诉服务器使用的协议是 http1.1，同时在请求头中附带connection:keep-alive（为保持兼容），告诉服务器这是一个长连接，后续请求可以重复使用这一次的 TCP 连接。

这样做的好处是减少了三次握手和四次挥手的次数，一定程度上提升了网络利用率。但由于 http1.1 不支持多路复用，响应顺序必须按照请求顺序抵达客户端，不能真正实现并行传输，因此在 http2.0 出现之前，实际项目中往往把静态资源，比如图片，分发到不同域名下的资源服务器，以便实现真正的并行传输。

8. HTTP/TCP中如何实现多路复用

首先，HTTP多路复用是指一个TCP连接中存在多个请求和响应。所以，实现多路复用其实就是使一个TCP连接可以同时发送多个请求并可识别对应请求而做出响应。根据这个原理，可以采用三种策略。

第一个是采用异步处理策略，使服务器在在等待客户端请求时，可以同时处理多个请求，比如非阻塞IO模型，管道模式，事件驱动，轮询复用。
第二是采用多线程/进程来处理，使HTTP服务器同时处理多个请求，比如线程池。
第三则是利用带标识的优化及缓存等技术来实现，比如请求分片、应答分片和HTTP 缓存。
回答一

在 HTTP 多路复用中，通常使用非阻塞 IO 模型和事件驱动模型来实现多路复用。非阻塞 IO 模型可以在 TCP 连接上并发发送和接收数据，而事件驱动模型可以实时处理 HTTP 请求和响应。
回答二

HTTP 多路复用可以通过以下两种方式实现:
1. 异步 IO:HTTP 多路复用可以通过异步 IO 来实现。异步 IO 可以让 HTTP 服务器在等待客户端请求时，可以同时处理多个请求。这种方式可以提高 HTTP 服务器的处理能力，但是需要操作系统和服务器硬件的支持。
2. 多线程/进程:HTTP多路复用也可以通过多线程/进程来实现。多线程/进程可以让HTTP服务器同时处理多个请求,从而提高HTTP服务器的处理能力。这种方式需要操作系统和服务器硬件的支持,并且需要合理规划线程/进程的数量,以避免资源浪费。
回答三
1. 管道模式 (Pipelining):管道模式是一种简单的多路复用技术，它允许 HTTP 客户端在同一 TCP 连接上发送多个请求，而不必等待之前的请求完成。HTTP 客户端首先发送一个请求，然后立即发送一个应答，然后将 TCP 连接释放。HTTP 服务器收到请求后，立即发送一个应答，然后等待客户端发送下一个请求。这种方法可以提高系统的并发处理能力，但是需要更多的硬件和软件支持。
2. 请求分片 (Request Segmentation):请求分片是将 HTTP 请求分成多个片段，每个片段都可以独立发送。这种方法可以在多个请求同时发送时，避免 TCP 连接的频繁建立和释放。HTTP 服务器收到片段后，将它们合并成一个完整的 HTTP 请求，然后发送出去。请求分片可以提高系统的并发处理能力，但是需要更多的硬件和软件支持。
3. 应答分片 (Response Segmentation):应答分片是将 HTTP 响应分成多个片段，每个片段都可以独立发送。这种方法可以在多个响应同时发送时，避免 TCP 连接的频繁建立和释放。HTTP 客户端收到片段后，将它们合并成一个完整的 HTTP 响应，然后发送出去。应答分片可以提高系统的并发处理能力，但是需要更多的硬件和软件支持。
4. HTTP 缓存 (HTTP Caching):HTTP 缓存是一种基于内容的缓存技术，它允许 HTTP 服务器缓存已经生成的响应。HTTP 客户端发送一个请求时，HTTP 缓存可以检查响应是否已经被缓存。如果是，HTTP 缓存可以立即发送响应，而不必生成新的响应。这种方法可以提高系统的并发处理能力，但是需要更好的缓存管理和策略。

9. HTTP2/3的头部压缩算法是怎样的？

HTTP2和HTTP3的头部压缩算法都是用来减少所要传输的数据量，可以提高网络的传输效率，提高网页的加载速度和用户体验。其中HTTP2中采用HPACK做为头部压缩算法，而HTTP3采用QPACK算法。

HPACK算法是一种用于数据包缓存和传输优化的算法，它基于贪心策略来缓存和传输数据包，从而提高网络传输效率。HPACK 算法会计算出每个数据包的哈希值、已接收标记和优先级标记，以优化数据包的缓存和传输。

HPACK算法采用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。HTTP2会在客户端和服务器两端建立"字典"，用索引号表示重复的字符串。

具体来说:
- 在客户端和服务器端使用"首部表"来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送；
- 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新；
- 每个新的首部键值对要么被追加到当前表的末尾，要么替换表中之前的值
QPACK算法使用哈希表技术来删除数据中的重复字符，从而提高压缩效率和压缩比。QPACK 算法通常被应用于数据压缩和文件压缩领域。

其核心思想是使用一个哈希表来记录数据中出现的字符，并将哈希值作为索引来访问哈希表，以查找重复的字符。如果哈希表中已经存在该字符，则直接将该字符对应的数据压缩成一个独立的压缩块;如果哈希表中不存在该字符，则将该字符对应的数据添加到压缩块中，并返回该压缩块的唯一标识符。

区别：

从实现方式来看，QPACK 算法是一种数据压缩算法，它通过对数据进行哈希表压缩来减少数据存储空间和传输带宽。而 HPACK 算法是一种用于优化数据包传输和缓存的算法，它通过贪心策略来缓存数据包并计算出每个数据包的优先级，以确保数据包可以被更快地传输和缓存。

压缩方式:QPACK 算法是一种压缩算法，它将数据压缩成多个压缩块，而 HPACK 算法则是一种优化数据包缓存和传输的算法，它通过哈希表技术和已接收标记、优先级标记等机制来优化数据包的缓存和传输。
应用领域:QPACK 算法通常被应用于数据压缩和文件压缩领域，而 HPACK 算法则被广泛应用于 TCP/IP 协议栈中，以优化数据包的缓存和传输效率。
压缩比:QPACK 算法的压缩比通常很高，因为它可以有效地删除数据中的重复字符，但 HPACK 算法的压缩比相对较低，因为它主要关注数据包的缓存和传输效率。

六、应用层之HTTPS

0. HTTP和HTTPS协议的区别？

HTTP是一种以保证客户端与服务端通信为目的的超文本传输协议，而HTTPS是以通信安全为设计目标的安全超文本传输协议，虽然两者都是用于 Web 浏览器和服务器之间的通信协议。但两者有很大的区别，尤其是在安全和隐私保护能力上。

首先，从数据传输和数据缓存的方式来看，HTTP采用明文传输协议，而HTTPS使用SSL/TLS加密协议来保护数据传输过程中的隐私和安全性，所以HTTPS比HTTP更具安全性。但HTTPS缓存不如HTTP高效。在HTTP协议中，HTTP直接和TCP通信；而在HTTPS协议中，HTTP会先和SSL通信，再由SSL和TCP通信，这样会增加数据的开销，所以HTTPS在握手阶段会比较耗时，会延长界面的加载时间和耗电。
其次，从连接方式和默认端口来看，HTTP协议是无状态的连接，默认端口为80；而HTTPS是可以进行身份认证的网络协议，默认端口号为443。
最后，从费用角度来看，HTTPS协议需要CA证书，费用较高。

总的来说，HTTPS实际上可以看成HTTP协议的安全版本，HTTPS=HTTP+加密+认证+完整性保护。

1. 什么是HTTPS协议？

HTTPS表示超文本传输安全协议，是以为通信安全为设计目标，采用SSL/TSL协议来加密HTTP请求和响应内容的安全通信传输协议。HTTPS=HTTP+加密+认证+完整性保护HTTPS主要目的是提供对网站服务器的身份认证，保护交换数据的隐私安全与完整性。这使得 HTTPS 协议成为访问敏感资源时的首选协议。

HTTP协议采用明文传输 信息，存在信息窃听 、信息篡改 和信息劫持 的风险，而协议TLS/SSL具有身份验证 、信息加密 和完整性校验的功能，可以避免此类问题发生。

2. HTTPS的特点/优缺点

HTTPS的优点如下：
1. 安全性高：使用HTTPS协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性。虽然HTTPS不是绝对的安全，但是大幅增加了中间人攻击的成本
2. 可靠性高：使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器。HTTPS 协议需要使用证书，证书包含了服务器的公钥，客户端可以通过验证证书的合法性来确保通信的服务器是合法的
3. 隐私性高（女明星）：HTTPS 协议可以隐藏客户端的真实 IP 地址，从而保护客户端的流量隐私
HTTPS的缺点如下：
1. 费用较高：HTTPS需要申请CA证书，证书是收费的，功能越强大的证书费用越高。同时CA 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名，IPV4 资源支持不了这种消耗。
2. 复杂度较高：HTTPS需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂；
3. 时耗/传输速度性能较差：HTTPS协议握手阶段比较费时，增加页面的加载时间；
4. 数据开销和功耗大：HTTPS缓存不如HTTP高效。在HTTP协议中，HTTP直接和TCP通信；而在HTTPS协议中，HTTP会先和SSL通信，再由SSL和TCP通信，这样会增加数据的开销
5. 需要客户端支持:HTTPS 协议需要客户端支持才能使用，因此需要升级客户端软件

3. HTTPS 的工作/通信（握手）过程（HTTPS原理）

HTTPS 的工作过程可以概括为以下几个步骤:

客户端发起 HTTPS 请求并告知密钥信息。 客户端向服务器发起一个 HTTPS 请求，请求的 URL 中包含要访问的资源的路径。在这一步，客户端会服务器自身支持的加密算法以及密钥长度等信息。
2. 服务器在收到请求后，将自己的数字证书发送给客户端（服务器发送 SSL/TLS 证书）并响应公钥。 服务器向客户端发送 SSL/TLS 证书（这套证书其实就是一对公钥和私钥，公钥可以发送给别人，但是私钥只有自己知道），证书包含了服务器的公钥、域名等信息，用于验证服务器的身份。
3. 客户端验证证书。 客户端收到证书后，会验证证书的合法性。如果证书合法，客户端会生成一个随机数，并将该随机数和服务器的公钥一起发送给服务器。
4. 服务器验证随机数。 服务器收到客户端发送的随机数和公钥后，会验证随机数的合法性。如果随机数合法，服务器会生成一个对称密钥，并用客户端的公钥进行加密，然后将加密后的对称密钥发送给客户端。
5. 客户端验证对称密钥。 客户端收到服务器发送的对称密钥后，会验证对称密钥的合法性。如果对称密钥合法，客户端会使用自己的私钥解密对称密钥。
6. 客户端和服务器使用对称密钥进行数据传输 。客户端和服务器都拥有了相同的对称密钥，接下来就可以用它来进行数据传输了。
7. 数据传输完成。 在数据传输完成后，客户端和服务器断开连接。

4. 身份验证过程中会涉及到密钥，对称加密，非对称加密，摘要的概念，请解释一下

密钥：是在明文转换为密文或将密文转换为明文的算法中输入的参数

密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。
对称加密（私钥加密）：指通信双方使用相同的密钥进行数据的加密和解密

对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有 DES、3DES、TDEA、Blowfish、RC5 和 IDEA。
非对称加密（公钥加密）：指通信双方使用不同的密钥进行加密和解密，其中加密使用公钥，解密使用私钥

非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。
摘要： 又称哈希/散列算法，即把摘要算法又称哈希/散列算法。它通过一个函数，把任意长度的数据转换为一个长度固定的数据串（通常用 16 进制的字符串表示）。算法不可逆。

5. 对称加密和非对称加密

对称加密和非对称加密都是HTTPS中常见的加密方式。

对称加密是指加密和解密使用相同的密钥，即对称密钥
- 类型
  对称密钥加密算法通常分为提前公开对称密钥和不提前公开对称密钥两种类型。
  - 提前公开对称密钥：在加密和解密前，提前公开对称密钥，这种算法安全性较高，但会影响通信效率
  - 不提前公开对称密钥：加密和解密使用不同的密钥，这种算法安全性较低，但可以提高通信效率
- 特点
  优点是速度快，缺点是安全性相对较低。信息传输使用一对一，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和N个客户端通信，需要维持N个密码记录且不能修改密码。
- 存在问题
  安全性较低，需要考虑密钥发送问题，即如何安全地将密钥发给对方。
- 常见算法
  AES(高级加密标准)、RSA(公钥加密算法)、DES、3DES、AES-GCM等。
非对称加密是指加密和解密使用不同的密钥，即非对称密钥------公钥和私钥。
- 在非对称密钥加密中，加密使用公钥，解密使用私钥。公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
  1. 公钥是指由一个实体向公众发布的密钥，这个密钥可以用于加密数据，但它不能用于解密数据。公钥通常用于数字签名、非对称密钥加密等算法中，以确保数据的安全性和完整性。
  2. 私钥则是指由一个实体私人持有的密钥，这个密钥只能用于解密数据，而不能用于加密数据。私钥通常用于对称密钥加密、私钥加密等算法中，以确保数据的隐私性和安全性。
- 特点
  安全性较高，缺点是速度慢，信息一对多。因为它使用的是不同的密钥，所以需要耗费更多的计算资源。服务器只需要维持一个私钥就可以和多个客户端进行通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密的速度慢。公钥加密的信息只有私钥可以解开，私钥加密的信息只能公钥解开，因此掌握公钥的不同客户端之间不能相互解密信息，只能和服务器进行加密通信，服务器可以实现一对多的的通信，客户端也可以用来验证掌握私钥的服务器的身份。
- 常见算法
  RSA、DSA、ECDSA 等。在实际应用中，非对称加密通常用于需要确保数据完整性和安全性的场合，例如数字证书的颁发、SSL/TLS 协议的加密等。

6. 数字证书是什么

数字证书是一种用于验证数字信息真实性和完整性的证书。它通常由一个第三方机构颁发，用于验证客户端与服务器之间通信的密钥、证书持有者的身份以及数据完整性。

原理：使用一种 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为数字证书。当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和生成的摘要进行对比，就能发现得到的信息是否被更改。
作用：确保客户端与服务器之间通信的安全性和隐私性，防止数据被篡改或窃取。

7. 数字签名是什么

数字签名是一种用于保证数字信息真实性和完整性的算法。它通过将数据与签名者的数字私钥进行数字签名，来确保数据在传输过程中没有被篡改或伪造，同时验证者可以通过计算签名值来验证签名的真实性。

数字签名通常使用哈希算法和私钥加密技术来实现。数字签名可以将原始数据转化为哈希值，并将哈希值作为签名附加到原始数据上。验证者接收到数据后，可以使用签名者的私钥对哈希值进行计算，并将其与接收到的哈希值进行比较。如果计算结果相同，则可以确定数据没有被篡改或伪造。（就是先用CA自带的Hash算法来计算出证书内容的一个摘要，然后使用CA私钥进行加密，组成数字签名。）

7. TLS/SSL？工作原理？

TLS 全称为安全传输层协议（Transport Layer Security）
SSL全称为安全套接层 （Secure Sockets Layer）

两者都是用于保证传输安全的协议，介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，TLS 是 SSL 的升级版。他们的功能实现和基本流程一致。

两者功能实现主要依赖三类基本算法：散列函数hash 、对称加密 、非对称加密。这三类算法的作用如下：

基于散列函数验证信息的完整性
对称加密算法采用协商的秘钥对数据加密
非对称加密实现身份认证和秘钥协商

基本流程：

客户端向服务器端索要公钥，并使用数字证书验证公钥。
客户端使用公钥加密会话密钥，服务端用私钥解密会话密钥，于是得到一个双方都认可的会话密钥
传输的数据使用会话密钥加密，然后再传输，接收消息方使用会话密钥解密得到原始数据

8. HTTPS是如何保证安全的？

HTTPS 采用混合的加密机制，就是发送方用非对称加密的公钥对对称加密的密钥进行加密，然后发送出去，之后，接收方使用私钥进行解密得到对称加密中的密钥，最后双方使用对称密钥进行通信。因此，HTTPS其实就是用非对称密钥保证密钥传输过程的安全性，用对称密钥保证通信过程的效率，结合了对称密钥和非对密钥的优点。

确保传输安全过程（其实就是rsa原理）：
1. Client给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。

Server确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
Client确认数字证书有效，然后生成呀一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给Server。
Server使用自己的私钥，获取Client发来的随机数（Premaster secret）。
Client和Server根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

💡 扩展
虽然HTTPS的混合加密机制兼顾了安全性和通信效率，但是在保证安全过程中第一步发送方获取的公开密钥可能被篡改（也就是中间人问题）。这是可以通过数字证书来解决。但是中间人篡改了证书是，则需要数字签名来保证安全性了。

中间人篡改公钥问题 → 数字证书解决
- 问题描述：客户端和服务器之间存在一个中间人,这个中间人只需要把原本双方通信互发的公钥,换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据。
- 方法描述：发布一个安全的第三方颁发证书（CA），证明身份的身份，防止中间人攻击，其中，证书中包含签发者，证书用途，使用者公钥和私钥，使用者的HAHA算法和证书到期时间等。
中间人篡改证书问题 → 数字签名技术解决
- 问题描述：当中间人篡改证书，则身份证明无法起效，证书相当于白买。
- 方法描述：采用数字签名技术，也就是数字签名者使用自己的私钥对数据进行加密，然后将加密后的数据和数字证书一起发送给接收方。接收方收到数据后，可以使用数字证书中的公钥对数据进行解密，然后比较解密后的数据是否与原始数据相同。如果数据不一致，则说明数据被篡过。

摘要是指对请求或响应的内容进行计算的一种算法，以便在传输过程中验证数据是否被篡改或伪造。

数字签名技术主要包括两个组成部分：数字证书和数字签名。数字证书是由证书颁发机构 (CA) 颁发的，用于验证数字签名者的身份和数字签名的有效性。数字证书通常包含数字签名者的有效公钥、数字签名日期、数字签名算法等信息。数字签名则是数字证书中的数字签名部分，用于对数据进行数字签名，确保数据的完整性和真实性。

9. 客户端如何验证证书的合法性

首先浏览器读取证书中的证书所有者、有效期等信息进行校验，校验证书的网站域名是否与证书颁发的域名一致，校验证书是否在有效期内
浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布
版本时，会事先在内部植入常用认证机关的公开密钥)，然后对服务器发来的证书里面的签名进行解密
浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
对比结果一致，则证明服务器发来的证书合法，没有被冒充

10. HTTPS 验证身份

也就是 TSL/SSL 身份验证的过程

客户端请求服务器，并告诉服务器自身支持的加密算法以及密钥长度等信息
服务器响应公钥和服务器证书
客户端验证证书是否合法，然后生成一个会话密钥，并用服务器的公钥加密密钥，把加密的结果通过请求发送给
服务器服务器使用私钥解密被加密的会话密钥并保存起来，然后使用会话密钥加密消息响应给客户端，表示自己已经准备就绪
客户端使用会话密钥解密消息，知道了服务器已经准备就绪。
后续客户端和服务器使用会话密钥加密信息传递消息

下一章笔记

下一章笔记的链接：

【计算机网络】八股文 | 第三章

笔记链接：【计算机网络】八股文 | 第三章

主要知识点：主要包括的知识有HHTP的劫持与攻击，DNS与XSS劫持以及相关的定义与方式，HTTP的两种连接法师，Keep-alive的理解与作用，HHTP缓存的相关知识点等知识要点。