<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://blog.yungyu.tech/</id><title>羊羽'Blog</title><subtitle>悲观者正确，乐观者成功，自律者自由。</subtitle> <updated>2026-08-07T14:07:05+00:00</updated> <author> <name>羊羽</name> <uri>https://blog.yungyu.tech/</uri> </author><link rel="self" type="application/atom+xml" href="https://blog.yungyu.tech/feed.xml"/><link rel="alternate" type="text/html" hreflang="zh-CN" href="https://blog.yungyu.tech/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 羊羽 </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>【笔记】特殊用途 IPv4 地址的语义与云网络边界</title><link href="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-%E7%89%B9%E6%AE%8A%E7%94%A8%E9%80%94-IPv4-%E5%9C%B0%E5%9D%80%E7%9A%84%E8%AF%AD%E4%B9%89%E4%B8%8E%E4%BA%91%E7%BD%91%E7%BB%9C%E8%BE%B9%E7%95%8C/" rel="alternate" type="text/html" title="【笔记】特殊用途 IPv4 地址的语义与云网络边界" /><published>2026-08-07T00:00:00+00:00</published> <updated>2026-08-07T00:00:00+00:00</updated> <id>https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-%E7%89%B9%E6%AE%8A%E7%94%A8%E9%80%94-IPv4-%E5%9C%B0%E5%9D%80%E7%9A%84%E8%AF%AD%E4%B9%89%E4%B8%8E%E4%BA%91%E7%BD%91%E7%BB%9C%E8%BE%B9%E7%95%8C/</id> <content type="text/html" src="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-%E7%89%B9%E6%AE%8A%E7%94%A8%E9%80%94-IPv4-%E5%9C%B0%E5%9D%80%E7%9A%84%E8%AF%AD%E4%B9%89%E4%B8%8E%E4%BA%91%E7%BD%91%E7%BB%9C%E8%BE%B9%E7%95%8C/" /> <author> <name>羊羽</name> </author> <summary>看到 100.64.0.0/10、169.254.0.0/16 或 RFC 1918 地址时，不能只用“都不是公网地址”把它们归为一类。地址段的注册用途、默认路由作用域和某个云厂商赋予它的产品语义是三层不同信息。 一句话心智模型是：IANA/RFC 决定地址的标准语义，路由系统决定当前网络能否到达，云产品再在其中绑定具体服务；后一层不能反向改写前两层。 1. 100.64.0.0/10 是 Shared Address Space RFC 6598 保留了： 100.64.0.0/10 100.64.0.0 - 100.127.255.255 它的原始目的，是让服务提供商在 Carrier-Grade NAT（CGN）设备与客户侧设备之间使用一段不与 RFC 1918 家庭/企业私网重叠的地址空间。 flowchart LR A[用户 LAN&amp;amp;lt;br/&amp;amp;gt...</summary> </entry> <entry><title>【笔记】四层负载均衡的数据路径与回包模型</title><link href="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-%E5%9B%9B%E5%B1%82%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E7%9A%84%E6%95%B0%E6%8D%AE%E8%B7%AF%E5%BE%84%E4%B8%8E%E5%9B%9E%E5%8C%85%E6%A8%A1%E5%9E%8B/" rel="alternate" type="text/html" title="【笔记】四层负载均衡的数据路径与回包模型" /><published>2026-08-07T00:00:00+00:00</published> <updated>2026-08-07T00:00:00+00:00</updated> <id>https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-%E5%9B%9B%E5%B1%82%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E7%9A%84%E6%95%B0%E6%8D%AE%E8%B7%AF%E5%BE%84%E4%B8%8E%E5%9B%9E%E5%8C%85%E6%A8%A1%E5%9E%8B/</id> <content type="text/html" src="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-%E5%9B%9B%E5%B1%82%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E7%9A%84%E6%95%B0%E6%8D%AE%E8%B7%AF%E5%BE%84%E4%B8%8E%E5%9B%9E%E5%8C%85%E6%A8%A1%E5%9E%8B/" /> <author> <name>羊羽</name> </author> <summary>四层负载均衡最容易产生的误解，是看到后端保留客户端 IP，就直接猜它使用了 DSR、隧道或某种 TCP Option。仅凭一个地址现象无法确定完整数据路径。 一句话心智模型是：分别追踪请求和回包经过的地址转换、下一跳与状态归属；“后端看见谁”只是其中一个观测点。 1. 一个连接有三种观察视角 客户端建立的是： ClientIP:ClientPort → VIP:ServicePort 后端可能看到： ClientIP:ClientPort → RSIP:BackendPort 客户端最终仍必须收到： VIP:ServicePort → ClientIP:ClientPort 如果后端回包直接以 RSIP 为源地址到达客户端，客户端 TCP socket 的远端四元组对不上，连接不能正常成立。因此，后端看到真实源地址时仍然要回答两个独立问题： 请求方向如...</summary> </entry> <entry><title>【笔记】OCI 容器镜像规范与分层复用机制</title><link href="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-OCI-%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E8%A7%84%E8%8C%83%E4%B8%8E%E5%88%86%E5%B1%82%E5%A4%8D%E7%94%A8%E6%9C%BA%E5%88%B6/" rel="alternate" type="text/html" title="【笔记】OCI 容器镜像规范与分层复用机制" /><published>2026-08-07T00:00:00+00:00</published> <updated>2026-08-07T00:00:00+00:00</updated> <id>https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-OCI-%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E8%A7%84%E8%8C%83%E4%B8%8E%E5%88%86%E5%B1%82%E5%A4%8D%E7%94%A8%E6%9C%BA%E5%88%B6/</id> <content type="text/html" src="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-OCI-%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E8%A7%84%E8%8C%83%E4%B8%8E%E5%88%86%E5%B1%82%E5%A4%8D%E7%94%A8%E6%9C%BA%E5%88%B6/" /> <author> <name>羊羽</name> </author> <summary>中心问题 skopeo、crane 这类”操作镜像仓库”的工具，职责和原理是什么？它们能够互相操作彼此的产物，靠的是什么规范体系？镜像分层能够复用（磁盘、传输、构建三个不同场景），背后各自依赖什么标识机制，这些标识之间是什么关系？ 整体模型：三份规范，各管一段 容器从”写 Dockerfile”到”进程真正跑起来”，要经过三个解耦的阶段，OCI（Open Container Initiative）对每个阶段各发布一份规范： image-spec ──转换──▶ runtime bundle ──runc/crun──▶ 实际运行的容器进程 （镜像长什么样） │ └─ runtime-spec 定义 bundle 结构（config.json + rootfs...</summary> </entry> <entry><title>【笔记】Linux 用户环境的 Shell 初始化与目录边界</title><link href="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-Linux-%E7%94%A8%E6%88%B7%E7%8E%AF%E5%A2%83%E7%9A%84-Shell-%E5%88%9D%E5%A7%8B%E5%8C%96%E4%B8%8E%E7%9B%AE%E5%BD%95%E8%BE%B9%E7%95%8C/" rel="alternate" type="text/html" title="【笔记】Linux 用户环境的 Shell 初始化与目录边界" /><published>2026-08-07T00:00:00+00:00</published> <updated>2026-08-07T00:00:00+00:00</updated> <id>https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-Linux-%E7%94%A8%E6%88%B7%E7%8E%AF%E5%A2%83%E7%9A%84-Shell-%E5%88%9D%E5%A7%8B%E5%8C%96%E4%B8%8E%E7%9B%AE%E5%BD%95%E8%BE%B9%E7%95%8C/</id> <content type="text/html" src="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-Linux-%E7%94%A8%E6%88%B7%E7%8E%AF%E5%A2%83%E7%9A%84-Shell-%E5%88%9D%E5%A7%8B%E5%8C%96%E4%B8%8E%E7%9B%AE%E5%BD%95%E8%BE%B9%E7%95%8C/" /> <author> <name>羊羽</name> </author> <summary>用户环境里有两套经常混在一起的机制：Shell 启动文件决定变量和交互行为何时进入进程；XDG Base Directory 约定应用把配置、数据和运行状态放在哪里。 一句话心智模型是：先沿进程父子关系判断配置何时被加载，再沿数据生命周期判断文件应该存放在哪里。 1. 环境不是从某个配置文件凭空出现的 进程通常继承父进程的环境变量。Shell 启动文件只是在 Shell 进程创建时，根据当前启动模式继续修改这份环境。 flowchart LR A[登录管理器、终端或 SSH] --&amp;amp;gt; B[启动 Zsh] B --&amp;amp;gt; C[按 login / interactive 状态读取启动文件] C --&amp;amp;gt; D[export 修改当前 Shell 环境] D --&amp;amp;gt; E[子进程继承环境] 这解释了两个常见现象： 变量写进 ...</summary> </entry> <entry><title>【笔记】Claude Code 与 Codex Command 的能力模型与工作流</title><link href="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-Claude-Code-%E4%B8%8E-Codex-Command-%E7%9A%84%E8%83%BD%E5%8A%9B%E6%A8%A1%E5%9E%8B%E4%B8%8E%E5%B7%A5%E4%BD%9C%E6%B5%81/" rel="alternate" type="text/html" title="【笔记】Claude Code 与 Codex Command 的能力模型与工作流" /><published>2026-08-07T00:00:00+00:00</published> <updated>2026-08-07T00:00:00+00:00</updated> <id>https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-Claude-Code-%E4%B8%8E-Codex-Command-%E7%9A%84%E8%83%BD%E5%8A%9B%E6%A8%A1%E5%9E%8B%E4%B8%8E%E5%B7%A5%E4%BD%9C%E6%B5%81/</id> <content type="text/html" src="https://blog.yungyu.tech/posts/%E7%AC%94%E8%AE%B0-Claude-Code-%E4%B8%8E-Codex-Command-%E7%9A%84%E8%83%BD%E5%8A%9B%E6%A8%A1%E5%9E%8B%E4%B8%8E%E5%B7%A5%E4%BD%9C%E6%B5%81/" /> <author> <name>羊羽</name> </author> <summary>1. 一句话心智模型 Claude Code 和 Codex 的 Command 不只是快捷键。它们正在成为 Agent Runtime 的控制面：观察当前状态，调整 Context，分叉 Conversation，切换执行者，延长任务生命周期，隔离 Workspace，最后把结果送进 Review、测试和 PR。 理解一条 Command 时，我现在固定问九个问题： 它改变哪一层状态？ 它继承什么 Context？ 谁继续执行？ 结果回到哪里？ Main Conversation 是否继续？ 是否共享 Workspace？ 是否自动创建 Worktree？ 怎样停止、恢复或收口？ 它受什么版本、平台、账号、Provider、Surface 或 Feature Gate 限制？ 这套问题比记住命令名字更重要。Claude Code 和 ...</summary> </entry> </feed>
