基于TCP的VPN的效率问题分析

2021-05-21

最近在研究 AnyConnect 协议和服务实现。AnyConnect 是思科开发的企业虚拟专用网(VPN)系统,其核心卖点之一是基于UDP的DTLS通道。本文就来分析一下为什么要用UDP传输VPN数据。

VPN工作在网络层,VPN隧道上传输的都是IP包,而IP包是不可靠的。为了实现可靠传输,我们需要用TCP协议。那TCP是怎么确保可靠传输的呢?答案是给每个包进行编号,接收方收到包后会把这个编号传回来,也就是所谓的ACK,过程如下:

一问一答确保可靠
一问一答确保可靠

如果A在一定时间内没有收到ACK,那可能是出现丢包,所以A会重新发送刚才的包:

数据丢包导致重传
数据丢包导致重传

当然了,如果B回复的ACK发生丢包,A也会重传:

ACK丢包导致重传
ACK丢包导致重传

如果反复出现丢包,就会产生大量的重传,严重浪费网络资源。所以TCP引入了指数避让算法。一开始超时的间隔比较短(比如0.5秒)。重传之后还收不到确认,则依次等待 1、1.5、2、2.5 等间隔。也不会无限等下去,超过一定时间就会关闭连接,通知应用出错。

那为会么用 TCP 传输 VPN 数据不好呢?因为 VPN 工作在网络层,而网络层本身不需要可靠传输。可靠传输是在 VPN 之上的传输层做的。如果用 TCP 传输 VPN 数据,那么这个「网络层」就是可靠的,上层 TCP 的可靠传输机制就成了包袱。

TCP over TCP如果不看 AnyConnect 那一层,那就只有上层 TCP。应用发的每个数据包都会收到一个ACK包。但因为 AnyConnect 走了 TCP 通道。所以,上层的数据包会交给下层的TCP连接发送。VPN的对端收到数据后会发一个ACK,真正的接收端收到数据后会再发一个ACK。可个过程如下:

TCP over TCP 应答
TCP over TCP 应答

显然,实际传输的时候有两次 ack vpn。一般来说不会造成什么问题,但如果有超时,问题就来了。

如果有超时,肯定是下层 TCP 先超时,所以下层 TCP 会重传并等待确认。上层TCP不知道下层TCP已经超时了,还是继续发,结果新发的数据包都没有收到确认,所以上层 TCP 也开始重传。因为下层 TCP 已经处于重传等待状态,并不会发送上层 TCP 的重传数据,所以上层 TCP 继续超时并重传,从而造成雪崩。

这里问题的关键是 TCP 在设计的时候认为底层网络层是不可靠的,但我们用 TCP 实现了一个可靠的网络层,从而产生这样的雪崩。

所以,如果要做 VPN,还是要尽量使用 UDP。而 UDP 则是在 IP 之上简单加了端口信息,本质上跟 IP 包没有什么区别,可以看作是网络层的天然模拟。再辅之以 DTLS,简直就是为 VPN 量身定制的协议。

好,今天就聊到这里。我是涛叔。欢迎留言或者私信讨论。谢谢。

「taoshu」微信公众号