本文是對上個月參加的技術沙龍總結，抱歉拖了這麼長時間才更文，最近公司的事情有點忙，回家後根本就不想看到電腦，今天工做終於告一個段落，開始把以前的落下的文章補一補。java
先說說我爲何參加這個技術沙龍。那天在csdn上閒逛，點擊活動欄目，看到在南京有融雲舉辦的線下沙龍活動。做爲歷來沒有參加過線下沙龍活動的我，一直對這樣的活動類型充滿好奇，因此就點擊了報名。在活動即將開始的前三天，我收到了短信通知和對應的參加碼。算法
首先向你們簡單介紹一個這個技術沙龍的主題——高質量、高併發的實時通訊架構設計與探索。json
活動概要
即時通信與實時音視頻做爲娛樂社交、電商購物、在線教育、生活服務、智能硬件等行業的核心功能，伴隨着行業紅利爆發，用戶規模呈指數級增加，不斷升級迭代架構，是保證用戶體驗的核心手段。網絡
活動亮點
-
實時通訊架構設計技術乾貨分享架構
-
頂級技術專家面對面交流併發
沙龍主要是融雲的幾個工程師針對不一樣的領域給出的一些解決方案分離。主要涉及sdk架構設計分享，日誌系統的演變和問題解決分享，針對小遊戲的實時交互通訊設計分享。高併發
其中讓我印象比較深入的是最後一位講師，爲何呢。由於他講到了一些個人知識盲區，起初的幾位老師講的也很是好，可是怎麼說呢。講的內容屬於已知內容的一種精進，雖然學習到了新的知識，可是並不會產生什麼太大的情緒波動。最後的這們講師說到了Quic協議，在未參加本次論壇前，我根本就不知道Quic協議是什麼，他的使用場景是什麼，有什麼樣的好處。可是通過老師的講解，我對此有了一個大概的瞭解，雖說在工做中不必定會使用到，可是橫向知識向的提高也是能加提高重要的一環。當你真正碰到問題的時候，瞭解了技術方案越多，你才能夠從中挑選出最符合當前場景的。學習
沙龍學習到的內容
第一點 protoibuf 和 json 的區別和好處
protoibuf 和 json 的區別和好處ui
Xml、Json是目前經常使用的數據交換格式，它們直接使用字段名稱維護序列化後類實例中字段與數據之間的映射關係，通常用字符串的形式保存在序列化後的字節流中。消息和消息的定義相對獨立，可讀性較好。但序列化後的數據字節很大，序列化和反序列化的時間較長，數據傳輸效率不高。
Protobuf和Xml、Json序列化的方式不一樣，採用了二進制字節的序列化方式，用字段索引和字段類型經過算法計算獲得字段以前的關係映射，從而達到更高的時間效率和空間效率，特別適合對數據大小和傳輸速率比較敏感的場合使用。
protobuf的簡單分析 優勢：經過以上的時間效率和空間效率，能夠看出protobuf的空間效率是JSON的2-5倍，時間效率要高，對於數據大小敏感，傳輸效率高的模塊能夠採用protobuf庫架構設計
缺點：消息結構可讀性不高，序列化後的字節序列爲二進制序列不能簡單的分析有效性；目前使用不普遍，只支持java,C++和Python；
第二點 瞭解quic協議的產生、優勢、使用場景
一、quic是什麼
Quic 全稱 quick udp internet connection，即：快速UDP互聯網連接。是由Google提出的基於UDP協議的多路併發傳輸協議。
二、quic的好處
1)經過減小往返次數，以縮短鏈接創建時間
(2)多路複用，解決HTTP/2隊頭阻塞問題
(3)使用FEC（前向糾錯）恢復丟失的包，以減小超時重傳
(4)使用一個隨機數（CID）標誌一個鏈接，取代傳統IP + PORT的方式，使得切換網絡環境如從4G到wifi仍然能使用以前的鏈接。
三、瞭解針對quic的實現庫
服務端 caddy
客戶端 quiche 或 quck-go
總結
經過這樣的線下技術沙龍活動，能夠幫助開發者拓展橫向領域的知識面，分享技術，討論知識，在時間容許的狀況下，多參加參加拓寬本身的見識是看的挺好的。