加密一条保序的数据流_对数据流加密

数据流传输过程中，包括不限于DPI，加解密等操作会对吞吐和延时带来大损害，因此倾向于对此类操作投放大资源。

在流传输过程中串行加解密不可取，应采用线程池，倾全系统之力并行做最困难的事。这种思路不可避免地遭遇队列设计问题。

请求/服务模型，用单队列而不用多队列，理由如下：

加密一条流应该怎么做：
​
如果是两条流呢？下图展列出一个问题，如何回答：
​
To extend or not ? No！
加解密队列不能按流扩展成多个，数目应该固定，不然就会陷入多队列的深渊。正确的做法如下：
​
要点不在流队列有多少，流队列亦可按照五元组hash成固定数目，要点在于，加解密队列一定要固定，且加解密线程一定要轮询从这些队列中取包。

现在，总结一下本质。

不要拿资源和请求做固定映射。

整个系统中，所有资源就是线程池里的加解密线程，这些资源是固定的。最高效的方式就是让所有资源全动起来。参考前天的文章可以得到一个共性的方法：
https://zhuanlan.zhihu.com/p/492863461​
要让固定的资源去调度请求，而不是反过来。如果为每个流分配一组加解密资源，无异于Apache之于Nginx，为每个请求分配一个线程。

从某个队列取出的某个请求若占用线程过久，多队列情形，该队列后续的请求均阻塞，即使其它队列对应的线程空闲，也无法前来处理，这些线程的空转便是资源浪费，落实下来就是对吞吐和延时的损害。

最后，指明一个明显的疑惑点。

单队列不会遇到锁问题吗？多个线程抢一个队列锁不是饱受诟病吗？使用多队列不正是解除这把锁从而释放性能的妙计吗？

No，No，No！很多人不但不理解场景的重要性，也不理解设计是一回事，实现是另一回事。

先说场景。在数据流通路场景下，单队列锁确实被诟病，此时应该用多队列拆锁。但加解密完全不是通路，而是一种服务，将数据包进行加解密是典型的请求/服务模型。

再看设计和实现。锁开销只是一个实现问题，不同的锁也有差异，本末考虑，锁开销在整体开销中可能微不足道。Intel最新一项技术也是本文所描述的思路，但它是硬件实现，另外，wireguard-go的加解密机制亦如是，单独的go channel完全不是瓶颈。

近日做了一些颠三倒四的优化，数据上看，单队列总吞吐性能秒杀多队列，使用多队列似乎有炫技之嫌疑。区分通路模型和请求/服务模型非常重要。分不清工作日和周末，随便写一篇。

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