Go 语言使用 TCP keepalive 已翻译 100%

oschina 投递于 2014/08/27 06:52 (共 6 段, 翻译完成于 08-27)
阅读 15017
收藏 79
Go
4
加载中

如果你写过某些 TCP socket 代码,你可能会疑问:如果网线被拨掉或者远程主机崩溃了我的TCP连接会怎样?

简短的答案是:一点影响都没有。这种情况下连接的结束远程主机是不会发送FIN数据包的,并且本地系统不能检测连接是否已中断。所以需要作为程序员的你来解决这种情况。

pseudo
翻译于 2014/08/27 09:22
1

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

pseudo
翻译于 2014/08/27 09:48
1

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

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

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

pseudo
翻译于 2014/08/27 10:12
2

GO 可以通过 net.TCPConnSetKeepAlive 来启用 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).

pseudo
翻译于 2014/08/27 10:24
1

我发现这种情况令人十分不满意,所以我创建了一个包,名叫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本身。

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


0x0bject
翻译于 2014/08/27 09:30
1

附录

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

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

0x0bject
翻译于 2014/08/27 09:48
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(12)

武当王也
武当王也

引用来自“光哥2014”的评论

看了一下go1.5代码,并且在linux上测试,作者这个库的代码已集成进去了。

引用来自“十一文”的评论

那么不需要心跳包了?
这个问题是关键
OSC管理员
OSC管理员
测试发现在不同操作系统上区别蛮大的
十一文
十一文

引用来自“光哥2014”的评论

看了一下go1.5代码,并且在linux上测试,作者这个库的代码已集成进去了。
那么不需要心跳包了?
光哥2014
光哥2014
看了一下go1.5代码,并且在linux上测试,作者这个库的代码已集成进去了。
Kyli
Kyli

引用来自“回去干活”的评论

我觉得内存模型这块难度好高,虽然看了effective go但是还有很多疑问,而且深入进去,发现还是很多坑,并不比C语言简单。也许是我自己太菜,学这种比较底层编译型的语言,本身就需要很强大的基础知识吧。
虽然go的语法比较简单,但是我发现看完effective go之类,几乎可以变出各种各样的设计模式,架构。
要比面向对象灵活太多,以致我觉得好难把握。
可能还是要多看看别人优秀的源码和设计思想吧。
赞 看了inject的源码,虽然很短,但是感觉很开朗
Kyli
Kyli

引用来自“young7”的评论

研究了一段时间Go,发现语法很让人纠结,2.0之后再过来看看

引用来自“LoveStones”的评论

已经比Erlang语法好多了
不能同意更多,看完erlang,我觉得三观全毁了,倒不是不好,只是干倒好不容易建立起来的大山,确实不爽啊
xu-Zhu
xu-Zhu

引用来自“young7”的评论

研究了一段时间Go,发现语法很让人纠结,2.0之后再过来看看
已经比Erlang语法好多了
树相马
树相马

引用来自“young7”的评论

研究了一段时间Go,发现语法很让人纠结,2.0之后再过来看看

引用来自“采女孩的小蘑菇”的评论

确实,很蛋疼的语法
这么美妙居然蛋疼?协同开发,统一格式多么重要。。。。
不得瑟掉毛
不得瑟掉毛

引用来自“young7”的评论

研究了一段时间Go,发现语法很让人纠结,2.0之后再过来看看
喜欢lua或ruby语法
不得瑟掉毛
不得瑟掉毛

引用来自“young7”的评论

研究了一段时间Go,发现语法很让人纠结,2.0之后再过来看看
确实,很蛋疼的语法
返回顶部
顶部