適合新手：手把手教你用Go快速搭建高性能、可擴展的IM系統(有源碼)

摘要: 本文為開源工程：“github.com/GuoZhaoran/fastIM”的配套文章，原作者：“繪你一世傾城”，現為：獵豹移動php開發工程師，感謝原作者的技術分享。0、引言閱讀提示：本文適合有一定網絡通信技術基礎的IM新手閱讀。如果你對網絡編程，以及IM的一些理論知識知之甚少，請務必首先閱讀：《新手入門一篇就夠：從零開發移動端IM》，按需補充相關... 閱讀全文

posted @ 2020-04-28 12:05 Jack Jiang 閱讀(474) | 評論 (0) | 編輯收藏

[資源] 阿里《Java開發手冊v1.6.0-泰山版》發布

阿里巴巴技術團隊于2020年04月22日發布《Java開發手冊v1.6.0-泰山版》。

1、概述

2017年開春之際，阿里誠意獻上重磅大禮：《阿里巴巴Java開發手冊(規約)》，首次公開阿里官方Java代碼規范標準。這套Java統一規范標準將有助于提高行業編碼規范化水平，幫助行業人員提高開發質量和效率、大大降低代碼維護成本。

《阿里巴巴Java開發手冊(規約)》是阿里內部Java工程師所遵循的開發規范，涵蓋編程規約、單元測試規約、異常日志規約、MySQL規約、工程規約、安全規約等，這是近萬名阿里Java技術精英的經驗總結，并經歷了多次大規模一線實戰檢驗及完善。這是阿里回饋給Java社區的一份禮物，希望能夠幫助企業開發團隊在Java開發上更高效、容錯、有協作性，提高代碼質量，降低項目維護成本。

另外，《作者談《阿里巴巴Java開發手冊(規約)》背后的故事》一文，可以看看作者怎么說。

下載方式：詳見文末 “6、歷史版及最新版下載地址” ！

2、價值意義

《阿里巴巴Java開發手冊(規約)》的愿景是碼出高效，碼出質量。它結合作者的開發經驗和架構歷程，提煉阿里巴巴集團技術團隊的集體編程經驗和軟件設計智慧，濃縮成為立體的編程規范和最佳實踐。眾所周知，現代軟件行業的高速發展對開發者的綜合素質要求越來越高，因為不僅是編程相關的知識點，其他維度的知識點也會影響軟件的最終交付質量，比如，數據庫的表結構和索引設計缺陷可能帶來軟件的架構缺陷或性能風險；單元測試的失位導致集成測試困難；沒有鑒權的漏洞代碼易被黑客攻擊等。所以，本手冊以開發者為中心視角，劃分為編程規約、異常日志、單元測試、安全規約、MySQL數據庫、工程結構、設計規約七個維度，每個條目下有相應的擴展解釋和說明，正例和反例，全面、立體、形象地幫助到開發者的成長和團隊代碼規約文化的形成。

從嚴格意義上講，《阿里巴巴Java開發手冊(規約)》超越了Java語言本身，明確作為一名合格開發者應該具備的基本素質，因此本手冊適合計算機相關行業的管理者和研發人員、高等院校的計算機專業師生、求職者等閱讀，希望成為大家如良師益友般的工作手冊、工具字典。

3、最新動態

關于泰山版（v1.6.0）：

此版發布于2020年04月22日，此版升級內容包括：

1）發布錯誤碼統一解決方案，詳細參考手冊的“附表 3”。
2）新增 34 條新規約。如：日期時間的閏年、閏月問題，三目運算的自動拆箱，SQL查詢的表別名限定，Collectors 類的 toMap()方法使用注意等。
3）修改描述 90 處。如：阻塞等待鎖、建表的小數類型等。
4）完善若干處示例。如：ISNULL 的示例等

4、主要作者

楊冠寶：

楊冠寶：花名孤盡，取自《笑傲江湖》中風清揚的“獨孤九劍，破盡天下武功”之意，是《阿里巴巴Java開發手冊》的主要作者。在阿里巴巴集團歷任研發、架構師、技術主管等不同的角色，承擔過雙11、國際化、代碼中心等大型項目，有著豐富的一線編程經驗，目前是研發協同平臺Aone代碼中心負責人。樂于分享與總結，在阿里巴巴集團內部大型分享多達30余次，不懈地追求技術創新，勇于挑戰技術難度，在大數據、高并發、研發效能領域均有較深的造詣。

2016年3月，孤盡帶領約碼項目組編寫《阿里巴巴Java開發手冊(規約)》，碼出高效，碼出質量，推動阿里系與業界一起進步，讓代碼變得更舒服，更清澈，更好維護。

5、部分內容截圖預覽

posted @ 2020-04-23 11:44 Jack Jiang 閱讀(1042) | 評論 (0) | 編輯收藏

愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇

本文原始內容由愛奇藝技術產品團隊原創分享，本次有修訂和改動。

1、引言

由于移動網絡的復雜性特點，編寫高質量、體驗好的具備網絡通信能力的移動端應用（尤其是即時通訊這類網絡質量高度敏感的應用）有很大的挑戰性。

我們平時看到的移動網絡主要有如下三個典型特點：

1）移動狀態網絡信號不穩定，高時延、易抖動丟包、通道狹窄；
2）移動狀態網絡接入類型和接入點變化頻繁；
3）移動狀態用戶使用高頻化、碎片化、非WIFI流量敏感。

（▲ 上述文字，引用自《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》）

正是由于上述特點，移動端應用在進行網絡數據通信時會面臨各種復雜多變的問題。

無論后面的技術有多復雜，但對于普通用戶使用APP來說，能順暢的完成網絡請求，是理所當然的事。換句話說，APP網絡請求成功率，重要性直接體現在它能直接決定APP服務的可用性，直接影響到數據通信、視頻播放、廣告展現、支付便捷等服務質量。

本文將以愛奇藝的iOS端APP為例，分享對移動網絡請求成功率優化方面的技術實踐之路。

本文將同時發布于“即時通訊技術圈”公眾號，歡迎關注：

（本文已同步發布于：http://www.52im.net/thread-2981-1-1.html）

2、相關文章

《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》（* 必讀好文）
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》

3、導致移動端網絡請求失敗的因素

想要優化移動端網絡請求成功率，先來了解移動端網絡請求全鏈條可能導致請求失敗的環節有哪些。

這些環節往往由以下兩類因素導致：

第一類：不可改善因素：

1）iOS系統對APP的網絡訪問權限控制、飛行模式或者無網絡連接。檢測和識別這三種情況，通過適當方式提示用戶；
2）路由器故障。

第二類：可以改善因素：

1）蜂窩/Wifi信號的強弱、連接擁堵的假連接狀態；
2）DNS故障（比如DNS劫持等）；
3）運營商局部節點故障；
4）自有運營負載均衡故障；
5）業務服務器故障：HTTP響應錯誤，對應APM的HTTP響應錯誤率；
6）業務邏輯錯誤：監控子類解析結果，對應APM的解析錯誤率監控。

對于不可改善因素：目前只能通過網絡診斷識別出故障類型，引導用戶手動去授權訪問網絡或者連接可用網絡。

