OpenVPN优化之-TLS握手控制通道的建立

来源:互联网
更新时间:2016/12/9 11:29:37
责任编辑:鲁晓倩
字体:

关于OpenVPN数据通道的一次优化正在进行中,当我参考了”巨型帧“的概念和思想后,我仔细思考了TCP/IP协议栈的设计和实现,于是我得出了一个可能是错误但是起码在我的场景中很实用的结论:上层协议尽管把数据发出吧,不要管数据的大小,如果真的需要拆分,那就由下层来完成吧。

       这个结论的一个反例就是TCP协议的数据分段,它感知了传输链路的MTU,也许在早期的网络中,IP分片重组确实影响了TCP的端到端流控和拥塞控制,也许还为状态防火墙带来了难题,但是现在不了,现在绝不再是这样了。如果在应用层感知了MTU,那么增加的处理复杂性完全抵消了IP分片避免带来的好处。

OpenVPN协议分析

我在3年前曾经逐字节地分析过OpenVPN协议,那个时候几乎没有人分析过,我的分析也只是兴趣所致,没有什么实际用途。看着OpenVPN那凌乱的代码,然后通过抓包分析协议实在太痛苦了,我当时有一种编写OpenVPN协议Wireshark插件的冲动,若不是受制于Windows以及Gnome/QT编程环境,也许我早就实现了,不喜欢也玩不转IDE,旧梦让我急于将时间快速用在问题本身而不是其它任何事。虽然当前的编程工具,框架几乎都在声称”让你将精力集中在自己的逻辑,而不必在意XXYYOO“,但我看不到这一点,学习成本太高本身就抵消了你对外围的关注。为了一杯牛奶养一头牛本身就是一种愚蠢的想法。

       Wireshark对OpenVPN协议的支持最终还是来了,但是来的太晚了。

       抓取OpenVPN隧道建立时的数据包,确认SSL如何在OpenVPN协议内部被封装。显然,SSL握手协议需要被封装在OpenVPN协议内部,具体如何封装的,抓包结果如下图:

点击图片看大图中国学网 www.xue163.com

这个图本应该显示了ClienHello的封装,但是呢?没有但是,它就是ClientHello,你看到数据的前几字节:16030100...折腾过SSL协议或者被SSL协议残忍蹂躏过的一看到这个就没脾气了。但是为何OpenVPN协议没有解析出这是一个ClientHello呢?因为它分段了...这么一个短短的ClientHello也要分段?也要!OpenVPN协议头占据了一些空间,加上ClientHello本身,我们看到这个OpenVPN数据的长度为100,它的另一部分在数据段29里面,那么看一下29:

点击图片看大图

确实,数据段28和数据段29拼接起来就是ClientHello了,是这样吗?当然是!

       为什么一个ClientHello要分割成100字节的大小呢?早在3年前我在一篇文章中写下了”这样,即使一个1000字节的SSL握手消息,reliable层也可以将其拆成10个100多字节的UDP包,数据到达对端后,每一个100多字节的UDP包进入其SSL BIO的内存BIO中,由SSL协议的实现负责重组数据。“那篇文章是《OpenVPN协议解析-握手数据包分析》,当时费了那么大的劲也没有给出原因。

       纵一个ClientHello都要分割,要是ServerHello以及后续的Certificate呢?当然也要分割了。我们看一下这个夸张的包,分了那么多的段:

点击图片看大图

点击图片看大图

UDP下的握手性能

从抓包分析可以看到,一次SSL握手要来来回回交互那么多的包,每一个包在Reliability层都要经过确认,这将极大影响效率。为何不将分割处理交给下层呢?IP层或者网卡会做得更好,即便做的不好,你也不必加班调试自己的程序和排错,对于协议栈的故障,你只需浏览Maillist,更新驱动...
www.xue163.com true http://www.xue163.com/network/5/55178.html report 3692 OpenVPN优化之-TLS握手控制通道的建立,关于OpenVPN数据通道的一次优化正在进行中,当我参考了”巨型帧“的概念和思想后,我仔细思考了TCP/IP协议栈的设计和实现,于是我得出了一个可能是错误但是起码在我的场景中很实用的结论:上层协议尽管把数据发出吧,不要管数据的大小,如果真的需要拆分,...
最近关注
首页推荐
热门图片