tcp三次握手、四次挥手

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

tcp三次握手、四次挥手
步骤 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。
tcp三次握手、四次挥手
总结:为什么是四次挥手而不是像握手一样将SYN和ACK打包一块发送呢?因为在断开连接时需要考虑当前还有没有发送的请求需要得到回复,等到过一段时间确定之后才会继续再发送FIN给客户端请求断开连接。因为发送ACK和发送FIN不在同一时间,所以就是四次挥手。

上一篇:TCP与UDP协议


下一篇:TCP协议的那些超时