一、异常 1：通信一方进程正常终止（主动 / 被动退出）
触发场景
- 应用程序主动调用
close()/shutdown()关闭 TCP 连接； - 进程因代码异常（空指针、内存溢出）、被系统杀死（
kill -9）、程序崩溃等被动终止。
TCP 层核心响应机制
进程终止时，操作系统会自动释放该进程持有的所有文件描述符（包括 TCP Socket） ，并触发 TCP 的正常四次挥手流程：
- 进程终止的一端（客户端 / 服务端）会向对方发送FIN 报文 ，进入
FIN_WAIT1状态； - 对方收到 FIN 后返回 ACK，发送端进入
FIN_WAIT2，接收端进入CLOSE_WAIT； - 接收端处理完剩余数据后，也发送 FIN 报文，双方完成四次挥手，连接正常释放。
应用层表现
- 对端程序调用
read()读取数据时，会返回 0（TCP 层的 "EOF" 标识，代表对端无数据发送且已关闭连接）； - 若对端程序调用
write()发送数据，会正常发送（TCP 仍会保证可靠传输），直到自身处理完数据后检测到对端 FIN，再触发自身的关闭流程。
关键特点
属于**"优雅的异常"**，TCP 层会完成完整的连接释放，无残留连接状态，也不会产生脏数据。
二、异常 2：通信一方主机正常重启（系统重启 / 开机）
触发场景
主机因系统更新、手动重启、电源正常重启等原因关机再开机，重启过程中所有进程被杀死、网络断开。
TCP 层核心响应机制
主机重启的本质是所有进程强制终止 + 网络临时中断，TCP 层的响应分两个阶段：
- 重启前（关机阶段）：若主机关机时系统仍能正常工作，会触发与「进程终止」相同的逻辑 ------ 释放所有 Socket，向对端发送 FIN 报文，尝试完成四次挥手；
- 重启后（开机阶段） ：主机重启后，所有之前的 TCP 连接状态会被完全清空 （内核中的 TCP 连接表、端口占用均重置）；若对端此时向重启后的主机发送数据，主机因无对应连接记录，会向对端发送RST 复位报文（标识 "连接不存在，请重置连接"）。
应用层表现
- 若主机关机时完成了四次挥手，对端
read()返回 0，连接正常释放； - 若主机关机时未完成四次挥手（如网络延迟），对端后续发送数据时会收到 RST 报文 ，应用层调用
read()/write()会触发网络错误 （如 Java 的Connection reset、C 的ECONNRESET）； - 重启后的主机无法恢复之前的连接，需重新与对端建立 TCP 连接。
关键特点
重启后的主机无任何历史连接状态，对端的残留连接会被 RST 报文终止，属于**"可检测的异常"**。
三、异常 3：通信一方主机掉电 / 网线断开（网络物理中断）
触发场景
- 主机突然掉电、电源被拔、硬件故障导致关机，系统无任何正常处理流程；
- 网线被拔、交换机故障、无线网络断开等网络物理层中断，导致双方完全无法收发报文。
TCP 层核心响应机制
这是 TCP 通信中最典型的 "非优雅异常" ，TCP 层无任何主动响应（因无法收发报文），核心依赖 TCP 的保活定时器（Keep-Alive） 和超时重传机制：
- 无保活机制时 ：断连的一端（如掉电主机）无法发送任何报文，对端会一直处于
ESTABLISHED（已建立连接）状态，若对端向掉电主机发送数据，会触发超时重传 ：- 重传次数按指数递增（500ms→1000ms→2000ms...）；
- 当重传次数达到系统阈值（如 Linux 默认 15 次），TCP 层会判定连接失效，向应用层抛出错误，同时释放连接；
- 开启保活机制时 ：若双方开启了 TCP Keep-Alive（默认关闭，需手动开启），TCP 层会定期发送保活探测报文 （如 Linux 默认 2 小时发一次）：
- 若探测报文无响应，会多次重试（默认 9 次）；
- 重试失败后，判定连接失效，发送 RST 报文并释放连接，应用层收到连接中断错误。
应用层表现
- 短时间内，应用层无任何感知，仍认为连接处于正常状态；
- 若对端尝试发送数据，会经历漫长的超时重传，最终触发网络超时错误 （如 Java 的
SocketTimeoutException、C 的ETIMEDOUT）； - 若对端不发送数据（空闲连接），无保活时会永久处于假连接状态，直到人工干预。
关键特点
无主动异常报文 ，TCP 层只能通过 "超时" 判定连接失效，是生产环境中**"连接假死"**的主要原因。
四、异常 4：网络拥塞 / 丢包（连接假死）（隐性异常，衍生自物理断连）
触发场景
不属于主机 / 进程故障，而是网络层的隐性异常：如网络严重拥塞、路由环路、防火墙屏蔽报文、跨网传输时的长时间丢包，导致双方能收发少量报文，但无法正常传输数据，连接处于 "看似正常，实际不可用" 的状态。
TCP 层核心响应机制
- 若数据报文丢失，触发超时重传 + 拥塞控制：拥塞窗口置为 1，进入慢启动，多次重传失败后判定连接失效；
- 若仅 ACK 报文丢失，发送端会因未收到确认而持续重传，直到超时；
- 若网络完全阻塞（无任何报文收发），与「主机掉电 / 网线断开」逻辑一致，依赖保活定时器检测。
应用层表现
- 应用层读写操作均被阻塞，无法收发数据；
- 最终触发超时错误，但超时时间远长于正常网络延迟（受系统重传策略、保活配置影响）；
- 若为部分丢包，会出现数据传输卡顿、重传频繁，应用层响应缓慢。
关键特点
属于**"隐性异常"** ，连接状态仍为ESTABLISHED，但实际无法通信，是分布式系统中最容易被忽略的 TCP 异常。
补充：四种异常的核心对比表
表格
| 异常类型 | TCP 层核心行为 | 应用层感知时机 | 核心标识 / 错误 | 连接残留情况 |
|---|---|---|---|---|
| 进程终止 | 自动发送 FIN，完成四次挥手 | 立即（read 返回 0） | read=0（EOF） | 无残留 |
| 主机重启 | 先尝试 FIN，重启后发 RST | 短时间（收到 RST） | Connection reset | 快速释放 |
| 主机掉电 / 网线断开 | 无主动报文，依赖超时 / 保活 | 长时间（超时后） | Connection timed out | 易假死 |
| 网络拥塞 / 丢包（假死） | 重传 + 拥塞控制，最终超时 | 较长时间（卡顿后） | 读写阻塞→超时 | 易假死 |
生产环境：TCP 异常的通用处理方案
针对 TCP 的非优雅异常（掉电、断网、连接假死），仅依赖 TCP 层机制（保活）不够灵活（默认超时时间过长），需应用层 + TCP 层配合优化：
1. 开启并优化 TCP 保活机制
- 调整保活参数（以 Linux 为例）：
tcp_keepalive_time：首次保活探测时间（默认 7200s→改为 30s）；tcp_keepalive_intvl：探测重试间隔（默认 75s→改为 5s）；tcp_keepalive_probes：探测重试次数（默认 9→改为 3）；
- 作用：将空闲连接的检测时间从 2 小时缩短为30+5×3=45s，快速发现假死连接。
2. 应用层实现心跳机制（推荐，最灵活）
不依赖 TCP 层保活，由应用程序自定义心跳包（如空包、固定格式的检测包）：
- 双方定期发送心跳包（如 10s 一次），对方收到后立即返回心跳响应；
- 若发送方连续 3 次未收到响应（30s），直接判定连接失效，主动关闭 Socket 并重新建连；
- 优势：超时时间可灵活配置，支持业务层自定义检测逻辑（如附带业务状态）。
3. 给 Socket 读写设置超时时间
- 避免应用层读写操作被永久阻塞，为
read()/write()设置超时（如 5s）； - 超时后立即触发重试或重新建连，防止应用线程被挂起。
4. 服务端做连接数限流 + 空闲连接清理
- 服务端维护连接表，记录每个连接的最后活跃时间；
- 定时扫描连接表，清理长时间空闲的连接（如超过 60s 无数据交互），避免假死连接占用服务器资源。
面试高频延伸问题
- TCP 保活和应用层心跳的区别？
- TCP 保活：传输层机制，基于裸报文，轻量但配置不灵活，仅检测网络层连通性；
- 应用层心跳：业务层机制，基于自定义报文，可灵活配置超时，还能检测业务层可用性（如服务是否正常）。
- 为什么主机掉电后，对端的 TCP 连接会一直处于 ESTABLISHED？
- 因为 TCP 是面向连接的协议 ，依赖报文交互判定连接状态，掉电后无任何 FIN/RST 报文，对端无法感知，只能通过超时 / 保活被动检测。
- 收到 RST 报文代表什么？应用层该如何处理？
- RST 代表连接被强制重置（对方无此连接记录 / 主动终止）；
- 应用层需立即关闭当前 Socket，释放资源，并尝试重新建立 TCP 连接。