Kế Hoạch Thêm Hỗ Trợ Liên Kết Ngắn Cho Skynet

Anonymous trong Hướng Dẫn và Phát Triển Nhanh

2014-07-01 Khoảng 1000 từ 5 phút

Dự kiến mở rộng hỗ trợ kết nối ngắn (short connection) cho Skynet

Trong lĩnh vực game web, mô hình không phụ thuộc vào kết nối TCP ổn định đã được áp dụng rộng rãi, thường xây dựng dựa trên giao thức HTTP để phù hợp với môi trường trình duyệt. Đối với game di động hoạt động trên mạng không dây, chất lượng kết nối mạng thường kém ổn định hơn nhiều so với game PC truyền thống, dẫn đến tình trạng người chơi bị ngắt kết nối đột ngột và thoát game ngoài ý muốn. Gần đây tôi đã phát triển một thư viện nhằm giảm thiểu vấn đề này.

Nếu logic nghiệp vụ xây dựng dựa trên kết nối ngắn, hệ thống sẽ đơn giản hơn nhiều, tuy nhiên cũng tồn tại những hạn chế sau:

Mỗi cặp yêu cầu-phản hồi đều độc lập, không đảm bảo thứ tự xử lý
Việc máy chủ đẩy dữ liệu (push) xuống máy khách trở nên phức tạp, thường yêu cầu máy khách phải gửi yêu cầu định kỳ
Bảo mật kém hơn, thường phải dùng chuỗi session để xác thực, nếu không mã hóa kênh truyền thì dễ bị đánh cắp thông tin

Dù có những hạn chế trên, mô hình này vẫn được ứng dụng rộng rãi. Trong phiên bản sắp tới của Skynet, tôi dự định tích hợp một số cơ chế hỗ trợ, tập trung vào giải quyết vấn đề xác thực danh tính - một trong những thách thức lớn nhất, đồng thời xây dựng hệ thống quản lý trạng thái trực tuyến và quy trình xác thực đăng nhập một cách gọn gàng, hiệu quả hơn.

Tôi không sử dụng HTTP vì khi đã có client chuyên dụng thì không cần phụ thuộc vào giao thức trình duyệt nữa. Về mặt hiệu năng, sau khi thiết lập kết nối TCP, hệ thống vẫn có thể gửi nhiều yêu cầu trên cùng một kết nối. Chỉ khi phát hiện kết nối không ổn định mới yêu cầu tạo kết nối mới.

Nhờ không phụ thuộc vào kết nối dài (long connection), hệ thống có thể tách biệt hoàn toàn quy trình đăng nhập và logic game. Toàn bộ hệ thống bao gồm 4 thành phần chính: máy chủ xác thực (login server), máy chủ chứng thực (auth server), máy chủ game và máy khách. Quy trình đăng nhập thực hiện theo các bước sau:

Xác thực máy khách: Máy khách gửi yêu cầu đến máy chủ chứng thực để nhận token xác thực. Token này thường chứa ID người dùng và dữ liệu kiểm chứng, thường được cấp thông qua SDK nền tảng thứ ba đối với ứng dụng di động.
Nhận bí mật đăng nhập: Máy khách nộp token này cho máy chủ xác thực để đổi lấy một chuỗi bí mật. Giai đoạn này đóng vai trò như cổng kiểm soát tải hệ thống - khi có quá nhiều người đăng nhập, hệ thống có thể sắp xếp theo hàng đợi. Việc thiết kế độc lập giúp nhiều dự án khác nhau có thể chia sẻ chung hệ thống này. Máy chủ xác thực giữ vai trò quản lý trạng thái trực tuyến của người dùng, đồng thời quyết định xử lý các yêu cầu đăng nhập trùng lặp theo các chính sách: ghi đè phiên đăng nhập cũ, từ chối yêu cầu mới hoặc cho phép đăng nhập đồng thời.
Thiết lập kết nối mã hóa với máy chủ game: Máy khách sử dụng chuỗi bí mật nhận được để thiết lập kênh truyền mã hóa với máy chủ game. Chuỗi bí mật này được máy chủ xác thực phân phát đến máy chủ game trước đó, đảm bảo máy chủ game sẵn sàng đón nhận kết nối từ người dùng.

Quản lý danh tính linh hoạt
Mỗi người dùng được phân bổ một định danh duy nhất theo cấu trúc: uid@nút_đăng_nhập/subid, trong đó:

uid: Có thể là ID từ nền tảng thứ ba hoặc do máy chủ xác thực tự sinh, tạo điều kiện tích hợp đa nền tảng
subid: Chuỗi ngẫu nhiên duy nhất nhằm hỗ trợ trường hợp người dùng đăng nhập đồng thời từ nhiều thiết bị

Hệ thống hỗ trợ truy vấn trạng thái trực tuyến thông qua ID, trả về toàn bộ tập định danh liên quan. Khi phát hiện yêu cầu đăng nhập trùng lặp, máy chủ xác thực sẽ gửi RPC đến các máy chủ game đang chứa phiên đăng nhập cũ để xử lý theo chính sách (từ chối, ngắt kết nối cũ hoặc cho phép đăng nhập song song).

Quy trình thiết lập kết nối an toàn
Sau khi đăng nhập thành công, máy khách nhận hai thông tin quan trọng:

Định danh duy nhất uid@node/subid
Chuỗi bí mật dùng để mã hóa kênh truyền với máy chủ game

Giao thức kết nối thực hiện theo quy trình:

Gửi thông tin định danh uid@node/subid:id:randomkey (với id là số lần bắt tay tăng dần, randomkey là chuỗi ngẫu nhiên)
Sử dụng tổ hợp secret+id để mã hóa toàn bộ lưu lượng truyền sau đó
Máy chủ game kiểm tra randomkey trong lưu lượng mã hóa để phát hiện kết nối giả mạo

Tối ưu hóa trải nghiệm đăng nhập
Khi cần thiết lập lại kết nối, máy khách không cần quay lại máy chủ xác thực. Chỉ cần tăng giá trị id, tạo randomkey mới và thực hiện lại quá trình bắt tay. Máy chủ game có thể giới hạn số kết nối đồng thời trên mỗi người dùng nhằm tối ưu tài nguyên hệ thống.

Bảo mật kênh truyền
Giao tiếp giữa máy khách và máy chủ xác thực nên sử dụng kênh truyền mã hóa. Nếu không dùng HTTPS tiêu chuẩn, có thể áp dụng giao thức trao đổi khóa DH (Diffie-Hellman) kết hợp mã hóa luồng RC4 để giảm tải chi phí xử lý.