三、网络的潜力

　　互联网时代的伟大就在于世界各地所有的计算机互相联系，就象在一个非常大的计算资源之中。远程和本地过程调用变得很难区分，并且发行者已经不再清醒地了解它们在哪些物理机器上工作。

　　不幸的是，远程和本地过程调用是根本不相同的技术。

　　在网络上的通讯是昂贵的(它们是慢并且不可靠的)。当一部分非网络代码被编译或解释时，各种方法和函数就象在其上操作的数据一样被编码为存储在相同的本地内存中的指令(图6)。这样，把数据传递给一个方法并返回结果就相当直接。

　　其实在底层，为了发送和接收数据，很多计算运行于一个网络连接的两端(图7)。实际上，这种计算远不如沿着物理线路的运行更导致系统的减慢-各级的编码与解码遍及通讯的各个方面，从沿着线路传输的物理信息，把这些信息翻译为二进制的1和0，错误检查和重发送，到重新整合该二进制序列。
　　调用函数的请求必须被编码为一个稍后将被串行化的对象（也即，被转换成一个线性字节集合）。然后，被串行化的数据被传递到应用程序协议（现在通常为HTTP）并且通过物理传输发送。

　　在远程机器上，该应用程序协议被解码，并且数据的字节被反串行化以创建该请求对象的一个副本。然后，这个对象被应用到数据模型和一个生成的响应对象上。为了联系该响应和调用函数，该串行化和传输层必须被再一次导航，最后导致一个响应对象被返回到调用函数。

　　这些客户端是复杂的但是适合于自动化实现。现代的编程环境例如Java和微软.NET框架都提供了这种功能的自由使用。尽管如此，当产生一个远程过程调用(RPC)时，在内部有大量的活动在进行并且如果这样的调用太自由的话，性能也会受到影响。

　　因此，通过网络的调用永远不会象调用本地内存中的一个方法那么富有效率。而且，网络的不可靠性（并因此需要重新发送失去的信息包)也使得这种低效在不断变化且很难预测。在你的本地机器上的内存响应性不仅更好一些而且相比之下可以被很好地定义。

　　这但与可用性有什么关系呢？已证明，其关系相当大。

　　一个成功的计算机UI的确需要模仿我们真实的世界期望。该交互的最基本原则之一是，当我们点按某东西时，它能够立即响应。在点按和响应之间的轻微的延迟都会带给用户迷惑并使之分神-把用户的注意力从手头的任务转移到UI本身。

　　必须做所有的额外工作来穿越网络常常就足已减慢一个系统，以至于该延迟变得相当引人注意。在一桌面应用程序中，我们需要做出糟糕的可用性设计决策来使得应用程序感觉起来充满错误或不具有响应性，但是在一个联网应用程序中，不需要我们关心这些！

　　由于网络潜力的不可预测性，这种可察觉的错误来来去去，并且测试应用程序的响应性也可能变得更为困难。因此，网络潜力是真实世界应用程序具有可怜的交互性的最通常的原因。