提示：閱讀本文前，請先讀此文了解文章背景：http://data.gameres.com/message.asp?TopicID=27236

　　讓無數中國玩家為之矚目的“魔獸世界”，隨著一系列內測前期工作的逐步展開，正在一步步地走近中國玩家，但是，“魔獸”的服務器，卻著實讓我們為它捏了一把汗。

造成一個網游服務器當機的原因有很多，但主要有以下兩種：一，服務器在線人數達到上限，服務器處理效率嚴重遲緩，造成當機；二，由于外掛或其它游戲作弊 工具導致的非正常數據包的出錯，導致游戲服務器邏輯出現混亂，從而造成當機。在這里，我主要想說說后者如何盡可能地避免。

　　要避免以上 所說到的第二種情況，我們就應該遵循一個基本原則：在網游服務器的設計中，對于具有較強邏輯關系的處理單元，服務器端和客戶端應該采用“互不信任原則”， 即：服務器端即使收到了客戶端的數據包，也并不是立刻就認為客戶端已經達到了某種功能或者狀態，客戶端到達是否達到了某種功能或者狀態，還必須依靠服務器 端上記載的該客戶端“以往狀態”來判定，也就是說：服務器端的邏輯執行并不單純地以“當前”的這一個客戶端封包來進行，它還應該廣泛參考當前封包的上下文 環境，對執行的邏輯作出更進一步地判定，同時，在單個封包的處理上，服務器端應該廣泛考慮當前客戶端封包所需要的“前置”封包，如果沒有收到該客戶端應該 發過來的“前置”封包，則當前的封包應該不進行處理或進行異常處理（如果想要性能高，則可以直接忽略該封包；如果想讓服務器穩定，可以進行不同的異常處 理）。

　　之所以采用“互不信任”原則設計網游服務器，一個很重要的考慮是：防外掛。對于一個網絡服務器（不僅僅是游戲服務器，泛指所有 服務器）而言，它所面對的對象既有屬于自己系統內的合法的網絡客戶端，也有不屬于自己系統內的非法客戶端訪問。所以，我們在考慮服務器向外開放的接口時， 就要同時考慮這兩種情況：合法客戶端訪問時的邏輯走向以及非法客戶端訪問時的邏輯走向。舉個簡單的例子：一般情況下，玩家登錄邏輯中，都是先向服務器發送 用戶名和密碼，然后再向服務器發送進入某組服務器的數據包；但在非法客戶端（如外掛）中，則這些客戶端則完全有可能先發進入某組服務器的數據包。當然，這 里僅僅是舉個例子，也許并不妥當，但基本的意思我已經表達清楚了，即：你服務器端不要我客戶端發什么你就信什么，你還得進行一系列的邏輯驗證，以判定我當 前執行的操作是不是合法的。以這個例子中，服務器端可以通過以下邏輯執行驗證功能：只有當客戶端的用戶名和密碼通過驗證后，該客戶端才會進入在線玩家列表 中。而只有在線玩家列表中的成員，才可以在登陸服務器的引導下進入各分組服務器。

　　總之，在從事網游服務器的設計過程中，要始終不移地 堅持一個信念：我們的服務器，不僅僅有自己的游戲客戶端在訪問，還有其它很多他人寫的游戲客戶端在訪問，所以，我們應該確保我們的服務器是足夠強壯的，任 它風吹雨打也不怕，更不會倒。如果在開發實踐中，沒有很好地領會這一點或者未能將這一思路貫穿進開發之中，那么，你設計出來的服務器將是無比脆弱的。

當然，安全性和效率總是相互對立的。為了實現我們所說的“互不信任”原則，難免的，就會在游戲邏輯中加入很多的異常檢測機制，但異常檢測又是比較耗時 的，這就需要我們在效率和安全性方面作個取舍，對于特別重要的邏輯，我們應該全面貫徹“互不信任”原則，一步扣一步，步步為營，不讓游戲邏輯出現一點漏 洞。而對于并非十分重要的場合，則完全可以采用“半信任”或者根本“不須信任”的原則進行設計，以盡可能地提高服務器效率。

　　本文只是對自己長期從事游戲服務器設計以來的感受加以總結，也是對魔獸的服務器有感而發。歡迎有相同感受的朋友或從事相同工作的朋友一起討論。