遊戲 Lag 白皮書 › L8 Socket 與協定

可靠 UDP 的重傳設定 Reliable-UDP tuning (KCP, ENet…)

原因 ID sk-reliable-udp · 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）

在含圖解與實驗的完整版中開啟卡片 →

在 UDP 上自行實作的重傳規則太保守時復原會變慢，太積極時反而讓線路更壅塞。

為什麼 重傳間隔、次數、視窗大小的設定與線路不相符 → 於是 復原太慢，或重複傳送讓壅塞惡化 → 畫面上 技能被吃、快轉、壅塞時 lag 更嚴重

症狀

吃指令／回檔, 快轉

因素

遺失, 延遲

誰會遇到

只有我

何時

偶爾隨機發生

負責單位

主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）

遊戲開發團隊要做的事

伺服器：依實測的往返時間決定重傳時機，並依重要程度分開通道。用戶端：套用與伺服器相同的重傳與通道設定。

圖表上

偶爾隨機飆高 · 可靠 UDP 的重傳比例、遊戲內 RTT

查看位置

在伺服器與用戶端記錄所用函式庫的每條連線統計（重傳次數、估計往返時間、重傳等待時間），並與同一玩家實際的線路遺失率（用 mtr 測得的值）比較

符合的跡象

重傳比例比實際線路遺失率高出好幾倍時是設定太積極；重傳等待時間是實測往返時間的好幾倍時是設定太保守

不符合的跡象

重傳比例與線路遺失率相近、等待時間也符合往返時間時，就不是設定問題。要查線路遺失本身

確認方式

需要遊戲伺服器／用戶端的 log 與指標

出處

1. RFC 8085: UDP Usage Guidelines IETF
   重傳可能加劇壅塞，因此應納入壅塞控制；往返時間以多次量測的平均（EWMA）估計，初始值 1 秒；計時器到期時降低傳送速率

相關原因

同一層：L8 Socket 與協定

• TCP HOL 阻塞
• TCP RTO 與指數退避
• Nagle 演算法 + 延遲 ACK
• 慢速用戶端造成的阻塞式傳送
• 慢速用戶端（slow consumer）的處理策略
• keepalive 預設值 2 小時
• UDP 封包的 IP 分段
• 閒置後的慢啟動（slow start）
• 壅塞控制造成傳送量驟降
• RST 強制關閉造成最後的資料遺失
• 阻塞式 I/O 架構
• SO_REUSEPORT 分配不均
• Windows UDP socket 的 WSAECONNRESET 錯誤

同一症狀（吃指令／回檔）在其他層的原因

• 時鐘同步誤差 L1 用戶端遊戲程式
• 雲端 NAT 閘道的連線與 port 上限 L5 資料中心網路設備
• 交換器 microburst L5 資料中心網路設備
• Ring buffer 不足 L6 伺服器網路卡
• 超過雲端 PPS 上限 L6 伺服器網路卡
• OOM killer L7 伺服器 OS（kernel）
• 系統時鐘跳動（NTP step） L7 伺服器 OS（kernel）
• 伺服器間連線的臨時 port 耗盡 L7 伺服器 OS（kernel）

查看含圖解與實驗的完整版卡片