计算机网络基础知识汇总

kryiea2024年1月1日

计算机网络 8古语雀导入

1. 导图

2. 网络体系结构

OSI 模型是理论是理论网络模型
TCP/IP 模型是 Linux 实际使用的

2.1. 为什么要设计分层网络模型

模块化：它将网络通信划分为不同的层次，每层负责一组特定的功能，这样可以简化网络的设计和管理。
互操作性：分层模型促进了不同厂商和设备之间的标准化，使得它们能够无缝协作。
维护和扩展性：由于每一层都是独立的，网络可以逐步发展和扩展，而不需要全面重构。
故障隔离：当出现问题时，我们可以快速定位到问题发生在哪一层，这样有助于提高故障排除的效率。
安全性：分层允许我们在不同层级上实施安全控制，提高整个网络的安全性。

2.2. OSI 模型

2.2.1. 参考模型

2.2.2. 各层作用

2.2.3. 7 层通信

会话层只对何时建立连接、何时发送数据等问题进行管理，并不具有实际传输数据的功能
真正负责在网络上传输具体数据的是会话层以下的 4 层

2.3. TCP/IP 模型

2.3.1. TCP/IP 的具体含义

TCP/IP 并不是指 TCP 与 IP 两种协议
很多情况下，TCP/IP只是利用 IP 进行通信时所必须用到的协议群的统称，也称 TCP/IP 为网际协议族

2.3.2. 参考模型

最下面两层可以一起叫：链路层
tcp/ip 分为 4 层

2.3.3. 4 各层作用

**应用层：**应用层是最接近用户的层，它为应用程序提供网络服务。
这一层包括所有高级协议，如HTTP（用于网页访问）、SMTP（用于电子邮件传输）、FTP（用于文件传输）等。
应用层协议定义了应用程序如何通过网络进行通信和数据交换。
**传输层：**传输层负责提供端到端的通信服务。
它确保数据可以在系统之间可靠地、按顺序地以及错误检测和修正的方式传输。
**网络层：**网络层处理数据包在网络中的路由。
它决定数据如何从源头到达目的地，通常涉及跨越多个网络和路由器。
IP协议就位于这一层，它定义了IP地址和数据包如何封装和处理。
**链路层：**链路层负责在网络的物理媒介上发送和接收数据。
这包括处理与物理网络硬件（例如以太网、Wi-Fi、光纤等）的直接交互，以及与地址解析协议（ARP）相关的任务，用于将IP地址解析为物理MAC地址。

2.3.4. 4 层通信

2.4. OSI 和 TCP/IP 模型联系和区别

2.4.1. 联系

基本概念相似：两者都采用了分层的概念，将复杂的网络通信任务分解为更小、更易管理的部分。
共同目标：两者的目标都是实现网络设备之间的互操作性和通信。
部分层次对应：OSI模型的传输层、应用层在TCP/IP模型中有直接对应的层次，而网络层在OSI模型中也有对应，只是在TCP/IP模型中称为互联网层。

2.4.2. 区别

层数不同：OSI模型有7层，而TCP/IP模型通常有4层。
实用性：TCP/IP模型是为了在实际网络中应用而设计的，而OSI模型是理论上的指导框架。
标准化时间：TCP/IP模型比OSI模型更早被广泛采用，因为它是随着互联网的发展而发展起来的。
中间层的差异：OSI模型设有会话层和表示层，而TCP/IP模型通常不区分这些层次
灵活性：TCP/IP模型在实践中被证明更为灵活和可靠，因为它是基于现实世界的需求而设计的。
协议举例：
在OSI模型中，网络层对应的协议包括IPX和IP，而在TCP/IP模型中，互联网层主要使用的协议是IP。
在传输层，OSI模型和TCP/IP模型都使用TCP和UDP协议。

3. 应用层

3.1. HTTP

3.1.1. 报文格式

请求报文、响应报文组成

两者结构相似，三大部分组成：

起始行：描述请求或响应的基本信息
头部字段集合：使用 key-value 形式更详细地说明报文；
消息正文：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据

请求报文、响应报文结构

HTTP 协议规定报文必须有 header，但可以没有 body，
header 之后必须要有一个"空行"，也就是"CRLF"，十六进制的"0D0A"

头部字段 header

头部字段是 key-value 的形式
可以使用标准里的 Host、Connection 等已有头，也可以任意添加自定义头

注意：

字段名不区分大小写，例如"Host"也可以写成"host"，但首字母大写的可读性更好
字段名里不允许出现空格，可以使用连字符"-"，但不能使用下划线"_"
字段名后面必须紧接着":"，不能有空格，而":"后的字段值前可以有多个空格
字段的顺序是没有意义的，可以任意排列不影响语义
字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie

一个 GET 请求实例

一个 POST 请求示例

3.1.2. 请求方法

目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形式：

GET：获取资源，可以理解为读取或者下载数据；
HEAD：获取资源的元信息；
POST：向资源提交数据，相当于写入或上传数据；
PUT：类似 POST；
DELETE：删除资源；
CONNECT：建立特殊的连接隧道；
OPTIONS：列出可对资源实行的方法；
TRACE：追踪请求 - 响应的传输路径。

GET、HEAD

含义：请求从服务器获取资源
HEAD 可以看作是 GET 的简化版，可以在并不真正需要资源的场合，避免传输 body 数据的浪费。（比如检查某个文件是否存在）

POST、PUT

含义：向 URI 指定的资源提交数据，数据就放在报文的 body 里（向服务器发送数据）
通常 POST 表示的是"新建""create"的含义，而 PUT 则是"修改""update"的含义。（PUT 用到的比较少，有些服务器选择直接禁用 PUT 方法）

扩展方法

HTTP 协议有良好的扩展性：可以任意添加请求动作，只要请求方和响应方都能理解就行。
可以根据实际需求，自己发明新的方法，比如"PULL"拉取某些资源到本地，"PURGE"清理某个目录下的所有缓存数据。

安全、幂等

**安全：**是指请求方法不会"破坏"服务器上的资源，即不会对服务器上的资源造成实质的修改。
**幂等：**实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次""幂"后结果"相等"。
GET 和 HEAD 既是安全的也是幂等的，DELETE 可以多次删除同一个资源，效果都是"资源不存在"，所以也是幂等的。
POST 和 PUT 的幂等性质就略费解一点。
POST 是"新增或提交数据"，多次提交数据会创建多个资源，即使数据相同。所以不是幂等的
PUT 是"替换或更新数据"，多次更新一个资源，只要数据是相同的，资源还是第一次更新的状态，所以是幂等的。

3.1.3. URI 和 URL

URI：统一资源标识符（Uniform Resource Identifier）
URL：统一资源定位符（Uniform Resource Locator）
URN：统一资源名称（Uniform Resource Name）
URI 是一个包含URL和URN的超集，它可以是一个位置（URL），也可以是一个名字（URN）
URI 通常可以叫 URL

URI 的格式

URI 基本组成

**scheme：**协议名，表示资源应该使用哪种协议来访问。
**😕/ ：**把 scheme 和后面的部分分离开。
**host：**表示资源所在的主机名，通常的形式是"host:port"主机名可以是 IP 地址或者域名的形式
**path：**标记资源所在位置
**?query：**在 path 之后，用一个"?"开始，但不包含"?"，表示对资源附加的额外要求
参数 query 的格式，：多个"key=value"的字符串，这些 KV 值用字符"&"连接。
http://www.chrono.com:8080/11-1?uid=1234&name=mario&referer=xxx
**#fragment：**片段标识符，是 URI 所定位的资源内部的一个"锚点"或者说是"标签"，浏览器可以在获取资源后直接跳转到它指示的位置。

补充

可以直接把文件或目录从资源管理器" 拖入浏览器窗口，地址栏就会显示出对应的 URI。
查询参数 query 也可以不使用"key=value"的形式，只是单纯的"key"，这样"value"就是空字符串。
如果查询参数 query 太长，也可以使用 POST方法，放在 body 里发送给服务器。
URL还有"绝对URL"和"相对URL"之分多用在HTML页面里标记引用的其他资源，而在HTTP 请求行里则不会出现。
需要注意URI编码转义与 HTML里的编码转义是完全不同的，URI 转义使用的是"%"，而HTML 转义使用的是"&#"，不要混淆

