走进腾讯公网传输系统

＂鹅厂网事＂由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营，我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息，同时分享腾讯在网络与服务器领域，规划、运营、研发、服务等层面的实战干货，期待与您的共同成长。 网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台，为支撑腾讯公司业务持续发展，为业务建立竞争优势、构建行业健康生态而持续贡献价值！

小编：还有1天就大年夜拉，期待大年夜晚上的微信红包，总有种要中大奖的感觉，所以这几天小编勤加苦练微信摇一摇，小编膏药已贴，你们呢？当然同时也不忘给大家带来一篇分享腾讯网络新技术的文章。腾讯网络越来越大，如何利用公网的资源，高性价比的将分布不同IDC之间的业务连接起来，于是BOBCAT应运而生。欲知何为BOBCAT，请看下文分解。

一、背景　

互联网企业的基础架构不断地被其业务发展规模所挑战，对于腾讯这家业务种类繁多、业务规模庞大的公司而言，矛盾尤为突出。随着业务的快速发展，公司在全球范围内通过自建和租借的方式建立了许多IDC。由于业务应用场景复杂多变，经常会出现单个业务部署在多个IDC或者多个业务之间需要相互通信的情况，这样，就会引起跨IDC的通信问题。一般而言，在广域网上运营商会提供网络专线服务来实现这种通信。其优点是安全性好，QoS也可以得到保证。但其缺点也很明显，价格高昂，建设部署由于涉及到外部运营商经常需要较长周期，超长距离的跨国专线由于涉及多个运营商，建设运营不可控因素多等。很容易想到的一个替代的方案是利用公网资源来规避这些问题，公网资源获取成本很低，可以实现anywhere/anytime的服务；部署方便，通过两端架设设备的方式能够可控的实现部署；跨国公网依赖于全球运营商现有的相对成熟稳定的因特网，可以保证绝大部分情况可用。公网传输系统（代号BOBCAT）就是在这样一种应用场景和需求下提出的解决方案。

二、行业解决方案

业界应对这种场景，有一种成熟的技术，叫做虚拟专用网（Virtual Private Network，简称V**）。虚拟专用网是透过公用的网络来传送私有网络的信息。它利用已加密的隧道协议（Tunneling Protocol）来达到保密、发送端认证、消息准确性等私有信息的安全效果。这种技术可以使用不安全的网络来发送可靠、安全的信息。当然，也有些场景不需要使用到加密，例如MPLS V**，这种场景使用安全信道进行传输，使用V**的目的更多在于方便网络维护管理。没有加密的也可以称为V**，但利用不加密V**传输的消息有被窃取的危险。　　

根据V**所在OSI模型层次，V**有多种协议标准，基于数据链路层的PPTP、L2TP，基于网络层的IPsec V**，基于应用层的SSL V**等。根据网络连接方式的不同，还可以分为Site to Site和End to Site两种类型。Site to Site主要指的是网络和网络之间的V**连接，而 End to Site 指的是终端到网络之间的V**连接。SSL V** 就是 End to Site类型的V**。目前BOBCAT系统属于Site to Site类型的V**。 　　

目前主流的设备厂商都有支持V**功能的设备。一般而言，这些厂商的设备集成了诸如anti-DDOS、ADS、IPS等多种安全功能，并且为适应不同应用场景这些设备还支持了多种V**方式，因此造价较高。而随着技术的演进，利用多核CPU进行数据面转发的软硬件也越来越成熟，使用廉价的标准服务器进行数据转发成为一个选择。　　

同时，互联网公司的业务具有不断演进的特点，在这个过程中会对公网传输系统提出各种定制化需求。这些定制化需求开发性较强，传统设备厂商反馈周期较长，甚至没有针对特定的小众需求进行开发的意愿，无法满足业务快速响应的需求。在这种背景下，我们决定采用软件的方式来解决公网传输的问题，BOBCAT公网传输系统也因此而生。

三、腾讯解决方案　　

以下内容将分为几个方面详细介绍腾讯公网传输系统BOBCAT，主要包括系统架构设计、高性能转发、安全传输、加密隧道、加速服务、SDN等几个方面。

3.1 系统架构　　

