标签：ACK 握手 tcp 发送 四次 FIN 服务端 客户端
TCP 的握手和挥手
TCP 是一个连接导向的协议，设计有建立连接（握手）和断开连接（挥手）的过程。TCP 没有设计会话（Session），因为会话通常是一个应用的行为。
SYN：Synchronization，请求同步
FIN：Finsh，请求完成
PSH：Push数据推送
以上 3 种情况，接收方收到数据后，都需要给发送方一个 ACK（Acknowledgement）响应。请求/响应的模型是可靠性的要求，如果一个请求没有响应，发送方可能会认为自己需要重发这个请求。
三次握手：
1.客户端发消息给服务端（SYN）—第一次握手
2.服务端准备好进行连接
3.服务端针对客户端的 SYN 给一个 ACK --第二次握手
4.服务端发送一个 SYN 给客户端 --第二次握手
5.客户端准备就绪
6.客户端给服务端发送一个 ACK --第三次握手!](https://www.icode9.com/i/ll/?i=2021051617434815.png?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NjE2NDg1Ng==,size_16,color_FFFFFF,t_70)
步骤 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不在同一时间，所以就是四次挥手。
标签：ACK,握手,tcp,发送,四次,FIN,服务端,客户端 来源： https://blog.csdn.net/weixin_46164856/article/details/116897830
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。