企业官网建设流程全解析

做skynet服务端有一段时间了，平时用得最多的是TCP那一套：gate做连接管理，agent处理单个连接逻辑。但最近项目要上“半实时”的帧同步和弱网扶持，TCP的队头阻塞实在忍不了，于是重新翻出KCP研究。翻来覆去发现，KCP本身不难，难的是把它“绑”到skynet里。这个“绑定”至少三层意思：KCP会话和UDP socket绑定、数据包和会话状态绑定、会话和skynet agent服务绑定。三层解耦不清楚，后面写出来的代码就是一团浆糊。这篇文章就把我在skynet里给KCP做绑定的完整过程、参数计算和踩坑记录一次性讲清楚。

1. 先搞清楚skynet的网络模型：KCP该“绑”在哪里

1.1 skynet的socket消息机制到底长什么样

skynet服务之间是靠消息驱动的，外部网络事件也一样。任何一个socket fd在skynet里都没有“主动回调”这种魔法，而是由框架把socket事件打包成消息，派发到注册了handler的服务里去。框架底层的epoll拿到可读事件后，把数据、地址、fd编号这些东西塞进一条网络消息，再投递给服务。

对TCP来说，事件消息不外乎accept、data、close三类。服务端通常是一个gate服务负责accept，然后把fd和对应agent的映射关系登记好，数据来了就转到agent去处理。这是skynet最常规的用法。

UDP就有点不一样了。UDP没有一个固定的“连接”，它天生就是发数据报的。所以skynet给UDP的socket消息通常是“这个fd收到了某地址发来的一坨数据”。如果你不把“地址”这个维度纳入管理，收到包之后根本不知道该给哪个业务逻辑处理。KCP恰恰需要做这件事：让UDP从一个无连接的数据报服务，变得像TCP一样有“会话”概念。

1.2 KCP在协议栈里的准确位置

很多人把KCP当成TCP替代品，这个理解我觉得不准确。KCP跑在UDP之上，它的作用是在不可靠的UDP上补出“可靠有序”的效果。TCP能做到的可靠、有序、重传、拥塞控制，KCP把前三个做了，拥塞控制基本不做，或者做得非常轻量。代价是它不管网络拥塞，只管把包尽快收齐。

所以正确的位置关系是：UDP负责传输，KCP负责可靠性，业务层负责协议解析。skynet在其中要承担的事情，包括UDP的收发、KCP实例的调度更新、以及把解出来的业务数据交给对应的服务。这里每一步都离不开“绑定”这个动作。

1.3 三种绑定拆开说

我在和同事讨论时发现，大家都被“绑定”这个词带偏了。skynet中接入KCP，至少要处理三个层面的绑定：

• socket层面的绑定：KCP实例要和某个UDP socket对应上。可以多个KCP实例共用一个UDP socket，靠地址和conv来区分。
• 会话层面的绑定：收到一个UDP包之后，要根据包的源地址和conv找到对应的KCP会话。找不到就新建，找到了就交给它去处理。
• 服务层面的绑定：每个KCP会话在业务上对应一个客户端，skynet里常说的agent就要和这个会话绑起来，消息才能正确路由。

这三个绑定是递进关系。socket绑定是底层的，会话绑定是核心的，服务绑定是业务侧的。后面所有代码和调试，最终都绕不开这三条线。

2. 核心细节：KCP会话与UDP端点的绑定原理

2.1 conv是什么，为什么它决定了会话归属

KCP协议头里有一个4字节的conv字段，相当于会话ID。两端创建KCP实例时必须用同一个conv，A把conv=12345的包发过来，B手上如果已经建了一个conv=12345的KCP实例，就能对上；对不上就当成陌生会话。

在UDP场景里，光靠conv还不够。同一个UDP socket会收到来自不同IP、不同端口的包，这些包可能都带着同一个conv。比如攻击者伪造，或者客户端切换网络导致源地址变了。所以实际绑定规则是“源地址+源端口+conv”三元组。我在底层做映射时，直接用这三元组做key，避免串会话。

2.2 KCP实例与socket的读写方向

一个KCP实例的正确工作方式是这样的：