3.1.4. 状态码

RFC规定 HTTP 的状态码为三位数，被分为五类：

1xx ：表示目前是协议处理的中间状态，还需要后续操作
2xx ：表示成功状态
3xx ：重定向状态，资源位置发生变动，需要重新请求
4xx ：请求报文有误
5xx ：服务端发生错误

3.1.4.1. 1xx Informational 信息化

表示临时响应并需要请求者继续执行操作的状态代码。

点击图片可查看完整电子表格

3.1.4.2. 2xx Success 成功

表示成功处理了请求的状态代码。

点击图片可查看完整电子表格

3.1.4.3. 3xx Redirection 重定向

表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。

点击图片可查看完整电子表格

3.1.4.4. 4xx Client Error 客户端错误

这些状态代码表示请求可能出错，妨碍了服务器的处理。

点击图片可查看完整电子表格

3.1.4.5. 5xx Server Error 服务端错误

这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

点击图片可查看完整电子表格

3.1.5. 连接

3.1.5.1. 短链接

短链接

HTTP 协议最初是个非常简单的协议，通信过程也采用了简单的“请求 - 应答”方式。
它底层的数据传输基于 TCP/IP，每次发送请求前需要先与服务器建立连接，收到响应报文后会立即关闭连接。
因为客户端与服务器的整个连接过程很短暂，不会与服务器保持长时间的连接状态，所以就被称为“短连接”（short-lived connections）。早期的 HTTP 协议也被称为是“无连接”的协议。

短链接缺点

短连接的缺点相当严重，因为在 TCP 协议里，建立连接和关闭连接都是非常“昂贵”的操作。
TCP 建立连接要有“三次握手”，发送 3 个数据包，需要 1 个 RTT；
关闭连接是“四次挥手”，4 个数据包需要 2 个 RTT。

3.1.5.2. 长连接

长连接也叫“持久连接”

把时间成本由原来的一个“请求 - 应答”均摊到多个“请求 - 应答”上。

3.1.5.3. 连接相关的头字段

HTTP/1.1 中的连接都会默认启用长连接
也可以在请求头里明确地要求使用长连接机制，使用的字段是Connection，值是 keep-alive

3.1.5.4. 队头阻塞

队头阻塞与短连接和长连接无关，而是由 HTTP 基本的“请求 - 应答”模型所导致的。
因为 HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求被最优先处理。
如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本。

3.1.6. 连接状态

3.1.6.1. http 无状态

HTTP无状态协议，是指协议对于事务处理没有记忆能力，之前做了啥完全记不住，每次请求都是完全独立互不影响的，没有任何上下文信息。
缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大，来实现上下文和状态的交互。
原生无状态的http协议，我们每换一个页面可能就得重新登录一次

3.1.6.2. Cookie

Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie。
内存Cookie：由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。
硬盘Cookie：保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。
所以，按存在时间，可分为非持久Cookie和持久Cookie。

工作过程

响应头字段Set-Cookie
请求头字段Cookie

服务端创建 Cookie

当服务器收到 HTTP 请求时，服务器可以在响应头里面添加一个 Set-Cookie 选项。
浏览器收到响应后通常会保存下 Cookie，之后对该服务器每一次请求中都通过 Cookie 请求头部将 Cookie 信息发送给服务器。
另外，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

Cookie 存在问题

3.1.6.3. Session

Session代表服务器与浏览器的一次会话过程，并且完全有服务端掌控，实现分配ID、会话信息存储、会话检索等功能。
Session机制将用户的所有活动信息、上下文信息、登录信息等都存储在服务端，只是生成一个唯一标识ID发送给客户端，后续的交互将没有重复的用户信息传输，取而代之的是唯一标识ID，暂且称之为Session-ID

与 Cookie 对比

如果说Cookie是客户端行为，那么Session就是服务端行为。

Session 实现方式

首先明确一点：Session和Cookie没有直接的关系，可以认为Cookie只是实现Session机制的一种方法途径而已，没有Cookie还可以用别的方法。

session的实现主要两种方式：cookie与url重写，而cookie是首选方式
因为各种现代浏览器都默认开通cookie功能，但是每种浏览器也都有允许cookie失效的设置，因此对于Session机制来说还需要一个备胎。

