Kỹ thuật đỉnh cao năm 2004: RuneScape nhồi nhét cả thế giới MMO vào modem 56k

Năm 2004, hàng ngàn game thủ trên khắp thế giới, trong đó có rất nhiều người Việt Nam thời đó, đã dành hàng giờ liền để "cày cuốc" trong thế giới 3D của RuneScape ngay trên trình duyệt web, với thứ kết nối Internet chậm chạp nhất: modem quay số 56k. Điều kỳ diệu là trò chơi vẫn hoạt động mượt mà với hàng chục người chơi hiển thị cùng lúc trên màn hình, bất chấp băng thông cực hạn chế. Làm thế nào Jagex làm được điều đó? Câu trả lời nằm ở một giao thức mạng được thiết kế tỉ mỉ đến từng bit, một bài học về sự tối ưu tuyệt đối vẫn còn giá trị cho đến ngày nay.

Hãy cùng phân tích một bước đi đơn giản của nhân vật xem dữ liệu được truyền đi như thế nào.

Đài phun nước trung tâm ở quảng trường Varrock Đài phun nước trung tâm ở quảng trường Varrock, một địa điểm quen thuộc với mọi game thủ RuneScape

Những ràng buộc khắc nghiệt của năm 2004

Để hiểu được sự kỳ diệu này, chúng ta cần nhìn lại những giới hạn công nghệ mà đội ngũ Jagex phải đối mặt:

• Băng thông: Modem 56k lý thuyết đạt tốc độ tải xuống 56 kilobit mỗi giây, nhưng trên thực tế chỉ khoảng 5 KB/s sau khi trừ đi chi phí giao thức và nhiễu đường truyền. Tốc độ tải lên còn chậm hơn nhiều.
• Nền tảng Java Applet: Trò chơi chạy trong applet Java trên trình duyệt, bị giới hạn bởi sandbox bảo mật. Điều này đồng nghĩa với việc không thể dùng socket UDP, mọi dữ liệu phải đi qua một kết nối TCP duy nhất, đảm bảo thứ tự nhưng kèm theo overhead cho mỗi phân đoạn.
• Chu kỳ server 600ms: Máy chủ RuneScape hoạt động theo các "tick" (chu kỳ) rời rạc, mỗi tick kéo dài khoảng 600ms. Trong mỗi chu kỳ, server phải tính toán và gửi đến mọi người chơi những gì họ có thể thấy trước khi chu kỳ tiếp theo bắt đầu.

Lớp mã hóa và "bí mật" của opcode

Sau khi đăng nhập, một lớp mã hóa nhỏ được thiết lập, không phải để bảo mật dữ liệu người dùng mà để bảo vệ chính opcode – byte đầu tiên của mỗi gói tin, đóng vai trò như "mã định danh" cho biết gói tin đó thuộc loại nào. Opcode này được mã hóa bằng thuật toán dòng ISAAC với hai luồng riêng biệt cho chiều gửi và nhận.

Tại sao chỉ mã hóa opcode? Vì nếu kẻ xấu biết được opcode, chúng có thể giả mạo các gói tin điều khiển nhân vật. Việc mã hóa này giúp bảo vệ tính toàn vẹn của phiên chơi, dù chỉ là một phần nhỏ trong tổng thể dữ liệu.

Theo dõi một bước chân: Hành trình 7 byte

Khi bạn click chuột để di chuyển nhân vật lên một ô, client sẽ không gửi tọa độ tuyệt đối mà gửi một gói tin WALK_TILE chỉ vỏn vẹn 7 byte. Gói tin này được làm mới mỗi 20ms, và giao thức quy định rằng client sẽ đợi đến khi đủ 8 gói hoặc gói lớn hơn 255 byte mới gửi đi để tối ưu chi phí.

Gói tin 7 byte này chứa:

• 1 byte opcode
• 1 byte độ dài
• 1 bit cờ "có di chuyển hay không"
• 2 bit cờ "có dùng phím Ctrl để chạy hay không" (ở phiên bản đầu, Ctrl là phím "chạy", sau này được đổi thành "đảo ngược chế độ di chuyển")
• 3 bit hướng (8 hướng)
• 2 byte tọa độ X tương đối
• 1 byte cho biết có bao nhiêu bước đi trong "hành trình"