• 应用层调用send把数据交给KCP，KCP把它切片成KCP包，放进发送队列。
• 然后通过output回调把KCP包交给传输层，也就是我们要绑定的那一个UDP socket。
• socket收到对端KCP包后，把整包数据交给KCP的input方法。
• input会解析、去重、排序、重传确认，然后应用层通过recv取出完整业务数据。

这里就看出什么是绑定了：output回调里必须要知道该往哪个socket发、发给哪个地址。如果KCP实例是和某一个固定的对端地址绑定的，那output里直接指定这个地址就行。如果不固定，就得靠外部传入的地址参数。我在skynet里一般把KCP对象和“对端地址”封装成一个会话对象，output回调里只发数据，地址从会话对象里取。

2.3 kcp绑定与udp connect的本质区别

另一个容易混的点是，UDP本身也有一个“connect”操作。调用udp connect之后，这个UDP socket只接收对端的数据，发送时也不需要再指定地址。这和KCP绑定看起来很像，但本质不同。

udp connect是内核层面限制源地址和目的地址，它节省的只是每次sendto时多传一个sockaddr的开销，协议本身依然是不可靠无连接的。KCP绑定则是应用层维护一套会话状态，把不可靠变成可靠。换句话说，udp connect管的是“谁能发给我”，KCP管的是“发过来的东西怎么整理成可靠的数据流”。

我在项目里实际是两者都要做的：UDP socket上做了connect或地址筛选，KCP层面再做会话绑定和重传。这两个动作互不替代。

3. 实操流程：把KCP一步步绑到skynet服务上

3.1 第一步：创建UDP socket并绑定本地端口

在skynet里创建一个UDP监听，通常就是调用socket模块的udp相关接口。skynet的selector会接管这个fd，并在可读时产生网络消息。

示意代码如下，重点体现绑定的第一步：

local skynet = require "skynet" local function start_kcp_listener(port) local fd = skynet.socket.udp("0.0.0.0", port) -- 把fd和当前服务绑定，后续这个fd的网络消息都会派发到本服务 skynet.socket.start(fd) skynet.socket.udp_bind(fd, "0.0.0.0", port) return fd end

第一次做的时候容易漏掉udp_bind，以为udp创建完就在监听了。实际不bind的话，内核不会把本地端口绑定上，对端数据发过来根本没人收。这一步就是最字面意义上的“绑定”。

3.2 第二步：收到UDP包时，按三元组找到或创建KCP会话

skynet里UDP数据到达后，服务会收到一条网络消息，里面带有fd、远端地址和原始数据。这一步要做的逻辑非常固定：

local sessions = {} local function find_or_create(fd, addr, pr, conv) local key = addr .. ":" .. conv local sess = sessions[key] if sess then return sess end -- 创建新KCP实例，conv从数据包解析而来 local kcp = kcp.create(conv, userdata) kcp:setoutput(function(kobj, buf, len) -- 绑定到socket：把KCP产生的协议包发向addr skynet.socket.udp_send(fd, addr, buf) return len end) local obj = { kcp = kcp, addr = addr, fd = fd } sessions[key] = obj return obj end

注意一点，创建KCP实例的时机，最好放在已经拿到对端第一个包之后。UDP没有连接过程，对端的第一包往往是KCP的握手/探测包，也可能就是应用数据。要确保先解析出包里的conv，再决定是复用老会话还是新建。

3.3 第三步：把KCP会话绑定到skynet agent服务

这一步是我的重点。如果只做socket和KCP的绑定，收发包OK了，但业务还是乱的。每个客户端连上来，不能所有数据都在一个服务里处理，必须有单独的agent。

常见的做法是：KCP会话建立成功之后，动态创建一个agent服务，并把会话对象作为初始化参数传进去。后续这个KCP会话收到的每条业务数据，都发给这个agent服务的邮箱。

这里我用了一个简单的分发器：

local skynet = require "skynet" local function dispatch_to_agent(fd, addr, msg, sess) local agent = sess.agent if not agent then -- 新连接，创建agent并绑定 agent = skynet.newservice("agent") skynet.call(agent, "lua", "bind", { fd = fd, addr = addr, conv = sess.conv }) sess.agent = agent end skynet.send(agent, "lua", "kcp_msg", msg) end