Session 利用 Cookie 实现，简单交互过程

当客户端第一次请求session对象时候，服务器会为客户端创建一个session，并将通过特殊算法算出一个session的ID，用来标识该session对象。
当浏览器下次请求别的资源的时候，浏览器会将sessionID放置到请求头中，服务器接收到请求后解析得到sessionID，服务器找到该id的session来确定请求方的身份和一些上下文信息。

Session 机制的弊端

Session信息是存储在服务端的，因此如果用户量很大的场景，Session信息占用的空间就不容忽视。
集群&分布式更是

3.1.6.4. Token

Token是令牌的意思，由服务端生成并发放给客户端，具有时效性的一种验证身份的手段

简单交互流程

以 JWT 为例

以JSON Web Token（JWT）为例，Token主要由3部分组成：

Header头部信息：记录了使用的加密算法信息
Payload 净荷信息：记录了用户信息和过期时间等
Signature 签名信息：Token 根据header中的加密算法和payload中的用户信息以及密钥key来生成
header和payload的信息不做加密，只做一般的base64编码，服务端收到token后剥离出header和payload获取算法、用户、过期时间等信息
然后根据自己的加密密钥来生成signature，并与客户端的sign进行一致性验证。

3.1.7. http 缓存技术

3.1.7.1. 强制缓存

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

Cache-Control，是一个相对时间；
Expires，是一个绝对时间；

Cache-Control 的优先级高于 Expires

3.1.7.2. 协商缓存

协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存

3.1.8. http 版本

3.1.8.1. HTTP/0.9 单行协议

最初版本的 HTTP 协议并没有版本号，后来它的版本号被定位在 0.9 以区分后来的版本。
HTTP/0.9 极其简单：请求由单行指令构成，以唯一可用方法 GET开头，其后跟目标资源的路径（一旦连接到服务器，协议、服务器、端口号这些都不是必须的）。
响应也极其简单的：只包含响应文档本身。

<html>
  这是一个非常简单的 HTML 页面
</html>

跟后来的版本不同，HTTP/0.9 的响应内容并不包含 HTTP 头。
这意味着只有 HTML 文件可以传送，无法传输其他类型的文件。
也没有状态码或错误代码。一旦出现问题，一个特殊的包含问题描述信息的 HTML 文件将被发回，供人们查看。

3.1.8.2. HTTP/1.0 构建可扩展性

由于 HTTP/0.9 协议的应用十分有限，浏览器和服务器迅速扩展内容使其用途更广：

协议版本信息现在会随着每个请求发送（ HTTP/1.0 被追加到了 GET 行）。
状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并相应调整行为（如更新或使用本地缓存）。
引入了 HTTP 标头的概念，无论是对于请求还是响应，允许传输元数据，使协议变得非常灵活，更具扩展性。
在新 HTTP 标头的帮助下，具备了传输除纯文本 HTML 文件以外其他类型文档的能力（凭借 Content-Type标头）。

一个典型的请求看起来就像这样：

GET /mypage.html HTTP/1.0
User-Agent: NCSA\_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
  一个包含图片的页面
  <IMG SRC="/myimage.gif"></HTML>

接下来是第二个连接，请求获取图片（并具有相同的响应）：

GET /myimage.gif HTTP/1.0
User-Agent: NCSA\_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(这里是图片内容)

3.1.8.3. HTTP/1.1 标准化的协议

HTTP/1.0 多种不同的实现方式在实际运用中显得有些混乱

HTTP/1.1 消除了大量歧义内容并引入了多项改进：

连接可以复用，节省了多次打开 TCP 连接加载网页文档资源的时间。
增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。
支持响应分块。
引入额外的缓存控制机制。
引入内容协商机制，包括语言、编码、类型等。并允许客户端和服务器之间约定以最合适的内容进行交换。
凭借 Host标头，能够使不同域名配置在同一个 IP 地址的服务器上。

一个典型的请求流程，所有请求都通过一个连接实现，看起来就像这样：

GET /zh-CN/docs/Glossary/Simple\_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,
\*/\*
;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/zh-CN/docs/Glossary/Simple\_header
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: 
*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/zh-CN/docs/Glossary/Simple\_header
200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache
(image content of 3077 bytes)

