在过去的几周里，我进行了一些模拟和测试，以了解当今万维网的延迟容忍度，以及假设未来的火星宇航员有足够的带宽，他们是否可以从火星上实际使用互联网。 结果并不令人惊讶。今天的万维网对延迟并不友好。矛盾的是，许多最新的发展，更准确地描述为现代客户端API驱动的网络，使这个问题变得更糟而不是更好。多平面世界必须有多平面万维网。尽管存在极端的延迟，但它必须在火星和其他行星上保持可用性。 首批火星宇航员可能依靠应用层网关访问一小部分核心服务：电子邮件、即时消息、在X上阅读和发布，甚至观看YouTube。这些网关可以聚合请求、积极缓存、转换协议，并在批处理和延迟容忍交付后隐藏延迟。这种方法会奏效，但它从根本上来说是一种权宜之计，一种适应层，旨在保护以地球为中心的应用程序免受它们从未设计过的现实的影响。 但网络并非一成不变。在史蒂夫·乔布斯于2007年推出移动友好型网络应用程序之前，万维网也没有为iPhone或智能手机做好准备。我们适应了一次，我们可以再次适应。长期解决方案不能仅依赖网关。它必须涉及重新思考web应用程序本身的设计方式。 一个对火星友好的网络应用程序不能假设网络是快速、可靠的，甚至是持续存在的。往返时间以分钟为单位，熟悉的点击节奏→ 请求→ wait → 反应崩溃。一旦光速成为瓶颈，任何依赖于即时服务器反馈进行日常操作的设计都会停止工作。 火星友好的网络应用程序不会将网络视为同步函数调用，而是将其视为延迟通信。用户操作首先在本地提交，记录为持久操作，然后在连接允许时进行同步。接口会立即响应，因为它是由本地状态驱动的，而不是由服务器权限驱动的。服务器变成了一个副本和协调的权威，而不是每次交互的看门人。在这种模型中，重试是正常的，消息是幂等的，如果同一操作到达两次或延迟到达，则没有任何中断。 这种转变迫使建筑更加诚实。验证、权限，甚至部分业务逻辑都必须更靠近客户端，由服务器解决冲突，而不是微观管理意图。数据流是增量而不是完全重新加载，工作流的设计是为了容忍不确定性，而不是假装不存在。最终一致性不再是边缘情况，它是现实的默认状态。 具有讽刺意味的是，为火星建造会在地球上产生更好的软件。应用程序感觉更快，因为它们停止了网络阻塞。故障变得可以生存，而不是灾难性的。用户获得的是代理权，而不是旋转器。设计星际延迟并不是科幻小说的放纵。这是一门去除偶然复杂性并迫使网络成长的学科。