Kiểm thử TCP Zero Window: slow receiver, backpressure và phục hồi

RFC 9293 mô tả receiver quảng bá cửa sổ nhận để giới hạn lượng dữ liệu chưa được ACK/tiếp nhận mà sender có thể gửi. Khi cửa sổ bằng 0, sender phải dừng gửi dữ liệu mới và dùng cơ chế persist/zero-window probe để tránh deadlock nếu window update bị mất. Đây là flow control giữa hai endpoint, khác với congestion control phản ứng trước trạng thái mạng.

Zero Window không tự động chứng minh lỗi NIC, thiếu bandwidth hay packet loss. Nguyên nhân thường nằm ở ứng dụng đọc socket chậm, thread/CPU bị nghẽn, garbage collection, storage downstream, giới hạn memory, hoặc backpressure được thiết kế. Một trace đơn lẻ chỉ cho thấy triệu chứng trên connection; cần metric ứng dụng và hệ điều hành để tìm nguyên nhân.

Ngược lại, loss/retransmission hoặc latency cao có thể kéo dài transaction và làm buffer tích tụ gián tiếp. Vì vậy test phải thay đổi riêng tốc độ đọc phía nhận và impairment mạng, rồi so signature. Không nên kết luận bằng nhãn phân tích của một công cụ capture mà không kiểm tra sequence, ACK và window scaling.

Topology cơ bản gồm sender, network emulator, receiver có khả năng điều khiển tốc độ đọc và packet capture hai phía. Mở rộng thực tế thêm reverse proxy/load balancer hoặc service mesh ở giữa. Capture tại cả hai biên giúp thấy middlebox có thay đổi ACK/window, timeout connection hay reset khi zero window kéo dài.

Ở receiver, thu socket receive queue, process/thread state, CPU, memory, GC, I/O wait và application read rate. Ở sender, thu send queue, bytes-in-flight, retransmission, application write latency và timeout. Gắn transaction ID vào payload/log để nối trace packet với request cụ thể.

Đồng bộ clock giữa packet capture và metric host. Nếu TLS che payload, vẫn có thể đo TCP sequence/window nhưng cần log transaction ở endpoint để phân biệt request. Với nhiều connection, lưu 5-tuple hoặc connection ID; không trộn trạng thái của connection khỏe với connection zero window.

Biến ứng dụng gồm message/object size, write pattern, concurrency, request/response direction, tốc độ receiver đọc, worker pool, queue downstream và timeout. Một response 1 KB ít khi làm cạn receive buffer như stream hàng trăm MB; throughput tổng giống nhau nhưng phân bố connection khác nhau tạo hành vi khác.

Biến TCP/host gồm receive buffer, autotuning, window scale, MSS, delayed ACK, keepalive và OS/kernel. RFC 7323 định nghĩa Window Scale để mở rộng cửa sổ; khi đọc trace phải áp scale factor đã thương lượng trong SYN. Giá trị window thô trong packet không thể so trực tiếp nếu bỏ qua scaling.

Biến mạng gồm RTT, jitter, packet loss, reordering, bandwidth và middlebox idle timeout. Thay từng biến độc lập. Nếu vừa hạ read rate vừa thêm loss, không thể tách zero window do ứng dụng với throughput giảm do retransmission.

KPI chính là thời gian từ receive window bắt đầu co đến zero, tổng zero-window duration, số probe, thời gian từ receiver đọc lại đến window update, và thời gian transaction phục hồi. Song song đo application read/write rate, socket queue occupancy, throughput hữu ích, tail latency, timeout và reset.

KPI · Điểm đo · Bằng chứng · Ý nghĩa Advertised window · Packet trace receiver→sender · ACK/window + scale · Flow-control state Receive queue · Receiver OS · Socket metric · Buffer có bị lấp đầy App read rate · Receiver process · Application/runtime metric · Consumer có theo kịp Persist/probe · Sender trace · Sequence/timestamp · Sender tránh deadlock Recovery time · Packet + transaction log · Window update → success · Dịch vụ phục hồi thực Timeout/reset · Hai endpoint/middlebox · Log + flags · Policy cắt connection Goodput · Payload ledger · Bytes thành công/thời gian · Giá trị ứng dụng

Chuỗi bằng chứng tốt phải cho thấy receiver read rate giảm trước, queue tăng, advertised window co, sender dừng dữ liệu, probe xuất hiện, receiver đọc lại, window update được phát và transaction tiếp tục. Nếu thứ tự khác, cần xem lại giả thuyết.

Tạo baseline receiver đọc liên tục, sau đó pause đọc theo khoảng cố định, giảm read rate dần, gây CPU/GC/I/O downstream, và lặp qua proxy. Thêm một nhánh chỉ gây network loss/RTT nhưng không làm chậm receiver để xây signature đối chứng.

