Kiểm thử WebSocket ở quy mô lớn: handshake, backpressure và reconnect storm

Với HTTP/1.1, WebSocket mở bằng handshake Upgrade và phản hồi 101; với HTTP/2 theo RFC 8441, nó dùng Extended CONNECT trên một stream, không dùng cơ chế Upgrade/101. Sau handshake, ứng dụng trao đổi message hai chiều trên kênh duy trì lâu dài. Vì vậy phải trả lời riêng: hệ thống mở được bao nhiêu kết nối mỗi giây; giữ ổn định bao nhiêu phiên; xử lý message ở kích thước/tần suất nào; và chuyện gì xảy ra khi downstream chậm, proxy reset hoặc backend bị drain.

Không nên dùng duy nhất “concurrent connections” làm KPI. Một triệu kết nối idle khác hoàn toàn một triệu kết nối có heartbeat, fan-out và payload. Cần mô tả protocol, TLS, authentication, compression, subprotocol, session duration, message direction, payload distribution và reconnect policy.

Topology tối thiểu gồm load generator phân tán, DNS, CDN/WAF nếu nằm trong đường thật, load balancer/reverse proxy, cụm WebSocket backend, broker hoặc datastore và observer độc lập. Đặt bộ mô phỏng mạng giữa một nhóm client với service để chèn RTT, jitter, packet loss và outage. Capture ở client edge và backend edge nhằm phân biệt lỗi handshake với lỗi application.

Khóa phiên bản client library, HTTP/1.1 Upgrade hay WebSocket over HTTP/2 nếu được hỗ trợ, TLS/cipher, keepalive, idle timeout, proxy buffer, max connection, worker model, backend build và broker policy. Muốn đo one-way latency, phải đồng bộ và ghi sai số clock ở nguồn/đích. Message ID chỉ giúp ghép bản ghi, không thay thế đồng bộ thời gian; nếu không kiểm soát được clock thì đo round-trip bằng đồng hồ monotonic tại một phía.

Traffic profile phải chứa ramp-up connection rate, steady concurrent sessions, session age distribution, heartbeat, client-to-server rate, server fan-out, payload size, compression ratio và close code. Thêm nhóm slow reader, slow writer, client bị mất mạng và client reconnect có jitter. Dùng ID duy nhất để đối soát missing/duplicate và sequence tăng theo session/producer để kiểm thứ tự. UUID ngẫu nhiên tự nó không cho biết ordering. TCP bảo toàn thứ tự byte trên một kết nối; kiểm ordering ở đây nhằm phát hiện xử lý song song, fan-out, replay hoặc reconnect ở tầng ứng dụng.

Biến mạng gồm RTT, jitter, loss, NAT timeout và path reset. Biến hạ tầng gồm backend scale-out, node drain, deploy rolling, proxy reload, certificate rotation và broker lag. Biến ứng dụng gồm authentication latency, authorization, room/topic cardinality, persistence và retry semantics. Không tăng đồng thời connection rate lẫn message rate nếu mục tiêu là tìm bottleneck.

KPI kết nối gồm handshake thành công theo HTTP mode, HTTP status/error class, TLS time, handshake latency và connection establishment rate. KPI steady state gồm concurrent sessions, message throughput, p50/p95/p99 latency, loss, duplicate, out-of-order, queue depth, memory mỗi connection và event-loop lag. KPI recovery gồm reconnect success, time-to-stable, surge CPU và backlog drain.

Không tính message được enqueue là đã giao tới client. Nếu SLO yêu cầu end-to-end delivery, acknowledgement phải nằm ở application hoặc generator. Ping/Pong WebSocket chỉ chứng minh đường điều khiển còn phản hồi, không chứng minh business message đã được xử lý hoặc persisted.

• KPI: Handshake success · Đơn vị: % theo status/error · Bằng chứng: Client log + proxy access log
• KPI: Connection rate · Đơn vị: connections/s · Bằng chứng: Generator + accept counter
• KPI: Concurrent session · Đơn vị: phiên ổn định · Bằng chứng: Hai phía + load balancer
• KPI: Message latency · Đơn vị: p50/p95/p99/max · Bằng chứng: ID và timestamp
• KPI: Integrity · Đơn vị: missing/duplicate/order · Bằng chứng: Sequence ledger
• KPI: Backpressure · Đơn vị: queue, blocked time, drop · Bằng chứng: Runtime/broker metrics
• KPI: Reconnect recovery · Đơn vị: giây đến SLO · Bằng chứng: Timeline fault–stable

