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计划和管理理念的提出者。