Woodstock Asked: 2021-05-17 00:38:21 +0800 CST2021-05-17 00:38:21 +0800 CST 2021-05-17 00:38:21 +0800 CST 网络传输中文件的熵 772 如果我们忽略应用层文件压缩（比如Mega，或者iCloud在传输前压缩文件），文件的内容会影响传输速度吗？ 即 - 在所有条件相同的情况下，底层互联网/路由器/物理层是否关心它是否在传输 1GBzeros与 1Gb 的高熵随机数据？ 我知道可以进行压缩，但我是在没有启用压缩的情况下专门询问的。 networking compression 4 个回答 Voted Best Answer user1686 2021-05-17T01:04:32+08:002021-05-17T01:04:32+08:00 如果我们忽略应用层文件压缩（比如Mega，或者iCloud在传输前压缩文件），文件的内容会影响传输速度吗？ 我知道可以进行压缩，但我是在没有启用压缩的情况下专门询问的。 不，一个字节总是花费相同的时间来传输，无论其值如何，一个给定大小和类型的数据包总是需要相同的时间来处理，无论其有效负载如何。 但是，除了传输速度之外，还有其他可能的差异： 即 - 在所有条件相同的情况下，底层的互联网/路由器/物理层是否关心它是在传输 1GB 的零还是 1Gb 的高熵随机数据？ 一些物理层确实很在意。一长串相同的位可能会导致它们不同步，因为它们依赖于 0 和 1 之间的偶尔转换，因此它们可能无法跟踪位或字节或符号的开始位置和结束位置。为了防止这引起问题，更高层必须对数据进行加扰（在某种意义上对其进行加密）以增加熵。例如，SONET就有这个问题。 瞻博网络：启用 SONET 有效负载加扰 思科：何时应该在 ATM 虚拟电路上启用加扰？ 维基百科：64/66b 编码——运行长度；思科出版社：SONET 上的数据包 “在 SONET/SDH 上的数据包 (RFC 1619) 中使用的早期加扰器有一个只有 7 位内部状态的短多项式，这允许恶意攻击者通过在所有 2 7 -1 状态中传输模式来创建拒绝服务攻击，其中一个保证使时钟恢复电路不同步。这个漏洞一直保密，直到加扰器长度增加到 43 位（RFC 2615），使得恶意攻击者不可能用短序列干扰系统。 这不适用于所有物理层，仅适用于一些物理层。 例如，光纤以太网不受影响，因为它使用8b/10b编码。在其他情况下（例如铜线以太网），加扰直接内置在物理层中，因此更高层不需要关心它（就像他们不应该关心的那样）。 出于同样的原因，串行 (RS-232) 链接使用明确的“开始/停止位”。 维基百科：时钟恢复 高层根本不在乎。它们都是为传输任意有效载荷而构建的，并且没有特别的理由说明包含所有 0 的 TCP 段的处理方式与其他段不同。（甚至这样的段仍然有一个明显不为空的 TCP 头和 IP 头。） 当然，如果您的数据被中间层加密（例如通过 TLS 或通过安全 Wi-Fi 传输），这也不是问题，这总是使它在外部看起来是高熵的。 jcaron 2021-05-18T03:20:50+08:002021-05-18T03:20:50+08:00 正如其他人所说，大多数现代传输技术都具有相当的确定性，一串 X 位将始终花费相同的时间来传输，无论是按原样，还是如果较低层需要加扰，但应用固定比率。 但是，如果某些字符需要转义，则在某些情况下可能会产生轻微影响。例如，PPP就是这种情况，其中至少需要转义0x7D0x7E（前者是转义前缀，后者是帧分隔符）。如果链接需要，可能需要转义其他字符。对于这些字符，传输它们将花费两倍的时间。由于 PPP 仍然是 PPPoA 和 PPPoE 的基础，并用于一些最后一英里的场景，这可能会产生非常轻微的影响。当然，除非您的文件只是0x7Dor的重复0x7E，在这种情况下，与根本不包含这些字符的文件相比，它将花费两倍的时间。 还有例如HDLC和 USB 使用的位填充的情况：NRZI 编码方案在发送一系列 1 时不会改变电平，所以在太多的 1 之后，插入一个 0 以确保不会丢失同步。这里最糟糕的情况是，如果你只发送一个（即你的文件只是一个重复），那么它将花费 20% 的时间（HDLC，5 个之后的额外位）或 17% 的时间（USB，6 个之后的额外位）而不是发送全零或任何从不包含 5 位或 6 位序列的序列。0xFF 回到过去，并非所有 8 位透明的链接，在某些情况下传输的数据可能需要编码（例如二进制数据的 base64）而不是其他情况（例如按原样发送的纯 ASCII），使用quoted-printable 之类的东西之间（例如带有一些重音字符的文本）。因此，根据您发送的内容，它需要在线上或多或少的字符/位。但这现在应该是非常罕见的（而且主要是邮件的问题）。 在所有这些情况下，真正重要的不是熵，而是匹配特定序列的实际内容。如果您有高熵数据（例如压缩或加密数据），那么即使在这些情况下，您也会获得相对一致的平均速度。如果您有特定的数据序列（例如，您0x7D通过 PPP 发送 1 GB 或0xFF通过 HDLC 发送 1 GB），则可能需要更长的时间。如果你完全避免这些序列，它可能会更短。 请注意，即使您不在较高层使用压缩，一些较低层也会引入压缩。同样，在 POTS（拨号）调制解调器的旧时代，调制解调器可以在它们之间使用 V.42bis 压缩。可能还有一些其他传输技术，包括在相对较低的层进行压缩。 fgrieu 2021-05-19T10:58:47+08:002021-05-19T10:58:47+08:00 底层的互联网/路由器/物理层是否关心它是在传输 1GB 的零数据还是 1Gb 的高熵随机数据？ 很多时候，这首歌里有一些东西。一些例子： 在许多常用链接上，包括任何HDLC，比特填充导致长序列 1 比相同长度的随机序列需要多近 20% 的时间。 一些调制解调器级别的数据压缩被标准化为 V.42bis 和 V.44，并且仍然存在于现代设备中。 有人告诉我，一些长途运营商或他们的客户在他们的链路中插入无损低延迟压缩，因为这确实节省了带宽/金钱。参考赞赏。 HTTP 内置了压缩（通常是 gzip），并受到通用服务器和浏览器的支持，这几乎不是与“Mega 或 iCloud 在传输前压缩文件”相比的“应用层”压缩。 有（通常是旧的）协议，其中一个字节为转义字符保留并作为两个字节传输（在某些协议中重复时除外）。 在摩尔斯电码中， 的数据速率.高于 的数据速率_，这并不是唯一需要不同时间的 0 和 1 的协议。 Peter Cordes 2021-05-17T10:35:03+08:002021-05-17T10:35:03+08:00 通常，动态压缩在任何级别都是可能的。如果您的连接包括 ssh 端口转发（启用压缩，包括端口转发和 X11），则实际上可能发生在应用层之下。ssh -C SSH 压缩仅使用 gzip，而不是像 zstd 或 lz4 设计的更快的现代算法，因此与链接速度相比，它只会使用更快的 CPU 来加快速度。 802.3 以太网或 802.11 Wifi 等标准物理/链路层协议不使用压缩；这将花费延迟，需要强大的硬件来跟上千兆数据速率，并且在某些情况下，任何大小的增加都会使最坏的情况变得更糟。用于长距离光纤链路的链路级协议也是如此。 压缩在应用程序级别上工作得更好，或者至少对于多个较低级别链路上的类似 VPN 的隧道。 唯一可以加快传输速度的方法是发送更少的数据包（应用程序级压缩）、发送更小的数据包（不太好，以及在成帧成 TCP 帧后您可能会从假设的链路级压缩中得到什么）或更低的数据包如果它们不为零，则损失率。 user1686 的回答提出了某些数据模式可能会成为链路级编码的问题，例如，如果它们已经接近它们的时序容差，您可能可以制作将某些设备推向错误通信点的数据包。不过，AFAIK 通常不必在 Internet 上担心。现实世界的光纤链路通常维护良好，并且引入会导致 TCP 校验和失败的误码率非常低，而且这在很大程度上可能与数据无关。（在加扰之后，不依赖于长时间运行的 0 或 1；这些发生在现实生活中的未压缩数据中，因此加扰函数旨在确保这些不是问题。）
不，一个字节总是花费相同的时间来传输，无论其值如何，一个给定大小和类型的数据包总是需要相同的时间来处理，无论其有效负载如何。
但是，除了传输速度之外，还有其他可能的差异：
一些物理层确实很在意。一长串相同的位可能会导致它们不同步，因为它们依赖于 0 和 1 之间的偶尔转换，因此它们可能无法跟踪位或字节或符号的开始位置和结束位置。为了防止这引起问题，更高层必须对数据进行加扰（在某种意义上对其进行加密）以增加熵。例如，SONET就有这个问题。
瞻博网络：启用 SONET 有效负载加扰
思科：何时应该在 ATM 虚拟电路上启用加扰？
维基百科：64/66b 编码——运行长度；思科出版社：SONET 上的数据包
“在 SONET/SDH 上的数据包 (RFC 1619) 中使用的早期加扰器有一个只有 7 位内部状态的短多项式，这允许恶意攻击者通过在所有 2 7 -1 状态中传输模式来创建拒绝服务攻击，其中一个保证使时钟恢复电路不同步。这个漏洞一直保密，直到加扰器长度增加到 43 位（RFC 2615），使得恶意攻击者不可能用短序列干扰系统。
这不适用于所有物理层，仅适用于一些物理层。
例如，光纤以太网不受影响，因为它使用8b/10b编码。在其他情况下（例如铜线以太网），加扰直接内置在物理层中，因此更高层不需要关心它（就像他们不应该关心的那样）。
出于同样的原因，串行 (RS-232) 链接使用明确的“开始/停止位”。
高层根本不在乎。它们都是为传输任意有效载荷而构建的，并且没有特别的理由说明包含所有 0 的 TCP 段的处理方式与其他段不同。（甚至这样的段仍然有一个明显不为空的 TCP 头和 IP 头。）
当然，如果您的数据被中间层加密（例如通过 TLS 或通过安全 Wi-Fi 传输），这也不是问题，这总是使它在外部看起来是高熵的。
正如其他人所说，大多数现代传输技术都具有相当的确定性，一串 X 位将始终花费相同的时间来传输，无论是按原样，还是如果较低层需要加扰，但应用固定比率。
但是，如果某些字符需要转义，则在某些情况下可能会产生轻微影响。例如，PPP就是这种情况，其中至少需要转义
0x7D0x7E（前者是转义前缀，后者是帧分隔符）。如果链接需要，可能需要转义其他字符。对于这些字符，传输它们将花费两倍的时间。由于 PPP 仍然是 PPPoA 和 PPPoE 的基础，并用于一些最后一英里的场景，这可能会产生非常轻微的影响。当然，除非您的文件只是0x7Dor的重复0x7E，在这种情况下，与根本不包含这些字符的文件相比，它将花费两倍的时间。还有例如HDLC和 USB 使用的位填充的情况：NRZI 编码方案在发送一系列 1 时不会改变电平，所以在太多的 1 之后，插入一个 0 以确保不会丢失同步。这里最糟糕的情况是，如果你只发送一个（即你的文件只是一个重复），那么它将花费 20% 的时间（HDLC，5 个之后的额外位）或 17% 的时间（USB，6 个之后的额外位）而不是发送全零或任何从不包含 5 位或 6 位序列的序列。
0xFF回到过去，并非所有 8 位透明的链接，在某些情况下传输的数据可能需要编码（例如二进制数据的 base64）而不是其他情况（例如按原样发送的纯 ASCII），使用quoted-printable 之类的东西之间（例如带有一些重音字符的文本）。因此，根据您发送的内容，它需要在线上或多或少的字符/位。但这现在应该是非常罕见的（而且主要是邮件的问题）。
在所有这些情况下，真正重要的不是熵，而是匹配特定序列的实际内容。如果您有高熵数据（例如压缩或加密数据），那么即使在这些情况下，您也会获得相对一致的平均速度。如果您有特定的数据序列（例如，您
0x7D通过 PPP 发送 1 GB 或0xFF通过 HDLC 发送 1 GB），则可能需要更长的时间。如果你完全避免这些序列，它可能会更短。请注意，即使您不在较高层使用压缩，一些较低层也会引入压缩。同样，在 POTS（拨号）调制解调器的旧时代，调制解调器可以在它们之间使用 V.42bis 压缩。可能还有一些其他传输技术，包括在相对较低的层进行压缩。
很多时候，这首歌里有一些东西。一些例子：
.高于 的数据速率_，这并不是唯一需要不同时间的 0 和 1 的协议。通常，动态压缩在任何级别都是可能的。如果您的连接包括 ssh 端口转发（启用压缩，包括端口转发和 X11），则实际上可能发生在应用层之下。
ssh -CSSH 压缩仅使用 gzip，而不是像 zstd 或 lz4 设计的更快的现代算法，因此与链接速度相比，它只会使用更快的 CPU 来加快速度。
802.3 以太网或 802.11 Wifi 等标准物理/链路层协议不使用压缩；这将花费延迟，需要强大的硬件来跟上千兆数据速率，并且在某些情况下，任何大小的增加都会使最坏的情况变得更糟。用于长距离光纤链路的链路级协议也是如此。
压缩在应用程序级别上工作得更好，或者至少对于多个较低级别链路上的类似 VPN 的隧道。
唯一可以加快传输速度的方法是发送更少的数据包（应用程序级压缩）、发送更小的数据包（不太好，以及在成帧成 TCP 帧后您可能会从假设的链路级压缩中得到什么）或更低的数据包如果它们不为零，则损失率。
user1686 的回答提出了某些数据模式可能会成为链路级编码的问题，例如，如果它们已经接近它们的时序容差，您可能可以制作将某些设备推向错误通信点的数据包。不过，AFAIK 通常不必在 Internet 上担心。现实世界的光纤链路通常维护良好，并且引入会导致 TCP 校验和失败的误码率非常低，而且这在很大程度上可能与数据无关。（在加扰之后，不依赖于长时间运行的 0 或 1；这些发生在现实生活中的未压缩数据中，因此加扰函数旨在确保这些不是问题。）