Go长连接丢包与重传机制详解

本文深入剖析了Go语言中TCP与UDP长连接场景下的丢包识别与重传策略，明确指出在TCP长连接中盲目添加应用层重传不仅多余，反而会因与内核TCP协议栈的重传机制冲突，引发消息重复、顺序错乱和业务状态不一致等严重问题；强调只有在协议明确要求“至少一次送达”且服务端已严格实现幂等性时，才可谨慎引入应用层重传；同时提供了基于心跳+读超时的轻量级丢包推断方案，并警示KeepAlive的局限性；对于UDP，则系统梳理了必须自建重传时的关键避坑要点，包括避免goroutine泄漏、控制包大小防分片丢包、正确理解WriteTo语义等——核心思想是：真正考验工程能力的，不是如何重传，而是清醒判断何时绝对不能重传。

不能在 TCP 长连接里加应用层重传，除非协议明确要求“至少一次送达”且服务端已实现幂等性——否则只会制造重复、错序和状态不一致。

为什么 TCP 连接上盲目重传会出事

TCP 协议栈本身已完整实现丢包检测、序列号管理、ACK 确认和指数退避重传。Go 的 net.Conn 默认就走这套机制。你在上层再套一层“发完没回就重发”，等于让两套重传逻辑打架：

• conn.Write() 成功只表示数据进了内核发送缓冲区，不代表对方收到；盲目重发会导致接收方收到两条相同消息
• 两次重发内容若不同（比如时间戳/随机数变化），服务端按序列号拼接就会错乱
• 服务端已处理成功并返回响应，但客户端因 ACK 延迟超时而重发，造成订单重复扣款、WebSocket 消息重复渲染

怎么判断是不是真丢包，而不是假死

网卡丢包无法被 Go 应用层直接感知，只能通过间接信号推断。最轻量、最可控的方式是结合业务心跳 + SetReadDeadline：

• 客户端每 30 秒发一次心跳，服务端必须在 5 秒内回 "pong"
• 每次读心跳前都调用 conn.SetReadDeadline(time.Now().Add(5 * time.Second))，否则超时只生效一次
• 若 err 是 net.Error 且 Timeout() 为 true，大概率是中间链路丢包或设备拦截，不是连接断开
• 别依赖 KeepAlive：默认 2 小时才探测一次，且无法反映应用层通路是否可用

UDP 场景下必须自己搞重传，但得避开几个坑

UDP 没有连接、没有 ACK、没有重传，所谓“长连接”只是应用层维护的会话状态。此时丢包只能靠你自己补，但常见错误包括：

• WriteTo 返回 nil 错误 ≠ 消息送达；它只代表数据进了内核队列，对方收不到也不会通知你
• 高频发包时，每个消息都起一个 time.After + goroutine，会造成 goroutine 泄漏和调度压力；应改用单个 time.Ticker 或最小堆统一驱动重传任务
• MTU 超限导致静默丢包：UDP 包 >1500 字节会被 IP 层分片，任一片丢失整包就被内核丢弃；建议应用层限制单包 ≤1200 字节
• 不要对每个 WriteTo 都设 SetWriteDeadline，它控制的是拷贝进内核队列的耗时，不是网络往返，设太短（如 5ms）容易误判失败

真正难的不是写重传逻辑，而是决定什么时候不该重传——比如非幂等操作、无状态请求、下游未承诺至少一次语义时，重传就是 bug 的源头。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。