其中，如果是路由器故障，可以引導用戶重啟路由器或者切換4G。通過愛奇藝APP的數據監控，大致可以看到用戶無網連接的時長占比有3.8%左右，這說明提供好的無網提示變得十分重要，而從用戶使用蜂窩信號的弱信號(0格和1格信號)時長占比有9%左右時長，也可以看出移動端網絡環境的復雜性。

針對可以改善的因素，解決方法可大致分為三類：

1）網絡層錯誤，對應因素1到4。主要體現為超時報錯；
2）HTTP響應錯誤，對應因素5。HTTP狀態碼為400及以上；
3）解析錯誤，對應因素6。由基線網絡庫定義的重載接口進行監控。

為了提高網絡請求成功率，首先需要建立監控體系，從而使得基線網絡庫能夠通過網絡統計模塊向APM投遞各種維度的網絡請求數據。有了APM的數據統計后，才能有效的發現導致端上網絡失敗的原因，進而解決問題。

除此之外，由于端上網絡請求數據巨大，存儲空間的限制使得APM只能采樣2%的用戶，因此針對重點業務的網絡請求（比如首頁）則進行了全量采集，從而對成功率的優化實現更客觀全面的評估。

4、在基線網絡庫這一層針對不同業務提供不同的補償思路

在優化之前，通過APM的歸類分析可以得出：請求失敗的主要報錯是超時(-1001)的占比達到九成，與此同時SSL錯誤，DNS解析錯誤占比緊隨其后。根據這一數據統計，重試成為最主要的請求成功率優化的措施。

經過不斷探索和實踐總結，基線網絡庫針對不同業務需求提供了四種不同的重試手段。

1）IP直連重試，通過配置直連IP數來控制重試次數：

Scheme不變，Host改為直接使用IP(消除域名解析風險)。由于此舉需要各個業務線自己提供直連的IP，目前接入的業務主要是登錄等強制要求HTTPS連接的業務。

2）超級管道重試，可以配置1~3次重試：

公司自研基于HTTP的網關代理服務(類似于遠程charles代理)。Host改為代理IP(消除域名解析風險)，Scheme改為HTTP(消除SSL風險，h2降級為HTTP1.1)。由于該措施需要付出流量成本，目前接入的業務都是關鍵核心業務，比如首頁等。

3）HTTP重試，可以配置1~3次重試：

Scheme修改為HTTP(消除SSL風險，h2降級為HTTP1.1)，其他不變。鑒于其為普惠性重試手段，目前接入非關鍵核心的一般業務。

4）原url重試，可以配置1~3次重試：

Scheme和host等都不變，通常意義上理解的重試，單純的再請求一次。此舉目前不是推薦重試手段，由業務方自主決定。

除了單個重試手段可以重試多次，基礎網絡庫也支持多種重試手段的組合，四種重試手段的優先次序為：IP直連重試 > 超級管道重試 > HTTP重試 > 原URL重試。扣除無網情況，首頁推薦頁CARD接口成功率通過組合重試在2020第一季度末達到了99.76%。

5、其它影響移動端網絡請求成功率的因素

除了重試，還有以下因素對網絡請求成功率有直接影響。

1）HTTP/2 vs HTTP/1.1：推薦的請求策略是首次請求走H2，當失敗重試時走HTTP/1.1：

HTTP/2對HTTP/1.1最大改進是共用一個TCP連接（詳見《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》），其在網絡順暢時，為HTTP/2帶來了速度上的優勢。但當網絡變壞時，TCP包的絕對順序編號會導致一個包的丟失而堵住后面所有的請求。這樣單TCP連接反而擴大了擁堵，增大了請求失敗的可能性。

NSURLSession是HTTP協議自適應的，不能控制請求使用HTTP/2或者HTTP/1.1。不過由于業界事實上的標準要求HTTP/2必須是HTTPs的，這樣通過將URL Scheme改為HTTP可以間接降級到HTTP/1.1。

2）適當的超時設置是一個重要影響因素：

NSURLSession的超時實際上是TCP的包間超時，并不是整體請求耗時的超時。

推薦的超時設置策略是：首次請求的超時可以小一點，而重試的超時應該大一些。

3）接口請求過于密集并發可能降低請求成功率：

比如播放記錄的upload接口在加上多次重試后，成功率仍然只有98.2%。APM監控此接口在IPv4環境失敗率只有0.47%，而IPv6失敗率高達7.07%。通過端上優化請求策略，降低接口的并發密度后，IPv6環境和IPv4環境同時提高到99.85%的成功率。

4）接口數據體積越小，請求成功率越高：

HTTP/2和HTTP/1.1都是基于TCP連接的，接口數據體積越小，需要傳輸的TCP包越少，傳輸失敗的概率也就降低了。目前愛奇藝APP正在從gzip轉向壓縮率更高的br（指的是Brotli壓縮算法，詳見：《啟用 Brotli 壓縮算法，對比 Gzip 壓縮 CDN 流量再減少 20%》）。

6、提高魯棒性并防止故障的優化措施

在經過各種優化措施提高網絡成功率后，我們還通過下面幾個措施成功的防止線上故障造成的成功率瞬時下降，提高了網絡請求的魯棒性。

1）超級管道本身的魯棒性：

下面案例顯示使用了超級管道重試的接口錯誤率只有3.95%，而沒有使用超級管道重試的接口錯誤率高達28.96%。這個案例的時間點還沒有使用異地容災IP，在疊加異地容災IP之后，錯誤率曲線幾乎可以抹平。

2）HTTP重試和原URL重試在v4v6雙棧環境下，優先IPv4：

由于IPv6仍在建設中，有些接口在IPv6的表現弱于IPv4，那么可以指定重試走IPv4。

3）TLS1.3– 1RTT的節?。?/em>

TLS1.3將SSL握手2個RTT降為1個RTT，降低了SSL握手失敗的概率。iOS12.2開始，NSURLSession支持TLS1.3。只需要服務器升級支持TLS1.3即可，端上無須改動。

4）IP復合連接競速：

使用TCP連接測速，目的是剔除壞IP，選擇最優IP，從而提高請求的成功概率。

經上述措施的持續優化，愛奇藝APP在2020Q1末，扣除無網情況后，業務成功率達到了99.7%，而網絡層成功率達到了99.77%。

▲ 業務成功率 = 網絡層成功率+HTTP響應成功率+解析成功率

在完成優化后，愛奇藝APP基礎網絡庫的構成如下：

如上圖所示，基礎網絡庫各模板的功能作用如下：

1）統一網絡庫：提供一個網絡接口層，所有業務接口都對接使用網絡接口層；

2）統一網絡庫：提供一個網絡封裝層，對接了iOS系統網絡層NSURLSession、ASIHTTPRequest(基于CFNetwork)、和公司自研的長連接網關；

3）網絡統計模塊：將從業務調用開始到回調給業務方的各個環節的耗時及狀態值，變成統計數據，上傳到APM匯合；

4）網絡診斷模塊：對關鍵業務進行診斷，包括dns解析，ping，tcpconnect，trace等工具對具體IP進行分析，分析結果上傳到APM匯合；

5）弱網檢測模塊：通過借鑒Facebook的弱網檢測是基于網速擬合的網絡等級分級，分為網絡情況非常差(2G或者無網)、網絡情況較差(3G)、網絡情況一般、網絡情況較好、網絡情況非常好五個等級；

