Unix/Linux内核协议栈的衰微，以及每年大量的行业工人输入，造成了网络数据面技术的内卷。
我经常和人一起讨论网络技术，各式各样的，也不仅限于技术，偶尔也吐槽下内卷，周末了总结下我的观点。
早在2013年，有一篇关于C10M的文章：
http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
中文翻译版本：
https://www.oschina.net/translate/the-secret-to-10-million-concurrent-connections-the-kernel
大致的意思就是揭露了Linux内核协议栈的各种性能瓶颈，结论是内核本来就不应该处理数据面，而仅仅保留控制面功能就OK了。在C10M问题之前，C1000K问题也是类似的。
当时移动互联网刚刚起来没几年，各互联网公司都还在忙着复制粘贴技术，先让业务跑起来再说，构建基础应用和不是基础设施，C10M问题尚未进入这些公司的视野，因此数据面技术内卷尚未开始。相关技术只是在酝酿。
一直到2015年，所谓的网络技术依然还是传统的路由，交换，QoS，流量工程…在2015年中，很多公司意识到C10M问题是必须要解决的，于是很多人开始被卷入洪流，包括我自己在内。我曾经被邀请去做转发优化，但后来终于还是没有成行。
到了2018年，应聘网络技术研发相关岗位的应聘者简历上普遍都有了“精通转发优化”这种句式，再往后，DPDK，FPGA，github上的用户态实现的基于DPDK的协议栈作品链接就成了简历上的标配，接着append进去的就是XDP，eBPF…
同移动互联网同时崛起的还有各类SDN，NFV技术，各类术语也开始寒武纪大爆发。
几乎每一个互联网公司纷纷开始实现自己的使用上述术语堆砌起来的核心网络，这些网络大同小异。甚至同一家公司的不同BG/BU，同一个BG/BU的不同部门，同一个部门的不同楼层都会稍微改改形成自己的版本。然而做这些事的人却是同一拨人，在不同的公司跳来跳去。
于是，内卷开始了。
跳槽之后几乎都会把在上家的经验积累落地到现家，来自不同上家的同事会落地不同但差别很小的技术，虽然从大体上看所有互联网公司的技术在趋同，但所谓的趋同也只是全局的趋同，比如说2016年时各公司拥有的技术情况如下：
T公司：aStack，bGW，dGWng，ePP
A公司：bStack，aGW，cGWng，fPP
H公司：cStack，cGW，eGWng，gPP
到了2020年的时候，情况如下：
T公司：aStack，bStackE，cStackE，dStack，bGW，aGWe，cGWe，dGWng，cGWngE，eGWngE，xxGWassd，ePP，fPPng，YA-gPP，…sadsd。
A公司：同上略改
H公司：同上略改
虽然尚未落地，但也在落地的进程中。
我听说T公司的工人安德森先生一撇说想做一个用户态的基于DPDK的TCP中继，我问为什么做这个，解决什么问题呢？工人安德森先生一撇告诉我为了完成KPI，因为楼上的工人亚历山大先生也在做这个，都要落地了，工人安德森先生一撇问我能不能帮忙招个人一起搞，不然亚历山大先生今年就五星好评了。我说你来我这里吧。
人还是那些人，事还是那些事，一一映射成了笛卡尔积，这是KPI导向下的内卷的根源，这些人，这些事，还在继续不断增加。
理智思考这件事，移动互联网营造出来的大流量让Linux内核协议栈不堪重负，C10M问题越发凸显，甚至C100M/C1000M问题也浮出水面，正确的做法确实是将数据面从内核里抽出来，要么upload到用户态，要么offload到网卡，这也显示了两种不同的生态：
- 对于使用Intel网卡的用户，Intel完全基于自家的CPU生态来推荐使用DPDK。同时卖CPU和网卡。
- 对于使用非Intel网卡的用户，由于没有CPU生态助力，则推荐闭环的SmartNIC，采用eBPF/XDP，FPGA等技术。
随着对转发性能要求越来越高，且故障响应要求越来越敏感，各大互联网公司都拥有规模越来越大的自建机房，网络核心设备也纷纷基于白牌设备自研，外在的看，是各种术语，DPDK，XDP，VXLAN，NFV，OVS，eBPF…但技术核心依然是如何快速处理网卡收到的报文的问题。
移动互联网应用的寒武纪爆发式的发展让互联网行业成了国内最赚钱的行业，各大985高校像蓝翔技校一样向互联网公司疯狂输出，互联网公司的现金流解决了大量毕业生就业问题，也为核心城市引入了大量的新户籍人口，当然同时受益的还有卖房子的。
互联网公司将每年的校招作为大事来办，校招看起来跟各大高校的招生一样，毕业生们平滑进入个大互联网公司成为工人，就好像之前在学校一样。工人基数构成了做事的基础。
一边是亟待解决的问题，一边拥有大量的工人，一推一拉，开干吧。必须提醒的是，我的意思并非是要表达所有的工人都涌入了数据面技术研发，我只是以此为例，因为我并不了解做互联网业务的内卷现状，可能更卷，也可能不。
亟待解决的问题虽紧急，但并不持续，一旦把积木搭起来，这就是个基础设施了，就像30多年前TCP/IP一直用了这么多年。DPDK也好，SmartNIC也罢，都只是实现高性能网络的手段，而不是目标，然而现实是，太多人做同样的事情之后，手段就成了目标。
如果工人亚历山大先生已经做了一个基于DPDK的TCP中继，工人安德森先生一撇如果不做一个类似的，就会担心自己的绩效，做同样的东西往往是不需要太多思考的，所以在紧张激烈的竞争环境下，下意识的赶紧做一件事是必须的，没有时间思考，否则没有东西落地就会被干掉。
我之前在一篇文章中举过一个例子，云南有个地方出那种印染的很漂亮的布，整个流程完全手工，所有的家庭早上很早起来开始忙，一直到很晚才收工，非常辛苦，问其中一个染户，为什么不去想一下去机械化呢，染户回答的大致意思是，如果去思考机械化的事情了，那么这段思考的时间是不能做活的，邻居家的产出就会超过自家。是不是有点意思了？
做一个SPF选路系统，在overlay网络上为一个端到端的TCP连接实时选择一条最优路径，这是一个好的KPI目标吗？应该不错，但显然不如下面这个，将Wireguard用DPDK实现，性能提高10倍。为什么把后面这个作为KPI目标更好呢？
SPF选路系统可能会比较难以看到效果，需要很长时间的打磨，互联网公司敏捷发布的流程以及一年两次绩效考核不允许这种打磨拖的太久，这也是这个KPI目标很难有人选择的原因。当某工人实现了DPDK版的Wireguard，他还可以顺势实现DPDK版的I-PS-e-c，XDP版的Wireguard，XDP版的I-PS-e-c，eBPF/XDP再实现一个NAT，性能提高10倍的那种，这样接下来至少3年，这位工人是安全的。
10倍的性能提升可量化，显得超猛，经理会非常欣赏这个。然而真的有遇到什么问题必须将性能提高10倍才能解决吗？设定一个目标的时候，首先要明确问题是什么，实现该目标能解决什么问题。TCP传输视频流就是卡顿，传输文件就是慢，这就是个现实的问题，现在要解决这个现实的问题，而不是生造一个单纯为了比拼数字的问题。站在这个视角看，做一个SPF选路系统才是正确的。
数据面技术，更多的是优化，这种优化是可预期的，只要去做了并且落地了，效果一般都杠杠的。换句话说，数据面是可优化的，于是大家就都会选择一个去优化，数据面优化非常契合互联网快速迭代小步快跑的敏捷特征。
问题来了。
为什么控制面技术没有发生内卷？
因为控制面技术有难度，不能立竿见影。网络控制面技术不像数据面技术那样仅在主机内生效，控制面技术是真正的网络核心技术，在所有主机之间生效，涉及到整个网络拓扑，该领域的优化非常难以把控，比方说很难解释一个TCP流在稳定pacing的情况下为什么会颠簸，中间发生了什么导致了这个结果，这是个全链路的问题，而不仅仅是本机的问题。上面提到的SPF选路系统就属于控制面。
万一没有效果怎么办？绩效考核的时候怎么跟经理交代，经理会等你3到5年吗？3到5年搞不好经理都跑路了。
控制面技术，涉及单机性能优化的路由表查表倒是可以做一做，不过也卷不起来，涉及到网络拓扑中与其他主机协作的，单机性能优化就不是重点了，更多的是计算性能，收敛时间，调度，公平性这些理论性更强很难快速收益的，便更是卷不起来了。
我昨天突然就想到一件事，以前也一直想做但没时间，什么事呢，就是在Debian系统上装一个rpm和yum，在Centos系统上装一个dpkg和apt-get，我不会用它们来下载软件包的，我只是觉得这件事有点难度，做出来显得自己好厉害。
浙江温州皮鞋湿，下雨进水不会胖。