最近添哥一直反映，他手下的裝置以grpc stream的方式向我服務端傳送資料。偶然會收到錯誤。現象如下：
- 連線已經建立了一段時間，正常使用。
- 突然client.Send 返回 eof。
- 客戶端有報錯：connection reset by peer
- 在服務端找到錯誤：context canceled
這裡不得不提一下，客戶端上報到服務的網路環境並不是很好，而且服務端每個程式有數十萬個協程在執行，處理上十萬條grpc stream。
選取了幾個裝置在服務端與客戶端tcpdump，通過七七四十九天，終於捕獲到了異常時的抓包。
現象：
- 正常情況下，服務端客戶端定期互Ping。
- 當異常時，在服務端/客戶端的抓包會發現Ping包未回。很快連線斷開。
猜測和grpc keepalive功能有關。
grpc server keepalive配置
原始配置
var keepAliveArgs = keepalive.ServerParameters{
Time: 60 * time.Second,
Timeout: 5 * time.Second,
}
s := grpc.NewServer(
grpc.KeepaliveParams(keepAliveArgs).....)
為了防止客戶端斷連後資源洩漏，grpc的服務端一般會配置keepalive，每隔一段時間就向空閒的client傳送ping包，並計算回包的時間。當ping沒有回應。則認為連線已失敗（比如被牆），此時在服務端會關閉這個連線並配置svr.Context()為done。
上面的配置代表，每60S向客戶端檢測一次，如果ping的包沒有在5秒內回，則斷開連線。此時就會出現上述的異常事件。
原因分析
為了弄清keepalive的邏輯，檢視原始碼grpc/internal/transport/http2_server.go
grpc ping發包邏輯
每隔預設的時間，就會發一個包。並將kpTimeoutLeft置為keepalive.Timeout。
發包之後邏輯
- 檢測是否在kpTimeoutLeft為0前收到了任何資料（不僅是ping的回包）。
- 此時outstandingPing為true，所以不會再有新的ping被髮出。這是最坑的一點設計。合理的設計應該允許重試幾次，以重試後能收到包為準。
- 不停的去sleep，並去減小kpTimeoutLeft。
- 當kpTimeoutLeft<0，連線關閉。
預期外斷聯原因
可能是因為網路抖動或者grpc server忙不過來，使得某次的ping包被丟棄或未及時處理。造成了連線被錯誤的切斷。
解決
一開始，想要找一找有沒有retry之類的配置。不要僅丟棄一次就把連線切斷，但沒找到。這時，添哥突發奇想，將Timeout的時間延長。於是，keepalive的配置變成了這樣：
var keepAliveArgs = keepalive.ServerParameters{
Time: 30 * time.Second,
Timeout: 90 * time.Second,
}
在這個配置下，為ping之後給了更長的反應時間，根據grpc的原始碼，90秒內如果有任意的資料被接收（包含收到客戶端發來的訊息）。連線都不會被切斷。但假如客戶端一直沒有資料回發，猜想應該還是會把連線切斷。因為ping在沒有收到回訊息的時候不會再進行下一次ping。
通過檢視註釋也能應證程式碼的實現：
// After having pinged for keepalive check, the server waits for a duration
// of Timeout and if no activity is seen even after that the connection is
// closed.
Timeout time.Duration // The current default value is 20 seconds.
只要在ping後timeout內有activity,連線就不會中斷。還好這個業務client和server互動很頻繁，在90秒內一般會有資料的互動。
立馬變更，困擾我們很久的問題，用一種不是很優雅的方式解決了。