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