[转]Google 的互联网野心

前几天做了个内部技术分享，各位同学的看法莫衷一是，因此拿出来跟大家聊聊。本文将讨论 Google 的网络基础设施计划——Google Fiber 和 Google Loon，以及 Google 在网络协议方面的探索——QUIC，其野心在于把互联网变成自家的数据中心。

有线网络基础设施——Google Fiber

Google Fiber 的目标是让千兆互联网走进千家万户。以千兆的速度，下载一部 7G 的电影只需一分钟（如果你还在用机械硬盘的话估计还来不及存呢）。目前这个项目仅在美国 Kansas 和 Provo 两个城市试点。这两个城市的 Google Fiber 都提供了三种套餐，以 Kansas 为例：[1]

1. 千兆网络 + Google TV：120 美元/月
2. 千兆网络：70 美元/月
3. 免月租网络：5Mbps 下载，1Mbps 上传，免月租，但要交 300 美元初装费。

其中第三种方案还不如美国大部分电信运营商提供的服务快，而大多数家庭已经购买了有线电视运营商的电视服务，因此对经济上能承受得起的家庭来说，三种套餐的对比突出了第二种套餐（70 美元/月的千兆网络）的“实惠”。

这里有两个值得争论的地方：

1. 每人都有千兆这么快的网络，技术上可以实现吗？
2. 70 美元/月的收费能收回 Google 搭建千兆网络的成本吗？

互联网拓扑的扁平化

很多大学和公司的内部网络都是千兆的，也就是理论上下载速度能达到 120MB/s。外面的网络很精彩，但外面的网络相比校园网来说一般也很慢。网线总是很快的，但运营商会对网络进行限速。这个限速一方面是鼓励你去买更贵的套餐，另一方面也跟公共互联网近似树形的拓扑结构有关。假设全国教育网到联通的流量都要经过一根 10Gbps 的光纤，你说能快吗？

事实上，随着互联网巨头和 CDN 的发展，互联网的拓扑结构已经在悄然改变。SIGCOMM 2010 的一篇论文 [2] 指出，随着大型内容提供商的兴起（例如早在 2009 年 Google 的流量就已经达到了整个 Internet 流量的 5%），现在互联网的拓扑结构正在逐渐扁平化。互联网更加依赖 IXP（Internet Exchange Point），它们把不同的运营商（ISP，Internet Service Provider）连接在一起，再连接到大型内容提供商。这种“分层网状”的拓扑结构有效地解决了跨运营商的网络瓶颈。很多 IXP 的数据都是公开的，例如香港 IXP [3] 的流量图：

把城市变成数据中心

不过，上述拓扑结构变化仅仅发生在互联网的中心，在互联网边缘的毛细血管，由传统运营商搭建的家庭有线网络仍然是树形结构。事实上，如今的大型数据中心里，服务器数以 10 万计，每台服务器仍然能有 10Gbps 的网络；假设所有连接都是在任意两台机器之间建立的，总流量可以达到 10Tbps 级别（事实上网络连接总是有一定的局部性，因此实际能支持的流量比这个大）。如果把这样的网络拓扑应用在一座城市里，城市规模的千兆“局域网”并不是神话。不过布线成本和网络交换设备的成本肯定会提高，这就是 Google Fiber 那么贵的原因。

为什么 Google 比传统运营商和其他互联网公司更急着让高速网络走进“最后一公里”呢？

• 技术方面，传统运营商不做数据中心，更不做网络研究，只知道从知名厂商买来一些交换机和路由器，再雇一些“认证工程师”来配置。
• Google 是世界上最大的内容提供商，对 Google 来说，Google Fiber 的收益不仅包括用户的包月上网费，还包括为其他产品（如 YouTube）省下的流量费用。
• 如果用户的网络够快，Google 就可以把很多本地应用放到互联网上，让“下载”成为过去时，进一步挤压非互联网公司的生存空间。
• 传统运营商的思维惯性和惰性。

因此，Google Fiber 所许诺的“千兆入户”不仅在技术上是可实现的，从整个公司的角度看也是有利可图的。

移动网络基础设施——Google Loon

说完了有线网络，再来说说无线。不论是室内无线网络（wifi）还是大范围蜂窝网络（3G），都有两块心病：

