Typo: Figure 1 Receive Flow Deliver的Deliver拼写错了。
这篇文章主要针对Linux内核对于短TCP连接的可扩展性差的问题，对TCP协议栈的设计和实现进行了优化。文章中的优化方案动机来自于新浪微博的后台服务器要处理高吞吐量的短时TCP连接，而传统的TCP协议栈的实现在核数增加，连接数量增加的情形下会遭遇各种性能瓶颈。作者们实现的Fastsocket也实际部署到了微博的后台服务器中。
TCP连接的可扩展性瓶颈主要来自两个地方，TCB（TCP控制块）的管理，和VFS（虚拟文件系统，因为socket被抽象成了文件描述符）的抽象。
TCB方面，Global Listen Table我理解为是维护来自同一端口的TCP连接和多个client之间的映射关系，这里的瓶颈在于简单的表级别划分还是会带来O(n)的遍历复杂度。Global Established Table我理解是维护全局所有TCP连接的表。由于它唯一，且被多核共享，所以同步锁的机制会带来很多冲突，影响性能。 另外，同一连接中收到的包和发出的包可能由不同的cpu核处理，这样可能引起缓存的颠簸。作者们希望通过“连接局部性”来解决这个问题，也就是同一个连接的操作最好都在同一个cpu核上处理。同时这自然也解决了ET表的划分问题。 最后，VFS对socket建立了inode和pentry。这样socket数目增多后，VFS的同步机制也会引入较高的开销。作者们希望解决这里的瓶颈，同时不改变对BSD socket API的兼容性支持。
从Fastsocket的架构设计来看，作者主要的思想是自下而上（网卡到用户应用层）的一种整体优化，具体通过设计PerCore Process Zone划分（隔离）的方式来消除不同连接、不同核、不同进程之间的耦合，从而减小同步机制带来的开销。除了将GET和GLT两张表分割成每个进程独享的局部表之外，Fastsocket还增加了两个中间层。Recive Flow Deliver是将TCP的包分发到对应的核上。fastsocket-aware VFS简化了VFS抽象的执行，绕过了不必要的操作，缩减了开销。
评测方面，研究者在新浪微博的集群上分析了两台机器的CPU利用率时序数据。由于负载均衡器的处理，这两台机器可认为负载一致，从而自然形成了对照实验。Fastsocket有效降低了CPU利用率（尤其是负载较重时），主要原因在于减小了同步开销。另外研究者还在nginx和HAProxy上通过benchmark测量了吞吐量数据。
Table1的评测很到位，测试了Fastsocket不同组件启用与否的情况下，锁的竞争的计数。这项测试直观地显示出哪些锁使用频繁，而fastsocket的不同组件对减少各种锁冲突的影响有多大。
连接局部性的指标是LLC mis ratio，和local packet的比例。
我理解这项研究工作的亮点在于跨层的优化，自下而上地，通过划分隔离共享数据结构，和绕过抽象层中不必要的操作来减少同步机制带来的开销。另外，以用户进程、CPU核为粒度的划分和隔离自然而然引出了对局部性进行优化的思想，通过对TCP连接和CPU核建立映射关系，而减小缓存的缺失，进一步优化性能。真实大规模IT业务的实验（新浪微博）是论文的加分项。