style(network): 网络文章格式规范化与 README 标题同步

- 统一标点：半角冒号/逗号改全角，英文括号改中文括号
- 中英文间距：行内代码与中文之间补空格
- 列表格式：冒号前空格清理，粗体关键词后冒号统一
- 专有名词大小写修正（Hadoop、Docker、DDoS 等）
- README 网络部分改用完整标题，侧边栏新增 TIME_WAIT 入口

Author: Snailclimb

docs/.vuepress/sidebar/cs-basics.ts

@@ -26,11 +26,11 @@ export const csBasics = [
         icon: ICONS.STAR,
         children: [
           {
-            text: "OSI 和 TCP/IP 网络分层模型详解",
+            text: "OSI 七层模型与 TCP/IP 四层模型详解",
             link: "osi-and-tcp-ip-model",
           },
           {
-            text: "访问网页的全过程",
+            text: "从输入 URL 到页面展示到底发生了什么？",
             link: "the-whole-process-of-accessing-web-pages",
           },
         ],

docs/cs-basics/README.md

@@ -20,13 +20,13 @@ head:
 
 **面试题**：
 
-- [计算机网络常见知识点&面试题总结(上)](./network/other-network-questions.md)
-- [计算机网络常见知识点&面试题总结(下)](./network/other-network-questions2.md)
+- [计算机网络常见面试题总结(上)](./network/other-network-questions.md)
+- [计算机网络常见面试题总结(下)](./network/other-network-questions2.md)
 
 **重点**：
 
-- [OSI 和 TCP/IP 网络分层模型详解（基础）](./network/osi-and-tcp-ip-model.md)
-- [访问网页的全过程（知识串联）](./network/the-whole-process-of-accessing-web-pages.md)
+- [OSI 七层模型与 TCP/IP 四层模型详解](./network/osi-and-tcp-ip-model.md)
+- [从输入 URL 到页面展示到底发生了什么？](./network/the-whole-process-of-accessing-web-pages.md)
 
 **应用层**：
 
@@ -46,7 +46,7 @@ head:
 
 **网络层**：
 
-- [ARP 协议详解（网络层）](./network/arp.md)
+- [ARP 协议详解(网络层)](./network/arp.md)
 - [NAT 协议详解（网络层）](./network/nat.md)
 
 **安全**：
@@ -55,10 +55,10 @@ head:
 
 ## 操作系统
 
-- [操作系统常见知识点&面试题总结(上)](./operating-system/operating-system-basic-questions-01.md)
-- [操作系统常见知识点&面试题总结(下)](./operating-system/operating-system-basic-questions-02.md)
+- [操作系统常见面试题总结(上)](./operating-system/operating-system-basic-questions-01.md)
+- [操作系统常见面试题总结(下)](./operating-system/operating-system-basic-questions-02.md)
 - **Linux**：
-  - [后端程序员必备的 Linux 基础知识总结](./operating-system/linux-intro.md)
+  - [Linux 基础知识总结](./operating-system/linux-intro.md)
   - [Shell 编程基础知识总结](./operating-system/shell-intro.md)
 
 ## 数据结构
@@ -74,9 +74,9 @@ head:
 
 **常见算法问题总结**：
 
-- [经典算法题推荐](./algorithms/classical-algorithm-problems-recommendations.md)
-- [常见数据结构对应的 LeetCode 题目推荐](./algorithms/common-data-structures-leetcode-recommendations.md)
-- [几道常见的字符串算法题总结](./algorithms/string-algorithm-problems.md)
-- [几道常见的链表算法题总结](./algorithms/linkedlist-algorithm-problems.md)
-- [剑指 offer 部分编程题](./algorithms/the-sword-refers-to-offer.md)
-- [十大经典排序算法](./algorithms/10-classical-sorting-algorithms.md)
+- [经典算法思想总结（含LeetCode题目推荐）](./algorithms/classical-algorithm-problems-recommendations.md)
+- [常见数据结构经典LeetCode题目推荐](./algorithms/common-data-structures-leetcode-recommendations.md)
+- [几道常见的字符串算法题](./algorithms/string-algorithm-problems.md)
+- [几道常见的链表算法题](./algorithms/linkedlist-algorithm-problems.md)
+- [剑指offer部分编程题](./algorithms/the-sword-refers-to-offer.md)
+- [十大经典排序算法总结](./algorithms/10-classical-sorting-algorithms.md)

docs/cs-basics/network/computer-network-xiexiren-summary.md

@@ -33,7 +33,7 @@ HTTP 协议，全称超文本传输协议（Hypertext Transfer Protocol）。顾
 
 ### HTTP 协议通信过程
 
-HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：
+HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80。通信过程主要如下：
 
 1. 服务器在 80 端口等待客户的请求。
 2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
@@ -49,7 +49,7 @@ HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认
 
 ### HTTPS 协议介绍
 
-HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443.
+HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443。
 
 HTTPS 中，TLS 握手完成后，通信数据使用对称加密算法（如 AES-128-GCM 或 AES-256-GCM）保护，密钥通过非对称加密（如 RSA-2048/4096 或 ECDH）在握手阶段协商生成。早期 SSL 使用的 40 比特密钥因强度不足已被废弃，现代 TLS 要求对称密钥至少 128 比特。
 
@@ -59,19 +59,19 @@ HTTPS 中，TLS 握手完成后，通信数据使用对称加密算法（如 AES
 
 ## HTTPS 的核心—SSL/TLS 协议
 
-HTTPS 之所以能达到较高的安全性要求，就是结合了 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。接下来重点介绍一下 SSL/TLS 的工作原理。
+HTTPS 之所以能达到较高的安全性要求，就是结合 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。接下来重点介绍 SSL/TLS 的工作原理。
 
 ### SSL 和 TLS 的区别？
 
 **SSL 和 TLS 没有太大的区别。**
 
-SSL 指安全套接字协议（Secure Sockets Layer），首次发布于 1996 年（SSL 3.0）。SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，**新版本被命名为 TLS 1.0**。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混称为 SSL/TLS。目前 SSL 已完全废弃，TLS 1.2 和 TLS 1.3 是现代 HTTPS 的实际标准。
+SSL 指安全套接层协议（Secure Sockets Layer），首次发布于 1996 年（SSL 3.0）。SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，**新版本被命名为 TLS 1.0**。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混称为 SSL/TLS。目前 SSL 已完全废弃，TLS 1.2 和 TLS 1.3 是现代 HTTPS 的实际标准。
 
 ### SSL/TLS 的工作原理
 
 #### 非对称加密
 
-SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密钥——一个公钥，一个私钥。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。可以设想一个场景，
+SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密钥：一个公钥，一个私钥。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。可以设想一个场景：
 
 > 在某个自助邮局，每个通信信道都是一个邮箱，每一个邮箱所有者都在旁边立了一个牌子，上面挂着一把钥匙：这是我的公钥，发送者请将信件放入我的邮箱，并用公钥锁好。
 >
@@ -101,11 +101,11 @@ SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密
 
 ![](./images/http-vs-https/symmetric-encryption.png)
 
-对称加密的密钥生成代价比公私钥对的生成代价低得多，那么有的人会问了，为什么 SSL/TLS 还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。
+对称加密的密钥生成代价比公私钥对的生成代价低得多。那么有的人会问：为什么 SSL/TLS 还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥对信息进行对称加密，即可保证传输消息的保密性。
 
 #### 公钥传输的信赖性
 
-SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐患，设想一个下面的场景：
+SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐患。设想下面的场景：
 
 > 客户端 C 和服务器 S 想要使用 SSL/TLS 通信，由上述 SSL/TLS 通信原理，C 需要先知道 S 的公钥，而 S 公钥的唯一获取途径，就是把 S 公钥在网络信道中传输。要注意网络信道通信中有几个前提：
 >

docs/cs-basics/network/http-vs-https.md

@@ -37,23 +37,23 @@ HTTP/1.0 仅定义了 16 种状态码。HTTP/1.1 中新加入了大量的状态
 
 HTTP/1.0 提供的缓存机制非常简单。服务器端使用`Expires`标签来标志（时间）一个响应体，在`Expires`标志时间内的请求，都会获得该响应体缓存。服务器端在初次返回给客户端的响应体中，有一个`Last-Modified`标签，该标签标记了被请求资源在服务器端的最后一次修改。在请求头中，使用`If-Modified-Since`标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之后，我要请求的资源是否有被修改过？”通常情况下，请求头中的`If-Modified-Since`的值即为上一次获得该资源时，响应体中的`Last-Modified`的值。
 
-如果服务器接收到了请求头，并判断`If-Modified-Since`时间后，资源确实没有修改过，则返回给客户端一个`304 not modified`响应头，表示”缓冲可用，你从浏览器里拿吧！”。
+如果服务器接收到了请求头，并判断`If-Modified-Since`时间后，资源确实没有修改过，则返回给客户端一个 `304 Not Modified` 响应头，表示”缓冲可用，你从浏览器里拿吧！”。
 
-如果服务器判断`If-Modified-Since`时间后，资源被修改过，则返回给客户端一个`200 OK`的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。
+如果服务器判断 `If-Modified-Since` 时间后，资源被修改过，则返回给客户端一个 `200 OK` 的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。
 
 ![HTTP1.0cache1](./images/http-vs-https/HTTP1.0cache1.png)
 
 ![HTTP1.0cache2](./images/http-vs-https/HTTP1.0cache2.png)
 
 ### HTTP/1.1
 
-HTTP/1.1 的缓存机制在 HTTP/1.0 的基础上，大大增加了灵活性和扩展性。基本工作原理和 HTTP/1.0 保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是`Cache-Control`，详见 MDN Web 文档 [Cache-Control](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control).
+HTTP/1.1 的缓存机制在 HTTP/1.0 的基础上，大大增加了灵活性和扩展性。基本工作原理和 HTTP/1.0 保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是 `Cache-Control`，详见 MDN Web 文档 [Cache-Control](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control)。
 
 ## 连接方式
 
 **HTTP/1.0 默认使用短连接** ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 TCP 连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。
 
-**为了解决 HTTP/1.0 存在的资源浪费的问题， HTTP/1.1 优化为默认长连接模式 。** 采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该 TCP 连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
+**为了解决 HTTP/1.0 存在的资源浪费的问题，HTTP/1.1 优化为默认长连接模式。** 采用长连接模式的请求报文会通知服务端：”我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该 TCP 连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
 
 如果 TCP 连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）还会支持超时时间的时间。在超时时间之内没有新的请求达到，TCP 连接才会被关闭。
 
@@ -65,7 +65,7 @@ HTTP/1.1 的缓存机制在 HTTP/1.0 的基础上，大大增加了灵活性和
 
 ## Host 头处理
 
-域名系统（DNS）允许多个主机名绑定到同一个 IP 地址上，但是 HTTP/1.0 并没有考虑这个问题，假设我们有一个资源 URL 是<http://example1.org/home.html，HTTP/1.0> 的请求报文中，将会请求的是`GET /home.html HTTP/1.0`.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。
+域名系统（DNS）允许多个主机名绑定到同一个 IP 地址上，但是 HTTP/1.0 并没有考虑这个问题。假设我们有一个资源 URL 是 `http://example1.org/home.html`，HTTP/1.0 的请求报文中，将会请求的是 `GET /home.html HTTP/1.0`，也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。
 
 因此，HTTP/1.1 在请求头中加入了`Host`字段。加入`Host`字段的报文头部将会是:
 
@@ -86,7 +86,7 @@ HTTP/1.1 引入了范围请求（range request）机制，以避免带宽的浪
 
 一个典型的 HTTP/1.1 范围请求示例：
 
-```bash
+```http
 # 获取一个文件的前 1024 个字节
 GET /z4d4kWk.jpg HTTP/1.1
 Host: i.imgur.com
@@ -95,8 +95,7 @@ Range: bytes=0-1023
 
 `206 Partial Content` 响应：
 
-```bash
-
+```http
 HTTP/1.1 206 Partial Content
 Content-Range: bytes 0-1023/146515
 Content-Length: 1024
@@ -113,15 +112,15 @@ Content-Length: 1024
 
 客户端想要获取资源的第 0 到 499 字节以及第 1000 到 1499 字节：
 
-```bash
+```http
 GET /path/to/resource HTTP/1.1
 Host: example.com
 Range: bytes=0-499,1000-1499
 ```
 
 服务器端返回多个字节范围，每个范围的内容以分隔符分开：
 
-```bash
+```http
 HTTP/1.1 206 Partial Content
 Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
 Content-Length: 376
@@ -149,13 +148,13 @@ Content-Range: bytes 1000-1099/2000
 
 ### 状态码 100
 
-HTTP/1.1 中新加入了状态码`100`。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码`100`可以作为指示请求是否会被正常响应，过程如下图：
+HTTP/1.1 中新加入了状态码 `100`。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码 `100` 可以作为指示请求是否会被正常响应，过程如下图：
 
 ![HTTP1.1continue1](./images/http-vs-https/HTTP1.1continue1.png)
 
 ![HTTP1.1continue2](./images/http-vs-https/HTTP1.1continue2.png)
 
-然而在 HTTP/1.0 中，并没有`100 (Continue)`状态码，要想触发这一机制，可以发送一个`Expect`头部，其中包含一个`100-continue`的值。
+然而在 HTTP/1.0 中，并没有 `100 (Continue)` 状态码，要想触发这一机制，可以发送一个 `Expect` 头部，其中包含一个 `100-continue` 的值。
 
 ### 压缩
 
@@ -167,11 +166,11 @@ HTTP/1.0 包含了`Content-Encoding`头部，对消息进行端到端编码。HT
 
 ## 总结
 
-1. **连接方式** : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
-2. **状态响应码** : HTTP/1.1 中新加入了大量的状态码，光是错误响应状态码就新增了 24 种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。
-3. **缓存处理** : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
-4. **带宽优化及网络连接的使用** :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
-5. **Host 头处理** : HTTP/1.1 在请求头中加入了`Host`字段。
+1. **连接方式**：HTTP/1.0 为短连接，HTTP/1.1 支持长连接。
+2. **状态响应码**：HTTP/1.1 中新加入了大量的状态码，光是错误响应状态码就新增了 24 种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。
+3. **缓存处理**：在 HTTP/1.0 中主要使用 header 里的 `If-Modified-Since`、`Expires` 来作为缓存判断的标准，HTTP/1.1 则引入了更多的缓存控制策略，例如 `Entity Tag`、`If-Unmodified-Since`、`If-Match`、`If-None-Match` 等更多可供选择的缓存头来控制缓存策略。
+4. **带宽优化及网络连接的使用**：HTTP/1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP/1.1 则在请求头引入了 `Range` 头域，它允许只请求资源的某个部分，即返回码是 `206 (Partial Content)`，这样就方便了开发者自由选择以便于充分利用带宽和连接。
+5. **Host 头处理**：HTTP/1.1 在请求头中加入了 `Host` 字段。
 
 ## 参考资料