1. 无线网络的覆盖范围有限，一些偏远的地方不值得投资修建无线基站；
2. 单一接入点的支持人数有限，人多了就比较慢甚至无法连接。

Google Loon [4] 跟 3G 的应用场景差不多，气球采用太阳能供电，悬浮在 20km 左右的平流层（云层和飞机在 10km 左右的高度，因此不受它们的影响），随风漂移，形成巨大的无线自组织网络（wireless mesh network）。不过这些气球不是随意漂移，而是利用气象部门的风力数据，在不同的风层之间受控地上下移动，气球随不同层的空气以不同的速度和方向运动，从而保证气球的运动轨迹是基本受控的。

每个气球直径约 15 米，无线网络可以覆盖大约 40km 的范围。地面上的人可以使用专用天线接收热气球信号。下图是接收天线（来自 YouTube），其中绿色的部分是信号接收器，银色的金属是反射盘，这种结构使得无论热气球在地面上空的哪个方向，都会有信号直射或反射进入接收器。

使用专用接收装置而不是 wifi，除了信号强度的原因，还可能是效率的考虑。无线网络是广播信道，如果大家同时说话，则谁也听不清。wifi 协议适用于 30 人以内的小型自组织网络，每个人听到周围安静了就随机等待一段时间开始请求发言。这个随机等待时间如果短了，大家要求发言的请求可能撞到一起；随机等待时间如果长了，则信道的利用率就会降低。3G 之类由基站控制的协议之所以能支持更多的用户，根本原因在于基站的协调，不论是频分、时分还是码分，都是由基站决定谁该在什么时候发言的，不可能撞到一起，提高了信道的利用率。

每个气球有两个工作在不同频段的天线，一个用于跟地面的用户或基站通信，一个用于气球之间的通信。这是无线自组织网络达到高效的重要方式。如果使用单一频段，气球间通信和地面的通信会争抢同一信道，导致随着跳（hop）数增加，无线网络的效率成反比例甚至指数衰减。这是用单频无线路由器搭建的无线自组织网络很难高效工作的原因，不过 Google Loon 避开了这个问题。

Google Loon 自然能够用较低的成本实现大范围偏远地区的网络覆盖。另一个很少有媒体提到的用途便是动态调整接入点数量，解决大型活动带宽不足的问题，或者在发生自然灾害时提供应急网络。例如在广阔的草原上举行一场盛会，临时建大量 3G 基站显然既不经济也来不及。但 Google Loon 可以提前调集大批热气球到这个区域，提供足够的带宽。Google 有个专利描述其实现 [5]。

加速网络协议的进化——QUIC

网络权威 Scott Shenker 在 2013 年的 Open Networking Summit 上讲，网络协议总是修修补补，没有一致的理论原则。操作系统、编译器都有一整套理论，而网络却是一系列协议的拼凑。其主要原因是网络协议的每项改动都要牵涉硬件，还可能牵涉多个机构，遇到新的需求只好打个补丁而不是设计更合理的架构。因此他提出 SDN（Software Defined Networking）是网络发展的方向，软件总是比硬件易于修改。

正是由于一个数据中心由一家公司管理，想怎么搞就怎么搞，目前有线网络协议的创新大多在数据中心里。不过 Google 的野心并不限于提高自家数据中心的效率，而想提高整个互联网的效率。显然 Google 是没有能力联合所有网络设备厂商和运营商的，只好绕过它们。好在 Google 是全世界最大的互联网内容提供商，还手握市场份额最大的浏览器 Chrome 和移动操作系统 Android，可以把网络协议栈的一部分架空，在应用层做协议创新。

目前的 HTTP + SSL/TLS + TCP + IP 协议栈有什么问题呢？（图片来源：[6]）