BOBCAT系统架构分为4个层次，分别为硬件层、转发层、管理层、应用层，主要模块及结构关系如下图所示。

Figure 1 系统架构

硬件层主要负责物理硬件的支持，包括多核CPU支持、千兆网卡、万兆网卡的支持。BOBCAT目前支持两种CPU架构，Tilera的网格架构和Intel的x86架构。最初该系统选用了Tilera的一款64核众核CPU，该CPU使用独有的“矩阵”架构（iMesh），该架构具备良好的扩展性，可以很轻易地将核心数量扩展到100个。Tilera同时配套提供一套MDE（Multicore Development Environment，多核开发环境），利用这个MDE环境可以非常方便的进行多核应用开发，发挥多核CPU性能。该CPU每个物理核时钟频率较低，为866MHz，使得整个CPU功耗较低，有利于降低整个数据中心的TCO。随着Intel的DPDK的发布，x86 CPU也具备了处理高速网络数据包的能力。DPDK与Tilera的思路有许多相似的地方，例如CPU亲和性绑定、内存零拷贝、轮询处理机制等，通过最大限度地释放CPU处理能力、降低内存拷贝开销，来实现线速转发。BOBCAT目前主要使用的是Intel的DPDK技术，后文也将对其进行介绍。　　

转发层主要提供数据处理能力，包括报文解析、封装、校验、加解密及防重放攻击等。转发层相当于传统交换机的Fast Path，通过精简的逻辑处理，提供线速的处理能力。　　

管理层主要负责提供各种用户接口、维护隧道关系等，支持传统网络设备的命令行配置，同时提供密钥协商、报文统计、调试、日志、心跳、AAA等功能，犹如整个设备的心脏。　　

应用层主要负责全局信息维护，随着整个系统在全球的部署，单个设备的信息维护方式逐渐捉襟见肘，从全局维护整个系统的状态成为必需。目前应用层通过统一的管控平台进行接入，提供拓扑、基础信息库、网络质量多个纬度的信息展示。除此之外，我们还在此基础上进行了SDN的相关尝试。

Figure 2 部署结构

公网传输系统的部署结构，如上图所示。不同地域的IDC通过BOBCAT，利用运营商公网进行连接，实现跨域互访。全球所有设备通过管理网与控制中心保持连接，实现数据采集、监控、告警、流量控制等功能。

3.2 高性能转发

一般而言，普通应用程序很难将网卡的处理能力发挥到极致，一般应用程序能够实现数万级别QPS的处理性能，已经属于非常高的处理能力了。但BOBCAT要求的处理性能是万兆吞吐量，对应着百万级别的PPS处理能力，使用传统手段很难满足其线速处理需求。限制应用程序性能的原因主要有两个：一是因为普通应用程序架设在操作系统之上，而网络数据报文从网卡进入操作系统，经由驱动至TCP/IP协议栈处理，需要进行至少两次拷贝，内存拷贝影响了应用程序的处理性能；二是普通应用程序与系统上其他应用程序共享CPU资源，操作系统对每个应用程序都是公平调度的，会导致频繁的进程调度、上下文切换，并导致大量Cache Miss，CPU性能被无谓的浪费在这些调度过程中，无法将CPU能力发挥到极致。　　

针对上述问题，业界产生了许多解决方法，一个行之有效的方法是通过CPU的亲和性绑定和内存零拷贝技术来规避这些问题。Intel的DPDK将这些方法进行了整合实现，可以通过使用DPDK来实现这些特性，达到百万级别PPS转发的目的。

Figure 3 DPDK框架

DPDK开发套件框架如上图所示，DPDK提供一个环境抽象层（Environment Abstraction Layer），EAL将用户态进程与底层网卡驱动的通信行为进行了封装，为应用程序提供了通用的报文处理接口，应用程序可以很方便地调用这些接口，对报文进行处理，屏蔽了报文收发细节。针对上面提到的普通应用程序的性能瓶颈问题，DPDK主要采用以下方式解决。

（1）基于大页表的内存管理

