[TCP灵魂之问]三次握手建立连接

TCP三次握手的过程

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

• 第一次

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

• 第二次

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

• 第三次

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

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

真实的三次握手

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

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

• 客户端注重发起连接，发送SYN，自己变成了SYN-SENT状态
• 服务端收到，返回SYN和ACK（对应客户端发来的SYN），自己变成了SYN-RECD
• 客户端再发送ACK给服务端，自己变成ESTABLISHED（established）状态；服务端收到ACK之后，也变成这个状态

其中SYN需要对端的确认，而ACK并不需要，因此SYN消耗一个序列号而ACK不需要。

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

为什么不是两次？

根本原因：无法确认客户端的接收能力。
分析如下：

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

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

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

为什么不是四次？

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

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

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

• 防止黑客。会增大服务器攻击风险，防止黑客在第一次握手中的SYN报文中放大量的数据，造成服务器消耗大量的时间和内存空间
• established状态相对安全。第三次这个状态已经能够确认服务器的接收发送能力正常了

状态变迁（同时发起挥手）

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

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

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