计算链路吞吐量的正确方法

Question

我在线阅读了一些文章,我对TCP和UDP有了一个很好的了解.但是,我仍有一些疑问,我肯定不会对此完全清楚.

计算吞吐量的正确方法是什么？

(Can't we just divide Total number of bytes received by total time taken ?)

TCP中的关键特性是什么使它具有比UDP高得多的吞吐量？

更新:

我知道TCP使用的窗口只是在实际等待确认之前可以发送很多段.但我怀疑的是,UDP段不断发送,甚至没有打扰致谢.因此UDP中没有额外的开销.那么,为什么TCP的吞吐量远远高于UDP的吞吐量呢？

最后,

这是真的 ？

TCP throughput = (TCP Window Size / RTT) = BDP / RTT = (Link Speed in Bytes/sec * RTT)/RTT = Link Speed in Bytes/sec

如果是这样,那么TCP吞吐量总是等于知道链接速度.由于RTT相互抵消,因此TCP吞吐量甚至不依赖于RTT.

我在一些网络分析工具中看到过,如iperf,passmark性能测试等,TCP/UDP吞吐量随块大小而变化.

吞吐量如何依赖于块大小？块大小是否等于TCP窗口或UDP数据报大小？

Answer 1

计算吞吐量的正确方法是什么？

有多种方法,具体取决于您想要测量的内容.如你所述,它们都归结为将某些位(或字节)除以某个持续时间; 不同的是你在计算哪些比特或(更少)你正在考虑测量持续时间的那些时刻.

您需要考虑的因素是:

您在网络堆栈的哪一层测量吞吐量？

如果您在应用程序层进行测量,那么重要的是您传输到另一个端点的有用数据.例如,如果要传输6 kB的文件,则在测量吞吐量时计算的数据量为6 kB(即6,000字节,而不是位,请注意乘数为1000,而不是1024;这些约定在网络中很常见).

这通常称为goodput,它可能与传输层实际发送的内容不同(如TCP或UDP),原因有两个:

1.由于标题导致的开销

网络中的每个层都为数据添加一个标头,由于其传输时间而引入一些开销.此外,传输层将您的数据分成几个部分; 这是因为网络层(如IPv4或IPv6中)具有称为MTU的最大数据包大小,通常在以太网网络中为1,500 B. 此值包括网络层标头大小(例如IPv4标头,其长度可变,但通常为20 B长)和传输层标头(对于TCP,它的长度也可变,但通常为40 B长).这导致最大段大小MSS(数据字节数,在一个段中没有标题)1500 - 40 - 20 = 1440字节.

因此,如果我们想要发送6 kB的应用层数据,我们必须将它分成6个段,每个段14个字节中的5个和240个字节中的一个.然而,在网络层,我们最终发送6个数据包,每个包含5个1500字节,300个字节中的一个,总共6.3 kB.

在这里,我没有考虑到链路层(如在以太网中)添加自己的头部以及可能还有后缀这一事实,这进一步增加了开销.对于以太网,以太网报头为14字节,VLAN标签可选为4字节,然后是4字节的CRC,间隔为12字节,每个数据包总共36字节.

如果您考虑固定速率链接,比如10 Mb/s,根据您测量的内容,您将获得不同的吞吐量.通常你想要其中一个:

• 良好输出,即应用层吞吐量,如果您要测量的是应用程序性能.对于此示例,您将6 kB除以传输持续时间.
• 如果要测量的是网络性能,则链路层吞吐量.对于此示例,您将传输持续时间除以6 kB + TCP开销+ IP开销+以太网开销= 6.3 kB + 6*36 B = 6516 B.

重传开销

Internet是尽力而为的网络,这意味着如果可能的话,数据包将被传送,但也可能被丢弃.在TCP的情况下,传输层纠正分组丢弃; 对于UDP,没有这样的机制,这意味着应用程序不关心数据的某些部分是否未被传递,或者应用程序在UDP之上实现重传.

重传降低了产量有两个原因:

一个.有些数据需要再次发送,这需要时间.这引入了延迟,该延迟与发送器和接收器(也称为瓶颈链路)之间的网络中最慢链路的速率成反比.湾 检测到某些数据未送达需要从接收器到发送器的反馈.由于传播延迟(有时称为延迟;由电缆中光速的有限速度引起),反馈只能由发送器以一定的延迟接收,这会进一步减慢传输速度.在大多数实际情况中,这是对重传造成的额外延迟的最重要贡献.

显然,如果您使用UDP而不是TCP并且不关心数据包丢失,那么您当然会获得更好的性能.但是对于许多应用来说,不能容忍数据丢失,因此这种测量毫无意义.

有些应用程序确实使用UDP来传输数据.一种是BitTorrent,它可以使用TCP或他们设计的称为uTP的协议,它在UDP之上模拟TCP,但旨在提高许多并行连接的效率.通过UDP实现的另一种传输协议是QUIC,它还模拟TCP并在单个连接上提供多路并行传输,并转发纠错以减少重传.

我将稍微讨论前向纠错,因为它与您关于吞吐量的问题有关.实现它的一种天真的方法是每次发送两次数据包; 如果一方迷路,另一方仍有机会被接收.这会将重新传输量减少一半,但也会因为发送冗余数据而使您的吞吐量减半(请注意,网络或链路层吞吐量保持不变!).在某些情况下,这很好; 特别是如果延迟非常大,例如在洲际或卫星链路上.此外,存在一些数学方法,您不必发送数据的完整副本; 例如,对于你发送的每n个数据包,你发送另一个reduntant,它是它们的XOR(或其他一些算术运算); 如果多余的一个丢失,那没关系; 如果n个数据包中的一个丢失,您可以根据冗余的一个和另一个n-1重建它.因此,您可以将前向纠错引入的开销配置为可以节省的任何带宽量.

你如何衡量转移时间

当发送方通过线路发送最后一位时,传输是否完成,还是包括最后一位传输到接收器所需的时间？此外,它是否包括从接收方获得确认所需的时间,说明所有数据都已成功接收且没有重传？

这实际上取决于你想要衡量的东西.请注意,对于大型转移,在大多数情况下,一次额外的往返时间是无关紧要的(除非您正在与火星上的探测器进行通信).

TCP中的关键特性是什么使它具有比UDP高得多的吞吐量？

虽然这是一种常见的误解,但事实并非如此.

除了在需要时重新传输数据外,TCP还将调整其发送速率,以便通过拥塞网络不会导致数据包丢失.调整算法已经完善了几十年,并且通常快速收敛到网络支持的最大速率(实际上是瓶颈链路).出于这个原因,通常很难在吞吐量方面击败TCP.

使用UDP,发送方没有速率限制.UDP允许应用程序尽可能多地发送.但是如果你试图发送超过网络可以处理的数据,一些数据将被丢弃,降低你的吞吐量,并使你正在使网络的管理员非常生气.这意味着以高速率发送UDP流量是不切实际的(除非目标是DoS网络).

某些媒体应用程序正在使用UDP,但会以极低的速率对发送方的传输进行速率限制.这通常用于VoIP应用程序或Internet Radio,您需要的吞吐量非常低但延迟很低.我想这是误解UDP比TCP慢的原因之一; 事实并非如此,UDP可以像网络允许的那样快.

正如我之前所说,有一些协议,如uTP或QUIC,通过UDP实现,实现类似于TCP的性能.

这是真的 ？

TCP throughput = (TCP Window Size / RTT)

没有丢包(和重传),这是正确的.

TCP throughput = BDP / RTT = (Link Speed in Bytes/sec * RTT)/RTT = Link Speed in Bytes/sec

仅当窗口大小配置为最佳值时,这才是正确的.BDP/RTT是网络中的最佳(最大可能)传输速率.大多数现代操作系统应该能够以最佳方式自动配置它.

吞吐量如何依赖于块大小？块大小是否等于TCP窗口或UDP数据报大小？

我在iperf文档中没有看到任何块大小.

如果您参考TCP窗口大小,如果它小于BDP,那么您的吞吐量将是次优的(因为您浪费时间等待ACK而不是发送更多数据;如果需要,我可以进一步解释).如果它等于或高于BDP,那么您将获得最佳吞吐量.