1. HTTP 不支持多路复用（multiplexing），现代网站动辄一个页面几十个资源（JS、CSS、图片），发起几十个 TCP 连接，握手开销太大；用单个 TCP 连接串行操作，等待时间又太长。
2. SSL/TLS 对每个 TCP 连接要分别进行握手，每次握手要走两个来回，这对 TCP 连接握手是雪上加霜。
3. TCP 协议中的拥塞控制算法是一个通用的折中算法，并不能充分利用各种网络的特点。例如对高带宽、高延迟的网络（长肥管道），首先需要较长的时间指数增长窗口大小，一旦发生丢包，窗口大小又得减半。如果事先知道网络的特性，就可以实现更精准的拥塞控制，甚至为一些实时应用（如视频）预留带宽。
4. IP 协议用 IP 地址定位主机，这在有线网络中是没有问题的，但在无线网络中，由于用户是移动的，可能在不同无线网络间不断切换，用于路由的 IP 地址也会不断改变。网络切换时自动重连只是权宜之计，它显然不能同时利用两个无线网络（wifi、3G）。

QUIC（Quick UDP Internet Connections）协议是基于 UDP 的，绕开了 TCP，也就是取消了基于 IP 地址的“连接”。取而代之的是每个 QUIC 包头部的 session ID，用 session ID 标识连接，这与浏览器 cookie 是一个道理。由于 QUIC 连接由 session ID 决定，数据包不管通过哪条路发到 QUIC 服务器都行，QUIC 可以同时利用多个无线网络（wifi、3G），并且在无线网络间无缝切换。这神似 Multipath TCP 的原理。

一个 QUIC 连接是多路复用的，也就是多个到同一网站的 HTTP 请求可以在一个 QUIC 连接中同时传输。整个 QUIC 连接建立时只需握手一次，节约了 SSL/TLS + TCP 每个 HTTP 请求都要建立连接、握手两到三次的开销。（如下图所示，图片来自 [6]）

QUIC 协议中对每个 HTTP 请求有编号，每个 HTTP “连接”内部的数据包也有序列号，这使得每个 HTTP “连接”所发的包可以被区分开，也可以使用单独的重传和拥塞控制策略。这解决了基于 TCP 的 SPDY 协议（这是 Google 之前提出的 HTTP 多路复用协议，将纳入 HTTP/2.0 标准）中的 Head-of-Line blocking 问题，也就是队列头部的数据包由于丢包被堵住了，队列中后面不论有关还是无关的数据包都会被堵住。在 QUIC 中丢包只会堵住丢包所在的那个 HTTP 请求。

QUIC 更长远的意义是加速网络协议的进化。在目前的网络中，带宽估计、用 packet pacing 实现限速、发送冗余校验包以容忍丢包之类的设计，由于涉及内核协议栈，是很难推广的。但 QUIC 绕过了 TCP 这块难啃的骨头，把 TCP 的工作放到应用层去做，只要升级浏览器甚至安装个浏览器插件就能用上新协议，把网络协议的进化周期由“年”缩短到了“周”。

互联网 == Google 数据中心？

Google Fiber 实现了千兆入户，Google Loon 将网络覆盖到“千兆入户”无法覆盖的地方，QUIC 又在优化网络传输、加速网络协议进化，它们形成了一个完整的链条，控制了互联网从用户端到 Google 数据中心的每个环节，或者说 Google 在把用户的终端纳入自己的数据中心。当然 Google Fiber 和 Loon 会遭到政策压力和运营商的反对，不过 Google 如能克服阻力做成这些项目，将成为互联网时代比 PC 时代的 WinTel 联盟更强大的垄断者——因为这次 Google 既做硬件又做软件，而当年微软做软件、Intel 做硬件，至少还是有分工的。

数据中心本来就是一个软硬件结合的大型项目，数以十万计的机器需要合理的网络拓扑，也需要定制操作系统中的网络协议栈和网络交换设备中的控制通路，还需要有可靠的中心控制器来收集全局状态和调度网络流量。如果“中心”足够稳定，集中控制总比分布式控制效率高，这也许是自由主义者不愿意承认的事实。Google 的野心便是把互联网变成自家的数据中心，自己来做“中心控制器”。至于这个目标是否能达成，让我们拭目以待吧。

参考文献

1. Google Fiber plans and pricing: https://support.google.com/fiber/answer/2657118?hl=en
2. Internet Inter-Domain Traffic, SIGCOMM 2010
3. http://www.hkix.net/hkix/stat/aggt/hkix-aggregate.html
4. http://www.google.com/loon/
5. Balloon Clumping to Provide Bandwidth Requested in Advance, US Patent
6. QUIC @ Google Developers Live, February 2014