Networking 网络传输100kb/s的实际比特传输速率是多少？

例如，当通过互联网传输1GB的数据时，这些数据被分成数据包，每个数据包包含一小段数据，这些数据包中的每一个都是一个帧的一部分

例如，Windows报告您正在通过TCP连接以100kb/s的速度传输文件，但这似乎是每秒传输的文件数据量，并且似乎不包括ip或TCP标头或以太网帧

以这种速度传输所需的网络实际流量是多少？或者，数据实际上已经包含在传输速度中，但只是足够小，不会产生显著差异

此外，IP支持高达1500字节/包（我想是吧？），但在reddit上加载高清图像时，数据包的一般大小是多少

---

很抱歉，我现在可能已经解决了一些基本的问题…

Internet上典型的全尺寸TCP/IPv4数据包的大小为1500B（最大传输单元（MTU）），其中（最小）20B是TCP头，而（最小）20B是IPv4。选择此MTU是为了与以太网兼容。此外，此数据包中还包括应用程序头（例如，用于web的HTTP、用于语音呼叫的SIP/RTP/RTCP等）。IPv4的最小MTU为576B，IPv6的最小MTU为1280B。使用

ifconfig

命令可以在Linux上看到MTU

---

计算这些值的最佳方法是使用pcap工具/网络分析仪，如。关于协议的标题和字段，请参阅wiki页面或优秀的网络书籍。

我很确定报告的传输速率不包括协议堆栈中不同层的所有标题和开销，由于报告的吞吐量通常来自某个用户空间应用程序，该应用程序只能从网络流对象获取实际数据。它需要做额外的工作，以了解不同层中发生的、影响实际物理传输的所有报头和帧以及其他开销。

这取决于您查看传输速率的位置：

• 任务管理器将报告所有传输的字节（即所有数据包的总和，包括它们的头）
• 文件传输程序将报告传输的有效负载

任务管理器 如果查看任务管理器/网络，您可以看到传输的字节以及传输的数据包数（单播或非单播）

这些数据来自网络驱动程序（或者至少是它的附近），因此在这里报告数据总量是有意义的（否则需要检查每个数据包以计算有效负载）

还有一个图表显示传输速率。这些数字可以很容易地与文件传输软件中报告的数字进行比较

文件传输程序 另一方面，文件传输程序不知道在较低层（可能是任何大小）中创建的数据包的详细信息。因此，这里唯一的选择是报告传输的有效负载数据量/文件的一部分，这对用户来说也更有意义

网络数据包 在正常网络上（也可能存在），TCP数据包（完整以太网帧）在完全加载时约为1500字节（在我的系统（IPv4）上，数据包为1514字节，总头大小为54字节——14个用于，20个用于，20个用于）。这些数据包可以在网络中被分割成更小的数据包，但在大多数情况下不会

转移率 传输文件（或其他大数据流）时，平均每次发送2个完整数据包（1514字节），并接收1个小数据包（54字节）（确认数据包）。在这种最佳情况下，我们有2 x 1460的有效负载，发送端有2 x 54字节的开销，接收端有54字节的开销。当与Internet连接的最大传输速率进行比较时，我们还必须考虑一些延迟。 并非所有变速箱都是最佳的：

• 可能存在从未到达或校验和错误的数据包，因此需要重新传输

• 在某些情况下，数据可以以较小的部分发送，从而导致更高的开销/有效负载比率（但使用小数据块可以解决这一问题）

• 某些软件可能正在将文件内容读入小缓冲区（比如4096字节）。然后，可以将它们拆分为2x1460和1x1176，从而引入一些额外的开销

结论

---

很难说出或计算准确的传输字节/有效负载比率。这取决于internet连接的质量（丢失的数据包、重新传输）、用于传输数据的软件或API调用，甚至是底层网络（例如，小帧与巨型帧）。

我无法回答这个问题，但确切的数字肯定取决于您的设置（windows TCP有几十个可设置的参数，默认值很糟糕），以及网络连接和质量（如果数据包丢失或损坏，它会重复，因此对于坏连接，大量重复会降低平均传输速率）谢谢你的回答！不过我更感兴趣的部分是这个。假设我们使用1500B数据包传输，包括标头，Windows Say的传输速度是100kb/s。100kb/s是网络上产生的实际流量，还是这只是数据传输速率？（即速度实际上至少是40B/数据包以上）简而言之，是的，100 kb/s是实际数据速率，不包括标头。详细信息：让我们从应用程序的角度来看它。如果应用程序有GB的数据要发送，它只会尝试尽可能多地推送字节。现在为了响应并向用户显示性能，它会触发一个定期计时器（每秒）并查看在这段时间内清除了多少字节。显然，它不关心作为