网络性能优化的先驱智慧与启示

网络性能三要素：
最小的传输成本，即载荷率，头占比要尽可能小
尽量大的收发速率，说尽量大是因为要考虑与公平性的权衡
最少的计算资源完成上面两件事。
点评：我不能说 817 最牛逼，但它足够牛逼，我们今天所做的所有网络性能优化正是基于上述三要素。在 1982 年，David D. Clark 那帮家伙能有如此洞见，你说牛逼不牛逼，最关键的是他补充了一句：最后一点可能是实现高速所必需，但在慢速网络情况下，可能仅在资源消耗昂贵时才重要。但这些不同的目标经常相互冲突，例如，通常可以在计算机的有效使用和网络的有效使用之间进行权衡。因此，可能不存在成功的通用协议实现。
模块化，分层和接口化是影响性能的最主要原因；
架构师需要注意到在良好的代码结构和良好的性能之间存在微妙的平衡，而初级程序员并不具备这种认知，所以他们倾向于先满足正确性，再修改局部以提高性能，但这并不正确
这是核心方法论，大家心里都懂，却很难讲出来，讲不清就不讲了
彻底的性能优化需要更改整个架构，而不是单点；
所以说单独改一个点很难妙手回春，架构师需要强大的代码重构能力
网络协议可由进程，内核，协处理器，网卡实现；
看看现在的 DPDK，用户态协议栈，智能网卡，各种 PU
协议校验和计算，数据复制很耗时；
这导致了后来的 TCP 硬件卸载以及零拷贝技术
TCP 可根据传输类型分别优化，但内核做不到；
如果 TCP 一开始就区分了 “通信型 TCP” 和 “内容型 TCP”，那些 Nagle，Delayed-ACK，捎带 ACK 等权衡就不必要
通用性与性能优化要权衡，优化注定不通用；
不多说，也说不清
这篇文档不是解决了什么问题，而是在那个 TCP/IP 刚刚标准化尚未全面铺开的时代预见到了 TCP/IP 的实现将会遇到的性能问题以及针对这些问题的建议。事实证明，后续的 TSO 等硬件卸载技术，DPDK，xPU，网卡等等基本上都属于这些建议的具体化。

模块化，分层，接口的好处，允许对其中一层修改，即使改错了也能确信另一层不会因此而停止工作，然而一个固定的边界几乎不可避免地导致低效，任何领域都是，想象一下曾经的省界收费站和出国签证多么麻烦。

如果接口被组织为对字节的顺序读写，那么期望高吞吐传输的代码将无法实现它们的目标。如果接口基于虚拟内存，那么字节流语义将不再必要。前几天有网友评论，socket 支持 mmap 会怎样，那岂不是就是 RDMA 了，非常正确！但 socket 抽象成了文件描述符，屏蔽了底层的流式操作，以至于用户无法使用 offset 做任意读写，这是 TCP 低效的核心。

拙劣的翻译，“一个接口，正是因为它是固定的，不可避免地导致缺乏对一个层希望从另一个层获得什么的完全理解。” 这句话简直金句，划重点，要考。

我前面专门写了几篇文章赞美 VJ-Style，说实话 VJ 绝对是牛逼的实干家，用精巧的代码完成高效但却谨慎的工作，完成早期 TCP 性能重构的重要工作，致敬！但在 VJ 之前，VJ-Style 的核心思想早就在 RFC817 中体现：

RFC817 提到了 “TCP 很少重传”，所以在资源受限的时代不必花大力气优化重传队列，是不是跟我前几天的说法异曲同工，很荣幸自己早就获得了精髓。但在 TCP 进入高带宽时代后，重传队列的粗糙实现就拖了后腿，果不其然，Linux 4.14 内核后将其重构成了红黑树。