两周内在 Github 上收获 1800+ 个星：内核层网络栈优化项目 Fastsocket 背后的故事

2014 年 10 月 18 日，当时就职于新浪操作系统团队的林晓峰在 Github 上开源了名为 Fastsocket 的项目，并在之后一天的中国 Linux 内核开发者大会上对该项目的原理和应用效果进行了介绍（演讲 slides 在此）。根据 Github 官网的介绍，Fastsocket 是：

• 高度可扩展的 socket
• 是 Linux 内核层面的底层网络实现
• 在多核机器上可实现极佳性能，24 核以内的性能增长呈线性，远超过默认内核在 12 核以上的机器就会出现性能下降的情况
• 非常容易使用和维护，应用代码无需变更
• 针对 kernel-2.6.32-431.17.1.el6/CentOS-6.5 的实现
• 已经在新浪的生产环境部署
• 由新浪的操作系统团队发起
• 清华大学操作系统实验室、Intel、哲思自由软件社区（Zeuux）对该项目均有支持
• 开源协议为 GPLv2

开源之后的两周之内，该项目迅速收获了 1800 多个 star 和 200 多个 fork，可以说成为了开源社区又一新的热点项目。近日，InfoQ 编辑对 Fastsocket 的主要维护人员林晓峰、新浪操作系统团队的负责人李晓栋进行了邮件采访，了解有关 Fastsocket 项目的更多背景。

InfoQ：简单介绍一下 fastsocket 的开发背景吧。这个项目主要是你在新浪这边跟清华大学的操作系统实验室一起合作。一开始是在什么时候发起的？发起的动机是什么？与清华大学的操作系统实验室、Intel 和哲思自由软件社区的合作模式是怎样的？

李晓栋：要说明清楚这点，需要从我们在新浪内部发起的 FastOS 计划谈起。

从技术上讲，FastOS 计划要做的是对 Linux 内核“协议栈、文件系统、IO”等不同子系统进行定向性的优化，以满足高性能网站的实际需要。Fastsocket 是 FastOS 计划中的第一个子项目，今后我们还会推出 FastTCP、FastIO……

从管理理念上讲，FastOS 期望打造的是一个有公司保障、但没有公司边界、开放式的生态系统，可参与该计划的不仅有新浪，而且还包括：各类硬件提供商、高校实验室、国内外自由软件组织、IT 媒体、互联网技术同行以及对我们计划感兴趣的任何开发者。所有正式加入我们 FastOS 合作计划的组织和个人，不仅可从共享通道中获得各合作方提供的软硬件及宣传资源，更为重要的是： 在对其它合作方利益无损的前提下，可以各取所需，实现合作成果的最大化分享。前面提到 FastOS 计划是有公司保障的，一是指该计划中所有的子项目都是在新浪生产环境中被正式使用的，所有公开的测试数据都是真实的，有可信度方面的保障；二是指 FastOS 计划的日常运作管理由新浪操作系统团队做长期保障，有一套明确的治理细节和管理流程，同时我们会充分考虑并切实避免合作方之间的利益冲突。 在这里，我们也诚邀请大家加入进来。

林晓峰：Fastsocket 项目与 2013 年初正式立项，该项目最初要解决的问题就是要提升七层交换服务的 Haproxy 的单机性能。提升单机性能根本原因在于降低成本，包括硬件相关成本和集群运维成本。经过 Haproxy 系统详尽分析后，我们发现大部分 CPU 资源消耗在 kernel 里，并且在多核平台下，kernel 在网络协议栈处理过程中存在着大量同步开销。据此，我们将开发 kernel 并行网络协议栈作为核心目标，来满足未来多核平台下万兆高性能的网络需求。随着 Fastsocket 展现出强劲的性能优势，以及在新浪生产环境落地，我们希望可以将项目成果整理过学术论文，并有信心冲击国际顶级系统和网络方面的技术会议。借助合作伙伴 Intel 的牵线，我们联系到了清华操作系统中心的陈渝教授，我们一拍即合的开始 Fastsocket 项目的深入合作，并且完成了 Fastsocket 论文，并已经向相关会议投稿，目前在等待结果。

InfoQ：如你之前的分享所说，多核机器在没有优化之前，CPU 资源大多消耗在锁上面了。多线程的性能提升一般有哪些手段，各自的原理是什么？

林晓峰：我并不是多线程编程专家，不过可以给一些有关多核平台性能优化的通用建议。设计程序框架的时候，要尽可能的避免多线程访问需要同步的共享资源，互斥上锁是多核平台性能第一杀手，每个线程只访问自己的数据是多核平台最高效，用户程序和系统内核里都一样。另外，线程数量不宜太多，并最好和核心绑定，线程调度也是有开销的，保持线程在一个核心上运行可以让 CPU cache 更高效。

InfoQ：简单介绍一下 Fastsocket 提升性能的技术原理？做了哪些技术上的实现或优化？

林晓峰：Fastsocket 提升性能，主要在于提高了 kernel 网络协议栈的效率，所以网络 I/O 密集的应用可以收到很好的性能提升效果。Fastsocket 对网络协议栈内部优化，在 github 上的主线有总计 7 个优化特性。这些优化可以分为两个维度。

