適用于移動設備的可靠傳輸協議與MMO網絡游戲服務器架構

侯爍

(杭州碧游信息技術有限公司 浙江杭州 310012)

1 背景闡述

傳統TCP協議運用在移動設備游戲上所遇到的問題。與有線網絡的情況不同，有線網絡的丟包（Packet Loss）可以被一個正態分布隨機過程來描述，即在丟包不存在時間相關性隨機事件。而無線網絡的丟包往往可以描述成有兩個狀態的馬爾可夫過程[1-2]。當進入平穩期時，丟包會呈現為一個正態分布過程、但是丟包概率還是遠大于有線傳輸；而進入屏障期時，鏈路中傳輸的數據包會出現完全損失。移動網絡還具有一個異構性特點，即用戶會在不同的網絡環境下進行切換。

目前，TCP 協議一直是被最廣泛使用的實現網絡游戲客戶端與服務端可靠通信的協議。但是在TCP協議設計時還沒有出現移動網絡，TCP 是完全按照有線網絡的設計思路下的產物，因此直接在TCP 協議之上設計移動端網絡游戲的通信架構，會帶來以下幾個方面的問題。

（1）在雙方互不發送信息時，即使網絡層已經發生改變無法通信，沒有收發信息造成的網絡層錯誤信息（SocketError），不能立刻判斷出現了斷線的狀態，因此很多網絡架構中如果長時間沒有網絡交互的情況下，會定期發送PING 消息來相互確認網絡狀態，因此PING 消息的間隔決定了基于TCP 協議的網絡層斷線重連的敏感度和反應速度，但即使每秒發送一次PING也會讓玩家感受到明顯的卡頓，而過高頻率的PING消息則消耗了網絡和服務器計算資源。而過于靈敏的PING機制會在移動網絡進入短暫的屏障期后，由于沒有收到PING消息對斷線進行“誤判”，從而對用戶的體驗進行打斷。

（2）在移動端設備經常出現的網絡切換后，由于源地址變更后TCP 協議無法收到ACK，不能確定對方是否收到在斷線之前發送的數據包，這樣“可靠”的連接在發生斷線之后就變得“不可靠”了。因此，很多移動端游戲在發生斷線TCP重連后往往需要進行打斷當前游戲體驗進行重新登錄操作，重新“可靠的”讓客戶端與服務端的數據進行一次同步。而這樣的體驗，對于在公交車或者地鐵上使用的用戶來說是不可接受的。

（3）無線網絡在穩定期丟包是因為隨機信號干擾導致的隨機丟包。而TCP協議由于設計之初視為有線網絡服務，擁塞控制認為丟包意味著網絡擁塞，需要禮貌性地“慢啟動”縮小發送窗口進行退讓[3]。而且TCP的收發機制由于是在操作系統內核態中進行處理，程序無法對其進行控制，當出現丟包后，必須等待ACK超時機制進行重發而程序無法干預。這些問題導致TCP 在無線信道環境下延遲較高，且無法持續達到最高速率進行傳輸。

2 基于UDP傳輸層的KCP協議

之所以出現上述問題，是因為TCP 將端對端的傳輸以及擁塞控制，以及可靠傳輸這兩個功能，耦合在了一個協議中。而這個協議被操作系統層實現，代碼無法控制。在客戶端和服務端的進程都正常運行時，即使出現了斷網現象，雙方的可靠傳輸機制中的數據包序號、超時重傳機制仍然有效，可以在網絡層將數據包傳送到對方之后繼續工作。KCP協議是一個運行在會話層的，負責通過在其KCP 包頭的CONV 字段（會話號）進行會話的唯一性標識，與TCP可靠傳輸原理類似的可靠傳輸協議，但是它并不關注數據是如何被傳輸的。而UDP協議只負責端到端的數據傳輸，但是它不關心數據是否能夠被對方收到。將KCP 運行在UDP之上，類似實現了將TCP 協議的端對端傳輸與可靠性保證兩個功能做了解耦。

