本来想说说 tcp fastopen(tfo)，但没什么意义，看 rfc7413 好了，还是 tcp 的惯常套路，引入一个新特性，解决了某个问题，带来一些新问题，然后就是各种 tradeoff，哪里适用哪里不适用。久而久之，tcp 就成了一个极其拧巴的协议，都烦，但谁也逃不过，但凡 tcp 问题都不是容易解决的，都是仁者见仁的形而上。
昨天刷到一个搞云原生项目管理的经理 up 主竟然单独出一期视频讲 tcp 超时，我就拧巴了，说明 tcp 真就是一团乱麻，得好好理一下。
tcp 是 internet(首字母 i 应该大写) 开山协议，后来从中分出了 ip，就是 tcp/ip 第四版，可见前面至少折腾了三个版本，其实远远不止。事后来看，这就是 tcp 拧巴的核心原因，如果 tcp/ip 是设计出来而不是进化出来的，应该是个反过来的过程，先有一个尽力而为的 ip 奠定瘦网胖端的细腰基础，然后在其上铺设其它协议。
果真如此的话，分层协议就没了传输层，协议会更加平坦，不会有 tcp 协议，更不会有 udp，而是 app 自决，由 app 自行规定传输控制语义，标准化的过程会更自然，哪个 app 比较流行，哪个 app 规定的传输控制语义就是标准，就像 quic 后来做的那样，其底色就是流行的 http，但 quic 却不为路由器交换机所知，这才是真正的端到端。
但事实和理想是相反的，tcp/ip 不是设计出来的，而是进化出来的，所以 iso/osi 说好的分层协议层间隔离就成了瞎话，它们本质是不同的东西。tcp 既没有隔离上层，也没有隔离下层，我就说几个例子。
对上层，程序员完全在 tcp 之上编程(inet steam socket)，如果 tcp 发生异常比如断了，程序员必须显式处理，一大堆恶心缠绕的代码在处理异常，这种习惯慢慢成了范式，以至于 quic 已经有了连接迁移能力时，程序员依然害怕五元组变化。当谈到 google 家的 plb 时，人们首先想到的不是它的作用，而是它的问题，"它是如何更换五元祖不导致连接挂掉的？" 连接挂就挂了呗，为什么 app 和 tcp 之间没有一个 lib 解决这个问题呢。程序员害怕 tcp 断，但其实 tcp 本不该被程序员感知。
对下层，tso/gso，lro/gro 依赖顺序 stream，但传输优化却要乱序，这两者相悖，但网卡还是害怕 tcp socket 在 cpu 间迁移，不然它那些个 offloading，rss 就不起作用，空耗复杂性，当我提到这两者相悖时，程序员怼我，拼命维护 offloading 和 rss，大意是 "我靠，你怎么连优秀的 rss 都喷"，我就说，有了 rss，你怎么玩乱序。
网络和 cpu 完全不同，带宽的发展是无关比特并行度的提高，而 cpu 则被串行流约束，两者如不解耦，性能根本上不去，然而程序员思维大大偏向 cpu，他们根本无法理解如果取消了流的串行约束，还能剩下什么。
核心交换容量都 100Tbps 了，还在玩 lro/gro，你们难道不知道它们受限于 cpu 吗，这还没考虑内存墙，你们懂交换容量吗，你们拼命节省 cpu，但你们忍心浪费核心交换机的背板能耗吗。懂网络的程序员很少，无论 xdp，dpdk，offloading，用户态，在他们没看懂近乎无限的交换容量前，他们完全不懂如何浪费这种容量，将精力集中在 cpu 没错，但错在他们忽略了带宽。
tcp 已经运行 40 年，虽然大家都在谈 tcp/ip 分层，但它和分层思想是相悖的，tcp 贯穿了从 socket 到网卡，在路由器，交换机，都有 tcp，tcp 无处不在，侵染了系统思想。
一个 web 前端程序员懂 tcp，一个网卡驱动程序员也懂 tcp，看起来都很精通，但其实并不懂，不怪人，只怪 tcp 太拧巴。当然，说的都是经理。
吃饭了。
浙江温州皮鞋湿，下雨进水不会胖。