打印
分类:计算机

以最通俗易懂的恋爱过程来讲述TCP三次握手的过程

第一次

 我爱你
男---------》女
女方收到-》证明男方有爱的能力

第二次

我收到你的爱,我也爱你
男《----------------------女
男方收到-》证明女方拥有爱与被爱的能力

第三次

我收到了你的爱
男----------------》女
女方收到-》证明男方具备被爱的能力

那么真实的握手又是怎么样的?

真实的三次握手

也是要确认双方的两样能力:发送能力与接收的能力。

2021082903300012345601

最开始双方都属于CLOSED状态。然后服务器开始监听某个端口,进入LISTEN状态。

客户端注重发起连接,发送SYN,自己变成了SYN-SENT状态
服务端收到,返回SYN和ACK(对应客户端发来的SYN),自己变成了SYN-RECD
客户端再发送ACK给服务端,自己变成ESTABLISHED(established)状态;服务端收到ACK之后,也变成这个状态
其中SYN需要对端的确认,而ACK并不需要,因此SYN消耗一个序列号而ACK不需要。

记住一个规则:凡是需要对端确认的,一定消耗TCP报文的序列号。

为什么不是两次?

根本原因:无法确认客户端的接收能力。

分析如下:

如果是两次
SYN报文
你------------》想要握手
但包 滞留 在当前的网络迟迟没有到达
TCP 认为是丢包 -》于是重传
两次握手建立好了连接

这看似没有问题,但是连接关闭后,如果这个滞留在网络中的包到达了服务端呢?

问题就来了,两次握手,服务端只要接收到然后发送相应的数据包,就 默认连接 了 ,但是事实上现在客户端已经断开连接了,这样也就带来了连接资源的浪费

为什么不是四次?

因为三次已经足够确认双方的发送和接收的能力了,四次以及四次以上当然就没必要啦

三次握手过程中可以携带数据吗?

可以,但是只有第三次
前两次不能带而要第三次带的原因分析如下:

状态变迁(同时发起挥手)

这是一个什么情况呢?在发送方给接收方发SYN报文的同时,接收方也给发送方发SYN报文,两个人刚上了!

2021082903300012345602

上图就是解释同时打开情况下的状态变迁。

发完SYN,两者的状态都变为SYN-SENT。
在各自收到对方的SYN后,两者状态都变为SYN-REVD。
接着会回复对应的ACK + SYN,这个报文在对方接收之后,两者状态一起变为ESTABLISHED。