DPDK采用基于大页表的内存管理机制，解决报文从驱动到协议栈，再从协议栈到用户态空间的内存拷贝问题。大页表是一项非常成熟的技术，在Linux 2.6内核中已经进行了支持，主要是解决大内存时的TLB Miss问题。我们知道应用程序访问的内存空间都是操作系统提供的虚拟内存空间，在实际进行访问时，需要将虚拟内存空间进行转换。虚拟内存到物理内存的转换就用到了TLB。操作系统传统页面大小为4K，若应用程序使用4G内存，将占用1M条表项，而一般CPU的TLB条目非常稀缺，无法同时维护如此巨大的表项，最终会通过置换算法将过期的表项移出TLB，导致TLB Miss。大页表通过增加单个页面的大小，减少了所需页表条目数量，可以有效的降低TLB Miss。同时由于大页表在系统启动时就分配好了，在使用过程中不需要换入和换出，也可以有效的减少内存交换。

DPDK在大页表的基础上实现了特有的内存管理机制，DPDK提供的网卡驱动将收到的报文通过DMA的方式映射到大页表对应的内存中，并抽取报文对应的报文指针，在应用程序和驱动之间维护一套无锁的环形队列来管理这些报文指针。应用程序只需要调用相对应的接口，从队列中提取相应的报文进行处理，完成后，再将报文指针放到发送队列中，由驱动程序进行发送。值得注意的是，在处理报文的整个过程中，不需要对报文进行任何拷贝，所有操作都依赖于报文指针，可以从整个报文生命周期上，解决内存拷贝问题，实现内存零拷贝。

当然，DPDK的这种方案也有其局限性。由于所有的报文没有经过内核协议栈的处理，所以所有的协议行为都需要应用程序来处理。对开发人员而言，就需要对各种TCP/IP协议的特性有较深入的了解。但有些应用层协议行为十分复杂，通过应用程序来进行协议处理会带来巨大的性能开销。因此，DPDK这种方案更适合协议行为简单的网络应用。DPDK为应对这种情况，也提供了一种利用内核协议栈处理复杂协议的方式，即KNI虚拟网卡。通过KNI技术，可以将已经到达用户态的报文，再次导入内核协议栈进行处理。但这种方式的处理性能不高，需要平衡使用。

（2）基于CPU亲和性的进程分配

DPDK的EAL提供基于CPU亲和性的多核并发处理机制。前面提到由于普通应用程序运行过程中，CPU同时需要处理其他应用及操作系统的中断，导致出现频繁的进程调度、上下文切换和大量的Cache Miss，导致普通应用程序无法达到百万PPS级别甚至更高的处理能力。CPU亲和性绑定，可以很好的解决这个问题。

CPU亲和性一般分为软亲和性和硬亲和性，软亲合性可以使应用程序不在处理器之间频繁迁移，而硬亲和性更为彻底，应用程序将只运行在指定的处理器之上。Linux系统天然支持软亲和性，其进程调度策略会尽量把进程固定在同一个处理器上运行。但有些时候，仅靠操作系统的调度是不够的。例如对于网络应用而言，其处理速度要求非常高，并且要尽力减少其处理时延。这个时候就需要CPU的硬亲和性绑定了，在Linux 2.6版本内核中对此进行了支持。

DPDK集成了CPU硬亲和性绑定技术，通过启动参数的设定，可以很方便将某个CPU核心分配给某个应用进程使用。当然，此种做法无法解决进程调度带来的开销，例如同一个CPU核心如果分配给了不同应用进程使用，仍然会带来进程调度、上下文切换、Cache Miss等问题。这时候只能通过独占来解决这个问题，Linux系统也对这种情况进行了支持。Linux内核启动参数支持isolcpus，通过该参数，可以将某些CPU核心进行隔离，默认不使用这些核心进行进程调度。这时候再使用DPDK提供的硬亲和性绑定技术，只要小心处理，可以实现一个应用进程独占CPU核心的效果，避免进程调度带来的上下文切换和Cache Miss。

3.3 安全传输

将业务数据放在公网上进行传输，势必带来许多安全挑战，因此如何保证业务数据安全地到达目的地是公网传输系统首先要解决的问题。在BOBCAT系统中，主要通过基于PKI密钥协商机制、灵活的加密策略、高效的防重播及防篡改技术等来保证业务数据安全。

3.3.1基于PKI的协商机制

