[ipsec][strongswan] VirtualPN隧道网络加速FEC(forward error correction)

引用

跟一个网友就有关IPsec的网络加速以及降低延迟等问题进行了一些讨论，并总结了一写粗浅的看法。

因为FEC的资料并不多，所以分享出来，希望能被有需要的人看见：）

先说一下FEC。

我们使用ipsec的本质，就是在IP层之上建立一条软件的点到点通信链路。通过internet到底任意地方。

由于internet的广域性，或者传输介质或者距离的限制等，倒是数据包的丢失，损坏，高延迟扥各种问题。

对比于专线的方案。我们可是改善介质，做链路保障等提高服务质量。

那么在VirtualPN软件的层面上我们又能做些什么呢？ 试想在存储的解决方案中，我们引入和RAID增加冗余

的方法来提高容错能力。那么在网络传输中，是否也可以同样引入呢？

从一个更宏观的角度上，存储和网络本质上是一直的，都是通信。只不过前者跨越的是时间，后者跨越的是

空间。

现在引入我们在网络传输上的解决方案，它就是FEC和channel coding。

不知道为什么这方面的资料并不多，但是我个人却觉得它既有趣又有价值。

https://en.wikipedia.org/wiki/Forward_error_correction

[author: class_tong, date: 20190915]

正文

由于我实在是太懒了。在征得对方同意后分享邮件内容如下，不再进行整理：

嗯。xdp也是在内核里的。主要是用eBPF处理包流转的加速。因为要double esp的包，可能会与netfilter+xfrm面临着同样的内存管理问题？

另外，关于数据面，kernel bypass也有很多手段，可以参考一下：https://blog.cloudflare.com/kernel-bypass/

祝顺利。