Ca thử · Thay đổi · Kỳ vọng · Rủi ro cần phát hiện Baseline · Receiver đọc đủ nhanh · Không zero window · Sai cấu hình nền Pause ngắn · Dừng read có kiểm soát · Window co rồi phục hồi · Recovery chậm Pause dài · Vượt idle/app timeout · Probe hoặc timeout rõ · Reset không quan sát được Slow disk · Hạ downstream consume · Queue tăng có tương quan · Backpressure lan truyền Network loss only · Thêm loss, read bình thường · Retransmission, không nhất thiết zero · Nhầm congestion với flow control Nhiều connection · Một số receiver chậm · Cô lập theo connection · Head-of-line ở worker pool Qua proxy · Thêm middlebox · Hai TCP leg có state riêng · Proxy che/cắt connection

Với HTTP/2 hoặc giao thức multiplexed trên một connection TCP, một receiver chậm có thể ảnh hưởng nhiều stream ở transport layer. Cần ghi stream/request latency cùng connection state. Không suy rộng trực tiếp sang QUIC vì QUIC có flow control ở connection/stream và chạy trên UDP.

Pha A ghi baseline với read rate lớn hơn offered rate. Pha B pause receiver đủ để cửa sổ co về zero; xác nhận sender dừng data và không busy-loop. Pha C mở lại receiver, đo window update và transaction completion. Pha D lặp với loss/RTT, proxy và timeout. Pha E tăng concurrency để thấy backpressure có lan sang connection khỏe hay không.

Pass/fail không nhất thiết yêu cầu “không bao giờ Zero Window”. Backpressure có thể là hành vi đúng khi consumer chậm. Tiêu chí hợp lý là không mất dữ liệu, không deadlock, không lan lỗi ngoài phạm vi, có telemetry, và phục hồi trong ngân sách sau khi bottleneck được gỡ.

• Ghi OS/kernel, socket buffer, window scaling và timeout.
• Đồng bộ clock; bật capture ở cả hai phía middlebox.
• Phát payload có sequence/test ID và biết tổng byte.
• Giảm hoặc pause application read, không chặn toàn bộ host ngoài ý muốn.
• Theo dõi receive/send queue, CPU, GC, I/O và worker pool.
• Xác nhận advertised window sau khi áp scale factor.
• Ghi zero-window probe, interval và response.
• Mở lại read; đo window update, goodput và transaction recovery.
• Lặp với network impairment riêng để xây đối chứng.
• Xuất pcap, host metric, app log và verdict trên cùng timeline.

Khi thấy Zero Window, xác định endpoint quảng bá window bằng 0. Kiểm tra process nào sở hữu socket, receive queue và read rate. Sau đó đối chiếu CPU/GC/I/O/downstream. Nếu qua proxy, coi mỗi leg TCP là connection riêng; window ở leg backend không nhất thiết xuất hiện giống hệt ở client leg.

Quan sát · Giả thuyết ưu tiên · Kiểm tra tiếp Queue nhận đầy, app read giảm · Slow consumer · Thread/GC/I/O/downstream Loss cao, window vẫn mở · Network congestion/loss · Retransmission, RTT, cwnd Zero window chỉ sau proxy · Proxy buffer/policy · Metric từng leg, timeout Window mở lại nhưng app treo · Lỗi application state · Request log, lock/queue Probe không được phản hồi · Path/middlebox/endpoint · Capture hai phía, firewall Nhiều connection cùng bị · Shared resource bottleneck · CPU, worker pool, storage

Khắc phục phải nhắm đúng tầng: tăng buffer chỉ trì hoãn cạn kiệt nếu consumer vẫn chậm; tăng timeout có thể giữ nhiều connection treo hơn. Ưu tiên sửa throughput của consumer, queue bound, admission control và backpressure end-to-end; mọi thay đổi buffer/timeout cần benchmark lại memory và tail latency.

Packet trace cho thấy transport behavior, không tự chứng minh nguyên nhân trong code. Metric host có thể bị sampling quá thưa và bỏ lỡ pause ngắn. TLS, proxy và container network namespace làm mapping process–connection khó hơn; cần correlation ID và capture đúng namespace.

Kết quả chỉ áp dụng cho OS, kernel, runtime, buffer, protocol, middlebox, RTT/loss và traffic profile đã thử. Một pass ở single connection không chứng minh pass khi hàng nghìn connection cùng backpressure. Không dùng Zero Window làm nhãn lỗi chung cho mọi transaction chậm.

• Receive window (rwnd): Dung lượng nhận còn trống do receiver quảng bá.
• Zero Window: rwnd bằng 0, sender tạm dừng dữ liệu mới.
• Persist timer: Cơ chế giúp sender thăm dò khi window bằng 0.
• Zero-window probe: Segment kiểm tra receiver đã mở lại window hay chưa.
• Backpressure: Tín hiệu ngược khi downstream tiêu thụ chậm hơn upstream.
• Window Scale: Tùy chọn TCP mở rộng trường window sau bắt tay.
• Goodput: Lượng payload hữu ích hoàn tất trên đơn vị thời gian.