如果我们忽略应用层文件压缩（例如Mega，或者iCloud在传输前压缩文件），文件的内容是否会影响传输速度？
即 - 在其他条件相同的情况下，底层互联网/路由器/物理层是否关心它是否传输 1GBzeros还是 1Gb 的高熵随机数据？
我知道可以进行压缩，但我专门询问是否未启用该功能。
答案1
如果我们忽略应用层文件压缩（例如Mega，或者iCloud在传输前压缩文件），文件的内容是否会影响传输速度？
我知道可以进行压缩，但我专门询问是否未启用该功能。
不，无论一个字节的值是多少，传输它总是需要相同的时间；无论它的有效载荷是多少，给定大小和类型的一个数据包总是需要相同的时间来处理。
然而，除了传输速度之外，还可能存在其他差异：
即 - 在其他条件相同的情况下，底层互联网/路由器/物理层是否关心它是传输 1GB 的零还是 1Gb 的高熵随机数据？
一些物理层确实关心这一点。一长串相同的位可能会导致它们不同步，因为它们依赖于 0 和 1 之间的偶尔转换，因此它们可能会忘记某个位、字节或符号的开始和结束位置。为了防止这种情况造成问题，更高层必须对数据进行加扰（在某种意义上是加密）以增加熵。例如，同步光纤网有这个问题。
维基百科：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 传输），这也不是问题，这总是使其在外部看起来是高熵的。
答案2
正如其他人所说，大多数现代传输技术都是非常确定性的，并且X位串总是需要相同的时间来传输，无论是按原样，还是如果较低层需要加扰，但应用固定比率。
然而，如果某些字符需要转义，则在某些情况下可能会产生轻微影响。例如PPP，至少0x7D需要0x7E转义（前者是转义前缀，后者是帧分隔符）。如果链接需要，则可能需要转义其他字符。对于这些字符，传输它们将花费两倍的时间。由于 PPP 仍然是 PPPoA 和 PPPoE 的基础，并用于某些最后一英里场景，因此这可能会产生非常轻微的影响。当然，除非您的文件只是 或 的重复0x7D，0x7E在这种情况下，与完全不包含这些字符的文件相比，它将花费两倍的时间。
还有位填充例如高清液晶显示和 USB：NRZI 编码方案在发送一系列 1 时不会改变级别，因此在太多 1 之后会插入一个 0 以确保同步不会丢失。最坏的情况是，如果您只发送 1（即您的文件只是 的重复0xFF），那么与发送全零或任何从不包含 5 位或 6 位 1 序列的序列相比，它将花费 20% 的时间（HDLC，5 个 1 之后的额外位）或 17% 的时间（USB，6 个 1 之后的额外位）。
在过去，并非所有链接都是 8 位透明的，传输的数据在某些情况下可能需要编码（例如二进制数据的 base64），而在其他情况下则不需要编码（例如按原样发送纯 ASCII），中间夹杂 quoted-printable 之类的内容（例如带有一些重音字符的文本）。因此，根据您发送的内容，它需要更多或更少的字符/位。但如今这种情况应该极为罕见（主要是邮件的问题）。
在所有这些情况下，重要的不是熵，而是与特定序列匹配的实际内容。如果你有高熵数据（例如压缩或加密数据），那么你会得到相对一致的平均的即使在这些情况下，速度也会有所提高。如果您有特定的数据序列（例如，您通过0x7DPPP 发送 1 GB 的数据或通过 HDLC 发送 1 GB 的数据0xFF），则可能需要更长时间。如果您完全避免这些序列，则时间可能会更短。
请注意，即使您不在较高层使用压缩，某些较低层也会引入压缩。同样，在 POTS（拨号）调制解调器的早期，调制解调器可以在它们之间使用 V.42bis 压缩。可能还有其他几种传输技术，它们在相对较低的层上包含压缩。
答案3
底层互联网/路由器/物理层是否关心它是传输 1GB 的零还是 1Gb 的高熵随机数据？
经常这首曲子很有特色。以下是一些例子：
- 在许多常用的链接上，包括任何高清液晶显示， 这位填充导致 1 的长序列比相同长度的随机序列需要多近 20% 的时间。
- 一些调制解调器级数据压缩被标准化为 V.42bis 和 V.44，并且仍然可以在现代设备。
- 我听说一些长途运营商或他们的客户在他们的链路中插入无损低延迟压缩，因为这确实可以节省带宽/金钱。欢迎提供参考。
- HTTP 内置有压缩（通常是 gzip），并且得到常见服务器和浏览器的支持，而且这几乎不是与“Mega 或 iCloud 在传输前压缩文件”相媲美的“应用层”压缩。
- 有些（通常是旧的）协议会保留一个字节用于转义字符并以两个字节传输（某些协议中重复的情况除外）。
- 在摩尔斯电码中， 的数据速率
.高于 的数据速率_，并且这不是唯一一个 0 和 1 需要不同时间的协议。
答案4
一般来说，即时压缩是可能的在任何层面。在实践中可以如果您的连接包括 ssh 端口转发ssh -C（启用压缩，包括端口转发和 X11），则发生在应用程序层之下。
SSH 压缩仅使用 gzip，而不是像 zstd 或 lz4 设计的更快的现代算法，因此与链接速度相比，它只能通过快速的 CPU 来加快速度。
标准物理/链路层协议（如 802.3 以太网或 802.11 Wifi）不使用压缩；压缩会导致延迟，需要强大的硬件来跟上千兆位数据速率，并且在某些情况下，任何规模的增加都会使最坏的情况变得更糟。长距离光纤链路上使用的链路级协议也是如此。
压缩在应用程序级别效果要好得多，或者至少对于跨多个低级链路的类似 VPN 的隧道来说效果要好得多。
唯一能够加快传输速度的方法是发送更少的数据包（应用程序级压缩）、发送更小的数据包（不太好，以及在组成 TCP 帧后可能从假设的链路级压缩中获得的数据包），或者如果它们非零则降低数据包丢失率。
用户 1686 的回答提出了一些数据模式可能对链路级编码造成问题的可能性，例如，如果某些设备已经接近其时间容差，那么你可能会制作数据包，使它们陷入通信错误。不过，据我所知，这在互联网上通常不是你需要担心的事情。现实世界中的光纤链路通常维护良好，并且具有非常引入会导致 TCP 校验和失败的位错误的概率很低，并且这可能在很大程度上不依赖于数据。（并且在加扰之后，不依赖于长时间的 0 或 1；这些发生在现实生活中的未压缩数据中，因此加扰功能旨在确保这些不会成为问题。）