通过“分布式系统的8大谬误”反思APP的设计 第二篇 谬误2：网络没有时延

就在今天上午，我的系统的网络请求时延高达544毫秒到6937毫秒之间。而且这是在一个已激活的网络接口上。如果接口从省电模式开始激活的话，这还额外需要10秒钟的时间。因此为了提供良好的用户体验，App需要考虑至少十几秒的网络时延。

假如在app发起用户认证请求后，只有请求成功用户才能进入登录页面，这时已经过去7秒。如果接着App需要再发一条请求获取用户信息，那么用户被阻碍在登录页面总共多达14秒。所以我会尽可能打破这种必须前后按序发生的请求。

实际操作中，我会同时发送多个请求；尤其是有些请求，不占用太多带宽，但是对时的性能要求很高。按应用的不同，这会使用到HTTP pipelining机制，或使用队列机制来管理同时发送的多个请求。需要注意的是，我们不能保证服务器按请求发送的顺序进行处理。所以服务器可能会收到一个删除信息的请求，而实际上服务器收到创建信息的请求。在最近的一个应用开发中，我们会在所有请求中填入序列号，服务器端会有个队列保存收到的请求。如果处于发送对列中间的某个请求还没收到，服务器是不会处理其之后的任何请求，保证了请求可以按顺序处理。

最后需要考虑到的是，由于时延太大，当前用户可能都切换到其他页面或其他任务。通常的做法是view controller在被销毁或从屏幕上消失时，会同时终止由它发出的请求。一般情况下，这个做法很管用。不过，不耐烦的用户会不断来回切换页面，导致每次页面被打开的时间都不长。所以我更加喜欢使用一个不含视图的controller 负责管理请求，以及更新app的model层内容。

测试：创建不同网络时延的测试环境
上一章节，我提到过使用Charles设置本地代理，来测试不同的网络条件。Charles还可配置网络时延，从而可以测试设备和服务器间传输时延。

英文原文地址：http://blog.carbonfive.com/2010/11/17/fallacy-2-latency-is-zero/