Test WebSocket

Kết nối bất kỳ endpoint ws:// hoặc wss://, gửi/nhận message trực tiếp, xem lịch sử đầy đủ với timestamp. Cho debug chat, GraphQL sub, MQTT-over-WS.

Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cả

Test WebSocket - Test Kết Nối WebSocket Thời Gian Thực

WebSocket là giao thức cuối cùng đã cho phép trình duyệt giao tiếp hai chiều thời gian thực, được chuẩn hóa năm 2011 là RFC 6455 và nay phổ biến: mọi ứng dụng chat hiện đại, widget thể thao trực tiếp, trình soạn thảo cộng tác (Figma, Google Docs), feed tick giao dịch, subscription GraphQL, lobby game multiplayer và hầu hết hệ thống thông báo real-time đều chạy trên đó. Khác với chu kỳ request-response HTTP, kết nối WebSocket giữ mở sau bắt tay ban đầu, cho phép bên nào cũng gửi frame bất kỳ lúc nào, và sống sót qua proxy và firewall doanh nghiệp vì bắt đầu như HTTP Upgrade request thường trước khi chuyển giao thức. Debug app WebSocket khó hơn debug HTTP — tab network của DevTools hiển thị bắt tay nhưng kém trong việc hiển thị dòng message theo thời gian. Trình test này lấp lỗ hổng đó. Gõ bất kỳ URL ws:// hoặc wss://, nhấp Kết nối, và bạn có kênh trực tiếp persistent: gửi message text hoặc JSON tùy ý với nút Gửi, xem mọi frame server gửi xuất hiện thời gian thực với timestamp chính xác, và phân biệt hướng message (gửi/nhận/sự kiện hệ thống như open/close/error) bằng màu trong log. Hữu ích để nghịch echo.websocket.org trong tutorial, xác nhận vòng lặp broadcast backend thực sự đến client kết nối, tái tạo race condition, hoặc xem traffic heartbeat của dịch vụ bạn tích hợp. Cho công việc hiệu năng, nó vượt xa client echo đồ chơi: bảng độ trễ khứ hồi (RTT) tích hợp đo số mili-giây giữa mỗi frame JSON gửi đi và phản hồi nhận được kế tiếp bằng performance.now(), rồi theo dõi độ trễ mới nhất, nhỏ nhất, trung bình và lớn nhất cùng bộ đếm đã gửi/đã nhận — để phát hiện jitter, broker chậm, hoặc backend ngừng echo chỉ trong một cái nhìn.

WebSocket là gì?

WebSocket là protocol cung cấp kênh giao tiếp full-duplex qua một kết nối TCP duy nhất. Không giống HTTP là request-response, WebSocket cho phép:

- Giao tiếp hai chiều theo thời gian thực
- Kết nối liên tục giữa client và server
- Độ trễ thấp hơn polling
- Hiệu quả cho ứng dụng real-time

Ứng dụng phổ biến:
- Ứng dụng chat
- Live feeds và notifications
- Gaming real-time
- Collaborative editing
- Tỷ số thể thao trực tiếp
- Bảng giá chứng khoán

WebSocket URLs dùng ws:// (không bảo mật) hoặc wss:// (bảo mật với TLS).

Làm thế nào để test WebSocket?

Test WebSocket rất đơn giản:

