Kiểm thử WebSocket: kết nối dài, heartbeat và reconnect storm

Lab cần biết hệ thống mở được bao nhiêu connection mỗi giây, duy trì bao nhiêu phiên, chuyển bao nhiêu message với latency mục tiêu và phục hồi ra sao. “Socket connected” không chứng minh subscription, authentication hoặc message delivery đúng.

Tách HTTP Upgrade/TLS handshake, application authentication, subscription, steady message và close/reconnect. Mỗi giai đoạn có bottleneck khác nhau ở client, load balancer, gateway, application hoặc broker.

Topology gồm client generator phân tán, DNS/load balancer/WAF, WebSocket service, authentication, broker/cache/database và telemetry. Capture ở trước/ sau gateway; đo resource trên từng tier và backend dependency.

Nếu dùng TLS, ghi termination point, session resumption và certificate. Nếu sticky session hoặc shared state, kiểm tra node loss và rebalance. Đồng bộ clock giữa generator và server để đo one-way/message latency đáng tin cậy.

Ghi connection ramp, concurrency, session duration, message direction/rate/size, fan-out, think time, heartbeat, idle timeout và reconnect backoff. Phân bố không nên đồng đều giả tạo nếu production có burst theo sự kiện.

Khóa HTTP/TLS version, compression, authentication, LB timeout, kernel/socket limit, autoscaling, broker partitions và database pool. Client generator cũng cần CPU/file descriptor headroom; nếu generator bão hòa, kết quả không phản ánh SUT.

Đo connection success, upgrade/auth latency, connection rate, concurrent active sessions, message throughput, end-to-end latency p50/p95/p99, loss/duplicate/order, disconnect reason và recovery time. Theo dõi CPU, memory, file descriptors, event-loop lag, queue depth và backend saturation.

Gắn message ID/timestamp để xác nhận delivery. Kết hợp client result, access/application log, distributed trace và broker metrics. Báo cả attempted và successful connection; chỉ báo active count có thể che retry liên tục.

• Giai đoạn: TLS/Upgrade · Rủi ro: CPU, handshake timeout · KPI: Success, p95
• Giai đoạn: Authentication · Rủi ro: Identity/backend bottleneck · KPI: Auth error/latency
• Giai đoạn: Subscription · Rủi ro: State không nhất quán · KPI: Subscribe success
• Giai đoạn: Idle/heartbeat · Rủi ro: Timeout hoặc zombie session · KPI: Disconnect reason
• Giai đoạn: Message burst · Rủi ro: Queue/backpressure · KPI: p99, drop
• Giai đoạn: Fan-out · Rủi ro: Broker/node imbalance · KPI: Delivery ratio
• Giai đoạn: Node restart · Rủi ro: Reconnect đồng loạt · KPI: Recovery, error
• Giai đoạn: Network flap · Rủi ro: Retry amplification · KPI: Attempt/success ratio

Chạy functional ít client, xác nhận open/message/close và negative authentication. Tăng connection rate theo bước tới concurrency mục tiêu, giữ steady state đủ lâu để quan sát memory leak và timeout. Sau đó tăng message rate độc lập.

Thử upstream/downstream, small/large payload, fan-out, slow consumer và burst. Với compression, chạy A/B cùng nội dung để đánh đổi bandwidth/CPU. Autoscaling test phải ghi warm-up và thời gian node mới thực sự nhận session.

Restart một node, mất LB/backend, chèn latency/loss và ngắt mạng client trong lab. Client phải dùng jittered exponential backoff; nếu mọi client retry cùng chu kỳ, recovery có thể tự tạo outage lần hai.

Tăng số client bị ngắt theo bước 10–25–50–100%, đặt kill threshold theo CPU/error. Đo connection attempt, auth load, backend queue và thời gian trở lại steady state. Kiểm tra message bị mất/trùng trong khoảng reconnect theo semantics đã công bố.

• [ ] Chốt protocol, auth, heartbeat và timeout.
• [ ] Xác nhận generator headroom.
• [ ] Chạy functional và negative cases.
• [ ] Ramp connection tới steady target.
• [ ] Tăng message/fan-out riêng.
• [ ] Thử slow consumer và backpressure.
• [ ] Tạo node/network failure theo bước.
• [ ] Lưu raw result, log, trace và verdict.

Capacity phụ thuộc runtime, kernel, LB, TLS, payload, session duration và backend. Một con số concurrent connection không có traffic profile gần như không dùng được để sizing.

WebSocket delivery semantics thường do ứng dụng xây dựng; protocol không tự bảo đảm exactly-once. Kết luận mất/trùng message phải gắn với thiết kế acknowledgment và persistence.