ns 3 project

% Alfred Tso Chun Fai 20012065g % COMP5311 项目：TCP 和 UDP 性能分析

新页

介绍

甚至想知道为什么 Chrome 浏览器在观看 Youtube 视频时感觉比 Firefox 快得多？我这样做了，作为一个好奇的学生，我启动了 Wireshark 并捕获了一些流量，我发现的是这个。

根据 wiki ¹ ，从 Chrome 网络浏览器到 Google 服务器的所有连接中有一半以上使用 QUIC。

什么是 QUIC

QUIC 是一个旨在通过建立多个复用 UDP 来改进当前使用 TCP ^{2 的}Web 应用程序的协议，有些人甚至将其称为“TCP/2”。据称即将推出的 HTTP/3（截至 2021 年 2 月的互联网草案）也将使用 QUIC。

等等...我们正在使用UDP 来替代TCP？我们被告知UDP不可靠，为什么它可以旨在“淘汰”TCP。两种协议（TCP 和 UDP）的比较类似于比较火车与飞机，而不是比较波音与空客（均为运输）。然而，我们仍然可以将它们与一些关键指标进行比较，以了解 QUIC 选择 UDP 进行改进的地方。

新页

TCP 与 UDP：案例研究

背景：相关作品

• 袁等人。 (2019) ³使用平均数据包延迟和数据包丢失概率比较了 SDN 上的 TCP 和 UDP 的性能。研究发现，在这两个指标上，TCP 的性能分别优于 UDP 12-50% 和 25-100%。请注意，这里我们不是在 SDN 中进行研究。
• 他等人。 (2004) ⁴研究了数据包聚合和入口缓冲等对 TCP 和 UDP 吞吐量和延迟抖动的影响。
• 游戏等人。 (2008) ⁵提出了 IPv4 和 IPv6 中 TCP 和 UDP 吞吐量的上限模型。该论文提出了计算两种协议最大理论吞吐量的模型，即在最小传输时间内传输的 TCP 或 UDP 有效负载字节数之比。必要的字节数，包括 IFG、前导码、SFD、以太网 DIX 封装、IP 标头、TCP（或 UDP）标头和填充，乘以链路带宽（假设全双工且无处理时间）。
• 沙鲁丁等人。 (2016) ⁶使用四个指标比较了 4G 网络上的各种传输协议，包括 TCP 和 UDP：吞吐量、数据包丢失、端到端延迟和平均抖动。

新页

问题定义

比较传输层协议并不是一件容易的事，因为有很多因素可能会影响结果：

不同的实现

协议中的一些参数（例如 TCP）留给实现（这会产生 TCP/IP 指纹，允许恶意行为者识别主机的操作系统等），这意味着这些差异可能会对绩效衡量

网络拓扑

数据包所采取的直接路由肯定会影响结果，因此直接路由器、中间的瓶颈链路和其他流量也会影响结果。

所涉及链路的带宽

如上所述，我们通常可能不确定这些直接链接的带宽或只是客户端和服务器之间的链接。提到的一篇论文假设该链接不会发生任何冲突。

硬件

我们已经看到缓冲区可能会影响这些协议的性能，不仅软件方面相关，硬件部分也很重要，而且通常我们无法完全控制这些较低级别的细节。

发送这些数据包的应用程序

在之前的大部分工作中，作者经常会实现一个自定义程序来进行实验，我们还需要考虑这些软件实现对结果的影响，比如发送UDP数据包的时间间隔，以及是否有限制。就我们目前的目的而言，所使用的语言是发送间隔。

目标

考虑到所有这些因素，我们将使用简单的网络拓扑，其设置尽可能接近现实。对于缓冲区队列大小或协议等底层细节，我们将为这两种协议使用相同的信息。因此，我们将使用吞吐量、平均延迟和平均抖动作为性能指标，在有线一对一主机中比较 IPv4 上的 TCP 和 UDP。

我们将发送 10、100 和range(1e4, 1e5, 1e4)数据包，UDP 应用程序中的每个数据包为 1472 字节，TCP 应用程序中的字节数相同，以观察 TCP 和 UDP 应用程序的流量。

吞吐量

$$ 吞吐量 = frac{接收到的数据包数量 (RxPackets)}{上次接收的时间 - 首次接收的时间} $$

平均延误

$$ 平均延迟 = frac{Total end-to-end DelaysForRxPackets}{RxPackets} $$

平均抖动

JitterSum包含流中所有接收到的数据包的所有端到端延迟抖动（延迟变化）值的总和。这里我们将数据包的抖动定义为相对于流的最后一个数据包的延迟变化，即 $$抖动left{P_Nright} = left|延迟left{P_Nright} - 延迟left{P_{N-1}right}right|$$此定义符合 IETF RFC 3393 中定义的 Type-P-One-way-ipdv

$$ 平均抖动 = frac{JitterSum}{RxPackets} $$

新页

设计/方法论

模拟或真实实验室

设计上述实验的首要问题是模拟与否。在我们的研究中，模拟可能会更好，因为我们可以更好地控制我们提到的考虑因素。最大的缺点是我们如何确定结果是“真实的”？答案是，只要我们有明确定义的实验范围并经常对这些范围进行健全性检查，我们就可以了解结果的“真实”程度。

工具：NS-3

ns-3是一个开源的离散事件网络模拟器，主要用于用 C++ 编写的研究或教育目的。模拟器本身有一个全面的在线文档。

ns-3：基础知识

就我们目前的目的而言，我们只需要了解ns-3的主要抽象

