[译] Go语言使用TCP keepalive

本篇文章首先简单介绍了TCP keepalive的机制以及运用场景。接着介绍了Go语言中如何开启与设置TCP keepalive。但是由于Go语言最上层的接口不够灵活,从而引出在Go语言中如何使用系统调用设置TCP连接的文件描述符属性。接着原作者就掉坑里了。。。最后介绍了在Go 1.11之后的版本如何使用新的接口设置TCP连接的文件描述符属性。
为了更适合中文阅读,我对文章做了些增删,并没有逐字翻译。原文地址:Notes on TCP keepalive in Go | TheNotExpert

我有一个供客户端连接的TCP服务端程序。它十分简单。但问题是,所有的客户端都使用手机移动网络并且网络总是不稳定。经常丢失连接却没有通过FIN或者RST包通知服务端。服务端保持着这个虚连接并且认为这个客户端仍然在线,而事实上却不是。

我的首个解决方案是等待一小会;如果某个客户端在给定的时间端没有发送任何数据,则在服务端关闭这个连接(值得一提,SetDeadline方法十分好用,当超时时它在conn.Read上返回i/o超时错误)。但是以下情况需要考虑:我不能把超时设置得过小,因为客户端生成数据的速度可能很慢,而且也不能把超时设置得过大,因为这会使我误判客户端的在线状态,而事实上我需要一定的精度。

我的想法是ping客户端。但是我不想给客户端发送它不需要的垃圾数据。而且,客户端的代码也不由我说了算,所以我也不确定如果我发送一些奇怪的数据给客户端,客户端会如何表现。

TCP keepalive —— 一个轻量级的ping

TCP keepalive发送没有(或者几乎没有)包体负载的TCP报文给对端,并且对端会回复keepalive ACK确认包。它不是TCP标准的一部分(尽管在RFC1122中有相关的描述),并且,它总是默认被禁用。尽管如此,大部分现代的TCP协议栈都支持这个特性。

在它的大部分实现中,简单来说,有三个主要参数:

  • Idle time(空闲时间) - 接收一个包后,等待多长时间发出一个ping包。
  • Retry interval(重试间隔时间) - 如果发送了一个ping,但是没有收到对端回复的ACK,在重试间隔时间之后重新发送ping。
  • Ping amount(重试次数) - 重试次数(没有收到对端ACK)达到多少次后,我们认为这个连接不存活了。

举个例子,空闲时间是30秒,重试间隔时间是5秒,重试次数为3。以下是它的工作方式:

服务端收到客户端的一包应用层数据。然后客户端不再发送任何数据。服务端等待30秒。然后发送一个ping给客户端。如果服务端收到了ACK,则服务端等待另一个30秒,再次发送ping;如果在这30秒内服务端收到了数据,则30秒的定时器被重置。

如果服务端没有收到ACK,等待5秒后再次发送ping。如果再过5秒还是没有收到回复?发送最后一个ping并等待最后一个5秒(是的,在最后一个ping也需要等待重试间隔时间)。然后我们认为这个连接超时了并且在服务端断开它。

默认值

据说Window系统在发送keepalive ping之前默认等待2小时。Linux下获取默认值十分简单,就像此处3.1.1节描述的这样。

1
2
3
4
5
6
7
8
# Idle time
cat /proc/sys/net/ipv4/tcp_keepalive_time

# Retry interval
cat /proc/sys/net/ipv4/tcp_keepalive_intvl

# Ping amount
cat /proc/sys/net/ipv4/tcp_keepalive_probes

在Go语言中如何设置?

由于我最近使用Go语言比较多,我需要在Go语言中运用TCP keepalive。

讨论开始之前需要说明,以下内容适用于Linux。我不是百分百确定它是否适用于OSX,但我几乎可以肯定它不适用于Windows。

连接的特殊类型

首先,我注意到我在服务端程序中只使用了net.Conn类型。但是它并不管用,它缺少我们需要的特定方法。我们需要TCPConn类型。

这意味着,我们需要使用ListenTCPAcceptTCP而不是ListenAccept(它们的调用方式有区别,ListenTCP使用结构体而不是字符串来表示地址。我们调用方式大概会像这样:ListenTCP("tcp", &net.TCPAddr{Port: myClientPort})。如果你不特别指定的话,IP的默认值为0.0.0.0)。之后它会返回我们需要的类型TCPConn

Go语言提供的方法

如果你翻看文档可能会注意到这两个相关的方法:SetKeepAliveSetKeepAlivePeriod
func (c *TCPConn) SetKeepAlive(keepalive bool) error的调用方式十分简单:传入true从而打开TCP keepalive机制。

但是接下来的func (c *TCPConn) SetKeepAlivePeriod(d time.Duration) error就有些令人困惑了。我们用它究竟设置的是什么?答案可以在这篇文章(好文章,推荐阅读)中找到:它同时设置了空闲时间重试间隔时间。而重试间隔次数则使用系统的默认值。所以如果我设置5 * time.Second。那么它可能是等待5秒钟,发送ping并等待另一个5秒。并且8次重试(取决于系统设置)。而我需要更大的灵活性,设置得更精准。

