大西洋上空的十一个小时 ELEVEN HOURS OVER THE ATLANTIC SEAT 24B WATCHES A FILM AGAIN SEAT 24C REVIEWS FOUR SERVERS GEO ADDS 703 MS TO EVERY KEY MOVE THE WORK NOT THE KEYSTROKES

十一个小时，从纽约飞往东边的某处。客舱灯光转成琥珀色。24B 座打开椅背屏幕，翻过四百部片子的 目录，选中了一部他已经看过三遍的电影。这不是批评。在一根加压的铝管里消磨十一个小时， 这是最合情合理的一种做法，我们大多数人都这么干过。

24C 座掏出一部手机。

两个座位连的是同一个 Wi-Fi，离地面一样远。等到起落架接地时，其中一个看完了一部台词都能背下来的 电影，另一个合并了三个分支、清掉了一整套失败的测试，还把四千英里外一台机器上卡住的任务重启了。

有意思的不是这件事做得到，而是它为什么做得到——以及为什么那个显而易见的做法， 就是大多数人试过一次、然后在格陵兰上空某处放弃的那个做法，根本行不通。

航空公司说「Wi-Fi」的时候，可能指的是两种截然不同的东西，而你这架飞机的机身上焊着的是哪一种， 决定了后面的一切。

老一套是一颗地球静止轨道卫星，停在 35,786 km 的高度。那个高度不是谁为了你的 方便挑的；它恰好是绕一圈需要二十四小时的距离，于是卫星看上去悬着不动。后果是一道任何工程预算 都吵不赢的算术题：上去再下来，来回两趟，光本身就要 477 ms 的往返， 这还没算上任何一台路由器。

新一套是一整群低地球轨道卫星，大约在 550 km ——近了大约六十五倍，往返传播时延 7.3 ms。

空中实测和物理对得上。对 Ookla 2025 年第一季度机上测速数据的分析发现， Starlink 的往返时延中位数是 44 ms，而 Hughes、Intelsat 和 Viasat 是 703–757 ms ——差距大约十六倍。另一支团队为 ACM IMC 2025 在 7 家航司的 25 个航班上给真实设备 装了探针，独立测出了同样的形状：LEO 低于 40 ms，GEO 高于 550 ms。

对一次跨洋长途来说，诚实的数字比标题稍差一点。同一项研究测得 太平洋上空的中位数是 62 ms，区间 19–86 ms。这才是该记在脑子里的那个数。 它依然出色。但它不是 44。

按惯例，产品站上的博客文章写到这里，该告诉你未来已经到了。

它到得并不均匀，而最后轮到的那批飞机，正是你坐的这批。

窄体机先改装——数量多、周转快，飞的是国内短途，没人打算在上面连着干十一个小时的任何事。 真正跨洋的宽体机排在队尾。截至 2026 年年中，United 已有 400 多架飞机装上 Starlink， 并预计年底接近一千架——但其中只有大约 六十架是宽体机，它第一班装了 Starlink 的 宽体跨大西洋航班（纽瓦克—希思罗）迟至 2026 年 6 月才执飞，整个宽体机队要等到 2027 年夏天才完工。Virgin Atlantic 已经做完了它的 十二架 A350 ——大约是宽体机队的 28%——787 排在 2026 年下半年，A330neo 排到 2027 年。

所以：如果你是在 2026 年的一趟洲际航班上读到这篇文章，概率仍然不站在你这边。 你多半连的是那条 700 ms 的链路，而不是 62 ms 的那条。

而这让本文余下的部分更有用，不是更没用。

电影和 shell 在相反的方向上失败，而机上 Wi-Fi 恰好是其中一个最不该碰上的网络。

电影是带宽问题，它不在乎时延。它会缓冲。第一帧晚到 700 ms 谁也不会察觉， 因为这段体验里没有任何东西取决于电影对你的反应。按下播放，等一会儿，看。往返只发生一次。

交互式 shell 正好是它的镜像。它几乎不需要带宽——一个终端会话的量级是千比特，不是兆比特—— 但你每敲一个指望回显出来的键，都要付一趟往返。在 700 ms 下，这不叫连接慢， 这叫每打一个字都要停顿三分之二秒的对话。

这就是大家想错的地方。他们在机上门户页面看到「50 Mbps」，断定连接没问题，打开一个终端， 然后发现「没问题」跟这事毫无关系。这里的货币不是带宽。是往返次数。

