OSI 模型 on 张欣耕的个人博客

买烤面包机的艺术

Wed, 13 May 2026 00:00:00 +0000

如果你是新读者:在上一篇交换机到底在干嘛里,我承认自己在网络这事上"嘴上有功底",然后认真补课,终于理解了:为什么一个监听在 127.0.0.1 的服务,会对那个通过 10.88.0.1 过来的容器完全隐身。

对老朋友们:这篇是一次有意为之的小小"岔路"。

小尴尬

写第一篇的中途,我试图把新学的东西讲给一个不写代码的朋友听。晚餐时她礼貌地问:你这周在发什么技术疯?

我说了大概三句话,她的眼睛就开始出现那种神奇的微光。

你懂的——那种"我爱你我在场,但我已经听不懂中文了"的微光。我已经说出了 TCP, 内核, bridge interface,下一步就要爆出 MAC address,幸好我及时刹车。

这时我发现一个问题:我现在会解释交换机了;我能解释虚拟桥;我能解释为什么 Portainer 容器看不见我的 SSH 隧道。可如果她问我——从她在网站上点下"购买"的那一刻起,到页面回个"下单成功"为止,整件事到底一秒不落地发生了什么? ——我会直接开摆。我有很多零件,但没有一个完整的故事。

于是我决定写一个。一个真的故事。有角色,有场景,有戏剧冲突。尽量不说术语。甚至要做到能在餐桌上讲完的那种。

“解码环”(每个角色在计算机世界里到底是谁)在文末。请先看故事。尤其是你从没认真想过网站"到底怎么工作"的话,更要先看。

出场人物

先认识一下小小的演员表,他们出场快,退场也快。

Jack。一个在家网购的男人。他只想买台烤面包机。这就是他全部的人设。
浏览器小助手(Browser-Bot)。住在 Jack 的笔记本里。写便条, 打包包裹, 交给快递。忠诚, 龟毛。
信使之海(The Sea of Couriers)。一整片在 Jack 家和商店之间的接力快递大军。每个人只知道"下一个该交给谁"。他们不看信,只转运。
前门(The Front Gate)。遥远写字楼门口冷静的小门童。只接收投递到"这栋楼"的包裹,其他一律拒收。不会读书。
内核妈妈(Mama Kernel)。办公室经理。知道每个门, 每张桌, 每位住户。她桌上有三样法宝:整栋楼的分机黄页, 一本改地址的规则书, 和一大本"今天收了啥我怎么处理的"的流水账。冷静, 稳重, 百战成精。
前置文员与后置文员(Pre-Clerk & Post-Clerk)。成对上班的小助理。前置文员负责每个入站包裹,有时会改改包裹外面的地址;后置文员管出站的包裹——并且手抄了一份前置文员做过的所有修改,好在出门前把地址"改回去"。
走廊礼宾(The Hallway Concierge)。管楼内走廊。认得每位住户的脸。他的唯一超能力:把包裹沿着走廊"横着"送到对的门口——不上不下,只走平面。
前端弗里达(Frieda the Frontend)。住在走廊里,10 号。脾气好,像个前台:接到访客的包裹,看看要求,要么自己处理,要么礼貌地转交给能处理的人。
后端布鲁图(Brutus the Backend)。10 号隔壁,11 号。粗声粗气的账房先生。不和外人说话。只接弗里达递过来的包裹。真正干活的——开账本, 扣库存, 记订单。
包裹(The Parcels)。故事里的每条消息都是俄罗斯套娃:一封信装进一个信封,塞进一个小包裹,再塞进一个大邮袋。每一层都写给不同的人,走不同的路。我们会看它们一层层拆开, 又一层层重新包好。

齐活儿,开戏。

第一幕——点击

Jack 想要一台烤面包机。

其实他已经惦记了好几周。旧的上周日伴着一缕青烟英勇就义,吓得猫当场换了个房间。他一直在拖,因为网购总感觉比它应有的"更郑重"。但今天,他下定决心。

他滑啊滑。挑中一个。点下"购买"。

