网络传输中的文件熵

Woo*_*ock 27 networking compression data-transfer

如果我们忽略应用层文件压缩(例如Mega,或者iCloud在传输前压缩文件),文件的内容是否会影响传输速度?

即 - 在所有条件相同的情况下,底层的互联网/路由器/物理层是否关心它是否正在传输 1GBzeros与 1Gb 的高熵随机数据?

我知道可以有压缩,但我特别要求没有启用压缩。

use*_*686 40

如果我们忽略应用层文件压缩(例如Mega,或者iCloud在传输前压缩文件),文件的内容是否会影响传输速度?

我知道可以有压缩,但我特别要求没有启用压缩。

不,一个字节总是需要相同的时间来传输,无论其值如何,并且一个给定大小和类型的数据包总是需要相同的时间来处理,无论其有效负载如何。

但是,除了传输速度之外,还有其他可能的差异:

即 - 在所有条件相同的情况下,底层的互联网/路由器/物理层是否关心它是否在传输 1GB 的零和 1Gb 的高熵随机数据?

一些物理层确实关心。一长串相同的位会导致它们不同步,因为它们依赖于 0 和 1 之间的偶然转换,因此它们可能无法跟踪位或字节或符号的开始位置和结束位置。为了防止这引起问题,更高层必须加扰数据(在某种意义上对其进行加密)以增加熵。比如SONET就有这个问题。

这不适用于所有物理层,仅适用于部分物理层。

例如,光纤以太网不受影响,因为它使用8b/10b编码。在其他情况下(例如铜以太网),加扰直接内置于物理层中,因此更高层不需要关心它(就像他们不应该关心的那样)。

出于同样的原因,串行 (RS-232) 链接使用明确的“开始/停止位”。

更高层根本不在乎。它们都是为了传输任意有效载荷而构建的,并且没有特别的理由为什么例如包含全 0 的 TCP 段将与其他段的处理方式不同。(即使这样的段仍然具有明显不为空的 TCP 标头和 IP 标头。)


当然,如果您的数据由中间层加密(例如通过 TLS 或通过安全 Wi-Fi 传输),这也不是问题,这总是使其在外部看起来是高熵的。


jca*_*ron 10

正如其他人所说,大多数现代传输技术都是非常确定的,并且一串 X 位总是需要相同的时间来传输,无论是按原样还是如果较低层需要加扰,但应用固定比率。

但是,如果某些字符需要转义,则在少数情况下可能会产生轻微影响。例如PPP0x7D0x7E的情况,其中至少并且需要转义(前者是转义前缀,后者是帧分隔符)。如果链接需要,可能需要转义其他字符。对于这些字符,传输它们需要两倍的时间。由于 PPP 仍然是 PPPoA 和 PPPoE 的基础并用于某些最后一英里场景,因此这可能会产生非常轻微的影响。当然,除非您的文件只是0x7Dor的重复0x7E,在这种情况下,与根本不包含这些字符的文件相比,它将花费两倍的时间。

还有比特填充的情况,例如HDLC和 USB 使用的:NRZI 编码方案在发送一系列 1 时不会改变电平,因此在过多的 1 之后,插入一个零以确保同步不会丢失。最糟糕的情况是,如果你只发送一个(即你的文件只是 的重复0xFF),那么它会花费 20% 的时间(HDLC,5 个后的额外位)或 17% 的时间(USB,6 个后的额外位)而不是发送全零或任何从不包含 5 位或 6 位 1 序列的序列。

回到过去,并非所有链接都是 8 位透明的,传输的数据在某些情况下可能需要编码(例如,二进制数据的 base64)而不是其他情况(例如按原样发送的纯 ASCII),诸如引用可打印之类的东西之间(例如带有几个重音字符的文本)。因此,根据您发送的内容,线路上需要更多或更少的字符/位。但这在今天应该是非常罕见的(并且主要是邮件的问题)。

在所有这些情况下,真正重要的不是熵,而是匹配特定序列的实际内容。如果您有高熵数据(例如压缩或加密数据),那么即使在这些情况下,您也会获得相对一致的平均速度。如果您有特定的数据序列(例如,您0x7D通过 PPP发送 1 GB或0xFF通过 HDLC发送 1 GB ),则可能需要更长的时间。如果你完全避免这些序列,它可能会更短。

请注意,一些较低层会引入压缩,即使您不在较高层使用它。再一次,回到 POTS(拨号)调制解调器的旧时代,调制解调器可以在它们之间使用 V.42bis 压缩。可能还有一些其他传输技术,包括在相对较低的层进行压缩。


fgr*_*ieu 5

底层的互联网/路由器/物理层是否关心它是传输 1GB 的零还是 1Gb 的高熵随机数据?

经常有一些东西在那个曲调上。一些例子:

  • 在许多常用链接上,包括任何HDLC位填充导致 1 的长序列比相同长度的随机序列需要多近 20% 的时间。
  • 一些调制解调器级别的数据压缩被标准化为 V.42bis 和 V.44,并且仍然可以在现代设备中找到。
  • 我听说一些长途运营商或他们的客户在他们的链接中插入无损低延迟压缩,因为这确实节省了带宽/金钱。参考赞赏。
  • 有压缩(通常是 gzip)内置于 HTTP 中并由常见服务器和浏览器支持,这很难与“Mega 或 iCloud 在传输前压缩文件”相媲美的“应用层”压缩。
  • 有一些(通常是旧的)协议,其中一个字节是为转义字符保留的,并作为两个字节传输(除了在某些协议中重复时)。
  • 在莫尔斯电码中, 的数据速率.高于 的数据速率_,并且这不是唯一需要不同时间的 0 和 1 协议。