以下是一篇由IanApplegate撰写的技术文章（@appelingtea），我们的系统工程团队的一名成员，讲解如何为移动连接优化Linux-TCP堆栈。这篇文章最初是发表的作为2012年网络性能日历的一部分。在CloudFlare，我们花了大量的时间来确保我们的网络堆栈能够调整到与我们连接的任何类型的网络或设备上。我们希望分享一些技术细节，以帮助其他寻求优化移动网络性能的组织，即使他们不使用CloudFlare。而且，如果您使用CloudFlare，当移动网络访问您的站点时，您将获得所有这些好处和最快的TCP性能。

我们在CloudFlare花了大量时间思考如何在移动设备上加快互联网的速度。目前有超过12亿活跃的移动用户，而且这个数字正在迅速增长。今年早些时候，印度的移动互联网接入超过了固定互联网接入，这一情况很可能在全世界重复。因此，移动网络的性能将变得越来越重要。目前，大多数关于提高移动性能的关注点都集中在第7层的前端优化（FEO）。在CloudFlare，我们在这方面做了大量的工作，使用了前端优化技术，如Rocket Loader、Mirage和Polish，dynamicall修改web内容，使其能够快速加载正在使用的任何设备。然而，我们在关注移动网络底层特性的同时，也要注意移动网络的底层特性。本文介绍了移动设备目前面临的挑战，默认的TCP配置如何不适合最佳的移动性能，以及您可以做些什么来提高通过移动网络连接的访问者的性能。在深入讨论细节之前，先做一个简短的技术说明。在CloudFlare，我们已经在Linux的定制版本上构建了我们的大多数系统，因此，虽然底层技术可以应用于其他操作系统，但我将使用的示例来自Linux。拥挤控制算法要了解移动网络性能在网络栈的第4层面临的挑战，您需要了解TCP拥塞控制。TCP拥塞控制是一个网关守卫，它决定如何控制从服务器到客户端的数据包流。它的目标是通过检测何时发生拥塞并降低数据传输速率来防止互联网拥塞。这有助于确保互联网对每个人都可用，但当TCP将移动网络问题误认为是拥塞时，可能会导致移动网络出现问题。如果TCP拥塞控制检测到远程端的拥塞（即数据包丢失），它会阻止闸门。网络本质上是一种共享资源。TCP拥塞控制的目的是保证网络上的每一个设备都能协同工作，而不会使其资源被淹没。在有线网络上，如果检测到数据包丢失，这是一个相当可靠的指标，表明沿连接的端口负载过重。在这些情况下，通常发生的情况是某个交换机中的内存缓冲区已超出其容量，因为数据包传入的速度快于发送的速度，数据被丢弃。在这些情况下，客户机和服务器上的TCP拥塞控制设置为"后退"，以确保网络对其所有用户仍然可用。但要弄清楚数据包丢失在移动网络上意味着什么是另一回事。无线网络固有的易受干扰的影响，从而导致分组丢失。如果数据包被丢弃，是否意味着交换机负载过重，就像我们可以在有线网络上推断的那样？或者有人从一个订阅不足的无线蜂窝移动到一个订阅过多的无线蜂窝？还是有人刚打开微波炉？或者只是一个随机的太阳耀斑？由于目前还不清楚数据包丢失在移动网络上意味着什么，所以也不清楚TCP拥塞控制算法应该采取什么行动。一系列泄漏的管子为了优化像移动网络那样有损网络的网络，准确理解TCP拥塞控制算法是如何设计的很重要。虽然高层次的概念是有意义的，但TCP拥塞控制的细节并没有被大多数从事web性能行业的人广泛理解。也就是说，它是使互联网可靠的重要核心部分，也是非常活跃的研究和开发课题。

为了理解TCP拥塞控制算法是如何工作的，想象一下下面的类比。把你的网络服务器想象成你当地的自来水厂。你在家乡建立了一个庞大的管道网络，你需要保证每根管道都尽可能的加压以供输送，但你不想让管道爆裂。（注：我认识到已故参议员泰德•史蒂文斯（tedstevens）曾因将互联网描述为"一系列管子"而饱受抨击，但这个比喻却出人意料地准确无误。）你的客户，疯狂的阿蒂，经营一个当地的瓶装水工厂，连接到你的管网。疯狂艺术的基础设施是建立在漏水和易碎的旧管道上。要想在不炸裂水管的情况下给他们取水，你需要推断疯狂艺术的系统的能力。如果你事先不知道，那你就做一个测试——你把已知量的水送到管线上，然后测量压力。如果压力突然消失，那么你可以推断你弄断了一根管子。如果没有，那么这个水位可能是安全的，你可以增加水压，重复测试。你可以重复这个测试，直到你爆裂了一个管道，看到下降的压力，写下最大水量，并确保你永远不会超过它。但是，想象一下，有一些外生因素可以降低管道中的压力，而实际上并不意味着管道已经破裂。举例来说，如果疯狂的阿蒂开了一个泵，他只是偶尔随机打开，而你却不知道。如果你唯一的信号是观察到压力的下降，你就无法知道你是否会爆管，或者疯狂的阿蒂刚刚插上了泵。结果是，你可能记录到的压力水平远低于管道实际承受的压力水平，这导致网络上所有客户的水压可能低于他们应该承受的压力。优化拥塞或丢失如果你一直在跟踪这一点，那么你已经知道了更多关于TCP拥塞控制的知识。我们在TCP中讨论的初始水量称为初始拥塞窗口（initcwnd），它是网络中传输的初始数据包数。或者说，在初始窗口中，压缩包的数量取决于返回窗口的速度。从本质上讲，TCP拥塞控制就像水资源工具一样——测量压力a管网可以承受然后调整容积，以尽量使流量最大化，而不会爆裂任何管道。当TCP连接第一次建立时，它会尝试快速提升cwnd。在连接的这个阶段，TCP快速增长cwnd，称为慢启动。这有点用词不当，因为它通常是一个指数增长函数，它非常快速且具有攻击性。就像上例中的water实用程序检测到压力下降时，它会降低水量，当TCP检测到数据包丢失时，它会减小cwnd的大小，并延迟另一个突发包被传递之前的时间。分组突发之间的时间称为重传超时（RTO）。这个TCP中控制这些进程的算法称为拥塞控制算法。拥塞控制算法很多，客户机和服务器可以根据各自网络的特点采用不同的策略。大多数拥塞控制算法都专注于针对一种或另一种网络丢失进行优化：拥塞性丢失（如您在有线网络上看到的）或随机丢失（如您在移动网络上看到的）。

在上面的例子中，管道破裂是充血性损失的一个迹象。管道有一个物理限制，超过了限制，适当的反应是后退。另一方面，疯狂艺术的泵类似于随机损失。管网上的容量仍然可用，只有暂时的干扰才会导致供水公司认为管道过满。互联网一开始是由有线设备组成的网络，顾名思义，拥塞控制主要是为了优化拥塞损失而设计的。因此，在许多操作系统中默认的拥塞控制算法对于有线网络的通信是很好的，但是对于与移动网络的通信却没有那么好。一些拥塞控制算法试图通过利用"压力增加"到"预期容量"的延迟时间来找出损失的原因，以此来弥补这一差距。这些被称为带宽估计算法，例如Vegas，维诺和韦斯特伍德+。不幸的是，所有这些方法都是反应式的，没有跨两个相似的流重用任何信息。在看到大量网络流量的公司，如CloudFlare或Google，可以映射互联网网络的特性并选择特定的拥塞控制算法，以最大限度地提高性能