程序员人生 网站导航

OpenVPN多处理之-最新架构

栏目:互联网时间:2014-09-29 22:03:28
好久没有更新这个系列了,因为我之前也说过,前段时间实在太忙了,而且早在一个月前就预示着本月将更加忙!事实也确实如此!终于在国庆前夕完成了既定的计划,心里也终于可以长出一口气了。最近在忙什么呢?其实就是OpenVPN!既然OpenVPN-ng已经不在计划内,那么让OpenVPN支持多处理就是必然要做的了。

       还记得下面这张图吗?我暂且叫它版本1:





起初,我一直以为画完这幅图就已经证明自己对OpenVPN很精通了,后来我慢慢知道我错了,于是,我画出下面这幅图的时候,事实证明我当初的理解是多么肤浅!下面这幅图我称为版本2:




版本1的出现是在2012年,那说明我对原生的OpenVPN已经有了比较深刻的理解,但是在经历了2012的后半年,2013年的整年,2014年的上半年,我一直在等待OpenVPN的更新升级,这期间我也一直在关注硬件和网络技术的进展,OpenVPN落后了,谁也没有提到过这一点,等到了2014年的农历年前后,我觉得我该做点什么了。就这样,出现了版本2。如果说之前的文章展示的都是设想,那么有了这副版本2之后,它就是一个实际的实现了,虽然是最简的实现。目前还有很多TODO:
1.目前每一个multi_instance只能由一个线程的multi_context处理。
当初我希望的是所有的线程都能处理所有的multi_instance,但是由于如此一来锁开销太大,只有作罢。事实上OpenVPN的原生架构很难实现多线程扩展,因为每一个multi_instance都有一个buff,每一个context也有一个buff,每一个multi_context的所有instance共享一个buff,这些buff被复制来复制去,很难实现细粒度的锁,因为你很难定义什么是一个不可打断的事务。
2.目前的多队列TUN驱动在返回包队列分发的实现有些粗糙。
3.TUN驱动模块和OpenVPN之间的耦合度太高,不利于分别扩展升级。
4.线程间的信号分发机制太粗糙。
5.如果OpenVPN的某个线程从tun收到一个广播包,分发效率太低。
6.客户端无法实现多进程打开同一个虚拟网卡,而只能捆绑多个虚拟网卡。
...
以上这些都是需要慢慢完善的。我希望自己不会就此作罢,也希望和高手们进一步交流。
       在实现的过程中,遇到过无数的问题,和起初设计的时候想象的根本不一样,很多细节都没有考虑到。比如tap的ARP广播分发问题,当时我觉得随便分发到一个线程即可,后来发生了无数次的段错误,assert失败...最终发现,即使是ARP也没有什么特殊的,只要解析出ARP的内容中的sip和dip即可,将它和IP报文同样对待...
       还是那句话,如果你能画一张图把一个技术展示明白,那么你绝对掌握了这项技术,如果你画图的过程中,突然不知道怎么画了,那么这点就是你的技术盲点。不要抱怨不会用画图软件,纸笔伺候,手绘即可。手绘图更能让你的精力集中在图本身而不是画图软件怎么用,因为你用你的脑子驱使你的手,借助笔的硬度和铅,墨水等在纸上留下痕迹,你的大脑完全起100%的作用,反之你用画图软件的话,你必须通过电脑的CPU芯片,即你必须想办法告诉CPU如何展示你脑子里想象的图像,而CPU却并不如纸和笔那样做你的奴隶,反之,你要迎合它的规则...说了这么多,其实我想说的是,版本1的最初版就是我手绘的,如下图所示:




最后,不要索要代码,代码通过邮件,QQ分发是一种不正规且不优雅的传播方式,这是Linus的观点,我很认同。如果你感兴趣,你一定能找到或者写出想要的代码,或者说,你也许能帮到我。
------分隔线----------------------------
------分隔线----------------------------

最新技术推荐