1. Nhập WebSocket URL (ws:// hoặc wss://)
2. Nhấp 'Kết Nối' để thiết lập kết nối
3. Đợi trạng thái 'Đã kết nối'
4. Gõ tin nhắn vào trường message
5. Nhấp 'Gửi' để gửi tin nhắn
6. Xem responses trong lịch sử tin nhắn
7. Nhấp 'Ngắt Kết Nối' khi hoàn thành

Ví dụ WebSocket servers để test:
- ws://echo.websocket.org (echo lại messages)
- wss://echo.websocket.org (echo bảo mật)

Lịch sử tin nhắn hiển thị tất cả messages đã gửi và nhận với timestamps.

Làm thế nào để đo độ trễ WebSocket (thời gian khứ hồi)?

Kết nối đến một endpoint echo hoặc heartbeat và gửi một frame: công cụ đo số mili-giây giữa tin nhắn bạn gửi và phản hồi nhận được kế tiếp bằng đồng hồ độ phân giải cao performance.now() của trình duyệt, rồi hiển thị kết quả trong bảng Độ Trễ Khứ Hồi (RTT).

Bảng hiển thị bốn chỉ số trực tiếp:
- Mới nhất: thời gian khứ hồi gần nhất tính bằng ms
- Trung bình: giá trị trung bình tích lũy của mọi phản hồi đo được
- Nhỏ/Lớn nhất: phản hồi nhanh nhất và chậm nhất cho đến nay — khoảng cách cho thấy jitter
- Đã gửi/Đã nhận: bộ đếm tổng frame, để biết backend có ngừng echo không

Gửi vài frame để tạo mẫu. Trung bình thấp ổn định với nhỏ/lớn nhất sát nhau nghĩa là feed real-time khỏe mạnh; giá trị lớn nhất tăng dần hoặc bộ đếm đã nhận tụt sau đã gửi cho thấy broker chậm, jitter mạng, hoặc backend đã đóng kết nối. Hoạt động tốt nhất với endpoint echo/heartbeat nơi mỗi frame gửi tạo ra một phản hồi (ví dụ wss://echo.websocket.org).

Khác biệt giữa ws:// và wss:// là gì?

ws:// và wss:// tương tự như http:// và https://:

ws:// (WebSocket):
- Kết nối không mã hóa
- Dùng port 80 mặc định
- Dữ liệu truyền dưới dạng plain text
- Kém bảo mật hơn
- Tốt cho phát triển local

wss:// (WebSocket Secure):
- Kết nối mã hóa dùng TLS/SSL
- Dùng port 443 mặc định
- Dữ liệu được mã hóa
- Bảo mật hơn
- Bắt buộc cho websites HTTPS
- Khuyên dùng cho production

Trình duyệt hiện đại yêu cầu wss:// khi webpage được serve qua HTTPS.

Tại sao tôi không thể kết nối đến một số WebSocket servers?

Kết nối thất bại có thể xảy ra vì nhiều lý do:

1. CORS/Bảo mật: Server không cho phép kết nối từ browsers
2. Xác thực: Server yêu cầu authentication headers
3. SSL/TLS: Mixed content (ws:// trên trang HTTPS)
4. Server Down: WebSocket server offline
5. Firewall: Network firewall chặn WebSocket
6. URL không hợp lệ: Sai format URL hoặc port

Khắc phục:
- Kiểm tra format URL (ws:// hoặc wss://)
- Dùng wss:// trên trang HTTPS
- Xác minh server đang chạy
- Kiểm tra cài đặt CORS của server
- Thử echo.websocket.org để test
- Kiểm tra console của trình duyệt để xem lỗi

Test WebSocket — Kết nối bất kỳ endpoint ws:// hoặc wss://, gửi/nhận message trực tiếp, xem lịch sử đầy đủ với timestamp. Cho debug chat, — **Test WebSocket**

Tôi có thể gửi những loại dữ liệu nào?

WebSocket tester này gửi text messages. WebSocket hỗ trợ:

Text Messages:
- Plain text
- JSON strings
- XML strings
- Bất kỳ định dạng string nào

Binary Messages:
- ArrayBuffer
- Blob
- File data
(Không hỗ trợ trong tester đơn giản này)

Định dạng phổ biến:
- JSON: {"type": "message", "text": "Hello"}
- Plain text: "Hello, World!"
- Commands: "/join room123"

Hầu hết WebSocket APIs mong đợi định dạng JSON cho giao tiếp dữ liệu có cấu trúc.

WebSocket khác gì với Server-Sent Events (SSE) và long-polling?

Cả ba đều đẩy server tới trình duyệt mà không cần polling, nhưng với tradeoff khác nhau. (1) WebSocket: full duplex (hai bên nói bất cứ lúc nào), overhead thấp mỗi message (header frame 2-14 byte), payload tùy ý text hoặc binary, giao thức ứng dụng tùy chỉnh. Tốt nhất cho chat, game multiplayer, soạn thảo cộng tác — bất cứ thứ gì thực sự tương tác. (2) Server-Sent Events: chỉ một chiều (server → client), API đơn giản hơn (EventSource trong trình duyệt), tự động reconnect, chỉ text UTF-8 thuần. Tốt nhất cho feed trực tiếp nơi client không bao giờ nói ngược lại: giá cổ phiếu, ticker tin tức, streaming log server. SSE qua HTTP/2 thuần nên thân thiện hơn với proxy trung gian. (3) Long-polling: client tạo HTTP request mà server giữ mở đến khi có dữ liệu, rồi ngay lập tức mở lại. Latency và overhead cao nhất nhưng hoạt động mọi nơi vì là HTTP thuần. Ứng dụng hiện đại mặc định WebSocket; fallback SSE cho feed một chiều; long-polling chỉ quan trọng cho môi trường legacy không hỗ trợ proxy đúng cách.

Kích thước message và tốc độ tối đa qua một WebSocket là bao nhiêu?

Bản thân giao thức cho phép frame lên tới 2^63 byte — hiệu quả là không giới hạn. Giới hạn thực đến từ stack runtime của bạn. Trình duyệt giới hạn message đơn lẻ khoảng 64 MB trước khi cảnh báo hoặc ngắt; sweet spot thực tế cho message tầng ứng dụng là dưới 1 MB để tránh nghẹt event loop JavaScript đơn luồng. Thư viện 'ws' Node.js mặc định tối đa 100 MB nhưng có thể cấu hình. Về tốc độ, phần cứng hiện đại duy trì 100.000+ message nhỏ mỗi giây mỗi kết nối WebSocket trên localhost, giảm xuống hàng nghìn/giây trên internet công cộng tùy RTT. Nếu cần throughput cao hơn, gom các cập nhật nhỏ thành message lớn định kỳ (ví dụ cadence 16ms cho client 60fps), dùng binary framing (ArrayBuffer) thay vì JSON để bỏ qua string parsing, và cân nhắc WebTransport (kế thừa dựa trên HTTP/3 thiết kế cho stream unreliable độ trễ thấp) cho traffic kiểu game. Tránh gửi blob base64 khổng lồ qua WebSocket; dùng upload HTTP riêng và báo hoàn tất qua socket.

Dữ liệu của tôi có an toàn không?

Các cân nhắc về quyền riêng tư và bảo mật:

- Tất cả kết nối đi trực tiếp từ trình duyệt của bạn đến WebSocket server
- Không có dữ liệu nào đi qua servers của chúng tôi
- Chúng tôi không log hoặc lưu trữ bất kỳ messages nào
- Dùng wss:// cho kết nối mã hóa
- Tránh gửi dữ liệu nhạy cảm đến servers không tin cậy
- Test servers có thể log messages của bạn

Thực hành tốt nhất:
- Dùng wss:// trong production
- Đừng gửi passwords hoặc dữ liệu nhạy cảm đến public test servers
- Xác minh tính xác thực của server
- Dùng authentication khi cần
- Test với dummy data khi có thể