Reconnect phải có backoff và jitter trong profile. Nếu generator reconnect đồng loạt ngay lập tức, đó có thể là worst case hữu ích nhưng không đại diện client production. Nên chạy cả client đúng policy và client lệch policy để đánh giá khả năng tự bảo vệ của service.

• Trường hợp: Ramp connection · Mục tiêu: Tìm CPS bền vững · Dấu hiệu lỗi: 429/5xx, timeout, accept queue
• Trường hợp: Idle concurrency · Mục tiêu: Đo chi phí phiên · Dấu hiệu lỗi: Memory/FD/NAT exhaustion
• Trường hợp: Bidirectional steady · Mục tiêu: Đo throughput/latency · Dấu hiệu lỗi: Queue, tail latency, loss
• Trường hợp: Server fan-out · Mục tiêu: Kiểm broadcast/topic · Dấu hiệu lỗi: Hot shard, slow consumer
• Trường hợp: Slow reader · Mục tiêu: Kiểm backpressure · Dấu hiệu lỗi: Buffer phình, process OOM
• Trường hợp: Reconnect storm · Mục tiêu: Kiểm admission control · Dấu hiệu lỗi: Auth/DB/cache quá tải
• Trường hợp: Rolling deploy · Mục tiêu: Kiểm drain/resume · Dấu hiệu lỗi: Abrupt close, duplicate
• Trường hợp: Network flap · Mục tiêu: Kiểm retry/jitter · Dấu hiệu lỗi: Thundering herd

Pha A kiểm handshake, auth, subprotocol, message echo và close code ở tải nhỏ. Pha B tăng connection rate trong khi message gần như idle để tìm giới hạn accept/TLS/auth. Pha C giữ concurrency mục tiêu và tăng message rate theo hướng cùng payload. Pha D thêm fan-out, payload lớn, compression và slow consumer để quan sát backpressure.

Pha E chèn RTT/loss, NAT idle timeout, proxy reload, backend crash, broker lag và rolling deploy. Pha F cắt kết nối một tỷ lệ client rồi cho reconnect theo backoff/jitter; một lượt khác dùng synchronized storm. Pha G chạy soak đủ dài để bao phủ lease/token refresh, log rotation, certificate, autoscaling và memory leak.

• Ghi HTTP mode, TLS, auth, subprotocol, compression và close policy.
• Mô tả connection ramp, concurrency, session age và message mix.
• Dùng message ID/sequence để đo missing, duplicate và order.
• Đo latency theo phân vị, không chỉ trung bình.
• Quan sát file descriptor, memory, event-loop, queue và broker lag.
• Chạy slow reader/writer và giới hạn buffer rõ ràng.
• Kiểm proxy/LB idle timeout, drain và reload.
• Chèn backend crash, network flap và broker slowdown.
• Kiểm reconnect có backoff/jitter lẫn synchronized storm.
• Lưu generator config, raw results, logs và topology/version.

Kết quả phụ thuộc mạnh vào client library, TLS, proxy, payload, session age và behavior của broker. Benchmark kết nối idle không thể suy thành năng lực message; throughput aggregate không chứng minh mọi client đạt latency SLO. Một generator duy nhất cũng có thể hết ephemeral port hoặc CPU trước hệ thống cần kiểm.

WebSocket RFC định nghĩa framing và control frame, không đặt SLO, retry hay semantics giao nhận ứng dụng. Kết luận phải giới hạn theo build, topology, traffic profile, vùng client, failure mode và duration đã chạy; không gọi “hỗ trợ X triệu connection” nếu thiếu message rate, tài nguyên và điều kiện đo.

• Upgrade: handshake chuyển giao thức với HTTP/1.1; HTTP/2 dùng Extended CONNECT.
• Concurrent session: số kết nối đồng thời đang được duy trì.
• Backpressure: cơ chế làm chậm hoặc giới hạn producer khi consumer không theo kịp.
• Slow consumer: client đọc chậm làm hàng đợi phía server tăng.
• Reconnect storm: nhiều client tái kết nối trong cửa sổ ngắn.
• Tail latency: độ trễ ở các phân vị cao như p95/p99.
• Close code: mã thể hiện lý do đóng WebSocket.