[譯] Go語言使用TCP keepalive

歡迎訪問我的個人網站獲取更佳閱讀排版：[譯] Go語言使用TCP keepalive | yoko blog (https://pengrl.com/p/62417/)

本篇文章首先簡單介紹了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節描述的這樣。

# 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類型。

這意味著，我們需要使用ListenTCP和AcceptTCP而不是Listen和Accept（它們的調用方式有區別，ListenTCP使用結構體而不是字元串來表示地址。我們調用方式大概會像這樣：ListenTCP("tcp", &net.TCPAddr{Port: myClientPort})。如果你不特別指定的話，IP的默認值為0.0.0.0）。之後它會返回我們需要的類型TCPConn。

Go語言提供的方法

如果你翻看文檔可能會注意到這兩個相關的方法：SetKeepAlive和SetKeepAlivePeriod。 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。我偷了（啊呸，是參考了）上面所引用的文章中的一些代碼，多謝。

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())
}
// dont 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函數調用。我們來看它的實現。

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。看以下代碼。

//Sets additional keepalive parameters. //Uses new interfaces introduced in Go1.11, which let us get connections 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對象從而設置參數。你所需要做的就是定義一個函數（就像上面例子中的匿名函數），它接收一個指向文件描述符的參數。這是操作連接中的文件描述符而不造成阻塞調用的方法，可避免出現瘋狂創建線程的情況。