PDF被动测量 TCP 往返时间
深入了解 TCP 的 RTT 测量
Stephen D. Strowes，Boundary 公司
测量和监控网络 RTT（往返时间）出于多种原因非常重要：它使网络运营商和最终用户能够了解其网络性能并帮助优化其环境，并且它帮助企业了解其服务对其用户群的响应速度。
测量网络 RTT 对于 TCP（传输控制协议）协议栈优化带宽使用率也很重要。终端主机上的 TCP 协议栈通过被动测量网络 RTT 来优化高性能，使用的网络 RTT 是通过广泛部署的 TCP 时间戳选项在 TCP 头部中携带的。如果利用这些信息，将为服务和应用程序带来一些独特的运营优势：主机无需启动带外 ICMP（互联网控制消息协议）回显请求（ping），也无需在应用程序流量中嵌入定时信息。相反，主机可以被动地测量代表 TCP 流量所经历的完整路径网络延迟的 RTT。
理解网络延迟是理解网络性能某些重要方面的关键。两个主机之间遍历网络所花费的时间会影响服务的响应速度，并影响终端主机可用的有效带宽。在服务器上被动地测量这些信息可以帮助从客户的角度提供服务响应性的细粒度指示，并且同时为客户提供比粗粒度和通常不准确的基于 IP 的地理位置更有效的网络距离指标。
测量到许多主机或客户的 RTT 并非易事。一种解决方案是主动探测，形式为 ICMP 回显请求和响应（即 ping），但这会增加额外的网络负载。在某些情况下，ICMP 流量会被降低优先级、完全丢弃或路由到与 TCP 流量不同的路径。即使以上情况都不是真的，仍然有可能 RTT 是测量到 NAT（网络地址转换器）而不是交换数据的终端主机的。
另一种测量网络 RTT 的可能解决方案是测量应用程序层响应速度。然而，这意味着需要执行应用程序特定的、临时的测量，方法是将 ID 或时间戳嵌入到 TCP 字节流中，这可能会根据网络条件给出误导性的、被放大的网络 RTT 测量值（稍后会详细介绍）。
这些解决方案都不是完全令人满意的，因为它们都不能保证测量到影响应用程序流量的网络 RTT。然而，TCP 头部中携带的时间戳信息提供了另一种解决方案：它有效地成为一种网络层 RTT 测量，可以穿透大多数中间盒，例如 NAT 和防火墙，并测量连接上两个主机之间的完整路径 RTT。此信息提供了终端主机可用的唯一非定制 RTT 估计解决方案。诸如 tcptrace 之类的工具可以使用此状态计算 RTT，但是任何可以检查数据包头部（通常通过 libpcap 完成）或查询本地系统以获取此类内核状态的软件都可以被动地收集所有活动连接的网络 RTT。
这些测量之间的关键差异以及不同的网络条件如何影响它们并不明显。本文的目的是讨论和演示使用 TCP 流量进行被动 RTT 测量的可能性。
背景
TCP 为使用它的应用程序提供可靠的字节流；应用程序发送任意数量的数据，TCP 层将其作为一系列报文段发送，报文段带有序列号和有效载荷长度，指示每个报文段所代表的字节流块。为了实现有序字节流，如果报文段在源和目标之间丢失（或者，如果已接收报文段的确认在目标和源之间丢失），TCP 会重传报文段。为了提高所有网络条件下的性能，TCP 协议栈测量其与每个连接上的另一个主机之间的 RTT，以便适当地优化其 RTO（重传超时），并优化从丢失事件中恢复的时间。
最初的 TCP 规范不包含强制性的、专用的 RTT 计算机制。相反，TCP 协议栈尝试通过观察发送序列号的时间并将该时间与相应的确认相关联来计算 RTT。然而，在存在数据包丢失的情况下，使用此机制计算 RTT 会使准确测量变得不可能。13 定义 TCP 时间戳是为了允许在连接的两端独立进行此计算，同时在两个主机之间交换数据。TCP 时间戳提供了一种独立于序列号和确认计算 RTT 的机制。
RFC 13233 中记录的从两个主机之间的 TCP 流计算 RTT 的算法，通常被连接上的两个终端主机使用，以改进 RTO，从而提高 TCP 在发生丢失时的性能。该机制在现代操作系统中默认启用，并且很少被防火墙阻止，因此出现在大多数 TCP 流中；已知 TCP 时间戳选项已在广泛部署。5
对于每个连接，只要在该连接上交换数据，就会持续计算 RTT。 TCP 计算每个连接上交换的数据包的 RTT，并计算这些测量的指数移动平均值，称为 SRTT（平滑 RTT）。 TCP 协议栈还维护测量的 RTT 的方差，即 RTTVAR。 TCP 协议栈为连接计算的 SRTT 决定了 RTO 值。给定变量 G（系统时钟粒度）和 K（设置为 4），8 RTO 的计算公式如下
RTO = SRTT + max(G,K * RTTVAR)
RTO 用于优化 TCP 协议栈在发送 TCP 报文段后等待相应确认的时间，然后再重试发送操作。准确测量两个主机之间的 RTT 可以使 TCP 为每个活动连接准确调整其 RTO。
理解大多数 TCP 流量中携带的 TCP 头部中包含的状态可以帮助应用程序设计者或网络运营商了解应用程序流量经历的网络 RTT。许多具有实时约束的应用程序使用 TCP 传输其流量，这在一定范围内是可以接受的。1 了解字节流语义如何影响实时性能非常有用。 TCP 时间戳是 TCP 头部中的可选字段，因此尽管它们非常有用并且在大多数流量中都携带，但它们并非 TCP 功能严格要求的。这些值保存在两个 4 字节的头部字段中：TSval（时间戳值）和 TSecr（时间戳回显回复）。参与连接的每个主机在每次发送 TCP 报文段时都会向另一个主机发送 TSval 时间戳，并等待返回相应的 TSecr。在首次发送 TSval 和接收到 TSecr 之间测量的时间差是 TCP 协议栈对 RTT 的最佳猜测。此处的时间戳是一个任意值，以本地系统时钟的粒度递增；它不是可以独立解释的时间戳，例如自纪元以来的秒数。
举例来说，在图 1 中，时间从上到下递进，水平线表示实时递增（例如，以毫秒为单位）。两个主机 A 和 B 具有打开的连接并且正在交换数据包。实际上，两个主机具有不同的时钟，但为简单起见，假设它们完全同步。
示例操作如下
主机 A 发送一个包含时间戳选项的 TCP 报文段
TSval = 1，TSecr = 0
TSecr 设置为 0，因为 A 未观察到来自 B 的 TSval；这通常表示 A 正在打开与 B 的连接。主机 B 在时间 1 接收到此时间戳；在时间 2，主机 B 发送回主机 A 的 TCP 报文段，其中包含值
TSval = 2，TSecr = TSvalA = 1
这些在时间 3 被主机 A 接收。给定此回显值和当前时间，主机 A 知道在此实例中 RTT 大约为 2 毫秒。
随后，A 发送的接下来的两个报文段都带有值
TSval = 3，TSecr = TSvalB = 2
第一个报文段在时间 4 被主机 B 接收，因此主机 B 也可以计算出 2 毫秒的 RTT。给定接收到的相同时间戳的两个回显，最小持续时间被认为最接近实际网络延迟；如果网络延迟发生变化，未来的交换将测量到这一点。持续向另一个主机发送值并记录直到收到包含该值的回显回复的最短时间，使每个终端主机都能够确定其与连接上的另一个主机之间的 RTT。
需要注意的是，为了使 TSval 被认为是有效的，TCP 报文段必须携带来自应用程序的数据。 TCP 报文段可以合法地携带零字节有效载荷，最常见的情况是确认数据报文段，或者启用 TCP 保活时。通过要求有效的 TSval 仅来自携带数据的 TCP 报文段，该算法不太可能测量到主机之间通信中断的情况，在这种情况下，数据交换暂停一段时间，然后使用最后接收到的 TSval 作为 TSecr 重新启动。这也意味着，在数据仅在一个方向交换的 TCP 流中，只有其中一个主机能够计算 RTT。然而，通常情况下，一些应用程序层会在两个方向都发生交互。
最后，RTT 计算可以在任何转发流量的主机上执行，而不仅仅是终端主机，因此可以从网络的网关主机计算网络内所有连接的完整路径 RTT。计算准确 RTT 所需的只是连接的两个方向都通过监控主机。这种情况是否属实通常取决于网络架构，但众所周知，互联网上的路径通常是不对称的。2 然而，在网络的所有流量都通过的网关节点上运行此算法，允许从一个位置被动地对所有连接进行 RTT 计算。
演示 RTT 测量
网络是一种共享资源，多种因素会影响 TCP RTT 计算。本节广泛涵盖了其中一些因素，并演示了 TCP RTT 计算与应用程序感知的 RTT 之间的差异。目的是证明与 ICMP 的 RTT 估计值具有对等性（假设所有其他条件都相同），以及数据包丢失和过度缓冲如何相对于应用程序层的感知延迟影响这些测量值。
为了演示 RTT 测量的响应性，在虚拟化环境中模拟了流量流。该环境很简单：两台 Linux 主机配置在不同的子网上，第三台 Linux 主机（启用数据包转发）配置了两个网络接口，每个子网一个。
此转发主机用于使用 tc（流量控制）工具更改两个终端主机之间观察到的网络特性。网络特性不会在终端主机上修改，因此它们的 TCP 协议栈不会直接意识到每个实验的配置。对于每个实验，在转发主机上的每个接口上设置 50 毫秒的出口延迟，从而导致两个终端主机之间的 RTT 为 100 毫秒。每个实验运行 180 秒。最大数据速率设置为 10 Mbps。
在这些终端主机上，以下组件正在运行
• Ping 在两台主机上运行，因此每台主机每秒向另一台主机发送一次 ICMP 回显请求。这测量 ICMP RTT 值以建立主机之间的“真实” RTT。
• 正在运行一个简单的客户端/服务器程序对，其中客户端每秒通过 TCP 连接向服务器发送本地时间戳，服务器将时间戳回显给客户端；客户端在每次从字节流中读取响应时计算差值。客户端应用程序运行两个线程：一个用于发送，一个用于接收。这测量应用程序层感知的 RTT。
• 也在两个终端主机上运行的是 pcap（数据包捕获）读取器，它观察客户端/服务器程序生成的流量的 TCP 头部中携带的 TCP 时间戳值，从中计算 RTT，并每秒输出最新的 RTT 值。这些实验导出的值是 RTT 而不是 SRTT，因为此处的目的是检查实际 RTT 而不是近似值。这从 TCP 时间戳被动地计算 RTT。主机之间不交换其他流量，缓冲区膨胀演示期间除外。
以下示例演示
1. 通过修改网络延迟来准确监控变化 RTT 的能力。
2. 数据包丢失的影响。
3. 超大缓冲区的影响（通常称为缓冲区膨胀）。
Nagle 算法
在详细描述这些实验之前，让我们看一下 Nagle 算法，6 它在许多 TCP 协议栈中默认启用。它的目的是减少网络传输的少量、头部繁重的数据报的数量。它的工作原理是，如果可发送的数据量小于 MSS（最大报文段大小）（这是路径上允许的最大传输单元给出的最长报文段），并且如果先前发送的数据仍在等待确认，则延迟新数据的传输。
对于在 TCP 上运行的时间关键型应用程序，Nagle 算法可能会导致不必要的延迟。因此，由于假设此类应用程序将在本文介绍的实验中通过 TCP 运行，因此禁用 Nagle 算法。这是通过在客户端和服务器上设置所有正在使用的套接字上的 TCP_NODELAY 套接字选项来实现的。
实验 1：变化的网络条件
在计算 RTT 时，至关重要的是测量值要准确反映当前条件。本实验的目的只是演示我们的指标对以可预测方式变化的条件的响应性。在本实验中，首先设置基本 RTT（100 毫秒），然后通过将转发主机上两个接口的延迟增加 25 毫秒来交替地在基本 RTT 上增加和减少额外的延迟（50 毫秒）。路径上未指定丢失率，并且两个主机之间未发送额外的流量。
请注意，由于 TCP 的 RTT 计算完全是被动的，因此如果没有数据交换，它不会观察到 RTT 的变化。然而，在存在流量的情况下，RTT 测量值快速更新是有益的。图 2 显示了此实验的结果。在所有层进行的测量都表明是双峰分布，这正是没有其他网络条件影响流量时应该预期的结果。三种形式的测量实际上是等效的，实验期间测量的平均 RTT 变化不超过 1%。
实验 2：数据包丢失
网络上的数据包丢失会影响可靠性、响应速度和吞吐量。它可能是由许多因素引起的，包括噪声链路损坏数据、转发硬件故障或路由重新配置期间的瞬时故障。假设网络基础设施没有故障且路由稳定，则丢失通常是由网络拥塞引起的，当汇聚的数据流导致瓶颈时，会强制缓冲区在转发硬件中溢出，从而导致数据包被丢弃。丢失可能发生在 TCP 连接的前向或反向路径上，TCP 协议栈的唯一指示是缺少收到的 ACK。
TCP 为应用程序提供有序的字节流。因此，当发生丢失并且必须重传报文段时，已经到达但在字节流中稍后出现的报文段必须等待丢失报文段的交付，以便可以按顺序重新组装字节流。这被称为队头阻塞，可能对在 TCP 上运行的应用程序的性能不利，尤其是当延迟很高时。如果启用了选择性确认，则允许主机精确地指示在前向路径上丢失了哪些报文段子集，从而指示要重传哪些子集。这有助于在发生丢失时提高“飞行中”的报文段数量。
在本实验中，在转发主机上以 5%、10%、15% 和 20% 的丢失率启用了数据包丢失，目的是证明 TCP 报文段仍然被交换，并且 TCP 估计的 RTT 比应用程序测量的 RTT 更能容忍丢失。图 3 显示了此实验的结果。这些点代表中值，并显示了第 5 和第 95 百分位数。
在这些测试中，即使中值接近真实的 100 毫秒 RTT，5% 的数据包丢失也可能为应用程序引入半秒的延迟；应用程序层 RTT 在 5% 丢失率下的测量平均值为 196.4 毫秒，比 TCP RTT 的测量平均值高 92.4 毫秒。测量平均值迅速上升：10% 丢失率为 400.3 毫秒，15% 丢失率为 1.2 秒，20% 丢失率为 17.7 秒。图 3 中显示的应用程序层 RTT 的中值遵循类似的模式，并且在此示例中，在 20% 数据包丢失的情况下，测量的应用程序层 RTT 中值约为 12 秒。然而，TCP RTT 始终接近真实的 100 毫秒距离；尽管延迟的数据包交换可能会夸大此测量值，但在这些测试中观察到的 TCP RTT 和 ICMP RTT 之间的最大平均偏差是 TCP 层测量的 RTT 增加了 57.7 毫秒。数据包丢失的影响可能对 TCP 应用程序的响应速度造成破坏性影响，但很明显，被动测量网络层 RTT 仍然是可行的，并且与 TCP 的按顺序交付语义可能引入的应用程序感知延迟不同。
实验 3：缓冲区膨胀
对丢包预防和网络性能之间关系的误解导致在转发和路由硬件中引入过多的缓冲作为避免丢包的策略。通常（但并非完全如此），这会影响商品 CPE（客户驻地设备），从而直接影响最终用户。然而，过度缓冲会与 TCP 的丢包检测算法背道而驰，因为它会增加延迟，从而延迟 TCP 协议栈识别丢包并退避的时间——也就是说，大型缓冲区引入的额外延迟可能会扰乱 TCP 的拥塞控制机制。
缓冲区膨胀是一种众所周知的现象7，即两个主机之间的网络路径上最深的缓冲区最终会被 TCP 填满。表面上看，系统设计人员增加缓冲区大小是为了减少丢包，但更深的缓冲区会增加数据包遍历路径的实际时间，增加 RTT 并延迟 TCP 确定何时发生丢包事件的时间。丢包是 TCP 拥塞控制算法的驱动因素，因此增加缓冲区大小实际上适得其反。
为了在本实验中演示缓冲区膨胀，tc 队列大小在转发主机上从 10 KB 系统地增加到 100 KB，然后是 200 KB，最后是 300 KB，并且在启动客户端/服务器应用程序之前，使用 netcat 在每个终端主机之间创建高带宽流。高带宽流的目的是填充转发主机上更长的队列，证明排空时间会影响应用程序响应速度。
实验结果如图 4 和图 5 所示。图 4 显示了随着缓冲区大小的增加，RTT 测量的分散情况。图 5 中的 300 KB 测试显示，来自 ICMP 测量、TCP 层和应用程序层中两个主机的 RTT 测量值非常相似；这些实验中所有层的平均值和中值都在彼此的 2 毫秒之内。所有 RTT 测量值都增加了相同的量，因为过大的缓冲区大小有效地增加了网络层路径长度。鉴于测试应用程序每秒仅发出少量数据包，锯齿模式表明 netcat 数据正在填充队列，然后 TCP 等待队列排空后再发送更多 netcat 数据，形成突发模式。这些已填充的队列对所有其他流量的交付产生不利影响，并增加了测试应用程序的 RTT，结果在 100 毫秒到约 250 毫秒之间变化。
缓冲区膨胀问题正在积极解决中。诸如 SACK（选择性确认）、DSACK（重复 SACK）和 ECN（显式拥塞通知）之类的机制在启用时都有助于缓解缓冲区膨胀。此外，诸如 Codel 之类的主动队列管理策略已被接受到主线 Linux 内核中。
总而言之，很明显，为了最大限度地减少 TCP 中队头阻塞引起的延迟，必须将数据包丢失保持在最低限度。鉴于我们必须将数据包丢失视为 TCP 拥塞控制算法的主要驱动因素，我们还必须小心地最大限度地减少网络缓冲，并避免缓冲区膨胀造成的延迟。在为必须可靠交付的时间关键型数据配置网络时，尤其要注意后一个要求。
相关工作
将 TCP 用于时间敏感型应用程序时的关键问题是 TCP 提供可靠的字节流。此要求与其他 TCP 的关键方面（例如拥塞控制和流量控制）不同。然而，TCP 并非适用于所有应用程序。 Eli Brosh 等人在更详细地讨论了 TCP 在存在延迟时的行为以及应用程序性能的某些可接受范围。1
UDP9 是 TCP 之后最常用的传输协议；它是一种面向数据报的协议，没有拥塞控制、流量控制或消息排序机制。它有效地使用 UDP 层端口号增强了 IP 层。由于没有消息排序约束，因此它不受可能影响 TCP 连接的队头阻塞问题的影响。
然而，仅 UDP 并不适用于许多应用程序，因为可靠性通常是必需的，并且拥塞控制对于允许公平共享网络资源很重要。许多应用程序选择在 UDP 之上分层协议，例如 RTP（实时协议）与 RTCP（实时控制协议）10 结合使用，主要用于承载能够处理少量丢失的时间敏感型实时流量。这些协议适用于诸如 VoIP 之类的应用程序，这些应用程序不需要 100% 的可靠性，并且发现队头阻塞造成的延迟是不利的。 RTCP 允许粗粒度的拥塞控制，并允许实时应用程序通过为实时流选择不同的质量设置来修改其使用率，但拥塞控制本身并未内置。
DCCP4 是一种面向消息的最佳努力传输层协议，它不强制数据交付的严格排序，不处理数据报重传，但执行拥塞控制以节省网络资源。 DCCP 适用于与 RTP 和 RTCP 类似的一组应用程序，但添加拥塞控制而没有潜在的数据报重复非常重要，允许 RTP 在 DCCP 上运行，而无需过多担心网络资源消耗。
SCTP11 也是一种面向消息的传输协议，其中每个消息都按顺序交付给应用程序。然而，严格的消息排序是可选的，因此传输对于应用程序流量可以更具响应性。 SCTP 还支持部分可靠性。12
请注意，缓冲区膨胀是普遍存在的，其他传输协议也受到与 TCP 相同方式的影响，但是放宽传输层的严格排序约束是提高性能的一种方法，方法是消除在流被阻塞等待丢失数据时产生的额外响应时间。 AQM（主动队列管理）技术7 正在新的 Linux 内核中部署，以帮助进一步缓解缓冲区膨胀，而无需修改应用程序。
结论
TCP 是当今最常用的传输层协议，它满足许多应用程序的需求：它提供可靠的字节流并处理重传和避免拥塞的问题。 TCP 的语义可能意味着在传输层测量的 RTT 与应用程序读取字节流测量的 RTT 之间存在很大差异。因此，TCP 并不总是时间关键型应用程序的最佳传输方式，但是今天大多数 TCP 协议栈中启用的 TCP RTT 测量机制实现了非常接近 ICMP“真实值”的测量，并且性能明显优于嵌入在 TCP 字节流中的类似基于回显的协议。
相关文章
Gettys, J., Nichols, K. 2011. 缓冲区膨胀：互联网中的黑暗缓冲区； https://queue.org.cn/detail.cfm?id=2071893。
Currid, A. 2004. TCP 卸载以进行救援； https://queue.org.cn/detail.cfm?id=1005069。
参考文献
1. Brosh, E., Baset, S., Misra, V., Rubenstein, D., Schulzrinne, H. 2010. TCP 对实时流量的延迟友好性。IEEE/ Transactions on Networking 18 (5): 478-491.
2. He, Y., Faloutsos, M., Krishnamurthy, S. and Huffaker, B. 2005. 关于互联网中的路由不对称性。在 IEEE Global Telecommunications Conference (GLOBECOM) 会议论文集 中。
3. Jacobson, V., Braden, R., Borman, D. 1992. 用于高性能的 TCP 扩展。RFC 1323。
4. Kohler, E., Handley, M., Floyd, S. 2006. 数据报拥塞控制协议。RFC 4340。
5. Kühlewind, M., Neuner, S. and Trammell, B. 2013. 关于互联网上 ECN 和 TCP 选项的状态。在 被动和主动测量 中。 M. Roughan 和 R. Chang 编辑。计算机科学讲义 7799: 135-144。施普林格出版社，柏林，海德堡。
6. Nagle, J. 1984. IP/TCP 互联网中的拥塞控制。RFC 896。
7. Nichols, K., Jacobson, V. 2012. 控制队列延迟。 10 (5); https://queue.org.cn/detail.cfm?id=2209336。
8. Paxson, V., Allman, M., Chu, J., Sargent, M. 2011. 计算 TCP 的重传定时器。RFC 6298。
9. Postel. J. 1980. 用户数据报协议。RFC 768。
10. Schulzrinne, H., Casner, S. Frederick, R., Jacobson, V. 2003. RTP：实时应用程序的传输协议。RFC 3550。
11. Stewart, R. 2007. 流控制传输协议。RFC 4960。
12. Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P. 2004. 流控制传输协议 (SCTP) 部分可靠性扩展。RFC 3758。
13. Zhang, L. 1986. 为什么 TCP 定时器不能很好地工作。在 SIGCOMM 会议论文集 (8 月) 中。
Stephen Strowes 是 Boundary 公司的资深工程师，他在那里从事网络测量指标和工具方面的工作。他之前研究过可扩展的域间路由协议、NAT 穿越协议和用于实时内容的对等协议。
© 2013 0001-0782/13/10 $15.00
最初发表于 Queue 第 11 卷，第 8 期—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 你不了解带宽
当你的员工或客户说他们的互联网性能很糟糕时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理其流量所需的时间。如果你是一家 ISP，并且所有客户都讨厌你，请振作起来。现在这是一个可以解决的问题，这要归功于一群致力于追踪、消除问题，然后在家庭路由器中验证其解决方案的个人。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加快流程，供应链中的信任关系必须在设备中形式化，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪的分布式延迟分析
低延迟对于许多 Google 应用（例如搜索）来说是一个重要的特性，并且延迟分析工具在维持大规模低延迟方面起着至关重要的作用。 对于包含功能和数据不断演变的复杂分布式系统，将总体延迟保持在最低限度是一项具有挑战性的任务。 在大型、真实的分布式系统中，诸如 RPC 遥测、CPU 性能分析和分布式追踪等现有工具对于理解整个系统的子组件很有价值，但不足以在实践中执行端到端延迟分析。
David Crawshaw - VPN 一切焕然一新
VPN（虚拟专用网络）已经 24 岁了。 这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。 随着互联网的成长和变化，VPN 用户和应用程序也随之发展。 VPN 在 2000 年代的互联网中经历了一段尴尬的青春期，与其他广受欢迎的抽象概念交互不佳。 在过去的十年中，互联网再次发生了变化，而这个新的互联网为 VPN 提供了新的用途。 一种全新的协议 WireGuard 的开发，为构建这些新的 VPN 提供了技术基础。
© 版权所有。