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