Jack 电脑角落里,浏览器小助手噌地弹起,打着领结,手持小夹板。他写下一张短短的便条:这位顾客想买一台烤面包机。然后开始为它披挂远行。

先把便条装进一个小信封,上面写好小助手一手好字的地址。再把这个信封装进一个更大的包裹,写上"商店"的远方地址。然后整个包裹再塞进一个外层邮袋,这一层写的,是门口第一位接力快递的地址。

三层。三个地址。每一层负责一段路。小助手今天已经这么干了一千遍。他把邮袋递出门外。

第二幕——穿越信使之海

第一位接力员早就等着。她接过邮袋,看一眼最外层的地址,撒腿就跑。

她跑到下一位,撕掉外层邮袋——这一层使命已毕——看内层的地址,再用"她自己"的新邮袋包上,写上下一位接力的地址,交棒。

如此往复。

每位接力员都做同样的事:撕掉只用于上一段路的外层,看看里面的地址,再为下一段路重新打包。那个内层包裹——写着商店真正地址的那个——从不被打开。它是神圣的。它是被指定要"端到端旅行"的。

如果你能把时间快进,从高空俯瞰,你会看到一个光点在接力员之间跳跃,穿越半个大陆,身后落满被丢弃的邮袋。最里面的信,相对它的信封没有移动;内层包裹也没有改变。只有最外面的那层,不断地重生。

最终,在人类时间里只是眨眼一瞬,包裹抵达它命定的那栋写字楼。最后一名接力把它交到前门手里,敬个礼,转身继续夜色中的奔波。

第三幕——剥洋葱

前门对邮袋内容不感兴趣。它只关心最外层写的是不是"这栋楼的名字"。确认无误,收下。它的使命完成。

包裹被送进后勤办公室,内核妈妈正等着。

她轻轻拾起,撕下外层邮袋——那只服务于最后一段路。她把里面的包裹放在桌上。这一层的地址的确是写给这栋楼的,而且是"更正式"的写法。对我们有利。

她正要再拆一层,前置文员出现在她身边。

“这件是 10 号公寓的,“他说,“销售咨询。弗里达管。”

内核妈妈点点头。前置文员拿起铅笔,轻轻在包裹外面动了两笔——把"整栋楼"的收件名,改成了"10 号公寓"的具体门牌。他翻开账本认真记下:包裹 #8472,原送达大楼,重定向至 10 号。回程记得改回。记得二字他画了三道杠。他对工作极其较真。

内核妈妈拿着改好抬头的包裹,翻目录。10 号——在走廊那边,礼宾的地盘。她又加了一层小小的"楼内快递套”,直接写明"收:弗里达”,从窗口递给走廊礼宾。

第四幕——走廊

礼宾早已把走廊住户的脸背得滚瓜烂熟。前端弗里达,10 号——稳。三步并作两步,唰地把包裹从她门缝塞入。

弗里达心情一如既往地阳光。她拆套——楼内快递套, 楼层那层, 一路上的原始旅行包裹——最后打开小信封,读到里面的便条。

“这位顾客想买一台烤面包机。”

“好嘞! “弗里达自言自语。“这是布鲁图的活儿。”

她抽出一张白纸,写下"有顾客想买一台烤面包机——请处理”。装进她自己的小信封,抬头写"11 号”,再套上她自己的小快递套,从门缝推出去给礼宾。

这点很关键。弗里达没有把"原包裹"转发给布鲁图;她是写了"一份新的"包裹,代表她自己向布鲁图提出同一请求。原包裹就像一张凭据,被她留在桌上。待会儿还要用。

礼宾接过弗里达的新包裹——沿走廊三步——塞入布鲁图的门缝。

11 号屋里,布鲁图没抬头,听见包裹落地,叹了口气。拆。读。嘟囔:“烤面包机。顾客。行吧。”

他翻开大账本。扣掉一台烤面包机库存。在 Jack 的名下记一笔。砸上一个鲜红的大章"CONFIRMED"。再写一小条回执——“已接单,将发货,ID #42”——装进写给弗里达的小信封,从门缝推回。

