Wow 服務器解析（一）

?????? 最近抽空研究了一下 WOW 的服務器結構，也順便從那些項目中又復習了一下 ManGOs 中 template 方式下 SingleTon 的使用方法。不過有些不明白的，如果這樣， SingleTon<Master> 這樣的使用，如果傳入的類型不同，難道傳出的 static 是一樣的？不可能吧，如果打印出 this 指針看看呢？抽空我再試試。 SingleTon 在游戲設計中是相當重要的設計模式，大家一定要好好學習。

認證過程

Wow 的服務器有兩部分組成： Logon Server （以下簡稱 LS ）和 Realm Server （以下簡稱 RS ）。 LS 接受來自 Wow 客戶端的連接，主要有以下幾步完成：

檢查客戶端版本區域等信息，檢察賬號密碼

開始 / 繼續傳送 Patch （如果有）

與客戶端進行 SRP6 的加密會話，把生成的密匙寫入數據庫

根據客戶端請求發送 Realms 列表

當客戶端選擇好 Realms 后，客戶端就從 LS 斷開，連接到 RS 上：

認證，使用剛才生成的客戶端密匙

如通過，進行游戲循環的交互

RS 和 LS 使用相同的數據庫， SRP6 密匙被 LS 生成并寫入 DB 后還要由 RS 讀取出來進行下一步的認證。

?

Logon Server 詳解

基本的連接過程如下：

客戶端準備連接，發送 CMD_AUTH_LOGON_CHALLENGE 數據包，包含了所有登陸所需要的數據比如用戶名密碼等

服務端返回 CMD_AUTH_LOGON_CHALLENGE 數據包，填充字段包括有效驗證，以及計算好的服務端 SRP6 數據

如果有效，客戶端發送 CMD_AUTH_LOGON_PROOF 數據包，并把自己計算的 SRP6 數據填充進去

服務端進行驗證，發送回 CMD_AUTH_LOGON_PROOF ，包含了 SRP6 驗證的結果

如果一切正常，客戶端發送 CMD_REALM_LIST 數據包，請求發送有效的 Realm

服務器回復 CMD_REALM_LIST 數據報，并填充過客戶端需要的 Realm 數據

客戶端的 Realm 列表每隔 3-4 秒就會從服務器端刷新一次。

? 這個 SPR6 是一種什么樣的加密手段呢？以前我也沒有用過，看得最多的是 MD5SHA 等 hash 算法。 SPR 算法吸取了 EKE 類型算法的優點進行了改進，非常適合于網絡的認證服務，如果我沒有記錯， J2EE 包含了這個算法的實現。下面簡單介紹一下 SRP6a 運作機制，原文見這里。

N???? N = 2q + 1 ， q 是一個素數，下面所有的取模運算都和這個 N 有關

g ??? 一個 N 的模數，應該是 2 個巨大的素數乘得來

k???? k = H(N,G) 在 SRP6 中 k = 3

s????? User’s Salt

I????? 用戶名

p???? 明文密碼

H()? 單向 hash 函數

^????? 求冪運算

u???? 隨機數

a,b?? 保密的臨時數字

A,B? 公開的臨時數字

x???? 私有密匙（從 p 和 s 計算得來）

v???? 密碼驗證數字

其中 x? =? H(s,p) 和 v = g ^ x ， s 是隨機選擇的， v 用來將來驗證密碼。

主機將 { I,s,v } 存入數據庫。認證的過程如下：

?

客戶向主機發送 I ， A = g ^ a （ a 是一個隨機數）

主機向客戶發送 s ， B = kv + g^b （發送 salt ， b 是一個隨機數字）

雙方同時計算 u = H(A,B)

客戶計算機算 x = H(s,p) （開始 hash 密碼）， S = ((B - kg^x) ^ (a + ux) ) ， K = H(S) ，（開始計算會話 Key ）

主機計算 S = (Av^u)^b ， K = H(S) ，也生成會話 Key

?

為了完成認證，雙方交換 Key ，各自進行如下的計算：

客戶接收到來自主機的 key 后，計算 H(A,M,K)

同理，主機計算 M = H(H(N) xor H(g), H(I), s, A, B, K) ，驗證是否合自己儲存的數值匹配。至此完成驗證過程。

?

三、 Realm Server 詳解

從 LS 斷開后，開始和 RS 認證：

連接到 RS ，向服務器發送 SMSG_AUTH_CHALLENGE 數據包，包含上次所用的隨機種子

服務器發送回 SMSG_AUTH_CHALLENG ?？蛻舳藦姆掌鞫税l送回來的種子和 SRP6 數據中產生隨機種子，生成 SHA1 字符串，用這些數據生成 CMSG_AUITH_SESSION 數據包，發送給服務端。

需要注意的是，這個過程是沒有經過加密的。當服務端收到認證回復后，通過客戶端產生的種子也生成一個 SHA1 串和來自客戶端的進行對比，如果相同，一切 OK 。

?

下面看一下對賬號創建的角色等操作進行分析。一個賬號最多可以建 50 個角色吧，我還沒有玩過，只是看了一下 Manual 。

?客戶端發送一個CMSG_CHAR_ENUM數據包請求接受角色

服務端發送回包含所有角色信息的 CMSG_CHAR_ENUM 數據包

這里客戶端可以對這些角色進行操作了， CMSG_CHAR_CREATE ， CMSG_CHAR_DELETE ， CMSG_CHAR_PLAYER_LOGIN

角色登陸完成后，服務器發送回 SMSG_CHAR_DATA 數據包

在游戲循環中是如何操作的呢？

如果玩家立刻退出游戲，那么客戶端發送 CMSG_PLAYER_LOGOUT ，服務器回復 SMSG_LOGOUT_COMPLETE

如果玩家選擇稍后退出游戲，發送 CMSG_LOGOUT_REQUEST 。服務端回復 SMSG_LOGOUT_RESPONSE 。如果玩家在倒計時階段退出，發送 CMSG_PLAYER_LOGOUT ，那么玩家的角色依舊等倒計時完成后再退出。

如果玩家中斷了退出繼續游戲，發送 CMSG_LOGOUT_CANCEL ，服務器回復 SMSG_LOGOUT_CANCEL_ACK 。