如何在Golang中实现TCP长连接与心跳机制

P粉602998670

发布时间：2026-02-25 12:26:03

196人浏览过

来源于php中文网

原创

tcp连接会悄无声息断开是因为nat/防火墙等中间设备存在5–30分钟空闲超时，而go的net.conn不感知此状态；需应用层主动发带验证响应的心跳包，并结合setreaddeadline实现可靠保活。

如何在golang中实现tcp长连接与心跳机制

为什么 TCP 连接会悄无声息地断开

不是网络突然挂了才断连，而是中间 NAT 设备、防火墙、负载均衡器普遍有连接空闲超时（通常 5–30 分钟），一动不动就回收连接。Go 的 net.Conn 本身不感知这个，Write 可能还成功（数据进了内核发送缓冲区），但对端早已关闭——你发出去的心跳包根本没走远。

别依赖 conn.SetDeadline 单纯防本地阻塞，它不解决中间链路静默断连
心跳必须由应用层主动发起，且要带可验证的响应（比如回传时间戳或序列号）
服务端不能只靠 Read 返回 io.EOF 才清理连接——客户端可能卡在半路，连接状态已失效

用 `SetReadDeadline` + 定时 `Write` 实现可靠心跳

核心思路：每次成功读/写后重置读超时；心跳定时器只负责发包，不等响应；真正判断是否存活，看下一次 Read 是否超时。

客户端侧：启动一个 time.Ticker，每 25 秒调用 conn.Write 发一个短心跳包（如 []byte{0x01}），同时确保每次 Read 前都调用 conn.SetReadDeadline(time.Now().Add(30 * time.Second))
服务端侧：同样为每个连接维护读超时，收到心跳后立刻重置，不响应也行（减小开销），但必须更新 deadline
注意 SetReadDeadline 影响后续所有 Read，包括心跳包的读取，所以心跳处理逻辑必须包含在正常读循环里，不能单独 goroutine 阻塞读

// 示例：服务端读循环片段
for {
    conn.SetReadDeadline(time.Now().Add(30 * time.Second))
    n, err := conn.Read(buf[:])
    if err != nil {
        if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
            // 连续两次读超时才判定断连
            if lastReadTimeout {
                closeConn(conn)
                return
            }
            lastReadTimeout = true
            continue
        }
        closeConn(conn)
        return
    }
    lastReadTimeout = false
    handlePacket(buf[:n])
}

`KeepAlive` 系统级选项只能辅助，不能替代应用层心跳

Go 的 net.Conn 支持 SetKeepAlive 和 SetKeepAlivePeriod，但这只是启用 TCP 层的 SO_KEEPALIVE，默认间隔是 2 小时（Linux），且无法穿透大部分中间设备——NAT 早把你踢了，TCP keepalive 根本发不到对端。

android rtsp流媒体播放介绍中文WORD版

本文档主要讲述的是android rtsp流媒体播放介绍；实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看

下载

开启方式：tcpConn.SetKeepAlive(true) + tcpConn.SetKeepAlivePeriod(30 * time.Second)（需 Go 1.19+）
仅建议作为兜底：防止进程僵死连接占用资源，但业务逻辑绝不能依赖它保活
Windows 默认 keepalive 时间更长，行为不一致，跨平台部署时尤其不可靠