Zero window (khoảng dừng dễ nhầm là truyền lại) Zero window, often mistaken for retransmission

ID nguyên nhân rt-zero-window · Phụ trách chính Phát triển client (Đội phát triển game) · Phối hợp Phát triển server (Đội phát triển game), Hạ tầng server (Đội hạ tầng)

Mở thẻ gốc có hình minh họa và thí nghiệm →

Nếu chương trình bên nhận không đọc socket kịp khiến bộ đệm đầy, bên gửi sẽ ngừng gửi và chỉ gửi zero window probe. Đường truyền không có vấn đề gì.

Vì sao Client bị đứng khung hình, thread server bị chặn nên không đọc được socket → Dẫn đến Cửa sổ nhận về 0 nên bên gửi ngừng gửi và chỉ gửi probe (khoảng cách thưa dần) → Trên màn hình Đứng hình rồi tua nhanh. Bản bắt gói có “ZeroWindow” và không có mất gói

Triệu chứng: Đứng hình, Tua nhanh
Yếu tố: Ngưng trệ
Ai gặp phải: Chỉ mình tôi, Cả server
Khi nào: Khi đông người, Thỉnh thoảng bất chợt
Phụ trách: Phụ trách chính Phát triển client (Đội phát triển game) · Phối hợp Phát triển server (Đội phát triển game), Hạ tầng server (Đội hạ tầng)
Việc cần làm (Đội phát triển game): Trong bản bắt gói, xem bên gửi ZeroWindow (bên không đọc được socket) trước; nhận dữ liệu mạng trên một thread riêng và đọc liên tục; đặt bộ đệm nhận kích thước phù hợp. Client: xử lý nguyên nhân gây đứng khung hình như loading, GC. Server: xử lý nguyên nhân làm thread đọc socket bị chặn.
Việc cần làm (Đội hạ tầng): Thêm TcpExtTCPToZeroWindowAdv trong nstat của server (số lần server báo cửa sổ nhận bằng 0) vào giám sát (nếu tăng thì lỗi ở phía server, chuyển cho bên phát triển server), cung cấp bản bắt gói phía server.
Trên đồ thị: Đứt quãng rồi dồn về · Lượng dữ liệu nhận theo từng kết nối, số lần zero window
Chỗ cần xem: Trong bản bắt gói, tìm bên báo cửa sổ bằng 0 bằng filter Wireshark tcp.analysis.zero_window. Trong nstat của server, xem riêng TcpExtTCPToZeroWindowAdv (server báo cửa sổ 0) và TcpExtTCPWinProbe (server gửi probe khi phía bên kia báo cửa sổ 0); xem Recv-Q của socket server (số byte chương trình chưa đọc, trong ss)
Đúng nếu: trong khoảng dừng không có truyền lại, chỉ có zero window và probe đi lại. TcpExtTCPToZeroWindowAdv của server hoặc Recv-Q của socket server tăng → server không đọc kịp; TcpExtTCPWinProbe tăng → client không đọc kịp
Loại trừ nếu: bản bắt gói không có zero window và cùng dữ liệu được gửi lại → nguyên nhân thuộc về mất gói hoặc truyền lại không cần thiết
Cách kiểm tra: Kiểm tra bằng công cụ hạ tầng (không cần code game)
Sự cố thực tế: Roblox 2021: Sự cố 73 giờ của Roblox: tranh chấp trong cụm service discovery (Consul)

Nguồn

RFC 9293: Transmission Control Protocol (TCP) IETF
Khi cửa sổ nhận bằng 0, bên gửi gửi zero window probe, và khoảng cách giữa các probe tăng theo cấp số nhân
7.5. TCP Analysis Wireshark
TCP ZeroWindow: gói tin bên nhận báo cửa sổ bằng 0 để bảo bên gửi ngừng gửi
Display Filter Reference: Transmission Control Protocol Wireshark
Bộ lọc hiển thị tcp.analysis.zero_window, tcp.analysis.zero_window_probe
SNMP counter Linux kernel
TcpExtTCPToZeroWindowAdv: số lần báo cửa sổ nhận chuyển từ giá trị khác 0 về 0
net/ipv4/proc.c Linux kernel
Tên counter trong nstat: TCPToZeroWindowAdv, TCPWinProbe
net/ipv4/tcp_output.c Linux kernel
TCPWinProbe: tăng mỗi lần gửi probe (tcp_send_probe0) khi cửa sổ nhận của phía bên kia bằng 0
net/ipv4/tcp_diag.c Linux kernel
Với một kết nối, Recv-Q trong ss là số byte đã nhận nhưng chương trình chưa đọc

Nguyên nhân nên xem cùng

Cùng tầng: Nguyên nhân gốc của truyền lại TCP

Nguyên nhân ở tầng khác gây cùng triệu chứng (Đứng hình)

Frame time vọt lên L1 Tiến trình game phía client
Thu gom rác (GC) phía client L1 Tiến trình game phía client
Tải đồng bộ trên main thread và biên dịch shader L1 Tiến trình game phía client
Ổ lưu trữ chậm khiến streaming asset không theo kịp L1 Tiến trình game phía client
Kiểm tra của module bảo mật game (anti-cheat) L1 Tiến trình game phía client
Chuyển đổi Wi-Fi ↔ LTE hoặc 5G L2 OS và thiết bị phía client
Thiếu bộ nhớ và swap phía client L2 OS và thiết bị phía client
Thiếu bộ nhớ đồ họa (VRAM) L2 OS và thiết bị phía client

Xem thẻ gốc có hình minh họa và thí nghiệm