对于 TCP 三次握手的理解
假设名叫 A 和 B 的两个人要进行通信，那么他们两人之间，首先要确保通信顺畅。
而确保通信顺畅，就要从 3 个维度，确定 8 个能力
3 个维度分别是：
1、人知道（A 知道、B 知道）
2、人（A、B）
3、能力（发出、收到）
那么对应的 8 个能力就分别是：（有点绕，可直接看下面的表格）
能力 1 ：A 知道 A 有 发出 的能力
能力 2 ：A 知道 A 有 收到 的能力
能力 3 ：A 知道 B 有 发出 的能力
能力 4 ：A 知道 B 有 收到 的能力
能力 5 ：B 知道 A 有 发出 的能力
能力 6 ：B 知道 A 有 收到 的能力
能力 7 ：B 知道 B 有 发出 的能力
能力 8 ：B 知道 B 有 收到 的能力
8 个能力的图表表示：
图表 1（A 知道）：
图表 2（B 知道）：
接下来，分别模拟一下三次握手的内容，以及每次握手发生之后，两张图表的变化
总的对话如下：
A：你好，B，能收到消息吗？
B：你好，A，我收到了。你能收到我的消息吗？
A：我收到了。让我们开始通话吧。
第一次握手：
A：你好，B，能收到消息吗？
注：A 发出去，且 B 收到了
握手之后：
图表 1（A 知道）：
图表 2（B 知道）：
即，确定了能力 5、8
解释：
对于 A 来说，他发出了消息，但是没有得到 B 的回应，所以他并不知道自己的消息是否成功发送出去了，其他的就更不知道了
对于 B 来说，他收到了 A 的消息，那么他就很清楚，自己可以收到消息，A 可以发出消息
第二次握手：
B：你好，A，我收到了。你能收到我的消息吗？
注：B 发出去，且 A 收到了
握手之后：
图表 1（A 知道）：
图表 2（B 知道）：
即，确定了能力 1、2、3、4
解释：
A 收到了 B 的回应，那么 A 肯定清楚刚才自己的消息成功发送出去了，且 B 一定能收到消息，要不然不会作出回应。而且自己收到了 B 的消息，这件事本身，也说明了，A 知道了 B 可以发消息，自己可以收到消息。
而 B 只是作了一个回应，并不知道回应是否成功，所以他知道的跟第一次握手之后是一样的。
2019.11.10 补充
最近偶然又想起 TCP 的三次握手，之前对于为什么在 第三次握手的时候，A 就直接发送正文（即正式的通信数据）给 B 了，而不是等到三次握手结束 这个点一直没有完全弄明白。
现在的理解是：
在完成两次握手之后，发起方 A 已经知道了自己和对方都有接收和发送信息的能力了，即已经具备了发送正文的条件
第三次握手：
A：我收到了。让我们开始通话吧。
注：A 发出去，且 B 收到了
握手之后：
图表 1（A 知道）：
图表 2（B 知道）：
即，确定了能力 6、7
解释：
B 收到了 A 的回应，那么 B 知道了自己的消息可以发出去，且 A 可以收到消息
三次握手到此结束，8 个能力全部确定完毕
最新文章
- The Google Test and Development Environment （持续更新）
- MySQL 命令行导出、导入Select 查询结果
- MySQL Show命令的使用
- [Swust OJ 1097]--2014(数位dp)
- sublime text3 支持终端打开文件
- 杂谈--DML触发器学习
- IScroll.js 学习笔记
- 【Spark篇】---Spark中控制算子
- es crul查询（一）
- megacli安装使用
- Python条件判断 if-else for循环 while循环 break continue
- 利用Python+163邮箱授权码发送带附件的邮件
- [转帖]Linux的标准输入 标准输出和错误输出
- ThinkPHP 3.1.3及之前的版本使用不当可造成SQLi
- poj 2299 Ultra-QuickSort(归并排序，树状数组，线段树)
- SERVER2012 FTP服务器和客户端配置
- 【python】格式化字符
- IIS 访问不了，IIS有问题，IIS右击浏览没反应
- (转)一次压测对nginx/tomcat配置的调整
- 给openvpn客户分配固定ip地址