Kiểm thử WebSocket: connection scale, heartbeat và reconnect storm

Test phải xác minh HTTP Upgrade thành công, connection được duy trì đúng, ping/pong và close handshake hoạt động, message đến đúng client với thứ tự/độ trễ mong muốn. Nếu ứng dụng có acknowledgement riêng, cần tách delivery ở WebSocket transport khỏi xử lý nghiệp vụ.

Ở sự cố, hỏi có bao nhiêu connection bị đóng, client phát hiện sau bao lâu, reconnect có backoff/jitter hay đồng loạt, session/subscription được phục hồi thế nào và message trong cửa sổ chuyển tiếp bị mất hay lặp.

Mô hình tối thiểu gồm client emulator, load balancer/reverse proxy, cụm WebSocket server, broker/backend và collector. Dựng hai baseline: nối trực tiếp server và qua full chain. Nếu có TLS termination hoặc sticky session, đánh dấu từng hop và nơi giữ state.

Gắn connection ID, logical client ID, message ID, sequence và timestamp. Thu metric ở client, proxy, server, broker; capture ở lab tại hai phía proxy. Network emulator giúp tiêm RTT, jitter, loss, bandwidth constraint và half-open path.

Ghi HTTP/TLS version, cipher, compression extension, frame/message size, text/binary, fragmentation, connection ramp, lifetime, heartbeat interval và idle timeout từng hop. Khóa auth/token lifetime, subscription count, room/fan-out pattern và server think time.

Traffic profile cần nêu active connections, new connections/s, message/s hai chiều, payload distribution, fan-out, burst shape và slow-consumer ratio. Reconnect policy phải có backoff, jitter, maximum attempts, resume token và deadline; đổi một biến mỗi pha.

KPI connection gồm handshake success/latency, active connections, churn, unexpected close và close-code taxonomy. KPI message gồm send/receive rate, end-to-end latency p50/p95/p99, loss, duplicate, out-of-order và acknowledgement delay. KPI hệ thống gồm queue depth, event-loop lag, CPU, memory, socket/file descriptor và broker lag.

Mốc · Ý nghĩa · Bằng chứng T0 · Fault hoặc disconnect · Trigger/log T1 · Client phát hiện · Ping timeout/close T2 · Reconnect bắt đầu · Client attempt log T3 · Session/subscription phục hồi · Server/broker state T4 · Message ổn định · Sequence/latency series

Pass/fail phải gắn với workload: connection success không dưới ngưỡng, message loss/duplicate theo policy, p99 trong budget và reconnect peak không vượt retry budget hoặc làm backend kiệt tài nguyên.

Tình huống · Mục tiêu · Rủi ro cần quan sát Ramp connection · Scale · Handshake queue, port exhaustion Heartbeat đồng pha · Burst · CPU/network spike Slow consumer · Backpressure · Queue growth, memory Proxy idle timeout · Lifecycle · Disconnect giả im lặng Server drain/restart · Resilience · Reconnect storm Broker pause/failover · Delivery · Loss/duplicate/order Token expiry · Authentication · Refresh loop

Mỗi case cần positive control và fault trigger có timestamp. Lặp với message nhỏ/lớn và fan-out thấp/cao; cùng số connection nhưng fan-out khác có thể tạo tải backend rất khác.

Pha baseline dùng ít client, xác minh upgrade, ping/pong, close và sequence. Pha scale tăng connection theo ramp thực tế; pha messaging tăng rate/fan-out; pha impairment thêm network condition từng biến. Pha resilience drain/restart proxy, server và broker.

Pha reconnect ngắt một tỷ lệ hoặc toàn bộ client, thử backoff/jitter khác nhau; pha soak giữ connection qua token rotation, idle period và deployment. Mỗi run lưu client seed, traffic profile, version, config, raw latency, sequence gap và resource series.

Không tạo reconnect đồng loạt nếu production client có jitter; nhưng phải có negative test để biết blast radius. Theo dõi connection attempts/s, auth requests/s, subscription replay, broker read và database/cache hit. Pass/fail nên giới hạn cả peak và thời gian backlog drain.

Với slow consumer, điều khiển read rate hoặc tạm dừng đọc. Xác minh queue limit, drop/disconnect policy và khả năng cô lập một client chậm khỏi client khác. Ghi rõ delivery semantics ở tầng ứng dụng; WebSocket tự nó không bảo đảm persistence sau reconnect.

• [ ] Chốt topology, protocol từng hop và state ownership.
• [ ] Gắn logical client, connection và message ID.
• [ ] Khóa ramp, heartbeat, payload, fan-out và retry policy.
• [ ] Chạy baseline direct và qua proxy.
• [ ] Tăng connection/message rate từng bậc.
• [ ] Thử slow consumer và network impairment.
• [ ] Drain/restart từng thành phần; ghi T0–T4.
• [ ] Gây reconnect có jitter và negative case đồng pha.
• [ ] Đối soát sequence, duplicate, broker lag và resource.
• [ ] Lưu raw result, version, config và điều kiện đo.

Kết quả chỉ áp dụng cho client library, proxy/server/broker version, topology và message profile đã thử. Một generator giữ được nhiều socket không chứng minh application xử lý đúng subscription, auth và fan-out. Cần giám sát chính generator để tránh nhầm giới hạn nguồn phát với DUT/SUT.

Không suy ra exactly-once từ WebSocket. Nếu ứng dụng yêu cầu replay/deduplication, phải kiểm thử protocol ứng dụng và storage liên quan. Kết luận “không mất message” chỉ đúng trong tập message ID và cửa sổ quan sát đã ghi.

• Upgrade handshake: Chuyển từ HTTP sang WebSocket.
• Ping/Pong: Control frame hỗ trợ kiểm tra liveness.
• Reconnect storm: Nhiều client kết nối lại cùng lúc sau sự cố.
• Backpressure: Downstream xử lý chậm hơn tốc độ message đến.
• Fan-out: Một message được phân phối tới nhiều client.
• Slow consumer: Client đọc chậm, làm queue tăng.
• Close code: Mã giải thích lý do đóng connection.