侯爍

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

1 背景闡述

傳統(tǒng)TCP協(xié)議運用在移動設(shè)備游戲上所遇到的問題。與有線網(wǎng)絡(luò)的情況不同，有線網(wǎng)絡(luò)的丟包（Packet Loss）可以被一個正態(tài)分布隨機(jī)過程來描述，即在丟包不存在時間相關(guān)性隨機(jī)事件。而無線網(wǎng)絡(luò)的丟包往往可以描述成有兩個狀態(tài)的馬爾可夫過程[1-2]。當(dāng)進(jìn)入平穩(wěn)期時，丟包會呈現(xiàn)為一個正態(tài)分布過程、但是丟包概率還是遠(yuǎn)大于有線傳輸；而進(jìn)入屏障期時，鏈路中傳輸?shù)臄?shù)據(jù)包會出現(xiàn)完全損失。移動網(wǎng)絡(luò)還具有一個異構(gòu)性特點，即用戶會在不同的網(wǎng)絡(luò)環(huán)境下進(jìn)行切換。

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

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

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

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

2 基于UDP傳輸層的KCP協(xié)議

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

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

圖1 LoginServer協(xié)助KCP協(xié)商會話號Conv，并與服務(wù)端通信

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

圖2 UDP端口收不到消息，向LoginServer查詢服務(wù)端狀態(tài)

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

3 基于KCP協(xié)議的MMO網(wǎng)絡(luò)游戲架構(gòu)

一個經(jīng)典的MMO 服務(wù)端，KBEngine，網(wǎng)絡(luò)架構(gòu)圖可以由圖3 來表示[5-6]，客戶端通過服務(wù)端的Gate 進(jìn)程與服務(wù)端的Game 進(jìn)程中的實體進(jìn)行通信。Gate 進(jìn)程會維護(hù)每個與之通信的服務(wù)端實體（Entity）所在的Game 進(jìn)程的路由表，當(dāng)服務(wù)端實體在Game 進(jìn)程之間遷移時，服務(wù)端實體需要跟對應(yīng)Gate進(jìn)行相應(yīng)的維護(hù)。因此可以認(rèn)為，使用TCP協(xié)議與固定的Gate進(jìn)行通信，通過Gate路由之后，即可以跟Game進(jìn)程進(jìn)行雙向收發(fā)RPC消息。

圖3 KBEngine服務(wù)器框架

在引入KCP 連接的概念后，在對原有服務(wù)端架構(gòu)不進(jìn)行大規(guī)模修改的前提下，基于KCP 的服務(wù)端架構(gòu)由圖4可知，額外添加一個負(fù)責(zé)登錄和查詢的微服務(wù)，并在Gate之外額外添加一層UDPGate進(jìn)程。

圖4 基于KCP的網(wǎng)絡(luò)游戲服務(wù)器框架

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

圖5 新的登錄流程

客戶端與服務(wù)端的RPC通信流程可以用圖6來表示。UDPGate進(jìn)程負(fù)責(zé)維護(hù)KCP的會話號到Gate進(jìn)程之間的路由和消息傳遞，當(dāng)UDPGate 收到一個UDP 帶有一個陌生的會話號時，會去Redis進(jìn)程中查找對應(yīng)的Gate 進(jìn)程并將這個路由信息保存下來，UDPGate 負(fù)責(zé)將收到的UDP 消息發(fā)送到對應(yīng)Gate 進(jìn)程，Gate 進(jìn)程持有KCP對象對UDP消息進(jìn)行解包，獲得原始的RPC消息，從而轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)端實體進(jìn)行RPC調(diào)用。

圖6 客戶端與服務(wù)端的RPC通信流程

4 結(jié)語

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