6）HTTPDNS模塊：有效的解決了運營商劫持問題；

7）超級管道重試：基于HTTP的網關代理，具有異地容災代理能力；

8）ipv4/ipv6模塊：識別端上是ipv4 only環境、v4/v6雙棧還是ipv6 only環境；

9）復合連接模塊：可以在server IP緩存池選出最佳IP，手段包括目標IP連接競速，IP歷史請求統計數據排序；

10）網絡日志模塊：記錄了最近發生的失敗網絡請求詳細數據和網絡診斷數據。隨反饋一并提交，可以便捷的排查線上網絡問題。

7、未來的目標與可能的優化措施

為了持續優化網絡成功率，下一步目標是扣除無網情況，重點業務成功率達到99.9%。后續考慮的優化措施如下。

1）Multipath：

當Wifi假連接的時可以走蜂窩流量，iOS 7開始支持Multipath特性（詳見：《揭開 iOS 7 之 Multipath TCP 的面紗》）。

2）QUIC：

QUIC是基于UDP的，由于運營商對UDP有針對性的丟包，實測QUIC并沒有體現出優勢。然而，考慮到libcurl在2019已提供完整QUIC能力，NSURLSession不久也會支持QUIC。隨著運營商對UDP包的干擾減少，QUIC的優勢將得到體現。

如果對QUIC協議感興趣，可以讀一讀下面這些文章：

《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》

《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》

《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》

《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》

3）智能調度并發：

更精準更靈敏的弱網識別，弱網下對關鍵核心業務進行傾斜。

4）HTTPDNS的push能力：

HTTPDNS打通APM的質量監控體系后，通過push及時下線故障IP。

關于移動端DNS問題上的優化，業內已經有了很多總結，有興趣可以深入研究：

《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》

《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》

《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》

《移動端網絡優化之HTTP請求的DNS優化》

附錄：更多網絡通信方面的技術資料

《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)》
《P2P技術詳解(四)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《網絡編程懶人入門(十一)：一文讀懂什么是IPv6》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《腦殘式網絡編程入門(七)：面視必備，史上最通俗計算機網絡分層詳解》
《腦殘式網絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》
《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》
《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《技術大牛陳碩的分享：由淺入深，網絡編程學習經驗干貨總結》
《可能會搞砸你的面試：你知道一個TCP連接上能發起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級并發的高性能長連接網關技術實踐》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
《愛奇藝移動網絡優化實踐分享：網絡請求成功率優化篇(iOS端)》
>> 更多同類文章 ……

歡迎關注我的“即時通訊技術圈”公眾號：

（本文已同步發布于：http://www.52im.net/thread-2981-1-1.html）

posted @ 2020-04-21 14:20 Jack Jiang 閱讀(320) | 評論 (0) | 編輯收藏

網絡編程懶人入門(十一)：一文讀懂什么是IPv6

本文同時發布于“即時通訊技術圈”公眾號，鏈接是：https://mp.weixin.qq.com/s/cS5xB2DrjF52rmz6EGVJ6A。
本文參考了公眾號鮮棗課堂的“IPv6，到底是什么？”一文的部分內容，感謝原作者。
1、引言
現在IPv6的技術應用已經越來越普及了，很多應用都開始支持IPv6。

▲ 去年開始，支付寶的官網上就已出現“支持IPv6”標識
對于即時通訊技術（尤其是IM應用）的開發者來說，新產品上架蘋果的App Store因IPv6問題被拒的情況，很常見。每次也都能根據網上的資料一一解決，并順利通過審核。
然而幾次下來，到底什么是IPv6，還是有點云里霧里。
那么，IP協議在TCP/IP體系中到底有多重要？看看下圖便知（原因清晰版：從此處進入下載）。

▲ 紅圈處就是IP協議，它幾乎是整個TCP/IP協議簇的支撐（圖引用自《計算機網絡通訊協議關系圖》）
總之，IP協議在TCP/IP體系中，是非常重要的一環（可以認為，沒它，也就沒有了互聯網），作為IPv4的下一代協議，了解IPv6非常有必要。而作為即時通訊開發者來說，了解IPv6就顯的尤為迫切，說不定某天你的IM就會因為IPv6問題而導致無法通信的局面出現。
本文將用淺顯易懂的文字，帶你了解到底什么是IPv6。
（本文同步發布于：http://www.52im.net/thread-2979-1-1.html）
2、系列文章
本文是系列文章中的第11篇，本系列文章的大綱如下：
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《網絡編程懶人入門(十一)：一文讀懂什么是IPv6》（本文）
3、復習一下什么是IPv4？
IPv4是Internet Protocol version 4的縮寫，中文翻譯為互聯網通信協議第四版，通常簡稱為網際協議版本4。
IPv4使用32位（4字節）地址，因此地址空間中只有 4,294,967,296（即2^32）個地址。
IPv4地址可被寫作任何表示一個32位整數值的形式，但為了方便人類閱讀和分析，它通常被寫作點分十進制的形式，即四個字節被分開用十進制寫出，中間用點分隔。
通常IPv4地址的地址格式為 nnn.nnn.nnn.nnn，就像下面這樣：
172.16.254.1
下圖看起來更清晰一些：
4、IPv6又是什么？
IPv6是Internet Protocol version 6的縮寫，中文翻譯為互聯網通信協議（TCP/IP協議）第6版，通常簡稱為網際協議版6。IPv6具有比IPv4大得多的編碼地址空間，用它來取代IPv4主要是為了解決IPv4地址枯竭問題，同時它也在其他方面對于IPv4有許多改進。
其實，IPv6并不是新技術，從IPv6最早的工作組成立1992年到現在，已過去27年。在互聯網技術的發展歷程中，IPv6年齡甚至有些太大了。
IPv6的“6”表示的是TCP/IP協議的第六個版本，IPv4的“4”表示的是TCP/IP協議的第四個版本。其實除了這兩個版本，當然還有其它版本，TCP/IP協議其實從IPv1開始，到現在IPv10都已經出現了，這些不同版本之間并沒有關聯，也不是簡單IP地址長度的長短。
IPv6地址由八組、每組四位16進制數字組成，每組之間由"："來分隔。
看個簡單的例子：
2610:00f8:0c34:67f9:0200:83ff:fe94:4c36，每個“：”前后都是4位16進制的數字，共分隔成8組。
如下圖所示：

小知識：如何查看手機或者電腦的網絡是否支持IPv6呢？
可以在你手機或者電腦上的瀏覽器中打開：Ipv6-test.com，就像下圖這樣：
5、為什么要使用IPv6？
最主要的原因，就是地址數量不夠用了。
IPv4迄今為止已經使用了30多年。最早期的時候，互聯網只是設計給美國軍方用的，根本沒有考慮到它會變得如此龐大，成為全球網絡。
尤其是進入21世紀后，隨著計算機和智能手機的迅速普及，互聯網開始爆發性發展，越來越多的上網設備出現，越來越多的人開始連接互聯網。這就意味著，需要越來越多的IP地址。
IPv4的地址總數是2的32次方，也就是約42.9億個。而全球的網民總數早已超過這個數目。