On // : AM, xxx wrote:
> hi
>     感谢回复！我会 再深入研究下的；
>      对于 数据平面，目前都是基于kernel xfrm，绕不开kernel， 我倒是看到有新的研究基于XDP的课题：http://vger.kernel.org/netconf2019_files/xfrm_xdp.pdf
>
> 以上
>
>
>> On Sep , , at : PM, Cao Tong <tony.caotong@gmail.com> wrote:
>>
>> 你好，
>>
>> 非常高兴跟你一起讨论这个问题，让我有机会思考新的问题。
>>
>> 我刚刚花了一下时间简短的了解了一下这部分内容，相信一定不会比你了解的更多，接下来我说一下我的思路，希望对你能有所帮助。
>>
>> . 先说一下strongswan相关的。
>>
>> 我在strongswan里没有看见与FEC有关的任何内容。也就是说我相信它是不能配置的。再进一步，即使它能配置，它也没有把ESP包double的
>>
>> 这个能力。因为所有包的流转都是用linux kernel做的（我们以strongswan跑着linux kernel上为例）。
>>
>> 首先要分清楚一个概念，就是数据和控制。控制是指VirtualPN信道的创建、删除，维护等。数据就理解为ESP/AH包。strongswan只是一个管理工具
>>
>> 它通过与kernel通信，来进行配置。信道的保持和数据包流转，都在kernel里完成。
>>
>> 所以，现在可以确定你的问题和strongswan或者其他任何swan都没有关系。
>>
>>
>> 。 数据通路
>>
>> 1里边我假设了，数据通路是在linux kernel上完成的。实际上，这并不是唯一的选择。取决于你们的方案是什么样的。比如跑在BSD上。或者storngswan
>>
>> 有一个自己开发的数据通路插件。或者你们自己开发了数据面软件。这些都和linux kernel没有关系了。
>>
>> 我看了linux kernel和BSD，应该都没有FEC的功能。所以，无论数据面的方式是什么样的，FEC功能怕是都需要自己开发。
>>
>>
>> .  开发思路
>>
>> VirtualPN的场景分两类，site to site，peer to site/peer。 对于端点设备就两种可能site、peer。为了表达方便现在把功能简单化为数据包的double
>>
>> 对于site场景，就两种方式：封ESP前做，封ESP后做。对于peer模式，还多出一种在应用程序上处理的方式，就是在进入ESP封包前。也就是net-speader
>>
>> 这种方式。（我们聚焦在virtualpn gateway上，所以不讨论这种情况。）
>>
>> 于是，考虑到性能，自然选择ESP封装后进行FEC功能的实现。
>>
>>
>> . kernel上的FEC事项
>>
>> 如果你没有自研可控的数据面实现。那么现在只能聚焦在linux kernel上。
>>
>> 这个时候有是三个选择
>>
>> 。 在内核态做，改kernel。
>>
>> 。 在用户态做，如你说的网卡抓包的方法。回去其他，方法很多
>>
>> .   在virtualpn gateway的出口处加一台专用设备做FEC功能。
>>
>>
>> 按照你的思路我们讨论1。基于以上的分析，我觉得在esp_out() / ah_out()的时候做FEC是非常合理的一件事情，但是
>>
>> 我们并不仅仅是做发包double，而是要做FEC，所以，在收包的时候也是要处理的，还有要综合考虑。
>>
>> 另外，多倍发包势必牵扯到内存管理问题，这个复杂度可能一下就上来了。 除了netfiler的hook，还可以再关心一下xfrm module。
>>
>> 这里边怕是有很多细节。kernel我也不是特别了解，帮助有限。
>>
>>
>> . 其他
>>
>> 其实，综合考虑的话，我觉得4里边的2，3是一个很好的选择，可以将其统合成一个统一的方案，整理部署就是2，考虑高性能的部署就是3。
>>
>> 写成统一的程序。毕竟用户态开发要比内核态省事很多，成本并不一定会变高。
>>
>> 另外，这一切都是在kernel的前提下讨论的。如果有可控的数据通路软件的话，就完全是另外一回事了。
>>
>>
>> 以上，希望有所帮助。
>>
>>
>>
>> On // : PM, xxxx wrote:
>>> Hi here:
>>>     事情是这样的，目前有个基于IPSec 隧道的需求，国内网络环境对于UDP、跨运营商之间穿透是比较差的，UDP包可能被无差别直接丢弃。特别是高峰时间段或者国际网络的传输线路上，结果就是UDP具有较高的丢包率和网络抖动， 
IPSec上的应用就不会稳定：https://www.reddit.com/r/networking/comments/ah0z93/highreliability_tunneling_any_fecing_idea/
>>>
>>>     所以，上面链接也说了， UDP Tunnel需要一种丢包补偿机制，实践上我看到有两种方式：暴力多倍发包 和 基于FEC的算法补偿（https://github.com/wangyu-/tinyfecVirtualPN）。IPSec VirtualPN 也需要修改来支持。
>>>     我对与strongSwan 和 Linux kernel 都是新手，所以我想问的是
>>>
>>>     . strongSwan有插件机制支持修改隧道数据包发送方式么（1个包 发  个， 或者 fec 算法 发送）？ 或者需要netlink api 监听修改数据包？
>>>     . 还是得修改内核 IPSec 数据包的发送（http://kernelspec.blogspot.com/2014/10/ipsec-implementation-in-linux-kernel.html）在esp_out() / ah_out() 时候修改？
>>>     . 或者还是内通过内核的xfrm netfilter hook 机制 stolen IPSec包 进行计算重新再发送？写个kernel module ？
>>>
>>>     我还看到就是直接网卡抓包， 对与特定包进行再发送，比如这个项目：https://github.com/snooda/net-speeder
>>>
>>>
>>> Reference: https://www.cs.cmu.edu/~guyb/realworld/reedsolomon/reed_solomon_codes.html
>>>
>>>
>>> 以上
>>>
>>>
>> --
>> ------------
>> Cao Tong
>
--
------------
Cao Tong

[author: class_tong, date: 20190915]