礼宾。三步。弗里达家门缝。

弗里达看完布鲁图的回信,笑了。她转回桌上那封"原包裹",提笔写好给"最初发件人——Jack"的回信:“订单已确认,烤面包机正在路上,感谢选购。“照来时的套娃法打包:信封里信封,外套里外套。门缝,递出。

第五幕——回家

回信按来时的路径"镜像"折返。礼宾到内核妈妈。内核妈妈翻目录:发件人在"楼外”,“得从前门出”。

但她正要为出站打包,后置文员来了,啪地翻到包裹 #8472 那页。

“别忘了,“他说,“这包裹进门时,我同事把抬头从大楼改成了 10 号。现在得改回。弗里达的门牌号不能出现在外发的包裹上——对外界来说,这封回信用的是’大楼’的地址,不是任何一个具体住户。”

他用铅笔把抬头改回,合上账本。

内核妈妈给改好抬头的包裹穿上全新的外邮袋,交给前门。前门转手给门口第一位接力。信使之海再次接力,邮袋一层层重生,直到最后一位快递员冲上 Jack 的小路,把包裹从他家门缝塞进来。

浏览器小助手郑重其事地拆开,抚平回信,朗读。

“订单已确认。你的烤面包机正在路上。感谢选购。”

Jack 的浏览器里,Buy 按钮静静变绿,写成”✓ 已下单”。某处,一只猫从阳光房里抬了抬眼。Jack 笑了。

他心想:也太顺了吧。

解码器

其实,一点也不顺。

以下是每位角色"真实身份"的演职员表。像看谢幕后名单一样看它,然后意识到:刚刚那场戏,比你以为的精巧多了。

Jack 与他的浏览器小助手:一位用户和他电脑上的浏览器。浏览器把"我点了购买"这种人类意图,翻译成服务器必须收到的那串消息。
小助手写的"便条"与那一层层套娃:这才是整出戏的灵魂,得多说两句。
- 每条穿越互联网的消息,都是层层嵌套的套娃。最里面那张便条是实际内容——在我们这里是"买一台烤面包机”。它叫 HTTP 请求,是浏览器和网站说话的语言。
- 其外是一层 TCP segment——加上可靠性功能(序列号, 重传, 确认回执),万一路上有丢件,能发现并补发。TCP 让互联网"像回事儿";没有它,打开网页就像抛硬币。
- 再外是一层 IP packet——写着端到端"谁发给谁"的地址。它说"这是发往商店公网地址的"。按故事设定,这一层基本不会在中途被打开或修改,它从端到端"穿越"。
- 最外是一层 Ethernet frame——最大号的邮袋。它只认识"下一跳是谁"。每一跳上路前,这一层都会被撕掉, 重写,再交给下一位。
  这套嵌套——HTTP 信里,TCP 外套,IP 再外套,以太网最外套——正是学校里讲的"OSI 模型"在人话里的模样:一个给不同受众的"包里包"。
