最近处理一个客户线上工单时，我发现自己不知不觉犯了一个方向性的小错误，于是开始重新反思故障应急这件事。第一份工作里，我经历了 4 年多高强度 on call，也长期参与大型项目迭代，那种状态有点像开着飞机换引擎：系统还在高速运行，变更还在持续推进，故障也随时可能发生。这篇文章想总结当年积累的经验教训，也记录自己是如何从五花八门的线上故障中学习、复盘和成长的。

这里，终于开始实现 QUIC 核心能力: QUIC 多路复用流传输，同时实现了流量控制，确保在 QUIC 传输数据的过程中，能够严格按照 QUIC 协议规范工作， 并且优化了项目的结构，新增了一些集成测试来确保项目质量

对比了 TCP 和 QUIC 在 Reliability 实现的区别，详细描述了实现 QUIC Reliability 能力的相关细节，考虑了后续要如何加强测试，提升项目质量

实现一个 TLS 1.3 的简单客户端版本，协商出 TLS 1.3 对称密钥来给 QUIC-TLS 使用，另外支持了 QUIC-TLS Key Update 的能力，同时顺带实现了 SSLKEYLOG 的密钥导出功能，方便后续使用 WireShark 等工具进行问题排查

努力描述了 QUIC-TLS 在解决什么问题，怎么解决问题，以及尝试不使用任何 SSL 库，自己独立实现一个客户端版本的 QUIC-TLS（暂时没有实现 TLS 1.3 握手协议相关，留给下一篇博客），另外支持了在客户端上对 QUIC Retry Packet 的处理

为 feather-quic 选择一个合适的 runtime

这是用 Rust 从零实现 QUIC 协议栈的开篇。文章会聊我为什么想做这个项目，希望通过它加深对 QUIC、网络协议和 Rust 工程实践的理解，也会记录对项目目标的预期，以及正式开始编码前需要做哪些准备。