webrtc与stunserver、turnserver建立连接花费时间十秒左右

  很奇怪,使用之前基于webrtc的p2p模块时出了了大问题,问题如标题左右,记得之前使用另外版本的webrtc做开发的时候,本地在CreateOffer后能够能够很快和turnserver连接,估计最左就两三秒,然而现在却是十秒左右了!

   由于换了一个webrtc的版本(此版本是支持winxp系统的),所以第一感觉似乎是webrtc版本的问题,实际上不是,因为就算是换回之前的版本,client和turnserver的连接时间几乎花费了与当前版本webrtc 差不多的时间。

 
 之前也说了,就是之前有点时间,client与turnserver的连接是正常的,于是在google到了一个解决方案,即是trickle
ice技术,据说使用该方法能够大大缩短client与opposite
client的连接时间,这个解决方案似乎和当前所遇到的问题擦着一点边,但是似乎可以值得尝试,因为这或多或少会提升client连接到对面的体验!然而client和turnserver的连接速度是似乎没多大作用,放弃此方案。

   
实际上只要网络状态好,按道理来讲本地client和turnserver的connect
时间应该很短才对,实际上也是如此!后来调试发现在client连接turnserver的过程中在stunrequest.cc中都有调用OnTimeout函数,而且说明本地client和turnserver的连接很不理想,通过查看源码获知在timeout的过程中,本地客户端总共尝试了MAX_SENDS次重发送(发送给turnserver、stunserver),在源码中MAX_SENDS被宏定义为9,超过9次之后才正式通知外部(OnTimeout),
OnTimeout函数最终会触发webrtc底层,告知client本地的icecandidate的收集已经完成,接着出发了外部的OnIceGatheringChange函数,该函数的icecandidate收集状态state将会为kIceGatheringComplete,此时本地的client才会知道本地的icecandidate信息收集已经完结,那么怎么根据当前peerconnection是否成功和stunserver、turnserver连接呢?如果已经收集到的icecandidate中不但包含了本地的ip信息,还包括了stunserver、turnserver的ip信息,那么就可以决断本地client已经成功和turnserver连接,如果只是包含了本地的ip地址信息(icecandidate信息的type字段为host、local),那么就可以决断本地client连接turnserver服务器失败。

 
 而我遇到的情况是,从client开始连接到收集icecandidate信息成功花费了太长的时间(10左右),不过最后还是能够成功连接上turnserver,之前也说了花费了那么长时间全是浪费在timeout上了,那么问题来了?为什么我本地的网络情况良好(可下载、可开网页),怎么在就是在探测turnserver的时候那么艰难呢?断点查看timeout时对应的ip地址,明白了,这个ip地址是我电脑中之前安装的virtulBox中一个虚拟机的ip地址,这个我真是没想到!查看源码,知道webrtc在探测turnserver的时候是要遍历当前平台下的所有的网络适配器的,不管是系统自带的无限网络、还是以太有线网,还是其他应用软件虚拟出来的适配器,webrtc探测时都会遍历,之所以出现时间是花在timeout上,也只是说明对应的网络适配器在和turnserver尝试连接的时候,网路状况不好!鉴于此,于是在控制面板中将virtualBox中虚拟出来的适配器禁用,重新打开本地的client,发现几乎是秒连了!