mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-08-01 16:28:03 +08:00
[docs update]计算机网络部分内容完善
This commit is contained in:
guide
parent
075593b231
commit
bbc4ed9b56
25
README.md
25
README.md
@ -131,12 +131,13 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
|
||||
|
||||
### 网络
|
||||
|
||||
1. [OSI 和 TCP/IP 网络分层模型详解（基础）](./docs/cs-basics/network/osi&tcp-ip-model.md)
|
||||
2. [HTTP vs HTTPS（应用层）](./docs/cs-basics/network/http&https.md)
|
||||
3. [HTTP 1.0 vs HTTP 1.1（应用层）](./docs/cs-basics/network/http1.0&http1.1.md)
|
||||
4. [HTTP 常见状态码（应用层）](./docs/cs-basics/network/http-status-codes.md)
|
||||
5. [计算机网络常见知识点&面试题（补充）](./docs/cs-basics/network/other-network-questions.md)
|
||||
6. [谢希仁老师的《计算机网络》内容总结（补充）](docs/cs-basics/network/谢希仁老师的《计算机网络》内容总结.md)
|
||||
1. [计算机网络常见知识点&面试题总结](./docs/cs-basics/network/other-network-questions.md)
|
||||
2. [OSI 和 TCP/IP 网络分层模型详解（基础）](./docs/cs-basics/network/osi&tcp-ip-model.md)
|
||||
3. [HTTP vs HTTPS（应用层）](./docs/cs-basics/network/http&https.md)
|
||||
4. [HTTP 1.0 vs HTTP 1.1（应用层）](./docs/cs-basics/network/http1.0&http1.1.md)
|
||||
5. [HTTP 常见状态码（应用层）](./docs/cs-basics/network/http-status-codes.md)
|
||||
6. [TCP 三次握手和四次挥手（传输层）](./docs/cs-basics/network/tcp-connection-and-disconnection.md)
|
||||
7. [谢希仁老师的《计算机网络》内容总结（补充）](docs/cs-basics/network/谢希仁老师的《计算机网络》内容总结.md)
|
||||
|
||||
### 数据结构
|
||||
|
||||
@ -422,18 +423,6 @@ Dubbo 是一款国产的 RPC 框架，由阿里开源。相关阅读：
|
||||
* [四步构建异地多活](https://mp.weixin.qq.com/s/hMD-IS__4JE5_nQhYPYSTg)
|
||||
* [《从零开始学架构》— 28 | 业务高可用的保障：异地多活架构](http://gk.link/a/10pKZ)
|
||||
|
||||
## 开发工具
|
||||
|
||||
### Git
|
||||
|
||||
* [Git 入门](./docs/tools/git/git-intro.md)
|
||||
* [Github 小技巧](./docs/tools/git/git-intro.md)
|
||||
|
||||
### Docker
|
||||
|
||||
* [Docker 基本概念解读](./docs/tools/docker/docker-intro.md)
|
||||
* [Docker从入门到上手干事](./docs/tools/docker/docker-in-action.md)
|
||||
|
||||
## 关于作者
|
||||
|
||||
* [个人介绍 Q&A](https://javaguide.cn/about-the-author/)
|
||||
|
||||
@ -172,6 +172,7 @@ export const sidebarConfig = defineSidebarConfig({
|
||||
"http&https",
|
||||
"http1.0&http1.1",
|
||||
"http-status-codes",
|
||||
"tcp-connection-and-disconnection",
|
||||
],
|
||||
},
|
||||
],
|
||||
|
||||
@ -0,0 +1 @@
|
||||
<mxfile host="Electron" modified="2022-08-13T13:41:56.051Z" 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="ltlIWFww6GRdYTsO7ZgJ" version="13.4.5" type="device"><diagram id="AL4jlyFzqR7gxqzt3J-t" name="Page-1">7Zldc6M2FIZ/DTPbizD6AASXxnHS2U532vXFNpcYhE0jIxfLid1fXwmELQHedZzE9WR2chF0JB2J8z46cLCDx8vtfZWsFr/zjDIHgWzr4FsHIQhBIP8py66xRBFpDPOqyPSgg2Fa/Eu1EWjrpsjo2hooOGeiWNnGlJclTYVlS6qKP9vDcs7sVVfJnPYM0zRhfeu3IhOL9r6C6NDxKy3mi3bpwPeanmXSjta3sl4kGX82THji4HHFuWiultsxZSp6bWCaeXdHevc7q2gpTpmw/Vp++XozAwysHz5jvLx/APAGNV6eErbRdzxmhXLYbFns2kBUfFNmVLmCDo6fF4Wg01WSqt5nKb20LcSS6e68YGzMGa/quThLaJin0r4WFX+kRk+QhnSWy56UL4tUz94HCuyntLGvnfNSaFBQPeKRirTt7AdFx+mJVoJuDZMO0j3lSyqqnRyie4nWSxMLQ91+PugfEZdomReG+L4emWjo5nvfB1nkhVbmBSrhnkpTWsk7elOV8pwG6aBKGYlmAFyXSh7BbkiuTimvp1RPI1pmI5WZZKvkJe1oYoRN3n0sA1Tt/lJRdv22+aDH1o3brZagae0GBUE9vU5SQyTVnIofZw+aWUm0r5khSBv5ITUqyhJRPNmpd0givcIfvFCZCuyfNpHFAwk6Kq/5pkqpnmVmyq4jglwUIIQj4gEPg8jmbJ8hWr9NnHp+a4D2UTifKf8jMXUlrPioI7FNTjc/nEqOj6BLjrpF+LLgBC8CJ2XJeq3Su8nOdxO7PG81AyvVyBndalff4cJ+QF07JdC33wUwOJcLIJ9W4TEucHhZLshPLl6ZPQByQ/OYe5ae3rnpA3odv5Zb37ssJuFPTF6ZPjzsYmDIiS09A3R2NkGuZ/si3cz0zmxEA2wETGiB64K8LR+CfzaqxJVqYQ9kKM9NUzBX/6cPX9rpcjeNh6bn03Typ/Sy/aWHnqwTxBBsbd2i34PMIkebElbMS0WsxEbWUDhWVUcha/6R7lgWWaaWGSygDgiCLqpmeWRyHtbThESJK/fQf4d6CIahC32DtcB+xMB+bYQC6KI+/F0q36w2ardwHJqDvC0hquNmXcdxJAfAcLU18XkrzF67j9ZLfJr/wV3neRYFgXV3Z+5jNP7t6D6APlFSzrEaJ8+W3Db8SOfr5l0OGPHcEB89X17QP19eRFz/kucL/uh8/W/cfWpQ23001N4nlUfYtb847N8UzOztR7LUvCReA9+2Jr4T+s5o7Ew8Jx47Eaktd04sL+5qy+hz8pTcq6/4LRqz6iTCgsEMOyFOfOtEUF2MYieK9uv8Ldepfy1w0/JKCWPJjLI4SR/ntb27uIFZoNvGR9i4/rPx670fWwy/AYoIE1mQWCwir88iJAMv0fDlIMrm4feQ5lX18LMSnvwH</diagram></mxfile>
|
||||
@ -0,0 +1 @@
|
||||
<mxfile host="Electron" modified="2022-08-13T14:28:15.284Z" 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="1K9ojrwZqdc5vI_gWreO" version="13.4.5" type="device"><diagram id="wcNzZLoUwuyfQb5zXRwy" name="Page-1">7Zldc6M2FIZ/DTO7F2GQAAGXxrGz2/2Ytp5O272TQWAajBwsx3Z+fSWQbPFhr+OJUzeT8YXRkXSE9D4c6YBhD+ebuxIvZt9oTHIDWvHGsG8NCAGwEP8Tlm1tCQKvNqRlFstGe8MkeyLSaEnrKovJstGQUZqzbNE0RrQoSMQaNlyWdN1sltC8OeoCp6RjmEQ471r/zGI2U/NCwb7iE8nSmRoauU5dM8eqtZzKcoZjutZM9siwhyWlrL6ab4YkF6unFqbuNz5Qu7uzkhTslA5/fE6Th4eb5OvT0w/v9yT9MXY/3UgvjzhfyRkP80w4rG+ZbdVClHRVxES4AoYdrmcZI5MFjkTtmkvPbTM2z2V1kuX5kOa0rPraMSZ+EnH7kpX0nmg1KPLJNOE1EZ1nkey9Wyhr10WtfeWcFkyCAqsW94RFqrK7KGqGpGRko5nkIt0ROies3PImstZzTCA7SWiBLyVc7xEIPNOTSs80/V3ZEkvu0p37vTL8QorzDKFgR6gJKfmkXlSoJCEo6hUq9oKpZV2XUI5nm753dUrZHaU6GpEiHojgxEsFLUhLE23Z+OxDvkDl9i+xyqarin/LtlXhdiMlqEvbXkFgR6+T1GC4TAn7eQAhcSOOdjXTBFEr36dGSXLMssdm9O2TSI7wK81EsFJIABVsJQ8eaqm8pKsyIrKXHizbjjxoQgShHXiO5dhW0OQMei2/9Tp1/FYA7VbhfKact8TUlbDiwpbETXLa8eFUclwITO+gW2i/Ljjus8CJcrxcivCus3M0sIOgZmAhCklONtLV/5gL4MCGZLZ1LgngGGC2/7okoHcSnh0hrKObgAPO3Vyco37dNnAXJsN7J+P5MQKZFjioIIJnh4yW3+ae9Mpg+D1goJxJdausWyUI6GEl8lgunB3FGE6JbtJIUkbh4GZZ8THgDYC/2FRN951QKv7Hn7+rMfkU6mHrmg+T0W/c5eZjB1aePrA+PFU6I49Heu4jTTjP0kIwzrHjqZUdimQki3A+kBXzLI7FML151T7zstpw61mT/mT4VTfGUaTCPXAvkCaB4Gi02W1v2pMDETBh9+FpU/1iKVNwFmhJEgcIvRBog+GXA6DxXoo1A4bgLfF2cxHgqhcoh3dN2OXN4Tm6+4q8qY37OoGTtG3fGm0Xgc2Gx3diu4e2nnPB5VDrvmF9P1397NwNLNPRNXWbEcR3zzx3u0f9ul7L74WPV6D7TldFhOUCF73RRcYlEVnKdPoBWvyWhyLMICgvAutjHZrOO2LVI6udD+G5ePaL6XKhBaa3FJQuswX6xxNHBd5/uQX2vKYeuQZ/tAZDY+QY4dDgdy0sYyPkF+PKMvgFP+I78U1OITMtT9oFEYevQ54x8ozw1giAuBiERhDsxvmHj1N9+zOj4kppy/GU5CGO7tPK3h5cQw7JsvY9Jax+TRQ7cbrB8wtQCW3P9FEDxd1mqKEIvJ7Q3n7XcQKIvLj/ulkHzf1HYnv0Lw==</diagram></mxfile>
|
||||
@ -5,6 +5,20 @@ tag:
|
||||
- 计算机网络
|
||||
---
|
||||
|
||||
## OSI 和 TCP/IP 网络分层模型
|
||||
|
||||
### OSI 七层模型是什么？每一层的作用是什么？
|
||||
|
||||
[ OSI 七层模型详解](./osi&tcp-ip-model.md#osi-七层模型)
|
||||
|
||||
### TCP/IP 四层模型是什么？每一层的作用是什么？
|
||||
|
||||
[TCP/IP 四层模型详解](./osi&tcp-ip-model.md#tcp-ip-四层模型)
|
||||
|
||||
### 为什么网络要分层？
|
||||
|
||||
[为什么网络要分层？](./osi&tcp-ip-model.md#为什么网络要分层)
|
||||
|
||||
## 应用层有哪些常见的协议？
|
||||
|
||||
### HTTP:超文本传输协议
|
||||
@ -84,135 +98,67 @@ FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP
|
||||
|
||||
**Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。**
|
||||
|
||||
## TCP 三次握手和四次挥手(面试常客)
|
||||
|
||||
|
||||
为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。
|
||||
## TCP 与 UDP
|
||||
|
||||
### TCP 三次握手漫画图解
|
||||
|
||||
如下图所示，下面的两个机器人通过 3 次握手确定了对方能正确接收和发送消息(图片来源：《图解 HTTP》)。
|
||||
### TCP 与 UDP 的区别
|
||||
|
||||
|
||||
1. **是否面向连接** ：UDP 在传送数据之前不需要先建立连接。而 TCP 提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。
|
||||
2. **是否是可靠传输**：远地主机在收到 UDP 报文后，不需要给出任何确认，并且不保证数据不丢失，不保证是否顺序到达。TCP 提供可靠的传输服务，TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制。通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达。
|
||||
3. **是否有状态** ：这个和上面的“是否可靠传输”相对应。TCP 传输是有状态的，这个有状态说的是 TCP 会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等。为此 ，TCP 需要维持复杂的连接状态表。而 UDP 是无状态服务，简单来说就是不管发出去之后的事情了（**这很渣男！**）。
|
||||
4. **传输效率** ：由于使用 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多。
|
||||
5. **传输形式** ： TCP 是面向字节流的，UDP 是面向报文的。
|
||||
6. **首部开销** ：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。
|
||||
7. **是否提供广播或多播服务** ：TCP 只支持点对点通信，UDP 支持一对一、一对多、多对一、多对多；
|
||||
8. ......
|
||||
|
||||
**简单示意图：**
|
||||
|
||||
|
||||
我把上面总结的内容通过表格形式展示出来了！确定不点个赞嘛？
|
||||
|
||||
* 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
|
||||
* 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
|
||||
* 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端
|
||||
| | TCP | UDP |
|
||||
| ---------------------- | -------------- | ---------- |
|
||||
| 是否面向连接 | 是 | 否 |
|
||||
| 是否可靠 | 是 | 否 |
|
||||
| 是否有状态 | 是 | 否 |
|
||||
| 传输效率 | 较慢 | 较快 |
|
||||
| 传输形式 | 字节流 | 数据报文段 |
|
||||
| 首部开销 | 20 ～ 60 bytes | 8 bytes |
|
||||
| 是否提供广播或多播服务 | 否 | 是 |
|
||||
|
||||
**详细示意图（图片来源不详）**
|
||||
### 什么时候选择 TCP,什么时候选 UDP?
|
||||
|
||||
|
||||
|
||||
### 为什么要三次握手
|
||||
- **UDP 一般用于即时通信**，比如： 语音、 视频 、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
|
||||
- **TCP 用于对传输准确性要求特别高的场景**，比如文件传输、发送和接收邮件、远程登录等等。
|
||||
|
||||
**三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。**
|
||||
### HTTP 基于 TCP 还是 UDP？
|
||||
|
||||
第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
|
||||
|
||||
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
|
||||
**HTTP 协议是基于 TCP 协议的**，所以发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。
|
||||
|
||||
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常
|
||||
### 使用 TCP 的协议有哪些?使用 UDP 的协议有哪些?
|
||||
|
||||
所以三次握手就能确认双方收发功能都正常，缺一不可。
|
||||
**运行于 TCP 协议之上的协议** ：
|
||||
|
||||
### 第 2 次握手传回了 ACK，为什么还要传回 SYN？
|
||||
1. **HTTP 协议** ：超文本传输协议（HTTP，HyperText Transfer Protocol)主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。
|
||||
2. **HTTPS 协议** ：更安全的超文本传输协议(HTTPS,Hypertext Transfer Protocol Secure)，身披 SSL 外衣的 HTTP 协议
|
||||
3. **FTP 协议**：文件传输协议 FTP（File Transfer Protocol），提供文件传输服务，**基于 TCP** 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽操作系统和文件存储方式。
|
||||
4. **SMTP 协议**：简单邮件传输协议（SMTP，Simple Mail Transfer Protocol）的缩写，**基于 TCP 协议**，用来发送电子邮件。注意 ⚠️：接受邮件的协议不是 SMTP 而是 POP3 协议。
|
||||
5. **POP3/IMAP 协议**： POP3 和 IMAP 两者都是负责邮件接收的协议。
|
||||
6. **Telent 协议**：远程登陆协议，通过一个终端登陆到其他服务器。被一种称为 SSH 的非常安全的协议所取代。
|
||||
7. **SSH 协议** : SSH（ Secure Shell）是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH 建立在可靠的传输协议 TCP 之上。
|
||||
8. ......
|
||||
|
||||
接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。”
|
||||
**运行于 UDP 协议之上的协议** ：
|
||||
|
||||
> SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。
|
||||
1. **DHCP 协议**：动态主机配置协议，动态配置 IP 地址
|
||||
2. **DNS** ： **域名系统（DNS，Domain Name System）将人类可读的域名 (例如，www.baidu.com) 转换为机器可读的 IP 地址 (例如，220.181.38.148)。** 我们可以将其理解为专为互联网设计的电话薄。实际上 DNS 同时支持 UDP 和 TCP 协议。
|
||||
|
||||
### 为什么要四次挥手
|
||||
### TCP 三次握手和四次挥手
|
||||
|
||||
|
||||
|
||||
断开一个 TCP 连接则需要“四次挥手”：
|
||||
|
||||
* 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
|
||||
* 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号
|
||||
* 服务器-关闭与客户端的连接，发送一个 FIN 给客户端
|
||||
* 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1
|
||||
|
||||
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
|
||||
|
||||
举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。
|
||||
|
||||
上面讲的比较概括，推荐一篇讲的比较细致的文章：[https://blog.csdn.net/qzcsu/article/details/72861891](https://blog.csdn.net/qzcsu/article/details/72861891)
|
||||
|
||||
## TCP, UDP 协议的区别
|
||||
|
||||
|
||||
|
||||
UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等
|
||||
|
||||
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
|
||||
|
||||
## TCP 协议如何保证可靠传输
|
||||
|
||||
1. 应用数据被分割成 TCP 认为最适合发送的数据块。
|
||||
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
|
||||
3. **校验和：** TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
|
||||
4. TCP 的接收端会丢弃重复的数据。
|
||||
5. **流量控制：** TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
|
||||
6. **拥塞控制：** 当网络拥塞时，减少数据的发送。
|
||||
7. **ARQ 协议：** 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
|
||||
8. **超时重传：** 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
|
||||
|
||||
### ARQ 协议
|
||||
|
||||
**自动重传请求**（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。
|
||||
|
||||
#### 停止等待 ARQ 协议
|
||||
|
||||
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。
|
||||
|
||||
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。
|
||||
|
||||
**优缺点：**
|
||||
|
||||
* **优点：** 简单
|
||||
* **缺点：** 信道利用率低，等待时间长
|
||||
|
||||
**1) 无差错情况:**
|
||||
|
||||
发送方发送分组, 接收方在规定时间内收到, 并且回复确认. 发送方再次发送。
|
||||
|
||||
**2) 出现差错情况（超时重传）:**
|
||||
|
||||
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 **自动重传请求 ARQ** 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。**连续 ARQ 协议** 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。
|
||||
|
||||
**3) 确认丢失和确认迟到**
|
||||
|
||||
* **确认丢失** ：确认消息在传输过程丢失。当 A 发送 M1 消息，B 收到后，B 向 A 发送了一个 M1 确认消息，但却在传输过程中丢失。而 A 并不知道，在超时计时过后，A 重传 M1 消息，B 再次收到该消息后采取以下两点措施：1. 丢弃这个重复的 M1 消息，不向上层交付。 2. 向 A 发送确认消息。（不会认为已经发送过了，就不再发送。A 能重传，就证明 B 的确认消息丢失）。
|
||||
* **确认迟到** ：确认消息在传输过程中迟到。A 发送 M1 消息，B 收到并发送确认。在超时时间内没有收到确认消息，A 重传 M1 消息，B 仍然收到并继续发送确认消息（B 收到了 2 份 M1）。此时 A 收到了 B 第二次发送的确认消息。接着发送其他数据。过了一会，A 收到了 B 第一次发送的对 M1 的确认消息（A 也收到了 2 份确认消息）。处理如下：1. A 收到重复的确认后，直接丢弃。2. B 收到重复的 M1 后，也直接丢弃重复的 M1。
|
||||
|
||||
#### 连续 ARQ 协议
|
||||
|
||||
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
|
||||
|
||||
**优缺点：**
|
||||
|
||||
* **优点：** 信道利用率高，容易实现，即使确认丢失，也不必重传。
|
||||
* **缺点：** 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5 条 消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。
|
||||
|
||||
### 滑动窗口和流量控制
|
||||
|
||||
**TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。** 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
|
||||
|
||||
### 拥塞控制
|
||||
|
||||
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
|
||||
|
||||
为了进行拥塞控制，TCP 发送方要维持一个 **拥塞窗口(cwnd)** 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
|
||||
|
||||
TCP 的拥塞控制采用了四种算法，即 **慢开始** 、 **拥塞避免** 、**快重传** 和 **快恢复**。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。
|
||||
|
||||
* **慢开始：** 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
|
||||
* **拥塞避免：** 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。
|
||||
* **快重传与快恢复：**
|
||||
在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。
|
||||
[TCP 三次握手和四次挥手（传输层）常见面试题总结](./tcp-connection-and-disconnection.md)
|
||||
|
||||
## 在浏览器中输入 url 地址 ->> 显示主页的过程(面试常客)
|
||||
|
||||
@ -235,21 +181,33 @@ TCP 的拥塞控制采用了四种算法，即 **慢开始** 、 **拥塞避免*
|
||||
5. 浏览器解析渲染页面
|
||||
6. 连接结束
|
||||
|
||||
具体可以参考下面这篇文章：
|
||||
具体可以参考这篇文章：[https://segmentfault.com/a/1190000006879700](https://segmentfault.com/a/1190000006879700) 。
|
||||
|
||||
* [https://segmentfault.com/a/1190000006879700](https://segmentfault.com/a/1190000006879700)
|
||||
## HTTP 状态码有哪些？
|
||||
|
||||
## 状态码
|
||||
HTTP 状态码用于描述 HTTP 请求的结果，比如2xx 就代表请求被成功处理。
|
||||
|
||||
|
||||
|
||||
|
||||
## 各种协议与 HTTP 协议之间的关系
|
||||
关于 HTTP 状态码更详细的总结，可以看我写的这篇文章：[HTTP 常见状态码总结（应用层）](./http-status-codes.md)。
|
||||
|
||||
一般面试官会通过这样的问题来考察你对计算机网络知识体系的理解。
|
||||
## HTTP 和 HTTPS 有什么区别？
|
||||
|
||||
图片来源：《图解 HTTP》
|
||||
- **端口号** ：HTTP 默认是 80，HTTPS 默认是 443。
|
||||
- **URL 前缀** ：HTTP 的 URL 前缀是 `http://`，HTTPS 的 URL 前缀是 `https://`。
|
||||
- **安全性和资源消耗** ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
|
||||
|
||||
|
||||
关于 HTTP 和 HTTPS 更详细的对比总结，可以看我写的这篇文章：[HTTP vs HTTPS（应用层）](./http&https.md) 。
|
||||
|
||||
## HTTP 1.0 和 HTTP 1.1 有什么区别？
|
||||
|
||||
- **连接方式** : 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`字段。
|
||||
|
||||
关于 HTTP 1.0 和 HTTP 1.1 更详细的对比总结，可以看我写的这篇文章：[HTTP 1.0 vs HTTP 1.1（应用层）](./http1.0&http1.1.md) 。
|
||||
|
||||
## HTTP 是不保存状态的协议, 如何保存用户状态?
|
||||
|
||||
|
||||
92
docs/cs-basics/network/tcp-connection-and-disconnection.md
Normal file
92
docs/cs-basics/network/tcp-connection-and-disconnection.md
Normal file
@ -0,0 +1,92 @@
|
||||
---
|
||||
title: TCP 三次握手和四次挥手（传输层）
|
||||
category: 计算机基础
|
||||
tag:
|
||||
- 计算机网络
|
||||
---
|
||||
|
||||
|
||||
为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。
|
||||
|
||||
## 建立连接-TCP 三次握手
|
||||
|
||||
|
||||
|
||||
|
||||
建立一个 TCP 连接需要“三次握手”，缺一不可 ：
|
||||
|
||||
|
||||
- **一次握手**:客户端发送带有 SYN（SEQ=x） 标志的数据包 -> 服务端，然后客户端进入 **SYN_SEND** 状态，等待服务器的确认；
|
||||
- **二次握手**:服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 **SYN_RECV** 状态
|
||||
- **三次握手**:客户端发送带有带有 ACK(ACK=y+1) 标志的数据包 –> 服务端，然后客户端和服务器端都进入**ESTABLISHED** 状态，完成TCP三次握手。
|
||||
|
||||
**当建立了 3 次握手之后，客户端和服务端就可以传输数据啦！**
|
||||
|
||||
### 为什么要三次握手?
|
||||
|
||||
三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
|
||||
1. **第一次握手** ：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
|
||||
2. **第二次握手** ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
|
||||
3. **第三次握手** ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常
|
||||
|
||||
三次握手就能确认双发收发功能都正常，缺一不可。
|
||||
|
||||
更详细的解答可以看这个：[TCP 为什么是三次握手，而不是两次或四次？ - 车小胖的回答 - 知乎](https://www.zhihu.com/question/24853633/answer/115173386) 。
|
||||
|
||||
### 第2次握手传回了ACK，为什么还要传回SYN？
|
||||
|
||||
接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。”
|
||||
|
||||
> SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。
|
||||
|
||||
## 断开连接-TCP 四次挥手
|
||||
|
||||
|
||||
|
||||
断开一个 TCP 连接则需要“四次挥手”，缺一不可 ：
|
||||
|
||||
1. **第一次挥手** ：客户端发送一个 FIN（SEQ=X） 标志的数据包->服务端，用来关闭客户端到服务器的数据传送。然后，客户端进入 **FIN-WAIT-1** 状态。
|
||||
2. **第二次挥手** ：服务器收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （SEQ=X+1）标志的数据包->客户端 。然后，此时服务端进入**CLOSE-WAIT**状态，客户端进入**FIN-WAIT-2**状态。
|
||||
3. **第三次挥手** ：服务端关闭与客户端的连接并发送一个 FIN (SEQ=y)标志的数据包->客户端请求关闭连接，然后，服务端进入**LAST-ACK**状态。
|
||||
4. **第四次挥手** ：客户端发送 ACK (SEQ=y+1)标志的数据包->服务端并且进入**TIME-WAIT**状态，服务端在收到 ACK (SEQ=y+1)标志的数据包后进入 CLOSE 状态。此时，如果客户端等待 **2MSL** 后依然没有收到回复，就证明服务端已正常关闭，随后，客户端也可以关闭连接了。
|
||||
|
||||
**只要四次挥手没有结束，客户端和服务端就可以继续传输数据！**
|
||||
|
||||
### 为什么要四次挥手？
|
||||
|
||||
TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
|
||||
|
||||
举个例子：A 和 B 打电话，通话即将结束后。
|
||||
|
||||
1. **第一次挥手** ： A 说“我没啥要说的了”
|
||||
2. **第二次挥手** ：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
|
||||
3. **第三次挥手** ：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
|
||||
4. **第四次挥手** ：A 回答“知道了”，这样通话才算结束。
|
||||
|
||||
### 为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
|
||||
|
||||
|
||||
因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。
|
||||
|
||||
### 如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
|
||||
|
||||
|
||||
客户端没有收到 ACK 确认，会重新发送 FIN 请求。
|
||||
|
||||
### 为什么第四次挥手客户端需要等待 2\*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？
|
||||
|
||||
|
||||
第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端没有因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2\*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。
|
||||
|
||||
> **MSL(Maximum Segment Lifetime)** : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。
|
||||
|
||||
## 参考
|
||||
|
||||
|
||||
- 《计算机网络（第 7 版）》
|
||||
|
||||
- 《图解 HTTP》
|
||||
|
||||
- TCP and UDP Tutorial：https://www.9tut.com/tcp-and-udp-tutorial
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user