tcp三次握手、四次挥手

TCP 的握手和挥手
TCP 是一个连接导向的协议，设计有建立连接（握手）和断开连接（挥手）的过程。TCP 没有设计会话（Session），因为会话通常是一个应用的行为。
SYN：Synchronization，请求同步
FIN：Finsh，请求完成
PSH：Push数据推送
以上 3 种情况，接收方收到数据后，都需要给发送方一个 ACK（Acknowledgement）响应。请求/响应的模型是可靠性的要求，如果一个请求没有响应，发送方可能会认为自己需要重发这个请求。
三次握手：

1.客户端发消息给服务端（SYN）—第一次握手
2.服务端准备好进行连接
3.服务端针对客户端的 SYN 给一个 ACK --第二次握手
4.服务端发送一个 SYN 给客户端 --第二次握手
5.客户端准备就绪
6.客户端给服务端发送一个 ACK --第三次握手

步骤 1 是 1 次握手；
步骤 2 是服务端的准备，不是数据传输，因此不算握手；
步骤 3 和步骤 4，因为是同时发生的，可以合并成一个 SYN-ACK 响应，作为一条数据传递给客户端，因此是第 2 次握手；
步骤 5 不算握手；
步骤 6 是第 3 次握手。

四次挥手：
1.客户端要求断开连接，发送一个断开的请求，这个叫作（FIN）。
2.服务端收到请求，然后给客户端一个 ACK，作为 FIN 的响应。
3.这里你需要思考一个问题，可不可以像握手那样马上传 FIN 回去？
其实这个时候服务端不能马上传 FIN，因为断开连接要处理的问题比较多，比如说服务端可能还有发送出去的消息没有得到 ACK；也有可能服务端自己有资源要释放。因此断开连接不能像握手那样操作——将两条消息合并。所以，服务端经过一个等待，确定可以关闭连接了，再发一条 FIN 给客户端。
4.客户端收到服务端的 FIN，同时客户端也可能有自己的事情需要处理完，比如客户端有发送给服务端没有收到 ACK 的请求，客户端自己处理完成后，再给服务端发送一个 ACK。

总结：为什么是四次挥手而不是像握手一样将SYN和ACK打包一块发送呢？因为在断开连接时需要考虑当前还有没有发送的请求需要得到回复，等到过一段时间确定之后才会继续再发送FIN给客户端请求断开连接。因为发送ACK和发送FIN不在同一时间，所以就是四次挥手。