吞吐优化札记_wireguard-go 丢包

wireguard-go的转发模型相当棒，它将整个流程分成了3段流水线接力，下面是一个方向的逻辑，另一个方向省略：
​

加密池的设计好。考虑到加密是耗时操作，要减少串行加密延时，多个goroutine并行加密多个packet是不错的，但要加一个保序逻辑，上图中的Lock/UnLock就是干这个的。

但测试结果不如人意，3段流水线接力反而不如简单撸到底的boringtun。流水线旨在减少单流长程处理带来的吞吐损耗，但这只是在理想情况下忽略控制开销的结论。

为了保序引入的Lock/Unlock不是spin操作，阻塞睡眠引发协程调度，影响了CPU利用率。另一方面，大多现代处理器，加密解密并非大开销，并行加解密带来的延时收益甚至无法抵消保序逻辑带来的调度延时损耗。

这是golang写的，如果换成C写，Lock/Unlock换成spin而非睡眠，就省了goroutine调度，肯定炸天。幸运的是，goroutine开销并不很，还是那句话，runtime带来了便利，你总要交点小费。

wireguard-go的这个问题能不能解呢？必须有。

将控制开销降低就行。虽无法控制goroutine的调度，但可以通过减少Lock进而减少睡眠间接影响goroutine调度。

若追求整机吞吐最大化，每一个部分都动起来做有效的事情即可，又因现代处理器加解密并没有慢得离谱，考虑到控制开销可能淹没并行收益，将每个单流串行处理试试看(boringtun就是这么处理的)。

首先要证明加解密开销不大，很简单，将加解密goroutine数量减少到1，并没有单流吞吐损耗，下一步就是串行化，去掉开销很大的保序逻辑：

单流吞吐果然提升了15%左右。

如果并发上来了，所有加解密goroutine全部动起来，同时又少了Lock/Unlock带来的开销，有效动作占比更大，好极了。

昨晚睡觉前，突然想比较一下并行+重组和串行相比哪个更好。并行看起来更棒，但重组也是有开销的，直觉上我觉得串行更好，今晚吃了一碗热干面，也没什么事，就拿wireguard-go开刀，正好它里面有一个并行+保序的逻辑，比较一下，如果直觉正确，那这就是一种优化方案。记录下来。

浙江温州皮鞋湿，下雨进水不会胖。