我最早接觸 KCP是在一版強(qiáng)調(diào)實(shí)時(shí)同步的戰(zhàn)斗服務(wù)里。skynet 本身對(duì) TCP 的支持非常成熟網(wǎng)關(guān)、轉(zhuǎn)發(fā)、agent 這些鏈路都能順暢跑起來(lái)但真到了玩家技能、位置高頻同步的時(shí)候TCP 的重傳隊(duì)列和擁塞窗口經(jīng)常把一次小抖動(dòng)放大成上百毫秒的延遲尖刺。后來(lái)我們把網(wǎng)絡(luò)層遷到 KCP 上情況好轉(zhuǎn)明顯。這里要特別說(shuō)明的是KCP 不是一個(gè)獨(dú)立服務(wù)它是一套基于 UDP 的可靠傳輸狀態(tài)機(jī)要真正在 skynet 里用起來(lái)需要把 KCP 的 C 實(shí)現(xiàn)和 skynet 的 socket 事件、定時(shí)器消息縫在一起。這篇文章不講 KCP 原理 PPT直接講怎么綁、綁的時(shí)候哪些坑最傷人。1. 為什么在 skynet 里折騰 KCP一次延遲敏感服務(wù)的選型復(fù)盤1.1 TCP 在幀同步場(chǎng)景下的“超時(shí)放大”問(wèn)題skynet 自帶的網(wǎng)絡(luò)鏈路大多數(shù)情況下是 TCP。TCP 的可靠性由內(nèi)核保證每個(gè)包都要確認(rèn)丟包了要重傳而且重傳時(shí)間走了指數(shù)退避。這在普通登錄、聊天場(chǎng)景里完全夠用但在幀同步或者狀態(tài)同步要求很高的戰(zhàn)斗里玩家操作是通過(guò)高頻小包上報(bào)的一旦某個(gè)包丟了TCP 會(huì)阻塞后續(xù)所有數(shù)據(jù)等重傳成功才開始繼續(xù)推進(jìn)。表現(xiàn)出來(lái)就是玩家端莫名其妙卡一下然后一瞬間收到一堆遲到的同步數(shù)據(jù)角色瞬移、技能時(shí)間軸錯(cuò)亂。這種“隊(duì)頭阻塞 重傳退避”的組合是 TCP 在設(shè)計(jì)上為公平性付出的代價(jià)。它優(yōu)先保證可靠性和網(wǎng)絡(luò)公平不優(yōu)先保證延遲。KCP 不是要推翻 TCP 的可靠性而是把可靠性的實(shí)現(xiàn)放到應(yīng)用層用更激進(jìn)的重傳策略、可選擇的無(wú)延遲模式和快速重傳機(jī)制讓“丟包到恢復(fù)”的時(shí)間從幾百毫秒壓到幾十毫秒。這也是我當(dāng)時(shí)決定在 skynet 里引入 KCP 的根本原因不是 TCP 不靠譜而是它不適合對(duì)延遲極度敏感的場(chǎng)景。1.2 KCP 解決的問(wèn)題與不解決的問(wèn)題KCP 解決的問(wèn)題很明確在不保證可靠傳輸?shù)?UDP 之上加上一套確認(rèn)、重傳、排序機(jī)制。它把 TCP 里由內(nèi)核管理的發(fā)送窗口、接收窗口、重傳隊(duì)列全部搬到用戶態(tài)交給開發(fā)者控制。你可以讓每個(gè)包更快被重傳可以關(guān)閉擁塞控制甚至在犧牲帶寬的前提下把延遲降到最低。對(duì)游戲來(lái)說(shuō)這通常意味著弱網(wǎng)下的操作反饋更快玩家不用系統(tǒng)性等待網(wǎng)絡(luò)恢復(fù)。但 KCP 不解決的問(wèn)題也要說(shuō)清楚。首先它不處理 NAT 穿透也不管路由質(zhì)量網(wǎng)絡(luò)物理丟包率太高時(shí)KCP 只是比 TCP 恢復(fù)得快不代表游戲不卡。其次KCP 假設(shè)調(diào)用方自己維護(hù)時(shí)間源它內(nèi)部所有的超時(shí)判斷都依賴外部傳入的當(dāng)前毫秒數(shù)如果上層定時(shí)器不準(zhǔn)KCP 的 RTO 計(jì)算也會(huì)跟著飄。第三KCP 不會(huì)自動(dòng)幫你做連接管理底層是 UDP沒(méi)有三次握手也沒(méi)有連接狀態(tài)超時(shí)斷線必須由業(yè)務(wù)層設(shè)計(jì)心跳。1.3 綁定方式選哪種C 服務(wù)內(nèi)置還是 Lua 模塊封裝在 skynet 里綁定 KCP業(yè)內(nèi)通常走兩條路。第一條是把 KCP 邏輯寫進(jìn)一個(gè) C 服務(wù)這個(gè)服務(wù)持有 UDP socket 和一組 KCP 會(huì)話對(duì)象收包、解包、調(diào)用 ikcp_input全部在 C 層完成再把最終業(yè)務(wù)消息發(fā)給對(duì)應(yīng)的 agent 服務(wù)和房間服務(wù)。優(yōu)點(diǎn)是性能好、拷貝少適合純 C 實(shí)現(xiàn)的戰(zhàn)斗邏輯或高頻網(wǎng)關(guān)。缺點(diǎn)是開發(fā)調(diào)試成本高尤其是包頭協(xié)議變更時(shí)每次都要編譯。第二條路是在 Lua 層封裝。skynet 的 socket API 本身是消息驅(qū)動(dòng)通過(guò) socket.udp 綁定端口收到 UDP 數(shù)據(jù)后進(jìn) Lua 回調(diào)再調(diào)用一個(gè)封裝好的 KCP Lua 模塊。開發(fā)速度快配合 skynet.console 可以隨時(shí)看會(huì)話狀態(tài)甚至能在不重啟服務(wù)的情況下調(diào)整某一路連接的參數(shù)。代價(jià)是每次消息都有一層額外的 Lua/C 邊界拷貝對(duì)很極端的同屏戰(zhàn)斗來(lái)說(shuō)可能吃緊。我的建議是先做 Lua 封裝跑通業(yè)務(wù)再根據(jù)壓測(cè)結(jié)果決定是否把這層下沉到 C。綁定 KCP 最大的難點(diǎn)從來(lái)不是性能而是你還沒(méi)搞清楚 KCP 狀態(tài)機(jī)時(shí)就把復(fù)雜度引入了 C 代碼。2. 綁定前的狀態(tài)機(jī)功課conv、窗口、nodelay 這些參數(shù)到底怎么配2.1 會(huì)話標(biāo)識(shí)一個(gè) UDP 端口如何映射多個(gè) KCP 連接KCP 的每個(gè)會(huì)話對(duì)象都由一個(gè) conv 值區(qū)分。conv 本質(zhì)上是會(huì)話 ID客戶端和服務(wù)端必須約定相同的 convKCP 協(xié)議頭里第一個(gè) 4 字節(jié)就是這個(gè)字段。由于 UDP 本身是無(wú)連接的skynet 里一個(gè) UDP fd 上可能同時(shí)跑幾十上百個(gè)客戶端所以服務(wù)端必須維護(hù)一張從 conv 到 KCP 會(huì)話的映射表。這里有個(gè)細(xì)節(jié)容易踩坑KCP 包的頭里帶 conv但它不區(qū)分“這個(gè)包是新連接還是舊連接”。服務(wù)端收到一個(gè)從未見過(guò)的 conv不能立刻拒絕應(yīng)當(dāng)把它當(dāng)成新會(huì)話建立請(qǐng)求。業(yè)務(wù)層要再定義一層握手消息來(lái)確認(rèn)身份比如客戶端首包帶一個(gè) session id服務(wù)端校驗(yàn)通過(guò)后才允許后續(xù)數(shù)據(jù)進(jìn)入游戲邏輯。KCP 只保證傳輸通道可靠不保證玩家身份合法。2.2 收發(fā)窗口與 MTU調(diào)整前先理解隊(duì)列模型KCP 內(nèi)部維護(hù)發(fā)送窗口和接收窗口。發(fā)送窗口決定在未收到確認(rèn)前最多有多少個(gè)分段可以被丟到網(wǎng)絡(luò)上接收窗口決定對(duì)方即使提前發(fā)來(lái)更多數(shù)據(jù)KCP 一次最多緩存多少分段。窗口太大會(huì)導(dǎo)致內(nèi)存占用升高窗口太小則吞吐上不去尤其是在高丟包環(huán)境下窗口小很容易把鏈路打滿。MTU 則影響分段策略。KCP 默認(rèn)按 1400 字節(jié)左右去切分用戶數(shù)據(jù)超過(guò) MTU 的大包會(huì)被拆成多個(gè)分段每個(gè)分段按序號(hào)重傳和重組。在 skynet 里綁定時(shí)我建議 MTU 先保持默認(rèn)不要在前期調(diào)它。真正需要調(diào)整的是業(yè)務(wù)消息大小一次 ikcp_send 最好不要超過(guò) 1200 字節(jié)這樣大部分戰(zhàn)斗同步消息都不觸發(fā)分段省掉不少重組開銷。如果你堅(jiān)持要傳大包也要接受它被打散后任意一個(gè)分段丟失都會(huì)讓整個(gè)業(yè)務(wù)包無(wú)法交付。窗口參數(shù)我一般給一個(gè)相對(duì)穩(wěn)的經(jīng)驗(yàn)組合發(fā)送窗口 64接收窗口 64。如果同屏同步對(duì)象多、單幀數(shù)據(jù)量超過(guò) 4KB再適當(dāng)調(diào)大。注意窗口是按“分段”計(jì)算的不是按“邏輯包”計(jì)算一個(gè) 4000 字節(jié)的業(yè)務(wù)包切成 3 個(gè)分段就占 3 個(gè)窗口槽位。2.3 nodelay 組合游戲常用參數(shù)的含義與代價(jià)KCP 的 nodelay 參數(shù)有四個(gè)經(jīng)常有人只調(diào)第一個(gè)后面三個(gè)不動(dòng)結(jié)果延遲改善不明顯。完整的參數(shù)組合是nodelay、interval、resend、nc。nodelay 設(shè)為 1 表示關(guān)閉延遲等待盡量發(fā)出去interval 是內(nèi)部狀態(tài)機(jī)更新的最小時(shí)間間隔單位毫秒resend 控制快速重傳的觸發(fā)閾值nc 表示是否關(guān)閉擁塞控制設(shè)為 1 表示關(guān)閉。我的常用組合是 nodelay1interval10resend2nc1。這個(gè)組合的含義是每 10 毫秒驅(qū)動(dòng)一次 KCP 更新開啟快速重傳關(guān)閉擁塞控制。它適合局域網(wǎng)或者可控弱網(wǎng)環(huán)境能明顯降低延遲但代價(jià)是網(wǎng)絡(luò)擁塞時(shí)不會(huì)主動(dòng)退讓可能把丟包率進(jìn)一步拉高。所以這個(gè)參數(shù)不是所有場(chǎng)景都適用如果是公網(wǎng)大型多人在線穩(wěn)妥做法是先 nc0 跑一段時(shí)間用監(jiān)控?cái)?shù)據(jù)說(shuō)話。你可以在 skynet 的 Lua 服務(wù)里封裝一個(gè)接口暴露這四個(gè)參數(shù)方便后續(xù)熱調(diào)。我就吃過(guò)參數(shù)寫死的虧開發(fā)環(huán)境跑得好好的一上弱網(wǎng)測(cè)試傻眼了重傳風(fēng)暴把服務(wù)器出口帶寬吃滿最后定位出來(lái)就是 nc1 加 resend2 在丟包率超過(guò) 15% 時(shí)過(guò)于激進(jìn)。3. 在 skynet 里接住 KCP完整數(shù)據(jù)鏈路拆解3.1 收包鏈路UDP 數(shù)據(jù)到達(dá)后如何交給 ikcp_input不管走 C 服務(wù)還是 Lua 封裝收包鏈路的順序是固定的。skynet 的 socket 層收到 UDP 包后回調(diào)或者消息里帶著一段字節(jié)流第一個(gè)動(dòng)作是解析出 KCP 頭里的 conv然后拿 conv 去會(huì)話表里查 KCP 對(duì)象。找不到就創(chuàng)建找到了就把去掉頭部的原始 KCP 報(bào)文交給 ikcp_input。ikcp_input 這一步非常關(guān)鍵它不能只被調(diào)用一次就完事因?yàn)樗鼉?nèi)部會(huì)根據(jù)序列號(hào)判斷哪些數(shù)據(jù)是新數(shù)據(jù)、哪些是重復(fù)包同時(shí)更新確認(rèn)信息和接收緩沖區(qū)。調(diào)用完 ikcp_input 之后還要反復(fù)調(diào)用 ikcp_peeksize 和 ikcp_recv 把完整業(yè)務(wù)包取出來(lái)因?yàn)橐粋€(gè) UDP 包可能只包含業(yè)務(wù)包的一個(gè)分段也可能一個(gè)業(yè)務(wù)包被拆成多個(gè)分段分批到達(dá)。-- 偽代碼展示收包主流程 function kcp_network:udp_recv(packet, addr) local conv bytes_to_uint32(packet, 1) local kcp self.sessions[conv] if not kcp then kcp self:new_session(conv, addr) end -- 去掉外層 conv 頭之后剩下的就是 KCP 協(xié)議報(bào)文 kcp:input(packet:sub(5)) while true do local peek kcp:peeksize() if peek 0 then break end local msg kcp:recv() skynet.send(self.agent[conv], lua, msg) end end這段偽代碼是最核心的框架。真正實(shí)現(xiàn)時(shí)new_session 里面不要急著 skynet.send先給 agent 服務(wù)發(fā)一個(gè)會(huì)話建立消息由 agent 決定要不要接納這個(gè)連接。業(yè)務(wù)層需要把會(huì)話映射和玩家綁定分開管理。3.2 發(fā)包鏈路ikcp_output 回調(diào)與真正 socket 發(fā)送KCP 是一套獨(dú)立的狀態(tài)機(jī)它并不直接操作 UDP socket。當(dāng) KCP 內(nèi)部產(chǎn)生需要發(fā)出去的報(bào)文時(shí)會(huì)通過(guò)一個(gè) output 回調(diào)把這些報(bào)文交給你。你必須自己實(shí)現(xiàn)這個(gè)回調(diào)否則數(shù)據(jù)只會(huì)堆積在 KCP 的發(fā)送緩沖里永遠(yuǎn)不會(huì)真正到達(dá)網(wǎng)絡(luò)。所以每次調(diào)用 ikcp_update 之后KCP 會(huì)把待發(fā)送的數(shù)據(jù)整理好在 update 內(nèi)部通過(guò) output 回調(diào)一批一批吐出來(lái)?；卣{(diào)里拿到的是一段完整 UDP 負(fù)載需要你自己補(bǔ)上 conv 頭然后通過(guò) skynet 的 socket 發(fā)送接口 sendto 到客戶端地址。注意這里發(fā)送的不一定是用戶調(diào)用 ikcp_send 的原始數(shù)據(jù)而是 KCP 分段后的報(bào)文可能一個(gè)用戶包被拆成好幾個(gè) UDP 小包。// 偽代碼展示 output 回調(diào)的實(shí)現(xiàn)思路 static int udp_output(const char *buf, int len, ikcpcb *kcp, void *user) { struct session *s (struct session *)user; // KCP 回調(diào)的數(shù)據(jù)需要加上 conv 頭再發(fā)給遠(yuǎn)端 uint32 conv ikcp_getconv(kcp); char head[4] {conv 24, conv 16, conv 0xff, 0}; // 調(diào)用 skynet socket sendto }這個(gè)回調(diào)的線程模型很容易埋雷。如果 KCP 對(duì)象在主服務(wù)線程更新output 回調(diào)也發(fā)生在主服務(wù)線程那么里面直接調(diào) socket 發(fā)送是安全的。如果底層 UDP fd 被別的線程監(jiān)控就要謹(jǐn)慎處理跨線程 sendto 的問(wèn)題。最省心的方式是讓所有 KCP 相關(guān)的操作全部收斂到同一個(gè)服務(wù)線程里。3.3 定時(shí)驅(qū)動(dòng)用 skynet 超時(shí)消息喚醒 ikcp_updateKCP 不會(huì)自己蘇醒它必須被周期性調(diào)用 ikcp_update并在恰當(dāng)?shù)臅r(shí)機(jī)調(diào)用 ikcp_flush。skynet 里最常見的做法是給持有 KCP 會(huì)話的服務(wù)掛一個(gè)循環(huán)定時(shí)器每隔一小段時(shí)間遍歷所有會(huì)話調(diào)用一次 update。但更精確的做法是使用 ikcp_check。ikcp_check 會(huì)返回一個(gè)毫秒時(shí)間點(diǎn)告訴你在當(dāng)前時(shí)間之后下一次必須調(diào)用 update 的時(shí)機(jī)。你把這個(gè)時(shí)間點(diǎn)換算成相對(duì)延時(shí)然后通過(guò) skynet.timeout 注冊(cè)下一次定時(shí)器。這樣 KCP 在空閑時(shí)可以盡量少喚醒在網(wǎng)絡(luò)繁忙時(shí)又能保證調(diào)度足夠密集。-- 偽代碼展示使用 check 的定時(shí)循環(huán) function kcp_network:tick() local now now_ms() local next_time 0x7fffffff for conv, kcp in pairs(self.sessions) do kcp:update(now) local check_at kcp:check(now) if check_at next_time then next_time check_at end end self:set_timeout(next_time - now_ms()) endskynet 的定時(shí)器精度受服務(wù)消息隊(duì)列繁忙程度影響如果你的戰(zhàn)斗邏輯服務(wù)在同一條線程里處理大量消息定時(shí)器觸發(fā)可能晚于預(yù)期。這時(shí)候 KCP 的 RTO 就會(huì)偏慢因?yàn)橐磺袝r(shí)間判斷都基于你傳入的 now_ms 和實(shí)際觸發(fā)時(shí)刻。所以綁定 KCP 的服務(wù)盡量不要和重 CPU 邏輯擠在同一個(gè)服務(wù)里。3.4 斷線檢測(cè)KCP 不負(fù)責(zé)告訴你連接斷了很多第一次用 KCP 的人會(huì)問(wèn)對(duì)方斷線了KCP 能檢測(cè)到嗎答案是能感知一部分但不能完全依賴。KCP 知道哪些包一直沒(méi)被確認(rèn)也知道對(duì)方最后的確認(rèn)序號(hào)停留在哪但 UDP 沒(méi)有連接狀態(tài)KCP 無(wú)法區(qū)分“對(duì)方網(wǎng)絡(luò)差”和“對(duì)方已經(jīng)下線”。所以綁定到 skynet 后業(yè)務(wù)層必須自己設(shè)計(jì)心跳。常見方案是應(yīng)用層心跳包每隔幾秒通過(guò) KCP 發(fā)送一個(gè) ping 消息服務(wù)器維護(hù)最后活躍時(shí)間超過(guò)心跳間隔的若干倍就判定超時(shí)回收會(huì)話對(duì)象。不要把這個(gè)邏輯和 KCP 的 nodelay 參數(shù)混在一起應(yīng)用層心跳是業(yè)務(wù)規(guī)則KCP 重傳是傳輸規(guī)則兩者缺一不可。我當(dāng)時(shí)的教訓(xùn)是最初把超時(shí)判定寄托在 KCP 的發(fā)送隊(duì)列上以為發(fā)了很多包沒(méi)確認(rèn)就說(shuō)明對(duì)方斷了結(jié)果玩家只是切換 Wi-Fi網(wǎng)絡(luò)短暫中斷后本可以恢復(fù)卻被服務(wù)器提前踢下線體驗(yàn)非常差。后來(lái)改成應(yīng)用層心跳加 10 秒超時(shí)閾值誤踢率降為 0。4. 綁定期的三個(gè)大坑外層包格式、分幀習(xí)慣、并發(fā)邊界4.1 在外層還是復(fù)用 KCP 自帶的 conv 頭KCP 協(xié)議頭本身自帶 conv 字段理論上不需要再包一層。但在 skynet 里綁定我強(qiáng)烈建議留一個(gè)極小的外層頭哪怕只是 4 字節(jié) conv 復(fù)制一份。原因很實(shí)際skynet 的消息系統(tǒng)里UDP 數(shù)據(jù)到達(dá)服務(wù)端時(shí)你拿到的是整段數(shù)據(jù)不可能每次都去解析 KCP 的內(nèi)部偏移而且未來(lái)你可能需要升級(jí) KCP 版本或者加加密、加客戶端版本號(hào)外層頭給你的擴(kuò)展空間遠(yuǎn)比直接用 KCP 頭大。外層頭設(shè)計(jì)成 [1 字節(jié)版本][4 字節(jié) conv][2 字節(jié)長(zhǎng)度][payload] 就夠了。版本號(hào)留給協(xié)議演進(jìn)conv 用于會(huì)話映射長(zhǎng)度字段幫你判斷 UDP 粘包因?yàn)闊o(wú)連接不代表不會(huì)一次收多個(gè)應(yīng)用包。KCP 本身會(huì)把大包分片重組但業(yè)務(wù)邏輯要一次性讀完整條消息長(zhǎng)度字段能省掉很多邊界判斷。4.2 KCP 已經(jīng)解決了半包但業(yè)務(wù)分幀仍要自己做這句話聽起來(lái)矛盾其實(shí)不矛盾。KCP 是消息協(xié)議一次 ikcp_send 對(duì)應(yīng)一次 ikcp_recv它已經(jīng)幫你解決了 TCP 那種字節(jié)流半包問(wèn)題。真正容易出問(wèn)題的是發(fā)送側(cè)如果業(yè)務(wù)層把兩條邏輯消息拼在一個(gè) buffer 里發(fā)送接收方拿到后就必須自己拆開。很多團(tuán)隊(duì)剛開始接 KCP 時(shí)覺(jué)得隨便后面加協(xié)議字段就痛苦了。正確的姿勢(shì)是每個(gè)業(yè)務(wù)邏輯消息單獨(dú)調(diào)用一次 ikcp_send發(fā)送前在業(yè)務(wù) payload 最前面加一個(gè) 2 字節(jié)的消息類型字段。這樣接收方 ikcp_recv 拿到的就是一個(gè)帶類型的完整業(yè)務(wù)包直接按類型分發(fā)不需要再維護(hù)拼包狀態(tài)機(jī)。KCP 做的是傳輸層可靠業(yè)務(wù)層協(xié)議仍然要按消息幀設(shè)計(jì)。4.3 并發(fā)邊界讓所有 KCP 操作收斂到同一條服務(wù)線程skynet 服務(wù)默認(rèn)是“單消息隊(duì)列 串行回調(diào)”看似不會(huì)并發(fā)但底層 socket 事件來(lái)源、定時(shí)器來(lái)源可能不在同一條線程。如果你在 C 服務(wù)里直接寫很容易出現(xiàn)兩個(gè)線程同時(shí)訪問(wèn)同一個(gè) KCP 對(duì)象的情況輕則數(shù)據(jù)錯(cuò)亂重則觸發(fā)段錯(cuò)誤。我推薦的做法是KCP 會(huì)話對(duì)象不對(duì)外暴露任何人想操作連接都通過(guò) skynet 消息投遞到持有該連接的 service。UDP 收包線程收到數(shù)據(jù)后只負(fù)責(zé)把原始字節(jié)放入消息隊(duì)列不直接調(diào) ikcp_input定時(shí)器線程只負(fù)責(zé)發(fā)一條 tick 消息不直接調(diào) ikcp_update。這樣所有 KCP 相關(guān)操作都在服務(wù)線程的 invoke 流程里串行完成天然免鎖。4.4 綁定期常見問(wèn)題排查清單現(xiàn)象可能原因驗(yàn)證方法收到 UDP 包但業(yè)務(wù)消息始終不出現(xiàn)output 回調(diào)沒(méi)實(shí)現(xiàn)或 send 后沒(méi)調(diào) update在 output 回調(diào)里打日志看是否有產(chǎn)出丟包后恢復(fù)明顯偏慢interval 太大、nodelay0短間隔下用日志記錄 RTT 分布內(nèi)存持續(xù)上漲發(fā)送后沒(méi)及時(shí) update隊(duì)列堆積監(jiān)控每個(gè)會(huì)話的 snd_queue 長(zhǎng)度一段時(shí)間后對(duì)方全斷線應(yīng)用層心跳機(jī)制缺失抓 UDP 包看是否有周期性數(shù)據(jù)這張表是我踩坑之后的濃縮。它不能解決所有問(wèn)題但能幫你快速定位 70% 的綁定期 bug。5. 參數(shù)調(diào)優(yōu)與落地測(cè)試我踩過(guò)之后的實(shí)操建議5.1 先跑通默認(rèn)參數(shù)再上弱網(wǎng)壓測(cè)綁定 KCP 最大的敵人是“自以為理解了參數(shù)”。一開始我也直接套了 nodelay1、interval10、resend2、nc1結(jié)果在丟包模擬環(huán)境里重傳風(fēng)暴把帶寬吃光了。后來(lái)我改成先跑默認(rèn)參數(shù)確認(rèn)整個(gè)鏈路通數(shù)據(jù)可靠再逐步調(diào)整。弱網(wǎng)工具我推薦直接在內(nèi)網(wǎng)機(jī)器上做延遲和丟包模擬把丟包率設(shè)定為 3%、5%、10%、15% 四檔。每檔跑至少五分鐘記錄業(yè)務(wù)層的有效傳輸成功率。不要只看 KCP 是否最終把包送到了游戲體驗(yàn)更關(guān)心的是“多少包在 50 毫秒內(nèi)到達(dá)”這個(gè)指標(biāo)才能反映弱網(wǎng)手感。5.2 推薦的監(jiān)控維度與驗(yàn)收指標(biāo)KCP 綁進(jìn) skynet 后至少要有四個(gè)監(jiān)控維度日志里能看到每個(gè)會(huì)話的重傳次數(shù)、每個(gè)會(huì)話的發(fā)送隊(duì)列長(zhǎng)度、一次業(yè)務(wù)消息從 send 到 recv 的耗時(shí)分布、以及應(yīng)用層心跳超時(shí)次數(shù)。驗(yàn)收指標(biāo)我建議定兩條線?；A(chǔ)線丟包率 5% 時(shí)90% 的業(yè)務(wù)消息延遲在 100 毫秒內(nèi)進(jìn)階層丟包率 15% 時(shí)連接存活率不低于 95%且不出現(xiàn)重傳風(fēng)暴導(dǎo)致出口帶寬打滿。如果你的服務(wù)滿足這兩條說(shuō)明綁定方案基本合格可以繼續(xù)做業(yè)務(wù)側(cè)優(yōu)化。5.3 一個(gè)值得做的改造把 KCP 封裝成獨(dú)立網(wǎng)絡(luò)服務(wù)等你把單機(jī)綁定跑通之后我建議再花點(diǎn)時(shí)間把 KCP 網(wǎng)絡(luò)層獨(dú)立成一個(gè) skynet 服務(wù)不把它和具體業(yè)務(wù)混在一起。這個(gè)網(wǎng)絡(luò)服務(wù)只負(fù)責(zé)管理 UDP socket、KCP 會(huì)話、心跳超時(shí)、消息收發(fā)向上提供一個(gè)統(tǒng)一的接口建立會(huì)話、發(fā)送消息、廣播消息、關(guān)閉會(huì)話。業(yè)務(wù)邏輯全掛在 agent 服務(wù)上。這樣做的收益很大。首先戰(zhàn)斗服需要熱更新時(shí)可以只更新業(yè)務(wù)服務(wù)不碰網(wǎng)絡(luò)層。其次壓測(cè)時(shí)可復(fù)制出多個(gè)網(wǎng)絡(luò)服務(wù)實(shí)例分別綁定不同端口觀察會(huì)話數(shù)和消息吞吐是否線性擴(kuò)展。最后后續(xù)如果要換加密算法或者改 MTU只需要改網(wǎng)絡(luò)服務(wù)內(nèi)部實(shí)現(xiàn)上層業(yè)務(wù)幾乎無(wú)感知。我在最后把綁定跑上線時(shí)最感慨的是綁定工作本身不難難的是意識(shí)到 skynet 的消息模型怎么和 KCP 的狀態(tài)機(jī)配合。所有跨線程的焦慮最后都?xì)w結(jié)為“讓每件事都在它該在的隊(duì)列里發(fā)生”。如果你也正在做類似的事先按文中的偽代碼跑通一次再開始?jí)簻y(cè)先解決“數(shù)據(jù)能流動(dòng)”再談參數(shù)優(yōu)化這樣會(huì)順很多。