端到端原则End-to-End Principle

只有两端掌握完整条件时，最终正确性就必须由两端保证。

WhatsApp 自己也读不到用户的聊天了。2016 年 4 月，美国加州山景城的这家公司宣布完成一项改造。创始人扬·库姆带领的团队，让最新版应用的聊天默认加密。消息在发送者的手机上加密，到接收者的手机上才解开。服务器照样转发消息，却拿不到解密所需的密钥。如果只加密手机到服务器这段路，服务器仍能读到内容。要把转发消息的公司也挡在对话之外，保护就得从说话的人一直覆盖到听话的人。

为什么成立

网络把数据送对，接收程序仍能把文件存错。设想你把一份合同发给客户：传输毫无差错，客户电脑却在写入硬盘时损坏了文件。沿途设备都报告“我这一段没出错”，这些报告却覆盖不到最后的写入。

中间层缺少完整条件时，最终保证必须放在应用两端。这就是端到端原则。两端在哪里，由任务的完成标准决定。若目标是文件完整落盘，终点就是接收端存好的文件。若目标是订单被接受，终点就是商家的订单记录。中间层知道消息已转交，应用两端才知道什么结果算完成。

最终检查必须覆盖整条路径，并让失败触发补救。发送端先根据原文件算出校验值，作为比对依据。接收端存好文件后，再读出文件，重新计算校验值。双方比对结果，发现差错就重传，通过检查才报告完成。这轮检查能发现传输之后的存储差错，逐段检查覆盖不到那里。

中间层的检查值得保留，只要它能减少返工。链路发现坏包就立即重传，应用便能少重传整份文件。中间层因此改善效率，两端仍负责验收结果。

把应用专属的保证塞进公共网络，会让其他应用也付出成本。文件传输关心字节完整，订餐应用还关心菜品和地址。公共网络无法替每种应用判断任务是否完成。让应用保留最终检查，公共网络才能为不同任务提供共同的传输服务。

出处

端到端原则来自计算机网络与分布式系统。1981 年，杰罗姆·萨尔策、戴维·里德和戴维·克拉克提出这一论证。1984 年发表的修订版题为《系统设计中的端到端论证》。论文以可靠文件传输为经典案例：逐段传输正确，仍不足以保证接收端保存的文件正确。

换个领域看

商业

发推还不算下单

订餐内容要由顾客和餐厅核对，转发平台只能送消息。2015 年 5 月，达美乐在美国推出发披萨表情推文订餐。顾客先保存常用订单，发推后再收到达美乐的私信确认。Twitter 能证明推文已发布，达美乐和顾客才能确认这次要买什么，并完成下单。

投资

收益算到自己手里

投资结果要核对到自己实际赚到的钱。假设你年初投入一万元，年内没有追加或取出。年底基金份额值一万一千元，你还另付了一百元账户费用。基金涨了百分之十，你的净收益却是九百元。基金记录提供份额价值，你的账本补上额外支出，两头接起来才得到个人净收益。

个人生活

接到孩子才算完成

接送安排要确认到真正执行的人和实际结果。设想你请亲戚下午四点去校门口接孩子，托家人转告。家人回复“发了”，亲戚却仍以为是三点。让亲戚直接回复接送时间和地点，接到孩子后再报平安。中间人能证明自己传过话，你和亲戚才能核对安排与接送结果。

遇事时问自己

这件事做到哪一步才算完成，谁能直接看到结果？
中间层报告成功后，还有哪一步会把结果弄坏？
判断结果所需的信息，哪些只在发起者或最终接收者手里？
两端怎样核对结果，发现失败后由谁补做或重试？
中间层增加检查能省下多少返工，又让哪些使用者承担成本？

边界与误用

中间层缺少必要信息、或覆盖不到完整路径时，端到端原则才要求两端保留最终保证。最常见的误用是撤掉沿途检查：无线链路就地重传坏包，能减少整份文件重传。若任务只是保护某段线路，负责该线路的设备已有完整信息，就该在那里处理。两端的验证也只能保证约定的目标：手机被入侵，聊天明文会从手机泄露；原合同写错，完整传输仍会送达错误内容。跨领域使用时，应让掌握结果的人参与验收，同时保留服务方的交付责任。

练一练

公司更换员工权限系统。迁移程序已把旧配置送到新系统，并报告成功。但新系统会把某些岗位映射成权限更大的默认角色。项目约定：迁移后，每个人能访问的资料范围保持原样。

哪一步最能支持宣布迁移完成？

你委托券商用一笔到期资金买入国债，目标是指定数量的债券登记到你的账户。页面显示“指令已送达”，但资金余额尚未减少，持仓也没有增加。券商提示，成交与持仓更新可能有延迟。

此时哪种判断最站得住？

家中一段明管接头漏水。维修约定：更换后的这段管道，在规定压力下保持三十分钟不漏就算合格。师傅隔离该段两端，用压力表完成测试，并留下记录。你提出，必须等全家连续用水一周，才能验收这段维修。

对这个提议，哪种判断最站得住？