很奇怪，使用之前基于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，发现几乎是秒连了！