閒置後的慢啟動（slow start） Slow start after idle

原因 ID sk-slowstart · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）

連線閒置一段時間後，TCP 會再次縮小壅塞視窗（一次能送出的量），所以突然要送大量資料時，得分成好幾次送出。

為什麼 透過原本閒置的連線送出進入城鎮等大量資料 → 於是壅塞視窗已縮小，只能分成多個往返傳送 → 畫面上 剛進入時，周圍的角色與 NPC 晚了好幾個往返才出現（伺服器越遠越明顯）

症狀: 輸入延遲, 看不見／幽靈物件
因素: 延遲
誰會遇到: 只有我
何時: 移動中／切換地圖時, 閒置一段時間後
負責單位: 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 減少進入時的資料量（先送真正必要的部分）。
基礎設施團隊要做的事: 關閉 tcp_slow_start_after_idle（Linux，整台伺服器的設定）。
數值參考: 閒置超過 RTO 時壅塞視窗就開始縮小，閒置很久的話會降到約 14KB（10 個封包）。這時 100KB 無法一次送出，要分成 3 個往返傳送。
圖表上: 只有部分偏高 · 剛進入時的傳送時間（RTT 較長的玩家）
查看位置: 確認 sysctl net.ipv4.tcp_slow_start_after_idle 的值，並在玩家閒置後進入某個區域的瞬間，看該連線 ss -ti 中的 cwnd（壅塞視窗）是否變小
符合的跡象: 設定為 1（預設），閒置後進入的瞬間 cwnd 降到 10 左右，傳送被拆成多個往返。RTT 越長的玩家，周圍物件出現得越晚，改成 0 後就不再發生
不符合的跡象: cwnd 維持在高檔仍然很晚出現時，要查伺服器端的進入處理（「進入密集區域時的生成暴增」）
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

IP Sysctl Linux kernel
tcp_slow_start_after_idle 預設開啟，閒置達一個 RTO 就縮小壅塞視窗（RFC 2861 的做法）
RFC 5681: TCP Congestion Control IETF
超過 RTO 沒有送出資料時，把壅塞視窗縮小到重新啟動視窗 min(IW, cwnd) 以下，並重新慢啟動
RFC 6928: Increasing TCP's Initial Window IETF
初始視窗 10 個區段，最多 14,600 位元組
ss(8) — Linux manual page iproute2
-i 的 cwnd（壅塞視窗）、ssthresh（慢啟動門檻）