問題描述
公司內部容器平臺，接入層用nginx做LB，使用者有grpc協議需求，所以在lb層支援grcp反向代理，nginx從1.13開始支援grpc反向代理，將公司使用的nginx包從1.12升級到1.14.0後，增加grpc反向代理配置。配置完成後，打壓力測試時，發現接入層機器埠占滿而導致服務異常，開始追查問題。
追查方向
深入瞭解grpc協議
- gRPC是一個高效能、通用的開源 RPC 框架，其由 Google 主要面向移動應用開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol Buffers) 序列化協議開發，且支援眾多開發語言。gRPC 提供了一種簡單的方法來精確地定義服務和為 iOS、Android 和後臺支援服務自動生成可靠性很強的客戶端功能庫。客戶端充分利用高階流和連結功能，從而有助於節省頻寬、降低的 TCP 連結次數、節省 CPU 使用、和電池壽命。
從上述描述可以看出grpc基於http2，client到server應該保持長連線，理論上不應該出現埠占滿的問題
抓包
- client到接入層抓包看請求狀態，發現client到接入層確實是長連線狀態。接入層到後端server抓包發現，請求並沒有保持長連線，一個請求處理完之後，連結就斷開了。
查nginx跟長連線相關配置
- nginx長連線相關說明參考以下文件：nginx長連線
- nginx跟grpc長連線相關配置，發現在1.15.6版本引入了"grpc_socket_keepalive"跟grpc直接相關長連線配置
Configures the “TCP keepalive” behavior for outgoing connections to a gRPC server. By default, the operating system’s settings are in effect for the socket. If the directive is set to the value “on”, the SO_KEEPALIVE socket option is turned on for the socket.
參考nginx長連線相關文件做了配置調整之後，發現nginx到server依然是短連線
將nginx升級到nginx1.15.6（升級過程中由於線上的nginx用到了lua模組，碰到了lua模組不適配問題，解決方案見連結lua模組適配問題)配置grpc_socket_keepalive on，抓包發現，會有少量處理多個請求的長連線存在，但大部分依然是短連線。
- 開啟nginx debug模式
從debug日誌來看nginx確實嘗試重用連結，但是從實際抓包看，nginx的連結重用的情況非常少，大部分都是請求處理完之後連結斷開，懷疑nginx對grpc反向代理支援的不夠理想。
調整埠回收策略
-
回到問題本身，要解決的問題是接入層埠占滿，各種調整nginx的長連線配置並不能解決這個問題，就嘗試從tcp連結埠回收方面解決，大部分的tcp連結都處於TIME_WAIT狀態。
-
TIME_WAIT狀態的時間是2倍的MSL(linux裡一個MSL為30s，是不可配置的)，在TIME_WAIT狀態TCP連線實際上已經斷掉，但是該埠又不能被新的連線例項使用。這種情況一般都是程式中建立了大量的短連線，而作業系統中對使用埠數量做了限制最大能支援65535個，TIME_WAIT過多非常容易出現連線數佔滿的異常。對TIME_WATI的優化有兩個系統引數可配置：tcp_tw_reuse，tcp_tw_recycle 這兩個引數在網上都有詳細介紹，這是就不展開來講
-
tcp_tw_reuse參考連結
-
tcp_tw_recycle（Enable fast recycling TIME-WAIT sockets）參考連結
-
測試來看，開啟tcp_tw_reuse並沒有解決埠被佔滿的問題，所以開啟了更激進的tcp_tw_recycle，至此埠占用顯著降低，問題解決，由於我們接入層並不是用的NAT，所以這個配置不會影響服務。
結論
- 通過測試發現nginx對grpc的反向代理支援的不夠理想，從nginx到後端server大部分請求不能保持長連線
- 當用nginx做接入層反向代理時，對tcp引數調優可以避免埠占滿等問題的發生