本来想说说 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 本不该被程序员感知。
