例如，当通过Internet传输价值1GB的数据时，该数据被拆分为数据包，每个数据包包含一小块数据，每个数据包都是帧的一部分。
例如。Windows报告您正在通过TCP连接以100kb / s的速度传输文件，但这似乎是每秒传输的文件数据量，并且似乎不包括ip或tcp标头或以太网帧。
以这种速度传输所需的网络实际流量是多少？还是该数据实际上已经包含在传输速度中，但是足够小以至于没有太大差异？
另外，IP最多支持1500字节/包（我认为？），但是在reddit上加载例如HD图像时，数据包的常见大小是多少？
抱歉，我现在可能应该已经弄清楚了一些基本问题。
这取决于您在哪里查看传输速率：
如果查看“任务管理器/网络”，则可以看到已传输的字节以及已传输的数据包数量（单播或非单播）。
该数据来自网络驱动程序（或至少接近它），因此在此处报告数据总量是有意义的（否则需要检查每个数据包以计算有效负载）。
还有一个显示传输速率的图表。这些数字可以很容易地与文件传输软件中报告的数字进行比较。
另一方面，文件传输程序不知道有关在较低层中创建的数据包的详细信息（这些数据包可以是任何大小）。因此，这里唯一的选择是报告传输的有效负载数据/文件部分的数量，这对用户也更有意义。
在普通网络上（也可能是巨型帧），TCP数据包（完整的以太网帧）在完全加载时（在我的系统（IPv4）上）约为1500字节，数据包为1514字节，总标头大小为54字节- 14表示以太网头，20表示IP头，20表示TCP头）。这些可能是沿着网络的方式较小的数据包拆分，但在大多数情况下，他们不会。
传输文件（或其他大数据流）时，平均每次将发送2个完整数据包（1514字节），并接收1个小数据包（54字节）（该[ACK]数据包）。在这种最佳情况下，我们有2 x 1460的有效负载，发送侧2 x 54字节的开销+接收侧54字节的开销。与Internet连接的最大传输速率进行比较时，我们还必须考虑一些延迟。
并非所有传输都是最佳的：
可能有数据包从未到达或校验和错误，因此需要重新传输。
在某些情况下，数据可能会以较小的部分发送，从而导致较高的开销/有效负载率（但使用小块Nagle的算法可以解决这一问题）。
某些软件可能正在将文件内容读取到较小的缓冲区（例如4096个字节）中。然后可以将它们分成2 x 1460和1 x 1176，从而带来一些额外的开销。
很难说出或计算出正确的比率transfer_bytes / payload。这取决于互联网连接的质量（丢失的数据包，重新传输），用于传输数据的软件或API调用，甚至取决于基础网络（例如，小帧与巨型帧）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句