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

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

以此速度传输所需的网络实际流量是多少？或者这些数据实际上是否已包含在传输速度中,但只是足够小以至于没有显着差异？

此外,IP支持高达1500字节/数据包(我认为？),但是在加载reddit上的高清图像时,数据包的常见大小是多少？

对不起,我现在可能已经想到了相当基本的问题……

最佳答案 这取决于您查看转移率的位置：

>任务管理器将报告所有传输的字节(即包括其标头在内的所有数据包的总和).
>文件传输程序将报告传输的有效负载.

任务管理器

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

该数据来自网络驱动程序(或至少接近它的某些内容),因此在此处报告数据总量是有意义的(否则需要检查每个数据包以计算有效负载).

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

文件传输程序

另一方面,文件传输程序不知道在较低层中创建的分组的细节(那些可以是任何大小).所以这里唯一的选择是报告传输的有效载荷数据量/文件的一部分,这对用户来说也更有意义.

网络包

在普通网络上(也可能是jumbo frames),TCP-packet(完整以太网帧)在满载时大约为1500字节(在我的系统(IPv4)上,数据包为1514字节,总标头大小为54字节 – 14对于Ethernet header,对于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,从而引入一些额外的开销.

结论

很难说出或计算transfer_bytes / payload的确切比率.它取决于互联网连接的质量(丢失数据包,重新传输),用于传输数据的软件或API调用,甚至底层网络(例如小帧与巨型帧).