移动网络性能的秘密

引言

过去的几年，我们已经在移动蜂窝网络性能方面取得了巨大的进步。但是，由于膨胀的网络延迟，许多移动应用却不能从中得益。网络延迟已经伴随移动网络很长时间了。尽管最近几年已经有所进展，但网络延迟降低的速度仍然没能跟上网速提升的速度。这种不一致带来的结果是，延迟，而不是吞吐量，常常是网络传输性能的限制因素。

本文逻辑上分为两个部分。第一部分将探讨引起网络延迟问题的移动蜂窝网络特性。第二部分将介绍最大限度减少 高网络延迟对（elevated network latency） 性能影响的软件技术。

你在等什么（What are you waiting for）？

延迟是指一个数据包跨越一个或多个网络传输所需要的时间。多种因素使移动网络加剧了基于互联网的通信中已经存在的延迟，包括，网络类型（例如：HSPA+ vs LTE）、运营商（AT&T, Verizon）、当前环境（站着不动，开车，地形，所处的时段等等）。很难确切给出移动网络的延迟时间，但大致范围是知道的，从几十毫秒到几百毫秒。

Round-trip time(RTT)用来测量一个数据包从源出发到达目标主机再返回来所经历的延迟。RTT对很多网络协议的性能有重大影响。我们通过一项古老的运动，乒乓球来说明其中的原因。

在常规的乒乓球赛中，球从一个参与者传到另一个参与者的时间是非常短的。然而，如果都站的很远，开始玩长球，他们就得花更多的时间等球。如果两个乒乓球玩家在距离1000英尺的情况下玩，那么常规距离的5分钟乒乓球赛可能要持续4小时。把两个玩家代之以客户端和服务器，玩家之间的距离看做是RTT，你就会发现问题所在了。

大部分网络协议的正常操作的一部分类似于玩乒乓球游戏。球就是来回的消息交换，创建和维护逻辑网络连接（eg: TCP ）或者执行服务请求（eg: HTTP）都需要这些消息交换。当消息交换很少或者没有数据要传输时，带宽利用率就很低。延迟加剧了带宽的未利用程度。每一个消息交换都伴随着一个延迟，最少也是一个RTT。这对性能的影响积累起来是很大的。

考虑一个下载10KB对象的HTTP请求，涉及到4个消息交换。现在假设RTT是100ms。根据这两个参数，我们得到一个有效的吞吐量10KB/400ms，或25KB/s。

注意，在前面的例子中，带宽完全是无关的 -- 无论网络多么快，结果都不会变，仍然是25KB/s。像前面这样的操作的性能只能通过一种策略来提升：避免客户端与服务器之间来回的消息交换。

移动蜂窝网络

下面简单介绍移动蜂窝网络的组成与导致延迟的特性（conventions）。移动蜂窝网络由一系列具有高度专业化的互连组件组成。这些组件都以某种方式增加了网络延迟，不过增加的程度不一样。有一些特性是移动蜂窝网络特有的，例如无线资源管理，这也是导致网络延迟的因素。

   

基带处理器（Baseband Processor）

大多数移动设备内部，实际上是两台复杂的计算机。移动处理器负责承载操作系统和应用程序，类似于你的计算机。基带处理器负责所有无线网络功能，类似使用无线波而不是电话线的调制解调器。

基带处理器是一个固定但微小的延迟源。高速无线网络是相当复杂的。它复杂的信号处理导致了固定的延迟，大部分网络的延迟范围在微秒与毫秒之间。

基站（Cell Site）

基站，也称接收器基站、蜂窝塔，是访问移动网络的入口。正是基站为被称作“蜂窝"（Cell）的一个区域提供网络覆盖。

像它服务的移动设备一样，基站承担着与高速无线网络相关的复杂处理，导致同样微小的网络延迟。然而，一个基站必须同时服务于成百上前个移动设备。吞吐量和延迟会随着系统负载的波动而变化。我们知道，在人拥挤的时候（比如春节期间的火车站）网络很慢还老是掉线，这就是因为基站达到了它的处理极限。

在最新一代的移动网络中，基站的角色被扩展了 -- 包括直接管理移动设备功能。以前由无线网络控制器负责的很多功能，例如网络注册，传输调度，现在由基站来处理。新一代网络中，这种角色转换减少了很多网络延迟，本章后面讲解释其中缘由。

回程网络（Backhaul Network）

回程网络是基站、基站控制器、核心网络之间的专用WAN连接。回程网络一直以来，并且以后也还是臭名昭著的延迟贡献者。回程网络延迟典型的是由旧网络（例如：GSM，EV-DO）所使用的电路交换和基于帧的传输协议造成的。这样的传输协议的同步性导致延迟无可避免，在这种传输协议中，一个通道代表一个逻辑连接，在预订时间内只能传输或接收数据。以此相反，新一代网络使用支持异步传输的基于IP的包交换回程网络。这种转换已经大大减少了回程网络的延迟。