这一步如果不做，KCP底层就把数据收了、ACK也回了，但skynet这边没有业务服务处理，等于空转。我一开始图省事，把全部逻辑堆在网关服务里，结果单个网关服务的消息积压感人，后来才老老实实拆了agent。每个会话一个服务，既隔离了崩溃影响，也方便做按连接的热更新。

3.4 第四步：驱动KCP的update，让重传和超时转起来

KCP不是收发包就完事的。它的超时重传、快速重传、窗口滑动的推进，都依赖周期性调用kcp.update。最不靠谱的写法是只在收到包时update一次，这样发出去的包如果丢了，没有任何时机触发重传。

skynet里我习惯用一个固定频率的定时器驱动这个更新动作：

skynet.timeout(10, function() local now = skynet.now() for key, sess in pairs(sessions) do sess.kcp:update(now) end skynet.timeout(10, -- 每10ms跑一轮 ...) end)

10ms是KCP官方推荐的基础帧率。实际项目里可以根据延迟和CPU占用调到20ms，但不要超过50ms，否则重传不及时，弱网下会明显感到卡顿。

注意，所有操作都要回到同一个线程/服务里做，不要跨服务直接操作KCP对象。skynet不同服务是独立协程，一个KCP对象绑定在一个服务里处理是最安全的。跨服务共享KCP对象，很容易出现一个在更新、一个在收包的操作竞争。

4. 绑定前后的参数计算与调优

4.1 窗口大小怎么估算

KCP有两个窗口：发送窗口和接收窗口。发送窗口决定了能同时有多少个KCP包在空中飞，接收窗口决定了接收端愿意缓存多少个乱序包。

窗口太小，带宽一高就变成“等等等”，吞吐上不去。窗口太大，内存浪费在缓存队列上，弱网下还容易放大重传风暴。

估算的一个经验式是：

窗口值 = 预期的最大带宽 × 平均RTT / 单个KCP包大小

比如预期链路带宽10Mbps，平均RTT 100ms，KCP包大小按1200字节算：

10 * 1000 * 1000 / 8 / 1200 ≈ 1041

也就是窗口往1024这个量级取比较合理。我做帧同步项目时，预期带宽其实很低，只有几百Kbps，算出来窗口值很小，我就直接把发送窗口设成64，接收窗口设成128。不要盲目抄TCP的大窗口，KCP的窗口更多是内存换时间，需要针对自己业务的单包大小和RTT来算。

4.2 快速重传和nodelay的取舍

KCP的ikcp_nodelay接口有四个参数：nodelay、interval、resend、nc。

• nodelay为0是默认模式，保守重传。
• nodelay为1表示开启快速重传，缩短了ACK等待时间。
• interval是内部更新间隔，影响的是KCP内部状态机的粒度。
• resend是快速重传的跳数阈值，一般设2。
• nc表示是否关闭流控，关闭后KCP基本不再限制发送速度。

我的经验是：游戏帧同步场景直接nodelay=1、interval=10、resend=2、nc=1。这个组合延迟低，但也容易把网络打满，只适合小包高频场景。如果做文件同步、大包传输，还是保持默认或者nc=0，让KCP自己限制一下发送速率，不然很容易把中间路由搞出丢包率线性增长。

4.3 绑定参数里的MSS该给多少

KCP的MSS（最大分段大小）不等于MTU。默认MSS是1400字节，但这是从IP层掏出来的，没考虑UDP头。实际链路MTU如果是1500，IPv4头和UDP头加起来至少消耗28字节，所以KCP包载荷最多1472。如果走的是互联网公网，中间还可能被运营商叠加PPPoE头，我习惯直接把MSS设成1200到1280之间。

MSS设太大，超过链路MTU后会触发IP分片。IP分片在网络差的时候是灾难：一片丢了，整个数据报都得丢，KCP会误以为整包丢了，触发重传，浪费带宽还增加延迟。

4.4 交互频率与skynet定时器绑定

KCP需要定时update，skynet里用定时器驱动这个动作时，有个容易被忽略的细节：skynet的now()返回的是毫秒，和KCP内部要求的时钟单位要保持一致。如果KCP封装用的是c的clock或者gettimeofday，那就不要混用，统一用一种时钟源。混用时钟会导致RTO计算错乱，表现就是半天不重传，或者疯狂重传。

