首先，按照惯例，先踩一踩 TCP，分析一下 QUIC 连接关闭设计为什么会比 TCP 要好很多。另外，实现了 QUIC 协议栈中各种异常需要关闭连接的情况。最后，这个项目的第一阶段算是初步完成了，说一说到目前为止的一些感受

我最近在处理一个客户的线上工单问题时，发现自己不知不觉犯了一个方向性的小错误，这让我有点开始反思自己，考虑到我第一份工作 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

为什么想做这件事情，对这个个人项目的预期，以及前期的一些准备工作