物理基础设施的带宽限制仍然是瓶颈。许多的回程网络不是设计来处理峰值流量负载的，那是现代高速移动网络所擅长的，当它们变得拥挤时，往往也会导致延迟和吞吐量的急剧变化。运营商正在想法尽快升级它们的网络，然而很多的网络中，这个组件仍然是一个弱点。

无线网络控制器（Radio Network Controller）

传统上，无线网络控制器管理着附近的基站和它所服务的移动设备。无线网络控制器使用被称为“信令”（signaling）的基于报文的管理机制来直接协调移动设备的活动。由于固有的拓扑逻辑，移动设备和控制器之间的所有消息必须通过一个高延迟的回程网络传递。仅考虑这一点是不理想的，许多实际的网络操作会使情况更糟，例如网络注册和传输调度，需要多个往返的报文交换。由于这个原因， 无线网络控制器是典型的主要延迟贡献者。

前面提到，在新一代网络中，控制器已经不再负责设备的管理，许多类似的工作现在直接有基站处理。这个设计决策，已经消除了许多网络的回程延迟因素。

核心网络（Core Network）

核心网络是运营商和公共互联网之间的一个网关。在这里，运营商使用在线网络设备实施服务质量控制和带宽测量。通常，任何网络流量的解释都会引入延迟。实际中，这里的延迟是很小的，但也应该注意它的存在。

省电（Power Conservation）

最大的网络延迟源之一与移动电池的有限容量直接相关。

一个高速移动设备的网络广播在有操作时会消耗掉3W的电源。这个指标大到足够在一个多小时耗干一个iPhone 5电池。为此，移动设备想方设法来移除和降低无线电路的电力消耗。这种想法是为了延长电池寿命，但也引入了一个启动延迟，在无线电路重新上电以发送或接收数据时，这个延迟都会发生。（PS: 怪不得才看一两个小时的电源，就没电了）

所有的移动蜂窝网络标准都包括一个正式的无线资源管理（RRM： radio resource management scheme）计划，用于节约电源。大多数RRM通常定义三种状态：active, idle, and disconnected -- 每一个状态都代表着省电和延迟的折中。

                               

Active

Active代表能以最低延迟高速接收和传递数据的状态。

这个状态即便在空闲时（Idle）也消耗大量电源。网络不活动的小周期（常常不到一秒），会触发到低耗电状态的Idle状态的转换。这对性能的影响足以引起重视：网络事务的足够长的暂停，导致移动设备在active和idle之间波动，这会引起额外的延迟。

Idle

Idle是低耗电量和适度启动延迟的折中。

设备保持与网络的连接，不能够传递和接收数据，但能够接收到网络请求，需要在active状态完成的网络请求（eg: incoming data）。在网络进入不活动状态一段合理的时间后，通常是1分钟或者更短，设备将转换到disconneted状态。

Idle以两种方式增加延迟。首先，无线模块上电和同步它的模拟电路需要一些时间。其次，为了节约更多电源，无线模块是间歇性的监听，所以对网络通知的响应都有轻微的延迟。

Disconnected

Disconnected状态最省电延迟也最大。

断开与移动网络的连接并关闭无线模块。然而，无线网络也不是总处于关闭状态，还是会时不时的激活，以侦听一个特定广播通道上是否有网络请求到达。

Disconnected与Idle具有相同的延迟源，另外还有网络重连的额外延迟。连接移动网络是一个复杂的过程，涉及多次信息交换。恢复一个连接最少也要耗费几百毫秒，有的时候可能需要花费数秒，不过这种情况很少见。

网络协议性能

现在回到我们可以做一些实际控制的事情上来。

网络事务的性能受到膨胀的RTT的不同程度的影响。这是由于大多数网络的操作是基于往返的报文交换造成的。本文的剩余部分将聚焦于理解为何会发生这些报文交换，以及怎样降低甚至消除它们发生的频率。

                                                                   

传输控制协议

TCP是构建于IP网络之上的面向会话的传输协议。TCP影响着无差错的全双工通信通道，这样的通道是诸如HTTP或TLS所必需的。

TCP演示了很多我们尽力避免的往返消息交换。其中一些可用通过采用协议扩展来消除，例如快速打开（Fast Open）。其它的可以通过调整系统参数尽量避免，例如初始拥塞窗口（the initial congestion window）。在这部分我们将探索这两方面的一些方法，同时也会介绍一些TCP的内部背景。

TCP Fast Open

