跳转到内容
use-cases / fastest-send-me-that-file / hero
PIPE · 分享流 · 文件传输

你能输入的最快「把那个文件发我」

Slack 拒收。Drive 要走文件夹分享请求。邮件上限 25 MB。两条 curl——一条在你的笔记本上,一条在他们那边——把文件从磁盘搬到磁盘。管道把字节穿过去;什么都没上传到服务器。

阅读 Pipe API 文档
use-cases / fastest-send-me-that-file / flow

一条管道路径。两条 curl。无中间文件。

GET 和 PUT 同一路径。Hoody Pipe 把先连上的那一端守住最多五分钟;另一端一出现,字节就直接流过去。服务器磁盘上不写任何东西。

pipe.containers.hoody.com/dump-yesterday
PUT · SENDER

把文件从 curl 推出去

# 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。管道建立时服务器把状态行打回来——可以当作另一端真的接上了的一个实时信号。

GET · RECEIVER他们

把文件直接拉到磁盘

# on their boxcurl \  https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday \  -o dump.sql# 4.2 GB · saved · done.

在同一路径上 GET 会阻塞,直到发送端连上。发送端写入的字节作为响应体出现——用 -o 保存到文件,或者直接接到任何能读 stdin 的程序。

n=1 · 默认 1 对 1 传输管道最多等 5 分钟服务器存 0 字节

顺序无所谓。如果你先跑 curl,请求会一直阻塞到对方连上。如果他们先跑 curl,他们的会阻塞。无论哪一边,一旦双端都连上,字节就开始流动。

use-cases / fastest-send-me-that-file / steps

实时看起来是这样

从 Slack 上的提醒到文件落到对方磁盘——管道做的四个动作。

Slack 提醒 → 文件到对方机器上FOUR STEPS · ONE PIPE
10:14 · PING01

队友要文件

「能把昨天的生产 dump 发我吗?」

文件 4 GB。Slack 拒收,共享盘要走文件夹分享工单。两个你都不再去碰。

10:14 · PUT02

你 curl -T 把文件推出去

curl -T dump.sql …/pipe/dump-yesterday

你的终端打出「Waiting for 1 receiver to connect…」就停在那。你把 URL 贴进聊天:「跑这条。」

10:15 · GET03

他们 curl 那个 URL

curl …/pipe/dump-yesterday > dump.sql

他们一连上,管道就建立。字节从你的磁盘穿过管道流进他们那边的文件。

10:15 · DONE04

文件到对方机器上,什么都没留下

Transfer complete · 0 bytes on server

服务器端磁盘占用始终为零。两端断开的瞬间,管道路径忘了这次传输发生过。

use-cases / fastest-send-me-that-file / reasons

为什么 curl 比分享更胜一筹

你为 Drive 来回走一遍要敲的命令数和这一样——少了登录、少了上传条、少了链接、少了清理。

NO UPLOAD

没有进度条要看

Hoody Pipe 是一个流式中间体,不是文件服务。文件就在你的磁盘上,也在他们的磁盘上。中间只是字节在飞,速度由你们两边的网络能撑多少决定——管道只是转发。

NO LOGIN

无账号、无文件夹分享、无 IT 工单

公共部署上的管道路径不需要鉴权。它们是限定单次传输的可寻址 URL;两端一断开,路径就消失。接收方什么都不用注册。

NO RESIDUE

服务器永远存零字节

传输从不落到服务器磁盘上。没什么要清理、没什么要泄漏、没什么会过期。字节在你笔记本上;然后也在他们那边;路径忘了它存在过。

use-cases / fastest-send-me-that-file / punchline

两条 curl。无登录。无上传条。完成。

「把那个文件发我」过去意味着一个标签页、一次登录、一次上传、一条链接、一次粘贴、一次下载。现在它意味着:敲 curl,粘 URL,再跑 curl。这是你能输入的最快版本。

  • 无上传
  • 无链接要分享
  • 两边都不用登录
阅读 Pipe API 指南
use-cases / fastest-send-me-that-file / replaces

它替代了什么

我们以前用来发一份 4 GB 文件的大多数工具,都是过去无法在两个终端之间通过 HTTP 流式传字节时留下的遗物。管道让它们全都没必要了。

  • Dropbox登录、手动分享、等同步
  • Google Drive走 IT 的文件夹权限工单
  • Slack 文件上传硬性大小上限,然后「请用一个真链接」
  • WeTransfer邮箱门槛、广告页、谜之保留期
  • AirDrop(跨网络)只能同一 Wi-Fi,远程的瞬间就失败
  • Firefox Send已停服,没再回来
  • 自建文件分享自托管的盒子、桶,加一个被遗忘的清理 cron
use-cases / fastest-send-me-that-file / cta

两条 curl。文件到对方机器上了。什么都没上传过。

阅读 Pipe API 指南
use-cases / fastest-send-me-that-file / related

阅读其他内容