关于Web应用中的网络延迟和异步交互

网络延迟

因物网的宏伟蓝图是将这个世界上所有的计算机都连接起来，形成一个无比巨大计算资源。如果能把本地调用和远程调用等同起来，那么无论是分析蛋白质的成分还是破解外太空的信号，使用者都无需考虑机器的物理位置，剩下来的只有愉快地计算。

但是非常不幸，本地调用和远程调用是完全不同的东西。在现有的技术水平之下，网络通信仍然是一件代价高昂的事情（也就是说，通常很慢，而且并不可靠）。在没有网络调用的情况中，不同的方法和函数以及它们所操作的数据都位于相同的本地内存中，向方法内传递数据并且获得方法的返回结果是非常直接的。

而在有远程程调用的情况下，位于网络两端的通信双方为了发送和接收数据在底层需要进行在量计算。比起数据在线路上的往返，这些计算需要消耗更多的时间。传输一段二进制的数据，中间要经过很多环节的编码和解码、错误校验、失败重发、数据包拆分和重组，数据最终转化为0和1表示的二进制信号，通过线路（或者无线连接）到达另外一方。

在本地，调用函数的调用请求被编码为一个对象，然后将这个对象序列化为一系列字节，最后使用应用层协议（通常是HTTP）通过物理传输介质（例如铜缆、光纤或者无线电波）将其发送出去。

在远程机器上，对应用层协议解码，将获得的数据字节反序列华，创建一个请求对象的副本。然后对数据模型应用这个对象并生成一个响应对象。为了将响应对象传递给本地的调用函数，所有序列化、返序列化以及转输层的操作都要返向再来一次。最后，响应对象被传递给本地的调用函数。

一个成功的计算机用户界面要能以最起码的水平模拟我们在真实世界中的体验。交互的基本规则之一就是，当我们推一下、剌一下或者捅一下某个东西的时候，它立刻就会响应。响应的时间只要稍微拖长一点点，就会使人困惑，分散其注意力，把关注点从手头的任务转移到用户界面上。

远程调用横穿整个网络，需要执行大量的额外操作，它们往往会把系统拖慢，使用户察觉到延迟。在桌面应用中，只有当可用性设计做得非常糟糕时候，才会出现这种令用户感觉充满bug、反应迟钝的用户界面，但在网络应用中，什么都不做就能得到大量这样的界面。

因为网络延迟不可预测，这类界面问题往往都神出鬼没，对应用响应的测试也难以开展。换句话说，网络延迟是导致实际应用的交互性糟糕的一个普遍原因。

异步交互

用户界面的开发者对于网络延迟只能做最坏的假设。简单地说，就是要尽可能让用户界面与网络活动无关。天才的程序员们是已发明了一种确实有效而且久经考验方案，来专门解决这一问题。

网络延迟问题和相关的解决方案由来已久。在老的客户/服务器模式中，当设计不佳的客户端程序碰上了高负载的服务器时，用户界面就会出现让人难以忍受的延迟。即便是在如今的因特网时代，当切换页面时，如果浏览器半天不出来东西，那么这种糟糕的情况很可能就是因为网络延迟造成的。在现有技术条件下，我们暂时还没有办法消除网络延迟，但是至少有一个对策，那就是采用异步方式处理远程调用。

对于Web开发人员而言这样做存在一个难点：HTTP协议是一个“请求 - 响应”模式的协议。也就是说，客户端请求一个文档，服务器要么返回这个文档，要么造诉客户端找不着文档或者让客户端去另外一个地方找，还可以造诉客户端可以使用它的本地缓存，诸如此类。总而言之，“请求 - 响应”模式的协议是一种单向的通信协议。客户端可以向服务器发起连接，但是服务器不可以向客户端发起连接。甚至，当客户端下次发起通信请求时，健忘的服务器都记不起来这个客户端是谁了（HTTP是无状态连接）。

多数Web开发都使用现代的编程语言，例如，Java、PHP或者.NET，他们熟悉用户会话（user session）的概念，这其实是应用服务器对于不能保持连接状态的HTTP协议的一种补救措施。HTTP就其最初的设计目的来说表现得非常好，采用一些巧妙的处理，它能够适应设计之初没有考虑的场合。但是我们的这个异步回调方案中的关键特征是，客户端会收到两次通知，一次是在线程创建的时候，另一次是在线程结束的时候。标准的HTTP和传统Web应用模型可不会提供这些。

使用模式

实际上，Alan Cooper 从行为的立场出发，总共定义了四种软件姿态（software posture），分别是：独点是：独占（sovereign）、瞬态（transient）、精灵（daemonic）和辅助（auxiliary）。瞬态应用需要能够提供良好的用户体验，但是用户仅在自己原有工作流程之外偶尔使用一下，使用中的一点瑕疵是可以接爱的。与此形成鲜明对比的是独点应用。它是为长时间的密集使用而设计的，其界面必须设计得近乎隐形，以免干扰用户集中于手头任务的注意力。