三次握手详解

三次握手

赤壁之战中，孙刘联军包围了曹操，为歼灭曹贼，孙刘联军必须同时发起进攻形成包围圈。那么问题来了，如果诸葛亮准备于次日卯时借东风，怎么通知孙权进攻时间呢？

打电话？不可能，没有这个玩意儿。

派传令兵。可是必须进过曹军阵地，这样安全吗？

刘备的传令兵可能出现的情况：

1.顺利抵达
刘备派传令兵（去通知孙权）->孙权派传令兵（给刘备说我知道了）->刘备派传令兵（孙权我已经收到）
消灭曹军

2.没有到达，孙权没有收到信息
传令兵有可能：

• 被曹军斥候发现抓走了
• 迷路了
• 被老虎吃了
• 当逃兵跑了

等了好久也不接孙权回信， 刘备慌了，只好另派一名传令兵。

3.到达了，但信息损坏。

• 路上下暴雨
• 密信丢失
• 被曹军斥候发现抓走，传令兵被严刑拷打，交出了密信，曹操将密信修改之后送往东吴大营

+++

孙权收到后起了疑心，这到底是不是刘备发送的，会不会让曹操改过了呢？遂又派一名传令兵将信送往刘备。为了不延误战机，隔了一个时辰，孙权又派了一个传令兵。

+++
刘备收到信后，发现卯时被改为子时，派骑兵通知孙权收到的信息是错的。以防万一，刘备又派了一名。

其中，一次完整的信息传达必定有三次正确的传令兵抵达，任何一次未到，都会导致密信的重新发送。

为什么要三次握手？而不是两次，四次？

1. 从资源浪费的角度

如果是两次，客户端发第一次发送了 SYN 报文，但是这个包滞留在了当前的网络中并没有到达，TCP认为发生了丢包，引发超时重传再次发送，服务端收到后，通过两次握手建立好了连接。

看似没有问题，但是当连接关闭后，如果这个滞留在网路中的包到达了服务端呢？这时候由于是两次握手，服务端只要接收到然后发送相应的数据包，就默认建立连接，并为其维护一部分资源。但是现在客户端已经断开了，这时候不管服务端发什么客户端并不会理睬，就造成了资源浪费。

2.从初始序列号的角度

三次握手可以同步双方的序列号，我们认为，如果没有第三次握手的话，当接收端第二次seq发出后，如果没有第三次ACK确认，那么发送端是不知道对端是否接收到

3.从信道安全的角度

四次，五次···当然会更好，但是没有必要。三次握手已经保证了TCP全双工的正常连接，多余的握手，也只是增加了网络负担，并没有实际效果。

同时发起握手怎么办？

1. 两者同时主动打开，发送SYN，进入SYN_SENT状态
2. 接收到对方发来的SYN后，进入SYN_RCVD，两者同时发送SYN+ACK
3. 接收到对方的SYN+ACK后，进入ESTABLISHED状态