所以說，IPv4地址池接近枯竭，根本無法滿足互聯網發展的需要。人們迫切需要更高版本的IP協議，更大數量的IP地址池。（有點像固定電話號碼升位。）
6、IPv6會帶給我們什么？
首先，最重要的一點，就是前面所說的地址池擴容。IPv4的地址池是約42.9億，IPv6能達到多少呢？
數量如下：
340282366920938463463374607431768211456個…
不用數了，太多了… 簡單說，是2的128次方。
這個數量，即使是給地球上每一顆沙子都分配一個IP，也是妥妥夠用的。

▲ 這圖你看懂了嗎？嗯，我也沒看懂，反正就是很多的樣子
這個數量值是怎么得來的呢？還是它的地址位長決定的。
如果以二進制來寫，IPv6的地址是128位。不過，這樣寫顯然不太方便（一行都寫不下）。所以，通常用十六進制來寫，也就縮短成32位（32位會分為8組，每組4位）。
下面就是一個標準、合法的IPv6地址示例：
2001:0db8:85a3:08d3:1319:8a2e:0370:7344
注意：IPv6的地址是可以簡寫的，每項數字前導的0可以省略。
例如，下面這個地址：
2001:0DB8:02de:0000:0000:0000:0000:0e13
粉紅的“0”就可以省略，變成：
2001: DB8:2de:0:0:0:0:e13
如果有一組或連續幾組都是0，那么可以簡寫成“::”，也就是：
2001: DB8:2de::e13
注意：一個IPv6地址，只能有一個“::”。
為什么？很簡單，你看下面這四個地址，如果所有0全都縮寫，會變成什么樣？
2001:0000:0000:0000:0000:25de:0000:cade
2001: 0000: 0000:0000:25de:0000:0000:cade
2001: 0000: 0000:25de:0000:0000:0000:cade
2001: 0000: 25de:0000:0000:0000:0000:cade
是的，都是2001::25de::cade，沖突了。所以，這個地址是非法的，不允許存在的。
關于IPv6還有很多技術細節，因篇幅原因，不再贅述。
除了地址數量之外，IPv6還有很多優點，例如：
1）IPv6使用更小的路由表。使得路由器轉發數據包的速度更快；
2）IPv6增加了增強的組播支持以及對流的控制，對多媒體應用很有利，對服務質量（QoS）控制也很有利；
3）IPv6加入了對自動配置的支持。這是對DHCP協議的改進和擴展，使得網絡（尤其是局域網）的管理更加方便和快捷；
4）IPv6具有更高的安全性。用戶可以對網絡層的數據進行加密并對IP報文進行校驗，極大地增強了網絡的安全性；
5）IPv6具有更好的擴容能力。如果新的技術或應用需要時，IPV6允許協議進行擴充；
6）IPv6具有更好的頭部格式。IPV6使用新的頭部格式，就簡化和加速了路由選擇過程，提高了效率；
……
7、IPv6的優點這么多，為什么之前普及卻這么慢？
IPv6優點這么多，為什么它問世已經20年了，還是沒有完全替代IPv4呢？這里面的水就很深了。。。說白了，主要還是和利益有關。
7.1 NAT這類技術，讓IPv4得以續命
如果按照本世紀初專家們的預測，我們IPv4的地址早已枯竭幾萬次了。但是，一直挺到現在，大家仍然還在用IPv4，對老百姓來說，并沒有因為地址不夠而無法上網。
這是為什么呢？就是因為除了IPv6之外，我們還有一些技術，可以變相地緩解地址不足。
例如NAT（Network Address Translation，網絡地址轉換）。
NAT是什么意思？當我們在家里或公司上網時，你的電腦肯定有一個類似192.168.0.1的地址，這種地址屬于私網地址，不屬于公共的互聯網地址。
▲ 一個典型的NAT應用場景（圖自《IPv6，到底是什么？》）
每一個小的局域網，都會使用一個網段的私網地址，在與外界連接時，再變換成公網地址。這樣一來，幾十個或幾百個電腦，都只需要一個公網地址。
甚至還可以私網套私網，NAT套NAT，一層一層套。這樣一來，大大節約了公網IP地址數量。正因為如此，才讓我們“續命”到了今天，不至于無法上網。
但是，NAT這種方式也有很多缺點，雖然私網地址訪問互聯網地址方便，但互聯網地址訪問私網地址就困難了。很多服務，都會受到限制，你只能通過復雜的設置才能解決，也會影響網絡的處理效率。
▲ NAT內網的計算機是不能被外網直接訪問的（圖自《IPv6，到底是什么？》）
7.2 升級IPv6涉及運營商的利益
物以稀為貴，地址越稀缺，就越值錢。掌握地址的人，就越開心。誰開心？運營商和ISP（互聯網服務提供商）。
他們就像是經銷商，從上游（互聯網域名與號碼分配機構，即ICANN）申請到IP地址，再賣給下游用戶。稀缺沒關系，反正，他一定能賺取更多的差價。
如果大家去找運營商或ISP買帶寬，或者租賃云服務，帶公共地址的，一定比不帶公共地址的貴很多很多。
除了地址可以賺錢之外，如果升級支持IPv6，對運營商和ISP來說，也意味著很大的資金投入。現在新設備基本都是支持的，但畢竟還是有一些老設備，如果在使用壽命到期之前就換，就是虧錢。
所以，運營商和ISP都沒有動力去啟用IPv6。
至于設備商或手機電腦廠商，出于提前考慮，早已普遍支持了IPv6，意見并不是很大，也決定不了什么。必竟，提供基礎設施服務的運營商們更強勢。
8、IPv6未來會怎樣
隨著5G時代的到來，有了IPv6的加持，萬物互聯或許會成為現實。對于我等實時通信類軟件的開發人員來說，某些場景下，或許再也不需要為“P2P打洞”這種事情煩惱了。
▲ 5G+IPv6，萬物互聯不是夢
未來已來，你準備好了嗎？
9、參考資料
[1] IPv6入門教程
[2] IPv6，到底是什么？
[3] 關于IPv6的發展史！IPv6的秘密史！
[4] 科普：一文讀懂IPv6是什么？
[5] 漫話：全球IPv4地址正式耗盡？到底什么是IPv4和IPv6？
附錄：更多網絡編程基礎知識文章
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)》
《P2P技術詳解(四)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《腦殘式網絡編程入門(七)：面視必備，史上最通俗計算機網絡分層詳解》
《腦殘式網絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》
《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》
《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《技術大牛陳碩的分享：由淺入深，網絡編程學習經驗干貨總結》
《可能會搞砸你的面試：你知道一個TCP連接上能發起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級并發的高性能長連接網關技術實踐》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
>> 更多同類文章 ……
歡迎關注我的“即時通訊技術圈”公眾號：
（本文同步發布于：http://www.52im.net/thread-2979-1-1.html）

posted @ 2020-04-17 11:21 Jack Jiang 閱讀(401) | 評論 (0) | 編輯收藏

5G時代已經到來，TCP/IP老矣，尚能飯否？

本文已同時發布于我的“即時通訊技術圈”公眾號。
1、引言
哈羅，大家好，我是Jack Jiang。。。（一股濃濃的自媒體視頻旁白味道）。
對于經?？次椅恼碌募磿r通訊開發者來說，今天要討論的這個話題，貌似有點不著邊際。
是的，自從我整理完《IM開發者的零基礎通信技術入門》系列文章之后，對于網絡編程的理解，開始有點飄了。
言歸正傳?，F在，5G技術離我們的生活越來越近了，號稱網絡延遲1ms、下行速度10Gb/s的5G，在這樣逆天的網絡性能指標下，老驥伏櫪的TCP/IP是否仍能Hold的??？帶著這個思考，便有了本文的內容。

