网站建设合同的注意点,医院网站建设的计划,营销型网站建设计划书,非凡网站建设平台网页TCP四次挥手全过程 有几点需要澄清#xff1a;
1.首先#xff0c;tcp四次挥手只有主动和被动方之分#xff0c;没有客户端和服务端的概念
2.其次#xff0c;发送报文段是tcp协议栈的行为#xff0c;用户态调用close会陷入到内核态
3.再者#xff0c;图中的情况前提是双…TCP四次挥手全过程 有几点需要澄清
1.首先tcp四次挥手只有主动和被动方之分没有客户端和服务端的概念
2.其次发送报文段是tcp协议栈的行为用户态调用close会陷入到内核态
3.再者图中的情况前提是双方程序正常运行程序在挥手过程中崩溃的情况后面会讲到
过程详解时间顺序
1.A程序调用close关闭连接陷入到内核态tcp协议栈发送fin报文段此时A进入fin_wait1状态等待B的ack回复
2.B的tcp协议栈接收到fin报文回复ack进入close_wait状态等待B的用户态程序调用close
3.A的tcp协议栈接收到ack进入半关闭状态B-A的单向通信
4.A进入半关闭的同时进入fin_wait2状态等待B发送fin报文
分析B程序的状态A发送fin报文(将标志位fin置1)B的协议栈接收并判断为fin报文向该条连接的tcp控制块的接收缓冲区在内核写入EOF结束符B程序调用recv返回0判断对方断开连接
5.B程序判断A请求断开连接正常的逻辑是B也调用close断开连接
6.B调用close陷入到内核态tcp协议栈发送fin报文B进入last_ack状态等待A的ack
7.A收到B的fin报文结束fin_wait2状态回复ack进入time_wait状态
8.B收到A的ack后断开连接
9.A在time_wait规定的2MSL时间到期时断开连接
状态详解
1.close_wait状态被动断开方发送ack回复主动方的fin后进入close_wait状态因为对方已经请求断开连接本端也要进入断开连接的流程而断开连接是由用户态程序控制的在这个状态下等待程序调用close陷入到内核态协议栈才能发送本方的fin报文
如果被动方程序一直不调用close该tcp连接会处于半关闭状态
2.fin_wait1和fin_wait21是主动方发送fin后等待ack的状态2是等待对方发送fin的状态
重点
3.time_wait状态主动断开连接方在发送ack回复被动方的fin后进入time_wait状态这个状态的内容就是等待2MSL的时间随后关闭连接。
MSL是最大报文生存时间在传输中超过此时间的报文会失效
等待2MSL时间的原因
a.在进入time_wait前有延迟未到达A的报文最晚会在1MSL后到达而在A进入time_wait状态时B已经发送fin不会在time_wait后有新的来自B的报文第一个MSL可以确保网络中所有滞留的报文正确A被接收
b.在A向B发送fin后进入time_wait状态如果该fin丢失或超时导致B没有收到finB会重传一个fin报文告诉A需要重发fin报文。
最坏情况在B重传fin时过去了1MSLA最晚接收到该fin并重发ack的时间是在B重传fin的1MSL后
所以第二个MSL保证了最坏情况下A可以重发第二个ack给B以处理B没有收到第一次ack的情况大部分情况下A可以处理并重发B的多个重发的fin
time_wait状态通过等待2MSL确保了
1.所有在网络中滞留的旧报文段在此期间会被自然丢弃。
2.确保重传机制有足够的时间处理任何潜在的重传报文如FIN和ACK报文。
3.防止旧的报文段干扰未来的连接。
特殊情况
一、A处于time_wait状态时当B没有接收到第一次的ack时重发finA会在2MSL内收到这个重发的fin并重发ack如果B一直没收到ack怎么办
Q:如果B没有接收到A重发的ack怎么办此时A已经关闭连接B不会再接收到ack那么B该怎么关闭连接
A:如果主机B没有收到主机A的ACK它会继续按照TCP的重传机制定期重传FIN报文直到重传次数达到设定的上限通常是TCP实现中的一个参数RFC 1122规定是最多重传4次每次重传都会等待一个时间间隔。这个时间间隔通常会指数增长即所谓的“指数退避”
A在TIME_WAIT状态下会处理这些重传的FIN报文并每次都重新发送ACK报文1-4个最坏情况下只能重发一次ack
B在重传次数耗尽之后如果仍未收到ACK报文它会认为连接已经关闭并释放资源
二、在四次挥手过程中发生1.主动断开方的程序崩溃 2.被动断开方的程序崩溃
一言以蔽之协议栈会关闭该程序所有套接字并发送RST(reset)报文给对方表示连接非正常关闭收到RST报文的一方会通过recv和errno获知
前置细节
1.在关闭TCP连接时如果操作系统检测到连接正在进行中比如在ESTABLISHED、FIN_WAIT、CLOSE_WAIT等状态它会发送RST报文给对方通知对方连接被异常终止
2.对端在接收到RST报文后会在后续的网络操作中感知到连接被重置
对端的系统调用错误 对端的应用程序如果尝试在接收到RST报文后继续进行网络操作会在相应的系统调用中收到错误。这些系统调用会返回错误并设置errno。例如如果对端调用recv会返回-1并设置errno为ECONNRESET表示连接被重置。
详细分析
1. 主动断开方的程序崩溃
情景
主动断开方主机A发送了FIN报文进入FIN_WAIT_2状态等待被动断开方主机B发送FIN报文来完成连接的关闭。主机A的程序在此时崩溃。
结果
主机A的TCP连接关闭 主机A的程序崩溃导致操作系统关闭该程序相关的所有套接字包括处于FIN_WAIT_2状态的套接字。主机A的TCP栈会发送RSTReset报文给主机B表示连接已被非正常关闭。 主机B的处理 主机B收到RST报文后立即终止连接并释放相关资源。任何在此连接上的未完成数据传输都将被终止应用程序将收到错误通知表明连接被重置。
2. 被动断开方的程序崩溃
情景
被动断开方主机B在接收到主机A的FIN报文后发送ACK并进入CLOSE_WAIT状态等待应用程序调用close以发送FIN报文。主机B的程序在此时崩溃。
结果
主机B的TCP连接关闭 主机B的程序崩溃导致操作系统关闭该程序相关的所有套接字包括处于CLOSE_WAIT状态的套接字。主机B的TCP栈会发送RSTReset报文给主机A表示连接已被非正常关闭。 主机A的处理 主机A收到RST报文后立即终止连接并释放相关资源。主机A的应用程序会收到错误通知表明连接被重置。
总结
无论是主动断开方还是被动断开方的程序崩溃最终结果都是TCP连接被非正常关闭两者的TCP栈会发送RST报文给对方通知对方连接已被重置。收到RST报文的一方会立即终止连接并释放相关资源。应用程序会收到相应的错误通知表明连接被异常终止。
点击获取更多Linux C/C开发学习资料