初始化TCP连接涉及3部分的消息交换，即三次握手。 TCP Fast Open（TFO）是TCP的一个扩展，它消除了由正常的TCP三次握手引起的往返延迟。TCP三次握手在客户端与服务器之间协商操作参数，这使健壮的双向沟通成为可能。初始SYN消息代表客户端的连接请求。假如服务器接受连接，它将回应一个SYN-ACK消息。最后，客户端回应一个ACK消息确认服务器的SYN。这之后一个逻辑连接就建立起来了，客户端可能开始发送数据。如果你保持计时，你可能会注意到，三次握手，最少也会引入等于当前RTT的延迟。

              

按照惯例，除了连接复用，没有其它的办法来避免TCP三次握手的延迟。然而，随着 TCP Fast Open IETF specification的引入，最近情况有所改变。

TCP Fast Open允许在连接逻辑上建立好之前就开始发送数据。这有效的消除了三次握手引入的RTT延迟。这项优化的累积效果是令人印象深刻的。根据 Google research  ，TFO可以降低40%的网页加载时间。虽然还是个草案，不过TFO已经有主流浏览器(Chrome 22+) 和 一些平台（Linux 3.6）支持了，其它一些厂商也放出话来，保证即将支持。

TCP Fast Open对三次握手做了一些修改，允许在SYN消息中放入少量数据。这些数据被缓存起来，当连接握手完成之后，传递给服务端应用程序。

早期类似于TFO的扩展建议最终都因为安全性而被否决了。TFO使用安全令牌、或者cookies来解决这个问题。安全令牌在传统的TCP握手期间被分配给客户端，而且要包含在TFO优化的请求中。（PS: 这里就不明白了，安全令牌是怎么分配给客户端的呢？）

还有一些其它使用TFO的注意事项。最需要注意的是，不保证初始SYN携带的数据是幂等的。TCP保证重复包会被接收者忽略，但这种保证不适用于连接握手。人们一直在努力，以期在规范草案中标准化一种解决方案，不过，在那之前，TFO仍然可以安全的部署在不需要幂等性的应用中。

初始拥塞窗口（Initial Congestion Window）

initcwnd是一个可配置的TCP选项，可以通过调整大大加速较小的网络事务。

最新的 IETF specification提议增加初始窗口值，由3个报文段增加到10个。这个提议是基于Google所做的 extensive research提出的，该研究显示这样做会提示10%的性能。如果不了解TCP的拥塞窗口，可能就比较不好理解这样做的目的和潜在的影响。

TCP在不可靠的网络上提供可靠性保证。这相当于承诺所有发送出去的数据都可以保证被收到。包丢失是提供可靠性保证最大的障碍。这就需要检查、修正、预防这些措施。

TCP使用一个正数确认号来检测包丢失，每一个发送出去的包都应该被潜在接收者确认，如果没有收到确认，就说明传输过程中出现了包丢失。在等待确认的时候，已经传递出去的包被保存在被称为拥塞窗口的缓冲区中。该缓冲满时，会产生一个cwnd耗尽事件，传输被停止，直到收到接收者的确认，腾出可用空间才会继续发送更多数据。这些事件在TCP性能中扮演重要角色。

如果不考虑网络带宽限制，TCP吞吐量最终将由cwnd耗尽事件决定。这可能与拥塞窗口大小有关。为了达到最好的TCP性能，拥塞窗口要符合当前网络条件：太大有堵塞网络的风险 - 太多包丢失表示网络拥挤；太小则珍贵的网络带宽得不到有效利用。理论上，对网络状况了解越多，越有可能选择出一个更好的拥塞窗口。但现实是，关键网络属性，比如容量和延迟，很难测量而且经常波动。更复杂的是，任何基于互联网的TCP连接都将跨越许多网络。

由于缺乏确切估计网络容量的手段，TCP转而通过网络拥塞状况来推测它。TCP扩展它的拥塞窗口直到它开始看到有包丢失，包丢失暗示着下游的某个地方不能处理当前的传输速率。通过使用拥塞避免机制，TCP最终使cwnd耗尽事件发生率降到最低同时使用了所有已分配的网络容量。现在，我们明白了TCP初始拥塞窗口设置的目的和重要性。

没有包丢失标志就没法检测网络拥塞。一个新建的，或处于Idle状态的连接缺乏用于优化拥塞窗口大小的数据。TCP采用这样的策略：以一个不太可能引起网络拥塞的窗口开始。最初，这意味着以一个报文段大小（~1480 bytes）作为初始拥塞窗口大小，这个设置持续了一段时间。后来，经验显示设置为4更有效。实际中，你通常会发现初始拥塞窗口被设置为3个报文段（~4KB）.

初始拥塞窗口对高速而微小的网络事务是不利的。这种影响很容易被证实。在标准的3报文段设置中，仅仅发送3个数据包，或者4KiB之后就发生cwnd耗尽。假设数据包是连续发送出去的，响应的确认将不会在比RTT更短的时间内到达。例如，如果RTT是100ms，有效的传输速率将只有可怜的40KB/s（原文是400 bytes/second，这是错误的吧？！）。尽管TCP会扩展它的拥塞窗口直到最终消费掉所有可用带宽，但这是一个很慢的过程。事实上，这就是所谓的慢启动。