▲ 5G網速有多快？看圖感受一下（圖自《零基礎，史上最強5G技術掃盲》）
（本文已同步發布于：http://www.52im.net/thread-2976-1-1.html）
2、學好TCP/IP夠用嗎？
對于即時通訊技術的開發者，從技術棧來說，一條最普通的聊天消息的送達，肯定要涉及到網絡編程技術，而網絡編程最核心的也就是TCP/IP協議（準確的說是TCP/IP協議簇，見《TCP/IP詳解》），毫無疑問深入的學習TCP/IP協議肯定是非常有必要了。
基本上，對于普通的IM或消息推送系統開發來說，對TCP/IP相關的計算機網絡基礎比較熟悉的話，完全夠用了。

▲ 這本書很多人都讀過
3、移動網絡問題，只能賴我代碼爛？
親手寫過即時通訊的網絡通信層的同學都很清楚，在移動網絡中（我說的移動網絡具體指的是運營商的2g/3g/4g/5g這些），因為無線通信的介質和技術實現特殊性，出現了很多傳統有線互聯網不曾有過的網絡通信問題。
就拿IM在移動弱網中出現的各種問題來說，多數開發者都不自信的認為這應該是自已的網絡層代碼寫的不夠優秀，是的，很多時候也確實是這樣。
我收集整理的下面這幾篇資料，就討論的是這些，有興趣可以讀一下：
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《微信移動端應對弱網絡情況的探索和實踐PPT [附件下載]》
《YY直播在移動弱網環境下的深度優化實踐分享(視頻+PPT)[附件下載]》
其實，很少有人會去思考，在TCP/IP協議被發明出來的50年后，對于現代的移動網絡來說，是否仍然能工作的好？以弱網問題為例，難道我寫的IM總是丟消息、掉線就僅僅是“我”的代碼太爛？
沒錯，這不僅僅是應用層的代碼編寫問題，它或許涉及到TCP/IP的設計局限，甚至移動網絡的底層設計也并不是最完美的。
下面這兩篇文章，對于弱網問題思考，已經深入到運營商的通信技術這一層，強烈建議讀一讀：
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
如果你的認知，已經開始對底層的網絡通信技術有所困惑，下面這幾篇就是為你準備的：
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
4、簡單復習一下TCP/IP
從字面意義上講，有人可能會認為 TCP/IP 是指 TCP 和 IP 兩種協議。實際生活當中有時也確實就是指這兩種協議。
然而在很多情況下，它只是利用 IP 進行通信時所必須用到的協議簇的統稱。
具體來說，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬于 TCP/IP 協議。他們與 TCP 或 IP 的關系緊密，是互聯網必不可少的組成部分。TCP/IP 一詞泛指這些協議，因此，有時也稱 TCP/IP 為網際協議簇。
互聯網進行通信時，需要相應的網絡協議，TCP/IP 原本就是為使用互聯網而開發制定的協議簇。因此，互聯網的協議就是 TCP/IP，TCP/IP 就是互聯網的協議。
▲ 上圖反映了TCP/IP協議族的關系（圖片引用自《計算機網絡通訊協議關系圖》）
5、TCP/IP或許太老了
對于現代移動網絡來說，TCP/IP或許太老了。我們簡單了解一下TCP/IP協議的產生過程。
1973年：卡恩與瑟夫開發出了TCP/IP協議中最核心的兩個協議：TCP協議和IP協議。
1974年：卡恩與瑟夫正式發表了TCP/IP協議并對其進行了詳細的說明。同時，為了驗證TCP/IP協議的可用性，使一個數據包由一端發出，在經過近10萬km的旅程后到達服務端。在這次傳輸中，數據包沒有丟失一個字節，這充分說明了TCP/IP協議的成功。
1983年：TCP/IP協議正式替代NCP，從此以后TCP/IP成為大部分因特網共同遵守的一種網絡規則。
1984年：TCP/IP協議得到美國國防部的肯定，成為多數計算機共同遵守的一個標準。
是的，你沒有看錯，TCP/IP協議設計于距今50年前！

▲ 羅伯特·卡恩(左者)與文特·瑟夫(右者)（圖片引用自《技術往事：改變世界的TCP/IP協議》）
6、TCP/IP原本是為固定網絡設計的
雖然TCP/IP自上世紀70年代發明以來，連接了無數的計算機，推動了互聯網的蓬勃發展。
但不可回避的現實是，基于TCP/IP的互聯網，它的初衷是為固定網絡和網絡互連而設計，而今天我們已經發展到了移動互聯時代。
再往后看，未來5G將面臨AR/VR、超高清視頻、物聯網、車聯網等各種應用、用例紛呈，加之網絡安全的緊迫性越發凸顯，TCP/IP或許難以適應未來。
7、TCP/IP或許并不適合移動網絡
7.1 TCP/IP設計之初無法預見高速移動網時代
在TCP/IP剛被設計的年代，即傳統固定互聯網的公元元年，主機是固定的，用于編址的IP也是固定的，世界是平的。
可是隨著應用程序以及芯片技術的活力涌現，設備越來越小，App越來越豐富，當你覺得渾身憋得慌的時候，移動互聯網時代來了。
但傳統的TCP/IP并不適合移動網絡，以TCP/IP協議簇中我們最常用的TCP協議來說，傳統的TCP基于TCP/IP協議頭字段的五元組，而標識設備的IP地址僅僅標識了設備位置，并沒有標識設備本身（實際上不管到了什么年代，IP地址都不應該標識設備本身，它就是標識位置的！問題是，TCP不應該用一個標識位置的元素來標識設備）。
而對于移動互聯網來說，一旦移動設備（比如智能手機）換了位置（通信基站切換了），其IP地址也會改變，進而既有的TCP連接將全部中斷。

▲ 運營商的基站是有覆蓋范圍的，而且覆蓋范圍并不大
對于底層的移動網絡通信技術有所了解的開發人員或許知道，手機的通信是由基站進行代理的，而基站是固定的。換句話說，當你移動到下一個基站的位置時，手機就得自動切換到新的基站，進而重新進行一系列的跟運營商的無線體系進行連接建立的過程。
這在日常生活中使用并沒有什么問題，但在時速達到350公里每小時的復興號高鐵上用手機上網時，這就會導致嚴重的問題。因為基站的信號覆蓋范圍有限，在手機移動速度如此之快的情況下，基站的切換也將頻繁到讓網絡工程師們崩潰（有興趣可以讀一下《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》）。
TCP/IP和網絡的關系，可以作個有趣的類比。
假設互聯網是公路，那么TCP/IP這就是這條公路上的一套交通規則。這套規則在制定時，可能考慮到的只是普通的市場內道路（最多是高速公路使用），而現在的5G時代，就好比時速350公里的高速鐵路，試想普通的市內交通規則套用在高速鐵路上，那難道不算是災難嗎。
必竟普通的市內交通速度不會很快，各種規則的制定誤差和余量可以比較大，但高速鐵路上，速度飛快、交通信號控制精確無比的情況下，這套規則，對于開高鐵的司機來說，肯定是膽顫心驚。而TCP/IP對于5G來說，就好比這套老的交通規則，用它來駕馭這么快速的5G快車，是不是很瘋狂？