这个失败比「感觉很慢」要具体得多，而研究对痛点落在哪里说得异常清楚。

在一项 31 名被试、对比端到端输入时延 20 ms 与 200 ms 的对照实验里， 成段打字几乎没动：每字符 290.9 ms 对 302.7 ms，作者认为这个差异称不上显著。 错误率完全一样。

但纠错任务——用方向键把光标挪回去改文字，也就是你在编辑器里真正在做的那件事—— 从 38.9 秒变成 46.5 秒，慢了大约 20%，效应量非常大（p < 0.001，d = 1.673）。 作者把机制说得很直白：在移动光标的过程中，你不得不一直等屏幕， 因为光标落在哪里决定了你下一步做什么。

即使速度没变，主观负担也在变糟。在打字任务上，尽管成绩在统计上没有差别， 自评挫败感仍然从 20.9 升到了 31.3。

把这些换算到终端上，它精确点出了在高空散架的是什么：不是把一条命令敲出来。是 vim 里的移动、Tab 补全、在 less 里翻页，还有 REPL 那种戳一下、 看一眼的节奏。这里每一样都是一个循环：你下一步做什么，取决于刚刚返回了什么。

一旦你接受往返次数才是稀缺资源，解法就不再是「换一架更快的飞机」，而变成一个架构问题： 少走几趟往返，并让每一趟运得更多。

有个众所周知的工具正面硬刚这件事。Mosh 会预测你的按键将产生什么效果，抢在服务器确认之前就在 本地回显出来。实测效果相当惊人：在往返时延约半秒的链路上，按键响应中位数从 503 ms 降到 5 ms 以内。在一条从 MIT 到新加坡的跨洋路径上， 从 273 ms 降到 5 ms 以内。

但要读小字，因为小字才是重点。Mosh 能预测大约 70% 的按键。剩下大约 30% 预测不了的部分，用作者自己的话说，主要是导航——对这部分而言，它的时延曲线又变回了 普通 SSH 的样子。也就是说：被高时延罚得最狠的那种交互，恰恰是本地回显救不了的那一种。

所以预测有帮助，但救不了你。真正能救你的，是拒绝那么频繁地待在循环里。

别再对着时延打字。把耗时的活儿放到远端，然后去看它一眼。 一次构建、一套测试、一次数据迁移、一个编程智能体——这些都不需要你陪着走完往返。 它们只需要你在开头出现，在要做决定的时候出现。中间的一切是机器的事， 而机器在地面上，连着一条好网。

这也是为什么在高空里并行胜过交互。你没法在 700 ms 里打字如飞， 但你完全可以同时盯着四台服务器，因为盯梢不受时延约束——它受注意力约束， 而你有整整十一个小时的注意力，且无处可花。

具体到一部手机、一条糟糕的链路上：

这些都不是为飞机发明的。在一条恶劣链路上远程干活，向来就是这个样子， 而飞机只是一条格外诚实的恶劣链路。

有两件事我们没能核实，也不打算假装核实过：

你所在航司的网络到底放不放 SSH 出去。关于各家机上 Wi-Fi 服务商的端口封锁、 VPN 政策和空闲超时，我们找不到可靠的公开证据——倒是有一大堆语气笃定、一查就站不住的论坛说法。 它因承运人而异、因服务商而异、因机型而异。在你围着它安排一趟长途之前，先在短途航班上试一试。

客舱里的时间实际花在了哪儿。被引用最多的那些机上娱乐统计数字， 追下去竟然出自没有任何方法论的广告刊例，我们把它们扔了。我们找到的最好的问卷证据—— Inmarsat/Censuswide，十个国家 11,231 名乘客，尽管调查是 2022 年做的，问的又是意愿而不是实测 时间——显示娱乐大幅领先于工作：41% 想看已下载的电影，35% 想在线看， 想干活的占 26%。

所以，请把 24B 座当成一个人物，而不是一个统计量。重点从来不是看电影有什么不对， 而是另一个选项已经不再是「没得选」了。

电影在它前三次结束的地方结束了。飞机开始下降。24B 座度过了一趟相当不错的飞行， 落地时精神饱满，这也值点什么。

24C 座落地时活儿已经干完了——因为活儿从来就不在座位上。它自始至终都在地面的一台机器上， 手机不过是望向它的一扇窗。

十一个小时，耗在 700 ms 上是很长的一段时间；用来盯着四台压根不在乎那颗卫星的服务器， 则短得很。