GO语言为你提供了解决这个问题的几种方法。首选的方法可能是 net.Conn 接口中的SetReadDeadline方法。假设你的连接在以一种特定的间隔来接收数据，你可以简单地把读取超时当作一个io.EOF错误并Close这个连接。很多现有的TCP协议都支持处理错误的这种方法，它们通过定义某种心跳机制或 service health ¹，在端点间以特定间隔发送PING/PONG探测包来检测双方网络问题。另外，这种心跳机制也可能有助于代理服务器查看网络活动来决定连接的健康质量。

所以，如果你的协议支持心跳的话，或者你能够为自己的协议加入心跳的话，这个方案应该是解决网络掉线问题的首选。

但是，如果你对该协议没有控制权并且它也不支持心跳你该怎么办？

现在是时候该了解 TCP keepalive并在GO中使用它了。TCP keepalive定义于RFC 1122，但并不是TCP规范中的一部分。它可以在个别的连接中启用，但默认必需是关闭的。启用它会使网络栈在空闲了特定时间后(不能低于2小时)探测连接的连接状况。探测包不能包含数据²，并且一个探测包的回复的失败不能将连接看作已中断，因为探测包的传输是不可靠的。

GO 可以通过 net.TCPConn 的 SetKeepAlive 来启用 TCP keepalive。在 OS X 和 Linux 系统上，当一个连接空间了2个小时时，会以75秒的间隔发送8个TCP keepalive探测包。换句话说， 在两小时10分钟后(7200+8*75)Read将会返回一个 io.EOF 错误.

对于你的应用，这个超时间隔可能太长了。在这种情况下你可以调用SetKeepAlivePeriod方法。但这个方法在不同的操作系统上会有不同的表现。在OSX上它会更改发送探测包前连接的空间时间。在Linux上它会更改连接的空间时间与探测包的发送间隔。所以以30秒的参数调用 SetKeepAlivePeriod在OSX系统上会导致共10分30秒(30+8*75)的超时时间，但在linux上却是4分30秒(30+8*30).

我发现这种情况令人十分不满意，所以我创建了一个包，名叫tcpkeepalive，用来提供给你更多的控制：

kaConn, _ := tcpkeepalive.EnableKeepAlive(conn)
kaConn.SetKeepAliveIdle(30*time.Second)
kaConn.SetKeepAliveCount(4)
kaConn.SetKeepAliveInterval(5*time.Second)

目前，仅支持Linux和OS X，但是我很乐意将其他平台上的pull requests合并。如果Go核心团队的成员对此感兴趣，我也愿意尝试将这些新方法贡献给Go本身。

请让我知道你是否觉得这篇文章有价值，如果有任何疑问，请指出；并请指出任何错误，以便我可以进行更正。

附录

1）早期通过一个较低，并且不真实的检出率来调优一个心跳机制故障，是件棘手的事情。可以检出 ϕ Accrual Failure Detector 来获取一个统计模型，同样也可以用 Damian Gryski 的 go-failure 扩展。可惜的是，我想不到有什么办法可以在保活机制中使用它。

2）根据 RFC 1122 keepalive 分节，可能在零碎实现的兼容性中存在单个垃圾八进制数。然而，我不确定是不是被系统网络堆栈过滤掉了，如果你知道，请在下面发评论留言。