3.1.8.4. HTTP/2 为了更优异的表现

HTTP/2 在 HTTP/1.1 有几处基本的不同：

HTTP/2 是二进制协议而不是文本协议。不再可读，也不可无障碍的手动创建，改善的优化技术现在可被实施。
这是一个多路复用协议。并行的请求能在同一个链接中处理，移除了 HTTP/1.x 中顺序和阻塞的约束。
压缩了标头。因为标头在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。
HTTP2 不需要站点和应用做出改变：使用 HTTP/1.1 和 HTTP/2 对他们来说是透明的。
拥有一个最新的服务器和新点的浏览器进行交互就足够了。

3.1.8.5. 后 HTTP/2 进化

随着 HTTP/2.的发布，就像先前的 HTTP/1.x 一样，HTTP 没有停止进化，HTTP 的扩展性依然被用来添加新的功能

3.1.8.6. HTTP/3 基于 QUIC 的 HTTP

HTTP 的下一个主要版本，HTTP/3 有着与 HTTP 早期版本的相同语义，但在传输层部分使用 QUIC (en-US)而不是 TCP。
QUIC 旨在为 HTTP 连接设计更低的延迟。类似于 HTTP/2，它是一个多路复用协议，但是 HTTP/2 通过单个 TCP 连接运行，所以在 TCP 层处理的数据包丢失检测和重传可以阻止所有流。
QUIC 通过 UDP运行多个流，并为每个流独立实现数据包丢失检测和重传，因此如果发生错误，只有该数据包中包含数据的流才会被阻止。

3.2. HTTPS

3.2.1. http 和 https 的区别

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。 HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
HTTP 的端口号是 80，HTTPS 的端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议。

3.2.2. https 混合加密

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

3.2.3. 非对称加密

3.2.3.1. 生成密钥

生成一对匹配的私钥和公钥 (ps：公钥其实是根据私钥生成的)
将公钥公布给外界

RSA 算法

为什么公钥自己加密的数据自己还解不出来？

RSA算法

RSA算法计算流程如下：

随机选取两个质数p和q
计算 n = pq
计算 φ(n) = (p-1)(q-1)
找一个与φ(n)互质的小奇数e，互质是指两个数的公约数只有1
对模φ(n)，计算e的乘法逆元d，即找到一个d，使下列等式成立：(e*d) mod φ(n) = 1
得到公钥：(e, n)，私钥： (d, n)
加密过程：c = (m^e) mod n, （c为加密后的密文，m为原文）
解密过程：m = (c^d) mod n

第七步说明下，m的e次方，m就是我们发送的原文，可以是文本，json，图片，虽然形式多样，但是在计算机里面都是二进制01，所以可以转换成数字求次方。下面我们找两个数来试一下这个算法：

随便选两个质数23和61
计算 n = 23 * 61 = 1403
计算 φ(n) = (23-1) * (61-1) = 22 * 60 = 1320
找一个与φ(n)互质的小奇数e，我们选7
计算乘法逆元d，我这里算好的是 d =943。对乘法逆元感兴趣的朋友可以网上搜搜怎么算，因为不是本文主题，我就不展开了。
得到公钥(7, 1403)，私钥(943, 1403)
我们用公钥随便加密一个5试试，加密 c = (m^e) mod n = (5^7) % 1403 = 78125 % 1403 = 960
私钥解密: m = (c^d) mod n = (960^943) % 1403 = 5，(960^943)这个数字超级大，一般计算器算不出来,JS计算更不行
再试试私钥加密：c = (m^d) mod n = (5^943) % 1403 = 283
公钥解密: m = (c^e) mod n = (283 ^ 7) % 1403 = 5

注意看加密算法(m^e) mod n这是个模运算啊，模运算是不能反解的。

比如5对4取模，5%4=1，但是反过来，知道x%4=1，求x。这个x可以有无限个，5，9，13，17。。。

所以即使你有公钥(e,n),和密文c，你也不知道(m^e)到底取哪个值，是反解不出来的，这就是非对称加密的核心机密，私钥加密同理，自己加密的自己也反解不出来

3.2.3.2. 公钥加密