但是這樣的設計并沒有TCP 的“三次握手”，客戶端無法自發“優雅”地與服務端協商會話號從而建立連接，因此在建立連接時客戶端與服務端需要先通過第三方使用TCP或者HTTP協議協商會話號，在會話號被同步到客戶端與服務端之后才能進行通信，建立連接流程具體見圖1。

圖1 LoginServer協助KCP協商會話號Conv，并與服務端通信

同樣由于這個過程沒有“四次揮手”，因此在長時間收不到對方消息的情況下，一方面可能是網絡的確長時間存在問題，另一方面可能是對方進程已經退出所以我方也應該進行退出操作。在無法判斷這兩種情況下，仍然需要借助第三方通過TCP或者HTTP協議進行對方狀態的查詢，具體見圖2。

圖2 UDP端口收不到消息，向LoginServer查詢服務端狀態

由于UDP 的無連接屬性[4]，客戶端無論由于網絡切換造成源地址變換，還是客戶端鏈通信恢復后，不需要像TCP那樣先要發現網絡斷開、再重新發送“三次握手”請求，即可相互發送數據，大大降低了傳輸層恢復的速度。而只要通信雙方的KCP 連接對象存活，KCP層都可以通過超時重發機制進行可靠的通信。而且由于KCP 數據包是在用戶程序層面生成的，程序控制利用UDP發送KCP數據包的頻率，可以設計更加適合無線信道環境的擁塞控制機制，甚至可以通過一次發送對一個KCP 數據包多次發送的方法，來抵抗隨機丟包重發造成的延時。

3 基于KCP協議的MMO網絡游戲架構

一個經典的MMO 服務端，KBEngine，網絡架構圖可以由圖3 來表示[5-6]，客戶端通過服務端的Gate 進程與服務端的Game 進程中的實體進行通信。Gate 進程會維護每個與之通信的服務端實體（Entity）所在的Game 進程的路由表，當服務端實體在Game 進程之間遷移時，服務端實體需要跟對應Gate進行相應的維護。因此可以認為，使用TCP協議與固定的Gate進行通信，通過Gate路由之后，即可以跟Game進程進行雙向收發RPC消息。

圖3 KBEngine服務器框架

在引入KCP 連接的概念后，在對原有服務端架構不進行大規模修改的前提下，基于KCP 的服務端架構由圖4可知，額外添加一個負責登錄和查詢的微服務，并在Gate之外額外添加一層UDPGate進程。

圖4 基于KCP的網絡游戲服務器框架

新的登錄流程可以用圖5 來表示，當客戶端通過HTTP 與登錄微服務發送Login 請求并通過后，微服務隨機選擇一個Game 進程生成一個實體，Game 實體向Gate 注冊后，由Gate 進程生成一個KCP 對象并申請一個全服唯一的KCP 會話號，并將KCP 會話號到對應Gate 的路由信息寫入一個Redis 進程，然后會話號和UDPGate 的IP 和端口通過TCP 的LoginSuccess 發送給客戶端完成正常登錄流程。

圖5 新的登錄流程

客戶端與服務端的RPC通信流程可以用圖6來表示。UDPGate進程負責維護KCP的會話號到Gate進程之間的路由和消息傳遞，當UDPGate 收到一個UDP 帶有一個陌生的會話號時，會去Redis進程中查找對應的Gate 進程并將這個路由信息保存下來，UDPGate 負責將收到的UDP 消息發送到對應Gate 進程，Gate 進程持有KCP對象對UDP消息進行解包，獲得原始的RPC消息，從而轉發到對應的服務端實體進行RPC調用。

圖6 客戶端與服務端的RPC通信流程

4 結語

與現在大部分基于TCP協議的游戲服務器框架相比，這個服務器框架，通過在KCP層將傳輸層的斷線進行隱藏，解決了上層業務邏輯被鏈路斷線所打斷的問題，也可以給用戶帶來網絡無縫切換的體驗。在這個框架下，客戶端可以通過與不僅僅一個UDPGate 進行通信，在不登出游戲的情況下，客戶端可以進行無縫的選擇在最快的接入點之間進行切換。而且這個游戲服務器框架這是在原有服務器框架下進行了一些進程節點的添加，改動量小，可以在現有服務器上進行快速的部署升級。