BOBCAT系统的协商机制经历了一系列演变，在设计之初，为保证协商的安全性，利用了公司分布广泛的专线资源，协商过程走专线进行，正常数据转发利用协商后的信息走运营商公网传输，其协商方式如下图所示。

Figure 4 基于专线的协商机制

这种方式很好的利用了IDC之间的专线资源，但其可用性和安全性都依赖于其他媒介，是其硬伤，在部署过程中，会受到网络资源的限制。针对此种情况，在BOBCAT后续的版本中，采用了一种基于PKI的协商机制。

Figure 5 基于公网的协商机制

如图Figure5所示，通过认证中心，为每台设备建立证书，并在部署时下发到相应设备上。每次进行协商时，会基于该证书文件，建立一个SSL安全通道，在此安全通道上执行基于随机数的协商逻辑，使两端设备获得相同的对称密钥，用于报文加解密。

3.3.2数据加解密

不同业务对安全性有不同的需求，而数据安全性依赖密钥生成机制的安全性和加密算法的强度，同时加密必然带来性能开销，加密算法的复杂度与性能之间如何进行平衡也是需要考虑的。

目前主流的加密算法可以分为对称加密算法和非对称加密算法。对称加密算法性能较高，主要有DES、3DES、AES、RC4等。非对称加密算法一般加解密性能较差，但安全性较好，主要有RSA、DSA、ECC等。一般会将这两种类型的算法结合起来使用，即使用非对称加密算法来管理密钥，使用对称加密算法进行数据加解密。此种方式综合了非对称加密算法的安全性和对称加密算法的性能优势。BOBCAT的加解密算法即是此种方式，利用基于SSL的公钥证书体系协商密钥，再使用协商出来的密钥使用对称加密算法对数据进行加解密。

解决密钥安全性的问题后，就需要重点考虑数据传输时使用的对称加密算法的性能。高速加密处理目前有许多解决方法，硬件的、软件的都有，业界有许多应用。Intel x86 CP针对常用加密算法进行了优化，增加了专用的指令集，可提供较高性能的对称加密功能。BOBCAT利用了此特点，可以在不分片情况下可以获得接近线速的加密转发性能。此外，BOBCAT还参考流式加密算法的思路，提供一种私有加密算法，对于安全性要求不高的场景，可以提供更高的性能表现。

3.3.3防重放攻击&防篡改攻击标题

由于BOBCAT直接面向公网使用，相比内网应用，要承担更多风险。因此也需要进行更多安全防护，这里主要介绍两种常见的攻击防范方法。

防重放攻击主要为了防止公网的恶意用户截取BOBCAT公网报文后大量复制发送该报文进行攻击。BOBCAT针对该情况进行了处理，使用了一种基于序列号的防重放攻击方法。为每个报文分配一个独一无二的序列号，在接收端通过一种滑窗机制，结合报文校验进行处理，防止重放攻击。报文在公网上传输，还可能会受到攻击者的数据篡改，在公网传输的逻辑通道上需要增加对报文数据的完整性、合法性进行验证。在报文发送端对报文数据进行校验，在报文接收端同样进行校验，防止报文在网络传输过程中遭到篡改。由于数据校验在传输过程中进行，校验算法对性能和耗时要求很高。BOBCAT使用了一种基于不断变化密钥的不可逆的私有检验算法，支持线速情况下全量数据校验。

3.4 加速服务

公网传输系统主要通过公网进行数据中心之间的数据同步，公网质量影响着该系统的传输质量。而在公网上，时刻发生着许多不可控的事件，例如施工导致的光纤断裂、海底地震导致的海缆中断、公网高峰期导致的拥塞、运营商进行网络变更导致的网络抖动，等等。如何提高公网传输体验成为一个重要的研究课题。业界在这一方面也给出了许多解决方案。一种方案是通过改进TCP的拥塞控制算法来进行TCP加速，一般称为单边加速，例如BIC、HTCP、TCP Vegas、CUBIC、Hybla、FastTCP、Veno、Westwood等。还有一种方式是通过网络双边部署设备，利用自定义的协议实现加速，称为双边加速。双边加速还经常引入压缩、缓存等技术来提升TCP性能。

