分享了一下自己在两个月重度使用 AI Code Agent 工具之后，一些个人的思考和感悟。以一个非 AI 领域从业者的普通程序员视角，大胆猜想后续的主流开发会切换到 AI 工具来生成代码，程序员更多的需要承担起技术架构师的职责，这意味着对程序员的要求不仅没有降低，反而变得更高了

聊了聊为什么想写这个新系列，以及自己为什么喜欢 eBPF 技术，随后就是以 Reuseport eBPF 方案为例，进一步分析它是怎么解决 UDP 热更新问题的技术细节，以及分析 nginx eBPF 实现和缺陷。在这个过程中，还回顾了自己当初由于不了解 eBPF 加载器背后原理而踩过的坑。最后，我还较为深入的分析了 Cloudflare 新出的 udpgrm 开源项目

借着当年一个棘手的需求，来介绍 Established-over-unconnected 技术方案：从 Linux 服务端高并发场景下如何进行 UDP 网络编程切入，讨论如何确保实现真正的无损热更新，更进一步的梳理了在不同内核版本下会存在哪些坑，并结合内核 TCP、UDP 数据包如何匹配对应套接字的代码实现细节，讲述了这些坑应该如何化解

在讨论连接迁移之前，先介绍了一下 QUIC 是怎么实现面向连接的特性，然后再分析了一下 QUIC 连接迁移的设计细节，并且对比其他协议类似的方案，比如说 WebRTC Mobility 等。关于具体的代码实现，重点分析了连接迁移的经典场景，并且讨论了 feather-quic 本次实现中可以提供哪些方式供开发者使用连接迁移功能，以及 feather-quic 目前的一些缺陷。最后，因为本次大部分代码都是依赖 AI 生成的，所以趁热打铁聊一聊对大模型生成代码这件事情的想法和感悟

从传输层协议为什么需要 MTU 探测说起，重点分析了为什么 IP 分片会导致传输层性能下降、甚至会影响可用性，接着讨论 MTU 探测常见的实现方式，以及有趣的实现细节，再分析下 QUIC 在实现 MTU 探测的时候，是怎么解决 TCP 面对的问题，也顺带着聊了聊 GSO TSO GRO 相关的内核优化技术，最后给了一些关于日常家用 MTU 配置的建议

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

我最近在处理一个客户的线上工单问题时，发现自己不知不觉犯了一个方向性的小错误，这让我有点开始反思自己，考虑到我第一份工作 4 年多时间一直在高强度的 on call，我其实觉得自己还是很擅长故障应急和客户紧急工单处理，所以我想总结一下我当初积累的经验教训，给自己提一个醒。同时也记录下当初自己是如何从五花八门的故障中学习经验教训，快速成长的

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

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