遊戲 Lag 白皮書 › TCP 重傳的根本原因
中間設備超過處理上限（防火牆、IPS、DDoS 防護） Inline appliance PPS / CPU overload
原因 ID rt-appliance-pps · 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
防火牆、入侵防禦設備（IPS）、DDoS 防護設備會逐一檢查經過的封包。從超過檢查能力的那一刻起，處理不了的封包就會被丟棄。
為什麼 尖峰時段或活動期間，每秒湧入數十萬個以上的小型遊戲封包，或是檢查規則太重 → 於是 設備的 CPU 或每秒封包數達到上限，封包在設備上被丟棄。誤判時連正常封包也會被擋 → 畫面上 該設備後方的所有伺服器同時出現定格、瞬移，只在人潮湧入時加劇
- 症狀
- 定格, 快轉, 瞬移, 斷線
- 因素
- 遺失, 延遲
- 誰會遇到
- 整個伺服器, 特定地區／電信業者
- 何時
- 晚間尖峰時段, 人潮湧入時
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 把遊戲的流量模式（port、封包大小、每秒封包數）提供給基礎設施團隊、把一個 tick 內要送的小訊息合併後一次送出，減少封包數。
- 基礎設施團隊要做的事
- 把設備的 CPU、每秒封包數、丟棄計數器與遊戲指標放在一起看、以小封包為基準規劃設備容量、讓遊戲 port 不經過重度檢查、讓 DDoS 防護規則配合遊戲流量模式。
- 數值參考
- 設備規格上的「10Gbps」，很多是以 1,500 位元組的大封包為基準標示的。100 位元組左右的遊戲封包在相同頻寬下，封包數多出 10 倍以上，所以即使線路看起來很空，每秒封包數上限也會先被用完。
- 圖表上
- 碰到上限後持平 · 設備每秒封包數與 CPU 使用率、設備丟棄數
- 查看位置
- 查看設備的 CPU、每秒封包數與丟棄計數器，並以相同間隔比較設備前後交換器 port 的封包數。與同時上線人數、伺服器重傳率疊在同一個畫面上看
- 符合的跡象
- 尖峰或活動時，設備的每秒封包數或 CPU 停在某個值無法再往上，從設備出來的封包比進去的少，同一時間該設備後方所有伺服器的重傳率一起上升
- 不符合的跡象
- 設備前後的封包數相同、設備也沒有丟棄時是其他原因。伺服器的 NIC 丟棄計數器或 softnet dropped 增加時是「接收端伺服器主機丟棄封包」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- RFC 2544: Benchmarking Methodology for Network Interconnect Devices IETF
設備效能必須以包含最小與最大尺寸在內的多種訊框大小測試（處理效能會隨封包大小而不同）
相關原因
同一層：TCP 重傳的根本原因
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片