到目前为止，我认为它们与字节是由位组成的相同，并且双方都需要知道对方的字节大小和字节序并相应地转换流。然而，维基百科说 byte stream != bit stream (https://en.wikipedia.org/wiki/Byte_stream ) 和 bit streams 专门用于视频编码 (https://en.wikipedia.org/wiki/Bitstream_format)。在这个 RFC https://www.rfc-editor.org/rfc/rfc107 中，他们讨论了这两件事并描述了 Two separate kinds of inefficiency arose from bit streams.。我的问题是：
【问题讨论】：
标签： streaming byte bits bytestream
这是一个相当宽泛的问题，我必须给出 10,000 英尺的视野。比特流在两种不同的用途中很常见：
非常底层，它是许多硬件运行的基本方式。最好的例子是来自硬盘或光盘的数据流，或通过传输线发送的数据，例如 USB 电缆、同轴电缆或您收到此帖子的电话线。您找到的 RFC 适用于此。
高级，它们在数据压缩中很常见，每个令牌的可变位数允许更紧密地打包数据。 Huffman coding 是最基本的压缩方式。您找到的视频编码主题适用于此。
字节流和比特流的真正区别是什么？
字节流与面向字节设备的计算机高度兼容，并且您在编程中几乎总是会遇到这些设备。比特流更底层，只有系统集成工程师才会担心它们。虽然比特流的有效负载通常是计算机感兴趣的字节，但通常需要更多的开销来确保接收器能够正确解释数据。通常有比对数据中的字节进行编码所需的多得多的位。需要额外的比特来确保接收器正确同步并且可以检测并可能纠正比特错误。 NRZ encoding 很常见。
RFC 非常具有考古学意义，在 1971 年，他们仍在敲定让计算机相互通信的基础知识。那时他们仍然接近传输线行为，比特流，许多计算机还没有就一个字节中的 8 位达成一致。他们担心在非常贫乏的硬件上将位转换为本地字节的成本以及将尽可能多的位打包到消息中的需要。
接收方如何知道在给定时间要处理多少位？
协议确定这一点，就像 RFC 一样。在可变长度位编码的情况下，决定它的是位值本身，就像霍夫曼编码一样。
为什么在某些情况下比特流比字节流更好？
我认为已经涵盖了，因为它更符合其目的。要么是因为硬件是面向位的，要么是因为可变位长编码很有用。
【讨论】：
位是计算机代码中的单个 1 或 0，也称为二进制数字。 比特流最常见的用途是传输控制协议或 TCP。这一系列指南告诉计算机如何在彼此之间发送和接收消息。万维网和电子邮件服务等依赖 TCP 准则以有序的方式发送信息。通过比特流发送可确保片段以正确的顺序到达，并且消息在传递过程中不会损坏，这可能会使其无法读取。因此，比特流会一个接一个地发送。
八位组成一个字节，字节流将这些八位数据包从计算机传输到计算机。
数据包在到达时被解码，因此计算机可以解释它们。因此，字节流是按顺序作为一组一起发送的比特的特殊情况。为了最有效的字节流，它流经一个专用的和可靠路径有时称为管道或管道。 在通过计算机网络发送字节流时，需要可靠的双向传输层协议，例如 Internet 上使用的传输控制协议 (TCP)。这些被称为字节流协议。与某些类型的硬件组件一起使用的其他串行数据协议，例如通用异步接收器/发送器 (UART) 技术，是一种也使用字节流进行通信的串行数据通道。在这种情况下，字节或字符在发送端被打包在一个帧中，其中附加了一个额外的起始位和一些可选的检查位，然后在接收端从帧中分离出来。这种技术有时被称为面向字节的协议。
举个一般生活的例子，假设你有很多火柴要送。那么你可以一根接一根地送他们，一根接一根 时间..或者您可以将其中一些包装在火柴盒中并发送 在一起，一个火柴盒一个接一个。第一个就像 比特流和后者像字节流。
因此，这完全取决于硬件想要什么或最适合什么。如果你的手很小，不能接受火柴盒，但你仍然想要火柴棒，那么你一次拿一根，否则就拿盒子。还有字节流在某种意义上更好，因为不需要检查每个位，并且可以分批发送 8 个数据，如果其中任何一个失败，则可以重新发送整个 8 位。
【讨论】：
在这里添加其他好的答案：
字节流是比特流的一种类型。字节流将位描述为 8 位宽的有意义的“包”。
某些（尤其是低级）流可能与每个 8 位序列中的含义无关。将这些称为“字节流”是一种糟糕的描述
类似于每辆本田思域都是汽车，但并非每辆汽车都是本田思域......
【讨论】：