前言

前面啰啰嗦嗦的几篇文字，各个方面介绍了Fastsocket，盲人摸象一般，能力有限，还得继续深入学习不是。这不，到了该小结收尾的时候了。

缘起，内核已经成为瓶颈

使用Linux作为服务器，在请求量很小的时候，是不用担心其性能。但在海量的数据请求下，Linux内核在TCP/IP网络处理方面，已经成为瓶颈。比如新浪在某台HAProxy服务器上取样，90%的CPU时间被内核占用，应用程序只能够分配到较少的CPU时钟周期的资源。

经过Haproxy系统详尽分析后，发现大部分CPU资源消耗在kernel里，并且在多核平台下，kernel在网络协议栈处理过程中存在着大量同步开销。

同时在多核上进行测试，HTTP CPS(Connection Per Second)吞吐量并没有随着CPU核数增加呈现线性增长：

内核3.9之前的Linux TCP调用

• kernel 3.9之前的tcp socket实现
• bind系统调用会将socket和port进行绑定，并加入全局tcp_hashinfo的bhash链表中
• 所有bind调用都会查询这个bhash链表，如果port被占用，内核会导致bind失败
• listen则是根据用户设置的队列大小预先为tcp连接分配内存空间
• 一个应用在同一个port上只能listen一次，那么也就只有一个队列来保存已经建立的连接
• nginx在listen之后会fork处多个worker，每个worker会继承listen的socket，每个worker会创建一个epoll fd，并将listen fd和accept的新连接的fd加入epoll fd
• 但是一旦新的连接到来，多个nginx worker只能排队accept连接进行处理
• 对于大量的短连接，accept显然成为了一个瓶颈

Linux网络堆栈所存在问题

• TCP处理&多核

  • 一个完整的TCP连接，中断发生在一个CPU核上，但应用数据处理可能会在另外一个核上
  • 不同CPU核心处理，带来了锁竞争和CPU Cache Miss（波动不平衡）
  • 多个进程监听一个TCP套接字，共享一个listen queue队列
  • 用于连接管理全局哈希表格，存在资源竞争
  • epoll IO模型多进程对accept等待，惊群现象

• Linux VFS的同步损耗严重

  • Socket被VFS管理
  • VFS对文件节点Inode和目录Dentry有同步需求
  • SOCKET只需要在内存中存在即可，非严格意义上文件系统，不需要Inode和Dentry
  • 代码层面略过不必须的常规锁，但又保持了足够的兼容性

Fastsocket所作改进

1. TCP单个连接完整处理做到了CPU本地化，避免了资源竞争
2. 保持完整BSD socket API

CPU之间不共享数据，并行化各自独立处理TCP连接，也是其高效的主要原因。其架构图可以看出其改进：

Fastsocket架构图可以很清晰说明其大致结构，内核态和用户态通过ioctl函数传输。记得netmap在重写网卡驱动里面通过ioctl函数直接透传到用户态中，其更为高效，但没有完整的TCP/IP网络堆栈支持嘛。

Fastsocket的TCP调用图

• 多个进程可以同时listen在同一个port上
• 动态链接库libfsocket.so拦截socket、bind、listen等系统调用并进入这个链接库进行处理
• 对于listen系统调用，fastsocket会记录下这个fd，当应用通过epoll将这个fd加入到epoll fdset中时，libfsocket.so会通过ioctl为该进程clone listen fd关联的socket、sock、file的系统资源
• 内核模块将clone的socket再次调用bind和listen
• bind系统调用检测到另外一个进程绑定到已经被绑定的port时，会进行相关检查
• 通过检查sock将会被记录到port相关联的一个链表中，通过该链表可以知道所有bind同一个port的sock
• 而sock是关联到fd的，进程则持有fd，那么所有的资源就已经关联到一起
• 新的进程再次调用listen系统调用的时候，fastsocket内核会再次为其关联的sock分配accept队列
• 结果是多个进程也就拥有了多个accept队列，可避免cpu cache miss
• fastsocket提供将每个listen和accept的进程绑定到用户指定的CPU核
• 如果用户未指定，fastsocket将会为该进程默认绑定一个空闲的CPU核

Fastsocket短连接性能

在新浪测试中，在24核的安装有Centos 6.5的服务器上，借助于Fastsocket，Nginx和HAProxy每秒处理连接数指标（connection/second）性能很惊人，分别增加290%和620%。这也证明了，Fastsocket带来了TCP连接快速处理的能力。 除此之外，借助于硬件特性：

• 借助于Intel超级线程，可以获得另外20%的性能增长
• HAProxy代理服务器借助于网卡Flow-Director特性支持，吞吐量可增加15%

Fastsocket V1.0正式版从2014年3月份开始已经在新浪生产环境中使用，用作代理服务器，因此大家可以考虑是否可以采用。针对1.0版本，以下环境较为收益：

• 服务器至少不少于8个CPU核心
• 短连接被大量使用
• CPU周期大部分消耗在网络软中断和套接字系统调用上
• 应用程序使用基于epoll的非阻塞IO
• 应用程序使用多个进程单独接受连接

多线程嘛，就得需要参考示范应用所提供实践建议了。

