[docs add&update]完善网络面试题+新增 DNS 域名系统详解

README.md

@@ -151,6 +151,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
 - [HTTP vs HTTPS（应用层）](./docs/cs-basics/network/http&https.md)
 - [HTTP 1.0 vs HTTP 1.1（应用层）](./docs/cs-basics/network/http1.0&http1.1.md)
 - [HTTP 常见状态码（应用层）](./docs/cs-basics/network/http-status-codes.md)
+- [DNS 域名系统详解（应用层）](./docs/cs-basics/network/dns.md)
 - [TCP 三次握手和四次挥手（传输层）](./docs/cs-basics/network/tcp-connection-and-disconnection.md)
 - [TCP 传输可靠性保障（传输层）](./docs/cs-basics/network/tcp-reliability-guarantee.md)
 - [ARP 协议详解(网络层)](./docs/cs-basics/network/arp.md)

docs/.vuepress/sidebar.ts

@@ -176,6 +176,7 @@ export const sidebarConfig = sidebar({
                 "http&https",
                 "http1.0&http1.1",
                 "http-status-codes",
+                "dns",
                 "tcp-connection-and-disconnection",
                 "tcp-reliability-guarantee",
                 "arp",

docs/cs-basics/network/application-layer-protocol.md

@@ -7,18 +7,19 @@ tag:
 
 ## HTTP:超文本传输协议
 
-**超文本传输协议（HTTP，HyperText Transfer Protocol)** 主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的，整个过程如下图所示。
+**超文本传输协议（HTTP，HyperText Transfer Protocol)** 是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。
+
+HTTP 使用客户端-服务器模型，客户端向服务器发送 HTTP Request（请求），服务器响应请求并返回 HTTP Response（响应），整个过程如下图所示。
 
 ![](https://oss.javaguide.cn/github/javaguide/450px-HTTP-Header.png)
 
-HTTP 协是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。
-
+HTTP 协议基于 TCP 协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。
 
 另外， HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。
 
 ## SMTP:简单邮件传输(发送)协议
 
-**简单邮件传输(发送)协议（SMTP，Simple Mail Transfer Protocol）** 基于 TCP 协议，用来发送电子邮件。
+**简单邮件传输(发送)协议（SMTP，Simple Mail Transfer Protocol）** 基于 TCP 协议，是一种用于发送电子邮件的协议
 
 ![SMTP 协议](https://oss.javaguide.cn/github/javaguide/cs-basics/network/what-is-smtp.png)
 
@@ -54,13 +55,13 @@ SMTP 协议这块涉及的内容比较多，下面这两个问题比较重要：
 
 ## POP3/IMAP:邮件接收的协议
 
-这两个协议没必要多做阐述，只需要了解 **POP3 和 IMAP 两者都是负责邮件接收的协议**即可。另外，需要注意不要将这两者和 SMTP 协议搞混淆了。**SMTP 协议只负责邮件的发送，真正负责接收的协议是POP3/IMAP。**  
+这两个协议没必要多做阐述，只需要了解 **POP3 和 IMAP 两者都是负责邮件接收的协议** 即可（二者也是基于 TCP 协议）。另外，需要注意不要将这两者和 SMTP 协议搞混淆了。**SMTP 协议只负责邮件的发送，真正负责接收的协议是 POP3/IMAP。**
 
-IMAP 协议相比于POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。
+IMAP 协议是比 POP3 更新的协议，它在功能和性能上都更加强大。IMAP 支持邮件搜索、标记、分类、归档等高级功能，而且可以在多个设备之间同步邮件状态。几乎所有现代电子邮件客户端和服务器都支持 IMAP。
 
 ## FTP:文件传输协议
 
-**FTP 协议** 主要提供文件传输服务，基于 TCP 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽操作系统和文件存储方式。
+**FTP 协议** 基于 TCP 协议，是一种用于在计算机之间传输文件的协议，可以屏蔽操作系统和文件存储方式。
 
 FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP 服务器之间建立两个连接。如果我们要基于 FTP 协议开发一个文件传输的软件的话，首先需要搞清楚 FTP 的原理。关于 FTP 的原理，很多书籍上已经描述的非常详细了：
 
@@ -73,15 +74,40 @@ FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP
 
 ![FTP工作过程](https://oss.javaguide.cn/github/javaguide/cs-basics/network/ftp.png)
 
+注意 ⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。因此，FTP 传输的文件可能会被窃听或篡改。建议在传输敏感数据时使用更安全的协议，如 SFTP（一种基于 SSH 协议的安全文件传输协议，用于在网络上安全地传输文件）。
 
 ## Telnet:远程登陆协议
 
-**Telnet 协议** 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的非常安全的协议所取代的主要原因。
+**Telnet 协议** 基于 TCP 协议，用于通过一个终端登陆到其他服务器。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用 Telnet，而是使用一种称为 SSH 的非常安全的网络传输协议的主要原因。
+
+![Telnet:远程登陆协议](https://oss.javaguide.cn/github/javaguide/cs-basics/network/Telnet_is_vulnerable_to_eavesdropping-2.png)
 
 ## SSH:安全的网络传输协议
 
-**SSH（ Secure Shell）** 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH  建立在可靠的传输协议 TCP 之上。
+**SSH（Secure Shell）** 基于 TCP 协议，通过加密和认证机制实现安全的访问和文件传输等业务。
 
-**Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。**
+SSH 的经典用途是登录到远程电脑中执行命令。除此之外，SSH 也支持隧道协议、端口映射和 X11 连接。借助 SFTP 或 SCP 协议，SSH 还可以传输文件。
 
-![](https://oss.javaguide.cn/github/javaguide/cs-basics/network/tcp-udp-overview.png)
+SSH 使用客户端-服务器模型，默认端口是 22。SSH 是一个守护进程，负责实时监听客户端请求，并进行处理。大多数现代操作系统都提供了 SSH。
+
+![SSH:安全的网络传输协议](https://oss.javaguide.cn/github/javaguide/cs-basics/network/ssh-client-server.png)
+
+## RTP:实时传输协议
+
+RTP（Real-time Transport Protocol，实时传输协议）通常基于 UDP 协议，但也支持 TCP 协议。它提供了端到端的实时传输数据的功能，但不包含资源预留存、不保证实时传输质量，这些功能由 WebRTC 实现。
+
+RTP 协议分为两种子协议：
+
+- **RTP（Real-time Transport Protocol，实时传输协议）** ：传输具有实时特性的数据。
+- **RTCP（RTP Control Protocol，RTP 控制协议）** ：提供实时传输过程中的统计信息（如网络延迟、丢包率等），WebRTC 正是根据这些信息处理丢包
+
+## DNS:域名系统
+
+DNS（Domain Name System，域名管理系统）基于 UDP 协议，用于解决域名和 IP 地址的映射问题。
+
+![DNS:域名系统](https://oss.javaguide.cn/github/javaguide/cs-basics/network/dns-overview.png)
+
+## 参考
+
+- 《计算机网络自顶向下方法》（第七版）
+- RTP 协议介绍:https://mthli.xyz/rtp-introduction/

docs/cs-basics/network/dns.md

@@ -0,0 +1,102 @@
+---
+title:  DNS 域名系统详解（应用层）
+category: 计算机基础
+tag:
+  - 计算机网络
+---
+
+DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是**域名和 IP 地址的映射问题**。
+
+![DNS:域名系统](https://oss.javaguide.cn/github/javaguide/cs-basics/network/dns-overview.png)
+
+在实际使用中，有一种情况下，浏览器是可以不必动用 DNS 就可以获知域名和 IP 地址的映射的。浏览器在本地会维护一个`hosts`列表，一般来说浏览器要先查看要访问的域名是否在`hosts`列表中，如果有的话，直接提取对应的 IP 地址记录，就好了。如果本地`hosts`列表内没有域名-IP 对应记录的话，那么 DNS 就闪亮登场了。
+
+目前 DNS 的设计采用的是分布式、层次数据库结构，**DNS 是应用层协议，基于 UDP 协议之上，端口为 53** 。
+
+![TCP/IP 各层协议概览](https://oss.javaguide.cn/github/javaguide/cs-basics/network/network-protocol-overview.png)
+
+DNS 服务器自底向上可以依次分为以下几个层级(所有 DNS 服务器都属于以下四个类别之一):
+
+- 根 DNS 服务器。根 DNS 服务器提供 TLD 服务器的 IP 地址。目前世界上只有 13 组根服务器，我国境内目前仍没有根服务器。
+- 顶级域 DNS 服务器（TLD 服务器）。顶级域是指域名的后缀，如`com`、`org`、`net`和`edu`等。国家也有自己的顶级域，如`uk`、`fr`和`ca`。TLD 服务器提供了权威 DNS 服务器的 IP 地址。
+- 权威 DNS 服务器。在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。
+- 本地 DNS 服务器。每个 ISP（互联网服务提供商）都有一个自己的本地 DNS 服务器。当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 层次结构中。严格说来，不属于 DNS 层级结构。
+
+## DNS 工作流程
+
+以下图为例，介绍 DNS 的查询解析过程。DNS 的查询解析过程分为两种模式：
+
+- **迭代**
+- **递归**
+
+下图是实践中常采用的方式，从请求主机到本地 DNS 服务器的查询是递归的，其余的查询时迭代的。
+
+![](https://oss.javaguide.cn/github/javaguide/cs-basics/network/DNS-process.png)
+
+现在，主机`cis.poly.edu`想知道`gaia.cs.umass.edu`的 IP 地址。假设主机`cis.poly.edu`的本地 DNS 服务器为`dns.poly.edu`，并且`gaia.cs.umass.edu`的权威 DNS 服务器为`dns.cs.umass.edu`。
+
+1. 首先，主机`cis.poly.edu`向本地 DNS 服务器`dns.poly.edu`发送一个 DNS 请求，该查询报文包含被转换的域名`gaia.cs.umass.edu`。
+2. 本地 DNS 服务器`dns.poly.edu`检查本机缓存，发现并无记录，也不知道`gaia.cs.umass.edu`的 IP 地址该在何处，不得不向根服务器发送请求。
+3. 根服务器注意到请求报文中含有`edu`顶级域，因此告诉本地 DNS，你可以向`edu`的 TLD DNS 发送请求，因为目标域名的 IP 地址很可能在那里。
+4. 本地 DNS 获取到了`edu`的 TLD DNS 服务器地址，向其发送请求，询问`gaia.cs.umass.edu`的 IP 地址。
+5. `edu`的 TLD DNS 服务器仍不清楚请求域名的 IP 地址，但是它注意到该域名有`umass.edu`前缀，因此返回告知本地 DNS，`umass.edu`的权威服务器可能记录了目标域名的 IP 地址。
+6. 这一次，本地 DNS 将请求发送给权威 DNS 服务器`dns.cs.umass.edu`。
+7. 终于，由于`gaia.cs.umass.edu`向权威 DNS 服务器备案过，在这里有它的 IP 地址记录，权威 DNS 成功地将 IP 地址返回给本地 DNS。
+8. 最后，本地 DNS 获取到了目标域名的 IP 地址，将其返回给请求主机。
+
+除了迭代式查询，还有一种递归式查询如下图，具体过程和上述类似，只是顺序有所不同。
+
+![](https://oss.javaguide.cn/github/javaguide/cs-basics/network/DNS-process2.png)
+
+另外，DNS 的缓存位于本地 DNS 服务器。由于全世界的根服务器甚少，只有 400 多台，分为 13 组，且顶级域的数量也在一个可数的范围内，因此本地 DNS 通常已经缓存了很多 TLD DNS 服务器，所以在实际查找过程中，无需访问根服务器。根服务器通常是被跳过的，不请求的。
+
+## DNS 报文格式
+
+DNS 的报文格式如下图所示：
+
+![](https://oss.javaguide.cn/github/javaguide/cs-basics/network/DNS-packet.png)
+
+DNS 报文分为查询和回答报文，两种形式的报文结构相同。
+
+- 标识符。16 比特，用于标识该查询。这个标识符会被复制到对查询的回答报文中，以便让客户用它来匹配发送的请求和接收到的回答。
+- 标志。1 比特的”查询/回答“标识位，`0`表示查询报文，`1`表示回答报文；1 比特的”权威的“标志位（当某 DNS 服务器是所请求名字的权威 DNS 服务器时，且是回答报文，使用”权威的“标志）；1 比特的”希望递归“标志位，显式地要求执行递归查询；1 比特的”递归可用“标志位，用于回答报文中，表示 DNS 服务器支持递归查询。
+- 问题数、回答 RR 数、权威 RR 数、附加 RR 数。分别指示了后面 4 类数据区域出现的数量。
+- 问题区域。包含正在被查询的主机名字，以及正被询问的问题类型。
+- 回答区域。包含了对最初请求的名字的资源记录。**在回答报文的回答区域中可以包含多条 RR，因此一个主机名能够有多个 IP 地址。**
+- 权威区域。包含了其他权威服务器的记录。
+- 附加区域。包含了其他有帮助的记录。
+
+## DNS 记录
+
+DNS 服务器在响应查询时，需要查询自己的数据库，数据库中的条目被称为**资源记录(Resource Record，RR)**。RR 提供了主机名到 IP 地址的映射。RR 是一个包含了`Name`, `Value`, `Type`, `TTL`四个字段的四元组。
+
+![](https://oss.javaguide.cn/github/javaguide/cs-basics/network/20210506174303797.png)
+
+`TTL`是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。
+
+`Name`和`Value`字段的取值取决于`Type`：
+
+![](https://oss.javaguide.cn/github/javaguide/cs-basics/network/20210506170307897.png)
+
+- 如果`Type=A`，则`Name`是主机名信息，`Value` 是该主机名对应的 IP 地址。这样的 RR 记录了一条主机名到 IP 地址的映射。
+- 如果 `Type=AAAA` （与 `A` 记录非常相似），唯一的区别是 A 记录使用的是 IPv4，而 `AAAA` 记录使用的是 IPv6。
+- 如果`Type=CNAME` (Canonical Name Record,真实名称记录) ，则`Value`是别名为`Name`的主机对应的规范主机名。`Value`值才是规范主机名。`CNAME` 记录将一个主机名映射到另一个主机名。`CNAME` 记录用于为现有的 `A` 记录创建别名。下文有示例。
+- 如果`Type=NS`，则`Name`是个域，而`Value`是个知道如何获得该域中主机 IP 地址的权威 DNS 服务器的主机名。通常这样的 RR 是由 TLD 服务器发布的。
+- 如果`Type=MX` ，则`Value`是个别名为`Name`的邮件服务器的规范主机名。既然有了 `MX` 记录，那么邮件服务器可以和其他服务器使用相同的别名。为了获得邮件服务器的规范主机名，需要请求 `MX` 记录；为了获得其他服务器的规范主机名，需要请求 `CNAME` 记录。
+
+`CNAME`记录总是指向另一则域名，而非 IP 地址。假设有下述 DNS zone：
+
+```
+NAME                    TYPE   VALUE
+--------------------------------------------------
+bar.example.com.        CNAME  foo.example.com.
+foo.example.com.        A      192.0.2.23
+```
+
+当用户查询 `bar.example.com` 的时候，DNS Server 实际返回的是 `foo.example.com` 的 IP 地址。
+
+## 参考
+
+- DNS 服务器类型：https://www.cloudflare.com/zh-cn/learning/dns/dns-server-types/
+- DNS Message Resource Record Field Formats：http://www.tcpipguide.com/free/t_DNSMessageResourceRecordFieldFormats-2.htm
+- Understanding Different Types of Record in DNS Server：https://www.mustbegeek.com/understanding-different-types-of-record-in-dns-server/

docs/cs-basics/network/other-network-questions.md

@@ -19,7 +19,16 @@ tag:
 
 ### 应用层有哪些常见的协议？
 
-[应用层常见协议总结（应用层）](./application-layer-protocol.md) 
+- **HTTP（超文本传输协议）** ：基于 TCP协议，是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。
+- **SMTP（简单邮件传输(发送)协议）** ：基于 TCP 协议，是一种用于发送电子邮件的协议。注意⚠️：SMTP协议只负责邮件的发送，而不是接收。要从邮件服务器接收邮件，需要使用POP3或IMAP协议。
+- **POP3/IMAP（邮件接收的协议）** ：基于 TCP 协议，两者都是负责邮件接收的协议。IMAP协议是比POP3更新的协议，它在功能和性能上都更加强大。IMAP支持邮件搜索、标记、分类、归档等高级功能，而且可以在多个设备之间同步邮件状态。几乎所有现代电子邮件客户端和服务器都支持 IMAP。
+- **FTP（文件传输协议）** : 基于 TCP 协议，是一种用于在计算机之间传输文件的协议，可以屏蔽操作系统和文件存储方式。注意⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。建议在传输敏感数据时使用更安全的协议，如SFTP。
+- **Telnet（远程登陆协议）** ：基于 TCP 协议，用于通过一个终端登陆到其他服务器。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet，而是使用一种称为SSH的非常安全的网络传输协议的主要原因。
+- **SSH（安全的网络传输协议）** ：基于  TCP 协议，通过加密和认证机制实现安全的访问和文件传输等业务
+- **RTP（实时传输协议）**：通常基于 UDP 协议，但也支持 TCP 协议。它提供了端到端的实时传输数据的功能，但不包含资源预留存、不保证实时传输质量，这些功能由 WebRTC 实现。
+- **DNS（域名管理系统）**: 基于 UDP 协议，用于解决域名和 IP 地址的映射问题。
+
+关于这些协议的详细介绍请看 [应用层常见协议总结（应用层）](./application-layer-protocol.md)  这篇文章。
 
 ## TCP 与 UDP
 
@@ -134,24 +143,84 @@ HTTP 状态码用于描述 HTTP 请求的结果，比如2xx 就代表请求被
 
 关于 HTTP 状态码更详细的总结，可以看我写的这篇文章：[HTTP 常见状态码总结（应用层）](./http-status-codes.md)。
 
+### HTTP Header 中常见的字段有哪些？
+
+| 请求头字段名        | 说明                                                         | 示例                                                         |
+| :------------------ | :----------------------------------------------------------- | :----------------------------------------------------------- |
+| Accept              | 能够接受的回应内容类型（Content-Types）。                    | Accept: text/plain                                           |
+| Accept-Charset      | 能够接受的字符集                                             | Accept-Charset: utf-8                                        |
+| Accept-Datetime     | 能够接受的按照时间来表示的版本                               | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT               |
+| Accept-Encoding     | 能够接受的编码方式列表。参考HTTP压缩。                       | Accept-Encoding: gzip, deflate                               |
+| Accept-Language     | 能够接受的回应内容的自然语言列表。                           | Accept-Language: en-US                                       |
+| Authorization       | 用于超文本传输协议的认证的认证信息                           | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==            |
+| Cache-Control       | 用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令 | Cache-Control: no-cache                                      |
+| Connection          | 该浏览器想要优先使用的连接类型                               | Connection: keep-alive Connection: Upgrade                   |
+| Content-Length      | 以 八位字节数组 （8位的字节）表示的请求体的长度              | Content-Length: 348                                          |
+| Content-MD5         | 请求体的内容的二进制 MD5 散列值，以 Base64 编码的结果        | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==                        |
+| Content-Type        | 请求体的 多媒体类型 （用于POST和PUT请求中）                  | Content-Type: application/x-www-form-urlencoded              |
+| Cookie              | 之前由服务器通过 Set- Cookie （下文详述）发送的一个 超文本传输协议Cookie | Cookie: $Version=1; Skin=new;                                |
+| Date                | 发送该消息的日期和时间(按照 RFC 7231 中定义的"超文本传输协议日期"格式来发送) | Date: Tue, 15 Nov 1994 08:12:31 GMT                          |
+| Expect              | 表明客户端要求服务器做出特定的行为                           | Expect: 100-continue                                         |
+| From                | 发起此请求的用户的邮件地址                                   | From: [user@example.com](mailto:user@example.com)            |
+| Host                | 服务器的域名(用于虚拟主机 )，以及服务器所监听的传输控制协议端口号。如果所请求的端口是对应的服务的标准端口，则端口号可被省略。 | Host: en.wikipedia.org:80                                    |
+| If-Match            | 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要作用时，用作像 PUT 这样的方法中，仅当从用户上次更新某个资源以来，该资源未被修改的情况下，才更新该资源。 | If-Match: “737060cd8c284d8af7ad3082f209582d”                 |
+| If-Modified-Since   | 允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ） | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT             |
+| If-None-Match       | 允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ） | If-None-Match: “737060cd8c284d8af7ad3082f209582d”            |
+| If-Range            | 如果该实体未被修改过，则向我发送我所缺少的那一个或多个部分；否则，发送整个新的实体 | If-Range: “737060cd8c284d8af7ad3082f209582d”                 |
+| If-Unmodified-Since | 仅当该实体自某个特定时间已来未被修改的情况下，才发送回应。   | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT           |
+| Max-Forwards        | 限制该消息可被代理及网关转发的次数。                         | Max-Forwards: 10                                             |
+| Origin              | 发起一个针对 跨来源资源共享 的请求。                         | Origin: [http://www.example-social-network.com](http://www.example-social-network.com/) |
+| Pragma              | 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生多种效果。 | Pragma: no-cache                                             |
+| Proxy-Authorization | 用来向代理进行认证的认证信息。                               | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==      |
+| Range               | 仅请求某个实体的一部分。字节偏移以0开始。参见字节服务。      | Range: bytes=500-999                                         |
+| Referer             | 表示浏览器所访问的前一个页面，正是那个页面上的某个链接将浏览器带到了当前所请求的这个页面。 | Referer: [http://en.wikipedia.org/wiki/Main_Page](https://en.wikipedia.org/wiki/Main_Page) |
+| TE                  | 浏览器预期接受的传输编码方式：可使用回应协议头 Transfer-Encoding 字段中的值； | TE: trailers, deflate                                        |
+| Upgrade             | 要求服务器升级到另一个协议。                                 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11               |
+| User-Agent          | 浏览器的浏览器身份标识字符串                                 | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0 |
+| Via                 | 向服务器告知，这个请求是由哪些代理发出的。                   | Via: 1.0 fred, 1.1 example.com (Apache/1.1)                  |
+| Warning             | 一个一般性的警告，告知，在实体内容体中可能存在错误。         | Warning: 199 Miscellaneous warning                           |
+
 ### HTTP 和 HTTPS 有什么区别？（重要）
 
+![HTTP 和 HTTPS 对比](https://oss.javaguide.cn/github/javaguide/cs-basics/network/http-vs-https.png)
+
 - **端口号** ：HTTP 默认是 80，HTTPS 默认是 443。
 - **URL 前缀** ：HTTP 的 URL 前缀是 `http://`，HTTPS 的 URL 前缀是 `https://`。
 - **安全性和资源消耗** ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
+- **SEO（搜索引擎优化）** ：搜索引擎通常会更青睐使用HTTPS协议的网站，因为HTTPS能够提供更高的安全性和用户隐私保护。使用HTTPS协议的网站在搜索结果中可能会被优先显示，从而对SEO产生影响。
 
 关于 HTTP 和 HTTPS 更详细的对比总结，可以看我写的这篇文章：[HTTP vs HTTPS（应用层）](./http&https.md) 。
 
 ### HTTP 1.0 和 HTTP 1.1 有什么区别？
 
+![HTTP 1.0 和 HTTP 1.1 对比](https://oss.javaguide.cn/github/javaguide/cs-basics/network/http1.0-vs-http1.1.png)
+
 - **连接方式** : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
 - **状态响应码** : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。
-- **缓存处理** : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
-- **带宽优化及网络连接的使用** :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
-- **Host头处理** : HTTP/1.1在请求头中加入了`Host`字段。
+- **缓存机制** : 在 HTTP1.0 中主要使用 Header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
+- **带宽** ：HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
+- **Host 头（Host Header）处理** :HTTP 1.1 引入了 Host 头字段，允许在同一 IP 地址上托管多个域名，从而支持虚拟主机的功能。而 HTTP 1.0 没有 Host 头字段，无法实现虚拟主机。
 
 关于 HTTP 1.0 和 HTTP 1.1 更详细的对比总结，可以看我写的这篇文章：[HTTP 1.0 vs HTTP 1.1（应用层）](./http1.0&http1.1.md) 。
 
+### HTTP 1.1 和 HTTP 2.0 有什么区别？
+
+![HTTP 1.1 和 HTTP 2.0 对比](https://oss.javaguide.cn/github/javaguide/cs-basics/network/http1.1-vs-http2.0.png)
+
+- **IO多路复用（Multiplexing）** ：HTTP2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP 1.1 中长链接的升级版本）。HTTP1.1 则使用串行方式，每个请求和响应都需要独立的连接。这使得 HTTP2 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
+- **二进制帧（Binary Frames）** ：HTTP2 使用二进制帧进行数据传输，而 HTTP1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
+- **头部压缩（Header Compression）** ：HTTP 1.1支持`Body`压缩，`Header`不支持压缩。HTTP2.0 支持对`Header`压缩，减少了网络开销。
+- **服务器推送（Server Push）**：HTTP 2.0  支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP1.1 需要客户端自己发送请求来获取相关资源。
+
+### HTTP 2.0 和 HTTP 3.0 有什么区别？
+
+![HTTP 2.0 和 HTTP 3.0 对比](https://oss.javaguide.cn/github/javaguide/cs-basics/network/http2.0-vs-http3.0.png)
+
+- **传输协议** ：HTTP 2.0 是基于 TCP 协议实现的，HTTP 3.0是基于 UDP协议实现的。
+- **传输方式** ：HTTP3.0 新增了 QUIC（Quick UDP Internet Connections） 协议来实现可靠的传输，提供与TLS/SSL相当的安全性，具有较低的连接和传输延迟。
+- **错误恢复** ：HTTP3 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP2 则需要依赖于 TCP 的错误恢复机制。
+- **握手过程** ：HTTP3 的握手过程相较于 HTTP2 更加简洁，减少了握手次数和握手延迟，从而提高了连接建立速度和性能。
+
 ### HTTP 是不保存状态的协议, 如何保存用户状态?
 
 HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。
@@ -169,6 +238,81 @@ HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说
 
 URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。
 
+### Cookie 和 Session 有什么区别？
+
+准确点来说，这个问题属于认证授权的范畴，你可以在 [认证授权基础概念详解](https://javaguide.cn/system-design/security/basis-of-authority-certification.html) 这篇文章中找到详细的答案。
+
+## PING
+
+### PING命令的作用是什么？
+
+PING命令是一种常用的网络诊断工具，经常用来测试网络中主机之间的连通性和网络延迟。
+
+这里简单举一个例子，我们来 PING 一下百度。
+
+```bash
+# 发送4个PING请求数据包到 www.baidu.com
+❯ ping -c 4 www.baidu.com
+
+PING www.a.shifen.com (14.119.104.189): 56 data bytes
+64 bytes from 14.119.104.189: icmp_seq=0 ttl=54 time=27.867 ms
+64 bytes from 14.119.104.189: icmp_seq=1 ttl=54 time=28.732 ms
+64 bytes from 14.119.104.189: icmp_seq=2 ttl=54 time=27.571 ms
+64 bytes from 14.119.104.189: icmp_seq=3 ttl=54 time=27.581 ms
+
+--- www.a.shifen.com ping statistics ---
+4 packets transmitted, 4 packets received, 0.0% packet loss
+round-trip min/avg/max/stddev = 27.571/27.938/28.732/0.474 ms
+```
+
+PING 命令的输出结果通常包括以下几部分信息：
+
+1. **ICMP Echo Request（请求报文）信息** ：序列号、TTL（Time to Live）值。
+2. **目标主机的域名或IP地址** ：输出结果的第一行。
+3. **往返时间（RTT，Round-Trip Time）** ：从发送 ICMP Echo Request（请求报文）到接收到ICMP Echo Reply（响应报文）的总时间，用来衡量网络连接的延迟。
+4. **统计结果（Statistics）** ：包括发送的ICMP请求数据包数量、接收到的ICMP响应数据包数量、丢包率、往返时间（RTT）的最小、平均、最大和标准偏差值。
+
+如果PING对应的目标主机无法得到正确的响应，则表明这两个主机之间的连通性存在问题。如果往返时间（RTT）过高，则表明网络延迟过高。
+
+### PING命令的工作原理是什么？
+
+PING 基于 **ICMP（Internet Control Message Protocol，互联网控制报文协议）**，其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。
+
+ICMP 报文中包含了类型字段，用于标识 ICMP 报文类型。ICMP 报文的类型有很多种，但大致可以分为两类：
+
+- **查询报文类型** ：向目标主机发送请求并期望得到响应。
+- **差错报文类型** ：向源主机发送错误信息，用于报告网络中的错误情况。
+
+PING 用到的ICMP Echo Request（类型为 8 ） 和 ICMP Echo Reply（类型为 0） 属于查询报文类型 。
+
+- PING命令会向目标主机发送ICMP Echo Request。
+- 如果两个主机的连通性正常，目标主机会返回一个对应的ICMP Echo Reply。
+
+## DNS
+
+### DNS 的作用是什么？
+
+DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是**域名和 IP 地址的映射问题**。
+
+![DNS:域名系统](https://oss.javaguide.cn/github/javaguide/cs-basics/network/dns-overview.png)
+
+在实际使用中，有一种情况下，浏览器是可以不必动用 DNS 就可以获知域名和 IP 地址的映射的。浏览器在本地会维护一个`hosts`列表，一般来说浏览器要先查看要访问的域名是否在`hosts`列表中，如果有的话，直接提取对应的 IP 地址记录，就好了。如果本地`hosts`列表内没有域名-IP 对应记录的话，那么 DNS 就闪亮登场了。
+
+目前 DNS 的设计采用的是分布式、层次数据库结构，**DNS 是应用层协议，基于 UDP 协议之上，端口为 53** 。
+
+### DNS 服务器有哪些？
+
+DNS 服务器自底向上可以依次分为以下几个层级(所有 DNS 服务器都属于以下四个类别之一):
+
+- 根 DNS 服务器。根 DNS 服务器提供 TLD 服务器的 IP 地址。目前世界上只有 13 组根服务器，我国境内目前仍没有根服务器。
+- 顶级域 DNS 服务器（TLD 服务器）。顶级域是指域名的后缀，如`com`、`org`、`net`和`edu`等。国家也有自己的顶级域，如`uk`、`fr`和`ca`。TLD 服务器提供了权威 DNS 服务器的 IP 地址。
+- 权威 DNS 服务器。在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。
+- 本地 DNS 服务器。每个 ISP（互联网服务提供商）都有一个自己的本地 DNS 服务器。当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 层次结构中。严格说来，不属于 DNS 层级结构
+
+### DNS 解析的过程是什么样的？
+
+整个过程的步骤比较多，我单独写了一篇文章详细介绍：[DNS 域名系统详解（应用层）](./dns.md) 。
+
 ## ARP
 
 ### 什么是 Mac 地址？
@@ -198,3 +342,10 @@ ARP 协议，全称 **地址解析协议（Address Resolution Protocol）**，
 ## 复习建议
 
 非常推荐大家看一下 《图解 HTTP》 这本书，这本书页数不多，但是内容很是充实，不管是用来系统的掌握网络方面的一些知识还是说纯粹为了应付面试都有很大帮助。下面的一些文章只是参考。大二学习这门课程的时候，我们使用的教材是 《计算机网络第七版》（谢希仁编著），不推荐大家看这本教材，书非常厚而且知识偏理论，不确定大家能不能心平气和的读完。
+
+## 参考
+
+- 《图解 HTTP》
+- 《计算机网络自顶向下方法》（第七版）
+- 详解 HTTP2.0 及 HTTPS 协议：https://juejin.cn/post/7034668672262242318
+- HTTP 请求头字段大全| HTTP Request Headers：https://www.flysnow.org/tools/table/http-request-headers/

docs/cs-basics/operating-system/operating-system-basic-questions-01.md

@@ -228,7 +228,7 @@ PCB 主要包含下面几部分的内容：
 
 - **创建状态(new)** ：进程正在被创建，尚未到就绪状态。
 - **就绪状态(ready)** ：进程已处于准备运行状态，即进程获得了除了处理器之外的一切所需资源，一旦得到处理器资源(处理器分配的时间片)即可运行。
-- **运行状态(running)** ：进程正在处理器上上运行(单核 CPU 下任意时刻只有一个进程处于运行状态)。
+- **运行状态(running)** ：进程正在处理器上运行(单核 CPU 下任意时刻只有一个进程处于运行状态)。
 - **阻塞状态(waiting)** ：又称为等待状态，进程正在等待某一事件而暂停运行如等待某资源为可用或等待 IO 操作完成。即使处理器空闲，该进程也不能运行。
 - **结束状态(terminated)** ：进程正在从系统中消失。可能是进程正常结束或其他原因中断退出运行。
 

docs/home.md

@@ -152,6 +152,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
 - [HTTP vs HTTPS（应用层）](./cs-basics/network/http&https.md)
 - [HTTP 1.0 vs HTTP 1.1（应用层）](./cs-basics/network/http1.0&http1.1.md)
 - [HTTP 常见状态码（应用层）](./cs-basics/network/http-status-codes.md)
+- [DNS 域名系统详解（应用层）](./cs-basics/network/dns.md)
 - [TCP 三次握手和四次挥手（传输层）](./cs-basics/network/tcp-connection-and-disconnection.md)
 - [TCP 传输可靠性保障（传输层）](./cs-basics/network/tcp-reliability-guarantee.md)
 - [ARP 协议详解(网络层)](./cs-basics/network/arp.md)

docs/java/jvm/memory-area.md

@@ -226,9 +226,7 @@ String bb = "ab";
 System.out.println(aa==bb);// true
 ```
 
-HotSpot 虚拟机中字符串常量池的实现是 `src/hotspot/share/classfile/stringTable.cpp` ,`StringTable` 本质上就是一个`HashSet<String>` ,容量为 `StringTableSize`（可以通过 `-XX:StringTableSize` 参数来设置）。
-
-**`StringTable` 中保存的是字符串对象的引用，字符串对象的引用指向堆中的字符串对象。**
+HotSpot 虚拟机中字符串常量池的实现是 `src/hotspot/share/classfile/stringTable.cpp` ,`StringTable` 可以简单理解为一个固定大小的`HashTable` ，容量为 `StringTableSize`（可以通过 `-XX:StringTableSize` 参数来设置），保存的是字符串（key）和 字符串对象的引用（value）的映射关系，字符串对象的引用指向堆中的字符串对象。
 
 JDK1.7 之前，字符串常量池存放在永久代。JDK1.7 字符串常量池和静态变量从永久代移动了 Java 堆中。