相较来说单边加速更多用于应用层，需要在业务主机上进行部署，一般有较好的加速效果。但其缺点是普适性不强，每个业务自身特点各不相同，无法使用一种通用的加速技术来解决所有业务的问题。而双边加速对业务而言无感知，可以很好的为不同业务提供加速服务，更能解决共性的问题。因此，在网络层的基础架构上，更倾向于使用双边加速。

从影响传输速率的根源来分析，主要来自于公网的丢包率和延时两个方面。这里主要介绍BOBCAT降低公网丢包率的解决方案。从TCP拥塞控制的角度来看，网络丢包会对TCP的传输性能产生较大影响，如图Figure 6所示，对TCP协议来说网络丢包会将TCP的传输窗口迅速拉低。当然，目前针对此种现象有许多不同版本的内核协议栈进行了优化，这里的只展示了其中一种较原始的拥塞控制思路。

Figure 6 网络丢包对TCP的影响

针对TCP的此种表现，我们在实验室也进行了测试，测试数据基于内核版本3.0.36。通过实验结果可以验证上述结论，可以发现，丢包率的升高会导致TCP的吞吐量迅速地降低，如图Figure7所示。

Figure 7 丢包对FTP的影响

如何降低公网丢包率成为一个问题，很容易想到的一个方案是通过重传确认的方式来缓解公网丢包，BOBCAT即是使用这种机制来降低公网丢包率的。对数据中心网络而言，BOBCAT工作在TCP/IP模型的数据链路层，在BOBCAT上进行重传确认，就像将TCP的重传确认机制下移到数据链路层来处理一样，可以实现在上层协议感知到丢包之前完成重传，降低丢包对上层协议性能的影响。鉴于TCP对丢包十分敏感，对TCP的加速效果较为明显。　

BOBCAT的重传确认框架如图8所示。发送方在数据转发的同时将报文内容缓存一份在本地，接受方收到报文后根据收到的报文序列号返回对应的ACK信息，发送方的重传进程收集所有的ACK信息，并利用这些ACK信息对缓存进行处理。若ACK超时没有返回，则对报文进行一定次数的重传。简单看起来这种重传确认的思路与TCP的重传确认思路并没有什么区别，仔细分析一下，也会发现一些不同。

Figure 8 BOBCAT重传确认框架

首先，由于BOBCAT的重传确认逻辑工作在数据链路层，上层协议在检测到丢包也会进行重传，若数据链路层在上层重传之后再重传，将没有任何效果。因此BOBCAT的最大重传次数会比TCP少很多，确保在上层协议重传之前完成所需的重传操作，而不做无效重传。

其次，由于整个公网传输系统需要处理接近端口线速的网络数据，单位时间内需要缓存的数据量十分巨大，和普通TCP协议栈维护的缓存量不在同一个量级，如何实现这些缓存报文的存储、老化、释放、快速查找会是一个艰难的任务。　　

第三，重传报文需要占用端口带宽，而正常的业务转发报文应该比重传报文优先级更高，因此需要控制重传速率。　　

针对这些问题，我们主要用以下技术来解决。

（1）无锁的二级缓存管理。如前文提到的，为充分发挥多核CPU的处理性能，BOBCAT使用了多个CPU核进行报文处理，缓存如何在这些处理器核心之间存储、释放，是一个必须要处理的问题。我们采取了一种无锁的二级缓存技术来解决这个问题。

Figure 9 二级缓存框架

如上图所示，加封装进程在报文发送时进行缓存，每一个加封装进程维护独立的一块本地内存作为数据缓存。在缓存的同时，采用基于序列号的索引，将报文缓存信息存储在一级索引中。当重传进程进行处理时，只需要处理少量的索引信息，可以提高访存效率。同时，由于重传进程本身位于另外一颗CPU，跨CPU访问内存效率极低，通过少量索引的访问，可以避免大量数据的访问，提高访问效率。当重传进程发送数据时，也只需要提供索引信息，即可完成跨CPU的发送。实际的数据读写、发送均在CPU0进行，避免了使用QPI进行跨CPU的内存访问。

（２）“尽力而为”的重传确认算法