场景： 用来针对互联网上加密数据传递
Linda 用 James的公钥对数据进行加密，然后发给 James，James用自己的私钥解密

因为一个公钥加密的数据只有对应的私钥才能解密，所以密文很安全

补充：如果要在网络上相互发送密文，可以让对方也发对方的公钥过来，用对方的公钥来加密

3.2.3.3. 私钥签名

场景： 目的是为了将明文公布给别人，同时证明是自己发的；可以防止明文被篡改。

第一步： James 用 James的私钥对明文的hash值进行加密，把密文(签名)和明文一起发给 Linda

第二步： Linda 用 James 的公钥进行解密，解密后的明文hash值和接收到的明文的hash值进行对比，如果一样则是 James 发的

3.2.4. 数字证书、CA 机构

数字签名是什么？ - 阮一峰的网络日志

3.2.4.1. 一个数字证书

一个数字证书通常包含：

公钥；
持有者信息；
证书认证机构（CA）的信息；
CA 对这份文件的数字签名及使用的算法；
证书有效期；
还有一些其他额外信息；

为了让服务端的公钥被大家信任，服务端的证书都是由 CA （证书认证机构）签名

CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

3.2.4.2. 数字证书签发、验证流程

CA 签发证书的过程，如上图左边部分：

首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
最后将 Certificate Signature 添加在文件证书上，形成数字证书；

客户端校验服务端的数字证书的过程，如上图右边部分：

首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信

3.2.4.3. 证书链

向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的

比如百度的证书，从下图你可以看到，证书的层级有三级：

3.2.5. TLS 之 RSA 握手

3.2.5.1. 握手过程流程图

通常经过 4 个消息即可完成 TLS 握手。2 个 RTT

3.2.5.2. 抓包握手过程

3.2.5.3. 第一次握手：客户端打招呼

客户端发送 Client Hello 信息

包括客户端使用的 TLS 版本号
支持的密码套件列表
生成的客户端随机数 Client Random

3.2.5.4. 第二次握手：服务端回应招呼

服务端收到 Client Hello 后
确认 TLS 版本号是否支持
从密码套件列表中选择一个密码套件
生成服务端随机数
服务端返回 Server Hello

消息里面有：

服务器确认的 TLS 版本号
出了服务端随机数 Server Random
从客户端的密码套件列表选择了一个合适的密码套件。

密码套件是： Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256

基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」

由于 WITH 单词只有一个 RSA，则说明握手时密钥交换算法和签名算法都是使用 RSA；
握手后的通信使用 AES 对称算法，密钥长度 128 位
分组模式是 GCM
摘要算法 SHA256 用于消息认证和产生随机数

服务端发送 Server Certificate

消息里含有数字证书

服务端发送 Server Hello Done

目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

3.2.5.5. 第三次握手：客户端确认回应

客户端收到证书后

客户端验证完证书后，认为可信则继续往下走

客户端回应 Client Key Exchange

生成一个新的随机数 (pre-master)

用服务器的 RSA 公钥加密该随机数通过「Client Key Exchange」消息传给服务端

服务端收到后解密

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此，客户端和服务端都共享了三个随机数

Client Random
Server Random
pre-master

客户端发送 Change Cipher Spec

双方根据已经得到的三个随机数，生成**会话密钥（Master Secret）**它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。
Change Cipher Spec 之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

客户端再发送 Encrypted Handshake Message（Finishd）

把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下

让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

3.2.5.6. 第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用「会话密钥」加解密 HTTP 请求和响应了

3.3. DNS

DNS 查询原理详解 - 阮一峰的网络日志

3.4. RPC

3.5. CDN

4. 传输层

4.1. TCP

4.1.1. 三次握手、四次挥手

4.1.2. 可靠性

4.1.3. 粘包、拆包

4.1.4. 半连接、全连接

4.1.5. tcp 异常

4.2. UDP

4.2.1. udp 实现可靠传输

5. 网络层

5.1. IP

5.2. ICMP

5.3. DHCP

5.4. NAT

6. 数据链路层

6.1. ARP 协议

7. 网络传输场景

7.1. 网页异常排查

8. 网络代理

8.1. 正向代理、反向代理

8.2. 负载均衡