信使之海:互联网上的路由器。每台只知道"下一跳",合在一起便能接力跨洲。那只"IP 包端到端不变,只有以太网帧每跳重写"的事实,才是互联网能跑起来的关键:里层能活到终点,外层随时换新。
前门:面向外网的网卡(NIC)。在 Linux 主机上通常叫 eth0。职责如故事所述:收下发给我们的帧,丢掉其余,递给内核。
内核妈妈:Linux 内核本尊。她拥有所有接口, 所有路由决定, 所有地址改写, 所有在飞行中的连接。她查的"黄页"是内核路由表(routing table),身边那本"改地址规则书"是 iptables/netfilter,她记的大账本是 conntrack 表。
前置文员与后置文员:iptables 的 PREROUTING 与 POSTROUTING 挂钩。它们做的是 NAT(网络地址转换)。故事里的"进站改目的地到内部门牌"是 DNAT(目的地址转换)。后置文员要在出站"改回"的原因,是让外界只看见大楼的公网地址,而不是任何内部门牌。
走廊礼宾:内核里的虚拟桥(virtual bridge)。在跑容器的 Linux 主机上,常叫 docker0 或 podman0。它的行为和我们在上一篇里研究的"交换机"一模一样:按名字在同一走廊里把包裹送到对应住户;至于它是软件不是铁盒子,只是实现细节。
前端弗里达与后端布鲁图:两只容器(containers),各自住在隔离的"小公寓"里。弗里达可能跑着 nginx 这样的前端;布鲁图可能是数据库或订单处理 API。它们都插在同一条内部走廊(bridge)上,但彼此——以及对整栋楼以外——都有严格隔离,细节我们后面还会聊。
- 弗里达"重写一份新包裹给布鲁图"而不是"简单转发原包裹"的那个瞬间,正是反向代理的真实工作方式:它把一个对外会话,拆成了两个独立的会话,中间用应用层"粘"起来;不是一根管子直通。这个区别比听上去重要,我们后面会展开。
10 号与 11 号, 走廊与大楼:这些就是你在上一篇和本文里反复看到的 IP。弗里达的门牌是 10.88.0.10,布鲁图是 10.88.0.11,走廊网段是 10.88.0.0/16,主机(内核妈妈在走廊上的座位)是 10.88.0.1。大楼的公网地址,则取决于外界怎么看到这台主机。
那段"外界看不见"的弗里达与布鲁图的对话:这就是桥上的容器间通信。注意它没过 NAT,没走什么复杂路由,没碰外部接口。两间公寓,一条走廊,礼宾横向递包。便宜, 快, 对外隐形。这也是为什么 bridge 上容器互通飞快——内核几乎没离开底层。
两本"对上暗号"的账本:连接跟踪(conntrack)。内核记住每条活动连接以及为它做过的改写,让回复流量能完美"反解"回去,尽管改写当初是"单边"的。没有它,地球上没有任何 NAT 能工作;有了它,现代互联网(你家路由器每天为家里每台设备干的事)就能悄无声息地运转。

啊哈时刻

我那位饭搭子一听"互联网",脑海里大概飘过一根气动管道:这头塞东西,那头吐出来,中间是魔法。

可中间不是魔法。中间是一串小而笨而相同的角色,每个包裹只做一件小事情,彼此并不知情,也不关心内容。所谓"聪明",全在两端——浏览器小助手把每层地址写对,接收方把层层包裹拆开并回信。中间只是好心路人传纸条。

在写字楼里,这种"接力"继续。内核妈妈比任何一个接力员都复杂——她能改地址, 能路由, 能记账——但她本质上仍是一串小机器:门口收件,撕最外层,看地址,必要时改地址,查下一跳,重新包好,从正确的内门送出去。这是条流水线,不是魔法阵。只要你别把它想象成"一大步",就能把它整个装进脑子里。

在我脑中,第一声"咔哒"是交换机那一刻——它让我看清"一瞬间, 一地点发生了什么"。第二声"咔哒"是这台烤面包机的旅程——让我看清"一整段路上发生了什么"。两者拼在一起,就顺了。

我还没想明白的

故事里有个地方我悄悄糊弄过去了。

包裹到了弗里达那里时,我说"她的本地内核"剥了外衣,“她的门缝"收了快递,“她的桌上"放着原始包裹。看起来,弗里达似乎有她自己的小宇宙:自己的大门, 自己的 loopback, 自己的门牌, 自己的一切。

可弗里达不是一台单独的电脑。她只是跑在和内核妈妈同一台主机上的一个进程。整栋楼只有一个内核,只有一套硬件。

那弗里达的"公寓"究竟怎么"存在"的? 她如何拥有自己的内部地址, 自己的 loopback, 自己看见的走廊,却又互不踩到隔壁布鲁图的地盘? 同一个内核,怎么能并排跑出多套"平行网络世界”,而每一套都以为"世界里只有我”?

答案就是我在上一篇挥手路过, 这篇终于要扣的那枚扣子:network namespace(网络命名空间)。一旦它"咔哒"落位,你就会明白为什么容器"像是独立的小电脑"。它也是 VPN, 沙箱, 很多零信任网络的地基——也是我这整个系列慢慢铺垫的那个 bug 的底层缘由。

