簡介面向Unity客戶端與Skynet服務(wù)端聯(lián)調(diào)需求的開發(fā)者這份源碼包圍繞sproto協(xié)議展示了完整的雙向通信實(shí)現(xiàn)尤其適合正在學(xué)習(xí)游戲后端框架或需要快速搭建通信原型的讀者。壓縮包共3個文件以.inscode腳本、.html說明頁和.gitignore配置為主整體僅有7KB內(nèi)容精簡便于直接查看核心代碼和工程結(jié)構(gòu)。已有207人學(xué)習(xí)查看對于一個小體量示例資源具備一定參考價值。包內(nèi)提供了客戶端sayhello消息與服務(wù)端heartbeat消息的收發(fā)示例包含協(xié)議文件轉(zhuǎn)C#腳本的關(guān)鍵過程可幫助理解從Skynet環(huán)境搭建到Unity端連接的整條鏈路同時index.html可作為可視化參考inscode腳本則適合在云端或本地快速運(yùn)行調(diào)試讀者可對照源碼理解協(xié)議定義、消息封裝、連接建立與心跳維持等細(xì)節(jié)并復(fù)用到實(shí)際項目的通信模塊設(shè)計中。 Unity客戶端接Skynet服務(wù)端這事兒說難不難說簡單也真不簡單。我見過太多人在第一步就卡住網(wǎng)關(guān)地址配好了TCP也連上了結(jié)果服務(wù)端收到的是一堆亂碼或者客戶端直接閃退查了半天發(fā)現(xiàn)是字節(jié)序?qū)Σ簧?。更常見的坑是粘包半包處理不到位客戶端瘋狂發(fā)消息服務(wù)端解析出來全是錯位的垃圾數(shù)據(jù)。這篇文章就拿一套能跑的完整代碼講透從協(xié)議設(shè)計、C#客戶端封裝到Lua網(wǎng)關(guān)邏輯最后把我在實(shí)際項目中踩過的坑和排錯思路一并甩出來。適合剛接觸Skynet的Unity客戶端開發(fā)也適合后端想快速給Unity開一個通信通道的人。這套方案最終實(shí)現(xiàn)的效果是Unity客戶端能穩(wěn)定連接Skynet網(wǎng)關(guān)按照自定義的二進(jìn)制協(xié)議收發(fā)消息支持心跳保活、斷線重連、大數(shù)據(jù)包拆包同時服務(wù)端能按消息類型分發(fā)到對應(yīng)邏輯服務(wù)處理。麻雀雖小五臟俱全跑通之后往里面填業(yè)務(wù)字段就能用。1. 先搞清楚Unity和Skynet到底怎么配合1.1 為什么用Skynet做游戲服務(wù)端聊通信之前得先想清楚Skynet在這條鏈路里扮演什么角色。Skynet是一個基于Actor模型的輕量級服務(wù)端框架核心是“服務(wù)”這個概念一個服務(wù)就是一個獨(dú)立的Lua虛擬機(jī)服務(wù)之間通過消息投遞通信底層由Skynet節(jié)點(diǎn)調(diào)度。開發(fā)的時候一般按業(yè)務(wù)拆服務(wù)比如登錄服務(wù)、房間服務(wù)、數(shù)據(jù)中心各管一攤活。Unity作為客戶端本質(zhì)上是“外部世界”。Skynet內(nèi)部服務(wù)之間互相發(fā)消息是同一套機(jī)制但Unity不在Skynet節(jié)點(diǎn)內(nèi)部所以必須經(jīng)過網(wǎng)絡(luò)層進(jìn)網(wǎng)關(guān)。網(wǎng)關(guān)通常叫Gate是所有外部連接的入口它持有每個客戶端的連接句柄fd然后把收到的消息轉(zhuǎn)發(fā)給相應(yīng)的內(nèi)部服務(wù)內(nèi)部服務(wù)處理完再通過網(wǎng)關(guān)把響應(yīng)推回客戶端。這個模型很清晰但很多項目死在第一步網(wǎng)關(guān)怎么接、消息怎么編解碼、連接斷了怎么通知邏輯層。1.2 通信鏈路的整體架構(gòu)畫一個最簡單的鏈路手畫不依賴工具Unity客戶端 (C#) │ TCP長連接, 自定義二進(jìn)制協(xié)議 ▼ Skynet網(wǎng)關(guān)服務(wù) (Lua) │ 服務(wù)間消息投遞 ▼ Skynet邏輯服務(wù) (Lua)客戶端只管和網(wǎng)關(guān)通信不感知后端有多少個服務(wù)。網(wǎng)關(guān)收到一條客戶端消息后根據(jù)消息頭里的msg_id或cmd字段決定轉(zhuǎn)發(fā)給哪個服務(wù)。這種設(shè)計的好處是換邏輯服務(wù)時客戶端完全無感只要協(xié)議不變前后端并行開發(fā)互不阻塞。從實(shí)測來看這個架構(gòu)下Unity端的核心工作量不在業(yè)務(wù)而在三塊Socket連接管理、字節(jié)緩沖區(qū)的粘包拆包、C#結(jié)構(gòu)體和字節(jié)流的互轉(zhuǎn)。后端的核心工作量則在網(wǎng)關(guān)的消息分發(fā)和連接生命周期管理。2. 通信協(xié)議設(shè)計一切從“報文格式”開始2.1 定長包頭 變長包體協(xié)議怎么定直接決定后面所有代碼怎么寫。我建議用“定長包頭 變長包體”的結(jié)構(gòu)這是游戲通信里最穩(wěn)妥的方案沒有之一。包頭固定8字節(jié)包含兩個int字段包體長度4字節(jié)和消息ID4字節(jié)。包體就是具體的業(yè)務(wù)數(shù)據(jù)長度由包頭里的長度字段決定。[包體長度: 4字節(jié)][消息ID: 4字節(jié)][包體數(shù)據(jù): N字節(jié)]為什么包頭要固定8字節(jié)而不是直接讀流到結(jié)束因為TCP是流協(xié)議沒有消息邊界。如果你不定包頭接收方根本不知道一條消息到哪結(jié)束。定長包頭的好處是接收方先積累8字節(jié)解析出長度字段再根據(jù)長度等待剩余數(shù)據(jù)這樣就能準(zhǔn)確切出每一條完整消息。消息ID用于區(qū)分請求和響應(yīng)。比如客戶端登錄消息ID是10001服務(wù)端返回登錄結(jié)果消息ID是10002。如果后面加了心跳消息ID就是10003。用數(shù)字而不是字符串的好處是省流量、解包快而且C#和Lua互轉(zhuǎn)整數(shù)都很方便。2.2 字節(jié)序統(tǒng)一一個大坑必須從第一天解決字節(jié)序是跨語言通信最容易翻車的點(diǎn)。C#的BitConverter默認(rèn)用本機(jī)字節(jié)序Windows/Linux通常是Little Endian小端而Skynet的socket庫自帶包頭封裝用的是Big Endian大端默認(rèn)讀取包頭時按大端解。如果你自定義協(xié)議不做統(tǒng)一就會出現(xiàn)“我發(fā)的是1你收到的是16777216”這種詭異問題。建議在項目里立一個規(guī)矩所有包頭字段統(tǒng)一用大端Big Endian也就是網(wǎng)絡(luò)字節(jié)序。包體里的字段也盡量統(tǒng)一。C#端用BinaryWriter默認(rèn)是小端所以要么手動逆序要么自定義寫字節(jié)的方法。我習(xí)慣寫兩個工具函數(shù)WriteInt和ReadInt內(nèi)部自己處理字節(jié)序這樣就不會到處犯低級錯誤。public static void WriteInt(Stream stream, int value) { // 統(tǒng)一轉(zhuǎn)大端先轉(zhuǎn)網(wǎng)絡(luò)字節(jié)序再寫 byte[] bytes BitConverter.GetBytes(value); if (BitConverter.IsLittleEndian) { Array.Reverse(bytes); } stream.Write(bytes, 0, bytes.Length); }Lua端同樣要配套。Skynet的socket庫提供了pack和unpack但那是給包頭用的。自定義包體建議用string.pack并指定大端格式-- 表示大端I 表示無符號int local body string.pack(I4, msg_id) .. ... -- 拼包體字段字節(jié)序這玩意兒前后端各寫各的時候最容易出問題。一定要在聯(lián)調(diào)第一天就把這個規(guī)則寫進(jìn)文檔我吃過虧后面細(xì)講。3. Unity側(cè)客戶端封裝C#代碼落地3.1 Socket連接與狀態(tài)管理Unity端核心類我封裝成SkynetClient負(fù)責(zé)Socket連接、數(shù)據(jù)收發(fā)、心跳和重連。構(gòu)造函數(shù)傳入地址和端口連接用BeginConnect異步方式避免阻塞主線程導(dǎo)致Unity卡頓。public class SkynetClient { private Socket socket; private bool isConnected; private const int HEADER_SIZE 8; private byte[] buffer new byte[1024 * 64]; private MemoryStream recvStream new MemoryStream(); public void Connect(string host, int port) { socket new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); socket.BeginConnect(host, port, OnConnected, null); } private void OnConnected(IAsyncResult ar) { socket.EndConnect(ar); isConnected true; socket.BeginReceive(buffer, 0, buffer.Length, SocketFlags.None, OnReceive, null); } public void Close() { isConnected false; if (socket ! null) { socket.Close(); socket null; } } }文件里留了個HEADER_SIZE 8常量后面拆包會用到。狀態(tài)管理上要注意Unity切后臺、斷網(wǎng)、被系統(tǒng)強(qiáng)殺Socket的狀態(tài)都不一樣。建議加一個ConnectionState枚舉Connecting/Connected/Reconnecting/Closed在Update里根據(jù)狀態(tài)自動重連。這個細(xì)節(jié)對移動端尤其重要后面單獨(dú)說。3.2 粘包拆包接收緩沖區(qū)的正確打開方式TCP是流協(xié)議消息不保證一次到達(dá)也不保證每次到達(dá)的數(shù)據(jù)剛好是一條完整消息。客戶端可能一次收到半條、一條半、兩條半。拆包的核心思路把收到的數(shù)據(jù)append到一個累積緩沖區(qū)然后循環(huán)從緩沖區(qū)里提取完整消息直到剩余字節(jié)不足以構(gòu)成一條完整消息為止。private void OnReceive(IAsyncResult ar) { int bytesRead socket.EndReceive(ar); if (bytesRead 0) { // 連接被對端關(guān)閉 isConnected false; return; } recvStream.Write(buffer, 0, bytesRead); // 循環(huán)拆包 while (true) { recvStream.Position 0; if (recvStream.Length HEADER_SIZE) { break; // 連包頭都不夠 } // 讀取包頭 byte[] header new byte[HEADER_SIZE]; recvStream.Read(header, 0, HEADER_SIZE); int bodyLen ReadInt(header, 0); int msgId ReadInt(header, 4); if (recvStream.Length - HEADER_SIZE bodyLen) { // 包體還沒齊回退緩沖區(qū) ResetStreamWithRemaining(header); break; } byte[] body new byte[bodyLen]; recvStream.Read(body, 0, bodyLen); DispatchMessage(msgId, body); // 處理完后把剩余數(shù)據(jù)壓縮到流頭部 TrimStream(); } socket.BeginReceive(buffer, 0, buffer.Length, SocketFlags.None, OnReceive, null); }這里有個很關(guān)鍵的操作ResetStreamWithRemaining和TrimStream。當(dāng)包頭獲取到了但包體不足時要把這個包頭重新塞回緩沖區(qū)不然下次接收會把包頭丟掉。每次處理完一條完整消息后要把流里剩余的數(shù)據(jù)挪到最前面方便下一輪循環(huán)繼續(xù)讀。很多初學(xué)者就是栽在這里收到半包后直接把數(shù)據(jù)清了結(jié)果對端重發(fā)數(shù)據(jù)就亂了。我這里的實(shí)現(xiàn)用MemoryStream做累積緩沖實(shí)時性夠用。如果對性能有要求可以換成byte[] offset的手寫環(huán)形緩沖但Unity端一般網(wǎng)絡(luò)流量不大MemoryStream完全夠用。3.3 發(fā)送封裝與心跳機(jī)制發(fā)送時同樣要按協(xié)議拼包頭。包體我們先用byte[]傳遞實(shí)際業(yè)務(wù)可以用BinaryWriter或MemoryStream組裝。發(fā)送前先發(fā)包頭再發(fā)包體。為了簡單可以直接把包頭和包體拼到同一個byte[]里再Send避免兩次發(fā)送的間隙被對端誤判為兩條獨(dú)立消息。public void Send(int msgId, byte[] body) { if (!isConnected || socket null) return; byte[] header new byte[HEADER_SIZE]; WriteInt(header, 0, body.Length); WriteInt(header, 4, msgId); byte[] packet new byte[HEADER_SIZE body.Length]; Buffer.BlockCopy(header, 0, packet, 0, HEADER_SIZE); Buffer.BlockCopy(body, 0, packet, HEADER_SIZE, body.Length); socket.BeginSend(packet, 0, packet.Length, SocketFlags.None, OnSend, null); }心跳是長連接必備。游戲服務(wù)端通常會把空閑超過一定秒數(shù)的連接踢掉比如120秒。客戶端如果在這期間沒有發(fā)任何數(shù)據(jù)就會被服務(wù)端斷掉表現(xiàn)就是“玩著玩著突然掉線”。所以客戶端需要一個心跳線程或攜程每隔30秒發(fā)一條心跳消息消息ID是10003包體空。private IEnumerator HeartBeatLoop() { while (true) { yield return new WaitForSeconds(30f); if (isConnected) { Send(10003, new byte[0]); } } }服務(wù)端收到心跳后刷新這個連接的最后活躍時間超時未活躍就主動關(guān)閉。兩端配合連接才能穩(wěn)定。4. Skynet側(cè)網(wǎng)關(guān)服務(wù)Lua代碼落地4.1 網(wǎng)關(guān)服務(wù)的基本結(jié)構(gòu)Skynet側(cè)我寫一個gate.lua用socket庫監(jiān)聽端口。Skynet的socket庫是異步的用callback注冊接收函數(shù)不會阻塞服務(wù)。網(wǎng)關(guān)啟動時綁定端口然后每個客戶端連接都會得到一個新的fd通過fd區(qū)分不同的客戶端。local skynet require skynet local socket require skynet.socket local client_fds {} -- 記錄所有連接的fd local function on_client_data(fd, msg) -- msg 是收到的原始數(shù)據(jù)可能包含不完整的消息 -- 需要和客戶端一樣做累積緩沖解析包頭 end local function on_client_connect(fd) log(client connected, fd) client_fds[fd] {} socket.start(fd) -- 重要不start不會觸發(fā)回調(diào) end local function on_client_disconnect(fd) log(client disconnected, fd) client_fds[fd] nil -- 通知邏輯層玩家下線 end skynet.start(function() socket.register(gate, function(fd, msg) if msg then on_client_data(fd, msg) else on_client_disconnect(fd) end end) local listen_fd socket.listen(0.0.0.0, 8888) socket.start(listen_fd, function(fd, addr) on_client_connect(fd) end) skynet.error(gate listen on 0.0.0.0:8888) end)這里有個Skynet新手最容易忽略的點(diǎn)socket.start(fd)一定要在連接建立后調(diào)用否則收不到數(shù)據(jù)回調(diào)。socket.register(gate, ...)注冊的是全局的回調(diào)函數(shù)所有fd的數(shù)據(jù)都會走到這個回調(diào)里所以拆包的邏輯必須在這個函數(shù)里做。4.2 Lua端的粘包拆包做法Skynet的socket庫不會幫你拆包收到的msg只是“某次網(wǎng)絡(luò)接收到的原始字節(jié)片段”。和C#端一樣Lua端也要維護(hù)每個fd的累積緩沖。我把緩沖存在client_fds[fd].cache字符串里每次收到新數(shù)據(jù)就做字符串拼接然后循環(huán)解析包頭。local HEADER_SIZE 8 local function read_int_from_cache(str, offset) -- 大端讀取4字節(jié) local b1 string.byte(str, offset 1) local b2 string.byte(str, offset 2) local b3 string.byte(str, offset 3) local b4 string.byte(str, offset 4) return (b1 24) | (b2 16) | (b3 8) | b4 end local function split_packages(fd, new_data) local cache client_fds[fd].cache .. new_data local packages {} while #cache HEADER_SIZE do local body_len read_int_from_cache(cache, 0) local msg_id read_int_from_cache(cache, 4) if #cache - HEADER_SIZE body_len then local body string.sub(cache, HEADER_SIZE 1, HEADER_SIZE body_len) table.insert(packages, { msg_id msg_id, body body }) cache string.sub(cache, HEADER_SIZE body_len 1) else break end end client_fds[fd].cache cache return packages end注意Lua的字符串索引從1開始string.sub的結(jié)束位置是包含的所以HEADER_SIZE body_len的寫法要對齊。這一步寫錯就是“服務(wù)端解析出來的消息體比實(shí)際長一個字節(jié)”或者“越界讀到了下一包的包頭”這種惡心bug。4.3 消息分發(fā)與業(yè)務(wù)邏輯對接拆出完整的{ msg_id x, body y }包后網(wǎng)關(guān)要按msg_id轉(zhuǎn)發(fā)給對應(yīng)的邏輯服務(wù)。我習(xí)慣維護(hù)一張路由表msg_id區(qū)間對應(yīng)不同的服務(wù)名。比如1~10000是登錄相關(guān)發(fā)到login_service10001~20000是房間相關(guān)發(fā)到room_service。Skynet的消息投遞用的是skynet.send(service_name, lua, ...)。local route_map { [10001] login_service, [10002] login_service, [20001] player_service, } local function dispatch_package(fd, pkg) local service_name route_map[pkg.msg_id] if not service_name then log(unknown msg_id, pkg.msg_id) return end -- 把客戶端的fd和消息體轉(zhuǎn)發(fā)給目標(biāo)服務(wù) skynet.send(service_name, lua, client_msg, fd, pkg.msg_id, pkg.body) end邏輯服務(wù)處理完需要把響應(yīng)送回網(wǎng)關(guān)再通過網(wǎng)關(guān)發(fā)回客戶端。這里我再加一個專門的處理邏輯服務(wù)調(diào)用網(wǎng)關(guān)暴露的接口send_to_client。因為fd和客戶端的對應(yīng)關(guān)系只有網(wǎng)關(guān)知道邏輯服務(wù)不能直接持有fd只能通過網(wǎng)關(guān)間接發(fā)送。-- 在網(wǎng)關(guān)中再注冊一個接口 skynet.dispatch(lua, function(_, _, cmd, fd, msg_id, body) if cmd send_to_client then -- 組裝包頭包體發(fā)送 local header string.pack(I4I4, #body, msg_id) socket.write(fd, header .. body) end end)這個鏈路設(shè)計初期可能覺得繞實(shí)際跑起來很清晰網(wǎng)關(guān)管連接生命周期邏輯服務(wù)管業(yè)務(wù)雙方只通過自定義消息對接互不干擾。5. 常見問題與排查技巧實(shí)錄5.1 亂碼和數(shù)據(jù)錯位多半是字節(jié)序或粘包我把實(shí)際項目中遇到的高頻問題整理成一張速查表基本覆蓋了Unity和Skynet聯(lián)調(diào)時80%的坑現(xiàn)象可能原因排查方式客戶端發(fā)過去的值變成大數(shù)字節(jié)序不一致打印包頭字段的十六進(jìn)制對比服務(wù)端解析到半個包就報錯粘包拆包邏輯缺失在網(wǎng)關(guān)打日志看緩存長度連接建立后立刻斷開服務(wù)端socket.start未調(diào)用檢查connect回調(diào)里是否有start客戶端收不到任何響應(yīng)網(wǎng)關(guān)沒有send_to_client接口檢查邏輯服務(wù)是否調(diào)用網(wǎng)關(guān)接口登錄成功后偶發(fā)掉線心跳超時檢查心跳間隔和服務(wù)端超時閾值收到消息順序錯亂多線程并發(fā)SendUnity端保證主線程調(diào)用Send或加鎖其中“字節(jié)序不一致”的癥狀最迷惑人。我遇到過一次客戶端發(fā)msg_id 1服務(wù)端解析出來是16777216排查了兩個小時最后發(fā)現(xiàn)是C#端用BinaryWriter默認(rèn)小端寫了包頭Lua端按大端讀。從那以后我在代碼注釋和文檔第一行都寫上“包頭字段一律大端”血淚教訓(xùn)。5.2 半包的調(diào)試技巧盯著第一個包的頭8字節(jié)調(diào)試粘包半包最有效的方式是“日志灌水法”。在網(wǎng)關(guān)的split_packages里打印每次接收到的原始字節(jié)長度以及拆包前后cache的長度變化。skynet.error(string.format(recv fd%d len%d cache_len%d, fd, #new_data, #client_fds[fd].cache))然后在客戶端那邊故意把一條大消息拆成多次Send比如循環(huán)10次每次發(fā)一小段看服務(wù)端日志是否在最后一次才拆出完整包。如果日志顯示cache長度一路增長最后成功拆包說明邏輯正確如果某一步cache長度變負(fù)說明你處理剩余數(shù)據(jù)時越界了。5.3 斷線重連移動端必須處理的常態(tài)Unity的Socket不會告訴你對端是否存活只有在你嘗試發(fā)送時才發(fā)現(xiàn)連接已斷。所以客戶端要有“心跳超時檢測”每30秒發(fā)一次心跳同時記錄lastSendTime在Update里檢查如果當(dāng)前時間 - lastSendTime 45秒認(rèn)為連接已經(jīng)死了主動Close并進(jìn)入重連流程。重連的策略我用的是“指數(shù)退避”第一次1秒后重連第二次2秒第三次4秒最多間隔15秒。這樣避免服務(wù)端抖動時客戶端瘋狂重連打爆網(wǎng)關(guān)。重連成功后要重新做一次登錄認(rèn)證拿新的會話憑證而不是簡單復(fù)用舊的連接。這是很多人忽略的細(xì)節(jié)導(dǎo)致重連后數(shù)據(jù)對不上。再補(bǔ)充一個Unity特有的坑Unity生命周期。OnApplicationPause切后臺的時候Socket可能被系統(tǒng)掛起回來之后要檢查連接狀態(tài)如果不健康就走重連流程。千萬別依賴Socket自己恢復(fù)它在移動端真的不可靠。6. 協(xié)議擴(kuò)展的小建議上面這套代碼跑通后你就有了一條完整的雙向通道。接下來要擴(kuò)展業(yè)務(wù)時建議直接引入更結(jié)構(gòu)化的序列化方案比如Sproto或者Protobuf。Sproto和Skynet同源在Lua側(cè)解析方便但C#側(cè)支持較弱Protobuf則兩邊都很成熟Unity有現(xiàn)成運(yùn)行時Lua側(cè)也能通過pb模塊解析。我自己的經(jīng)驗是如果項目很小純手寫二進(jìn)制夠了一旦消息字段超過20個建議立刻切Protobuf手寫解析會變成維護(hù)噩夢。切換時需要重新定義協(xié)議文件然后生成C#和Lua兩邊的代碼協(xié)議層改動不影響網(wǎng)絡(luò)層所以這套Socket封裝可以原封不動繼續(xù)用。最后再分享一個調(diào)試神器。Unity端我封裝了LogPacket方法把每次發(fā)送和接收的消息ID、包體長度、耗時打出來Skynet端在dispatch_package里也打同樣的日志。兩邊日志拼一起前后端的問題在上線之前基本都能提前暴露別等線上出了問題再抓瞎。連接管理、拆包、字節(jié)序、心跳、重連這五件事搞定Unity和Skynet的通信就踏實(shí)了。剩下的工作就是在協(xié)議表里填你的業(yè)務(wù)字段了。本文還有配套的精品資源點(diǎn)擊獲取