Kiểm thử Server-Sent Events: concurrent streams, reconnect và Last-Event-ID

Client dùng text/event-stream và giữ HTTP response mở để nhận sự kiện. Khi kết nối mất, client có thể kết nối lại và gửi Last-Event-ID; server quyết định có replay phần bị thiếu hay không. Vì vậy “kết nối thành công” và “không mất dữ liệu” là hai tiêu chí khác nhau.

SSE phù hợp cho luồng một chiều như trạng thái tác vụ, thông báo và telemetry nhẹ. Nó không thay WebSocket cho giao tiếp hai chiều. Test objective nên bắt đầu từ semantics của sự kiện: được phép trùng không, phải giữ thứ tự không, và retention cho replay dài bao lâu.

Topology đại diện gồm load agent ở ngoài edge, DNS/CDN hoặc WAF nếu có, reverse proxy/load balancer, nhiều instance SSE, event broker và nguồn phát sự kiện có sequence ID. Mỗi client ghi timestamp nhận, event ID, connection ID và instance ID; phía server ghi timestamp publish và flush.

Chạy cả HTTP/1.1 và HTTP/2 nếu production cho phép. Xác minh timeout, buffering và connection reuse tại từng hop. Đặt agent ở nhiều vùng khi mục tiêu có WAN; một agent cùng subnet server chỉ đo được phần nhỏ của service path.

Khóa số client đồng thời, ramp rate, event rate, payload size, heartbeat interval, server retry, client backoff, retention window và sticky-session policy. Ghi rõ proxy idle timeout, response buffering, compression và giới hạn file descriptor/ephemeral port.

Traffic profile cần nhóm client nhanh/chậm, mạng ổn định/suy hao, foreground/background và nhiều thời gian sống. Nếu tất cả client kết nối cùng lúc, kết quả chủ yếu phản ánh startup spike; hãy tách ramp bình thường khỏi reconnect storm có chủ đích.

Đo concurrent active streams, connect success rate, time-to-first-event, publish-to-receive latency p50/p95/p99, event gap, duplicate, out-of-order, reconnect time và replay completion time. Theo dõi CPU, memory, socket, queue depth và egress ở từng tier để định vị giới hạn.

Mỗi event nên có ID tăng đơn điệu và timestamp từ nguồn. Client tạo ledger nhận sự kiện; đối chiếu với ledger phát để tính loss/duplicate chính xác. Đồng bộ thời gian và lưu offset; nếu không, percentile latency có thể sai dù sequence vẫn đúng.

• KPI: Active streams · Cách đo: trạng thái client + server sockets · Rủi ro diễn giải: socket mở chưa chắc event đang chảy
• KPI: Event latency · Cách đo: publish timestamp đến client receive · Rủi ro diễn giải: clock skew làm sai percentile
• KPI: Gap rate · Cách đo: thiếu event ID theo subscriber · Rủi ro diễn giải: có thể do retention hoặc filter hợp lệ
• KPI: Duplicate rate · Cách đo: event ID lặp · Rủi ro diễn giải: replay at-least-once có thể được thiết kế
• KPI: Reconnect time · Cách đo: disconnect đến event hợp lệ đầu tiên · Rủi ro diễn giải: HTTP connect không đồng nghĩa phục hồi dữ liệu

Thử idle timeout, proxy reload, instance termination, broker lag, client network loss, DNS/LB failover và slow consumer. Với mỗi lỗi, ghi expected behavior: disconnect có được phát hiện, backoff có phân tán, Last-Event-ID được tôn trọng, replay có giới hạn và duplicate được xử lý ra sao.

Đặc biệt kiểm tra buffering: proxy có thể gom nhiều event rồi đẩy thành burst, làm average throughput đẹp nhưng event latency xấu. Heartbeat quá thưa gây timeout; quá dày tăng overhead và che capacity dành cho dữ liệu.

• Xác định delivery semantics và ngân sách latency/loss.
• Chạy một client, xác minh format, ID, retry và heartbeat.
• Tăng concurrent streams theo bậc, giữ event rate/client cố định.
• Giữ soak đủ lâu vượt các idle timeout quan trọng.
• Tạo slow consumer và packet loss có kiểm soát.
• Restart một instance, rồi một proxy; đo reconnect và replay.
• Ngắt đồng thời một tỷ lệ client để tạo reconnect storm.
• Lặp với backoff có jitter và không jitter.
• Khôi phục, đối chiếu ledger phát/nhận và resource trở về baseline.

• Gắn event ID, publish timestamp và correlation ID.
• Tắt buffering ở hop cần stream và xác minh bằng capture.
• Định nghĩa proxy/LB idle timeout lớn hơn heartbeat phù hợp.
• Theo dõi file descriptor, socket, queue và egress.
• Kiểm tra retry có exponential backoff và jitter.
• Giới hạn reconnect rate để bảo vệ dependency.
• Xác minh retention/replay theo tenant và quyền truy cập.
• Lưu ledger nguồn–client làm bằng chứng pass/fail.

Kết quả phụ thuộc browser/runtime, giao thức HTTP, edge, proxy, load balancer, OS limit và implementation server. Generator giữ được 100.000 stream không chứng minh người dùng thật có cùng hành vi; ngược lại generator hết ephemeral port không phải giới hạn SUT.

SSE không định nghĩa end-to-end exactly-once. Last-Event-ID hỗ trợ tiếp tục nhưng retention, replay và deduplication là trách nhiệm ứng dụng. Báo cáo cần ghi delivery semantics đã chọn, không quảng bá “không mất dữ liệu” nếu chỉ thử một failure mode.

• SSE: Luồng sự kiện một chiều từ server qua HTTP response dài hạn.
• Last-Event-ID: ID client gửi khi reconnect để server xác định điểm tiếp tục.
• Heartbeat: Dữ liệu/comment định kỳ giữ đường truyền không bị coi là idle.
• Reconnect storm: Nhiều client kết nối lại gần đồng thời sau lỗi chung.
• Slow consumer: Client đọc chậm hơn tốc độ server phát.
• Delivery semantics: Quy ước at-most-once, at-least-once hoặc xử lý trùng ở ứng dụng.