Nginx测试服务器配置

• nginx工作进程数量设置成CPU核数个
• http keep-alive特性被禁用
• 测试端http_load从nginx获取64字节静态文件，并发量为500*CPU核数
• 启用内存缓存静态文件访问，用于排除磁盘影响
• 务必禁用accept_mutex（多核访问accept产生锁竞争，另fastsocket内核模块为其去除了锁竞争）

从下表测试图片中，可以看到：

1. Fastsocket在24核服务器达到了475K Connection/Second，获得了21倍的提升
2. Centos 6.5在CPU核数增长到12核时并没有呈现线性增长势头，反而在24核时下降到159k CPS
3. Linux kernel 3.13在24核时获得了近乎两倍于Centos 6.5的吞吐量，283K CPS，但在12核后呈现出扩展性瓶颈

HAProxy重要配置

• 工作进程数量等同于CPU核数个
• 需要启用RFD(Receive Flow Deliver)
• http keep-alive需要禁用
• 测试端http_load并发量为500*CPU核数
• 后端服务器响应外围64个字节的消息

测试结果中：

• fastsocket呈现出了惊人的扩展性能
• 24核，Linux kernel 3.13成绩为139K CPS
• 24核，Centos 6.5借助Fastsocket，获得了370K CPS的吞吐量

实际部署环境的成绩

8核服务器线上环境运行了24小时的成绩，图a展示了部署fastsocket之前CPU利用率，图b为部署了fastsocekt之后的CPU利用率。 Fastsocket带来的收益：

• 每个CPU核心负载均衡
• 平均CPU利用率降低10%
• HAProxy处理能力增长85%

其实吧，这一块期待新浪公布更多的数据。

长连接的支持正在开发中

长连接支持，还是需要等一等的。但是要支持什么类型长连接？百万级别应用服务器类型，还是redis，可能是后者。虽然目前正做，但目前没有时间表，但目前所做特性总结如下：

1. 网络堆栈的定制
   • SKB-Pool，每一CPU核对应一个预分配skb pool，替换内核缓冲区kernel slab
     • Percore skb pool
     • 合并skb头部和数据
     • 本地Pool和重复循环使用的Pool（Flow-Director）
   • Fast-Epoll
     • 多进程之间TCP连接共享变得稀少
     • 在file结构体中保存Epoll entry，用以节省调用epoll_ctl时红黑树查询的开销
2. 跨层的设计
   • Direct-TCP，数据包隶属于已建立套接字会直接跳过路由过程
     • 记录TCP套接字的输入路由信息（Record input route information in TCP socket）
     • 直接查找网络套接字在进入网络堆栈之前（Lookup socket directly before network stack）
     • 从套接字读取输入路由信息（Read input route information from socket）
     • 标记数据包被路有过（Mark the packet as routed）
   • Receive-CPU-Selection 类似于RFS，但更轻巧、精准与快速
     • 把当前CPU核id编码到套接字中（Application marks current CPU id in the socket）
     • 直接查询套接字在进入网络堆栈之前（Lookup socket directly before network stack）
     • 读取套接字中包含的CPU核，然后发送给它（Read CPU id from socket and deliver accordingly）
   • RPS-Framework 数据包在进入网络堆栈之前，让开发者在内核模块之外定制数据包投递规则，扩充RPS功能

Redis测试结果

测试环境:

• CPU: Intel E5 2640 v2 (6 core) * 2
• NIC: Intel X520

Redis配置选项:

• TCP持久连接
• 8个Redis实例，绑定不同端口
• 使用到8个CPU核心，并且绑定CPU核

测试结果：

• 仅开启RSS：20%的吞吐量增加
• 启用网卡Flow-Director特性：45%吞吐量增加

但需要注意：

• 仅为实验测试阶段
• 为V1.0补充，Nginx和HAProxy同样会收益

Fastsocket v1.1

V1.1版本要增加长连接的支持，那么类似于Redis的服务器应用程序就很受益了，因为没有具体的时间表，只能够慢慢等待了。

以后一些优化措施

1. 在上下文切换时，避免拷贝操作，Zero-Copy
2. 中断机制完善，减少中断
3. 支持批量提交，降低系统函数调用
4. 提交到Linux kernel主分支上去
5. HugeTLB/HugePage等

Fastsocket和mTCP等简单对比

说是对比，其实是我从mTCP论文中摘取出来，增加了Fastsocket一栏，可以看出人们一直努力的脚步。

有一个大致的印象，也方便对比，但这只能是一个暂时的摘要而已，人类对性能的渴求总是朝着更好的方向发展着。

部署尝试

怎么说呢，Fastsocket是为大家耳熟能详服务器程序Nginx，HAProxy等而开发的。但若应用环境为大量的短连接，并且是小文件类型请求，不需要强制支持Keep-alive特性（短连接要的是快速请求-相应，然后关闭），那么管理员可以尝试一下Fastsocket，至于部署策略，选择性部署几台作为实验看看结果。

小结

本系列到此算是告一段落啦。以后呢，自然是希望Fastsocket尽快发布对长连接的支持，还有更高性能的提升咯 :))

资源引用

• fastsocket github
• fastsocket优化网络性能原理