遊戲 Lag 白皮書 › L5 資料中心網路設備
負載平衡器閒置逾時 Load balancer idle timeout
原因 ID dc-lb-idle · 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（用戶端開發）, 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
負載平衡器會在一段時間後清除閒置連線。遊戲還以為連線仍然維持著，結果就斷線了。
為什麼 玩家有一段時間完全沒送出任何封包（開著對話視窗、暫離） → 於是 負載平衡器清理閒置連線（常見的預設值為 60～350 秒） → 畫面上 再次移動的瞬間斷線
- 症狀
- 斷線
- 因素
- 遺失
- 誰會遇到
- 只有我, 整個伺服器
- 何時
- 閒置一段時間後
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（用戶端開發）, 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 用戶端：以最短閒置逾時一半以下的間隔送出心跳封包（位於 60 秒逾時的 ALB 後方時，就是 30 秒以下），斷線時自動重新連線。伺服器：回應心跳封包，一段時間沒收到就先清理連線，用 session token 接續連線。
- 基礎設施團隊要做的事
- 確認路徑上負載平衡器的閒置逾時數值並提供給遊戲團隊，必要時調長。
- 數值參考
- AWS ALB 的預設值是 60 秒，NLB 是 TCP 350 秒、UDP 120 秒，Azure Load Balancer 是 TCP 4 分鐘。ALB 與 NLB 的 TCP 數值可以修改，但 NLB 的 UDP 120 秒無法修改。ALB 時間到時也會關閉伺服器端的連線；NLB 則是默默清除，伺服器很容易在不知情的狀態下留著連線。
- 圖表上
- 連線同時大量中斷 · 斷線次數、斷線前的閒置時間
- 查看位置
- 確認路徑上負載平衡器的閒置逾時設定值，並彙整每條斷線連線從最後一個封包到斷線所經過的時間。若是 AWS NLB，也查看 CloudWatch 的 TCP_ELB_Reset_Count（負載平衡器送出的 RST 數）
- 符合的跡象
- 斷線連線的閒置時間集中在設定值（ALB 60 秒、NLB TCP 350 秒等）剛過之後，閒置超過該時間再移動就能重現。NLB 在該時間點 TCP_ELB_Reset_Count 增加
- 不符合的跡象
- 與閒置時間無關的斷線，就不是這個原因。沒有經過負載平衡器、直接連線的伺服器集中在 350 秒附近斷線時是「雲端安全群組的連線追蹤過期」，問題在玩家家中的分享器時是「NAT mapping 過期」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- Edit attributes for your Application Load Balancer AWS
ALB 閒置逾時預設 60 秒（1～4,000 秒），用戶端與目標的連線在這段時間內都沒有流量時，負載平衡器會關閉連線 - Network Load Balancers AWS
NLB TCP 閒置預設 350 秒（60～6,000 秒），超過後只停止追蹤，之後有資料進來就回 RST，UDP flow 的 120 秒無法變更 - Configure load balancer TCP reset and idle timeout Microsoft Azure
Azure Load Balancer 閒置逾時預設 4 分鐘（4～100 分鐘），超過後不保證維持 session，TCP reset 為選用設定 - CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count：負載平衡器產生並送出的 RST 封包數
相關原因
同一層：L5 資料中心網路設備
同一症狀（斷線）在其他層的原因
查看含圖解與實驗的完整版卡片