Đặc biệt, client và server cùng sử dụng chung một thuật toán tìm đường (pathfinder) trên cùng một bản đồ va chạm. Client chỉ gửi các điểm mốc (corners) của con đường, và server dựa trên đó để tính toán và xác nhận toàn bộ đường đi. Điều này giúp tiết kiệm rất nhiều byte so với việc gửi toàn bộ tọa độ từng bước.

Gói tin cập nhật người chơi: Nghệ thuật nén bit

Sau khi server xử lý, nó sẽ gửi đến tất cả người chơi khác đang nhìn thấy bạn một gói tin cập nhật, với cấu trúc được chia thành 4 bước và được nén bit cực kỳ thông minh:

Bước 1 & 2: Thông tin người chơi cục bộ và danh sách người chơi

• Mỗi người chơi được biểu diễn bằng 1 bit trạng thái "di chuyển" hoặc "không di chuyển". Con số 0 đồng nghĩa với việc "không có gì thay đổi" – đây là trạng thái mặc định được cả hai bên ngầm hiểu.
• Nếu di chuyển, 1 bit tiếp theo cho biết có hành động "chạy" hay không.
• 3 bit cho hướng đi, 1 bit cho biết có gửi thêm chi tiết ở bước 4 hay không.
• Cuối cùng là 7 bit tọa độ (mỗi trục 3 bit hoặc 4 bit so với vị trí hiện tại).

Bước 3: Người chơi mới xuất hiện

• Khi một người chơi mới bước vào vùng hiển thị (trong bán kính ~15 ô), gói tin sẽ gửi ID 11 bit, 1 bit cho biết có cập nhật chi tiết ở bước 4, 1 bit cho biết có teleport hay không, và 10 bit tọa độ tương đối (5 bit mỗi trục).
• Ý tưởng này là điểm mấu chốt: thay vì gửi tọa độ tuyệt đối 32 bit, chỉ cần gửi tọa độ tương đối trong phạm vi quan sát được. Số 2047 (ID tối đa của 11 bit) được dùng làm dấu hiệu kết thúc danh sách, tránh lãng phí byte cho việc đếm số lượng.

Bước 4: Cập nhật chi tiết

• Bước này chỉ dành cho những người chơi được đánh dấu "có thêm chi tiết" ở các bước trước. Các cờ cập nhật được đóng gói trong 1 hoặc 2 byte, với bit trọng số cao nhất (MSB) làm cờ đánh dấu việc có cần đọc thêm byte thứ hai hay không.
• Các cờ bao gồm: quay mặt vào thực thể/ô đất, thay đổi hoạt ảnh, thay đổi ngoại hình (trang bị, màu da, giới tính...), nhận sát thương, chat công khai, hiệu ứng đồ họa...
• Trong số này, cập nhật "ngoại hình" là tốn kém nhất, tiêu tốn từ 44 đến 80 byte cho mỗi người chơi, bao gồm tên, cấp độ chiến đấu, thông tin trang bị, màu sắc, hoạt ảnh đi/đứng, giới tính và các biểu tượng trên đầu (cầu nguyện, PK).

Tại sao bước 4 không dùng nén bit?

Một câu hỏi thú vị đặt ra là tại sao bước 4 – phần tốn kém nhất – lại không áp dụng kỹ thuật nén bit như các bước trước. Câu trả lời nằm ở sự đánh đổi giữa CPU và băng thông:

• Nén bit tiêu tốn CPU: Việc đọc từng bit đòi hỏi các thao tác dịch chuyển và kiểm tra bit, tốn kém hơn nhiều so với đọc byte thông thường.
• Không có trạng thái mặc định nhỏ: Mỗi trường trong bước 4, dù nhỏ nhất (như "quay mặt vào thực thể") cũng cần ít nhất 2 byte (một short). Không có "khoảng trống" nào để tiết kiệm.
• Không có sự lặp lại: Bước 4 chỉ chứa thông tin của vài người chơi thay đổi trong chu kỳ đó, không phải tất cả, nên lợi ích từ việc nén không được nhân lên.

Quan trọng hơn, việc giữ bước 4 theo byte-aligned giúp server có thể cache các phần dữ liệu (như buffer ngoại hình) đã được tạo sẵn và ghép (splice) trực tiếp vào gói tin cho mọi người quan sát. Nếu nén bit, vị trí của buffer này sẽ phụ thuộc vào nội dung trước đó, khiến việc cache trở nên vô nghĩa.

Con số biết nói: 9 byte cho một bước đi

Hãy cộng tổng lại cho kịch bản thực tế: bạn đi một bước lên phía Bắc, có 20 người chơi khác trong tầm nhìn của một người quan sát, và chỉ mình bạn di chuyển trong chu kỳ đó.

