找回密码
 立即注册
查看: 660|回复: 0

Protobuf 作者不建议在 Deno 中使用 Protobuf

[复制链接]
发表于 2024-9-13 09:07 | 显示全部楼层 |阅读模式
0. 布景

我之前在”如何评价ry(Ryan Dahl)的新项目deno?”的回答中曾经写到:
我斗劲好奇的是 deno 使用了 Protobuf,而没有使用 Mojo。既然方针是要兼容浏览器,却不使用 Mojo...
...
如果想要兼容浏览器生态,选择 Mojo 是个捷径,而如果方针是高性能的处事器,那么应该选择非序列化的 zero-copy 库。无论从哪个角度看 protobuf 仿佛都不太适合 deno。
但是从 issue 中可以看出,Ryan Dahl 之前是没有风闻过 Mojo 的,但是他看完 Mojo 之后,依然感觉 Protobuf 是正确的的选择。
Ryan Dahl 最初选择了 golang,后来又将 golang 从 deno 中彻底删除。前几天 Protobuf 的作者 Kenton Varda(kentonv) 开了一个 issue:Protobuf seems like a lot of overhead for this use case? #269,在文中 kentonv 指出:
I was surprised by the choice of Protobuf for intra-process communications within Deno. Protobuf's backwards compatibility guarantees and compact wire representation offer no benefit here, while the serialize/parse round-trip on every I/O seems like it would be pretty expensive.
概略意思是:kentonv 对于 Deno 选择 Protobuf 感到很吃惊,因为 Protobuf 的兼容性优势并不是 Deno 需要的,相反,Protobuf 的序列化和反序列化非常消耗 I/O 性能。
1. Cap'n Proto 性能

kentonv 分开 Google 之后开发了 Cap'n Proto。
Cap'n Proto 对比 Protobuf 到底有多快呢?10 倍?100 倍?1000倍?官网给出了一张对比图:



Cap'n Proto 的编码解码速度是 Protobuf 的 ∞ 倍。2333
其实这张图是个标题党,图中对比了两者的编码解码,但是在 Cap'n Proto 中,是底子不需要编码和解码(encoding/decoding)的。Cap'n Proto 编码后的数据格式直接存放在内存,数据布局跟在内存里面的布局保持一致,所以可以直接将编码好的布局按照字节存放到硬盘,或者通过网络传输。
这是不是意味这 Cap'n Proto 编码是特定于平台的?
不!Cap'n Proto 采用的按字节编码方案是独立于任何平台的,但在如今主流的通用 CPU 上面会有更好的性能。数据的组织类似于编译器对 struct 的组织形式:固定宽度,固定偏移,以及内存对齐,对于可变的数组元素使用指针,而指针也是使用的偏移存放而不是绝对地址。整数使用的是小端序,因为大大都现代 CPU 都是小端序的,甚至大端序的 CPU 凡是有读取小端序数据的指令。
注:大端序(big-endian)和小端序(little-endian)统称为字节挨次。对于多字节数据,例如 32 位整数占据 4 字节,在分歧的措置器中存放方式也分歧,以内存中 0x0A0B0C0D 的存放方式为例:
在大端序中,如果数据以 8bit 为单元进行存储,则最高位字节 0x0A 存储在最低的内存地址处。
  1. 地址增长标的目的→
  2. 0x0A, 0x0B, 0x0C, 0x0D
复制代码
如果数据以 16bit 为单元进行存储,则最高的 16bit 单元 0x0A0B 存储在低位:
  1. 地址增长标的目的→
  2. 0x0A0B, 0x0C0D
复制代码
而小端序则与此相反。目前大大都主流 CPU 都是小端序的,这也是 Cap'n Proto 采用小端序的原因。
如果熟悉 C 或者 C++ 的布局体,可以看到 Cap'n Proto 的编码方式跟 struct 的内存布局很相似。即使在 V8 引擎内部,也是使用了类似的布局来进行属性的快速读取。对比使用 Hash Map 有很高的性能提升。

  • 扩展阅读:开启 V8 对象属性的“fast”模式
2. 序列化/反序列化

