TCP客户端非正常离线时，服务器不会立刻知道；它主要靠TCP Keepalive、应用层心跳、超时重传和连接错误事件来间接判断。 正常关闭会发FIN或RST，非正常离线往往没有报文，连接会变成半开状态。
TCP客户端非正常离线服务器怎么知道？先分清正常断开和非正常离线
服务器判断客户端在线,靠的不是“感觉”，而是内核状态机、报文和定时器，客户端离开的方式不同，服务器感知速度完全不同。
![[公益/网易/3.9/iOS/安卓]最新公益 pvp客户端 功能众多 端圈 T0～](https://i0.hdslb.com/bfs/archive/06bcb7cd88a007a66de2bcb24af7499ada59ebbb.jpg)
- 正常下线：客户端调用
close()，发FIN；或进程崩溃后操作系统发RST，服务器read()返回0或收到ECONNRESET，能较快释放连接。 - 非正常离线：拔网线、断电、飞行模式、进程被强杀、NAT表项过期，客户端没机会发FIN/RST，服务器这边的socket仍可能显示
ESTABLISHED。 - 半开连接：一端已经不可达，另一端还保留连接状态，服务器如果只等数据，可能长时间误判在线。
业内专家指出,TCP本身没有“死亡通知”机制，它只能通过探测、超时和错误事件推断对端是否还活着。
TCP层如何发现非正常离线：Keepalive、重传和错误事件
TCP层不是完全无能为力,它有几个内置机制，只是默认参数通常偏慢，不适合实时业务。
TCP Keepalive默认参数与触发条件
Linux启用SO_KEEPALIVE后，会在连接空闲时发送探测包，默认参数常见为：
net.ipv4.tcp_keepalive_time = 7200，即空闲2小时后开始探测。net.ipv4.tcp_keepalive_intvl = 75，每次探测间隔75秒。net.ipv4.tcp_keepalive_probes = 9，连续9次无响应才判定断开。
按默认值,服务器可能要2小时11分钟左右才知道客户端断电，这个速度对聊天、物联网、长连接推送都太慢，可以临时调整：
sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_intvl=30 sysctl -w net.ipv4.tcp_keepalive_probes=3
也可以代码里设置：
int keepalive = 1; setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive));
Keepalive的优点是内核自动做,不依赖业务代码，缺点是只能检测空闲连接，参数调太激进会增加无效探测。
重传超时与TCP_USER_TIMEOUT
如果服务器有数据发给客户端,但客户端已离线，TCP会重传，重传到一定次数后，内核返回ETIMEDOUT，Linux的tcp_retries2默认值较大，完全靠它发现离线，可能等十几分钟甚至更久。
更可控的方式是设置TCP_USER_TIMEOUT，它表示数据发出后，多久没有确认就判定连接超时：
int timeout_ms = 10000; setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout_ms, sizeof(timeout_ms));
这个参数适合有下行数据的服务,如果服务器只收不发，它触发不了，还得靠Keepalive或应用心跳。
epoll、read返回值和RST
服务器常用epoll管理连接，连接出错时，epoll可能返回EPOLLERR或EPOLLHUP。read()返回0表示对端正常关闭；返回-1且errno为ECONNRESET，表示收到RST，但非正常离线时，这些事件不一定马上出现。
可以用命令观察：
ss -tnp state established ss -tnp state established '( dport = :8080 )'
如果看到连接长时间存在,但没有收发计数变化，就要怀疑半开连接。
应用层心跳才是主力：TCP心跳检测和Keepalive哪个更靠谱
对大多数业务,应用层心跳比TCP Keepalive更靠谱，原因不是Keepalive没用，而是它太底层、默认太慢、跨NAT和移动网络时不够灵活。
| 对比项 | TCP Keepalive | 应用层心跳 |
|---|---|---|
| 检测速度 | 默认慢，可调 | 可做到秒级到分钟级 |
| 实现位置 | 内核 | 业务代码 |
| 穿透NAT | 依赖系统行为 | 主动发包，更容易保活 |
| 资源消耗 | 较低 | 略高，但可控 |
| 适用场景 | 通用空闲连接 | 移动端、物联网、IM、推送 |
| 可观测性 | 弱 | 强，可带业务状态 |
心跳设计实操
- 客户端每30秒或60秒发一次
PING，服务器回PONG。 - 服务器维护每个连接的
last_active，收到任何业务包或心跳都刷新。 - 定时器扫描超时连接,比如超过90秒或180秒没活跃，标记离线。
-
心跳间隔要小于NAT超时,移动网络NAT映射可能几分钟失效，太长的间隔会被中间设备悄悄断开。
- 重连使用指数退避加随机抖动,避免大量客户端同时重连。
消息格式可以简单设计：
| 长度 | 类型 | 序列号 | 时间戳 | 负载 |
服务器收到PING后立即回PONG，同时更新连接活跃时间，这样即使客户端断电，服务器也能在超时阈值内发现。
超时扫描怎么落地
常见做法有三种：
- Redis过期键：连接ID写入Redis并设置TTL，心跳刷新TTL，过期事件触发离线。
- 时间轮：适合海量连接，插入和删除效率高。
- 最小堆或优先队列：按超时时间排序，扫描到期连接。
不管用哪种,核心都是“最后一次活跃时间 + 超时阈值”，阈值通常设为心跳间隔的2到3倍，心跳30秒，超时90秒，是比较常见的组合。
物联网设备TCP断线服务器如何感知
物联网场景更复杂,设备可能用4G、NB-IoT、WiFi，也可能休眠，设备断电后，服务器同样收不到FIN/RST。
如果使用MQTT,Broker有Keepalive机制，客户端声明Keepalive间隔，Broker在约定时间没有收到控制报文，就认为客户端离线，通常按1.5倍Keepalive判断，例如Keepalive为60秒，Broker约90秒后断开。
如果没有MQTT,自建TCP协议就要做：
- 设备定时上报心跳或业务数据。
- 服务器下行探测,比如发
PING等PONG。 - 记录设备影子,离线后更新状态。
- 用
tcpdump抓包确认是否有FIN/RST：
tcpdump -i any -nn 'tcp port 8080 and (tcp[tcpflags] & (tcp-fin|tcp-rst) != 0)'
行业共识认为,物联网长连接不能只靠TCP Keepalive，设备休眠、运营商NAT、信号弱都会让连接状态和实际可达性不一致。
北京服务器TCP连接超时时间怎么设置
“北京服务器TCP连接超时时间怎么设置”是很多运维会搜的问题，地域本身不改变TCP原理，但跨运营商、跨地域链路会影响丢包和延迟，北京服务器对接全国移动端时，参数要兼顾及时性和误判率。
系统级配置可写入/etc/sysctl.conf：
net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_retries2 = 8
应用层建议：
- 心跳间隔：30秒到60秒。
- 服务端超时：90秒到180秒。
- 重连退避：1秒、2秒、4秒、8秒，加随机抖动。
- 云负载均衡：注意SLB/ELB的连接空闲超时，按云厂商文档调整，避免后端还认为在线，前端已断开。
有人会问“TCP长连接保活方案多少钱”，自建方案主要花在服务器、带宽、开发和运维上；云厂商长连接服务通常按连接数、消息量或流量计费，不同厂商差异较大，以官网计费文档为准。
服务器判断客户端离线的完整工程流程
把机制串起来,服务器端一般这样做：
- 接受连接,注册到连接管理器。
- 设置
SO_KEEPALIVE和TCP_USER_TIMEOUT。 - 启动应用层心跳,维护
last_active。 - 定时扫描超时连接,超过阈值标记离线。
- 关闭socket,清理会话，触发离线事件。
- 记录日志和监控指标,观察误判和漏判。
常用排查命令：
# 查看连接状态 ss -tnp state established # 查看Keepalive参数 sysctl -a | grep keepalive # 抓取FIN/RST tcpdump -i any -nn 'tcp[tcpflags] & (tcp-fin|tcp-rst) != 0'
监控指标可以包括：当前连接数、心跳超时数、重连次数、RST数量、半开连接数。核心结论是：服务器要知道非正常离线，不能只靠TCP状态，必须把内核保活、超时重传和应用层心跳组合起来。
Q&A：TCP客户端非正常离线服务器怎么知道
客户端拔网线后服务器为什么还显示ESTABLISHED？
因为服务器内核没有收到FIN或RST,TCP状态机不会主动变成关闭，连接会保持半开，直到Keepalive探测失败、数据重传超时或应用层心跳超时。
只靠TCP Keepalive能发现断电吗？
能,但默认太慢，Linux默认空闲2小时才开始探测，连续多次无响应才断开，对实时性要求高的业务，应调小参数，并加上应用层心跳。
服务器如何快速判断TCP客户端掉线？
应用层心跳加服务端超时扫描最可控,心跳间隔小于NAT超时，超时阈值设为2到3个心跳周期；同时启用SO_KEEPALIVE和TCP_USER_TIMEOUT作为兜底，服务器最终通过超时事件关闭socket并更新离线状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/690619.html