7.2 TCP/IP與電信網的基因不同
基于TCP/IP的互聯網原本是為固定網絡和網絡互聯設計，而運營商的移動網絡是為移動性連接而生。互聯網的連接是分布式的，而移動通信網絡是集中控制的。
這兩者的技術基因確實有很大不同，在早期移動網絡網絡性能較慢的情況下，這兩者的結合，矛盾似乎并不突出。
實際上，在傳統電信網（就是大家最常用的電話、短信網絡）與IT互聯網是兩撥人各自有玩耍（電信網為代表的就是3GPP標準化組織，互聯網為代表的就是IETF標準化組織）。
在那個移動網還不發達的年代，這兩撥人各自玩各自的，大家誰也不用鳥誰。
隨著人們對移動上網需求越來越旺盛，搞電信網的這撥人只能想辦法接入傳統的互聯網，必竟在當時傳統互聯網太強勢，而移動網的應用場景還在摸索階段，為了能快速解決移動上網的問題，與是也不好麻煩IETF這撥人，所有痛苦默默承受——雖然TCP/IP在移動網上的實施并不合適，但只能想辦法縫縫補補，把移動網的標準制定，往它上面靠。
這就好比，TCP/IP這輛車已經造好了，至于你搞移動網的人，是修一條普通馬路（2G）、還是一條高速公司路（3G）、或者是現在的高速鐵路（5G），反正你只能將就這輛車。原本應該是什么路上跑什么車，而現在是不管你什么路，只能跑這輛車。反正車子跑不好，不怪車子，怪路。。。
好奇葩的邏輯，而這個邏輯就好比是現在的TCP/IP跟移動網的關系。
所以，在5G，甚至未來的6G、7G時代，這種“勉強”的結合，拋必帶來網絡低效、基礎設施成本高昂等問題。
8、移動運營商們已經意識到問題
是的，大佬們已經意識到了問題的嚴重性，正在著手解決。
2020年4月初，歐洲電信標準協會（ETSI）已成立了一個新的行業規范工作組“Non-IP Networking”（ISG NIN），以解決新服務、尤其是5G服務面臨的老式網絡協議所存在的問題。
▲ 詳細新聞內容《點此查看》
該工作組的目標是為5G網絡研究開發新的網絡協議，以替代TCP/IP。
是的，這些移動運營商已經發現在4G、甚至5G網絡中使用的基于TCP/IP的技術存在一些問題。
由于TCP/IP協議最初是為互聯網設計，而非為移動通信網絡而生，當移動通信網絡引入TCP/IP后，增加了移動性、安全性、QoS等功能，這使得網絡更復雜，頻譜使用效率較低。為了解決這些問題，后續的修補和替代方案又導致了成本、時延和功耗增加。
大佬們終于承認，對于5G的某些高級服務，TCP/IP確實被認為不是最佳的。
9、移動網絡未來會怎樣？
雖然TCP/IP可能越來越難以適應移動網絡的發展，但不可否認，短期內TCP/IP的不可替代性。
必竟，基于TCP/IP的傳統互聯網所構建的軟件和硬件世界（尤其是硬件）并不是一朝一夕的事，而替換掉這些，無論是從成本還是各方利益來說，都是個需要反復權衡和博弈的事。
一個很好的例子是，IPv4和IPv6，雖然誰都知道IPv4的困境，但IPv6喊了這么多年目前想要普及，仍然還比較遙遠，要知道IPv6已經喊了10年了。因為這小小的IP地址，牽涉的是互聯網從硬到軟幾乎所有環節，影響之大，無出其右。
對于IM開發者來說，因為移動網絡的特殊性，而技術改朝換代也并不鮮見。
比如眾所周之的XMPP協議，設計之初也是野心勃勃——“要讓上IM就像打開網頁一樣簡單！”。確實，XMPP無論是肉眼可讀性，還是數據結構的優雅，都非常優秀，但悲劇的是，設計者們從來沒有想過移動網會發展成今天這樣，或者說設計者們從未考慮過XMPP在移動網下的使用。于是，后面的故事，大家都很清楚——每個人都在抱怨XMPP臃腫、冗余（是的，這里我收集了一大堆這樣的文章），這算個是把優點做成缺點的典型案例了。
或許，未來會有那么一天，移動網絡終有屬于為自已定制的網絡協議標準。而對于搞網絡通信的程序員來說，如果這套新的標準讓能基于移動網絡的代碼編寫，變的愉快起來，那真是謝天謝地了！
10、參考資料
[1] TCP/IP 已完？New IP 之后，又來一個 Non-IP
[2] 5G：再見，TCP/IP
[3] 重新設計TCP/IP協議棧以支持設備移動性
[4] 5G要拋棄TCP/IP？
[5] ETSI LAUNCHES NEW GROUP ON NON-IP NETWORKING ADDRESSING 5G NEW SERVICES
附錄：更多網絡編程基礎資料
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》
《P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)》
《P2P技術詳解(四)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《腦殘式網絡編程入門(七)：面視必備，史上最通俗計算機網絡分層詳解》
《腦殘式網絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》
《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》
《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《技術大牛陳碩的分享：由淺入深，網絡編程學習經驗干貨總結》
《可能會搞砸你的面試：你知道一個TCP連接上能發起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級并發的高性能長連接網關技術實踐》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
>> 更多同類文章 ……
歡迎關注我的“即時通訊技術圈”公眾號：
（本文已同步發布于：http://www.52im.net/thread-2976-1-1.html）

posted @ 2020-04-13 23:41 Jack Jiang 閱讀(498) | 評論 (0) | 編輯收藏

微信后臺基于時間序的新一代海量數據存儲架構的設計實踐

     摘要: 本文作者騰訊WXG后臺開發工程師jeryyzhang，收錄時有改動，感謝原作者的分享。1、引言大約3年前，微信技術團隊分享了《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》一文，文中總結了微信這種超級IM基于時間序的海量數據存儲架構的設計實踐，也得以讓大家了解了微信后臺的架構設計思路。時隔3年，微信再次分享了基于時間序的新一代海量數據存儲架構的設計實踐（可以認為是《微信后臺基于時間序的海量數據...  閱讀全文

posted @ 2020-04-09 15:07 Jack Jiang 閱讀(324) | 評論 (0) | 編輯收藏

社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐

     摘要: 一、引言2020年春節早已過去兩月有余，回顧本次騰訊手Q春節紅包活動的玩法，主要以答題形式結合中國傳統文化（成語、詩詞、對聯、歷史等）的方式進行，達到寓教于樂的效果。 ▲ 2020年春節QQ的紅包活動對于這種大體量的IM社交應用運營活動，技術上除了前端、后臺的大力支撐，對于手Q客戶端來說，又是從哪些方面來保證整個紅包活動的靈活性、穩定性和用戶體驗的呢？帶著這個問題，我們一起來...  閱讀全文

posted @ 2020-04-06 23:41 Jack Jiang 閱讀(303) | 評論 (0) | 編輯收藏

