Eri*_* J. 43
你只是不能打败二进制
二进制协议总是比文本协议更节省空间.即使互联网速度急剧增加,我们希望传达的信息量和复杂性也随之增加.
您引用的文本协议在标准化,灵活性和易用性方面非常出色.但是,总会存在二进制传输效率超过这些因素的应用程序.
大量信息本质上是二进制的,可能永远不会被文本协议所取代.视频流作为一个明显的例子浮现在脑海中.
即使您压缩基于文本的协议(例如使用GZip),通用压缩算法也不会像围绕特定数据流设计的二进制协议那样高效.
但有时你不必
您看到更多基于文本的协议的原因是因为与广泛应用的数据大小相比,传输速度和数据存储容量确实快速增长.我们人类发现使用文本协议更加容易,因此我们围绕文本表示设计了无处不在的XML协议.当然,我们可以创建XML作为二进制协议,如果我们真的必须保存每个字节,并构建通用工具来可视化和处理数据.
然后再次,有时你真的做
许多开发人员习惯于考虑多GB,多核计算机.如今,即使是典型的手机也让我的第一台IBM PC-XT感到羞耻.仍然存在诸如嵌入式设备之类的平台,其对处理能力和存储器具有相当严格的限制.在处理这些设备时,二进制可能是必需的.
虽然高级语言是大多数编程工作的首选工具,并且(部分)由于CPU速度和存储能力的提高而成为可能,但它们并没有消除对汇编语言的需求.
以类似的方式,非二进制协议引入了更多抽象,更具可扩展性,因此特别适用于应用程序级通信.他们也受益于带宽和存储容量的增加.然而,在较低的水平上,如此浪费仍然是不切实际的.
此外,与编程语言不同的是,为了增加简单性,开发速度等,有强烈的动机来"降低性能", 构建层次通信的能力使得较低层的复杂性和"二元性"相当透明到应用程序级别.例如,只要收到的SOAP消息没问题,应用程序就不需要知道这些消息是通过网络有效压缩的.
我很少看到这个,但二进制协议,块协议尤其可以大大简化服务器架构的复杂性.
许多文本协议的实现方式使得解析器没有依据可以在接收到逻辑单元之前推断出需要多少数据(XML和JSON都可以提供最少的必要字节来完成,但不能提供有意义的估计).这意味着解析器可能必须定期切换到接收代码的套接字以检索更多数据.如果您的套接字处于阻塞模式,这很好,如果它们不是,那就不那么容易了.它通常意味着所有解析器状态必须保留在堆上,而不是堆栈上.
如果您有一个二进制协议,在接收过程的早期阶段,您确切知道完成数据包所需的字节数,那么您的接收操作不需要与解析操作交错.因此,解析器状态可以保存在堆栈上,解析器可以为每个消息执行一次并直接运行而不会暂停以接收更多字节.
| 归档时间： |
|
| 查看次数： |
10287 次 |
| 最近记录： |