Protobuf 每次城市构建一个用于暗示 message 的对象,然后将对象序列化为 ArrayBuffer,在动静的接收方需要从缓冲区读取 message,然后解析为一个对应的对象,在之后的编程中使用该对象。而在 Cap'n Proto 中动静的布局直接存放在 ArrayBuffer 上,当我们调用 message.setFoo(123) 时,实际上就类似于 uint32Array[offset] = 123,在动静的接收方,我们可以直接从缓冲区读取这条动静。
Protobuf 可以使用变宽的编码,这样对于某些场景可以有更小的编码长度。而 Cap'n Proto 为了性能考虑会把整数编码为固定宽度,额外的字节使用 0 进行填充(这种存储方式很类似于 memcached)。一个是以空间换时间,一个是以时间换空间。在通过网络发送动静时,我们但愿动静体越小越好,但是如果在同一地址空间内通信时,则我们有无限带宽。Cap'n Proto 的文档中还指出,当带宽真的很重要时,无论您使用何种编码格式,都应该对动静体进行通用压缩,如 zlib 或 LZ4。
3. FlatBuffers

deno 的作者 ry 也在 issue 中参与了讨论,对大师的热情存眷 ry 感到十分打动,然后。。。。然后创建了一个 flatbuffers 分支 :P



FlatBuffers 同样是一个 created at Google 的库,具有更加完善的文档以及 Benchmarks。而 Cap'n Proto 除了阿谁“无限倍速”的不公平测试外,没有任何的基准测试数据。
而 kentonv 对基准测试的态度是:
关于基准测试 - 我花了很多时间对序列化系统进行基准测试,不幸的是,我的结论是基准测试成果几乎总是毫无意义。
...
一个真正有意义的基准测试,需要使用两种分歧的序列化来编写两个版本的实际应用法式,并对它们进行斗劲......但这是几乎没有人做过的大量工作。
这确实是个大工程。对比而言,V8 和 Chrome 每次发布城市进行 Real-world JavaScript performance
4. 安全

在当前 deno 的 protobuf 使用上,每个动静城市创建一个副本。deno 使用 protobuf 只是为了在 V8 和其他特权代码之间通讯,即使真的明确需要一个动静副本,那么也可以直接使用 memcpy() 来达到更高的性能。
如果在同一个缓冲区(ArrayBuffer),当分歧的线程同时操作时,则需要一个副本来防止 TOCTOU 缝隙,或者谨慎的措置 JavaScript 代码,但这是不成控的,因为你不能防止第三方模块也做不异的假设(如果第三方扩展也使用不异的通讯机制的化)。
TOCTOU 的全程是“time of check to time of use”,TOCTOU 是竞争条件缺陷的一种。在多线程、多核系统中,这个缝隙很遍及。当我们访谒某个共享资源时,系统首先会检测当前用户或代码是否有权限,而查抄(check)和使用(use)是分手的,而且不是原子的。当系统查抄资源被授予用户权限后,攻击者可以临时阻塞调用户线程,然后在时间差内替换调资源,以达到越权访谒的目的。
举个简单的例子:
  1. if (hasPermission(”file”)) {// (1)buffer = open(”file”);// (2) dosthwrite(”file”, buffer);// (3)
  2. }
复制代码
而攻击者可以在 (1) 处构造如下代码:
  1. // ...
  2. // hasPermission 查抄通过
  3. symlink(”/etc/passwd”, ”file”);
  4. // 文件打开之前
  5. // ...
复制代码
这样用户就越权拿到了 ”/etc/passwd” 的控制权。
上面只是一个简单的例子,TOCTOU 有很多分歧的形式。在类 Unix 系统上,/tmp 和 /var/tmp 目录经常会被错误地使用,从而导致竞争条件。
为了安全而暂时损掉性能是一种不得已的妥协,之前 V8 也遇到过,对于逃逸分析的缝隙直接导致了安全问题,Chrome 团队不得不不才一个发行版中去除了逃逸分析。

  • 扩展阅读:V8 团队的一个错误,使得整个互联网变慢
5. 综上

Deno 就像一个出生不久的孩子,Ryan Dahl 也在不竭的探索,不免会走一些弯路。而作为普通开发者的我们,可以存眷 deno 的源码以及 github 上的 commit。
对于一个非常成熟的项目,比如 Node.js,我们很难读懂他的全部源码,甚至我们都不知道从何读起。而 deno 则是一个机会,我们见证了 deno 的诞生,截至到我写这篇文章,deno 一共才有 249 次 commit。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-10-14 09:45 , Processed in 0.099568 second(s), 28 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表