微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考

     摘要: 本文原文由微信客戶端高級工程師方秋枋原創發表于WeMobileDev公眾號，收錄時有修訂和加工，感謝作者的無私分享。1、引言作為一個重要業務，微信支付在客戶端上面臨著各種問題。其中最核心問題就是分平臺實現導致的問題：1）iOS 和安卓實現不一致：容易出 Bug、通過溝通保證不了質量；2）擴展性差且無法快速響應業務需求：需求變更迭代周期長、數據上報不全面；3）質量保障體系不完善：缺少業務及設計知識沉...  閱讀全文

posted @ 2020-03-25 17:00 Jack Jiang 閱讀(424) | 評論 (0) | 編輯收藏

IM消息ID技術專題(五)：開源分布式ID生成器UidGenerator的技術實現

     摘要: 1、引言很多人一想到IM應用開發，第一印象就是“長連接”、“socket”、“?；?#8221;、“協議”這些關鍵詞，沒錯，這些確實是IM開發中肯定會涉及的技術范疇。但，當你真正開始編寫第一行代碼時，最現實的問題實際上是“聊天消息ID該怎么生成？”這個看似微不足道的小事情。說它看似微不足道，...  閱讀全文

posted @ 2020-03-19 17:34 Jack Jiang 閱讀(374) | 評論 (0) | 編輯收藏

IM要做手機掃碼登錄？先看看微信的掃碼登錄功能技術原理

本文原文由作者Amazing10原創發布于公眾號業余碼農，收錄時有改動，感謝原作者的技術分享。
1、引言
某天中午，吃完午飯，攤在自己的躺椅上，想趁吃飽喝足的午后時間靜靜享受獨自的靜謐。

干點什么好呢？于是單手操作鼠標打開了一個陌生而隱秘的網站。正開著某個視頻起勁。。。
突然瀏覽器彈出了一個提示：
請使用微信掃碼登錄賬號，繼續觀看
這...

但是由于強烈的好奇驅使，迫于無奈，只好選擇登錄再繼續觀看。于是熟練的掏出手機，打開微信掃一掃對準上面的二維碼，只聽見 “叮” 的一聲，網頁上的二維碼放佛活過來了，直接刷新出了本尊的微信頭像，同時手機上也彈出登錄的提醒。

