返回资讯中心
外部精选
软件工程
#开发者实时流

Pion 发布 DTLS 1.3 实现并设为默认版本

来源标题:How hard could implementing DTLS 1.3 possibly be?

Pion 的 DTLS 1.3 实现历时十个月、约 400 次提交后,已成为 pion/dtls 的默认版本。该项目自 2020 年规范仍为草案时便已立项,2022 年 DTLS 1.3 成为 RFC 9147。作者于 2026 年 1 月接手主导开发,当时团队多数人并不了解 DTLS 1.3 的工作原理。

Hacker News 最新Sean-Der2026/11/7 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

2026年1月,我不知怎么就成了Pion的DTLS 1.3实现负责人,并且完成了其中的大部分工作。那时这基本还只是个想法,我对DTLS 1.3怎么工作也谈不上了解。后来跟我一起把它做出来的大多数人,当时也一样 :)

十个月、大约400个commit之后,DTLS 1.3成了pion/dtls的默认版本:

我想把这段来龙去脉写下来,也想按我当初希望有人给我讲的方式来讲DTLS。所以这篇两件事都做,中间穿插你可以随手折腾、弄坏的交互式demo。

Client想和Server私下通信 Server想确认对面真的是Client Mallory蹲在线上,什么都读,能改的就改

背景与来龙去脉

不想看背景的直接跳到实现部分。

Pion的“DTLS 1.3计划”issue从2020年2月就开着,那时规范还是草案。它在2022年成了RFC 9147,但没人有那个时间真正投入进去,隔一阵子就有人来问进度……

而在2025年1月,Pion及其各个库的创造者Sean DuBois跟我说(一个无名小卒),我可以和他一起co-maintain,并把整个项目的owner权限交给了我。Sean对我的信任超过了我对自己的信任 :)

我建了Pion的Discord服务器,每天review PR,在整个技术栈上贡献新功能,还游说朋友们来贡献。但我总是打开那个DTLS 1.3 issue,盯着它,然后把标签页关掉。做DTLS的修复和review还行,再大一点的事感觉我会搞出个RCE来!

然后2025年5月,Theo(Theodor Signebøen Midtlien)在issue里说他已经向NLnet提交了申请。同一天,Sean提出由他来review和merge一切,如果NLnet不给钱,他就去敲公司的门要钱。NLnet批了,Theo在8月6日公布了这笔资助。

当时,R Chiu和我正大量投入Pion的SCTP栈——WebRTC data channel跑在上面的那个东西。她实现了RACK丢包恢复。

Adriano Sela Aviles也在和我们一起做Pion的TURN实现时加入了,发了一些很重要的PR,但他和R都有自己的生活,没法把实现一路做到底。

我把规范读过一遍,从高层面理解起来没什么障碍,所以很乐意帮忙review。R Chiu帮忙做了key schedule。但这是Theo的项目,我们想帮忙,又不想碍事。

很多人在等它。12月,项目刚起步的时候,在OpenAI(Sean工作过的地方)的Justin Uberti来问进度。他们想要“连接建立阶段更少的RTT,以及……后量子加密支持”。更低的RTT意味着语音AI能更快开口。

Theo整理了一份高层MVP计划,开了几个骨架PR,但后来生活忙起来了,包括在NetBird的新工作!到2026年1月,我刚开始在Upwork做一份新的WebRTC工作,不过我还没有家庭,所以下班后有自由时间 :) Theo很乐意把项目交给我。我承诺会按他的计划好好做并加以扩展,包括WebRTC子集之外的部分。我想要一个真正的DTLS 1.3库,Pion只是恰好也用它,因为WebRTC之外的用户同样需要resumption、0-RTT和Connection ID。

我不想因为自己在Pion上的工作拿钱,因为我不想把它当成一份工作。我也想让人和我一起做。所以我找了已经为Pion贡献过的朋友们——Jade Kolos、Júlia Borges Paschoalinoto和Julia-Elena Roman,后来还有Jan Muška——加入这个NLnet资助的工作,并把他们推荐给Theo。于是DTLS 1.3就归我们来完成了 :)

我们手上有一些其实并不真正理解DTLS 1.3的DTLS 1.2扩展解析器,还有一个没合并的状态机骨架。没有record layer,没有key schedule,没有加密,没有任何能完成一次DTLS 1.3握手的部分。而且我们谁都没有真正的TLS背景。

从交接算起,大约过了四个月,我们才有了第一个record layer实现。期间有扩展和辅助函数的commit,但主体实现是停滞的。我们不停地读规范和别人的实现:RFC 9147、RFC 8446、RFC 9146、IETF的各种文章。我主要还是焦虑:我想把它做对,不想弄坏别人已经在用的东西。

后来Sean来问进展如何。就是从那时起,我们得到了他的背书,可以真正往前推。他帮忙做了代码设计(DTLS 1.3怎么和1.2干净地共存)、FSM、Go的惯用写法、清理一些旧代码,后来还做了DTLS 1.3 ACK可靠性的大部分。

但最重要的是,除了技术部分,他让我有足够的信心去做这件事,并在过程中弄坏东西。他告诉我,我可以不经过review直接merge!

我们不必在开始之前把每一点都搞明白。他review、merge、扫清障碍、给我们打气。没有他,我觉得这还得多花一年甚至更久。

5月13日我们开始做record layer。6月19日我们终于把状态机合并了。

7月7日,我用这个非常合理的估计关掉了那个六年前的issue:

我觉得两周内我们就能有一个可用的、production ready的MVP。

服务端的Finished在7月12日验证通过,7月29日客户端的Finished也验证通过。一个Pion客户端和Pion服务端终于完成了一次DTLS 1.3握手。8月5日,我得到了第一个确认:DTLS 1.3在WebRTC中对着Chrome能工作!我两天没睡,简直不敢相信。大部分代码是我写的,而且没对着别的实现测过,哈哈。

我们团队的总结里有一句话我很喜欢:“Finished”是另一回事。握手只是开始。8月有一百多个commit:Connection ID、KeyUpdate、HelloRetryRequest、SRTP协商、重写扩展解析,还有一周时间在删重复代码——这一项我严重低估了。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →