续断内网穿透的稳定性治理

续断工程师 2021年4月25日

前言



  作为续断的PM,几年前我定义这个产品时,首先面临一个问题:痛点是什么?

稳定!

  答案不难发现。但要解决这个痛点却并不容易,一些影响因素不在于产品自身:跨境网络的高延时、宽带运营商经常性的网络抖动、监管要求和政策变化、所在公司规章制度、第三方软件的误拦截等等,这些与产品无关的因素容易让人沮丧。


  但产品端绝非束手无策,强化稳定性的手段远没有用尽,有些困难固然无法直接克服,但或许可以选择绕开。三年来续断产品团队持续在“稳定”这个点上投入,取得了一些效果,积累了一点口碑,多少有些心得。总结一下,不是结束,是为更好的继往开来。

一些认知



  稳定是个宽泛的概念,是一个“面”问题,不能因为解决某个“点”就宣布大功告成,鸣金收兵。增强隧道稳定是一个持续的治理过程,新情况层出不穷,需要以技术为基础,见招拆招遇河搭桥。既然是个治理过程,就一般需要闭环,这是基本策略。

  稳定又不只是技术问题,还是个心理学问题。网安圈有一句话很有意思,“真正的安全是用户觉得安全”。拿到内网穿透的场景中,这句话或许可以变成“真正的稳定是用户觉得稳定”。人类很复杂,首先是感性的。用户除了要求产品在技术上更加精进外,在产品出现问题时,还要求它有足够的预见,能回答一些自然而然的假设。即使这个回答是一种无能为力后的心理关怀。或许,人们关心的不全是问题本身,还在于你是否尽力而为了。

  为了让产品更加简单,PM可以假设用户是小白。但不能基于同样的假设,放松产品交付价值的努力。实际上恰恰相反,面对产品问题用户是最苛刻的专家。所以,隧道稳定性的治理是无法回避的,也是没有借口的。

治理闭环



  纯技术视角看,续断的治理闭环是这样的。 1619436396685

