为什么 skynet 提供的包协议只用 2 个字节表示包长度
这篇讲的是 skynet 框架中一个经典设计决策：为什么它的 netpack 库坚持使用 2 字节（最大 64KB）来表示 TCP 数据包长度，而不是更“灵活”的 4 字节。 作者从游戏客户端网络通信的实际场景出发，解释了这并非简单的技术限制，而是一种有意的引导。核心原因在于，在单个 TCP 连接中允许过大的数据包（比如 100KB）是一个糟糕的设计。这会在弱网环境下长时间阻塞整个通信信道，连带心跳包等需要及时响应的小数据包也被延迟，严重影响实时性。更进一步，4 字节的长度头还存在被恶意攻击耗尽服务器内存的安全风险。 因此，作者主张正确的做法不是放宽包长度限制，而是在“长度+内容”协议之上增加一层，将大数据块分片传输。这个设计看似“绕”，但它强制开发者去思考和解决数据传输的阻塞问题，最终能实现单个 TCP 连接承载多个逻辑信道的能力，比如区分高优先级的心跳/关键指令和低优先级的聊天信息或大文件分片。 所以，skynet 这个看似限制性的选择，其实是在用简洁的接口引导使用者构建更健壮、响应更及时的网络架构。