Netfilter,iptables/OpenVPN/TCP guard:-(

做新传输协议，必须忘掉TCP。要是总记得TCP，就会潜意识中往TCP靠，TCP那些不合时宜的东西会影响认知和判断。曾经我将TCP通告窗口标量化做隧道协议，效果不错，所以我想将TCP本身的通告窗口也标量化。标量化就是通告窗口不再和序列号相关，仅代表允许发送的配额。要理解TCP滑动窗口为何不合时宜，要从最初开始。TCP最初是纯粹的GBN(Go-back-N)协议，没有SACK，没有ofoq，为支持GBN，滑动窗口是端到端流控的唯一选择，若UNA丢失，在它之后发送的数据均不会被接收。引入SACK后，接收端

网络对TCP很宽容，但TCP对网络并不宽容，这意味着转发节点必须小心翼翼处理TCP。核心IP网络本是尽力而为，面对TCP却有使不上劲儿的感觉。本文后面我会讲一个故事，在这个故事前，我先描述结论。转发节点无法并行处理同一条TCP流。若串行化，会有新问题，单程串行将影响TCP的burst，order pacing时序。转发节点的资源分配和利用严重影响TCP流的形态。无论两个CPU并行处理两个长程，还是分别处理一个半程，总吞吐和单包总延时都不变，不同的是对burst，order pacing的影响。两个并行

人类一共创造三个系统：第一个系统是原型系统，仓促的原型，一小撮爱好者造就，精简，刚刚够用，不多也不少。第二个系统是经理系统，经理组织无数次会议讨论再讨论设计而成，臃肿低效满足完备性。第三个系统回归到现实，在第一个系统上叠加做了减法的第二个系统，是沉淀的结晶。TCP属于第一个系统。这可以解释为什么它的性能差，以及为什么难以优化。TCP从来没被设计过，仅为实现字节流的可靠传输而为之，不多也不少。甚至IP从TCP分离出来形成两个层也是几年后的事。最初的TCP和性能不沾边，完全不在考虑范畴，甚至拥塞控

wireguard-go的转发模型相当棒，它将整个流程分成了3段流水线接力，下面是一个方向的逻辑，另一个方向省略：​加密池的设计好。考虑到加密是耗时操作，要减少串行加密延时，多个goroutine并行加密多个packet是不错的，但要加一个保序逻辑，上图中的Lock/UnLock就是干这个的。但测试结果不如人意，3段流水线接力反而不如简单撸到底的boringtun。流水线旨在减少单流长程处理带来的吞吐损耗，但这只是在理想情况下忽略控制开销的结论。为了保序引入的Lock/Unlock不是spin操作，

流水线不会缩短延时，但能提高吞吐。长程逻辑是转发吞吐劣化的罪魁祸首：​优化方案有两种：​多CPU涉及保序处理，比较复杂，一般不采用，如善用的RSS均不会对单流进行并行处理，因此一般将长程分割成多个短程，流水线接力。各软件转发产品的实现不谈，仅谈wireguard，抛砖引玉。wireguard采用的是第二种方式：这就是单流吞吐比Open虚拟专网好的原因，路线是对的，但wireguard-go未竟全功。我觉得loop1和loop2还是太长了，紧接着TUN的loop应该只做一件事：将TUN

原题应该是“以时间换空间的端到端”，但端到端可能不为人知，就说成TCP。TCP天生不为性能而生，TCP天生节省带宽和内存，天生的时间换空间。为节省空间开销，宁可多几轮来回。TCP天生以多花点时间来确保“可靠传输”这个底盘。体现在两方面：不允许乱序，节省接收端内存，否则就要维护ofo队列。TCP短头，增加数据载荷率，提高有效带宽利用率。1970年代，内存昂贵，网络带宽昂贵，除保证可用性，优化性能简直是中邪。空间约束下，TCP就成了TCP。结果是发送端获得的反馈信息不足，GBN就是自然的选择，几

我暂时将直连对等通信看作是一个去中心化的实例。都说互联网是去中心化的，其实并不是。虽然互联网的前身ARPA网的初衷是去中心化以防核打击，但发展到最后，显然这个目标并没有在互联网实现。现代互联网使用更多资源跑B/S，C/S服务，用于资源的获取，而不是对等通信。资源曾经集中在门户，如今集中在云机房，而云资源必然构建在从属于某个公司的平台，显然不是去中心的。P2P曾流行，但很快被遍地打压而销声匿迹。本文从TCP的视角刨一刨。建立TCP连接，要有一个主动端和一个被动端，其中被动端在收到主动端的SYN时，必须

前段时间写了篇随笔：我错怪了goroutine有点长，本文缩一下。我并不懂golang，只会照猫画虎，我一直以为goroutine是比thread更轻量的执行体，系统开销依然会随着goroutine的数量而线性增加，在大并发场景显然存在扩展性问题，但其实并不是。下图解释：​左上角是传统方式，有扩展性问题，右上角是异步方式，epoll收事件，loop处理，这是大家都认可的方式，下面是goroutine方式，和异步方式差异是不用自己loop事件，runtime帮调度，没有系统开销，为啥就觉得它会跟传

一个常见的面试题：UDP如何实现可靠传输。既然有TCP了，干嘛用UDP重新实现一遍，就算非要卷，能比QUIC更好吗？显然，这问题没意义。还有另一个问题，TCP如何实现不可靠传输。数据传输只有两个协议可选(这里不抬杠)，TCP或UDP，对于那些某些数据可以丢失某些却必须送达的传输业务而言，就要在UDP上重写一个协议，可理解为松散可靠传输。实现这种协议工作量不小，收益却不大。so，人们往往选择复用TCP，当然也继承了TCP的缺陷，如队头拥塞，而这是大多数卡顿，传输低效的根源。换句话说，TCP根本就无法实

又跟朋友聊TCP，这次说到了移动性。一个TCP连接是绑定五元组的，该连接的生命周期呢，五元组不可改变，如果IP变化了，需要重新建立一个新的连接，这是众所周知的。如果在TCP连接上直接构建应用，一旦IP地址发生了变化，该应用必须自己处理连接的重建。若希望应用无感于IP地址的改变，常见的方法是增加一个会话层。很早以前我做Open-V-P-N的时候，就是采用了这个方法，在协议头里增加了一个全局唯一的SID，用于识别连接。现在QUIC协议也是这样处理的。还有别的方案吗？还有一种扁平的方案，将IP地址的变化直

高吞吐，大并发，不怕数据大，最怕数量大。网络处理怕小包，文件操作怕小文件，无论每一个小包还是每一个小文件，它们均消耗元操作和元数据，如每一个数据包都触发一次中断，而中断是有固有调度开销的，中断数量越多，开销越大。小文件类似，再小的文件也要有inode，ident等固定元数据描述。元开销是固定的。时间方面和空间方面元开销都与数量正相关。时间开销体现在并发调度，本质上是查找，这个已经说了好多次。空间上是元数据开销，这个不谈。时间开销优化方法两种：一次处理尽可能多的量。多次操作尽可能合并成。第一

昨天的一篇短文：通用计算机器今天假期最后一天，接着说几句。图灵机将步骤按照时间展开，替代将部分空间中连线延展，成就了通用计算机器，我们现在的计算机都是图灵机的形式。这就必然会有内存和CPU之间的通信，就算如火如荼的存内计算也不过是小范围优化，既然词中还有“存”，便没有改变本质，内存和CPU依旧两隔。但时间展开和空间展开真的就是固然对立的吗？非也。虽然计算组件不能在空间扩展，因为太占地方，但已经按照时间扩展的步骤却可以自由组合和递归，实现新的功能。这便是Unix哲学的实例了。组合使用命令，cat

还是下面这句话：将固定的资源在所有使用者中分配，而不是为每一个使用者分配固定额度的资源。还是那个简单的倒换，通用计算机就设计出来了。人们就意识到内存和CPU之间的总线成了瓶颈，于是人们拼命缩短这条总线的长度，甚至将内存控制器封装进CPU内部。无论怎么折腾，CPU和内存依然内外两隔，沟通媒介始终存在。人们把锅甩给了冯诺依曼体系，甚至图灵机。对，就是那条纸带和会移动的机器头，它们始终内外两隔。这种分离带来的二者之间的沟通损耗是回避不了的，但也正是这种分离，让图灵机变得通用。把一个计算组件定义为输

我说过好几次Linux TCP不是全双工的，没人信，也可能不知道我在说什么，总是有人拿TCP规范来怼我，说TCP就是全双工的，两边可以同时发送数据，显然没get到我的点。Linux TCP半双工体现在以下方面：Linux TCP接收ACK反馈和由此反馈激励发送数据在同一个CPU上，不能同时进行。Linux TCP接收数据以及对该数据的即时ACK反馈在同一个CPU上，不同同时进行。Linux TCP socket发送数据和接收数据均需要lock socket，不能同时进行。这下说明白了吗？还不信

文言文为什么短？我是搞网络的工人，略懂文字，从Unix视角谈。Unix/Linux程序很像文言文，列举一些：ls, pwd, sed, awk, ab, bc, cd, cc, cat, dd, df, ex, fg, ip不是干这一行的基本不明白上面这些命令是干什么的。再看一些文言词：汝 子 若 君 尔 彼 其 或 所 何 安是不是很像。这里面有什么关联？存储开销Unix早期磁盘磁带昂贵，古代龟甲竹简丝帛纸张昂贵，信息越短越好。传输开销Unix早期直到1990年代，网络带

曾遇到一个很有意思的问题，当时给出了一个回答：https://www.zhihu.com/question/392259415/answer/2385499293​今天正好五一假期又出不去，把答案再深入细化一下。首先声明，我不是搞生物医学的，甚至连爱好都算不上，我是一个搞网络传输的普通工人，以系统设计的视角来瞻仰人体之妙。下图是一个简单的循环系统图示：很明显，唯一的心脏是以串行泵血的方式工作的，而肺泡却是多实例并行，多个肺泡组成一个肺叶，理论上肺叶的数量可以超过两个，为什么会这样呢？如果不这样

多条流共享同一瓶颈链路时，涉及到并发调度问题。调度在微观上就是查找，调度本身会带来开销。视角放远一点，我们仅当开销是个黑盒，不问细节，看看怎么回事。类比进程调度，多进程分时运行，想象中时间被所有进程完全分享，实际上调度本身也占用时间，随着进程规模增加，调度开销也增加，O(1)调度的代价是调度周期的延长，因此O(1)理论上不存在，现实中log级已很好。因此，时间利用率随进程规模增加而降低。开销与规模正相关，多流收敛也一样。多流之间互不相识，不知对方存在，完全自组织，靠感知带宽，RTT等反馈的变化知道别

并发的核心是查找，之前解释过，今夜豪雨，再说两句。并发问题实质是可扩展问题，好的并发系统开销不应随并发entity数量的增加而线性增加，时间复杂度应在O(n)以下。并发和并行不同，并行是同时执行，但entity数量并不永远和硬件数量匹配，当entity数量大于硬件数量，总会有多个entity共享一套硬件，一套硬件处理多个entity，就是并发。并发entity最终还是要串行，并发的本质是分时串行，并发处理的核心是“随时查找一个最适合使用时间片的entity。”并发技术是一种调度技术，调度多个enti

下午发了一则朋友圈：​接着第二个话题继续说。说说老本行相关的。信息传播的本质目的是互动。只有互动才能激起风暴。果真如此，有必要将信息大块大块地从一个地方复制到另一个地方吗？每次传输的信息只具有一个固定的含义，两次传输的信息彼此正交，这样效率才最高。如果有多个含义，就分多次传输，因为第一个信息的反馈会影响第二个信息。既然小信息才更好，为何大家将大部头视为经典呢？如果一本书写不厚，就会被轻视？直接原因是思维定势，人们在过去几千年一直这么认为，很难改变认知。根本原因是古代没有支撑小消息的传输的技术，

将固定的资源在所有使用者中分配，而不是为每一个使用者分配固定额度的资源。Windows为每个进程映射了一个独立的内核地址空间，布局非常正则，比如页表在固定的地址A，PCB在固定的地址B，该独立的地址空间通过MMU映射到物理内存。如下图：每个进程需要额外内存作为页表映射独立的内核地址空间本身，随进程增多，这部分内存开销线性增加。理论上Windows进程地址空间任何部分都可换出到磁盘，优点是系统可承载的进程数不受物理内存限制，缺点是换入换出会影响性能。好坏不评说。颠倒一下，还是那个技巧，每个进程不再独