引用
跟一個網友就有關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]