[docs update]网络部分重构

README.md

@@ -122,7 +122,10 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
 
 ### 网络
 
-1. [计算机网络常见面试题](docs/cs-basics/network/计算机网络常见面试题.md)
+1. [OSI 和 TCP/IP 网络分层模型详解（基础）](./docs/cs-basics/network/osi&tcp-ip-model.md)
+1. [HTTP vs HTTPS（应用层）](./docs/cs-basics/network/http&https.md)
+1. [HTTP 1.0 vs HTTP 1.1（应用层）](./docs/cs-basics/network/http1.0&http1.1.md)
+1. [计算机网络常见知识点&面试题（补充）](./docs/cs-basics/network/other-network-questions.md)
 2. [谢希仁老师的《计算机网络》内容总结](docs/cs-basics/network/谢希仁老师的《计算机网络》内容总结.md)
 
 ### 数据结构

docs/.vuepress/config.js

@@ -217,9 +217,10 @@ module.exports = config({
         title: "计算机基础", icon: "computer", prefix: "cs-basics/",
         children: [
           {
-            title: "计算机网络", prefix: "network/", icon: "network",
+            title: "网络", prefix: "network/", icon: "network",
             children: [
-              "计算机网络常见面试题", "谢希仁老师的《计算机网络》内容总结", "HTTPS中的TLS"
+              "osi&tcp-ip-model", "http&https", "http1.0&http1.1",
+              "other-network-questions"
             ],
           },
           {

docs/cs-basics/network/HTTPS中的TLS.md

@@ -1,124 +0,0 @@
----
-title: HTTPS中的TLS
-category: 计算机基础
-tag:
-  - 计算机网络
----
-
-# 1. SSL 与 TLS
-
-SSL：（Secure Socket Layer） 安全套接层，于 1994 年由网景公司设计，并于 1995 年发布了 3.0 版本  
-TLS：（Transport Layer Security）传输层安全性协议，是 IETF 在 SSL3.0 的基础上设计的协议  
-以下全部使用 TLS 来表示
-
-# 2. 从网络协议的角度理解 HTTPS
-
-![此图并不准确][1]  
-HTTP：HyperText Transfer Protocol 超文本传输协议  
-HTTPS：Hypertext Transfer Protocol Secure 超文本传输安全协议  
-TLS：位于 HTTP 和 TCP 之间的协议，其内部有 TLS握手协议、TLS记录协议  
-HTTPS 经由 HTTP 进行通信，但利用 TLS 来保证安全，即 HTTPS = HTTP + TLS
-
-# 3. 从密码学的角度理解 HTTPS
-
-HTTPS 使用 TLS 保证安全，这里的“安全”分两部分，一是传输内容加密、二是服务端的身份认证
-
-## 3.1. TLS 工作流程
-
-![此图并不准确][2]  
-此为服务端单向认证，还有客户端/服务端双向认证，流程类似，只不过客户端也有自己的证书，并发送给服务器进行验证
-
-## 3.2. 密码基础
-
-### 3.2.1. 伪随机数生成器
-
-为什么叫伪随机数，因为没有真正意义上的随机数，具体可以参考 Random/TheadLocalRandom  
-它的主要作用在于生成对称密码的秘钥、用于公钥密码生成秘钥对
-
-### 3.2.2. 消息认证码
-
-消息认证码主要用于验证消息的完整性与消息的认证，其中消息的认证指“消息来自正确的发送者”  
-
->消息认证码用于验证和认证，而不是加密  
-
-![消息认证码过程][3]  
-
-1. 发送者与接收者事先共享秘钥
-2. 发送者根据发送消息计算 MAC 值
-3. 发送者发送消息和 MAC 值  
-4. 接收者根据接收到的消息计算 MAC 值
-5. 接收者根据自己计算的 MAC 值与收到的 MAC 对比
-6. 如果对比成功，说明消息完整，并来自于正确的发送者
-
-### 3.2.3. 数字签名
-
-消息认证码的缺点在于**无法防止否认**，因为共享秘钥被 client、server 两端拥有，server 可以伪造 client 发送给自己的消息（自己给自己发送消息），为了解决这个问题，我们需要它们有各自的秘钥不被第二个知晓（这样也解决了共享秘钥的配送问题）  
-
-![数字签名过程][4]  
-
->数字签名和消息认证码都**不是为了加密**  
->可以将单向散列函数获取散列值的过程理解为使用 md5 摘要算法获取摘要的过程  
-
-使用自己的私钥对自己所认可的消息生成一个该消息专属的签名，这就是数字签名，表明我承认该消息来自自己  
-注意：**私钥用于加签，公钥用于解签，每个人都可以解签，查看消息的归属人**  
-
-### 3.2.4. 公钥密码
-
-公钥密码也叫非对称密码，由公钥和私钥组成，它最开始是为了解决秘钥的配送传输安全问题，即，我们不配送私钥，只配送公钥，私钥由本人保管    
-它与数字签名相反，公钥密码的私钥用于解密、公钥用于加密，每个人都可以用别人的公钥加密，但只有对应的私钥才能解开密文  
-client：明文 + 公钥 = 密文  
-server：密文 + 私钥 = 明文  
-注意：**公钥用于加密，私钥用于解密，只有私钥的归属者，才能查看消息的真正内容**   
-
-### 3.2.5. 证书
-
-证书：全称公钥证书（Public-Key Certificate, PKC）,里面保存着归属者的基本信息，以及证书过期时间、归属者的公钥，并由认证机构（Certification Authority, **CA**）施加数字签名，表明，某个认证机构认定该公钥的确属于此人  
-
->想象这个场景：你想在支付宝页面交易，你需要支付宝的公钥进行加密通信，于是你从百度上搜索关键字“支付宝公钥”，你获得了支什宝的公钥，这个时候，支什宝通过中间人攻击，让你访问到了他们支什宝的页面，最后你在这个支什宝页面完美的使用了支什宝的公钥完成了与支什宝的交易
->![证书过程][5]   
-
-在上面的场景中，你可以理解支付宝证书就是由支付宝的公钥、和给支付宝颁发证书的企业的数字签名组成  
-任何人都可以给自己或别人的公钥添加自己的数字签名，表明：我拿我的尊严担保，我的公钥/别人的公钥是真的，至于信不信那是另一回事了
-
-### 3.2.6. 密码小结
-
-| 密码 | 作用 | 组成 |
-| :-- | :-- | :-- |
-| 消息认证码 | 确认消息的完整、并对消息的来源认证 | 共享秘钥+消息的散列值 |
-| 数字签名   | 对消息的散列值签名 | 公钥+私钥+消息的散列值 |
-| 公钥密码   | 解决秘钥的配送问题 | 公钥+私钥+消息 |
-| 证书      | 解决公钥的归属问题 | 公钥密码中的公钥+数字签名 |
-
-## 3.3. TLS 使用的密码技术
-
-1. 伪随机数生成器：秘钥生成随机性，更难被猜测
-2. 对称密码：对称密码使用的秘钥就是由伪随机数生成，相较于非对称密码，效率更高
-3. 消息认证码：保证消息信息的完整性、以及验证消息信息的来源
-4. 公钥密码：证书技术使用的就是公钥密码
-5. 数字签名：验证证书的签名，确定由真实的某个 CA 颁发 
-6. 证书：解决公钥的真实归属问题，降低中间人攻击概率   
-
-## 3.4. TLS 总结
-
-TLS 是一系列密码工具的框架，作为框架，它也是非常的灵活，体现在每个工具套件它都可以替换，即：客户端与服务端之间协商密码套件，从而更难的被攻破，例如使用不同方式的对称密码，或者公钥密码、数字签名生成方式、单向散列函数技术的替换等
-
-# 4. RSA 简单示例
-
-RSA 是一种公钥密码算法，我们简单的走一遍它的加密解密过程  
-加密算法：密文 = (明文^E) mod N，其中公钥为{E,N}，即”求明文的E次方的对 N 的余数“  
-解密算法：明文 = (密文^D) mod N，其中秘钥为{D,N}，即”求密文的D次方的对 N 的余数“  
-例：我们已知公钥为{5,323}，私钥为{29,323}，明文为300，请写出加密和解密的过程：  
->加密：密文 = 123 ^ 5 mod 323 = 225  
->解密：明文 = 225 ^ 29 mod 323 = [[(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 5) mod 323] * [(225 ^ 4) mod 323]] mod 323 = (4 * 4 * 4 * 4 * 4 * 290) mod 323 = 123
-
-# 5. 参考
-
-1. SSL加密发生在哪里：<https://security.stackexchange.com/questions/19681/where-does-ssl-encryption-take-place>  
-2. TLS工作流程：<https://blog.csdn.net/ustccw/article/details/76691248>  
-3. 《图解密码技术》：<https://book.douban.com/subject/26822106/> 豆瓣评分 9.5
-
-[1]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/%E4%B8%83%E5%B1%82.png
-[2]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/tls%E6%B5%81%E7%A8%8B.png
-[3]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/%E6%B6%88%E6%81%AF%E8%AE%A4%E8%AF%81%E7%A0%81%E8%BF%87%E7%A8%8B.png
-[4]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/%E6%95%B0%E5%AD%97%E7%AD%BE%E5%90%8D%E8%BF%87%E7%A8%8B.png
-[5]: https://leran2deeplearnjavawebtech.oss-cn-beijing.aliyuncs.com/somephoto/dns%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB.png

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

@@ -0,0 +1,149 @@
+---
+title:  HTTP vs HTTPS（应用层）
+category: 计算机基础
+tag:
+  - 计算机网络
+---
+
+> 本文由  [SnailClimb](https://github.com/Snailclimb) 和 [csguide-dabai](https://github.com/csguide-dabai) （公众号“CS指南”作者）共同完成。
+
+## HTTP 协议
+
+### HTTP 协议介绍
+
+HTTP 协议，全称超文本传输协议（Hypertext Transfer Protocol）。顾名思义，HTTP 协议就是用来规范超文本的传输，超文本，也就是网络上的包括文本在内的各式各样的消，具体来说，主要是来规范浏览器和服务器端的行为的。
+
+并且，HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息），而且如果客户或服务器失效，会产生状态的不一致，解决这种不一致的代价更高。
+
+### HTTP 协议通信过程
+
+HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：
+
+1. 服务器在 80 端口等待客户的请求。
+2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
+3. 服务器接收来自浏览器的 TCP 连接。
+4. 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
+5. 关闭 TCP 连接。
+
+### HTTP 协议优点
+
+扩展性强、速度快、跨平台支持性好。
+
+## HTTPS 协议
+
+### HTTPS 协议介绍
+
+HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443.
+
+HTTPS 协议中，SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特。
+
+### HTTPS 协议优点
+
+保密性好、信任度高。
+
+## HTTPS 的核心—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 的工作原理
+
+#### 非对称加密
+
+SSL/TLS 的核心要素是**非对称加密**。非对称加密采用两个密钥——一个公钥，一个私钥。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。可以设想一个场景，
+
+> 在某个自助邮局，每个通信信道都是一个邮箱，每一个邮箱所有者都在旁边立了一个牌子，上面挂着一把钥匙：这是我的公钥，发送者请将信件放入我的邮箱，并用公钥锁好。
+>
+> 但是公钥只能加锁，并不能解锁。解锁只能由邮箱的所有者——因为只有他保存着私钥。
+>
+> 这样，通信信息就不会被其他人截获了，这依赖于私钥的保密性。
+
+![](./images/http&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)
+
+上图就是一个单向函数（不是单项陷门函数），假设有一个绝世秘籍，任何知道了这个秘籍的人都可以把苹果汁榨成苹果，那么这个秘籍就是“陷门”了吧。
+
+在这里，函数 f 的计算方法相当于公钥，陷门 h 相当于私钥。公钥 f 是公开的，任何人对已有输入，都可以用 f 加密，而要想根据加密信息还原出原信息，必须要有私钥才行。
+
+#### 对称加密
+
+使用 SSL/TLS 进行通信的双方需要使用非对称加密方案来通信，但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密。
+
+> 对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。
+
+![](./images/http&https/symmetric-encryption.png)
+
+对称加密的密钥生成代价比公私钥对的生成代价低得多，那么有的人会问了，为什么 SSL/TLS 还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。
+
+#### 公钥传输的信赖性
+
+SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐患，设想一个下面的场景：
+
+> 客户端 C 和服务器 S 想要使用 SSL/TLS 通信，由上述 SSL/TLS 通信原理，C 需要先知道 S 的公钥，而 S 公钥的唯一获取途径，就是把 S 公钥在网络信道中传输。要注意网络信道通信中有几个前提：
+>
+> 1. 任何人都可以捕获通信包
+> 2. 通信包的保密性由发送者设计
+> 3. 保密算法设计方案默认为公开，而（解密）密钥默认是安全的
+>
+> 因此，假设 S 公钥不做加密，在信道中传输，那么很有可能存在一个攻击者 A，发送给 C 一个诈包，假装是 S 公钥，其实是诱饵服务器 AS 的公钥。当 C 收获了 AS 的公钥（却以为是 S 的公钥），C 后续就会使用 AS 公钥对数据进行加密，并在公开信道传输，那么 A 将捕获这些加密包，用 AS 的私钥解密，就截获了 C 本要给 S 发送的内容，而 C 和 S 二人全然不知。
+>
+> 同样的，S 公钥即使做加密，也难以避免这种信任性问题，C 被 AS 拐跑了！
+
+![](./images/http&https/attack1.png)
+
+为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的**电子签名**（见下节）。
+
+当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
+
+#### 数字签名
+
+好，到这一小节，已经是 SSL/TLS 的尾声了。上一小节提到了数字签名，数字签名要解决的问题，是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖，就是靠数字签名技术。
+
+数字签名，是 CA 在给服务器颁发证书时，使用散列+加密的组合技术，在证书上盖个章，以此来提供验伪的功能。具体行为如下：
+
+> CA 知道服务器的公钥，对该公钥采用散列技术生成一个摘要。CA 使用 CA 私钥对该摘要进行加密，并附在证书下方，发送给服务器。
+>
+> 现在服务器将该证书发送给客户端，客户端需要验证该证书的身份。客户端找到第三方机构 CA，获知 CA 的公钥，并用 CA 公钥对证书的签名进行解密，获得了 CA 生成的摘要。
+>
+> 客户端对证书数据（也就是服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。
+
+![](./images/http&https/digital-signature.png)
+
+注意，验证身份的证书一定是由 CA 的公钥进行签名，而不能由发送者自己来签名。这是为了抵抗以下的攻击场景：
+
+> 攻击者使用某种手段，欺骗了客户端，将服务器的公钥替换为攻击者的诱饵公钥。
+>
+> 假使证书的签名使用的是服务器的私钥，那么客户端在解码的时候，将会使用假的服务器公钥（实则为诱饵公钥）。那么，如果该证书实则由攻击者（使用自己的私钥签名）发出，那么客户端就会成功验证（攻击者的）身份为真，从而信赖了证书中的公钥。
+>
+> 如果使用 CA 的私钥和公钥来对签名处理，则不会出现上述问题。
+
+总结来说，带有证书的公钥传输机制如下：
+
+1. 设有服务器 S，客户端 C，和第三方信赖机构 CA。
+2. S 信任 CA，CA 是知道 S 公钥的，S 向 CA 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
+3. S 获得 CA 颁发的证书，将该证书传递给 C。
+4. C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书山的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
+5. 如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）。
+
+![](./images/http&https/public-key-transmission.png)
+
+## 总结
+
+- **端口号** ：HTTP 默认是 80，HTTPS 默认是 443。
+- **UTL 前缀** ：HTTP 的 URL 前缀是 `http://`，HTTPS 的 URL 前缀是 `https://`。
+- **安全性和资源消耗** ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
+
+
+

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

@@ -0,0 +1,107 @@
+---
+title:  HTTP 1.0 vs HTTP 1.1（应用层）
+category: 计算机基础
+tag:
+  - 计算机网络
+---
+
+> 本文由  [SnailClimb](https://github.com/Snailclimb) 和 [csguide-dabai](https://github.com/csguide-dabai) （公众号“CS指南”作者）共同完成。
+
+这篇文章会从下面几个维度来对比 HTTP 1.0 和 HTTP 1.1：
+
+- 响应状态码
+- 缓存处理
+- 连接方式
+- Host头处理
+- 带宽优化
+
+## 响应状态码
+
+HTTP/1.0仅定义了16种状态码。HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。
+
+## 缓存处理
+
+缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络带宽，降低了用户接收信息的延迟。
+
+### HTTP/1.0
+
+HTTP/1.0提供的缓存机制非常简单。服务器端使用`Expires`标签来标志（时间）一个响应体，在`Expires`标志时间内的请求，都会获得该响应体缓存。服务器端在初次返回给客户端的响应体中，有一个`Last-Modified`标签，该标签标记了被请求资源在服务器端的最后一次修改。在请求头中，使用`If-Modified-Since`标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之前，我要请求的资源是否有被修改过？”通常情况下，请求头中的`If-Modified-Since`的值即为上一次获得该资源时，响应体中的`Last-Modified`的值。
+
+如果服务器接收到了请求头，并判断`If-Modified-Since`时间后，资源确实没有修改过，则返回给客户端一个`304 not modified`响应头，表示”缓冲可用，你从浏览器里拿吧！”。
+
+如果服务器判断`If-Modified-Since`时间后，资源被修改过，则返回给客户端一个`200 OK`的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。
+
+![HTTP1.0cache1](./images/http&https/HTTP1.0cache1.png)
+
+![HTTP1.0cache2](./images/http&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.0 默认使用短连接** ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。
+
+**为了解决 HTTP/1.0 存在的资源浪费的问题， HTTP/1.1 优化为默认长连接模式 。** 采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该TCP连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
+
+如果 TCP 连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）还会支持超时时间的时间。在超时时间之内没有新的请求达到，TCP 连接才会被关闭。
+
+有必要说明的是，HTTP/1.0仍提供了长连接选项，即在请求头中加入`Connection: Keep-alive`。同样的，在HTTP/1.1中，如果不希望使用长连接选项，也可以在请求头中加入`Connection: close`，这样会通知服务器端：“我不需要长连接，连接成功后即可关闭”。
+
+**HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。**
+
+**实现长连接需要客户端和服务端都支持长连接。**
+
+## Host头处理
+
+域名系统（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`字段的报文头部将会是:
+
+```
+GET /home.html HTTP/1.1
+Host: example1.org
+```
+
+这样，服务器端就可以确定客户端想要请求的真正的网址了。
+
+## 带宽优化
+
+### 范围请求
+
+HTTP/1.1引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1可以在请求中加入`Range`头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略`Range`头部，也可以返回若干`Range`响应。
+
+如果一个响应包含部分数据的话，那么将带有`206 (Partial Content)`状态码。该状态码的意义在于避免了HTTP/1.0代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。
+
+在范围响应中，`Content-Range`头部标志指示出了该数据块的偏移量和数据块的长度。
+
+### 状态码100
+
+HTTP/1.1中新加入了状态码`100`。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码`100`可以作为指示请求是否会被正常响应，过程如下图：
+
+![HTTP1.1continue1](./images/http&https/HTTP1.1continue1.png)
+
+![HTTP1.1continue2](./images/http&https/HTTP1.1continue2.png)
+
+然而在HTTP/1.0中，并没有`100 (Continue)`状态码，要想触发这一机制，可以发送一个`Expect`头部，其中包含一个`100-continue`的值。
+
+### 压缩
+
+许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。
+
+HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。
+
+HTTP/1.0包含了`Content-Encoding`头部，对消息进行端到端编码。HTTP/1.1加入了`Transfer-Encoding`头部，可以对消息进行逐跳传输编码。HTTP/1.1还加入了`Accept-Encoding`头部，是客户端用来指示他能处理什么样的内容编码。
+
+## 总结
+
+1. **连接方式** : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
+1. **状态响应码** : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，`100 (Continue)`——在请求大资源前的预热请求，`206 (Partial Content)`——范围请求的标识码，`409 (Conflict)`——请求与当前资源的规定冲突，`410 (Gone)`——资源已被永久转移，而且没有任何已知的转发地址。
+1. **缓存处理** : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
+1. **带宽优化及网络连接的使用** :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
+1. **Host头处理** : HTTP/1.1在请求头中加入了`Host`字段。
+
+## 参考资料
+
+[Key differences between HTTP/1.0 and HTTP/1.1](http://www.ra.ethz.ch/cdstore/www8/data/2136/pdf/pd1.pdf)

docs/cs-basics/network/images/network-layer/network-protocol-overview.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2021-12-27T12:18:49.363Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="BCO_bX0iVrMdmYNRiWAx" version="13.4.5" type="device"><diagram id="tmrIvn8UqugqhCCRZjQR" name="Page-1">7VzbcqM4EP0aVe0+eIs74hFjO0nVZCYzzu7M7ptsZJsdDF6sjO18/UogbC4icRIMsUNSlUDrAvQ53Wo1QkB1lturCK0Wt6GLfaBI7haoA6AosqWq9B+T7BKJZZmJYB55Lq90EIy9R8yFEpc+eC5e5yqSMPSJt8oLp2EQ4CnJyVAUhZt8tVno56+6QnNcEoynyC9Lv3suWSRSqJgH+TX25ov0yrJhJSVLlFbmT7JeIDfcZETqEKhOFIYkOVpuHewz5aV6SdqNKkr3NxbhgBzTwHDsx4FiP35XNv/0vvSvvvbgrsd7+YX8B/7AYAiBLQMbgqEJbA30bTDUQV8GUOHPQXapcqLwIXAx618Gan+z8Ager9CUlW4oHahsQZY+L56FAeH40jul557vO6EfRnFfqqtj6GpUviZR+BNnSqAyUQ2Dlsx9tGZwstZ7bbKup+HSm/LjslrSZ8QRwduMiKvpCodLTKIdrZKWanrShHPWUDmEmwMD5BTWRQZ9g8sQJ9183/UBF3rAoXkBTIoAJp1BY2kMJvqX4dUITAjD2VQEkzGFeDJrESbdbBsmVQATtSAHWHZsViNgDZqBaTbDxlQIk2taE0lq05qstmFKnXdG99ilXp+fhhFZhPMwQP7wIO0f0GEKO9T5FIYrrqx/MSE7Dgp6IGEesUpVrsOHaIqfuF8tqcfu8UmFR9hHxPuVH7lE2uNN70KP3soeKE2TckCZsAAAQdEcE96qgMH+Nl4Pi1ZlPbbErKc/BJbakPXAKRZbzwTqmt6m9Zh669YDz8t69HasB2rNWo8usB4T9AfAkuODPrCcZqwHyzSWM0XWYxmmitqM5KDctvUYApgMYFFcJHYAB8AegqHFXB11eMztmSxuaAQ4eYJkrIiAkyRjSO8i6SEXZrCfNgFtPeYzhXYHLWBbcWguAWg0A58k6RKeieGTB3QcfX/wWe3PrPTzGs0UpZ3hzCgicOrhrJUoA2898oM3Z8d/s+M/dH422GaKBjt+cgZYtgtl+phZF1ntB6Xn/WBISzyyS93gPEKuhw+OLQgDRgYXrRd7z5q4xDSDp9bkzZS8YoUJCFPgzeTizKo+d2admTtT23Fn+4GnIRsw5DZwoXBEux/Zk4xDY6cHjxaf1eDSOJ6JOp9SiFQ38G+zG0Hq7kJ81BEBs9BHKafyUanpHafrI+LiXMRaDJKzoW02mi2mfHT2K8xrxz/l4Dn5qQclTS+k3gRZHkVvMi5WXzRof0iQoNI6SC/yWh8SJEtqHSRBXrsDKQeS6AWrqjYKkiB9qhg+YRpaoSCHlvHfA3tnT9UbK8dmQcp88ptqAIVeXNJk/t/4PdaWxBTZW8cYsbqysdomBVRbpId8bx4kJT6ekbgkvQI9mrP/1/f3d+nt0MdL7igpKlGJdVrgSw5iHnnwyw6mFEVM5X2GnjdFvs0Llp7rxlGoiI35UKgY3GQzSz6aYL+Ppj/ncZvCXdTBJbPAJa3MJU1ApdOFN4KM4CuoJB3YJB0IpUjVnErLhLQqcWrwedxRSkwpXX1vlIKVlHK9X0JGHUeCZ4kp5FlVL6wyYEuxUswOFVVFUywFl9uOb6lrG6oASgDKd1/u1P3Jza2ddXpJ5/kLloi7F8dqyUvPXVNp20kkeN43aOeDG3spFhFMkBWpSWvXBIvyauXwW9j3Nv6PnohjnuNyR9rMCAXf2QiliWail8HZe+wHmHS0rYG2RtHXtk5b0dz8Mmg7Hl93nD0FZ422OVudqjj3EPfeqSni/+Cc1eU8Z01BTNssZwXL3i6Es38OOs7W4mel98bZ6jzeuXP2pqPsKVLPUPAao1nKXm6e0P7WcbaW0EB5b5y1LnYKduPcdumuU6S7WidtOie8QNJ+tu87ztYRzxZeIkLBkq5mOXu5rxW+3RzeIX4Z3432J/2rzgHXEukWP7sSrU+UG2WzcrFsHjjXHWvrYK1ZiHVbf92gnzp12x5p8/OzjrO1hQ2th7qXm7q9tZ0up1BHdFCYnlmChfHNcrY6dUsvgBhPFiha8w+UUlo8kFkPvoKnb14HnBQk/bKSIIyWyM+UbbjSWKEm8WWePiaUNr01+9AomJdbVq4uTko8yp6A9ynlViSTCAXrGe0p7ZPzRNqEkZu/3r6h661XPtolUi/wvbTNzA8RKXRU1LAzvqXlI2dQaXZiA3tmnXzeQo63tneVn7NkvWRLsmg5WvGDxvqMSZCg6zYf6xVXYLW+k4EhyEkJdoAxABwCW2eAwRGwG9pR6Yi9KY5CrmoDixMgKvpyqGFEy9OF8mfERwYbWTxOEH887Rcz5JBhTWjJxV0N2s6vGeWXb2Wb6tBKBK2/3TfKo5raoVWBVuuTULM8tmkdWhVoNTn9soMt+XQ1vv1meIu/kPR1NxpPhZsK02hDB3S+zfdDNXn80acHo2SHVGccBycOgEnhgNWq/OaFSV6fMzhz5gg+z+3Hv3GfBBEvZNdmOy3k46oa6KYW1mnppmCCAgV0k19ON3p62B872YrlsMu4Ovwf</diagram></mxfile>

docs/cs-basics/network/images/network-layer/transport-layer.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-02-25T07:27:08.543Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="4kxx-sCj15jdkqoPe9xM" version="13.4.5" type="device"><diagram id="IKFI_ZB9R2pDRW9sJrDE" name="Page-1">vZZdb5swFIZ/jS8rAQZiLhtKO22rNimb1lvHPoA1gyPjjKS/fqaYACGVNqnJFfg9xx/nfY4TEE6rw5Omu/JZcZAo8PgB4QcUBL7vxfbRKcdeSZJVLxRacJc0ChvxCk70nLoXHJpZolFKGrGbi0zVNTAz06jWqp2n5UrOd93RAhbChlG5VH8JbspeJcFq1D+BKMphZz9O+khFh2RXSVNSrtqJhDOEU62U6d+qQwqyM2/wpZ/3+E70dDANtfmXCZw9b799ecEvn8O82Xivd1+VunOr/KFy7wp2hzXHwQGt9jWHbhEf4XVbCgObHWVdtLXMrVaaSrpwrmrjINrj2LGQMlVS6be1MKdAcmb1xmj1GyaRmBHY5jZSSNp0zLrZJ8u6AVOVYG6bZe1DIaANHCaS8+IJVAVGH22KiwZe2E9xjRnFjlM7Yg5XrnvLKeLEJVLXWsVp7dF9++IA/AeMYAkjC9E6RfceyghaZyjBKIvQ2kdkycnWbeYw5ibXqoYzIk6iUhS1HTLrJlh93bko7B24d4FKcN5tc5H+2B/eWQPgc4QfgA1jPMe2WmILfLLEFl6LGl5Q+5F+v+otygkDdvEWbUkURt4tbxHxZjjiaInDH34Bpzjia+GIFjh+PlwXB4+A8PASDhJscRzfEEeY3A6HHY5/Xm+xyScAzv4C</diagram></mxfile>

docs/cs-basics/network/images/osi&tcp-ip-model/TCP-IP-4-model.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-02-25T06:26:44.060Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="fzicsnCHu9ESaRWQG5v1" version="13.4.5" type="device"><diagram id="0XygYSvObaGfJKnrfW3A" name="Page-1">7VzZbuM2FP0aAu1DCu0iHyVbmQJFgQIpujwVtEXL6mjxyPLEnq8vL0nJWujEznhJZzwDJBR33UOeu5AKsif59kNFV8tfy5hlyDLiLbKnyLJM0/D4L8jZyRxCfJmRVGmsKu0zntIvTGUaKneTxmzdq1iXZVanq37mvCwKNq97ebSqyud+tUWZ9Udd0YSNMp7mNBvn/pnG9VLmYsvf5//M0mTZjGx6RJbktKms3mS9pHH53MmyI2RPqrKsZSrfTlgGwmvkIts9HihtJ1axoj6mQfB79Aum4VOaT93oj392y60xfbBVN59ptlFvjCKMAhMFGEU+ChwUBihyUWgibKkXqXeNdKpyU8QMBjCRHT4v05o9regcSp/5euB5yzrPVPGiLGoFMJ8qf06zbFJmZSX6smOX4djh+eu6Kj+yTgm2Zrbn8ZIko2vAE1q34oSu52WezlV6LJfmHVlVs20nS8npAytzVlc7XkWVtqtPLVrfUc/P+yVgNrguO/B7Ko+qVZe0Xe+B4QmFzSk4WRqcXMCGOIAT/wmAXQUnyvBirsPJm2M2W9wQJw/fHCdbgxPfQxNEArGxHhGZXgenxYJ5cy1OsU9mhnFDnLBxc5ycQzgFBuAURojYV8IJz5kepxl2HfemOHk3x8nV4OSjcIqIKRIhIpPr4MRMrqF8HU7E8216S/1ErJvj5Glw8hDhwBiQwFMURCgisKv43oId5gMZXgU5c0ZNZumQMwwv4rOQPfS4E/7dEtHbazJfu/MwQQERFoeBsHcd/AzDNdhCj5855Zz9/vAzjdubjHgEoDmCib9e3ceiL+OiLNgAEJVFszQp+OOcC43x/BCElXLHKVAFeRrHMIwW/P3yMDT4nwEQ0x4CYo8BcTR4WBfDg4zwGG+b7wYPotkfV4WjGazLb0M0WBEHEEMAsQKRAGO8xFtsm9Z/qTJI/w3y/MlVT9OtEq942KmHg7Jdl5tqzl5aUGrCLO6FMMYQdETsakTc5FUso3X6uc8VOrmrEX4rUz7lFmHb6yPsmwPo5AupVt1AxaAj57WOalolrB51JJZB+9pfsTI0MRHLy2Bfrle06C0R79MG4jdcnYjNGIAYk9kPHncv+KT5+IZvtUli/ojUfjJg6TysxdqBRqa32vbLnhVCUOqBv6QKZ3T+MRHb9WEwqOW67VCD9I/7mfJUIn6Du4NFdAeDbRYIe5oniC8st4koaiML3IQTNhskHkH5Q3NeOVSVsfBqcQD9KGFx4Ut5qQHfJ9f1rIKuudC1EC5AiI4zWOUan5hbB9dkRE2M6V0x4nshuoEq8/1zEd2wo0sTnSZY9Qaia1iuobiD/HaY3I5htpbWWk4TZDaitbHX6UIYGzsdr+URIj1YRLghNOcJDuTsZwsO5HU4GdoIy4SkNUP08yiat5XbnG7lCOFQ9QyuUqfysEhOg3zbhGl6ZyLM4W7RBKfs65qQmiDinTBfJ0xsn4kwRx1dmjA10cgbEqbYqw9ruVmhpCirnGZnZVN/bxsOudOF6Ks0EoNQEFvLgiIwGzqCgwNg330RQdgX1iI3J7khGe1ZUHOe5cNP6FkUccMTrE4icggYqqGsHAh2Hx2z3Gn1DbSKNbFkW0cOl6NVTSz5TqtH0Co5F60OO7o0rWpCza/R6qzcAlumRSKJbVZWMaseePZxbvRZHfYL+OQiAcTpAu2FRlMUdpxzyaBhhyZfYEcCBExkz4+C0ceefFunQ8Cq+diqHp+Wfl+BgLMRsD/YfZqjH9u/KgGPTw7uBHwEARP3TAQ86ujSBDw+mrgDfgTgpnGuGPe4pwtD3kjkDvmpkJ8r2jfu6dKQv+Fc4wUz6xXn9JA/O7J51BSgvnYKR3cEZgdubidI82VsozhgQoGFhME8UnWkyXXKdRX9MYgj6vCiiXB1pWMrrifBuUok7k9EYggfmvBxweSyhFX3wiEMBnMKy+sXFlh4GjvPEz6vo65oQB0Pha5yxrsmIBYzJBhmspcPUe753mKTePQx+oYNuYzOWBa2dvxwxv3rJc4U/p/L/3YHtHDzuKarOwh6l/7YguZptpPNZJXmp0fzlaho2+JOOUtKxgs26ajocKMlyz4zWIUntKFVSrNT6q9WGWvfn6u9vPz3lDl2X+zrGq93+aw8ZepZOmMV162lWBG0WJ/QdsUXyoLyxcJbzk9oxzdwVa7LBaiKHeW74RQ404omaVG2szWS2QnNn1nxaUOLHchKTENuxzf28IUVJ7df17JJfVKjND9xlDRfb4qvfy344KVaHe4HMHhYsypd9Pf0xWMsrTIXZkIoDu2I1SjqR6GNXYgfc5XYjXZjrlHtRplr7QUXNLYMmwxvKHcCKWBuYDEN2bxrXESizndxLnipixS6m2XXjZ+4bzhXv+vPu/6868+7/vwf6M/xkbDOmx26rLKOPBLmzd0XzxZGhxV3TXiEJrSbc7vWldTcKbyyKjziikxfeK98KlLykrTeNVJLKhqnbO+cKzRjul62H5/IJdB8vW2fR9Ym7rvt2k9PdaI28cVkrbud8k3IerCutR9HaWV9uXU9vqNgv1M2usLHHLojy+tGrMY3CJzvFw7dzcgzwcEf93+xQh5M7P/uhx39Bw==</diagram></mxfile>

docs/cs-basics/network/images/osi&tcp-ip-model/application-layer.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-01-11T02:36:21.755Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="0H9U1Wz2i3VyUxEKUyq8" version="13.4.5" type="device"><diagram id="ox_IyTXRnZNLjcFnBTdz" name="Page-1">5Zhbb5swFMc/jR8rYQzGPAaaLFPVaRKT9uyAuawGZ8Rpkn362eCEa6VVapJJVaTE/p/jS87v2MYAFJbHLzXd5s8iYRzYVnIE6BHYNoQWVj9aObWK73utkNVFYpw6ISr+MCNaRt0XCdsNHKUQXBbboRiLqmKxHGi0rsVh6JYKPhx1SzM2EaKY8qn6s0hk3qrE9jp9zYosP48Msd9aSnp2Nv9kl9NEHHoSWgIU1kLItlQeQ8Z18M5xadut3rBeJlazSv5Lg234dHplx+Al/lU4NHjKTnb9gNpeXinfmz9sJitP5wjUYl8lTHcCAQoOeSFZtKWxth4Uc6XlsuTGnIpKGohqOqpecB4KLuqmL5RQRtJY6TtZixfWs+CYsE2qLBmnO81Mt76ETHcdi7KITdnMmtWSHd8MB7wEWWUnEyWT9Um5mAa25bRNTGI6xHA6dJgdz2Rv3kOMXONITWpll7676KuCAfAOGM4UxtIFwQL4Dlh6+ntBGgUCMuWkQiGHMIZBrkTFRkSMRHmRVaoaq9AxpQc6sIVaAwtjKIsk0cPM0u/ywxolAPoYUgihASnXmpKyIZmScq4Fyp2AWv/48f2qKyclMYtnV86GuI5r3XLlIGvIw5/ygOddr88DX4sHnvBYXRtHmtrzOBK8wS6+IQ4Ehziwd28c3gTH4zq8Lo/EZSRx5ngQe4PwLXk4cHiwuHfnQaY8vkVXxcGgAuLN4fCxh+gtcbguHC4P+944/AmO6PkTnR7ecLvynHvzOO+fPSBfnxef5vxw/BEQfHcgcLpCovVn2bAcPDrP7/54ZU9w6FsIccEiBEsHBCFQl3qtrECgCqtGWYQRWGJAQkBa46P2sjHXl5RNrUqZbALWKT24+Pde34sbbA+7httCOUC8PXbGro//8irE6YbxgMYvWaOPB+8SEmJT76Vd0HyaPiWVhdBjP6DxRv0R+/Ho8dGd24/JTLrB96ebqnbvOxpb760RWv4F</diagram></mxfile>

docs/cs-basics/network/images/osi&tcp-ip-model/nerwork-layer.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-01-11T03:08:09.434Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="wZkdwQbGlyahQdMlLp3v" version="13.4.5" type="device"><diagram id="aLP9Q2JBGdJELPBJHqNY" name="Page-1">5Zhdb5swFIZ/jS8jYQzGXAZK2knrWjXTJu3OgCGoBqfEWdL9+hlwwmelVSrJpCoXsd/jL85zjo0ByM+PtyXdbu5FzDgwjfgI0A0wTQgNrP4q5bVRXNdphLTMYt2oFdbZH6ZFQ6v7LGa7XkMpBJfZti9GoihYJHsaLUtx6DdLBO/PuqUpGwnriPKx+jOL5aZRiem0+h3L0s1pZojdxpLTU2P9JLsNjcWhI6EAIL8UQjal/OgzXjnv5Jem3+oN63lhJSvkv3QI7n5Yd1+tPHnJ//x62C/iYHe70KP8pnyvH1gvVr6ePFCKfRGzahAIkHfYZJKttzSqrAfFXGkbmXNtTkQhNUS1HFXPOPcFF2U9FoopI0mk9J0sxTPrWHBEWJgoS8rprmJW9T67rBo6EnkW6bJeNSslO77pDnh2sopOJnImy1fVRHcwDavpogPTIprTocVsOTp6Nx3EyNYNqQ6t9Dx2631V0ADeAcMcwwgc4N0AF9YFD7g+CGzgQUDGnJQrZB9G38mFKNiAiJYoz9JCVSPlOqZ0r3JspnJgqQ15FsfVNJP02/gwBgGAPoYUQqhHyjbGpExIxqSsuUChEagvj7PmTUIiFk3mTUhsyzYumTfI6NNwxzTgac/r0sBz0bBGNL4tv8+LI0nMaRwxDrGNL4gDwT4O7Fwbhz3CsXyaNztim5HYmsJBzBDhS+KwYP9Usa+OA4/3Kv9+5t0qYfiN9HDc0LjkbmXbsJ8e5rV5OCMeTzMfHgyqBHGmcLjYQfSS6WE6/d3Ksa6Ng4xweLefBoflDnDga+NwRzge1o+rT8MDDw7zq79bnd4uencSGxAbLNVVxAKeD9SFvlJWwFOFVa0s/TUIMCA+II3xpmplYl5dUMJSlVJZe6xVOnTxy766E9fcFrsa3FI1gHh7bI3tGP/lNYjTkHGPRs9prQ8nbyMSYl3vxJ1X/+oxJZWZqOZeoOGx+RHb8eDl0Z7ajslEvMH3x5uqtt86alvnixEK/gI=</diagram></mxfile>

docs/cs-basics/network/images/osi&tcp-ip-model/network-interface-layer.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-01-11T03:13:25.100Z" agent="5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/13.4.5 Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36" etag="IKo_p9QaQrGGghVbgDv6" version="13.4.5" type="device"><diagram id="FvOr2f2zJKBByRSDsAu0" name="Page-1">5ZdNj5swEIZ/jY8rYQzGHIGQblXtoc2h6qlywCFoHZwSp0n213cMToDASl1pk61UIUXmHX9lnpmxQSTZHD/VfLt+UrmQyHXyIyIz5LoBxfBrhFMrYHhapajL3GqdsChfhBUdq+7LXOwGHbVSUpfboZipqhKZHmi8rtVh2G2l5HDVLS/ESFhkXI7V72Wu163K3KDTH0VZrM8rYxq2lg0/d7b/ZLfmuTr0JJIiktRK6ba1OSZCGued/dKOm79ivWysFpX+mwHh/uVH+ONLhANcPJ5mn79++zl7sLP85nJv/7DdrD6dPVCrfZULMwlGJD6sSy0WW54Z6wGYg7bWG2nNK1VpCxG2A++llImSqm7mIjkXbJWBvtO1ehY9C82YWK7AUki+M8zM6IvLzNSZ2pSZbdtdi1qL46vuwBcnQ3QKtRG6PkEXO8B1vHaIjUyPWU6HDrMX0FZb9xAT33bkNrSKy9yd96FhAbwBhjuGkQYonqEQN40YhQlKKWIpinyU+ojNUURGwMAnekhl6O1KVeIKjZW4LIsKXjPwoQA9Nh4uIRkia9iUeW6WmQyDLlCcq0gg74OMEDJA5jtjZC5mY2TerYiREbFk8RTBVMnspnm0YpnIJvNoyXzPd+6ZR8QZQgnHUPC5Bvah0FtB8UdQnqLktmXNFyz3pnAwd0kovSMODw/Lmh98NA46UdV8FAcoSlEaotBDYWiqGlQyKMHQiKGwxbdNn5Wg0+mTB+HSuWf6+GTIi5KP5sUmeHnm8GnPnMhDUdSdS7fEJDAkVjCFKaQB4fdMq8tRYzEF7kdjCifTCuiEQIc1+TU3DciyeN4kWpNx/wkvgq94TVwV7svrvKErYAyYJU2CJYZQe6kDeOm8UaJk0dz4EsRa48z0cqk0N7xlDa1CNx7rlB5d+mtvvi4abg+7BhxcThxMt8fO2M3xT94jJV8KGfPsuWj068W7iMTUvvfiLm6eZk7NdanM2g/kur6/xy3oKt58byLe2ES84bfHG7x2X42NrfftTdI/</diagram></mxfile>

docs/cs-basics/network/osi&tcp-ip-model.md

@@ -0,0 +1,116 @@
+---
+title:  OSI 和 TCP/IP 网络分层模型详解（基础）
+category: 计算机基础
+tag:
+  - 计算机网络
+---
+
+> 本文由  [SnailClimb](https://github.com/Snailclimb) 和 [csguide-dabai](https://github.com/csguide-dabai) （公众号“CS指南”作者）共同完成。
+
+## OSI 七层模型
+
+**OSI 七层模型** 是国际标准化组织提出一个网络分层模型，其大体结构以及每一层提供的功能如下图所示：
+
+![osi七层模型](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/osi%E4%B8%83%E5%B1%82%E6%A8%A1%E5%9E%8B.png)
+
+每一层都专注做一件事情，并且每一层都需要使用下一层提供的功能比如传输层需要使用网络层提供的路有和寻址功能，这样传输层才知道把数据传输到哪里去。
+
+**OSI 的七层体系结构概念清楚，理论也很完整，但是它比较复杂而且不实用，而且有些功能在多个层中重复出现。**
+
+上面这种图可能比较抽象，再来一个比较生动的图片。下面这个图片是我在国外的一个网站上看到的，非常赞！
+
+![osi七层模型2](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/osi七层模型2.png)
+
+**既然 OSI 七层模型这么厉害，为什么干不过 TCP/IP 四 层模型呢？**
+
+的确，OSI 七层模型当时一直被一些大公司甚至一些国家政府支持。这样的背景下，为什么会失败呢？我觉得主要有下面几方面原因：
+
+1. OSI 的专家缺乏实际经验，他们在完成 OSI 标准时缺乏商业驱动力
+2. OSI 的协议实现起来过分复杂，而且运行效率很低
+3. OSI 制定标准的周期太长，因而使得按 OSI 标准生产的设备无法及时进入市场（20 世纪 90 年代初期，虽然整套的 OSI 国际标准都已经制定出来，但基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了）
+4. OSI 的层次划分不太合理，有些功能在多个层次中重复出现。
+
+OSI 七层模型虽然失败了，但是却提供了很多不错的理论基础。为了更好地去了解网络分层，OSI 七层模型还是非常有必要学习的。
+
+最后再分享一个关于 OSI 七层模型非常不错的总结图片！
+
+![](./images/osi&tcp-ip-model/osi-model-detail.png)
+
+## TCP/IP 四层模型
+
+**TCP/IP 四层模型** 是目前被广泛采用的一种模型,我们可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成：
+
+1. 应用层
+2. 传输层
+3. 网络层
+4. 网络接口层
+
+需要注意的是，我们并不能将 TCP/IP 四层模型 和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来，如下图所示：
+
+![TCP-IP-4-model](./images/osi&tcp-ip-model/TCP-IP-4-model.png)
+
+### 应用层（Application layer）
+
+**应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。** 我们把应用层交互的数据单元称为报文。
+
+![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/5971-2-7I1-20220111095024771-20220111201807861.png)
+
+应用层协议定义了网络通信规则，对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如支持 Web 应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。
+
+![application-layer](./images/osi&tcp-ip-model/application-layer.png)
+
+### 传输层（Transport layer）
+
+**传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务。** 应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
+
+**运输层主要使用以下两种协议：**
+
+1. **传输控制协议 TCP**（Transmisson Control Protocol）--提供**面向连接**的，**可靠的**数据传输服务。
+2. **用户数据协议 UDP**（User Datagram Protocol）--提供**无连接**的，尽最大努力的数据传输服务（**不保证数据传输的可靠性**）。
+
+![transport-layer](./images/osi&tcp-ip-model/transport-layer.png)
+
+### 网络层（Network layer）
+
+**网络层负责为分组交换网上的不同主机提供通信服务。** 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。
+
+注意 ⚠️：**不要把运输层的“用户数据报 UDP”和网络层的“IP 数据报”弄混**。
+
+**网络层的还有一个任务就是选择合适的路由，使源主机运输层所传下来的分株，能通过网络层中的路由器找到目的主机。**
+
+这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称。
+
+互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做**网际层**或**IP 层**。
+
+![](./images/osi&tcp-ip-model/nerwork-layer.png)
+
+### 网络接口层（Network interface layer）
+
+我们可以把网络接口层看作是数据链路层和物理层的合体。
+
+1. 数据链路层(data link layer)通常简称为链路层（ 两台主机之间的数据传输，总是在一段一段的链路上传送的）。**数据链路层的作用是将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。**
+2. **物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异**
+
+![network-interface-layer](./images/osi&tcp-ip-model/network-interface-layer.png)
+
+## 为什么网络要分层？
+
+在这篇文章的最后，我想聊聊：“为什么网络要分层？”。
+
+说到分层，我们先从我们平时使用框架开发一个后台程序来说，我们往往会按照每一层做不同的事情的原则将系统分为三层（复杂的系统分层会更多）:
+
+1. Repository（数据库操作）
+2. Service（业务操作）
+3. Controller（前后端数据交互）
+
+**复杂的系统需要分层，因为每一层都需要专注于一类事情。网络分层的原因也是一样，每一层只专注于做一类事情。**
+
+好了，再来说回：“为什么网络要分层？”。我觉得主要有 3 方面的原因：
+
+1. **各层之间相互独立**：各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）**。这个和我们对开发时系统进行分层是一个道理。**
+2. **提高了整体灵活性** ：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。**这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。**
+3. **大问题化小** ： 分层可以将复杂的网络间题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。 **这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。**
+
+我想到了计算机世界非常非常有名的一句话，这里分享一下：
+
+> 计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，计算机整个体系从上到下都是按照严格的层次结构设计的。

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

@@ -1,77 +1,94 @@
 ---
-title: 计算机网络常见面试题
+title: 计算机网络常见知识点&面试题（补充）
 category: 计算机基础
 tag:
   - 计算机网络
 ---
 
-## 一 OSI 与 TCP/IP 各层的结构与功能, 都有哪些协议?
+## 应用层有哪些常见的协议？
 
-学习计算机网络时我们一般采用折中的办法，也就是中和 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚。
+### HTTP:超文本传输协议
 
-![五层体系结构](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/五层体系结构.png)
+**超文本传输协议（HTTP，HyperText Transfer Protocol)** 主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的，整个过程如下图所示。
 
-结合互联网的情况，自上而下地，非常简要的介绍一下各层的作用。
+![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/450px-HTTP-Header.png)
 
-### 1.1 应用层
+HTTP 协是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。
 
-**应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。**应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如**域名系统 DNS**，支持万维网应用的 **HTTP 协议**，支持电子邮件的 **SMTP 协议**等等。我们把应用层交互的数据单元称为报文。
 
-**域名系统**
+另外， HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。
 
-> 域名系统(Domain Name System 缩写 DNS，Domain Name 被译为域名)是因特网的一项核心服务，它作为可以将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。（百度百科）例如：一个公司的 Web 网站可看作是它在网上的门户，而域名就相当于其门牌地址，通常域名都使用该公司的名称或简称。例如上面提到的微软公司的域名，类似的还有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco 公司的域名是 www.cisco.com 等。
+### SMTP:简单邮件传输(发送)协议
 
-**HTTP 协议**
+**简单邮件传输(发送)协议（SMTP，Simple Mail Transfer Protocol）** 基于 TCP 协议，用来发送电子邮件。
 
-> 超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。（百度百科）
+注意⚠️：**接受邮件的协议不是 SMTP 而是 POP3 协议。**
 
-### 1.2 运输层
+SMTP 协议这块涉及的内容比较多，下面这两个问题比较重要：
 
-**运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务**。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。
+1. 电子邮件的发送过程
+2. 如何判断邮箱是真正存在的？
 
-**运输层主要使用以下两种协议:**
+**电子邮件的发送过程？**
 
-1. **传输控制协议 TCP**（Transmission Control Protocol）--提供**面向连接**的，**可靠的**数据传输服务。
+比如我的邮箱是“dabai@cszhinan.com”，我要向“xiaoma@qq.com”发送邮件，整个过程可以简单分为下面几步：
-2. **用户数据协议 UDP**（User Datagram Protocol）--提供**无连接**的，尽最大努力的数据传输服务（**不保证数据传输的可靠性**）。
 
-**TCP 与 UDP 的对比见问题三。**
+1. 通过 **SMTP**  协议，我将我写好的邮件交给163邮箱服务器（邮局）。
+2. 163邮箱服务器发现我发送的邮箱是qq邮箱，然后它使用 SMTP协议将我的邮件转发到 qq邮箱服务器。
+3. qq邮箱服务器接收邮件之后就通知邮箱为“xiaoma@qq.com”的用户来收邮件，然后用户就通过 **POP3/IMAP** 协议将邮件取出。
 
-### 1.3 网络层
+**如何判断邮箱是真正存在的？**
 
-**在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。** 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 **IP 协议**，因此分组也叫 **IP 数据报** ，简称 **数据报**。
+很多场景(比如邮件营销)下面我们需要判断我们要发送的邮箱地址是否真的存在，这个时候我们可以利用 SMTP 协议来检测：
 
-这里要注意：**不要把运输层的“用户数据报 UDP ”和网络层的“ IP 数据报”弄混**。另外，无论是哪一层的数据单元，都可笼统地用“分组”来表示。
+1. 查找邮箱域名对应的  SMTP 服务器地址
+2. 尝试与服务器建立连接
+3. 连接成功后尝试向需要验证的邮箱发送邮件
+4. 根据返回结果判定邮箱地址的真实性
 
-这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称.
+推荐几个在线邮箱是否有效检测工具：
 
-互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Internet Protocol）和许多路由选择协议，因此互联网的网络层也叫做**网际层**或**IP 层**。
+1. https://verify-email.org/
+2. http://tool.chacuo.net/mailverify
+3. https://www.emailcamel.com/
 
-### 1.4 数据链路层
+### POP3/IMAP:邮件接收的协议
 
-**数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。** 在两个相邻节点之间传送数据时，**数据链路层将网络层交下来的 IP 数据报组装成帧**，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
+这两个协议没必要多做阐述，只需要了解 **POP3 和 IMAP 两者都是负责邮件接收的协议**即可。另外，需要注意不要将这两者和 SMTP 协议搞混淆了。**SMTP 协议只负责邮件的发送，真正负责接收的协议是POP3/IMAP。**  
 
-在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。
+IMAP 协议相比于POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。
-控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。
 
-### 1.5 物理层
+### FTP:文件传输协议
 
-在物理层上所传送的数据单位是比特。
+**FTP 协议** 主要提供文件传输服务，基于 TCP 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽操作系统和文件存储方式。
 
-**物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异，** 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。
+FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP 服务器之间建立两个连接。如果我们要基于 FTP 协议开发一个文件传输的软件的话，首先需要搞清楚 FTP 的原理。关于 FTP 的原理，很多书籍上已经描述的非常详细了：
 
-在互联网使用的各种协议中最重要和最著名的就是 TCP/IP 两个协议。现在人们经常提到的 TCP/IP 并不一定单指 TCP 和 IP 这两个具体的协议，而往往表示互联网所使用的整个 TCP/IP 协议族。
+> FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点就在于它在两台通信的主机之间使用了两条 TCP 连接（其它客户服务器应用程序一般只有一条 TCP 连接）：
+>
+> 1. 控制连接：用于传送控制信息（命令和响应）
+> 2. 数据连接：用于数据传送；
+>
+> 这种将命令和数据分开传送的思想大大提高了 FTP 的效率。
 
-### 1.6 总结一下
+![FTP工作过程](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C%E6%80%BB%E7%BB%93/ftp.png)
 
-上面我们对计算机网络的五层体系结构有了初步的了解，下面附送一张七层体系结构图总结一下（图片来源于网络）。
 
-![七层体系结构图](https://gitee.com/SnailClimb/blog-images/raw/master/network//%E4%B8%83%E5%B1%82%E4%BD%93%E7%B3%BB%E7%BB%93%E6%9E%84%E5%9B%BE.png)
+### Telnet:远程登陆协议
 
-## 二 TCP 三次握手和四次挥手(面试常客)
+**Telnet 协议** 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的非常安全的协议所取代的主要原因。
+
+### SSH:安全的网络传输协议
+
+**SSH（ Secure Shell）** 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH  建立在可靠的传输协议 TCP 之上。
+
+**Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。**
+
+## TCP 三次握手和四次挥手(面试常客)
 
 为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。
 
-### 2.1 TCP 三次握手漫画图解
+### TCP 三次握手漫画图解
 
 如下图所示，下面的两个机器人通过 3 次握手确定了对方能正确接收和发送消息(图片来源：《图解 HTTP》)。
 
@@ -89,7 +106,7 @@ tag:
 
 ![](https://img-blog.csdnimg.cn/img_convert/0c9f470819684156cfdc27c682db4def.png)
 
-### 2.2 为什么要三次握手
+### 为什么要三次握手
 
 **三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。**
 
@@ -101,13 +118,13 @@ tag:
 
 所以三次握手就能确认双发收发功能都正常，缺一不可。
 
-### 2.3 第 2 次握手传回了 ACK，为什么还要传回 SYN？
+### 第 2 次握手传回了 ACK，为什么还要传回 SYN？
 
 接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。”
 
 > SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。
 
-### 2.5 为什么要四次挥手
+### 为什么要四次挥手
 
 ![TCP四次挥手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/TCP四次挥手.png)
 
@@ -124,7 +141,7 @@ tag:
 
 上面讲的比较概括，推荐一篇讲的比较细致的文章：[https://blog.csdn.net/qzcsu/article/details/72861891](https://blog.csdn.net/qzcsu/article/details/72861891)
 
-## 三 TCP, UDP 协议的区别
+## TCP, UDP 协议的区别
 
 ![TCP、UDP协议的区别](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/tcp-vs-udp.jpg)
 
@@ -132,7 +149,7 @@ UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP
 
 TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
 
-## 四 TCP 协议如何保证可靠传输
+## TCP 协议如何保证可靠传输
 
 1. 应用数据被分割成 TCP 认为最适合发送的数据块。
 2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
@@ -143,7 +160,7 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接，
 7. **ARQ 协议：** 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
 8. **超时重传：** 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
 
-### 4.1 ARQ 协议
+### ARQ 协议
 
 **自动重传请求**（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。
 
@@ -180,11 +197,11 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接，
 * **优点：** 信道利用率高，容易实现，即使确认丢失，也不必重传。
 * **缺点：** 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5 条 消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。
 
-### 4.2 滑动窗口和流量控制
+### 滑动窗口和流量控制
 
 **TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。** 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
 
-### 4.3 拥塞控制
+### 拥塞控制
 
 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
 
@@ -197,7 +214,7 @@ TCP 的拥塞控制采用了四种算法，即 **慢开始** 、 **拥塞避免*
 * **快重传与快恢复：**
   在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。
 
-## 五 在浏览器中输入 url 地址 ->> 显示主页的过程(面试常客)
+## 在浏览器中输入 url 地址 ->> 显示主页的过程(面试常客)
 
 百度好像最喜欢问这个问题。
 
@@ -222,11 +239,11 @@ TCP 的拥塞控制采用了四种算法，即 **慢开始** 、 **拥塞避免*
 
 * [https://segmentfault.com/a/1190000006879700](https://segmentfault.com/a/1190000006879700)
 
-## 六 状态码
+## 状态码
 
 ![状态码](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/状态码.png)
 
-## 七 各种协议与 HTTP 协议之间的关系
+## 各种协议与 HTTP 协议之间的关系
 
 一般面试官会通过这样的问题来考察你对计算机网络知识体系的理解。
 
@@ -234,23 +251,7 @@ TCP 的拥塞控制采用了四种算法，即 **慢开始** 、 **拥塞避免*
 
 ![各种协议与HTTP协议之间的关系](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/各种协议与HTTP协议之间的关系.png)
 
-## 八 HTTP 长连接, 短连接
+## HTTP 是不保存状态的协议, 如何保存用户状态?
-
-在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。
-
-而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：
-
-```
-Connection:keep-alive
-```
-
-在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如 Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
-
-**HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。**
-
-—— [《HTTP 长连接、短连接究竟是什么？》](https://www.cnblogs.com/gotodsp/p/6366163.html)
-
-## 九 HTTP 是不保存状态的协议, 如何保存用户状态?
 
 HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。
 
@@ -262,7 +263,7 @@ HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说
 
 ![HTTP是无状态协议](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/HTTP是无状态的.png)
 
-## 十 Cookie 的作用是什么? 和 Session 有什么区别？
+## Cookie 的作用是什么? 和 Session 有什么区别？
 
 Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。
 
@@ -272,31 +273,13 @@ Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器
 
 Cookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密，然后使用到的时候再去服务器端解密。
 
-## 十一 HTTP 1.0 和 HTTP 1.1 的主要区别是什么?
+## URI 和 URL 的区别是什么?
-
-> 这部分回答引用这篇文章 <https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A?> 的一些内容。
-
-HTTP1.0 最早在网页中使用是在 1996 年，那个时候只是使用一些较为简单的网页上和网络请求上，而 HTTP1.1 则在 1999 年才开始广泛应用于现在的各大浏览器网络请求中，同时 HTTP1.1 也是当前使用最为广泛的 HTTP 协议。 主要区别主要体现在：
-
-1. **长连接** : **在 HTTP/1.0 中，默认使用的是短连接**，也就是说每次请求都要重新建立一次连接。HTTP 是基于 TCP/IP 协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。**HTTP 1.1 起，默认使用长连接** ,默认开启 Connection： keep-alive。 **HTTP/1.1 的持续连接有非流水线方式和流水线方式** 。流水线方式是客户在收到 HTTP 的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
-1. **错误状态响应码** :在 HTTP1.1 中新增了 24 个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
-1. **缓存处理** :在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
-1. **带宽优化及网络连接的使用** :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
-
-## 十二 URI 和 URL 的区别是什么?
 
 * URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
 * URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
 
 URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。
 
-## 十三 HTTP 和 HTTPS 的区别？
-
-1. **端口** ：HTTP 的 URL 由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
-2. **安全性和资源消耗：** HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
-   - 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有 DES、AES 等；
-   - 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有 RSA、DSA 等。
-
 ## 建议
 
 非常推荐大家看一下 《图解 HTTP》 这本书，这本书页数不多，但是内容很是充实，不管是用来系统的掌握网络方面的一些知识还是说纯粹为了应付面试都有很大帮助。下面的一些文章只是参考。大二学习这门课程的时候，我们使用的教材是 《计算机网络第七版》（谢希仁编著），不推荐大家看这本教材，书非常厚而且知识偏理论，不确定大家能不能心平气和的读完。