reliable核心概念指南端点、序列号与ACK机制彻底讲透【免费下载链接】reliablePacket acknowledgement system for UDP项目地址: https://gitcode.com/gh_mirrors/re/reliablereliable是一个面向 UDP 的轻量级数据包确认ACK系统用不到 3000 行 C 代码帮你回答一个核心问题我发出去的 UDP 包对端到底收到没有围绕这个目标它构建了三个核心概念——端点Endpoint、16 位序列号Sequence和捎带式 ACK 确认机制再附加分片重组与 RTT、抖动、丢包率统计。本文带你彻底讲透这三件事读完即可看懂 reliable.c 的主干逻辑。一、reliable 是什么给 UDP 补上收到没的确认层UDP 快速但不可靠包可能丢失、乱序、重复。TCP 虽然可靠却带着重传、拥塞控制等全家桶对实时游戏、音视频等低延迟场景偏重。reliable 走的是第三条路它不是消息层而是确认系统。能力说明✅ 收包确认收到对端包后立即确认ack告诉你哪些包已送达✅ 分片重组超过阈值的大包自动切分发送对端自动拼回✅ 网络统计自动估算 RTT、抖动、丢包率、带宽✅ 去重窗口内的重复包被识别并丢弃❌ 不重传哪些包丢了由你决定怎么补发——这是刻意的设计正如 STANDARD.md 所写It doesnotretransmit. It tells you which packets arrived; what you do about the ones that did not is your business. 这种只确认、不重传的取舍让 reliable 保持极小、极快适合叠加在游戏协议等自有逻辑之上。二、端点Endpoint一条连接一个端点端点是 reliable 里一切状态的家。每条连接各持一个reliable_endpoint_t客户端/服务器场景每个客户端一个端点服务器为每个客户端槽位各建一个端点端点内部维护三本账已发包记录sent_packets、已收包记录received_packets、分片重组缓冲fragment_reassembly端点还保存 ACK 缓冲、RTT 历史、网络计数器等端点不是线程安全的一个线程一个端点或自行加锁。1️⃣ 创建端点的三步曲调reliable_default_config()拿到一份面向 60Hz 实时通信的默认配置按业务调整关键参数见下表调reliable_endpoint_create(config, time)创建记得结束时reliable_endpoint_destroy()释放配置项含义max_packet_size可收发的最大包大小fragment_above超过该字节数即分片发送fragment_size/max_fragments每片大小 / 每包最多片数上限 256ack_buffer_size两次清理之间最多暂存多少个 ACKtransmit_packet_function发包回调由你套上 UDP socket 发出process_packet_function收包回调返回 1 表示接受并确认该包返回 0 拒绝这种库不碰 socket的设计让 reliable 可以搭任何网络库使用作者的姊妹项目 netcode 就是配套的网络层。完整可运行示例见 example.c。三、序列号Sequence16 位、会回绕、必须按环形比较每个发出去的包都会被端点自动分配一个16 位序列号从 0 一路加到 65535 后回到 0回绕。为什么能只比较 32768 以内reliable 用有符号距离判断新旧见 reliable.c 中reliable_sequence_greater_than两个序列号相减后距离不超过 32768 才算更新。这就像时钟——凌晨 0:59 比 23:59 晚。这套规则带来三个直接后果回绕安全发送速率按 60Hz 设计65536 个包约 18 分钟才转一圈完全来得及陈旧包stale被拒序列号落在接收窗口之前的包直接丢弃重复包被拒窗口内已收过的序列号再次出现按NUM_PACKETS_DUPLICATE计数并丢弃发送前预知序列号reliable_endpoint_next_packet_sequence(endpoint)会告诉你下一个包将要拿到的序列号。这是做重传的关键记录消息 X 装进了序列号 4021 的包 → 收到 4021 的 ACK → 消息 X 已被确认。四、ACK 机制每个包都捎带一份确认回执这是 reliable 最精妙的部分没有独立的 ACK 包确认信息直接搭便车在数据包头上。1️⃣ 包头里有什么每个包的头部携带三个值格式细节见 STANDARD.md字段作用sequence本包的序列号ack对端最近收到的序列号累计确认ack_bits32 位掩码ack之前 32 个包的逐个接收状态ack ack_bits的组合等价于 TCP 的 SACK累计确认 空洞细节一次说清你发的前 32 个包哪些到了。2️⃣ 头部压缩健康连接只要 4 字节头部采用省略编码稳态下 32 位确认位全为 1这些全 1 字节直接省略不传ack与sequence差距在 255 以内时也只存一个字的差值。于是健康网络头部仅4 字节高丢包网络逐渐膨胀到最多9 字节包头越短恰好是网络越健康的信号。3️⃣ 收发两端如何配合发送侧send_packet() 自动打上 sequence并生成我收到了你哪些包的 ack/ack_bits ↓ 接收侧receive_packet() 解析头部 → 查已发包记录 → 把被确认的序列号压入 ack 缓冲 ↓ 每帧末尾get_acks() 取出 → 清掉 clear_acks()两个必须记住的约定每帧处理完必须调reliable_endpoint_clear_acks()否则缓冲写满后新 ACK 会被丢弃并打印错误日志假设持续双向通信ACK 靠出站包捎带单向或突发式请求/响应不在设计范围内因此 reliable 也不做 keepalive4️⃣ ACK 顺手算出 RTT收到 ACK 的瞬间端点用当前时间 − 该包发出时间得到一次 RTT 样本存入历史环形缓冲。这就是下一节统计数据的来源。五、分片与重组大包也能可靠确认地穿过 UDPUDP 单包受 MTU 限制约 1500 字节reliable 用分片解决大包问题超过fragment_above的包按fragment_size切片所有分片共享同一个序列号只有第 0 片携带完整包头含 ACK 信息后续分片只带 5 字节的分片头接收端按序列号归集分片收齐后重组走与普通包相同的确认流程⚠️ 设计上刻意接受丢片代价任何一片丢失整个包作废。因为 reliable 优先保证时延——需要可靠传大文件的场景应在上层自建块传输作者的 yojimbo 就是这么做的而不是 routinely 发超大包。六、网络统计RTT、抖动、丢包率一键读取每帧调一次reliable_endpoint_update(endpoint, time)端点会自动刷新全部统计随后按需读取reliable_endpoint_rtt()指数平滑后的 RTT 均值毫秒reliable_endpoint_rtt_min/max/avg()历史窗口内的极值与均值reliable_endpoint_jitter_*()抖动平均/最大/标准差相对 RTTreliable_endpoint_packet_loss()丢包率百分比reliable_endpoint_bandwidth()发送/接收/已确认三路带宽kbps另有 11 个计数器reliable_endpoint_counters()暴露收发、确认、陈旧、重复、超尺寸等全部路径的精确计数排障时非常有用。stats.c就是一个只打印这些指标的演示程序。七、最小使用流程五步跑通收发确认步骤API说明1reliable_default_config()→reliable_endpoint_create()每端一个端点2reliable_endpoint_send_packet()发包自动分片、自动打 ACK3reliable_endpoint_receive_packet()socket 每收到一个 UDP 包就喂进来4reliable_endpoint_get_acks()→clear_acks()每帧取走并清空确认列表5reliable_endpoint_update()→destroy()每帧刷新统计结束销毁example.c 演示了完整闭环两个端点互相发包、模拟 90% 丢包打印每个 ACK 的到达过程——强烈建议配合 BUILDING.md 编译后运行一遍。八、常见误区与注意事项 忘记清 ACKACK 只增不减缓冲写满即丢务必每帧清理发包回调里再发同一个端点的包发送路径使用端点内共享的暂存缓冲回调中发同端点会踩坏数据发其他端点没问题拿它当消息层用reliable 不重传、不保证顺序、不建连——握手、加密、认证是 netcode 的职责Release 构建信任调用者错误配置在 Debug 下会被断言拦住Release 下不加校验开销正确配置是程序员的契约端点跨线程共享不加锁就会出乱子九、项目文件导航文件内容reliable.c/reliable.h库本体与全部公开 API含详细注释example.c最小收发确认示例stats.c/soak.c/fuzz.c统计演示 / 压力测试 / 对抗性链路模糊测试STANDARD.md线格式规范可独立实现并逐字节互通BUILDING.mdCMake 构建与 CI 说明tools/conformance/文档与实现的一致性校验工具oss-fuzz/OSS-Fuzz 集成配置一句话总结reliable 用端点 回绕序列号 捎带式 ACK三板斧为 UDP 补上确认能力——它不替你重传却让你精确知道每个包的命运这正是构建低延迟可靠网络协议最锋利的那把刀。【免费下载链接】reliablePacket acknowledgement system for UDP项目地址: https://gitcode.com/gh_mirrors/re/reliable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 reliable核心概念指南：端点、序列号与ACK机制彻底讲透
reliable核心概念指南端点、序列号与ACK机制彻底讲透【免费下载链接】reliablePacket acknowledgement system for UDP项目地址: https://gitcode.com/gh_mirrors/re/reliablereliable是一个面向 UDP 的轻量级数据包确认ACK系统用不到 3000 行 C 代码帮你回答一个核心问题我发出去的 UDP 包对端到底收到没有围绕这个目标它构建了三个核心概念——端点Endpoint、16 位序列号Sequence和捎带式 ACK 确认机制再附加分片重组与 RTT、抖动、丢包率统计。本文带你彻底讲透这三件事读完即可看懂 reliable.c 的主干逻辑。一、reliable 是什么给 UDP 补上收到没的确认层UDP 快速但不可靠包可能丢失、乱序、重复。TCP 虽然可靠却带着重传、拥塞控制等全家桶对实时游戏、音视频等低延迟场景偏重。reliable 走的是第三条路它不是消息层而是确认系统。能力说明✅ 收包确认收到对端包后立即确认ack告诉你哪些包已送达✅ 分片重组超过阈值的大包自动切分发送对端自动拼回✅ 网络统计自动估算 RTT、抖动、丢包率、带宽✅ 去重窗口内的重复包被识别并丢弃❌ 不重传哪些包丢了由你决定怎么补发——这是刻意的设计正如 STANDARD.md 所写It doesnotretransmit. It tells you which packets arrived; what you do about the ones that did not is your business. 这种只确认、不重传的取舍让 reliable 保持极小、极快适合叠加在游戏协议等自有逻辑之上。二、端点Endpoint一条连接一个端点端点是 reliable 里一切状态的家。每条连接各持一个reliable_endpoint_t客户端/服务器场景每个客户端一个端点服务器为每个客户端槽位各建一个端点端点内部维护三本账已发包记录sent_packets、已收包记录received_packets、分片重组缓冲fragment_reassembly端点还保存 ACK 缓冲、RTT 历史、网络计数器等端点不是线程安全的一个线程一个端点或自行加锁。1️⃣ 创建端点的三步曲调reliable_default_config()拿到一份面向 60Hz 实时通信的默认配置按业务调整关键参数见下表调reliable_endpoint_create(config, time)创建记得结束时reliable_endpoint_destroy()释放配置项含义max_packet_size可收发的最大包大小fragment_above超过该字节数即分片发送fragment_size/max_fragments每片大小 / 每包最多片数上限 256ack_buffer_size两次清理之间最多暂存多少个 ACKtransmit_packet_function发包回调由你套上 UDP socket 发出process_packet_function收包回调返回 1 表示接受并确认该包返回 0 拒绝这种库不碰 socket的设计让 reliable 可以搭任何网络库使用作者的姊妹项目 netcode 就是配套的网络层。完整可运行示例见 example.c。三、序列号Sequence16 位、会回绕、必须按环形比较每个发出去的包都会被端点自动分配一个16 位序列号从 0 一路加到 65535 后回到 0回绕。为什么能只比较 32768 以内reliable 用有符号距离判断新旧见 reliable.c 中reliable_sequence_greater_than两个序列号相减后距离不超过 32768 才算更新。这就像时钟——凌晨 0:59 比 23:59 晚。这套规则带来三个直接后果回绕安全发送速率按 60Hz 设计65536 个包约 18 分钟才转一圈完全来得及陈旧包stale被拒序列号落在接收窗口之前的包直接丢弃重复包被拒窗口内已收过的序列号再次出现按NUM_PACKETS_DUPLICATE计数并丢弃发送前预知序列号reliable_endpoint_next_packet_sequence(endpoint)会告诉你下一个包将要拿到的序列号。这是做重传的关键记录消息 X 装进了序列号 4021 的包 → 收到 4021 的 ACK → 消息 X 已被确认。四、ACK 机制每个包都捎带一份确认回执这是 reliable 最精妙的部分没有独立的 ACK 包确认信息直接搭便车在数据包头上。1️⃣ 包头里有什么每个包的头部携带三个值格式细节见 STANDARD.md字段作用sequence本包的序列号ack对端最近收到的序列号累计确认ack_bits32 位掩码ack之前 32 个包的逐个接收状态ack ack_bits的组合等价于 TCP 的 SACK累计确认 空洞细节一次说清你发的前 32 个包哪些到了。2️⃣ 头部压缩健康连接只要 4 字节头部采用省略编码稳态下 32 位确认位全为 1这些全 1 字节直接省略不传ack与sequence差距在 255 以内时也只存一个字的差值。于是健康网络头部仅4 字节高丢包网络逐渐膨胀到最多9 字节包头越短恰好是网络越健康的信号。3️⃣ 收发两端如何配合发送侧send_packet() 自动打上 sequence并生成我收到了你哪些包的 ack/ack_bits ↓ 接收侧receive_packet() 解析头部 → 查已发包记录 → 把被确认的序列号压入 ack 缓冲 ↓ 每帧末尾get_acks() 取出 → 清掉 clear_acks()两个必须记住的约定每帧处理完必须调reliable_endpoint_clear_acks()否则缓冲写满后新 ACK 会被丢弃并打印错误日志假设持续双向通信ACK 靠出站包捎带单向或突发式请求/响应不在设计范围内因此 reliable 也不做 keepalive4️⃣ ACK 顺手算出 RTT收到 ACK 的瞬间端点用当前时间 − 该包发出时间得到一次 RTT 样本存入历史环形缓冲。这就是下一节统计数据的来源。五、分片与重组大包也能可靠确认地穿过 UDPUDP 单包受 MTU 限制约 1500 字节reliable 用分片解决大包问题超过fragment_above的包按fragment_size切片所有分片共享同一个序列号只有第 0 片携带完整包头含 ACK 信息后续分片只带 5 字节的分片头接收端按序列号归集分片收齐后重组走与普通包相同的确认流程⚠️ 设计上刻意接受丢片代价任何一片丢失整个包作废。因为 reliable 优先保证时延——需要可靠传大文件的场景应在上层自建块传输作者的 yojimbo 就是这么做的而不是 routinely 发超大包。六、网络统计RTT、抖动、丢包率一键读取每帧调一次reliable_endpoint_update(endpoint, time)端点会自动刷新全部统计随后按需读取reliable_endpoint_rtt()指数平滑后的 RTT 均值毫秒reliable_endpoint_rtt_min/max/avg()历史窗口内的极值与均值reliable_endpoint_jitter_*()抖动平均/最大/标准差相对 RTTreliable_endpoint_packet_loss()丢包率百分比reliable_endpoint_bandwidth()发送/接收/已确认三路带宽kbps另有 11 个计数器reliable_endpoint_counters()暴露收发、确认、陈旧、重复、超尺寸等全部路径的精确计数排障时非常有用。stats.c就是一个只打印这些指标的演示程序。七、最小使用流程五步跑通收发确认步骤API说明1reliable_default_config()→reliable_endpoint_create()每端一个端点2reliable_endpoint_send_packet()发包自动分片、自动打 ACK3reliable_endpoint_receive_packet()socket 每收到一个 UDP 包就喂进来4reliable_endpoint_get_acks()→clear_acks()每帧取走并清空确认列表5reliable_endpoint_update()→destroy()每帧刷新统计结束销毁example.c 演示了完整闭环两个端点互相发包、模拟 90% 丢包打印每个 ACK 的到达过程——强烈建议配合 BUILDING.md 编译后运行一遍。八、常见误区与注意事项 忘记清 ACKACK 只增不减缓冲写满即丢务必每帧清理发包回调里再发同一个端点的包发送路径使用端点内共享的暂存缓冲回调中发同端点会踩坏数据发其他端点没问题拿它当消息层用reliable 不重传、不保证顺序、不建连——握手、加密、认证是 netcode 的职责Release 构建信任调用者错误配置在 Debug 下会被断言拦住Release 下不加校验开销正确配置是程序员的契约端点跨线程共享不加锁就会出乱子九、项目文件导航文件内容reliable.c/reliable.h库本体与全部公开 API含详细注释example.c最小收发确认示例stats.c/soak.c/fuzz.c统计演示 / 压力测试 / 对抗性链路模糊测试STANDARD.md线格式规范可独立实现并逐字节互通BUILDING.mdCMake 构建与 CI 说明tools/conformance/文档与实现的一致性校验工具oss-fuzz/OSS-Fuzz 集成配置一句话总结reliable 用端点 回绕序列号 捎带式 ACK三板斧为 UDP 补上确认能力——它不替你重传却让你精确知道每个包的命运这正是构建低延迟可靠网络协议最锋利的那把刀。【免费下载链接】reliablePacket acknowledgement system for UDP项目地址: https://gitcode.com/gh_mirrors/re/reliable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考