我在线阅读了一些文章，我对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数据报大小？
答案 0 :(得分：6)
有多种方法，具体取决于您想要测量的内容。如你所述，它们都归结为将某些位（或字节）除以某个持续时间;不同的是你在计算哪些比特，或者（更少）你正在考虑测量持续时间的那些时刻。
您需要考虑的因素是：
如果您在应用程序层进行测量，那么重要的是您传输到另一个端点的有用数据。例如，如果要传输6 kB的文件，则在测量吞吐量时计算的数据量为6 kB（即6,000字节，而不是位，请注意乘数为1000，而不是1024;这些约定在网络中很常见）。
这通常称为goodput，它可能与传输层实际发送的内容不同（如TCP或UDP），原因有两个：
网络中的每个层都会为数据添加一个标头，由于其传输时间而导致一些开销。此外，传输层将您的数据分成几个部分;这是因为网络层（如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。
这里我没有考虑链路层（如Ethernet中）添加自己的头部以及可能还有后缀这一事实，这进一步增加了开销。对于以太网，以太网报头为14字节，VLAN标记为4字节，然后为4字节的CRC，间隔为12字节，每包总共36字节。
如果您考虑固定速率链接，比如10 Mb / s，根据您测量的内容，您将获得不同的吞吐量。通常你想要其中一个：
互联网是一种尽力而为的网络，这意味着如果可能，数据包将被传送，但也可能被丢弃。在TCP的情况下，传输层纠正分组丢弃;对于UDP，没有这样的机制，这意味着应用程序不关心数据的某些部分是否未被传递，或者应用程序本身在UDP之上实现重传。
重传降低了产量有两个原因：
一个。有些数据需要再次发送，这需要时间。这引入了延迟，该延迟与发送器和接收器之间的网络中最慢链路的速率成反比（也就是瓶颈链路）。 湾检测到某些数据未送达需要从接收器到发送器的反馈。由于传播延迟（有时称为延迟;由电缆中有限的光速引起），反馈只能由发送器以一定的延迟接收，这会进一步减慢传输速度。在大多数实际情况中，这是对重传造成的额外延迟的最重要贡献。
显然，如果您使用UDP而不是TCP而不关心数据包丢失，那么您当然会获得更好的性能。但对于许多应用来说，数据丢失是不能容忍的，因此这种测量毫无意义。
有些应用程序确实使用UDP来传输数据。一个是BitTorrent，它可以使用TCP或他们设计的称为uTP的协议，它在UDP之上模拟TCP，但旨在提高许多并行连接的效率。通过UDP实现的另一个传输协议是QUIC，它还模拟TCP并在单个连接上提供多路并行传输，并转发纠错以减少重传。
我将稍微讨论前向纠错，因为它与您关于吞吐量的问题有关。实现它的一种天真的方法是每次发送两次数据包;如果一方迷路，另一方仍有机会被接收。这会将重新传输量减少一半，但也会因为发送冗余数据而使您的吞吐量减半（请注意，网络或链路层吞吐量保持不变！）。在某些情况下，这很好;特别是如果延迟非常大，例如在洲际或卫星链路上。此外，存在一些数学方法，您不必发送数据的完整副本;例如，对于你发送的每n个数据包，你发送另一个reduntant，它是它们的XOR（或其他一些算术运算）;如果多余的人迷路了，那并不重要;如果n个数据包中的一个丢失，您可以根据冗余的一个和另一个n-1重建它。因此，您可以将前向纠错引入的开销配置为可以节省的任何带宽量。
当发送方完成通过线路发送最后一位时传输是否完成，还是包括最后一位传输到接收器所需的时间？此外，它是否包括从接收方获得确认所需的时间，说明所有数据都已成功接收且没有重传？
这实际上取决于您想要衡量的内容。请注意，对于大型传输，在大多数情况下，一个额外的round-trip-time是无关紧要的（除非您正在与火星上的探测器进行通信）。
虽然这是一种常见的误解，但事实并非如此。
除了在需要时重新传输数据外，TCP还将调整其发送速率，以便通过拥塞网络不会导致数据包丢失。调整算法已经完善了几十年，并且通常快速收敛到网络支持的最大速率（实际上是瓶颈链路）。因此，通常很难在吞吐量方面击败TCP。
使用UDP，发送方没有速率限制。 UDP允许应用程序尽可能多地发送。但是如果你试图发送超过网络可以处理的数据，一些数据将被丢弃，降低你的吞吐量，并使你正在使网络的管理员非常生气。这意味着以高速率发送UDP流量是不切实际的（除非目标是DoS网络）。
有些media applications正在使用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是网络中的最佳（最大可能）传输速率。大多数现代操作系统应该能够以最佳方式自动配置它。
我在iperf documentation中看不到任何块大小。
如果您参考TCP窗口大小，如果它小于BDP，那么您的吞吐量将是次优的（因为您浪费时间等待ACK而不是发送更多数据;如果需要，我可以进一步解释）。如果它等于或高于BDP，那么您将获得最佳吞吐量。
答案 1 :(得分：1)
这取决于您如何定义“吞吐量”。它通常可以是以下之一。
当人们谈论吞吐量时，您可以将这些定义应用于每个层。在应用层中，第二个定义意味着应用程序的接收端确实已经接收到了字节。有些人称之为“良好输出”。在传输层，比如TCP，第二个定义意味着接收到相应的TCP ACK。对我来说，大多数人应该只对接收端真正接收到的字节感兴趣。因此，第二个定义通常是人们所说的“吞吐量”。
现在，一旦我们对吞吐量有了明确的定义（第二个定义）。我们可以讨论如何正确测量吞吐量。
通常，人们使用TCP或UDP来测量网络吞吐量。
TCP：人们通常仅在发送方端测量TCP吞吐量。对于接收端成功接收的数据包，ACK将发回。因此，发送方本身将知道接收方端发送和接收的字节数。将此数字除以测量时间，我们将知道吞吐量。
但是，在TCP吞吐量测量期间需要注意两件事：
测量期间发送方是否始终为完全缓冲区？即在测量期间，发送方应始终有要发送的数据包。对于正确的吞吐量测量很重要。例如如果我将测量时间设置为60秒，但我的文件已在40秒内完成传输。然后有20秒网络实际上是空闲的。我会低估吞吐量。
TCP速率由拥塞窗口大小，慢启动持续时间，发送方窗口（和接收方窗口）大小调节。这些参数的次优配置将导致低估的TCP吞吐量。虽然大多数现代TCP实现应该具有相当好的所有这些配置，但是测试人员很难100％确定所有这些配置都是最佳的。
由于TCP在网络吞吐量估算中的这些限制/风险，相当多的研究人员将使用UDP来测量网络吞吐量。
UDP：由于UDP在成功接收数据包后没有发回ACK，因此人们必须测量接收端的吞吐量。或者，如果不容易访问接收器端，人们可以比较发送方和接收方的日志以确定吞吐量。但是，一些吞吐量测量工具减轻了这种不便。例如，iperf在其自定义有效负载中嵌入了序列号，以便它可以检测到任何丢失。此外，收件人的报告将发送给发件人以显示吞吐量。
由于UDP本质上只是向网络发送任何内容而不是等待反馈。一旦测量，其吞吐量（记住第二个定义）将是网络的实际容量（或带宽）。
因此，通常，UDP测量的吞吐量应该高于TCP的吞吐量，尽管差异应该很小（~5％-10％）。
UDP吞吐量测量的一个最大缺点是，当使用UDP时，还应确保发送方缓冲区必须已满。 （否则，它会导致吞吐量低估为TCP）。这一步有点棘手。在iperf中，可以通过-b选项指定发送速率。在不同轮次的测试中增加-b值将收敛测量的吞吐量。例如，在我的千兆以太网中，我首先在测试中使用-b 100k。测量的吞吐量为100Kbps。然后我执行以下迭代来收敛最大吞吐量，即以太网的容量。
-b 1m - ＆gt;吞吐量：1Mbps
-b 10m - ＆gt;吞吐量：10Mbps
-b 100m - ＆gt;吞吐量：100Mbps
-b 200m - ＆gt;吞吐量：170Mbps
-b 180m - ＆gt;吞吐量：175Mbps（这应该非常接近实际容量）