我会讲到的。我保证。

下回见——看我先掉进哪只兔子洞。

(人类撰写,必要处由 AI 协助润色)

交换机到底在做什么

Tue, 12 May 2026 00:00:00 +0000

这事儿我以前干过十几次,本该手到擒来。

思路很直:在笔记本上跑 Portainer(Docker 管理界面),远端服务器装 Portainer Agent,用 Cloudflare Tunnel 打通,让俩端点隔着 SSH(再套一层 Cloudflare Access)聊得不亦乐乎,外网啥都看不到。

所有零件我都摸过:SSH 隧道, Docker, Portainer, Cloudflare。没有新东西。

但这次,它罢工了。

远端 Agent 在听;本地 UI 在跑;我在终端里手搓 curl,两个端点都能打通。可一到 Portainer 的 UI 上点 Connect,直接给了我联网界最干净, 也最无情的报错:

Get "https://host.containers.internal:19001/ping": dial tcp 10.88.0.1:19001: connect: connection refused

connection refused。不是"打不通", 不是"没路由",而是有人在门口把门砰的一声给你摔上。

我盯着这个报错沉默了挺久。链路里每个环节单测都绿了:Agent 在听, SSH 隧道也绑好了端口, 笔记本上 curl 隧道端口通, Portainer 的容器也健康。

零件都没毛病。错误里倒是冒出了两个我平时从来不细想的东西:一个是我说不清来路的地址 10.88.0.1,另一个是我习惯性手就能敲出来, 但其实没想过含义的名字 host.containers.internal。

就在那一刻,我意识到问题在哪了。

老实交代

我这些年靠的是"背命令"。

会敲 ssh -L,知道能转端口;会写 docker run -p 9001:9001,知道能"暴露"端口;127.0.0.1 是 localhost,这谁不知道呢。用得多了,肌肉记忆就接管了大脑。真出问题了,也常常是 Stack Overflow 换个 flag 继续莽过去,完全没把"为啥"搞明白。

大学学过 OSI 模型,七层背得贼溜:物理, 数据链路, 网络, 传输, 会话, 表示, 应用。考试问我肯定能全答上来。但"网桥"和"路由器"的区别? 说实话,那会儿我真讲不明白。工作了好多年,也靠着上层抽象把活儿干了,下边几层就当不存在一样。

可它们真的在那,躺着不响。公司规模一大,需求往往就顺着蛋糕的切面往下探:反向代理, 流媒体, 多地域容灾, 零信任, 还有那句灵魂拷问"为啥开发环境行, 预发就不行"。每一个都戳在我一直糊弄过去的知识空洞上。

这次也是:容器里报 connection refused,目标明明是我笔记本上开的口子。错不在工具,错在我自己那点"差不多先生"式的心态。

所以我决定补课。

这是一篇开放式系列的第一篇。我不写教科书(世界不缺,作者也不该是我),我就盯着当前把我卡住的那一层,刨到不困惑为止,然后再往下一层挖。Portainer 这次的事故会作为主线,每篇都回到它。

等这个系列写完,开头那条报错应该能像读中文一样,一眼看懂。

而这篇要搞清的第一件事是:在这次问题所涉及的"最低那一层",到底发生了什么。10.88.0.1 到底是谁? 它跟 127.0.0.1 有啥区别? 所谓"桥(bridge)“到底是个啥玩意儿?

“等等,我电脑里头的网络,自己是咋转的? "

先说把我拍醒的那一巴掌。

远端 Agent 监听 19001;我把笔记本的 19001 用 SSH 隧道转到了远端的 19001;我在笔记本上 curl https://127.0.0.1:19001/ping,回得干干净净。

但同一台笔记本上, 跑在容器里的 Portainer Server,去连同样的地址,却得到"connection refused”。

同一台机器, 同一个内核, 同一个端口号,结果居然不一样?

怎么可能?

我先前的直觉模型是错的:一台电脑就"一张网”,不是么? “我的机器"要么能到,要么到不了。如果我在终端 curl 成功,那同一台机器上跑的别的东西也应该能成功。

