한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

Zero window（看起來像重傳的停頓） Zero window, often mistaken for retransmission

原因 ID rt-zero-window · 主要負責 遊戲開發團隊（用戶端開發） · 協同遊戲開發團隊（伺服器開發）, 基礎設施團隊（伺服器基礎設施）

接收端程式沒有及時讀取 socket、緩衝區塞滿時，傳送端會停止傳送，只送出 zero window probe。線路本身沒有問題。

為什麼 用戶端的畫格更新停住、伺服器執行緒卡住，導致無法讀取 socket → 於是接收視窗變成 0，傳送端停止傳送、只送 probe（間隔越來越長） → 畫面上 定格後快轉。封包擷取中看得到「ZeroWindow」，沒有遺失

症狀: 定格, 快轉
因素: 停滯
誰會遇到: 只有我, 整個伺服器
何時: 人潮湧入時, 偶爾隨機發生
負責單位: 主要負責 遊戲開發團隊（用戶端開發） · 協同遊戲開發團隊（伺服器開發）, 基礎設施團隊（伺服器基礎設施）
遊戲開發團隊要做的事: 先從封包擷取中送出 ZeroWindow 的一方（無法讀取 socket 的一方）開始確認、在獨立的執行緒持續讀取網路接收資料、把接收緩衝區設為適當大小。用戶端：解決載入、GC 這類讓畫格更新停住的原因。伺服器：解決讀取 socket 的執行緒卡住的原因。
基礎設施團隊要做的事: 把伺服器 nstat 的 TcpExtTCPToZeroWindowAdv（伺服器通告接收視窗為 0 的次數）加入監控（增加時問題在伺服器端，轉交伺服器開發）、提供伺服器端的封包擷取。
圖表上: 中斷後一次湧入 · 各連線的接收量、zero window 次數
查看位置: 在封包擷取中用 Wireshark 篩選條件 tcp.analysis.zero_window 找出通告視窗為 0 的一方。伺服器的 nstat 則分開查看 TcpExtTCPToZeroWindowAdv（伺服器通告視窗為 0）與 TcpExtTCPWinProbe（針對對方的視窗 0 送出 probe），並查看伺服器 socket 的 Recv-Q（ss 中程式尚未讀取的位元組）
符合的跡象: 停住期間沒有重傳，只有 zero window 與 probe 往來。伺服器的 TcpExtTCPToZeroWindowAdv 或伺服器 socket 的 Recv-Q 增加時，是伺服器沒有及時讀取；TcpExtTCPWinProbe 增加時，是用戶端沒有及時讀取
不符合的跡象: 擷取中沒有 zero window、同樣的資料被重送時，原因在遺失或不必要的重傳
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
實際案例: Roblox 2021: Roblox 73 小時事故：服務探索（Consul）叢集的資源競爭

出處

RFC 9293: Transmission Control Protocol (TCP) IETF
接收視窗為 0 時，傳送端會送出 zero window probe，probe 間隔以指數方式拉長
7.5. TCP Analysis Wireshark
TCP ZeroWindow：接收端通告視窗為 0、讓傳送端停止傳送的封包
Display Filter Reference: Transmission Control Protocol Wireshark
tcp.analysis.zero_window、tcp.analysis.zero_window_probe 顯示篩選條件
SNMP counter Linux kernel
TcpExtTCPToZeroWindowAdv：接收視窗從非 0 的值改為通告 0 的次數
net/ipv4/proc.c Linux kernel
nstat 顯示的計數器名稱 TCPToZeroWindowAdv、TCPWinProbe
net/ipv4/tcp_output.c Linux kernel
TCPWinProbe：對方接收視窗為 0 時，每送出一個 probe（tcp_send_probe0）就增加
net/ipv4/tcp_diag.c Linux kernel
已連線的 socket，ss 的 Recv-Q 是已收到但程式尚未讀取的位元組數

Zero window（看起來像重傳的停頓） Zero window, often mistaken for retransmission

出處

相關原因

同一層：TCP 重傳的根本原因

同一症狀（定格）在其他層的原因