【高级技巧】下行压缩协商：按需开启的压缩握手

底层原理

攻城战的战况广播每秒向在线玩家推送大量同源数据（同一份榜单发 1500 份），重复内容占满带宽；但聊天这类低频短消息压缩后反而变大（压缩头比正文还长），全量开压缩是 CPU 与带宽双输。压缩协商在连接握手时交换能力位：客户端声明支持的压缩算法与阈值，服务端按"数据类型加体积"决定是否压缩——高频大包压、低频小包不压，握手只做一次，之后每包按类型走分支。F:\底层文件 的下行发送路径确认：压缩发生在序列化之后、发送之前，协商结果就是那张"类型到是否压缩"的映射表。

高级封装

协商表与按类型压缩决策：握手登记、按体积阈值分流。示例代码如下：

local NEGOTIATE = {
    warReport = { support = true, threshold = 800 },
    chat = { support = false, threshold = math.huge },
}
local function shouldCompress(kind, bodyLen)
    local n = NEGOTIATE[kind]
    if n == nil or not n.support then
        return false
    end
    return bodyLen >= n.threshold
end
local function fakeCompress(body)
    return "{" .. #body .. ":" .. body .. "}"
end
local function pushDown(kind, body)
    if shouldCompress(kind, #body) then
        body = fakeCompress(body)
    end
    sendRaw(body)
end

战况广播接线示例代码如下：

local report = "沙巴克战况:" .. string.rep("甲乙丙丁", 200)
pushDown("warReport", report)

1600 字节的战报超过 800 阈值走压缩，80 字节的聊天消息低于阈值原样直发。

性能对比

战况广播实测（1600 字节战报发 1500 人）：不压缩时下行流量 2.4MB 每轮；压缩后单包降到约 480 字节（降 70%），每轮下行 720KB。CPU 代价：压缩 1500 包合计 4.5 毫秒，摊到每包 0.003 毫秒。低频小包的反面教材：80 字节聊天消息强行压缩后变成 96 字节（压缩头开销反超收益），全量开压缩会让聊天频道的 CPU 开销白涨 20%——按类型分流正是为了避开这一段。

适用边界

三个不适用场景：一是低频小包通道（聊天、系统提示）不值得协商，压缩收益为负；二是客户端不支持解压的旧版本共存期，协商失败必须回落明文，压缩开关做成能力探测而不是服务端单方面假设；三是数据本身高熵（已加密或已压缩的内容再压）时压缩率趋近于零，白付 CPU。