这个模型从很久以前就不对了。现代 Linux 不是"一张网”,而是"网中之网"——在一个内核里拼出了好几张网。容器, 虚拟机, VPN, 乃至普普通通的 SSH 隧道,全靠这件事成立。只不过平时不需要想,直到有一天它以一种别扭的姿势坏给你看。

要解释为啥容器看不见我终端能看到的东西,我得从最笨, 最底层的那个家伙讲起:容器和宿主之间,那台"虚拟交换机"。

我用一个小剧场讲,稍微忍耐一下。演员阵容不大。

小剧场:会议室与递条子的前台

Margaret:会议室中间的前台,耐心无限,手里拿个小本本。一天到晚就干一件事:给桌子边的人传纸条。
Alice, Bob, Carlos:坐在桌边的三位同事。每人胸前都别着一张奇怪的名牌,比如 aa:42:81:9c:0e:33,机器印的,看着就不像给人类读的。
小本本:只记录"谁坐在哪个座位"。没人教她怎么记,都是她自己观察写下的。
纸条:对折的小条,外面写"要给谁"(名牌),里面写内容。Margaret 只看外面,不看里面。

故事开始。

会议室的一天

Alice 第一天来上班,挑了个空位——3 号,坐下。

Margaret 并不知道 Alice 的存在,小本本里也没 Alice 的记录。

过会儿,Alice 写了张"早上好"要给 Carlos,递给 Margaret。Margaret 看外面写的收件人是 Carlos,心里想"Carlos? 他在 7 号位",然后把纸条递到了 7 号。

走之前,Margaret 顺手扫了眼纸条外面的"发件人"——Alice 的名牌,又看了眼她刚拿纸条的座位,刷刷写进小本本: Alice(aa:42:81:9c:0e:33)— 3 号位。

十分钟后,Bob(5 号位)要给 Alice 写条子。Margaret 翻开本子,查到 Alice 在 3 号,稳准快送达。

这就是 Margaret 的理想工作流:她认识的人,翻一页就送到。

可如果在她"还不认识 Alice"的那五分钟里,Bob 突然要给 Alice 送条呢? 这会儿 Alice 还没发过任何纸条,Margaret 根本就没法在本子里查到她。

Margaret 会摊手, 然后干一件粗暴而有效的事:把这条纸条复印一堆,除了 Bob 的座位,其他每个人都发一份。谁是 Alice 谁就回,其他人看一眼不是自己的名牌,就丢纸篓里。

这就是 Margaret 的"全活"。两个动作:

查得到就直达(forwarding);
查不到就全发(flooding)。

而且每一条她经手的纸条——不管是直达的还是要全发的——她都会顺便学习:这条从 3 号位来的, 发件人名牌 aa:42:81:9c:0e:33——记上。新同事只要发过一条,Margaret 就知道他在哪了,而且不会记错——因为她只记录亲眼所见。

把戏拆穿:她在计算机里是谁

Margaret 就是一台交换机(switch)。在软件里也叫桥(bridge),算法一模一样。机房里那种金属盒子是硬件交换机;Linux 内核里的数据结构是软件网桥。行为一致。
“座位"是交换机的端口(port)——插网线的那个口。注意这可不是 TCP 端口,撞名了而已。
名牌是 MAC 地址。网卡出厂就刻着,长得就像 aa:42:81:9c:0e:33。
小本本是 MAC 地址表(MAC address table)。
查得到就送叫转发(forwarding)。
查不到就全发叫泛洪(flooding)。
她靠"看见谁从哪个口发出了帧"来自学习(MAC learning)。不配 DHCP, 不配配置文件,插上线发一帧,交换机就知道你在哪。

重点是:她从不看"纸条里写了啥”。不管上面跑 ARP, IP, TCP, HTTP,跟她都没关系。她只认"外面写给谁",不是就全发,是就直达。这也是为啥硬件交换机能用专用芯片一秒钟转发上百万帧:逻辑简单到不能再简单。

当 Bob 想找一个"他不认识的人"