时钟源统一后，update间隔尽量和业务帧率绑定。我的项目是30帧的逻辑帧，于是我把KCP update间隔设为33ms并和帧推进对齐。这样重传时机的抖动不至于影响同帧的输入一致性。

5. 常见问题与排查技巧实录

5.1 绑定后一直建不起会话，收不到第一个业务包

表现：客户端发来第一个包，服务端没任何响应，KCP实例也没新建。

排查顺序先看UDP socket有没有真正bind。我遇到过一次，skynet.socket.udp创建了fd，但没有做bind，数据包到了内核层，发现目标端口没监听，直接回了ICMP不可达，KCP层当然什么都没有。

另一个隐蔽原因是第一个包被当成了“探测包”，服务端解析后只记录了IP和端口，没把conv解析出来就丢弃了。KCP的第一个包也可能携带着业务数据。一定要先把conv从包头解析出来再去建会话。如果直接按整包内容判断，可能误丢首包。

5.2 socket收到数据了，但KCP解不出完整业务包

这个多半是input和recv的节奏问题。KCP的input是把原始协议包喂进去，recv是从接收队列里取出一个完整的业务消息。如果你把数据包的每个字节原样喂入KCP，但应用层数据又自己做了粘包处理，就会导致recv拿到半截。

干净的做法是：上层如果做消息分包，就只做一次。要么完全依赖KCP的可靠流，自己维护流式分包；要么用KCP的不可靠+乱序通道，自己做应用层协议。两个层面都做粘连，就会出现“时而能解开，时而不完整”的灵异事件。我最终选择了可靠流+KCP包内自包含长度头，逻辑最清晰。

5.3 会话误绑定：客户端换网络后找不到老会话

移动端经常在WiFi和4G之间切换，切换后源IP和端口都变了。如果绑定key是“源地址+端口+conv”，旧地址对应的会话就永远收不到数据了，新地址又会新建一个会话，业务上等于掉线重连。

我的处理是两层：底层继续用三元组索引，但为每个业务会话分配一个稳定的token，放在KCP业务包头部。底层发现一个未知三元组时，先去全局会话表查token，如果有对应会话就做“重绑定”，更新这个会话的远端地址，并通知上层连接没有断，只是网络换了个出口。

5.4 agent绑定导致的服务风暴

每个新KCP会话都newservice一个agent，这个做法简单但怕DDos和连接抖动。客户端反复握手断开，agent服务就会反复创建销毁，服务数量瞬间暴涨。

加一个会话代理复用的机制：先创建少量的agent池，把多个KCP会话的消息通过会话ID路由到同一个agent。这样即使有大量短连接，也不会把节点打爆。我后来项目规模变大后，把agent池做到了可动态伸缩，才会按需扩容。

5.5 快速重传遇上路由器先入先出：重传风暴

这是我在弱网模拟环境里抓到的典型问题。KCP开启快速重传后，只要检测到一个包跳号，就立刻重传其后的所有包。弱网环境下，跳号是常态，结果就是越丢越多、重传导致链路更加拥塞。

解法是给确认和重传之间加一个微小的抑制窗口，比如在快速重传触发前，先等收到两个重复确认。虽然多等了几个毫秒，但避免了风暴式重传。KCP resend参数就是从1改成2的最直观效果。

还有一个技巧：把每个会话加一个发送速率的软上限。哪怕KCP自己没做拥塞控制，我在output回调里做令牌桶限制，保证单会话不会把UDP socket的发送队列打满。这样最差情况是延迟上升，但不会拖垮整个skynet节点的网络线程。

最后再分享一个经验

整个KCP接入skynet的过程，我最大的感受不是KCP本身复杂，而是“绑定”拆得清不清楚。socket绑定、会话绑定、agent绑定三层各管各的，问题就好查。当初我把三件事写在一个模块里，结果线上只要出现一个异常包，整个状态机都乱，根本排查不动。后来拆成udp_adapter、kcp_session、agent三个独立模块，问题定位速度和代码复用率完全不是一个量级。

如果你正准备在skynet项目里上KCP，不妨先拿一张纸把这三个绑定画出来，想清楚每一条消息从socket进来之后要经过哪几层、每层维护什么状态。这个设计工作花30分钟，后面至少能省你三天调试时间。