Merge branch 'main' into docs

Author: Mister-Hope

README.md

@@ -141,10 +141,10 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
 
 **重要知识点详解** ：
 
-- [OSI 和 TCP/IP 网络分层模型详解（基础）](./docs/cs-basics/network/osi&tcp-ip-model.md)
+- [OSI 和 TCP/IP 网络分层模型详解（基础）](./docs/cs-basics/network/osi-and-tcp-ip-model.md)
 - [应用层常见协议总结（应用层）](./docs/cs-basics/network/application-layer-protocol.md)
-- [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 vs HTTPS（应用层）](./docs/cs-basics/network/http-vs-https.md)
+- [HTTP 1.0 vs HTTP 1.1（应用层）](./docs/cs-basics/network/http1.0-vs-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)
@@ -300,7 +300,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
 
 - [认证授权基础概念详解](./docs/system-design/security/basis-of-authority-certification.md)
 - [JWT 基础概念详解](./docs/system-design/security/jwt-intro.md)
-- [JWT 优缺点分析以及常见问题解决方案](./docs/system-design/security/advantages&disadvantages-of-jwt.md)
+- [JWT 优缺点分析以及常见问题解决方案](./docs/system-design/security/advantages-and-disadvantages-of-jwt.md)
 - [SSO 单点登录详解](./docs/system-design/security/sso-intro.md)
 - [权限系统设计详解](./docs/system-design/security/design-of-authority-system.md)
 
@@ -324,10 +324,10 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
 
 ### 理论&算法&协议
 
-- [CAP 理论和 BASE 理论详解](./docs/distributed-system/theorem&algorithm&protocol/cap&base-theorem.md)
-- [Paxos 算法详解](./docs/distributed-system/theorem&algorithm&protocol/paxos-algorithm.md)
-- [Raft 算法详解](./docs/distributed-system/theorem&algorithm&protocol/raft-algorithm.md)
-- [Gossip 协议详解](./docs/distributed-system/theorem&algorithm&protocol/gossip-protocl.md)
+- [CAP 理论和 BASE 理论详解](./docs/distributed-system/protocol/cap-and-base-theorem.md)
+- [Paxos 算法详解](./docs/distributed-system/protocol/paxos-algorithm.md)
+- [Raft 算法详解](./docs/distributed-system/protocol/raft-algorithm.md)
+- [Gossip 协议详解](./docs/distributed-system/protocol/gossip-protocl.md)
 
 ### API 网关
 

docs/.vuepress/sidebar/high-quality-technical-articles.ts

