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社羣