在线速转发时维护收发两端正确的执行重传确认处理逻辑，是BOBCAT网络加速的另一个难点。这里主要问题在于接收端的接收窗口维护。BOBCAT在接收端维护了一个接收窗口，用来判断什么时候需要对哪些报文进行确认。由于内存及访存时间限制，该接收窗口被设定为一个有限大小的值。正常情况下接收端收到业务报文会累积一定数量后向发送端发送ACK信息。但当出现丢包时，最新的ACK信息会滞留在当前丢包的位置一段时间，由于报文发送速度非常快，小包达到百万PPS级别，瞬间就会占满当前接收窗口。若持续等待丢包重传，将为影响正常的重传确认功能执行。因此，这里采用了“尽力而为”的思想进行重传确认。

首先通过维护一个有限的接收窗口，利用接收窗口里收到的报文信息进行确认。其次，维护一个最大最新的序列号，当出现大量报文超出接收窗口时，将接收窗口滑动到最大最新的值进行处理，防止部分丢包导致功能失效。另外，采用相对序列号进行大小比较，防止出现报文序列号翻转的情况。根据网络质量和负载情况的不同分别进行处理。

３.5 SDN实践

SDN（即Software Defined Network）是最近几年网络基础设施中很火的话题，其主要思路是将网络设备的控制面和转发面分离，进行实现灵活策略管理和流量控制。作为纯软件实现的公网传输系统，BOBCAT也进行了一些实践，取得了不错的效果。其架构图如下图所示。

Figure 10 SDN软件结构　

BOBCAT SDN为三层结构，第一层为user层，提供用户视图，主要面向网络管理员，其流量控制功能需网络管理员介入。第二层为controller层，主要功能是通过各种工具系统收集现网设备运行信息，通过定制的最短路径优先算法向上层提供抉择依据。并根据上层用户最终决策信息下发流量控制信息。控制器是SDN的核心，利用了腾讯在这方面已有的积累，此处不再展开描述。利用腾讯控制器组件，在其基础上开发私有APP实现信息采集及最优路径计算。第三层为device层，设备通过控制协议（OpenFlow）收发信息，执行上层指令实现流量调度功能。由于转发进程不希望处理复杂的控制协议，在设备端也将控制面与转发面进行了分离。控制面处理OpenFlow协议，并将其转换层相对应的流量添加到转发表中；转发面读取相应转发表信息，并根据该表内容进行转发。　

利用BOBCAT系统的流量调度能力，可以很容易的实现公网流量的切换，如图Figure 11所示，若在深圳天津之间公网出现故障，可以将业务流量牵引至上海，经由上海到达天津，实现流量调度功能。此功能支持全球范围内的公网传输系统流量调度，在该功能的支持下，网络管理员将真正成为交通管理员的角色，可以根据当前链路状况，适时的进行全局调度。

Figure 11 BOBCAT SDN应用实例

在该功能的基础上，公网传输系统还支持了基于隧道的自动调整功能。设备通过基于UDP的公网测速，可以得到实时的网络质量信息。利用得到的丢包和延时信息进行加权计算，获得链路综合质量信息，并根据此信息，选出Top-N的隧道并自动应用到转发表中，使转发程序保持使用较优的隧道进行转发。这里不再累述。

四、未来展望

公网传输系统目前已在腾讯网络中运营了接近3年时间，部署了100+台服务器，为分布在全球的公司业务提供了数百G的网络带宽，在提高网络可靠性、节约基础架构成本方面，发挥了重要作用，其加速功能在应用中也得到业务团队的肯定。公网传输系统为腾讯网络架构的演进提供了一种崭新的手段，许多网络结构中均有应用。利用软件的方式来解决网络的问题也逐渐成为一种网络从业者认可的思路，相信未来还会涌现出更多网络应用产品。未来我们还将面临更多挑战，云的落地需要我们对网络进行更多的改造，SDN的逐步成熟将在传统网络中掀起更高的改革浪潮，网络虚拟化对基础网络提出了更高的要求，网络加速等增值服务也要求网络更加智能。面对这些挑战，我们还需要做更多事情。期待软件的力量，在网络基础设施中发挥更大的作用。

新年快乐，明天就是大年夜团圆的日子拉，同学们都已经辛苦一年，最后小编祝大家一切顺利，红包多多，羊年喜气洋洋。 注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利；注2：本文图片部分来至互联网，如涉及相关版权问题，请联系tracyyun@tencent.com