Gói tin cập nhật người chơi (player-update) sẽ có cấu trúc như sau:

• 1 bit cho người chơi cục bộ (không di chuyển)
• 8 bit cho số lượng người chơi
• 7 bit cho bước đi của bạn
• 19 bit cho 19 người chơi đứng yên (mỗi người 1 bit)
• 11 bit cho sentinel (dấu hiệu kết thúc danh sách người chơi mới)
• 2 bit padding để căn chỉnh byte

Tổng cộng: 48 bit = 6 byte, cộng thêm 1 byte opcode và 2 byte độ dài (vì gói tin này có thể dài hơn 255 byte), tạo thành 9 byte trên đường truyền.

Một vòng khứ hồi hoàn chỉnh cho một bước đi: 7 byte gửi lên + 9 byte nhận về cho mỗi người quan sát. Với băng thông 5 KB/s, bạn có thể dư sức thực hiện hàng trăm bước đi mỗi giây, và vẫn còn chỗ cho chiến đấu, đám đông và chat.

Bài học lớn: Thiết kế hệ thống như một thể thống nhất

Điều thú vị nhất từ phân tích này không chỉ là kỹ thuật nén bit mà là triết lý thiết kế đằng sau nó. Client và server RuneScape không phải là hai hệ thống riêng biệt trao đổi thông điệp với nhau. Chúng được xây dựng như một hệ thống duy nhất, chỉ tình cờ bị phân chia bởi một kết nối TCP.

Mọi sự tối ưu trong giao thức đều dựa trên sự hiểu biết chung mà không bao giờ được truyền tải:

• Cả hai bên cùng chạy một thuật toán tìm đường trên cùng một bản đồ va chạm.
• Cả hai bên đều ngầm hiểu trạng thái mặc định của người chơi là "không thay đổi" – chỉ tốn 1 bit.
• Cả hai bên đều biết "có thể nhìn thấy" nghĩa là "trong bán kính ~15 ô" – nên tọa độ tương đối chỉ cần 5 bit mỗi trục.
• Cả hai bên đều có một bảng cố định về những gì có thể thay đổi – nên một bitmask có thể thay thế cho toàn bộ schema.

Không có sự hiểu biết chung nào được gửi qua mạng. Nó nằm trong thiết kế. Giao thức nhỏ gọn vì hai chương trình được viết cùng nhau, bởi những người coi mạng là một chi tiết triển khai của một ứng dụng duy nhất, thay vì một ranh giới ngăn cách hai thực thể.

Kết luận: Bài học cho thời đại hiện tại

Nhiều người có thể coi đây là di tích của quá khứ – cách mà mọi thứ phải được xây dựng trước khi băng thông trở nên rẻ. Nhưng ranh giới quan trọng không phải là cũ so với mới, mà là hệ thống đó dùng để làm gì và ràng buộc nào thực sự quan trọng.

Các dịch vụ web hiện đại được xây dựng theo phong cách ngược lại: tách rời, tự mô tả (self-describing), có phiên bản, dài dòng (verbose). Một bản cập nhật cảnh tương tự qua JSON over HTTP sẽ tốn hàng trăm byte, với riêng phần header đã lớn hơn 9 byte của RuneScape. Sự "phì nhiêu" này không phải là lãng phí, mà là cái giá để đổi lấy khả năng thay đổi một bên mà không cần triển khai lại bên kia, phục vụ nhiều loại client khác nhau và dễ dàng gỡ lỗi bằng cách đọc dữ liệu trên đường truyền.

Tuy nhiên, nhiều phần mềm hiện đại vẫn đang sống ở "phe RuneScape" của ranh giới này. Một game bắn súng cạnh tranh, một game đối kháng, hay một đường truyền dữ liệu thị trường tài chính – những nơi mà cả hai đầu đều được phát hành cùng nhau và mỗi byte đều có giá trị – đều hướng tới phương pháp đồng thiết kế chặt chẽ, nén bit, và schema được cài sẵn giống như vậy.

Nghiên cứu giao thức RuneScape 2004 là nghiên cứu về kỹ thuật phần mềm dưới một giới hạn tuyệt đối, cứng nhắc. Đó là minh chứng cho thấy khi mỗi byte thực sự có ý nghĩa, sự thông minh sẽ nằm ở việc bạn sắp xếp để không phải gửi đi thứ gì.