stun-types

包含STUN（RFC5389/RFC8489）协议实现（使用Rust编程语言）的仓库。

目标

• 效率
  • 零拷贝解析
  • 直到消息写入之前不进行任何复制。
• 易于支持外部定义的属性。实现只需要3个特质，其中两个是 From 和 TryFrom。

相关标准

• RFC5245：交互式连接建立（ICE）：用于Offer/Answer协议的网络地址转换器（NAT）穿越协议
• RFC5389：会话穿越NAT（STUN）
• RFC5766：使用NAT（TURN）穿越：STUN的会话穿越扩展
• RFC5769：会话穿越NAT（STUN）的测试向量
• RFC6156：使用NAT（TURN）穿越：对IPv6的扩展
• RFC8445：交互式连接建立（ICE）：用于网络地址转换器（NAT）穿越的协议
• RFC8489：会话穿越NAT（STUN）
• RFC8656：使用NAT（TURN）穿越：STUN的会话穿越扩展

示例

请参阅crate根目录中的文档以获取一些示例

为什么不使用 stun_codec、stun-format、stun-rs 或 '此处插入crate'？

现有的STUN crate存在一些缺点。

1. 将编码属性作为枚举而不是作为特性。使用特性来表示属性允许外部代码实现自己的属性，因此不受crate实现的限制。基于特性的方法还允许我们在不要求打破semver的情况下添加属性实现。例如，rust-stun-coder 和 stun-format 就属于这一类。虽然我们旨在最终支持 IANA 和各种 RFC 中定义的所有 STUN 属性，但我们也不会强迫用户使用我们的实现（除了完整性和指纹属性）。
2. 非零拷贝解析，即在某些特定属性实现需要时才进行数据拷贝。对于大多数 STUN 消息来说，这通常不是什么大问题，但在 TURN 使用和高比特率传输中可能会成为问题。我们的目标是除非必要，否则不进行数据拷贝。例如，stun-format、stun_codec、stun-rs 都未能达到这一设计目标。我能找到的唯一其他实现是 turn-rs，它包含一个非常小的 STUN 实现仅足够用于 TURN 使用。
3. 过于复杂，使用了宏和额外的特性。通常没有必要使用复杂的宏或为消息和属性实现 decoder/encoder 特性来实现 STUN。STUN 是一个相对简单的字节编码器，不需要复杂的实现。例如，stun-rs、stun_codec 目前都未能达到这一设计目标。