{ 宽度=75% }

应用

它就像我们计算机中的进程一样，它使用“套接字”将数据发送到下层。我们将在ns-3中安装一个现成的BulkSendApplication ，使用 TCP 套接字和UDPClient和UDPServer来发送 UDP 数据包，并在这两种情况下安装一个FlowMonitor来监视数据包。

UDP：选择发送间隔

我们将以 2 微秒的间隔发送数据包，这是下面指定的底层通道的延迟

UDP：MaxPacketSize 的选择

这里指的是有效载荷。由于 MTU 是 1500，我们自然会想要使用 1500 字节。然而，IP 标头和 UDP 标头需要 20 + 8 字节，因此我们应该使用 1472 而不是⁵ 。这在模拟中得到了证实；使用 1500 字节数据包可能会损害吞吐量性能。

TCP： BulkSendApplication

“该流量生成器只是尽可能快地发送数据，直到达到 MaxBytes 或直到应用程序停止（如果 MaxBytes 为零）。一旦下层发送缓冲区被填满，它就会等待，直到空间空闲来发送更多数据，本质上是保持持续的数据流”。

我们将 MaxBytes 设置为 UDP 的总字节数（PacketCount * PacketSize）来比较性能，并且在一些实验中 SendSize 并不重要

协议栈

也称为InternetStackHelper ，通常包括 UDP、TCP 套接字、IPv4，对于我们目前的目的， TrafficControlLayer包括一个队列，当队列已满时，它会通知上层

网络设备

这对应于硬件（网络接口卡、NIC）和它们的软件驱动程序，还包括数据包队列，因此ns-3中有两级排队

节点

它是我们可以安装Application 、 InternetStack和NetDevice的终端主机，类似于我们的计算机。我们将创建两个Node并用类似于以太网电缆的东西连接它们。

渠道

为Node提供通信通道，我们将使用 CSMA 通道（如以太网）。这里的重要细节是可用于调整的这些属性的选择：MTU、DataRate 和 Delay。我们将使用标准 MTU（无巨型帧，有时可用于特定网络）、千兆位和 2 微秒的延迟。 2 微秒的原因是光传播 600m，而其他研究则使用 0 延迟。

新页

结果

结果如下：

吞吐量

我们观察到发送的 14720、147200 字节的 UDP 吞吐量超过了 1000Mbps（我们的带宽是 1Gbps）。然后我们查看了数据包的丢失情况

我们可以看到，在 147200 字节中，100 个数据包中有 97 个丢失了。可以肯定地说，我们应该放弃这两个并进一步调查

我们还可以看到 TCP 吞吐量逐渐增加并稳定在 400Mbps 左右。

平均延误

由于缺乏流量控制，UDP 数据包可能“卡在”较低层的队列中。结果也可能是由于我们快速、始终在线的发送数据包导致拥塞。需要进一步调查来确认，例如降低缓冲区以查看延迟是否实际上增加。

传输控制协议

平均延迟在“峰值”之后出现下降，然后再次逐渐增加。这可能是由于拥塞避免中的cwnd调整所致。需要进一步调查，因为我们需要确认拥塞控制算法实际上会产生这样的模式，因为ns-3中有很多选择（Veno、Cubic...等）

平均抖动

随着系统“稳定”，平均抖动预计会减少，并且延迟的变化也会减少。

TCP 的抖动比 UDP 的抖动大

UDP中没有流量控制意味着数据包将连续地压入堆栈并在不受干扰的情况下发送，延迟的变化应该很小，而由于所述流量控制，连续数据包的数据包延迟可能很大。

新页

讨论

为什么不比较丢失的数据包？

BulkSendApplication确保一旦下层发送缓冲区被填满，它就会等待。因此，我们唯一可以丢弃数据包的地方是在我们需要引入错误的通道中。

UDPClient没有这样的流量控制，因此我们可以观察数据包的丢失情况。

那么根据我们这里的研究，QUIC 选择 UDP 的原因可能是什么？

可能只是吞吐量（更高的吞吐量）和抖动（更少的延迟变化）。较大的平均延迟主要是由于缺乏流量控制，QUIC 旨在将“拥塞控制算法移至用户空间……而不是内核空间” ¹ 。

代码

https://github.com/alfredtso/ns-3-project

新页

参考

ns-3 培训资源

HTTP/3 草案

脚注

1. 快速 ↩ ↩ ²

2. QUIC GoogleDoc ↩

3. Yuan-Cheng Lai、Ahsan Ali、Md. Shohrab Hossain、Ying-Dar Lin，软件定义网络上 TCP 和 UDP 流的性能建模和分析，网络与计算机应用杂志，第 130 卷，2019 年，第 76-88 页，ISSN 1084-8045 ↩

4. Jingyi He，S.-H.Gary Chan，光分组交换网络上互联网的 TCP 和 UDP 性能，计算机网络，第 45 卷，第 4 期，2004 年，第 505-521 页，ISSN 1389-1286 ↩

5. Eric Gamess、Rina Surós，IPv4 和 IPv6 中 TCP 和 UDP 吞吐量的上限模型，网络与计算机应用杂志，第 31 卷，第 4 期，2008 年，第 585-602 页，ISSN 1084-8045 ↩ ↩ ²

6. Shahrudin Awang Nor、Raaid Alubady、Wisam Abduladeem Kamil，4G 网络上 TCP、SCTP、DCCP 和 UDP 协议的模拟性能，Procedia 计算机科学，第 111 卷，2017 年，第 2-7 页，ISSN 1877-0509 ↩