问题来了:Bob 一开始连 Alice 的名牌都不知道,他怎么写外面的"收件人"?

回到剧场。

今天 Bob 收到个任务:“给管烤面包机订单的人递个条”。他不知道是谁,不知道名牌,不知道座位。

Margaret 帮不上忙。她的小本本只记"名牌—座位"的映射,不知道"谁管什么业务"。

但 Bob 有个招:他在纸条里面写"你好我是 Bob,名牌 bb:11:22:33:44:55,坐 5 号。谁管烤面包机请回信告诉我你的名牌"。然后,重点来了,他在外面的"收件人"一栏,不写具体的名牌,而是写:

FF:FF:FF:FF:FF:FF

这是一个保留的"特殊名牌"。没人真的佩戴它。它的意思是:大家都听着(broadcast)。

他把纸条递给 Margaret。Margaret 翻本子当然翻不到这个"名牌",于是走她"查不到就全发"的流程:除了 Bob 的座位,其他所有座位都发一份。

注意,这不是 Margaret 的"特判",而是 Bob 主动写了一个所有人都认得的"大家一起上"的目的名牌,逼着交换机走泛洪。交换机自己分不清这是不是 ARP,更不懂"烤面包机"是何物,她只是按规矩干活。

大家都收到复印件了,绝大多数人一看跟自己无关,扔了。只有 Alice——原来她就管烤面包机——认真看完回了一条,这次她把外面的收件人写成了 Bob 的真名牌,里面写:“你好,我是 Alice,我的名牌是 aa:42:81:9c:0e:33”。

Margaret 在把回条送回 5 号的同时,也顺手把 Alice 记进了本子。自此 Bob 知道了 Alice 的名牌,Margaret 也知道了 Alice 的座位,天下太平。

翻译回计算机:这套来回就是 ARP(Address Resolution Protocol)。那个 FF:FF:FF:FF:FF:FF 是广播 MAC 地址。协议的精髓就是:先用广播问"谁是 X 的 IP 拥有者",对方用自己的真 MAC 回;你记住它的 MAC,以后就可以直连。

两个常见"为什么会泛洪"的触发点,其实分别是:

交换机真不认识(MAC 表里没有),只好泛洪;
发送方故意把目的 MAC 写成广播地址,让交换机去泛洪。

(小彩蛋:FF:FF:FF:FF:FF:FF 全是 1 不是随便拍脑袋定的。MAC 地址第一个字节的最低位就是"组播/广播"标志,硬件只用一个按位判断就能快速认出"这玩意儿要大家一起看"。从设计之初就给硬件友好了。)

会议室变成"虚拟"的了

刚才说的是物理交换机的世界:铁盒子, 网线, 端口。

我笔记本上的那台交换机是"虚拟"的,跑在 Linux 内核里,叫 bridge。Docker 默认叫 docker0,Podman 默认叫 podman0。行为跟物理交换机一模一样:一本 MAC 表,两个动作,广播照做,其他一概不懂。区别只是:Margaret 入驻了内核,这间房间是内存里的数据结构,不是铜线和晶体管。

容器启动时,内核会造一根"虚拟网线"(veth pair),就像一根两头的线:一头塞进容器里,变成容器看到的 eth0;另一头插在 Margaret 的会议室里某个座位上。内核保证"一端进,另一端出",就是这么朴素。

关键点:宿主机自己也坐在 Margaret 的房间里。房间一搭好,内核就让宿主也占个座,配个名牌,再配个 IP。Margaret 不在乎谁是宿主, 谁是容器,反正都是戴着名牌的"人",她只按规矩转纸条。

在这一层,Docker/Podman 干的其实是三件无聊但重要的小事:

让内核建房(bridge);
容器启停时,用 veth 把它们插上/拔下;
确保宿主机也在房里有自己的座位。

至于"怎么转发",全是内核在干,容器运行时只是搭台。

这下我的报错顺了:10.88.0.1 是 Podman 这间房(podman0)里,宿主机那个座位的 IP。站在容器的视角,它就是"房里那个坐着宿主的口子"。host.containers.internal 不过是它的一个顺口的 DNS 别名(Docker 一样,只是常见的是 172.17.0.1,对应 docker0 里的宿主座位)。