技术细节



  每个环节涉及了诸多技术点,它们环环相扣,职责清晰。 1619436670107

  • 信标节点


  客户端离隧道服务器越近,隧道越稳定。信标节点是个区域的标记,它并不直接用于选择具体的服务器,只负责找出最近的服务器区。通过简单的ping延时,再结合客户端的地理库信息,系统可以很快找到最佳区域。一段时间以后,当用户发起再次选择服务器的请求时,系统还会进一步分析历史数据,获得更优的结果。


  哲西云的数据表明,有30%左右的广州用户,离他们最近的服务器区不是广州区,而是深圳区。


  • 基础双协议


  这节提到的协议是构建隧道时使用的基础协议,不是用户映射的协议。


  续断客户端在建立隧道时可以使用Websocket和QUIC两种协议,前者是TCP的一种,后者是UDP的。一般情况下Websocket更传统更稳健,但TCP已老态龙钟,互联网越来越复杂,在众多后起之秀面前它已显得臃肿低效。它对网络抖动敏感,灵敏的窗口机制容易导致较大的带宽波动。连接断开时,它总是会花费更多的时间去完成握手重连,尽管人们很有可能感觉不到。


  QUIC协议是众多优秀的后辈之一,它更安全、更简洁、更高效,有一贯的G厂风范。有研究论文表明,它具有一定的侵略性,使用该协议的程序,更容易获得对自己有利的带宽分配,也更容易实现持续稳定的带宽占用。在复杂的互联网环境中,它可以更高效的传输,相比之下,TCP害羞的像个孩子。


  但它的缺点和优点一样明显,UDP属性让它更容易受到网络运营商的歧视,尤其是在跨省或跨境网络中,有些运营商甚至会禁掉非著名端口的UDP协议。另外,它的高效以流量为代价,哲西云的测试数据表明,在网络环境很差时,广州到成都使用QUIC协议可以实现较高的带宽,但丢包严重,传输文件消耗的流量比文件体积多了70%。即,传1G的文件消耗了1.7G的流量。


  Websocket和QUIC两种不同的类型是互补关系,有更好的网络适应性。


  • 拥塞控制


  上面对基础协议的分析可能会让人耳目一新,其实不需要过度反应。协议的对比很复杂,维度很多,难有优劣之分,应该总是站在应用的角度看待它们,合适的才是最好的。


  Websocket并没有那么不堪,实际上我们建议优先选择它,就一条“成熟可靠”,就够格了。再加上数月前我们也优化了它的拥塞控制算法,算是老树开新花。


   我们全面升级了服务器,以使用新的拥塞控制机制,在网络环境很差的场景中,新机制效果明显,比如,广州到法兰克福,当网络很差时,常规Websocket隧道只有25KB/s时,应用新算法,速度提升至1.4MB/s,效果非常显著。


  • 连接保持


  在使用按量付费或高速流量时,隧道的带宽是动态可调的,随时调整,即时生效。但有一个问题,像Windows远程桌面映射,隧道需要尽可能保持不断开,因为如果你恰巧在通过mstsc远程拷一个文件,隧道断开就只能重传了。


  连接保持就是为解决这类问题而生。在调整隧道带宽时,隧道不会断开,尽可能保证应用层稳定。


  • 数据采集


  系统采集了隧道运行时实际上下行带宽,应用延时,并发连接数,并形成历史记录。在执行诊断后,客户端还会提供更多即时数据,如物理带宽测速,重连次数,ping延时,最近一次并发超限的时间等。这些数据与隧道稳定密切相关,不涉及隐私。用户经常的反馈是“我感觉隧道很慢”,现在,我们可以用数据来看出隧道有多慢,比“感觉”更准确,也更容易解释和解决。


  在这些参数中,我们使用了“应用延时”这一新指标,它使用“应用请求和响应”的时间来表示,相比与应用无关的ping延时,它能更准确的反映应用的响应速度。毕竟,你关心的是应用快不快,而不是ping快不快。


  关于数据采集,我们在《续断诊断功能升级,提供更多隧道运行数据》一文中有更多说明。


  • 切换协议


  上面在“基础双协议”一节提到了很多,在网络状况不佳时,可以尝试切换基础协议。

1619437985581

  • 切换服务器


  小王用广州的客户端建隧道时,系统分配了广州的服务器。后来由于业务需要,要换成北京的客户端,编辑隧道后客户端换了,但隧道服务器仍然是广州的。很明显,隧道稳定性变差了。当然小王可以删除隧道重建,但这样一来,外网访问地址和端口会变,使用到这个地址的应用要改参数,用户可能并不希望这样。

1619438085719


  切换服务器可以解决这个问题。它提供了一种更灵活的处置:在保持外网访问地址和端口不变的前提下,系统会重新分配服务器。在“信标节点”一节中,我提到过“再选”服务器时,系统会参考更多数据维度。


  • 专属服务


  一般情况下,隧道服务器是公用的。一台服务器上会有很多用户的隧道,它们各种各样,五花八门,有的是高带宽业务,有的是高频/高并发业务,有的业务有竞争性容易吸引攻击等等。如果你映射的业务很重要,比如用于自己客户的ERP,你可能不希望跟其他人共用服务器。


  专属服务就是在这样的背景下出现的,它只为一个用户提供服务,每台服务器最高200Mbps的总带宽,每条隧道拥有高达50Mbps的带宽上限,更稳更快。


  专属服务还提供可自定义的控制台入口,允许用户自定义独立的控制台二级域名,实现更加彻底的隔离。

结语



  隧道稳定性治理是一个持续的过程,尽管有一些因素是不可控的,但仍然可以做很多工作去规避、优化。只要保持敏感,保持快速响应,内网穿透的稳定性体验会持续改善。


  三年来,续断始终把“稳定”作为产品的核心竞争力去建设,未来,我们将继续坚持下去