第一个维度是多核扩展性的优化，也就是让 kernel 网络协议栈在多核平台发挥多核的并行处理优势。这个维度又可以分为两个方向：一是，将网络协议栈处理的关键数据结构做 CPU 核心间的隔离，使得每个核心有完全本地的访问数据，从而消除了执行路径上核心间的同步开销。二是，使得任意的某个 TCP 连接的全部处理，都在一个核心上完成，这样可以最大化的提高 CPU cache 利用率。

第二个维度是单核性能的提升，也就是不考虑多核同步的情况下，如何提升网络协议栈在单个核心上的绝对性能。这个维度也可以分为两个方向：一是，将 kernel 中的通用服务为网络 I/O 做专用定制，来提升网络协议栈的性能。二是，做网络协议栈的跨层优化，改变传统协议栈 TCP/IP 协议栈的严格分层处理，将传输的关键信息垂直贯穿网络协议栈，来做全局的优化。

InfoQ：Nginx 在 CPU 均衡上已很不错了，factsocket 对于吞吐量的增加是如何实现的？后续是否考虑做成 nginx modules？针对 HAProxy 的实现与 Nginx 一样吗？有什么差异？

林晓峰：Fastsocket 是内核层面的优化，对用户程序是透明的，并不需要开发 Nginx 模块来支持。Fastsocket 对应用程序来说通用的，提升的是内核网络协议栈的效率。

InfoQ：吞吐量的提升通用于 4、7 层代理吗？

林晓峰：Fastsocket 对于网络性能的提升，适用于使用 socket API 来进行网络 I/O 的应用程序，所以我们将它命名为 Fastsocket。如果 4 层代理是指 LVS，那是 Fastsocket 是不适用的，因为 LVS 功能是借助 kernel 里 Netfilter 框架实现的。

InfoQ：像 Fastsocket 这类以性能优化为主打的开源项目，品质保障、技术方案选择、成本管控非常重要，你能介绍一下这方面的经验吗？

李晓栋：在做性能优化的过程中，很多时候我们往往会陷入到仅关注性能指标的误区，而忽视了程序交付给运维人员后的部署成本、运维成本。比方说：是否跟现有的上层软件、运维手段兼容？有无自动化的部署脚本？应急回滚是否方便？是否提供了良好的统计和追踪机制？等等等等。这些都需要在方案设计环节充分考虑，否则很有可能出现“运维成本” 大于“性能提升所节省的硬件成本”，最终导致无法在生产环境中很好地使用起来。也就是说，我们需要在性能和可运维之间找到一个最佳平衡点。其实在 Fastsocket 之前我们还有一版内部代号为“Hydra”的预览版，性能比现在的 Fastsocket 要更好，但需要修改 haproxy、nginx 等上层软件的代码，运维成本过高，因此被我们果断放弃了。关于品质保障，我觉得最好的办法就是，在设计测试用例时，要把生产环境中可能出现的各类正常、非正常操作和情景尽量都考虑进去，最好能让比较资深的运维人员参与到测试用例设计中。当然，测试过程中，细心必不可少，要能敏锐捕捉异常情况。

InfoQ：Fastsocket 开源之后立刻在 Github 上得到了上千个 star，看来很多人也有这方面的需求。目前主要得到的反馈有哪些？

林晓峰：Fastsocket 在 Github 上正式开源到现在刚两周多，到写稿时已经接近两千 star，这是出乎我们意料的。

我们收到的反馈主要分为两方面。一是，具体是如何实现的，对其性能的大幅性能的技术点很有兴趣。二是，比较关注 Fastsocket 是否有移植到 3.X kernel 版本和合并到 kernel 主线的计划。在 Haproxy 的 mailing list 上也看到关于 Fastsocket 的讨论，很高兴的看到 Haproxy 作者对我们项目也很感兴趣，并表示可以考虑对 Fastsocket 进行直接支持。

InfoQ：有其他公司的人来参与支持这个吗？未来以开源模式更新，对于项目的 commit、review 机制有什么计划？

林晓峰：据我个人所知，已经几家大型互联网公司对 Fastsocket 有试用的兴趣。目前项目的 commit 主要采用 Github 的 pull request 机制，由我来 review 代码。未来希望可以吸纳更多活跃的开发者作为 committer，用社区方式去维护 Fastsocket 项目。

InfoQ：Fastsocket 后续对新版本的内核、新版本的 CentOS 的支持，计划用怎样的方式去长期维持？

李晓栋：Fastsocket 对不同版本内核和 CentOS 发行版的持续支持，采用两种方式：一是由新浪根据生产环境需要和操作系统使用策略，适时升级，这种方式相对比较稳健和持续，但更新周期相对要长一些。第二种方式是依托社区的支持，目前已有热心贡献者愿意帮助我们将 fastsocket 移植到 CentOS7 下，在这里我们也表示深深感谢。

受访者简介

林晓峰，前新浪网高级系统开发工程师，关注网络，关注高性能，关注 Linux 内核。

李晓栋，新浪网研发中心高级技术经理，有十年的互联网工作经验，是“新浪软件负载均衡系统” 和“ 新浪操作系统管理与优化”方面的重要开拓者，也是 FastOS 计划和管理理念的提出者。