对于 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 个能力全部确定完毕

 

 

2020.5.20 补充

《计算机网络 自定向下方法》第5章最后的那个例子里,建立 TCP 连接时,在第三次握手的时候,Bob 的便携机(客户端)就发送了实际的 HTTP GET 请求(即,有效载荷)
理论依据:
即,第三次握手时,可以承载有效载荷
按照我的理论(上文),可以理解这一点(因为第二次握手之后,主动方已经知道了他需要知道的4种能力),但是会引发一个问题,即,既然有两次就够了,为什么还要有第三次呢?
可以参见这个博客里提到的情况:
即,第三次握手解决的主要问题其实是为了不让服务器继续等待而占用 CPU 资源

 

posted @ 2018-12-27 15:39  stoneBlog  阅读(368)  评论(0编辑  收藏  举报