Bài 8: WebSockets: Cuộc cách mạng Real-time trên trình duyệt web

Ở các bài học trước, chúng ta đã làm chủ các socket thuần túy (Raw TCP/UDP Sockets) ở tầng vận chuyển, xây dựng từ chat server cho đến truyền tải file nhị phân. Tuy nhiên, khi dịch chuyển môi trường lập trình mạng lên trình duyệt web (Web Browsers), một rào cản lớn xuất hiện: các trình duyệt web hiện đại không cho phép lập trình viên trực tiếp mở một raw TCP socket hay UDP socket vì lý do bảo mật và kiểm soát chính sách mạng.

Trong bài học này, chúng ta sẽ khám phá cách WebSockets ra đời như một cuộc cách mạng đập tan giới hạn của HTTP truyền thống, mang lại khả năng giao tiếp thời gian thực (Real-time) mượt mà ngay trên trình duyệt.

1. Giới hạn của HTTP truyền thống & Thời kỳ "Long-polling"

Giao thức HTTP được thiết kế dựa trên mô hình Request - Response (Yêu cầu - Phản hồi):

• Client phải là bên chủ động gửi một request đi.
• Server nhận request, xử lý, trả về response, và ngay lập tức đóng kết nối. Server không thể tự chủ động "bơm" dữ liệu ngược về client nếu client không hỏi.

Các giải pháp "chắp vá" trước khi có WebSocket:

• Polling (Hỏi vòng liên tục): Trình duyệt cứ mỗi 2 giây lại gửi một HTTP request lên server hỏi: "Có tin nhắn mới chưa?".
  • Hậu quả: 99% các request trả về dữ liệu trống, gây lãng phí băng thông khủng khiếp và làm quá tải CPU của Server.
• Long-polling (Hỏi dài hạn): Client gửi request lên server, server giữ nguyên kết nối (hold connection) cho đến khi có tin nhắn mới hoặc hết thời gian timeout rồi mới trả về, sau đó client lại lập tức gửi request mới.
  • Hậu quả: Giảm bớt số lượng request rác nhưng vẫn gánh nặng overhead từ các HTTP Headers cồng kềnh (mỗi request chứa hàng trăm bytes metadata không cần thiết).

2. WebSocket là gì? Cơ chế "Bắt tay" nâng cấp (Handshake)

WebSocket là một giao thức truyền thông chuẩn (được định nghĩa tại RFC 6455), cung cấp một kênh giao tiếp song công toàn phần (Full-duplex) — nghĩa là cả Client và Server có thể đồng thời gửi dữ liệu cho nhau bất cứ lúc nào trên cùng một kết nối TCP duy nhất.

Bí mật của quá trình chuyển đổi giao thức (Protocol Upgrade):

WebSocket không chạy trên một cổng hoàn toàn mới. Nó bắt đầu bằng một HTTP Request bình thường để lợi dụng các cơ chế tường lửa sẵn có, sau đó "nâng cấp" lên giao thức WebSocket:

[ Client ]                                                  [ Server ]
    │                                                           │
    │ ── 1. HTTP GET /chat (Headers: Upgrade: websocket) ────────► │ (Bắt tay)
    │ ◄── 2. HTTP 101 Switching Protocols (Đã đổi giao thức) ───── │
    │                                                           │
    │ ◄══════ 3. Kênh TCP Full-duplex WebSocket được thiết lập ═══► │

1. Client gửi HTTP Request đặc biệt: Kèm theo các header quan trọng:
   • Upgrade: websocket
   • Connection: Upgrade
   • Sec-WebSocket-Key: Một chuỗi ngẫu nhiên được mã hóa base64 để bảo mật.
2. Server đồng ý: Nếu chấp nhận, Server trả về mã trạng thái 101 Switching Protocols.
3. Chuyển đổi hoàn toàn: Từ khoảnh khắc này, kết nối HTTP ban đầu chính thức bị "tiêu hủy" hoặc biến đổi thành kênh WebSocket vĩnh viễn. Hai bên có thể tự do truyền nhận các gói tin (frames) qua lại mà không cần lặp lại HTTP headers nữa.