但整栋楼不止这一个房间

既然宿主在 podman0 这间房里是 10.88.0.1,那 127.0.0.1 呢? 那个"本机地址"是啥?

127.0.0.1 是另一间房。

想象公司走廊的另一头,还有个超小的私人房间,只有一个座位——你的。房里也有个前台,叫 Lorraine。她的工作更简单:你给她纸条,她走两步又把纸条递回你手上。房里没人,纸条永远不会离开这个小房间。

Lorraine 是回环接口(loopback,lo,对应 127.0.0.1)。所有 Linux 主机都有这么一间"自言自语室"。

重点来了:宿主机同时坐在两间房里。它在 Margaret 的房里有个座(10.88.0.1),也在 Lorraine 的房里有个座(127.0.0.1)。不同房,不同前台,不同地址。

而当一个程序想"监听"某个端口时,它其实是在决定:把"门卫"安排在哪间房门口。监听 127.0.0.1,门卫就站在 Lorraine 的房里;监听 10.88.0.1,门卫就站在 Margaret 的房里;监听 0.0.0.0,那就每间房门口都站一个(只要宿主在那间房里有座)。

我的 bug 就卡在这一步。

我的 SSH 隧道在本地"开监听"(把 19001 口子开起来,进来的连接全转发到远端)时,默认把门卫安排在了 127.0.0.1。也就是说,门卫一直蹲在 Lorraine 的小黑屋里。

我在宿主上跑 curl https://127.0.0.1:19001/ping,那当然通——我是在 Lorraine 的房里敲门,门卫就在眼前。

可容器在 Margaret 那间大房里,它去找的是宿主在这间房的门——10.88.0.1:19001。容器的请求到了 Margaret 的房门口,敲了半天,门卫不在这屋啊! 这屋没人听,宿主在这间房的这个口子上没有监听,回答自然就是:connection refused。

解决方案一旦看清楚,简单得有点丢人:把 SSH 隧道的监听绑定到 10.88.0.1,或者干脆 0.0.0.0。反正让门卫出现在容器真正会来敲门的那间房就行。

但要走到"简单得丢人"的这一步,我得先知道"原来有好几间房"。要知道有房,得懂"bridge"是啥;要懂 bridge,得知道 Margaret 只干两件事。这就是为啥这篇要从这里开刀。

讲明白了吗?

比之前强多了,但还没圆满。

我现在知道了 10.88.0.1 为啥重要, 它跟 127.0.0.1 有啥本质区别。我能在脑子里看见 Margaret 的会议室:容器占一个座, 宿主占一个座,前台按"名牌—座位"把纸条转来转去,不懂上层协议。也知道为啥"只在某个接口上监听"的服务,会对来自另一间房的敲门视而不见。ARP 也不再神秘了:只是 Bob 用"大家一起看"的目的 MAC 问了一嗓子,交换机忠实地泛洪,因为它只会干这件事。

但一个更大的问号冒出来了:上面的故事默认"容器有自己的网络栈,可以插到 Margaret 的房里"。可容器归根结底只是跑在同一个内核里的进程,它怎么会"有自己的一块网卡, 一个 IP, 甚至有自己的一间 Lorraine 小黑屋的 127.0.0.1",而且跟宿主的 127.0.0.1 互不干扰?

再想想——我总说"容器是隔离的"。到底隔离的是什么? 用的是什么机制? 内核里哪一层在实施这个隔离?

一个坑刚填平,下面就是个更大的坑。

答案是 Network Namespace。它让一台 Linux 机器在内核里"分身多用",同时跑出很多套"自以为是全世界的网络栈",每一套都有自己的 127.0.0.1。容器, VPN, 很多现代基础设施的魔法,都栖身于此。一旦这个概念卡进脑子,前面提到的 veth 从比喻,变成了看得见摸得着的"管子"。

下篇见,我们从这里开始挖。

(人类写作,必要处参考了 AI 的点子与润色。)