CHAINX·PCX

Signal

全球各地数百万人每天在使用 Signal 进行免费的即时通信。收发可信的消息，进行高清视频语音通话， 让人们随时保持互联互通。借助 Signal 持续的高级隐私保护技术，可专心与重要的人分享重要的时刻。那么 Signal 都有哪些技术实现（基于服务端 3.21 版本）？

基于 websocket

首先说一下使用 websocket 通信的好处是：

1. 真正的全双工方式，建立连接后客户端与服务器端是完全平等的，可以互相主动请求。而 HTTP 长连接基于 HTTP，是传统的客户端对服务器发起请求的模式

2. 减少通信量，只要建立起 websocket 连接，就一直保持连接，在此期间可以源源不断的传送消息， 直到关闭请求。也就避免了 HTTP 的非状态性。和 HTTP 相比，不但每次连接时的总开销减少了，而 且 websocket 的首部信息量也小 ，通信量也减少了。

3. 减少资源消耗，那么为什么他会解决服务器上消耗资源的问题呢？其实我们所用的程序是要经过两层代理的，即 HTTP 协议在 Nginx 等服务器的解析下，然后再传送给 相应的 Handler（PHP等）来处理。

简单地说，我们有一个非常快速的接线员（Nginx），他负责把问题转交给相应的客服（Handler）。本身接线员基本上速度是足够的，但是每次都卡在客服 （Handler）了，老有客服处理速度太慢。导致客服不够。Websocket 就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一 转交给客户。这样就可以解决客服处理速度过慢的问题了。

Signal 加密通信软件正是基于 websocket 协议实现端对端的通信，客户端只需要与服务器建立长连接，就可以实时的接收和发送消息，而不是像传统的 http 请求-应答模式，服务器只是起一个转发消息的作用， 并不会对消息做任何的处理，消息的延迟大大降低，保证了消息的实时性。

采用 Protocol buffer

Protocol Buffer 和 XML、JSON 一样都是结构数据序列化的工具，但它们的数据格式有比较大的区别：

首先，Protocol Buffer 序列化之后得到的数据不是可读的字符串，而是二进制流

其次，XML 和 JSON 格式的数据信息都包含在了序列化之后的数据中，不需要任何其它信息就能还原序列化之后的数据；但使用 Protocol Buffer 需要事先定义数据的格式(.proto 协议文件)，还原 一个序列化之后的数据需要使用到这个定义好的数据格式

最后，在传输数据量较大的需求场景下，Protocol Buffer 比 XML、JSON 更小（3到10倍）、更快 （20到100倍）、使用和维护更简单；而且 Protocol Buffer 可以跨平台、跨语音使用

Signal 加密通信软件采用 Protocol buffer 实现对客服端与服务之间数据传输的序列化和反序列化，使传输 的数据更小，速度更快，效率更高。

Signal 通过 Redis 的发布/订阅（publish/subscribe）实现消息的转发，在发布消息的过程中，无可避免的会遇见一端下线的情况，在这种情况下发布消息会失败，Siganl 会将发布失败的消息先写入Redis缓存， 再将消息临时存储在 PostgreSQL 数据库中，当用户再次上线时，会从数据库中读取消息推送给用户，在消息推送成功之后，会将数据库中的数据删除，不做任何的保留。

端对端的

加密-X3DH 密钥算法

Signal 的核心是”畅所欲言”，对 Signal 而言，隐私并非可有可无，而是必不可缺，每条消息、每次通话、每时每刻都应受到保护，Signal 采用 X3DH 密钥协商协议来为每次的会话进行加密，来确保每条消息的隐私性。先用一个简单的场景介绍一下 DH 密钥算法：Alice 和 Bob 想要在一个不安全的信道共享一个 密钥，该密钥可被用来进行后续的其他的操作，并且仅被 Alice 和 Bob 所知，第三方无法得知。一个简单的方法就是，现在全世界都是知道一个值 P=100。Alice 生成随机值5（私钥），然后乘上 P，接着发送 Pa = 500 给Bob；同样 Bob 生成随机值6（私钥），然后乘上 P，接着发送 Pb = 600 给Alice。

这样，Alice 有 100，5 ，600，Bob 有 100，6，500。

Alice计算: 随机值 5（自己私钥） * 600（对端的公钥） = 3000 等式1

Bob 计算 : 随机值 6（自己私钥） * 500（对端的公钥） = 3000 等式2

这样 Alice 就和 Bob 共享了一个值 s=3000（公钥），双方使用 s 对消息进行加密，再使用各自的随机值（私钥）进行解密。这就是 DH 密钥算法的一个简单应用场景，Signal 的使用的 X3DH 密钥算法是在 DH 密钥算法的衍生算法 EC-DH 算法的基础上衍生出来的，它的安全性更高。

因为 Signal 所有端对端的通信都是经由服务端将消息转发，这就涉及到了服务端的压力问题，举一个简 单的场景：

在 A 地到 B 地之间有一条高速通道 S，所有的车都是通过 S 这条高速通道从 A 第到 B 地，当车流量越来越大，单条车道已经不能再满足我们通车的需求，这时候就必须拓宽我们的车道，将单车道变为双车道。随着车流量的继续增大，渐渐的双车道也不能满足通车需求，于是就将双车道拓宽为四车道、八车道。

虽然拓宽车道可以暂时的解决车流量增加的问题，但终有一天会达到临界点。服务器就像我们的车道一样，随着用户的增多，就不得不增加服务器的数量来支撑我们的服务，增加服务器数量的同时，也表示着我们的服务器越来越大.

Signal 的服务器不仅仅是用来做消息转发，还做了其他的工作，如果某天服务器再像 2021 年 1 月份出现宕机的情况，就意味着所有的服务都将不可用。

Signal 的电话号码登录

是否真的隐私？

Signal 的注册登录简单快捷，只需要使用手机+验证码就可以登录 Signal，开启隐私聊天之旅。但是 Signal 使用电话号码登录真的隐私吗？

Signal 的群内成员的注册资料，包括手机号都会被查看到，并且会查看手机的通讯录，在联系人界面展 示。对很多国家而言，都实行了实名制电话号码，每个电话号码都对应了一个真实的人。如果我想知道我的朋友是否注册了Signal，只需要在联系人界面搜索他的电话号码就可以了，这又是否足够隐私？对于有心人而言，用一个电话号码查到个人的真实信息，我相信这并不是难事。

Coming

首先来对比一下 Signal 和 Coming 的相同和不同点

从表中可以看出，Coming 和 Signal 最大的不同点有两个：

1. 对服务器的依赖：Coming 在前期会和 Signal 一样，采用 websocket 的通信方式，但在后期会增加 SMS 通信方式，用户可以在两种通信方式之间自由切换，减少对服务器的依赖，就算服务器宕机了，也还是可以进行通信，做到真正的端对端通信。

2. 对 BTC 的支持： Coming 支持多种币种的支付，与 Signal 最大的不同在于 Coming 支持 BTC 的支付。

除此之外，Coming 在后期使用链上的公私钥对进行登录，不在使用电话号码+验证码的方式登录，实现 了真正的去中心化。

我们致力于将 Coming 打造成一个去中心化、对服务器依赖轻、支持包含 BTC 在内的多种币种支付的端对端加密隐私通讯软件。

作者：Coming，来源：ChainX社区

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。