@@ -19,7 +19,7 @@ export const highQualityTechnicalArticles = arraySidebar([
     collapsible: false,
     children: [
       "four-year-work-in-tencent-summary",
-      "two-years-of-back-end-develop--experience-in-didi&toutiao",
+      "two-years-of-back-end-develop--experience-in-didi-and-toutiao",
       "8-years-programmer-work-summary",
       "huawei-od-275-days",
     ],

docs/.vuepress/sidebar/index.ts

@@ -22,7 +22,6 @@ export default sidebar({
     {
       text: "面试准备",
       icon: "interview",
-      collapsible: true,
       prefix: "interview-preparation/",
       children: [
         "teach-you-how-to-prepare-for-the-interview-hand-in-hand",
@@ -174,10 +173,10 @@ export default sidebar({
               icon: "star",
               collapsible: true,
               children: [
-                "osi&tcp-ip-model",
+                "osi-and-tcp-ip-model",
                 "application-layer-protocol",
-                "http&https",
-                "http1.0&http1.1",
+                "http-vs-https",
+                "http1.0-vs-http1.1",
                 "http-status-codes",
                 "dns",
                 "tcp-connection-and-disconnection",
@@ -418,7 +417,7 @@ export default sidebar({
           children: [
             "basis-of-authority-certification",
             "jwt-intro",
-            "advantages&disadvantages-of-jwt",
+            "advantages-and-disadvantages-of-jwt",
             "sso-intro",
             "design-of-authority-system",
             "sentive-words-filter",
@@ -440,9 +439,9 @@ export default sidebar({
         {
           text: "理论&算法&协议",
           icon: "suanfaku",
-          prefix: "theorem&algorithm&protocol/",
+          prefix: "protocol/",
           children: [
-            "cap&base-theorem",
+            "cap-and-base-theorem",
             "paxos-algorithm",
             "raft-algorithm",
             "gossip-protocl",

docs/.vuepress/styles/palette.scss

@@ -1,4 +1,3 @@
 $theme-color: #2980b9;
-$sidebar-width: 20rem;
-$sidebar-mobile-width: 16rem;
-$content-width: 60em;
+// $sidebar-width: 20rem;
+// $sidebar-mobile-width: 16rem;

docs/cs-basics/network/http&https.md renamed to docs/cs-basics/network/http-vs-https.md

@@ -61,15 +61,15 @@ SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密
 >
 > 这样，通信信息就不会被其他人截获了，这依赖于私钥的保密性。
 
-![](./images/http&https/public-key-cryptography.png)
+![](./images/http-vs-https/public-key-cryptography.png)
 
 非对称加密的公钥和私钥需要采用一种复杂的数学机制生成（密码学认为，为了较高的安全性，尽量不要自己创造加密方案）。公私钥对的生成算法依赖于单向陷门函数。
 
 > 单向函数：已知单向函数 f，给定任意一个输入 x，易计算输出 y=f(x)；而给定一个输出 y，假设存在 f(x)=y，很难根据 f 来计算出 x。
 >
 > 单向陷门函数：一个较弱的单向函数。已知单向陷门函数 f，陷门 h，给定任意一个输入 x，易计算出输出 y=f(x;h)；而给定一个输出 y，假设存在 f(x;h)=y，很难根据 f 来计算出 x，但可以根据 f 和 h 来推导出 x。
 
-![单向函数](./images/http&https/OWF.png)
+![单向函数](./images/http-vs-https/OWF.png)
 
 上图就是一个单向函数（不是单项陷门函数），假设有一个绝世秘籍，任何知道了这个秘籍的人都可以把苹果汁榨成苹果，那么这个秘籍就是“陷门”了吧。
 
@@ -81,7 +81,7 @@ SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密
 
 > 对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。
 
-![](./images/http&https/symmetric-encryption.png)
+![](./images/http-vs-https/symmetric-encryption.png)
 
 对称加密的密钥生成代价比公私钥对的生成代价低得多，那么有的人会问了，为什么 SSL/TLS 还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。
 
@@ -99,7 +99,7 @@ SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐
 >
 > 同样的，S 公钥即使做加密，也难以避免这种信任性问题，C 被 AS 拐跑了！
 
-![](./images/http&https/attack1.png)
+![](./images/http-vs-https/attack1.png)
 
 为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的**电子签名**（见下节）。
 
@@ -117,7 +117,7 @@ SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐
 >
 > 客户端对证书数据（包含服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。
 
-![](./images/http&https/digital-signature.png)
+![](./images/http-vs-https/digital-signature.png)
 
 总结来说，带有证书的公钥传输机制如下：
 
@@ -127,7 +127,7 @@ SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐
 4. C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
 5. 如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）。
 
-![](./images/http&https/public-key-transmission.png)
+![](./images/http-vs-https/public-key-transmission.png)
 
 对于数字签名，我这里讲的比较简单，如果你没有搞清楚的话，强烈推荐你看看[数字签名及数字证书原理](https://www.bilibili.com/video/BV18N411X7ty/)这个视频，这是我看过最清晰的讲解。
 

docs/cs-basics/network/http1.0&http1.1.md renamed to docs/cs-basics/network/http1.0-vs-http1.1.md

@@ -29,9 +29,9 @@ HTTP/1.0 提供的缓存机制非常简单。服务器端使用`Expires`标签
 
 如果服务器判断`If-Modified-Since`时间后，资源被修改过，则返回给客户端一个`200 OK`的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。
 
-![HTTP1.0cache1](./images/http&https/HTTP1.0cache1.png)
+![HTTP1.0cache1](./images/http-vs-https/HTTP1.0cache1.png)
 
-![HTTP1.0cache2](./images/http&https/HTTP1.0cache2.png)
+![HTTP1.0cache2](./images/http-vs-https/HTTP1.0cache2.png)
 
 ### HTTP/1.1
 
@@ -78,9 +78,9 @@ HTTP/1.1 引入了范围请求（range request）机制，以避免带宽的浪
 
 HTTP/1.1 中新加入了状态码`100`。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码`100`可以作为指示请求是否会被正常响应，过程如下图：
 
-![HTTP1.1continue1](./images/http&https/HTTP1.1continue1.png)
+![HTTP1.1continue1](./images/http-vs-https/HTTP1.1continue1.png)
 
-![HTTP1.1continue2](./images/http&https/HTTP1.1continue2.png)
+![HTTP1.1continue2](./images/http-vs-https/HTTP1.1continue2.png)
 
 然而在 HTTP/1.0 中，并没有`100 (Continue)`状态码，要想触发这一机制，可以发送一个`Expect`头部，其中包含一个`100-continue`的值。