进入系统层面

可以通过直接操作socket参数来实现。我没有关注里面太多的细节,这纯粹是我的个人解释。以下是我们如何设置空闲时间为30秒(我们可以通过SetKeepAlivePeriod设置,因为其他参数我们再另外设置),重试时间间隔设置为5秒,重试次数设置为3。我偷了(啊呸,是参考了)上面所引用的文章中的一些代码,多谢。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
conn.SetKeepAlive(true)
conn.SetKeepAlivePeriod(time.Second * 30)

// Getting the file handle of the socket
sockFile, sockErr := conn.File()
if sockErr == nil {
// got socket file handle. Getting descriptor.
fd := int(sockFile.Fd())
// Ping amount
err := syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPCNT, 3)
if err != nil {
Warning("on setting keepalive probe count", err.Error())
}
// Retry interval
err = syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPINTVL, 5)
if err != nil {
Warning("on setting keepalive retry interval", err.Error())
}
// don't forget to close the file. No worries, it will *not* cause the connection to close.
sockFile.Close()
} else {
Warning("on setting socket keepalive", sockErr.Error())
}

在这段代码之后的某一行我会写上dataLength, err := conn.Read(readBuf),这行代码会阻塞直到收到数据或者发生错误。如果是keepalive引起的错误,err.Error()将会包含连接超时信息。

关于文件描述符的坑

上面的代码只有在你不频繁调用的前提下才运行良好。在写完这篇文章之后,我以困难模式学习到了一个关于它的小问题。。。

问题就隐藏在Fd函数调用。我们来看它的实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func (f *File) Fd() uintptr {
if f == nil {
return ^(uintptr(0))
}

// If we put the file descriptor into nonblocking mode,
// then set it to blocking mode before we return it,
// because historically we have always returned a descriptor
// opened in blocking mode. The File will continue to work,
// but any blocking operation will tie up a thread.
if f.nonblock {
f.pfd.SetBlocking()
}

return uintptr(f.pfd.Sysfd)

}

如果文件描述符处于非阻塞模式,会将它修改为阻塞模式。根据stackoverflow的这个回答,举例来说,当Go增加一个阻塞的系统调用,运行时调度器将该系统调用所属协程所属系统线程从调度池中移出。如果调度池中的系统线程数小于GOMAXPROCS,则会创建新的系统线程。鉴于我的每一个连接都使用一个独立协程,你可以想象一下这个爆炸速度。将很快到达10000线程的限制然后panic。

将它放入独立协程并不好使。

译者yoko注,个人理解此处可做两层解释,如果是像原作者所描述的,每个连接都独占一个协程(直到连接关闭再退出协程),先使用系统调用设置文件描述符属性,再收发数据,那么系统线程会随连接数线性增长。如果是在连接收发数据的协程之前,先弄一个协程处理完文件描述符属性的设置,那么系统调用完成后临时协程结束,线程还是会回收的。但也毕竟不是一种好的模式。

但是有一个方法是可行的。注意,前提是Go版本高于1.11。看以下代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
//Sets additional keepalive parameters.
//Uses new interfaces introduced in Go1.11, which let us get connection's file descriptor,
//without blocking, and therefore without uncontrolled spawning of threads (not goroutines, actual threads).
func setKeepaliveParameters(conn devconn) {
rawConn, err := conn.SyscallConn()
if err != nil {
Warning("on getting raw connection object for keepalive parameter setting", err.Error())
}

rawConn.Control(
func(fdPtr uintptr) {
// got socket file descriptor. Setting parameters.
fd := int(fdPtr)
//Number of probes.
err := syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPCNT, 3)
if err != nil {
Warning("on setting keepalive probe count", err.Error())
}
//Wait time after an unsuccessful probe.
err = syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPINTVL, 3)
if err != nil {
Warning("on setting keepalive retry interval", err.Error())
}
})
}

func deviceProcessor(conn devconn) {

//............

conn.SetKeepAlive(true)
conn.SetKeepAlivePeriod(time.Second * 30)

setKeepaliveParameters(conn)

//............

dataLen, err := conn.Read(readBuf)

//............
}

最新版本的Go提供了一些新接口,net.TCPConn实现了SyscallConn,它使得你可以获取RawConn对象从而设置参数。你所需要做的就是定义一个函数(就像上面例子中的匿名函数),它接收一个指向文件描述符的参数。这是操作连接中的文件描述符而不造成阻塞调用的方法,可避免出现疯狂创建线程的情况。

总结

网络编程是复杂的。并且时常是系统相关的。这个解决方法只在Linux下有用,但是这是一个好的开始。在其他操作系统中有类似的参数,它们只是调用方式不同。

感谢阅读。再见。

本文完,作者yoko,尊重劳动人民成果,转载请注明原文出处: https://pengrl.com/p/62417/

0%