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