别说国产软件和小型软件
如果你有正版订阅，你看看 office.com
那 EXCEL 功能几乎除了 VBA 这类本地化的东西 都实现了 而且飞快

紫米的砷化镓即可

散了吧 这老兄想要一个月几百块钱的不限流量随便跑

@aureole999 #19 看来我可能用了假的 Chrome……

这个有啥影响？
我目前用 chrome 浏览器访问网站，不会被阻止，也不会有其他提示

楼主重新定义了好多概念

重新定义了云计算……
团队没能力开发虚拟化，就搞这玩意……

IDE 挂好语言插件
截图类结构 ocr

跟滴滴打车不支持人力三轮车注册成车主差不多吧

@watzds #14
整个硬盘都是一个连续数据段 问题是你不知道那个数据是啥 扔给你是没用的 要么你知道怎么存的 要么你知道原始数据是啥

硬盘数据恢复这种盲恢复都是建立在文件系统已知或者可在小范围内遍历，然后可以依赖文件存储模式进行匹配

而一个未知的裸盘数据直存文件系统 很多还是为机械硬盘优化的存储模式 你不了解其实现的情况下 是很难的

@AngryPanda #15
如果你的数据大 那么切成更多片 那就是一部分
如果数据小 肯定就在一个节点上 甚至在一个节点的一块硬盘上 也不会去刻意打乱 要不读取性能低下

搞私有云的，这个比较熟悉。上面大多数人说的都没理解这个是啥。


这些都是防止理论泄露数据可能的一部分，以常见 OSS 系统为例，这个加密的存在，只是让数据安全的风险从 99.999%提升到 99.999999%这么个过程，即使没有，原先的系统也足够安全，同时也是满足一些合规、等保的加密存储要求。


现在 OSS 的系统都是分布式存储，你上传了一个文件，首先控制引擎会把这个文件打散（文件大）或者与其他用户文件组合（文件小）成一个最小单元，然后分配给三个实际存储服务器（假设三副本模式）。

举个实际的例子吧，可能比较极端，也不考虑文件系统占用空间什么的这些，方便理解。

你创建了一个二进制文件，有 4Bytes 0x33 0x44 0x55 0x66

你上传到阿里云，在没有这个加密的时候，首先阿里云的 OSS 控制器，会把这四个 byte 与其他用户的数据组合在一起，凑够一个块大小并记录下你的数据在块的哪个位置，然后去阿里云的比如 1000 个实际存储服务器中，按既定规则根据负载，选出三个，假设是 147,304,828，把这个数据的三份分别存储到这三个服务器硬盘的一个位置，控制器会在自己的存储中记录下这三个位置，等你再需要的时候，去这三个位置的提取出这个块，再从块里的之前记录的位置还原出你的数据 0x33 0x44 0x55 0x66

这个模式下，一个小偷单纯的搬走了比如服务器 828，或者小偷就是 828 服务器的运维有 root 权限，基本都能直接访问裸硬盘设备，那么你的数据 0x33 0x44 0x55 0x66 就面临泄露，但是这在一定程度上仍然是安全的，因为 828 服务器里插了 120TB 的硬盘，鬼知道上哪里找你的 0x33 0x44 0x55 0x66…… 4bytes/120Tbytes 的大海捞针……


这时候，这个小偷，还得想办法搞到，OSS 控制服务器的存储，这样就会有一个索引，告诉他你那四个字节的重要数据，存在什么位置，这就跨系统了，一般来说，分布式架构下，你搬走了一台存储节点是比较容易的，同时还能搬走控制器数据是比较难的，而且运维也不太容易有全部权限。所以这个机制就造成了比较难泄露。毕竟控制器的存储索引，可能是一些复杂数据结构或者数据库服务，直接盗取相对困难，还得理清逻辑关系。


而本文提到的那个技术呢，就是在控制器确定把 0x33 0x44 0x55 0x66 放在哪之前，在前面的流程上，再加一个加解密服务，把 0x33 0x44 0x55 0x66 变成了可能是 0x77 0x88 0x99 0xaa，这样就算比较难得完成了刚才说的那两个部分全部掌握，获取到的也是密文。中间这个加解密服务，必然是依据密钥管理的机制，存储、操作的内容均跟运维脱钩的方式管理，更难获取。