慢启动已经到了影响较小下载的性能的程度，对于这样的应用，我们就要重新评估拥塞窗口的风险补偿提案了。Google做了这件事（   did just that  ）并发现把初始拥塞窗口设为10可以产生最大的吞吐量和最小的拥塞可能性。真实世界的结果显示，可以降低10%的整体页面加载时间。高RTT延迟的连接可以达到更好的结果。

把初始拥塞窗口更改为不同于默认值的值并不是件简单的事。在大多数服务器操作系统上，这是个只有特权用户可配置系统设置。客户端的非特权用户很少，甚至根本不可能配置这个设置。要特别注意，服务器端的一个较大的初始拥塞窗口，加速了服务端的下载速度，而对客户端来说，是加速了上传速度。 客户端对这个设置的无能为力暗示着我们应把心思花在如何减小请求数据大小上。

超文本传输协议（Hypertext Transport Protocol）

这部分将讨论如何减轻高往返延迟对HTTP性能的影响。

Keepalive

Keepalive是一个HTTP约定，使得可以通过同一个TCP连接发送连续请求。这样最少也可以避免三次握手附带的单个RTT延迟，为每个请求节约几十到几百毫秒。此外，keepalive还有一个额外的潜在性能优势，利用已经保存的TCP拥塞窗口，可以减少cwnd耗尽事件（PS：随着数据的收发，拥塞窗口会自动达到一个最佳值，这个值既可以充分利用带宽，又减少拥塞发生的机率）。

         

pipelining可以有效把网络RTT延迟分配到到多个HTTP事务中。例如，5个流水化的跨越100msRTT延迟的连接的HTTP请求，将平均只有20ms的延迟。同样的条件下，10个流水化的HTTP请求将把平均延迟降到10ms。

HTTP pipelining有显著的副作用阻止了它的广泛应用，即参差不齐的HTPP代理支持历史和面对DDOS攻击的脆弱性。

传输层安全（Transport Layer Security）

TLS是一个面向回话的网络协议，允许通过公共网络安全的传输敏感信息。TLS在安全通信方面是很有效的，但在高延迟网络上性能会降低。

TLS握手很复杂，涉及到两轮信息交换。由于这个原因， TLS -secured  HTTP事务可能会相当慢。

          

通常，主机平台会提供一个缓存实现来避免频繁的DNS查询。DNS缓存的语意是不难理解的。每一个DNS响应都包含有一个TTL属性，声明了这条结果可能被缓存多长时间。TTLs变化范围很大，从几秒到几天，不过通常是几分钟。非常短的TTL，通常不到1分钟，被用于调整负载分配和最大限度减少服务器备份和ISP故障切换的停机时间。

大多数平台的本地DNS缓存实现都没有考虑移动网络的高延迟。许多移动网络应用都可以从缓存实现中获得益处。这里推荐几种高速缓存策略，如果为应用程序部署这样的策略，将可以消除任何由不必要的DNS查询引起的随机和杂散延迟。

刷新失败（Refresh on Failure）

高可用性系统通常依赖于由它们IP的地址空间路由的冗余基础设施，低TTL的DNS条目有利于降低一个网络客户端使用路由失败的地址的次数，但同时会引起过多的DNS查询。TTL是最小化停机时间和最大化客户端性能的一个折中。

应该注意到这种缓存技术可能与基于DNS的负载分配机制不兼容。

异步刷新（Asychronous Refresh）

异步刷新是应用于DNS缓存的一种方法，它遵从发布的TTLs同时消除了频繁DNS查询的延迟。需要一个异步DNS库，比如 c-ares，来实现这种技术。

原理是很直接的，对一个已过期的DNS条目的请求将返回一个陈旧的结果，同时在后台安排一个非阻塞的DNS查询以刷新DNS缓存。如果实现是对一个很旧的条目采用阻塞查询，这种技术在基本消除DNS延迟的同时，还保持了与基于DNS失效和负载分配机制的兼容性。

有一个简单的解决方案解决这一难题，只有当高层协议，例如TCP或HTTP，检测到一个不可恢复的错误时才刷新缓存中的DNS条目，而不是严格遵从TTL。在大多数情况下，这种技术模拟了 a  TTL -conformant  DNS  cache的行为，同时消除了基于DNS的高可用性解决方案的副作用。

结论（Conclusion）

减轻移动网络膨胀延迟（inflated latency）的影响需要降低网络往返时间，才能有比较明显的效果。对于软件优化，聚焦于最大限度减少或消除往返协议报文是克服这个艰巨的性能问题的关键。

原文：

http://www.aosabook.org/en/posa/secrets-of-mobile-network-performance.html