在网络连接中,经常会出现一些意外情况,导致TCP连接不能正常工作,对于这些意外情况,TCP内部有自己的解决方法
一.进程崩溃
在网络通讯时可能会出现进程突然崩溃的情况,当进程崩溃后进程就没了,就会导致进程的进程控制块(PCB)也被摧毁,而进程控制块中的一个属性”文件描述符表“也就被释放了,文件描述符表中有Socket网卡文件,将Socket网卡文件释放后相当于调用Socket.close(),于是崩溃的这一方就发出FIN(结束报文段)请求断开连接,就进一步触发了四次挥手,此时连接就正常释放了,所以,进程崩溃的处理和进程正常退出的处理没有区别
关于进程推荐看Java多进程(详细),关于四次挥手推荐看网络连接(3次握手和4次挥手)
二.主机关机(正常步骤的关机)
正常关机,就会先尝试摧毁所有的进程(强制终止进程),就和上面说的进程崩溃的处理方式一样,在触发四次挥手断开网络连接时,主机正在关机,所以可能四次挥手挥完了以后才关机,也有可能没有挥完就关机了
但是四次挥手有没有挥完是没有问题的,因为即使四次挥手没有挥完,要关机的这个A设备的每个进程都会发送一个FIN(结束报文段)给网络连接的另一方B设备,此时接收到FIN(结束报文段)的B设备就会返回一个ACK(应答报文段)并且发送一个FIN(结束报文段),但是A设备可能已经关机了,所以不会返回ACK(应答报文段)给B设备,B设备没有收到A设备返回的ACK(应答报文段)就会触发超时重传,再进行多次重传都没有得到A设备返回的ACK(应答报文段)后,B设备就会单方面的断开连接(释放存储网络连接相关信息的内存)
三.主机掉电(拔电源,没有任何反应的时间)
根据掉电的一方正在发送数据还是接收数据,分为两种情况
1.掉电的一方正在接收数据
假设设备A正在发送数据给设备B,此时设备B突然断电。
设备A发送数据过去以后,由于设备B已经断电,所以并不会接收到设备A发送的数据,也不会返回ACK(应答报文段)给 设备A,设备A在等待一段时间后仍然没有收到设备B返回的ACK(应答报文段)就会触发超时重传(关于超时重传推荐看出现丢包问题的情况以及解决方法),在多次重传以后还是没有接收到设备B返回的ACK(应答报文段)就会触发复位报文(RST),尝试重置连接,要是重置操作仍然失败,此时设备A就会单方面的断开连接(释放与设备B进行网络连接相关的内存数据)
2.掉电的一方正在发送数据
假设设备A正在发送数据给设备B,此时设备A突然断电。
设备B就处于了一个尴尬的状态,因为设备B正在接收数据,突然设备A就不发送数据了,设备B也不知道设备A是一会发送数据还是一直都不发送数据了,所以就会进入阻塞等待。
而这里就涉及到了一个”心跳包“的机制,设备B虽然是接收方,但也会周期性的发送一个不含任何业务数据(不含载荷)的TCP数据报给设备A,目的就是触发设备A返回ACK(应答报文段)给设备B,监测设备A是否正在正常工作,网络是否通畅
要是设备B发送TCP数据报给设备A以后,没有收到设备A返回的ACK(应答报文段)就说明此时与设备A之间的网络连接已经出现问题了,设备B就会单方面的断开与设备A之间的网络连接。
注意
虽然TCP中已经有心跳包的支持了,但是还不够,往往需要在应用层,应用程序中重新实现心跳包(TCP心跳包,周期太长了,是分钟级别的)而在现在高并发的场景下,分钟级是远远不够的,需要秒级甚至毫秒级的心跳包,可以在更短的时间内,发现某个服务器出现问题
四.网线断开
相当于主机断电的升级版本,假设在网线断开时,设备A正在给设备B发送数据
1,设备A作为发送端,设备A的处理方式就和主机掉电时”掉电的一方正在发送数据“的处理方式相同
2.设备B作为接收端,设备B的处理方式就和主机掉电时”掉电的一方正在接收数据“的处理方式相同文章来源:https://www.toymoban.com/news/detail-664951.html
文章来源地址https://www.toymoban.com/news/detail-664951.html
到了这里,关于TCP网络连接异常情况的处理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!