以最通俗易懂的恋爱过程来讲述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。