
一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
Slack 拒收。Drive 要走文件夹分享请求。邮件上限 25 MB。两条 curl——一条在你的笔记本上,一条在他们那边——把文件从磁盘搬到磁盘。管道把字节穿过去;什么都没上传到服务器。
GET 和 PUT 同一路径。Hoody Pipe 把先连上的那一端守住最多五分钟;另一端一出现,字节就直接流过去。服务器磁盘上不写任何东西。
# from your laptopcurl -T dump.sql \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
PUT(或 POST)带流式 body。管道建立时服务器把状态行打回来——可以当作另一端真的接上了的一个实时信号。
# on their boxcurl \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday \ -o dump.sql# 4.2 GB · saved · done.
在同一路径上 GET 会阻塞,直到发送端连上。发送端写入的字节作为响应体出现——用 -o 保存到文件,或者直接接到任何能读 stdin 的程序。
顺序无所谓。如果你先跑 curl,请求会一直阻塞到对方连上。如果他们先跑 curl,他们的会阻塞。无论哪一边,一旦双端都连上,字节就开始流动。
从 Slack 上的提醒到文件落到对方磁盘——管道做的四个动作。
「能把昨天的生产 dump 发我吗?」文件 4 GB。Slack 拒收,共享盘要走文件夹分享工单。两个你都不再去碰。
curl -T dump.sql …/pipe/dump-yesterday你的终端打出「Waiting for 1 receiver to connect…」就停在那。你把 URL 贴进聊天:「跑这条。」
curl …/pipe/dump-yesterday > dump.sql他们一连上,管道就建立。字节从你的磁盘穿过管道流进他们那边的文件。
Transfer complete · 0 bytes on server服务器端磁盘占用始终为零。两端断开的瞬间,管道路径忘了这次传输发生过。
你为 Drive 来回走一遍要敲的命令数和这一样——少了登录、少了上传条、少了链接、少了清理。
Hoody Pipe 是一个流式中间体,不是文件服务。文件就在你的磁盘上,也在他们的磁盘上。中间只是字节在飞,速度由你们两边的网络能撑多少决定——管道只是转发。
公共部署上的管道路径不需要鉴权。它们是限定单次传输的可寻址 URL;两端一断开,路径就消失。接收方什么都不用注册。
传输从不落到服务器磁盘上。没什么要清理、没什么要泄漏、没什么会过期。字节在你笔记本上;然后也在他们那边;路径忘了它存在过。
两条 curl。无登录。无上传条。完成。
「把那个文件发我」过去意味着一个标签页、一次登录、一次上传、一条链接、一次粘贴、一次下载。现在它意味着:敲 curl,粘 URL,再跑 curl。这是你能输入的最快版本。
我们以前用来发一份 4 GB 文件的大多数工具,都是过去无法在两个终端之间通过 HTTP 流式传字节时留下的遗物。管道让它们全都没必要了。
两条 curl。文件到对方机器上了。什么都没上传过。