当通过互联网传输1GB数据时，这些数据被分成数据包，每个数据包包含一小段数据，而这些数据包中的每一个都是帧的一部分。
EG。 Windows报告您通过TCP连接以100kb / s传输文件，但这似乎是每秒传输的文件中的数据量，并且似乎不包括ip或tcp标头或以太网帧。
以此速度传输所需的网络实际流量是多少？或者这些数据实际上是否已包含在传输速度中，但只是足够小以至于没有显着差异？
此外，IP支持最多1500字节/数据包（我认为？），但在加载reddit上的高清图像时，数据包的常见大小是多少？
对不起我现在可能已经想到的相当基本的问题......
答案 0 :(得分：2)
这取决于您查看转移率的位置：
如果查看任务管理器/网络，您可以看到传输的字节以及传输的数据包数（单播或非单播）。
该数据来自网络驱动程序（或至少接近它的内容），因此在此处报告数据总量是有意义的（否则需要检查每个数据包以计算有效负载）。
还有一个显示传输速率的图表。这些数字可以很容易地与文件传输软件中报告的数字进行比较。
另一方面，文件传输程序不知道在较低层中创建的数据包的细节（可以是任何大小）。所以这里唯一的选择是报告传输的有效载荷数据 /部分文件的数量，这对用户来说也更有意义。
在普通网络上（也可能有jumbo frames），当完全加载时，TCP数据包（完整的以太网帧）大约为1500字节（在我的系统（IPv4）上）是1514字节，总标头大小为54字节 - Ethernet header为14，IP header为20，TCP header为20。那些可以在网络中分成较小的数据包，但在大多数情况下它们不会。
传输文件（或其他大型数据流）时，平均每次发送2个完整数据包（1514个字节），并接收1个小数据包（54个字节）（[ACK]数据包）。在这种最佳情况下，我们有2 x 1460有效载荷，发送端有2 x 54字节的开销，接收端有54个字节。当与互联网连接的最大传输速率进行比较时，我们还必须考虑一些延迟。
并非所有传输都是最佳的：
可能存在从未到达的数据包或校验和错误的数据包，因此需要重新传输。
在某些情况下，数据可以以较小的部分发送，从而导致更高的开销/有效负载比率（但是使用小块Nagle's algorithm可以解决这个问题）。
某些软件可能正在将文件内容读入小缓冲区（比如4096字节）。然后可以将它们分成2 x 1460和1 x 1176，从而引入一些额外的开销。
很难判断或计算 transferred_bytes / payload 的确切比率。它取决于互联网连接的质量（丢失数据包，重新传输），用于传输数据的软件或API调用，甚至底层网络（例如小帧与巨型帧）。
答案 1 :(得分：1)
因特网上的典型全尺寸TCP / IPv4分组大小为1500B（最大传输单元（MTU）），其中（最小）20B是TCP报头，（最小）20B是IPv4。选择该MTU与以太网兼容。此外，该分组中包括应用标题（例如，用于web的HTTP，用于语音呼叫的SIP / RTP / RTCP等）。 IPv4的最小MTU为576B，IPv6的最小MTU为1280B。可以使用ifconfig命令在Linux上看到MTU。
计算这些值的最佳方法是使用pcap工具/网络分析器，例如Wireshark。另请参阅维基页面或协议标题和字段的良好网络书。
答案 2 :(得分：-1)
我非常确定报告的传输速率不包括协议栈中不同层的所有标头和开销，因为报告的吞吐量通常来自某些用户空间应用程序，从网络流对象中获取实际数据。它需要做额外的工作来找出所有标题和帧以及在不同层中发生的其他开销并影响实际的物理传输。