标签：状态 ACK 报文 TCP 发送 四次 握手 服务端 客户端

三次握手

第一次握手，客户端向服务端发送连接请求报文，其中同步标志位SYN=1，生成的序列号seq=x,客户端的状态由关闭状态转为同步已发送状态；

第二次握手，服务端向客户端发送确认报文，其中同步标志位SYN=1，确认标志位ACK=1，序列号seq=y,确认号ack=x+1,服务端的状态由监听状态转为同步已接收状态

第三次握手，客户端向服务端发送确认报文，其中确认标志位ACK=1,确认号ack=y+1,序列号为x+1,客户端将处于连接已建立的状态，服务端收到报文后也由同步已接收状态转为连接已建立的状态

四次挥手

第一次挥手：客户端主动关闭，客户端向服务端发送FIN断开请求报文，其中终止标识符FIN=1，顺序号seq假设为u,客户端状态由建立连接状态转为终止等待1状态（FIN-WAIT-1）

第二次挥手：服务端接收到客户端的FIN报文后，服务端状态由连接建立状态转为等待关闭状态（CLOSE-WAIT）,向客户端发送确认报文，其中确认标志位ACK=1,确认号ack=u+1,序列号假设为v;服务端被动关闭；此时客户端不能再向服务端发送数据请求，但服务端仍可以向客户端发送数据，即客户端->服务端方向的连接断开；

第三次挥手：服务端向客户端发送完最后的报文后，就向客户端发送断开连接报文，其中终止标志位FIN=1，确认标志位ACK=1,确认号ack=u+1,序列号seq假设为w,服务端状态转为LAST-ACK最后确认状态

第四次挥手：客户端接收到服务端发来的终止报文，向服务端发送确认报文，其中确认标志位ACK=1,确认号ack为w+1，序列号seq=u+1,客户端状态转为时间等待状态（TIME-WAIT）,等待2MSL(最大报文段生命周期)后转为连接关闭（CLOSED）状态，服务端接收到确认报文后也转为连接关闭状态(CLOSED)

常见问题

【问题1】为什么握手用三次，挥手却用四次

​ 服务端接收到客户端的SYN请求连接报文后，可以直接向客户端返回一个SYN+ACK连接报文，其中SYN是用来同步的，ACK是应答信号；但是在关闭连接时，服务端接收到客户端的FIN报文后不一定立即断开socket连接，只有等待服务端向客户端发送完最后的数据之后，才会向客户端发送FIN报文，所以不能一起发送；

【问题2】为什么TIME_WAIT状态需要等待2MSL（最大报文段生命周期）才会转为CLOSE状态

​ TIME_WAIT 用于重发可能丢失的ACK报文；客户端接收到服务端发来的FIN报文，正常情况下客户端向服务端发送ACK报文后可以转为关闭状态，可能存在这样一种情况，客户端发送的ACK报文丢失，服务端接收不到ACK报文后会一直向客户端发送FIN报文，客户端再次接收到FIN报文后会重发ACK报文并等待2MSL时间，以确认服务端最终接收到该ACK报文

【问题3】为什么用3次握手进行连接

两次握手：可能会出现死锁现象，客户端向服务端发送连接请求报文，服务端接收到连接报文返回一个应答报文，根据两次握手协议，服务端就可以向客户端发送应答报文，如果服务端返回的应答报文丢失的情况下，客户端并不能确定服务端是否已准备好，不知道服务端建立什么序号，在这种情况下客户端认为连接还未建立，会忽略掉服务端发送的数据报文，只等待服务端的应答报文，而服务端在发送的数据分组超时后会重复发送，形成死锁。

【问题4】建立连接后，客户端突然出现了故障怎么办

​ TCP还设有一个保活计数器

标签：状态,ACK,报文,TCP,发送,四次,握手,服务端,客户端
来源： https://www.cnblogs.com/fyusac/p/13144018.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。