3. Cấu trúc Khung tin (WebSocket Framing)

• Khác với TCP Stream thuần túy (vốn là một dòng byte vô tận đòi hỏi ứng dụng phải tự định nghĩa biên giới gói tin như đã thấy ở Bài 5), WebSocket đóng gói dữ liệu thành các Frames (Khung tin) nhỏ gọn.
• Mỗi frame có một header tối thiểu rất nhỏ (từ 2 đến 10 bytes).
• Hỗ trợ truyền tải cả Text (Văn bản UTF-8) lẫn Binary (Dữ liệu nhị phân).
• Tích hợp sẵn cơ chế Masking (mã hóa dữ liệu phía client gửi lên) để ngăn chặn các cuộc tấn công giả mạo yêu cầu chéo (Cross-Site WebSocket Hijacking - CSWSH).

4. Thực hiện WebSocket Server bằng Golang

Hệ sinh thái Go hỗ trợ WebSocket cực kỳ mạnh mẽ thông qua thư viện phổ biến gorilla/websocket (hoặc gói chuẩn golang.org/x/net/websocket).

Dưới đây là một mô hình WebSocket Server đơn giản xử lý nâng cấp kết nối và phát tán tin nhắn (Echo/Broadcast):

package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/gorilla/websocket"
)

// Cấu hình bộ chuyển đổi kết nối HTTP sang WebSocket
var upgrader = websocket.Upgrader{
	CheckOrigin: func(r *http.Request) bool {
		return true // Cho phép mọi origin kết nối (dùng khi dev/test)
	},
}

func handleWebSocket(w http.ResponseWriter, r *http.Request) {
	// 1. Nâng cấp kết nối HTTP lên WebSocket
	conn, err := upgrader.Upgrade(w, r, nil)
	if err != nil {
		log.Printf("Lỗi nâng cấp WebSocket: %v\n", err)
		return
	}
	defer conn.Close()

	fmt.Printf("🔗 Client mới đã thiết lập WebSocket thành công: %s\n", conn.RemoteAddr().String())

	// 2. Vòng lặp đọc/ghi dữ liệu thời gian thực
	for {
		// Đọc tin nhắn dạng text hoặc binary từ client
		messageType, msg, err := conn.ReadMessage()
		if err != nil {
			log.Printf("Client ngắt kết nối hoặc lỗi đọc: %v\n", err)
			break
		}

		fmt.Printf("💬 Nhận tin nhắn WebSocket: %s\n", string(msg))

		// Gửi ngược lại tin nhắn cho client (Echo)
		err = conn.WriteMessage(messageType, msg)
		if err != nil {
			log.Printf("Lỗi ghi dữ liệu WebSocket: %v\n", err)
			break
		}
	}
}

func main() {
	http.HandleFunc("/ws", handleWebSocket)

	log.Println("🚀 WebSocket Server đang chạy tại ws://localhost:8080/ws ...")
	if err := http.ListenAndServe(":8080", nil); err != nil {
		log.Fatalf("Lỗi HTTP server: %v\n", err)
	}
}

5. So Sánh: HTTP, Long-polling và WebSockets

💡 Tổng Kết

WebSockets đã giải quyết hoàn hảo bài toán giao tiếp hai chiều thời gian thực trên nền tảng trình duyệt web, kết hợp sự tiện lợi của cổng HTTP chuẩn với hiệu năng truyền tải gần như raw TCP.

Tuy nhiên, trong các hệ thống game multiplayer tốc độ cao (nơi độ trễ tính bằng mili-giây và đôi khi chấp nhận mất gói tin), WebSocket chạy trên nền TCP có thể gặp hiện tượng "kẹt gói tin" (Head-of-Line Blocking) do cơ chế đảm bảo trật tự của TCP. Giải pháp cho các hệ thống game thời gian thực là gì?

Đó chính là nội dung của Bài 9: Xây dựng hệ thống đồng bộ trạng thái cho Game Multiplayer (Sử dụng UDP kết hợp Dead Reckoning).