心中略微驚嘆，但沒來得及多想。忙點擊手機界面中登錄按鈕。此時網頁刷新，恢復了正常，表示可以繼續觀看。
上網沖浪的時間總是過得很快，很快就有些疲倦。于是閉上眼睛，腦海中卻浮現出了剛剛微信掃描二維碼，然后登錄網頁的場景，心中再次驚嘆，并開始思考起其中的原理來。。。
言歸正傳，本文將以輕松活潑的語言形式，為你分析和講解微信手機掃碼登錄的技術原理，希望在你的IM中開發此功能時有所啟發。
推薦閱讀：另一篇同類文章《IM的掃碼登錄功能如何實現？一文搞懂主流的掃碼登錄技術原理》也值得一讀。
學習交流：
- 即時通訊/推送技術開發交流5群：215477170[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-2941-1-1.html）
2、IM開發干貨系列文章
本文是系列文章中的第23篇，總目錄如下：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》
《移動端IM登錄時拉取數據如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《淺談移動端IM的多點登錄和消息漫游原理》
《IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登錄接口的原理》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《IM群聊消息的已讀回執功能該怎么實現？》
《IM群聊消息究竟是存1份(即擴散讀)還是存多份(即擴散寫)？》
《IM開發基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《一個低成本確保IM消息時序的方法探討》
《IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！》
《IM里“附近的人”功能實現原理是什么？如何高效率地實現它？》
《IM開發基礎知識補課(七)：主流移動端賬號登錄方式的原理及設計思路》
《IM開發基礎知識補課(八)：史上最通俗，徹底搞懂字符亂碼問題的本質》
《IM的掃碼登功能如何實現？一文搞懂主流應用的掃碼登錄技術原理》
《IM要做手機掃碼登陸？先看看微信的掃碼登錄功能技術原理》（本文）
3、原理解析
微信掃碼登錄現在在日常生活中已經是常見不能再常見的場景之一了，但是要知道微信首次公開這項功能時，卻是驚艷眾人。移動端與PC端以這樣一種巧妙的方式鏈接在了一起，的確是讓人驚嘆。
以下是一個典型的微信掃碼登錄全過程：
本來想在Web版微信上截圖，但掃碼登陸后出現了下面的提示（貌似很多人都碰到過）：
好吧，這很微信，反正就是不想讓你好好用，用戶愛咋咋滴。。。
如上圖所示，操作過程如下：
1）第一步：電腦上打開PC端（出現2維碼）；
2）第二步：拿出手機，掃碼2維碼；
3）第三步：PC端顯示掃碼成功；
4）第四步：手機端“確認”登錄；
5）第五步：成功登陸PC端。
上述實際操作過程，用戶體驗相當順滑，也難怪剛出來那會，能驚艷到很多人。
那么，對于上述操作過程的技術實現原理是什么樣的呢？
想起來之前聽過的前后端的概念，知道賬戶的數據信息一般都是放在服務器上，前端負責向后端 “討要數據” 并顯示，后端則是對前端的 “討要” 做出反應。
這樣一來，猜測微信登錄的過程可能就是：
1）網頁前端向微信后臺請求賬號數據；
2）微信后臺接受網頁前端的請求，然后將他的賬號數據返回；
3）網頁前端接收到了數據后，在瀏覽器里進行顯示。
于是，手腳麻利的畫了個示意圖：
當我正準備沾沾自喜的時候，突然看到桌面上的手機。咦，如果就只是這么個過程，那手機的作用是啥。于是才開始意識到，問題沒這么簡單。
好吧，我們城要再深入一點探秘微信掃碼登錄的過程。
4、過程分析
為了更深入的分析整個過程，我們可以去看看微信網頁版，地址是：https://wx.qq.com/。

筆者看著網頁中碩大的二維碼陷入了沉思——這個二維碼跟手機賬號有沒有什么對應關系呢？如果沒有，那它又是怎么生成的呢？
思考間，于是打開了瀏覽器的開發者工具。
在網絡監控一覽找到了這幅二維碼，與之對應的鏈接是：
https://login.weixin.qq.com/qrcode/gaO8cOQweA==
如下圖所示：
然后習慣性地，嘗試多次刷新頁面，發現二維碼不斷發生變化，鏈接也不斷更改：
https://login.weixin.qq.com/qrcode/AencxgKNFQ==
https://login.weixin.qq.com/qrcode/YcD7f_DxvA==
https://login.weixin.qq.com/qrcode/QblN8lCn2g==
似乎發現了些東西：二維碼不斷變化，其對應的鏈接尾的代碼也相應變化，并且是隨機性的變化。
這也就是說，每一次頁面刷新都會隨機且唯一地生成一個二維碼。這或許可以與手機登錄的過程聯系起來。
似乎開始明白了，于是再次拿起手機，熟練的使用微信掃描了此時的二維碼。
“叮” 的一聲，網頁上的二維碼頓時變成了我帥氣的微信頭像。這個時候，我才突然意識到，是掃碼之后網頁才與他的微信賬號建立起了聯系。
如下圖所示：
也就是說：
1）沒有掃碼之前，頁面上的二維碼只是隨機生成的且與用戶無關的碼；
2）而當用戶掃碼之后，二維碼便與用戶帳號綁定在了一起。
原來手機掃碼的用處是這樣！
此時注意到，手機微信上彈出了『微信登錄確認』的提醒。這個時候謹慎地點擊了下方的登錄按鈕。
如下圖所示：
隨著平滑的動畫一閃而過，網頁上已經顯示出了我的微信賬號信息，顯示微信賬號已經登錄。再一次體驗這個過程，心中開始思索手機微信在登錄過程中所起到的具體作用。
首先需要明白幾個過程：
1）進入網頁登陸界面，隨機生成一個二維碼；
2）通過手機掃描二維碼，將微信賬號與二維碼綁定；
3）在手機微信點擊登錄按鈕，授權網頁登錄微信賬號；
4）網頁獲得的賬號信息，將數據顯示。
5、原理解釋
回顧上述過程，結合最開始的原理猜測，開始思索整個環節，是哪里理解的不對。。。
1）網頁的二維碼到底從何而來？
2）是誰向微信后臺請求了賬號數據？
實際上：不同的網站可能都需要通過微信后臺進行數據的獲取，那么每一個網站必然也存在它的后臺來給微信后臺發送請求。
這樣一來，整個過程就能解釋得通了：
1）網站頁面刷新，網頁后臺向微信后臺請求授權登錄；
2）微信后臺返回登錄所需二維碼；
3）用戶通過手機掃描二維碼，并在手機上授權登錄后，微信后臺告知網頁后臺已授權；
4）網頁后臺向微信后臺請求微信賬號數據；
5）微信后臺返回賬號數據；
6）網頁后臺接收數據并通過瀏覽器顯示；
6、技術剖析
正如上節所述，想清楚了整個過程后，我們應該對整個過程的技術實現進行進一步的探究。
在微信開發官方文檔中，我找到了第三方網站應用微信登錄開發指南：
https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html
我將整個過程梳理了一遍，畫出了這個圖：
如上圖所示，整個技術實現如下。
（1）二維碼的獲得：
1）用戶打開網站后，網站后臺根據微信OAuth2.0協議向微信開發平臺請求授權登錄，并傳遞事先在微信開發平臺中審核通過的AppID和AppSecrect等參數；
2）微信開發平臺對AppID等參數進行驗證，并向網站后臺返回二維碼；
3）網站后臺將二維碼傳送至網站前端進行顯示。
（2）微信客戶端授權登錄：
1）用戶使用微信客戶端掃描二維碼并授權登錄；
2）微信客戶端將二維碼特定的uid與微信賬號綁定，傳送至微信開發平臺；
3）微信開發平臺驗證綁定數據，調用網站后臺的回調接口，發送授權臨時票據code；
（3）網站后臺請求數據：
1）網站后臺接收到code，表明微信開發平臺同意數據請求；
2）網站后臺根據code參數，再加上AppID和AppSecret請求微信開發平臺換取access_token；
3）微信開發平臺驗證參數，并返回access_token；
4）網站后臺收到access_token后即可進行參數分析獲得用戶賬號數據。
在上述過程中，有幾個參數值得解釋一下（來源官方文檔）：
1）AppID：應用唯一標識，在微信開放平臺提交應用審核通過后獲得；
2）AppSecret：應用密鑰，在微信開放平臺提交應用審核通過后獲得；
3）code：授權臨時票據，第三方通過code進行獲取access_token的時候需要用到，code的超時時間為10分鐘，一個code只能成功換取一次access_token即失效。code的臨時性和一次性保障了微信授權登錄的安全性。
整個過程從網站后臺向微信開發平臺請求授權登錄開始，最終目的是為了獲得access_token：
access_token：用戶授權第三方應用發起接口調用的憑證
在獲得了access_token后就可以解析用戶的一些基本信息，包括頭像、用戶名、性別、城市等。這樣一來，整個微信掃描登錄的過程就完成了。
7、寫在最后
研究到這，終于大體上對微信掃碼登錄的整個過程有了清晰的認知?？雌饋硭坪跻膊浑y，開發者只需要在網頁后端做好對微信公眾平臺的接口調用即可實現掃碼登錄。
伸了伸懶腰，忽然又想到在整個過程中還需要考慮超時的問題。比如二維碼超時未掃描、二維碼掃描后超時授權、獲得access_token后超時等等問題。
我發現一個簡單的功能實現起來還是需要考慮許多細節，真的是紙上得來終覺淺呀。于是我下定決心，下次得少上網沖浪了，花點時間搭個服務器先把微信掃碼登錄過程實現看看。
不過，還得先去在微信開放平臺注冊開發者帳號，并擁有一個已審核通過的網站應用，并獲得相應的AppID和AppSecret才行。
想了想，還是讓我先趟一會兒吧。。。

附錄：更多IM開發相關文章
[1] IM開發熱門文章：
《新手入門一篇就夠：從零開發移動端IM》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《小白必讀：閑話HTTP短連接中的Session和Token》
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現方式嗎？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《微信對網絡影響的技術試驗及分析（論文全文）》
《即時通訊系統的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)》
《字符編碼那點事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移動端主流圖片格式的特點、性能、調優等》
《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《自已開發IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《融云技術分享：解密融云IM產品的聊天消息ID生成策略》
《適合新手：從零開發一個IM服務端（基于Netty，有完整源碼）》
《拿起鍵盤就是干：跟我一起徒手開發一套分布式IM系統》
>> 更多同類文章 ……
[2] 有關WEB端即時通訊開發：
《新手入門貼：史上最全Web端即時通訊技術原理詳解》
《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》
《SSE技術詳解：一種全新的HTML5服務器推送事件技術》
《Comet技術詳解：基于HTTP長連接的Web端實時通信技術》
《新手快速入門：WebSocket簡明教程》
《WebSocket詳解（一）：初步認識WebSocket技術》
《WebSocket詳解（二）：技術原理、代碼演示和應用案例》
《WebSocket詳解（三）：深入WebSocket通信協議細節》
《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關系(上篇)》
《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關系(下篇)》
《WebSocket詳解（六）：刨根問底WebSocket與Socket的關系》
《socket.io實現消息推送的一點實踐及思路》
《LinkedIn的Web端即時通訊實踐：實現單機幾十萬條長連接》
《Web端即時通訊技術的發展與WebSocket、Socket.io的技術實踐》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《開源框架Pomelo實踐：搭建Web端高性能分布式IM聊天服務器》
《使用WebSocket和SSE技術實現Web端消息推送》
《詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket》
《MobileIMSDK-Web的網絡層框架為何使用的是Socket.io而不是Netty？》
《理論聯系實際：從零理解WebSocket的通信原理、協議格式、安全性》
《微信小程序中如何使用WebSocket實現長連接(含完整源碼)》
《八問WebSocket協議：為你快速解答WebSocket熱門疑問》
《快速了解Electron：新一代基于Web的跨平臺桌面技術》
《一文讀懂前端技術演進：盤點Web前端20年的技術變遷史》
《Web端即時通訊基礎知識補課：一文搞懂跨域的所有問題！》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-2941-1-1.html）

posted @ 2020-03-13 17:15 Jack Jiang 閱讀(366) | 評論 (0) | 編輯收藏

僅列出標題
共50頁: First 上一頁 29 30 31 32 33 34 35 36 37 下一頁 Last