◆ 博主名称 小此方-CSDN博客大家好欢迎来到小此方的博客。⭐️网络系列个人专栏 【主题曲】计算机网络⭐️此方的GitHub github_此方⭐️我们思考 (Rethink) · 我们重建 (Rebuild) · 我们记录 (Record)文章目录概要序論一、TCP 异常情况分析1.1 常见 TCP 异常场景1.2 网线拔出时的异常处置与连接重建1.3 连接的保活机制Keepalive二、从源码看传输层协议概要序論Hello大家好我是此方。本文是TCP原理的最后一篇传输层协议终于要收尾了。本文介绍TCP异常然后带领大家研究UDP与TCP在源码中的结构。好我们开始吧。一、TCP 异常情况分析在实际网络环境中通信节点可能会遭遇各种突发异常如进程崩溃、机器宕机、网线拔出等。TCP 协议作为一种可靠的传输层协议设计了完备的异常处理机制与强健的容错能力。1.1 常见 TCP 异常场景我这图画得太复杂了我们边讲边理解根据异常发生的层级与严重程度典型的 TCP 异常情况可分为以下几类进程终止进程终止时操作系统会自动释放该进程打开的文件描述符TCP 协议栈依然可以正常发送 FIN 报文进行四次挥手这与正常关闭连接没有本质区别。进程退出后其打开的文件在操作系统中将不再存在。机器重启机器重启的过程与进程终止的情况相同关机前操作系统会关闭所有进程并释放相关连接资源。机器掉电或网线断开接收端在未发生读写时会认为连接依然存在。一旦接收端进行写入操作就会发现连接已经不存在进而触发 ResetRST报文重置连接。即便没有写入操作TCP 内部也内置了保活定时器会定期询问对方是否在线若对方长期无响应也会自动释放连接。应用层检测机制除了传输层自身的保活机制外应用层协议也会设计类似的检测机制例如 HTTP 长连接中的心跳检测。像 QQ 等应用在断线后也会在应用层尝试重新连接。1.2 网线拔出时的异常处置与连接重建当客户端突然拔掉网线时客户端并没有来得及与服务器进行挥手告别服务端并不知道客户端的网线已经被拔掉。此时的通信与处理逻辑如下服务器连续发送多条报文后均未收到应答检测到网络不可达。服务器向客户端发送数据但长期收不到 ACKTCP 重传超时后最终判断连接已经失效。如果服务器删除该连接后客户端重新插上网线并尝试向服务器发送数据服务器发现该连接已不存在就会向客户端发送 RST 报文。客户端收到 RST 后才知道原来的 TCP 连接已经失效。如果服务器不向客户端发送数据服务器就没有机会通过发送数据失败来发现客户端已经掉线。TCP 本身不会因为对方突然断网就立刻知道连接断开了必须通过后续的通信活动或保活机制才能识别。不管怎样这种异常连接最终都会被正确释放TCP 对异常连接展现出了极强的容错能力。1.3 连接的保活机制Keepalive为了应对无数据传输场景下的静默断网问题TCP 提供了 Keepalive 保活机制TCP 内置保活机制的时间间隔通常较大通常是大约几十分钟级别。在实际开发中更及时有效的保活机制往往是由应用层自行实现的如应用层心跳包。保活报文主要用于探测连接连通性通常不包含有效数据载荷。接下来我们从源码的层面来进一步了解一下传输层协议也是我们TCP原理部分的收尾以下是我绘制的一张图还是比较详细的一般能看懂。二、从源码看传输层协议————TCP原理完————好的本期内容就到这里如果对你有帮助还不要忘记点赞三联支持,如果有什么疑问可以再后台私信我。我是此方我们下期再见。bye!