遊戲 Lag 白皮書 › L5 資料中心網路設備
雲端安全群組的連線追蹤過期 Cloud security group connection tracking timeout
原因 ID dc-cloud-conntrack · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同 遊戲開發團隊（用戶端開發）, 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
雲端伺服器上的防火牆（安全群組）也會追蹤連線，閒置連線的追蹤項目會在一定時間後過期。即使是沒有經過負載平衡器、直接連線的伺服器，靜止不動的玩家也可能斷線。
為什麼 安全群組處於會追蹤遊戲連線的設定（只允許特定位址、限制輸出規則、經由 NLB 等） → 於是 連線閒置一段時間後追蹤項目過期，之後進來的封包被安全群組默默丟棄 → 畫面上 暫離後再移動時沒有反應，接著斷線。伺服器程式很長一段時間都沒察覺
- 症狀
- 斷線
- 因素
- 遺失
- 誰會遇到
- 只有我, 整個伺服器
- 何時
- 閒置一段時間後
- 負責單位
- 主要負責 基礎設施團隊（伺服器基礎設施） · 協同 遊戲開發團隊（用戶端開發）, 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 用戶端：以最短閒置逾時一半以下的間隔送出心跳封包（TCP 350 秒時為 175 秒以下，UDP 串流 180 秒時為 90 秒以下），斷線時自動重新連線。伺服器：回應心跳封包，一段時間沒收到就先清理連線，用 session token 接續連線。
- 基礎設施團隊要做的事
- 確認執行個體的連線追蹤時間（TcpEstablishedTimeout），必要時調長（UDP 最多 180 秒，無法再調長）；檢討不會產生追蹤的安全群組配置（遊戲 port 允許所有位址、輸出規則全部允許；經由 NLB 的連線仍會被追蹤）；換到新世代執行個體時進行閒置測試。
- 數值參考
- 以 AWS 為例，Nitro v6 執行個體類型預設在 350 秒後清除閒置 TCP 連線的追蹤項目（其他類型為 5 天）。UDP 的預設值為：請求與回應往返多次的 flow（串流）180 秒，只往單一方向送出或請求與回應只有一次的 flow 30 秒。
- 圖表上
- 連線同時大量中斷 · 斷線次數、斷線前的閒置時間
- 查看位置
- 確認執行個體的連線追蹤時間設定與安全群組規則（是否為會產生追蹤的配置），並彙整斷線連線的閒置時間。剛斷線時在伺服器用 ss -tnoi 查看該連線是否仍以 ESTABLISHED 殘留、重傳計時器（timer:(on,…)）在跑且 backoff 變大
- 符合的跡象
- 斷線連線的閒置時間集中在 TCP 350 秒、UDP 串流 180 秒、UDP 單向 30 秒剛過之後，伺服器端的 socket 沒偵測到斷線、仍以 ESTABLISHED 殘留（伺服器有資料要送時只會一直重傳）
- 不符合的跡象
- 安全群組處於不追蹤的配置（遊戲 port 允許所有位址、輸出規則全部允許、不經過 NLB）時，就不是這個原因。經過 NLB 時，與「負載平衡器閒置逾時」的數值比較
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- Amazon EC2 security group connection tracking AWS
TCP 閒置追蹤預設 350 秒（Nitro v6，其他為 43 萬 2,000 秒=5 天），UDP 單向 30 秒、串流 180 秒（最多 180），允許所有位址的規則不追蹤，經由 NLB 的連線一律追蹤 - Update the TCP idle timeout for your Network Load Balancer listener AWS
NLB 閒置逾時比目標執行個體的連線追蹤時間長時，執行個體端會先默默丟掉連線狀態 - ss(8) — Linux manual page iproute2
-o 的 timer:(on,…) 是重傳計時器，-i 的 backoff 是重傳等待時間加倍的次數
相關原因
同一層：L5 資料中心網路設備
同一症狀（斷線）在其他層的原因
查看含圖解與實驗的完整版卡片