WebSockets là gì

WebSockets là một giao thức truyền thông cung cấp kênh giao tiếp song song, hai chiều qua một kết nối TCP duy nhất. Không giống HTTP, theo mẫu yêu cầu- phản hồi nghiêm ngặt, WebSocket cho phép cả máy khách và máy chủ gửi tin nhắn độc lập bất cứ khi nào sau khi kết nối được thiết lập.

Giao thức WebSocket được nhận diện bằng các phạm vi URL `ws://` (chưa mã hóa) và `wss://` (mã hóa, tương đương với HTTPS). Nó hoạt động trên các cổng 80 và 443 tương ứng, làm cho nó tương thích với hạ tầng web hiện có bao gồm các proxy và firewall.

The Upgrade Handshake

Kết nối WebSocket khởi đầu như những yêu cầu HTTP thông thường. Máy khách gửi một yêu cầu HTTP với các tiêu đề đặc biệt để yêu cầu máy chủ nâng cấp kết nối lên WebSocket. Quá trình này được gọi là handshake nâng cấp.

Đây là cách trông của yêu cầu nâng cấp HTTP ban đầu:

http
GET /chat HTTP/1.1
Host: example.com:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://example.com

Máy chủ trả về mã trạng thái `101 Switching Protocols`, xác nhận sự nâng cấp giao thức. Sau handshake này, kết nối TCP cơ sở vẫn mở và hai bên có thể trao đổi tin nhắn một cách tự do mà không cần tái thiết lập kết nối.

Các tiêu đề quan trọng cần nhớ:

- `Upgrade: websocket` và `Connection: Upgrade` cho biết ý định chuyển đổi giao thức. - `Sec-WebSocket-Key` là một giá trị được mã hóa base64 ngẫu nhiên mà máy chủ dùng để chứng minh đã nhận được yêu cầu. - `Sec-WebSocket-Version: 13` chỉ định phiên bản giao thức.

HTTP vs WebSocket: Sự khác biệt về kiến trúc

HTTP hoạt động theo chu kỳ một yêu cầu một phản hồi. Mỗi tương tác đòi hỏi một yêu cầu mới từ phía client, và máy chủ không thể đẩy dữ liệu mà không có client yêu cầu trước. Mô hình này đơn giản nhưng kém hiệu quả cho các tính năng thời gian thực như ứng dụng chat, thông báo trực tiếp hoặc chỉnh sửa hợp tác.

WebSockets giải quyết bằng cách duy trì kết nối liên tục. Sau quá trình bắt tay (handshake), máy chủ có thể đẩy cập nhật tới client bất cứ khi nào có dữ liệu mới và client có thể gửi message mà không cần chờ poll.

Dưới đây là một so sánh đơn giản về luồng truyền thông:

http
HTTP (polling):
Client: GET /updates
Server: 200 OK (no new data)
Client: GET /updates (repeat every 2s)
Server: 200 OK (here is an update)
WebSocket:
Client: HTTP Upgrade request
Server: 101 Switching Protocols
Server: (pushes update when ready)
Client: (sends message when needed)
biểu đồ luồng so sánh chu kỳ polling HTTP với kết nối WebSocket duy trì liên tục có các mũi tên hai chiều

Những yếu tố hiệu suất

Lợi thế hiệu suất chính của WebSockets đến từ việc loại bỏ chi phí kết nối lặp đi lặp lại. Với polling HTTP, mỗi yêu cầu mang theo dữ liệu tiêu đề đầy đủ (thông thường 500-800 byte) ngay cả khi máy chủ không có gì mới để báo cáo. WebSockets truyền chỉ các tiêu đề khung nhỏ (2-6 byte cho hầu hết các khung) sau khi bắt đầu handshake ban đầu.

Điều này khiến WebSockets hiệu quả hơn đáng kể đối với:

- Ứng dụng chat nơi tin nhắn truyền đi hai chiều thường xuyên. - Bảng điều khiển trực tiếp hiển thị dữ liệu thay đổi theo thời gian thực. - Trò chơi nhiều người chơi đòi hỏi đồng bộ trạng thái với độ trễ thấp. - Công cụ hợp tác nơi nhiều người dùng chỉnh sửa nội dung chia sẻ.

Tuy nhiên, WebSockets không phải là giải pháp tối ưu cho mọi tình huống. Các lần lấy dữ liệu một lần đơn giản, phân phối nội dung tĩnh và các cuộc gọi REST API được phục vụ tốt hơn bằng HTTP truyền thống.

Những sai lầm và hiểu lầm phổ biến

Một sai lầm phổ biến là cho rằng WebSockets thay thế hoàn toàn HTTP. Trên thực tế, hầu hết các ứng dụng thực tế sử dụng cả hai: HTTP cho tải trang ban đầu, xác thực và REST API, và WebSockets chỉ cho các kênh thời gian thực thực sự cần đẩy hai chiều.

Một hiểu lầm khác là WebSockets tự động mang lại an toàn. Giống như HTTP, bạn phải dùng `wss://` (TLS được mã hóa) để bảo vệ dữ liệu trong quá trình truyền. Một kết nối `ws://` không được mã hóa rủi ro như HTTP plaintext.

Cuối cùng, quản lý kết nối rất quan trọng. Các kết nối WebSocket có thể bị mất do gián đoạn mạng, thời gian chờ proxy hoặc khởi động lại máy chủ. Các ứng dụng sản xuất phải triển khai logic tái kết nối ở phía client và cơ chế heartbeat (khung ping/pong) để phát hiện kết nối chết.

Tóm tắt

WebSockets cho phép giao tiếp hai chiều thời gian thực bằng cách nâng cấp kết nối HTTP ban đầu thành một kênh toàn song công kéo dài. Giao thức nâng cấp sử dụng các tiêu đề cụ thể và máy chủ phản hồi với `101 Switching Protocols`. Khi được thiết lập, cả客户 và máy chủ có thể gửi dữ liệu độc lập với chi phí tối thiểu, làm cho WebSockets trở thành lựa chọn lý tưởng cho các tính năng thời gian thực. Nhớ rằng WebSockets bổ sung chứ không thay thế HTTP, và các triển khai ở môi trường sản xuất cần mã hóa đúng cách, xử lý tái kết nối và giám sát sức khỏe kết nối.

Bài kiểm tra cuối bài

1. Máy chủ trả về mã trạng thái HTTP nào để xác nhận nâng cấp WebSocket thành công?

2. Tiêu đề Sec-WebSocket-Key chứa gì trong yêu cầu nâng cấp ban đầu?

3. Sự khác biệt kiến trúc chính giữa HTTP và giao tiếp WebSocket là gì?

4. Bạn nên dùng giao thức URL nào để đảm bảo một kết nối WebSocket được mã hóa?

5. Tại sao WebSocket hiệu quả hơn so với polling HTTP để cập nhật thời gian thực?

6. Kịch bản nào WebSocket phù hợp nhất?

7. Mối quan ngại nào khi triển khai kết nối WebSocket cần xử lý ở môi trường sản xuất?