美国棒球比分有平局吗:Jack Jiang

我的最新工程MobileIMSDK://git.oschina.net/jackjiang/MobileIMSDK
posts - 184, comments - 13, trackbacks - 0, articles - 0

置頂隨筆

     摘要: 本文的上篇我們討論了在線實時消息的投遞,如果接收方用戶B不在線,系統是如何保證離線消息的可達性的呢?這就是本文要討論的問題。  閱讀全文

posted @ 2016-11-18 14:39 Jack Jiang 閱讀(2805) | 評論 (0)編輯 收藏

     摘要: 雖然C10K問題已被妥善解決,但對于即時通訊應用(或其它網絡編程方面)的開發者而言,研究C10K問題仍然價值巨大,因為技術的發展都是有規律和線索可循的,了解C10K問題及其解決思路,通過舉一反三,或許可以為你以后面對類似問題提供更多可借鑒的思想和解決問題的實踐思路。而這,也正是撰寫本文的目的所在。  閱讀全文

posted @ 2016-10-21 16:02 Jack Jiang 閱讀(2428) | 評論 (0)編輯 收藏

     摘要: 本文將以新手的視角引導你閱讀相關文章,以便為從零開發一個移動端IM做好方方面面的知識準備:包括但不限于網絡編程基礎、通信協議的選型、IM的架構設計等等。  閱讀全文

posted @ 2016-08-29 17:42 Jack Jiang 閱讀(2969) | 評論 (0)編輯 收藏

     摘要: 本文將簡要介紹TeamTalk開源的過去和現在,為打算研究和采用TeamTalk的同行提供一定程度的參考。  閱讀全文

posted @ 2016-08-09 17:25 Jack Jiang 閱讀(2527) | 評論 (0)編輯 收藏

     摘要: 本文基于作者的實踐以及相關資料的整理,總結了自已對Android進程和Service?;畹睦斫?,希望能為你的應用開發帶來啟發。  閱讀全文

posted @ 2016-08-02 22:43 Jack Jiang 閱讀(2280) | 評論 (0)編輯 收藏

     摘要: 本文將介紹如何在現有的技術基礎上選擇合適的方案開發一個“服務器推”(Comet技術)的應用,最優的方案還是取決于應用需求的本身。相對于傳統的 Web 應用, 開發 Comet 應用具有一定的挑戰性。  閱讀全文

posted @ 2016-07-28 11:07 Jack Jiang 閱讀(1344) | 評論 (0)編輯 收藏

     摘要: 本文對服務器推送技術(SSE)進行了詳細的介紹,包含瀏覽器端和服務器端的相應實現細節,為在實踐中使用該技術提供了指南  閱讀全文

posted @ 2016-07-22 18:03 Jack Jiang 閱讀(998) | 評論 (0)編輯 收藏

     摘要: Web端即時通訊技術因受限于瀏覽器的設計限制,一直以來實現起來并不容易,主流的Web端即時通訊方案大致有4種:傳統Ajax短輪詢、Comet技術、WebSocket技術、SSE(Server-sent Events)。本文將簡要介紹這4種技術的原理,并指出各自的異同點、優缺點等。  閱讀全文

posted @ 2016-07-15 15:08 Jack Jiang 閱讀(1568) | 評論 (2)編輯 收藏

     摘要: Web端的IM應用,由于瀏覽器的兼容性以及其固有的“客戶端請求服務器處理并響應”的通信模型,造成了要在瀏覽器中實現一個兼容性較好的IM應用,其通信過程必然是諸多技術的組合,本文的目的就是要詳細探討這些技術并分析其原理和過程。   閱讀全文

posted @ 2016-07-12 15:59 Jack Jiang 閱讀(5253) | 評論 (0)編輯 收藏

     摘要: 文演示的是一個Android客戶端程序,通過UDP協議與兩個典型的NIO框架服務端(分別用MINA2和Netty4來實現),實現跨平臺雙向通信的完整Demo。  閱讀全文

posted @ 2016-06-30 16:57 Jack Jiang 閱讀(585) | 評論 (0)編輯 收藏

     摘要: 本文將演示一個iOS客戶端程序,通過UDP協議與兩個典型的NIO框架服務端(將分別用MINA2和Netty4來實現),實現跨平臺雙向通信的完整Demo。  閱讀全文

posted @ 2016-06-28 22:11 Jack Jiang 閱讀(1181) | 評論 (0)編輯 收藏

     摘要: 本文是《NIO框架入門》系列文章中的第2篇,將演示的是一個基于MINA2的UDP服務端和一個標準UDP客戶端(Java實現)雙向通信的完整例子。  閱讀全文

posted @ 2016-06-24 14:38 Jack Jiang 閱讀(571) | 評論 (0)編輯 收藏

     摘要: 本文將演示的是一個基于Netty4的UDP服務端和一個標準UDP客戶端(Java實現)雙向通信的完整例子。實際上,Netty4的UDP例子非常難找,官方的代碼演示里只有一個簡單的UDP廣播例子,不足以用于演示Netty4的UDP通信最佳實踐。  閱讀全文

posted @ 2016-06-20 14:48 Jack Jiang 閱讀(1157) | 評論 (0)編輯 收藏

     摘要: MobileIMSDK是一套專為移動端開發的原創即時通訊框架:超輕量級、高度提煉,lib包50KB以內;完全基于UDP協議實現;客戶端支持iOS、Android、標準Java平臺;可應用于跨設備、跨網絡的聊天APP、企業OA、消息推送等各種場景。  閱讀全文

posted @ 2015-12-14 15:18 Jack Jiang 閱讀(2607) | 評論 (0)編輯 收藏

     摘要: MobileIMSDK是專為移動端開發的原創即時通訊開源框架:超輕量級、高度提煉,lib包50KB以內;完全基于UDP協議實現;客戶端支持iOS、Android、標準Java平臺;可應用于跨設備、跨網絡的聊天APP、企業OA、消息推送等各種場景。  閱讀全文

posted @ 2015-12-01 16:06 Jack Jiang 閱讀(3105) | 評論 (2)編輯 收藏

2020年6月3日

本文中文譯文由作者“ably.io”發布于公眾號“高可用架構”,譯文原題:《深入解讀HTTP3的原理及應用》、英文原題:《HTTP/3 deep dive》(文末有譯文和原文鏈接),即時通訊網收錄時有少許改動,感謝原作者和譯者的分享。

1、引言

HTTP3是HTTP協議的最新版本。從誕生之初,HTTP就是交換超文本文檔的首選應用層協議。多年來,為了跟上互聯網的發展,以及WWW上交換的內容種類增加,HTTP進行了幾次重大升級,而HTTP/3就是目前的最新版本。

本文將從HTTP/3的基本概念、技術原理、應用場景和如何使用它等方面進行介紹,確保在有限的篇幅內,能讓你通俗地理解它。


 

本文是系列文章中的第12篇,本系列文章的大綱如下:

網絡編程懶人入門(一):快速理解網絡通信協議(上篇)

網絡編程懶人入門(二):快速理解網絡通信協議(下篇)

網絡編程懶人入門(三):快速理解TCP協議一篇就夠

網絡編程懶人入門(四):快速理解TCP和UDP的差異

網絡編程懶人入門(五):快速理解為什么說UDP有時比TCP更有優勢

網絡編程懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門

網絡編程懶人入門(七):深入淺出,全面理解HTTP協議

網絡編程懶人入門(八):手把手教你寫基于TCP的Socket長連接

網絡編程懶人入門(九):通俗講解,有了IP地址,為何還要用MAC地址?

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

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

網絡編程懶人入門(十二):快速讀懂Http/3協議,一篇就夠!》(本文)

學習交流:

- 即時通訊/推送技術開發交流5群:215477170 [推薦]

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

歡迎關注“即時通訊技術圈”,更多好文會同步發布在公眾號:

(本文同步發布于://www.52im.net/thread-3020-1-1.html

2、相關文章

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

網絡編程懶人入門(七):深入淺出,全面理解HTTP協議

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議》(推薦)

技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》(推薦)

3、HTTP協議的演進史

在萬維網誕生之時,萬維網僅僅是一群交換超文本文件的計算機。在計算機之間交換文件是一個簡單的程序,包括請求和響應。在此基礎上設計了一個簡單的基于文本的協議。HTTP(超文本傳輸協議)應運而生。后來,它被起草成了一個標準化的IETF協議,定義在RFC 1945中,也被稱為HTTP/1.0。

多年來,HTTP從HTTP/1.0發展到HTTP/1.1,再到HTTP/2。在每一次迭代中,協議都增加了新的功能,以處理大量的需求,如應用層需求、安全考慮、會話處理和媒體類型等。要深入了解HTTP/2及其演進史,可詳讀《從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路》。

盡管經歷了幾次修訂,但HTTP的底層傳輸機制基本沒有變化。但是,隨著互聯網流量的激增,在移動電話的推動下,HTTP的傳輸機制在保證網頁瀏覽體驗的流暢性方面變得問題重重。

HTTP/3是為了處理HTTP/2.0的傳輸相關問題而生的,可以在各種設備上更快地訪問Web。它基于一個新的傳輸層協議,稱為QUIC(Quick UDP Internet Protocol),在UDP之上工作。這一選擇與之前版本的HTTP截然不同,之前版本都是基于TCP。TCP是一個比UDP更可靠的協議,那么為什么要在UDP之上重新設計HTTP的傳輸層呢?


 

讓我們來看看在TCP上運行HTTP的局限性,并深入了解一下基于QUIC協議的HTTP/3的設計思想。

4、什么是HTTP/3

當IETF正式標準化HTTP/2時,Google正在獨立構建一個新的傳輸協議,名為gQUIC。它后來成為新互聯網草案,并被命名為QUIC。gQUIC最初的實驗證明,在網絡條件較差的情況下,gQUIC在增強網頁瀏覽體驗方面的效果非常好。因此,gQUIC的發展勢頭越來越好,IETF的大多數成員贊成建立一個在QUIC上運行的HTTP新規范。這個新的倡議被稱為HTTP/3,以區別于當前的HTTP/2標準。


 

從語法和語義上看,HTTP/3與HTTP/2相似。HTTP/3遵循相同的請求和響應消息交換順序,其數據格式包含方法、標題、狀態碼和body。然而,HTTP/3的顯著的偏差在于協議層在UDP之上的堆疊順序。


 

有關QUIC的更多資料,可以看看《網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議》、《技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》。

5、HTTP/3 是如何工作的?

HTTP/3功能的核心是圍繞著底層的QUIC協議來實現的。在討論QUIC和UDP之前,我們有必要先列出TCP的某些限制,這也是導致QUIC發展的原因。

5.1 TCP可能會間歇性地掛起數據傳輸

如果一個序列號較低的數據段還沒有接收到,即使其他序列號較高的段已經接收到,TCP的接收機滑動窗口也不會繼續處理。這將導致TCP流瞬間掛起,在更糟糕的情況下,即使所有的段中有一個沒有收到,也會導致關閉連接。這個問題被稱為TCP流的行頭阻塞(HoL)。


 

5.2 TCP不支持流級復用

雖然TCP確實允許在應用層之間建立多個邏輯連接,但它不允許在一個TCP流中復用數據包。使用HTTP/2時,瀏覽器只能與服務器打開一個TCP連接,并使用同一個連接來請求多個對象,如CSS、JavaScript等文件。在接收這些對象的同時,TCP會將所有對象序列化在同一個流中。因此,它不知道TCP段的對象級分區。

5.3 TCP會產生冗余通信

TCP連接握手會有冗余的消息交換序列,即使是與已知主機建立的連接也是如此。


 

QUIC協議在以下設計選擇的基礎上,通過引入一些底層傳輸機制的改變,解決了這些問題。

1)選擇UDP作為底層傳輸層協議:在TCP之上建立新的傳輸機制,將繼承TCP的上述所有缺點。因此,UDP是一個明智的選擇。此外,QUIC是在用戶層構建的,所以不需要每次協議升級時進行內核修改。

2)流復用和流控:QUIC引入了連接上的多路流復用的概念。QUIC通過設計實現了單獨的、針對每個流的流控,解決了整個連接的行頭阻塞問題。


 

3)靈活的擁塞控制機制:TCP的擁塞控制機制是剛性的。該協議每次檢測到擁塞時,都會將擁塞窗口大小減少一半。相比之下,QUIC的擁塞控制設計得更加靈活,可以更有效地利用可用的網絡帶寬,從而獲得更好的吞吐量。

4)更好的錯誤處理能力:QUIC使用增強的丟失恢復機制和轉發糾錯功能,以更好地處理錯誤數據包。該功能對于那些只能通過緩慢的無線網絡訪問互聯網的用戶來說是一個福音,因為這些網絡用戶在傳輸過程中經常出現高錯誤率。

5)更快的握手:QUIC使用相同的TLS??榻邪踩?。然而,與TCP不同的是,QUIC的握手機制經過優化,避免了每次兩個已知的對等者之間建立通信時的冗余協議交換。


 

通過在QUIC之上構建基于HTTP/3的應用層,您可以獲得增強型傳輸機制的所有優勢,同時保留HTTP/2的語法和語義。但是,你也必須注意到,HTTP/2不能直接與QUIC集成,因為從應用到傳輸的底層幀映射是不兼容的。因此,IETF的HTTP工作組建議將HTTP/3作為新的HTTP版本,并根據QUIC協議的幀格式要求修改了幀映射。

除此之外,HTTP/3還使用了一種新的HTTP頭壓縮機制,稱為QPACK,是對HTTP/2中使用的HPACK的增強。在QPACK下,HTTP頭可以在不同的QUIC流中不按順序到達。與HTTP/2中的TCP確保數據包的按順序傳遞不同,QUIC流是不按順序傳遞的,在不同的流中可能包含不同的HTTP頭。因此,QPACK使用查找表機制對報頭進行編碼和解碼。

6、為什么HTTP/3很重要?

TCP已經有40多年的歷史了。它在1981年通過RFC 793從而標準化。多年來,它經歷了多次更新,是一個非常強大的傳輸協議,可以支持互聯網流量的增長。然而,由于設計上的原因,TCP從來就不適合處理有損無線環境中的數據傳輸。在互聯網的早期,有線網絡將網絡中的每一臺計算機連接起來。

現在,隨著智能手機和便攜式設備的數量超過臺式機和筆記本電腦的數量,超過50%的互聯網流量已經通過無線傳輸。這種趨勢給整體的網絡瀏覽體驗帶來了問題,其中最重要的是在無線覆蓋率不足的情況下,TCP中的行頭阻塞(關于TCP在移動網絡下的不足,請閱讀《5G時代已經到來,TCP/IP老矣,尚能飯否?》)。

Google的一些初步實驗證明,QUIC作為Google部分熱門服務的底層傳輸協議,極大地提高了速度和用戶體驗。部署QUIC作為YouTube視頻的底層傳輸協議,導致YouTube視頻流的緩沖率下降了30%,這直接影響了用戶的視頻觀看體驗。在顯示谷歌搜索結果時,也有類似的改善。

網絡條件較差的情況下提升非常明顯,這促使谷歌更加積極地完善該協議,并最終向IETF提出標準化。

由于這些早期的試驗所帶來的所有改進,QUIC已經成為帶領萬維網走向未來的重要因素。在QUIC的支持下,HTTP從HTTP/2到HTTP/3的改頭換面,朝著這個方向合理地邁出了一步。


 

7、HTTP/3的最佳用例

HTTP/3將改善我們上網的體驗,特別是在仍無法使用高速無線網絡的地區。盡管HTTP/2已經解決了一部分問題,然而HTTP/3更進一步。

7.1 物聯網(IoT)

HTTP可能不是物聯網的首選協議,但在某些情況下,基于HTTP的通信非常適合特定的應用。HTTP/3可以解決從傳感器收集數據的移動電話的無線連接損耗問題。這個問題同樣適用于安裝在車輛或可移動資產上的獨立IoT設備。通過HTTP來訪問這些設備,可以更加可靠。

7.2 大數據

全球各地的企業都在覺醒,意識到從多個部門收集數據的潛力,并將其整合成更大的信息共享API,供內部和外部受眾共享。這些API也為數據的貨幣化鋪平了道路,通過托管這些數據作為流API服務可以實現數據的貨幣化。隨著時間的推移,這些服務會吐出海量的數據。通過HTTP/3托管的流API將使它們比HTTP/2更健壯、更有彈性。

7.3 Web VR

隨著瀏覽器能力的提升,內容格局正在快速變化。其中一個領域就是基于網絡的VR。雖然還處于起步階段,但有很多的用例可以讓VR在加強協作方面發揮關鍵作用。網絡在促進VR互動方面占據了核心位置。VR應用需要更多的帶寬來渲染虛擬場景中的復雜細節,因此遷移到HTTP/3會大有收獲。

8、HTTP/3的局限性

過渡到HTTP/3不僅涉及到應用層的變化,還涉及到底層傳輸層的變化。因此,與它的前身HTTP/2相比,HTTP/3的采用更具挑戰性,因為后者只需要改變應用層。傳輸層承受著網絡中的大量中間層審查。這些中間層,如防火墻、代理、NAT設備等會進行大量的深度數據包檢查,以滿足其功能需求。因此,新的傳輸機制的引入對IT基礎設施和運維團隊來說有一些影響。

然而,HTTP/3被廣泛采用的另一個問題是,它是基于QUIC的,在UDP上運行。大多數的Web流量,以及IETF定義的知名服務都是在TCP之上運行的。這也是為什么長時間運行HTTP/3的UDP會話會被防火墻的默認數據包過濾策略所影響的原因。

隨著IETF正在進行的標準化工作,這些問題最終都會得到解決。此外,考慮到Google在早期QUIC實驗所顯示的積極結果,人們對HTTP/3的支持是壓倒性的,這將最終迫使中間層廠商標準化。

針對受限的IoT設備,HTTP/3由于過于繁瑣從而無法采用。許多IoT應用部署的設備的外形尺寸非常小。因此,它們的RAM和CPU功率都是有限的。為了使設備在電池功率、低比特率和有損連接等限制條件下高效運行,必須執行此要求。HTTP/3在現有的UDP之上,以QUIC的形式在傳輸層處理,增加了HTTP/3在整個協議棧中的占用空間。這使得HTTP/3較為笨重,不適合那些IoT設備。但這種情況很少出現,而且存在專門的協議,這就避免了直接在此類設備上支持HTTP的需要。此外,還有以物聯網為核心的協議,如MQTT。

9、開始使用HTTP/3

IETF的HTTP工作組正致力于在2020年后期發布HTTP/3。因此它還沒有被NGINX和Apache等主流web服務器正式支持。不過,有幾個lib可以用來實驗這個新協議,也提供了非官方的補丁。

以下是支持HTTP/3和QUIC傳輸lib的列表。請注意,這些實現都是基于互聯網標準草案某一個版本,而這個版本很可能會被更高的版本所取代,最終的標準會在RFC中發布。

1)Quiche :

Quiche提供了通過QUIC協議發送和接收數據包的底層編程接口。它還支持HTTP/3???,通過其QUIC協議實現發送HTTP數據包。除此之外,它還為NGINX服務器提供了一個非官方的補丁,可以安裝和托管一個能夠運行HTTP/3的Web服務器。除此以外,還提供了額外的程序來支持Android和iOS移動應用上使用HTTP/3。

2)Aioquic

Aioquic是QUIC的python實現。它還內置HTTP/3的測試服務器和客戶端庫。Aioquic建立在asyncio??櫓?,asyncio??槭荘ython的標準異步I/O框架。

3)Neqo

Neqo 是 Mozilla 使用 Rust 實現 QUIC 和 HTTP/3。

如果你想嘗試QUIC,請查看這個由QUIC工作組維護的QUIC協議的開源實現鏈接:https://github.com/quicwg/base-drafts/wiki/Implementations

(本文英文原文鏈接:點此進入、中文譯文鏈接:點此進入

附錄:更多有關HTTP協議的文章

網絡編程懶人入門(七):深入淺出,全面理解HTTP協議

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

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

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

腦殘式網絡編程入門(四):快速理解HTTP/2的服務器推送(Server Push)

Comet技術詳解:基于HTTP長連接的Web端實時通信技術

WebSocket詳解(四):刨根問底HTTP與WebSocket的關系(上篇)

WebSocket詳解(五):刨根問底HTTP與WebSocket的關系(下篇)

快速理解高性能HTTP服務端的負載均衡技術原理

一分鐘理解 HTTPS 到底解決了什么問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

即時通訊安全篇(八):你知道,HTTPS用的是對稱加密還是非對稱加密?

IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token

即時通訊安全篇(七):如果這樣來理解HTTPS原理,一篇就夠了

一分鐘理解 HTTPS 到底解決了什么問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

小白必讀:閑話HTTP短連接中的Session和Token

IM開發基礎知識補課:正確理解前置HTTP SSO單點登錄接口的原理

基于APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)

全面了解移動端DNS域名劫持等雜癥:原理、根源、HttpDNS解決方案等

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

HTTPS時代已來,打算更新你的HTTP服務了嗎?

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

(本文同步發布于://www.52im.net/thread-3020-1-1.html

posted @ 2020-06-03 23:18 Jack Jiang 閱讀(71) | 評論 (0)編輯 收藏

2020年5月29日

     摘要: 1、引言網絡優化對于移動端App產品的用戶體驗至關重要,也與公司的運營和營收息息相關。這里列舉兩個公開的數據:“《頁面加載超過3秒,57%的用戶會離開》”“《Amazon頁面加載延長1秒,一年就會減少16億美金營收》”網絡性能對于用戶體驗的影響,將非常直接地反饋到業務的運營上。而且,移動網絡固有的弱網問題、DNS問題、連接性能等等都無法跟傳統的固定網...  閱讀全文

posted @ 2020-05-29 12:06 Jack Jiang 閱讀(120) | 評論 (0)編輯 收藏

     摘要: 1、引言網絡優化對于移動端App產品的用戶體驗至關重要,也與公司的運營和營收息息相關。這里列舉兩個公開的數據:“《頁面加載超過3秒,57%的用戶會離開》”“《Amazon頁面加載延長1秒,一年就會減少16億美金營收》”網絡性能對于用戶體驗的影響,將非常直接地反饋到業務的運營上。而且,移動網絡固有的弱網問題、DNS問題、連接性能等等都無法跟傳統的固定網...  閱讀全文

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

2020年5月21日

1、引言

IM應用的初學者們,在補全了各種基礎技術知識后(如果您仍不具備這些知識,建議馬上閱讀《新手入門一篇就夠:從零開發移動端IM》),在動手編碼實踐時,很多時候糾結的并不是功能該如何實現,而是這個功能該實現成什么樣(沒有經驗,我特瑪能找誰問問?)。

比如,最常見的糾結有以下這些:

  • 1)離線聊天消息該保存多久?
  • 2)好友請求應該保存多久?
  • 3)短視頻消息中的視頻時長設為多大合適?
  • 4)圖片、短視頻、語音這些多媒體消息中,未讀的文件數據保存多久?
  • 5)群管理的邏輯該怎么弄?參考微信?還是參考QQ?(關鍵是參考資料哪里有?)
  • 6)朋友圈限制最多發幾張照片合適?
  • ... ...

嗯,這些問題,老板認為并不是問題,因為可以“參考微信”??!

然而,微信又不會親口說出來它的這些規則到底是多少?難不成要一個一個去試?那太扯了!

本文將根據微信官方目前已公開的資料,將它的一些常用功能參數和邏輯規則資料進行了匯總整理,希望能助力你的IM開發?。ū疚囊遜⒉加冢?a target="_blank" style="color: #1d58d1; text-decoration-line: none;">//www.52im.net/thread-3008-1-1.html)

學習交流:

- 即時通訊/推送技術開發交流5群:215477170[推薦]

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM》

本文已同步發布于“即時通訊技術圈”公眾號,歡迎關注:

▲ 本文在公眾號上的鏈接是:https://mp.weixin.qq.com/s/F-pVE9vN21h0Vm8LwnYplg

2、資料來源

本文中整理的所有內容均來自微信官方知識庫,如果存在不全或不準確的情況,請在評論中回復,我會逐條核實并修訂。

* 特別申明:本文內容僅供研究和學習使用,請勿用作其它用途。如有不妥之處,請指出,我會及時處理。

3、閱讀對象

本文適合作為新老IM開發者的備查資料。本文不適合不懂技術的普通用戶閱讀,因為所有內容都盡量以技術人員的視解整理和表述。

移動端IM產品中,微信是標桿,也是事實的用戶體驗標準。所以,無論是被老板或產品經理懟,直接說“微信也這樣”,能省去很多口水仗(經驗?。?。這也是整理本文的初衷,以及價值所在。

4、相關資源

微信本地數據庫破解版(含iOS、Android),僅供學習研究 [附件下載]》(* 推薦研究)

仿微信的IM聊天時間顯示格式(含iOS/Android/Web實現)[圖文+源碼]

5、微信的好友關系規則匯總

5.1 好友驗證請求有效期限

有效期限為 3 天。

* 補充規則:微信的好友驗證請求只保存在手機本地,當卸載重裝后,好友請求會消失且無法找回。

5.2 通訊錄分組/好友排序

微信通訊錄分組、好友排序,是根據微信通訊錄朋友昵稱的首字母(或首個漢字拼音首字母)由A-Z排序。

* 補充規則:如果好昵稱是特殊符號、數字或Emoji表情(比如愛心、氣球等),將會歸到#類中。

 

5.3 好友驗證規則

  • 1)當開啟“加我為朋友時需要驗證”后,需你同意接受請求后,才能成為好友;
  • 2)未開啟“加我為朋友時需要驗證”時,任何人都能添加你為好友(無需你確認)。

* 補充規則:如果不想被他人添加好友時搜索到,微信中可以設置關閉“微信號/手機號/QQ號”等搜索方式。

 

5.4 微信有4種添加好友方式

1)搜索加好友:

輸入對方的微信號/QQ號/手機號搜索添加即可,但不支持搜索昵稱。

* 補充規則:如果對方將關閉了“通過QQ/手機號/微信號搜索到我”,則沒有辦法通過此種方法添加好友。

2)雷達加朋友:

當被添加者物理距離很近時,一起按住手機,就可以添加對方為朋友。

3)掃二維碼加朋友:

掃描對方的二維碼名片,就可以添加對方為朋友。

4)手機聯系人:

綁定手機聯系人的微信帳號,可以查看到手機通訊錄聯系人已開通了微信的朋友,并直接添加對方為微信好友。

5.5 好友人數上限

微信最多可以添加 5000 個好友。

5.6 通訊錄黑名單功能邏輯

將對方加入黑名單后,與對方的關系邏輯如下:

  • 1)在自己的會話列表不再顯示與其聊天記錄,解除黑名單后會重新出現在會話列表中;
  • 2)在對方的通訊錄好友列表中仍然會顯示;
  • 3)將不再接收到對方的消息;
  • 4)對方無法給你發消息,會提示“對方拒絕接收您的消息”,自己可以給對方正常發送消息;
  • 5)互相無法查看更新后的頭像、個性簽名;
  • 6)對方將無法查看你的微信個人相冊和對照片進行評論;
  • 7)互相看不到朋友圈更新,拉黑之前在朋友圈分享的照片也不在對方朋友圈展示。

5.7 當被對方刪除或“拉黑”后的聊天效果

當好友將你刪除或加入黑名單后,你給他發消息時,微信將出現以下提示。

對方將我加入黑名單后,我發消息時的微信提示:

對方把我刪除后,我發消息時的微信提示: 

6、微信的群聊規則匯總

6.1 微信群的功能定位

微信群相當于QQ中的討論組,所以沒有QQ里的群號碼這種東西。

6.2 群主規則

群的創建者默認是群主。

* 補充規則:當創建者退出該群時,群成員列表中的第一位(也就是建群以來第2個加群的人)將自動成為新群主(好奇葩的規則?。?。

另外:當原群創建者(即原群主)再次加群時,身份將會是普通群員。

6.3 群員邀請規則

群成員可以拉其他人加入群,群主不能取消普通群員的這個能力。

* 補充規則:群主可以設置邀請需確認,即需群主確認后才可以讓被邀請的好友加到群內。

6.4 群名稱規則

每個人(不只是群主)都可以修改群名稱。

* 補充規則:當群超過 100 人時,只有群主可以修改群名稱。

6.5 群公告規則

只有群主可編輯群公告。

* 補充規則:群公告字數限制為最大 2000 個字(即4000字節)。

6.6 群保存規則

微信群需要手動添加到通訊錄才會永久保存,否則它只會保存在本地,一旦你卸載APP后,它就會消失。除非有群內成員發送消息,你才能再次看到,除次之外,你沒有別的方法可以找回它。

6.7 群人數限制

微信群最大上限為 500 人。而且,100 人以上的微信群只有已通過實名驗證的微信用戶才能加入。

6.8 加群驗證規則

  • 1)當群人數小于40人時,好友可以自由加入或被邀請加入;
  • 2)當群人數超過40人時,加群邀請需要對方同意;
  • 3)當群人數超過100人時,對方需要通過實名驗證才能接受邀請(微信中可以通過綁定銀行卡進行實名驗證)。

6.9 解散或退出群規則

微信沒有像QQ那樣的“一鍵解散群”功能。

可以通過中列方法實現解散群或退出群的能力:

1)如果是群主(創建者或群成員列表第一位),可以將群成員全部刪除;

2)如果是普通群員,可以退出群聊。

6.10 群二維碼的有效期限

微信群的二維碼有效期為 7 天(從二維碼生成時開始計算),失效后的2維碼掃描時將提示“該二維碼已過期”。

6.11 微信群消息屏蔽規則

微信沒有屏蔽群聊消息的功能,如果要達到這樣的效果,你只能設置不提醒新消息或退出此群。

7、微信的朋友圈規則匯總

7.1 照片數和文字數限制

  • 1)朋友圈照片單次最多可添加 9 張照片,上傳照片沒有文件數量限制,也沒有存儲容量限制。
  • 2)最多可輸入 1500 個漢字(即 3000 個字節)。

7.2 朋友圈新動態提醒規則

如果關閉了朋友圈更新提醒,當好友有發布新的朋友圈動態時,“發現”按鈕上將不會再出現紅點提示,否則將提示。

 

7.3 朋友圈查看權限規則

當你未作任何權限設置的情況下:

  • 1)你的所有朋友可以,查看到你在朋友圈發表的所有動態;
  • 2)陌生人可以查看你最近的10條動態。

發新朋友圈時,可以設置回避的人(即設置“誰可以/不可以看”):

  • 1)公開:所有朋友可見;
  • 2)私密:僅自己可見;
  • 3)部分可見:可在通訊錄中選擇哪些好友可見;
  • 4)不給誰看:可在通訊錄中選擇哪些好友不可見。
 

可以允許或禁止陌生人查看:

可以允許或禁止陌生人(可能來自掃碼但未添加好友、附近的人、搖一搖、群聊時)看到10張最近發的照片。

可以設置朋友圈查看時間范圍:

可選擇允許好友查看朋友圈最近三天、最近半年或者全部的內容。

可以關閉朋友圈功能:

之前通過朋友圈發表的照片,可在個人相冊里查看。但好友仍可以看到。

7.4 朋友圈的評論可見規則

  • 1)評論時,只會通知發布者;
  • 2)當評論時“@”某評論者,只會通知被回復者;
  • 3)評論者只能看到朋友的所有評論(當該條朋友圈的回復者不是朋友時,是看不到他的回復的)。

7.5 朋友圈隱私規則

1)陌生人查看十張照片:

當禁止“允許陌生人查看十張照片”時,陌生人將看不到你發布的任何朋友圈動態。微信默認是允許。

2)不看他(她)的朋友圈(即屏蔽好友的朋友圈):

在您的朋友圈中不會顯示對方發送的朋友圈消息。

3)不讓他(她)看我的朋友圈(即內容不更新給好友):

對方查看您的朋友圈顯示是空白的,不會顯示您發送過的任何朋友圈消息。

 

8、微信的聊天消息規則

8.1 聊天記錄保存規則

  • 1)微信聊天記錄保存在本地手機,一旦卸載微信,則聊天記錄永久消失;
  • 2)微信不支持聊天記錄漫游功能,一旦更新手機,新手機上無法看到之前手機上的聊天記錄。

點評:這里有份完整的微信本地數據庫樣本,可以用來研究和學習:《微信本地數據庫破解版(含iOS、Android),僅供學習研究 [附件下載]》。

8.2 離線消息保存規則

  • 1)微信服務器只保存 72 小時內的離線普通消息(從對方發消息時間開始算起),過期會被服務端清理;
  • 2)微信服務器只保存 72 小時內的多媒體數據(圖片、短視頻、大文件),即使你的手機已收到該條消息,只要未點擊查看,即被視為未讀,服務器會在此期限后清理掉多媒體數據。

8.3 “對方正在輸入”的顯示規則

給對方發送消息后,對方在 10 秒內回復才可以看到該提示。

 

8.4 聊天消息撤回時限

微信的規則是可以撤回2分鐘內發送的消息。

8.5 消息已讀回執規則

微信不支持已讀回執功能。微信認為已讀或未讀狀態屬于個人隱私,不希望打破這種自由溝通的感覺。

8.6 語音消息規則

  • 1)最長可錄制為 60 秒的語音消息;
  • 2)語音文件格式為:AMR;
  • 3)語音文件壓縮比率:60秒語音文件約為45KB。

點評:如果你的IM中,語音文件大大超過微信的這個數據量,就表達存在較大優化空間,可以從采樣率等方面進行設置。

8.7 短視頻消息規則

  • 1)最長可錄制為 10 秒的語音消息;
  • 2)語音文件格式為:MP4;
  • 3)語音文件壓縮比率:10秒短視頻約文件紅為1.5MB至2.0MB。

點評:如果你的IM中,短視頻文件大大超過微信的這個數據量,就表達存在較大優化空間,可以從采樣率等方面進行設置。

8.8 文件消息規則

微信限制最大可以上傳的文件大小為 25 MB。

8.9 聊天消息時間顯示規則

  • 1)當天的消息,以每5分鐘為一個跨度顯示時間(即格式:HH:mm);
  • 2)超過1天、小于1周的消息,將顯示“星期+收發消息的時間”;
  • 3)超過1周的消息,將顯示手機收發時間的日期(即格式:yyyy-MM-dd)。

點評:這里有一份仿微信的聊天界面時間顯示規則代碼,可以下載用一用:《仿微信的IM聊天時間顯示格式(含iOS/Android/Web實現)[圖文+源碼]》。

9、微信的其它規則

9.1 收藏功能規則

  • * 收藏的內容:可以收藏文字、語音、圖片、視頻、地理位置等。
  • * 保存的位置:收藏里面的內容是保存在服務器中的,只要你不主動刪除,會一直存在。
  • * 單個文件大小限制:可以收藏的單個文件大小不能超過 25 M。
  • * 存儲總容量限制:微信限制收藏數據的總容量為 2 GB,當總收藏容量超出2G后,超出容量的內容,將不能再上傳。

9.2 “附近的人”功能規則

  • * 技術實現:當你查看附近的人功能時,微信將通過手機GPS獲取你的位置信息,同時會被保留一段時間。
  • * 位置緩存:當你使用過“附近的人”時,服務器就會留下您的地理位置信息一段時間,周圍的人可以再次搜到您。

9.3 “搖一搖”功能規則

當距離很近的兩個同時“搖一搖”時,不一定能搖到對方。因為微信的“搖一搖”沒有距離限制,而且是由服務器隨機匹配。

10、電腦版微信的特殊規則

10.1 可以發送的消息類型

微信電腦端,可以發送文字、默認表情、符號表情、動畫表情(兔斯基表情)、截圖、圖片消息,并能同步手機上已收藏的表情并發送。

10.2 可能接收的消息類型

可以接收文字、默認表情、emoji表情、動畫表情、圖片、文件、語音、視頻、公眾號消息、名片類型消息、小視頻、地理位置消息、轉賬消息、合并轉發的聊天記錄消息。

10.3 可以接收但不能查看的的消息類型

紅包消息、AA收款消息(收到此類消息會提示請在手機上查看)。

10.4 發送文件的大小限制

微信電腦端,上傳文件大小最大為 100 MB,一次最多可以選擇10個文件同時發送。

* 補充規則:如果發送的是視頻,則文件大小不能超過 25 MB。

附錄:微信團隊分享技術資料匯總

微信朋友圈千億訪問量背后的技術挑戰和實踐總結

微信團隊分享:微信移動端的全文檢索多音字問題解決方案

微信團隊分享:iOS版微信的高性能通用key-value組件技術實踐

微信團隊分享:iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的?

微信團隊原創分享:iOS版微信的內存監控系統技術實踐

iOS后臺喚醒實戰:微信收款到賬語音提醒技術總結

騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路

微信團隊分享:視頻圖像的超分辨率技術原理和應用場景

微信團隊分享:微信每日億次實時音視頻聊天背后的技術解密

微信團隊分享:微信Android版小視頻編碼填過的那些坑》 

微信手機端的本地數據全文檢索優化之路》 

企業微信客戶端中組織架構數據的同步更新方案優化實戰

微信團隊披露:微信界面卡死超級bug“15。。。。”的來龍去脈

月活8.89億的超級IM微信是如何進行Android端兼容測試的

一篇文章get微信開源移動端數據庫組件WCDB的一切!

微信客戶端團隊負責人技術訪談:如何著手客戶端性能監控和優化

微信后臺基于時間序的海量數據冷熱分級架構設計實踐

微信團隊原創分享:Android版微信的臃腫之困與??榛導?/a>》

微信后臺團隊:微信后臺異步消息隊列的優化升級實踐分享

微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐》 

騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》 

騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)》 

騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(上篇)》 

微信Mars:微信內部正在使用的網絡層封裝庫,即將開源》 

如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》 

開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》 

微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解》 

微信團隊原創分享:Android版微信后臺?;釷嫡椒窒?進程?;釔?》 

微信團隊原創分享:Android版微信后臺?;釷嫡椒窒?網絡?;釔?》 

Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》 

微信團隊原創分享:Android版微信從300KB到30MB的技術演進》 

微信技術總監談架構:微信之道——大道至簡(演講全文)

微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]》 

如何解讀《微信技術總監談架構:微信之道——大道至簡》

微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]

微信異步化改造實踐:8億月活、單機千萬連接背后的后臺解決方案》 

微信朋友圈海量技術之道PPT [附件下載]》 

微信對網絡影響的技術試驗及分析(論文全文)》 

一份微信后臺技術架構的總結性筆記》 

架構之道:3個程序員成就微信朋友圈日均10億發布量[有視頻]》 

快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)

快速裂變:見證微信強大后臺架構從0到1的演進歷程(二)》 

微信團隊原創分享:Android內存泄漏監控和優化技巧總結》 

全面總結iOS版微信升級iOS9遇到的各種“坑”》 

微信團隊原創資源混淆工具:讓你的APK立減1M》 

微信團隊原創Android資源混淆工具:AndResGuard [有源碼]》 

Android版微信安裝包“減肥”實戰記錄》 

iOS版微信安裝包“減肥”實戰記錄》 

移動端IM實踐:iOS版微信界面卡頓監測方案》 

微信“紅包照片”背后的技術難題》 

移動端IM實踐:iOS版微信小視頻功能技術方案實錄》 

移動端IM實踐:Android版微信如何大幅提升交互性能(一)

移動端IM實踐:Android版微信如何大幅提升交互性能(二)

移動端IM實踐:實現Android版微信的智能心跳機制》 

移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)

移動端IM實踐:iOS版微信的多設備字體適配方案探討》 

騰訊信鴿技術分享:百億級實時消息推送的實戰經驗

IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)

IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)

微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等

騰訊技術分享:微信小程序音視頻技術背后的故事

微信多媒體團隊梁俊斌訪談:聊一聊我所了解的音視頻技術

騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐

手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)

微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)

微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)

微信團隊分享:Kotlin漸被認可,Android版微信的技術嘗鮮之旅

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進

社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的

社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的

社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐

QQ設計團隊分享:新版 QQ 8.0 語音消息改版背后的功能設計思路

微信團隊分享:極致優化,iOS版微信編譯速度3倍提升的實踐總結

IM“掃一掃”功能很好做?看看微信“掃一掃識物”的完整技術實現

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

IM開發寶典:史上最全,微信各種功能參數和邏輯規則資料匯總

>> 更多同類文章 ……

(本文同步發布于://www.52im.net/thread-3008-1-1.html

posted @ 2020-05-21 13:23 Jack Jiang 閱讀(155) | 評論 (0)編輯 收藏

2020年5月14日

本文引用了公眾號“鮮棗課堂”的《5G消息(RCS),到底是什么?》和公眾號“InfoQ”的《5G消息來了,它會干掉微信還是變成另一個飛信?》兩篇文章的部分內容,感謝原作者的分享。

1、引言

上個月3大運營商(移動、電信、聯通)發布了《5G消息白皮書》(此白皮書PDF版 ▶ 點此附件下載),宣布將共同啟動5G消息業務。

 

簡單理解,5G消息相當于是原先短消息服務的全新升級。與以前的短消息相比,5G消息具有多媒體、能互動服務的能力,不僅有文字、圖片,還能發視頻、位置,甚至進行支付。

嗯,聽起很熟悉——這不就是微信、支付寶們現在干的活嗎?

沒錯!在移動互聯網時代已經淪為微信這類IM巨頭的管道工的運營商們,正在試圖通過5G消息這個新工具搶回失去的話語權。

那么,5G消息到底是什么?是完全的創新技術還是舊式短信技術的新瓶裝舊酒?它是否真的具有可以取代現時移動端主流IM產品的能力?請跟著本文,一起讀懂5G消息的前世今生!

學習交流:

- 即時通訊/推送技術開發交流5群:215477170[推薦]

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

本文已同步發布于“即時通訊技術圈”公眾號,歡迎關注: 

▲ 本文在公眾號上的鏈接是:https://mp.weixin.qq.com/s/BF3ja1Uui6Pn32z0zI0H2g

2、5G消息是全新技術?

No,并不是!

“5G消息”,其實和5G并沒有什么關系。它既不是5G特有的功能,也不是5G時代新開發出來的業務。它的真實身份,是誕生已有 10 多年的 RCS 技術。

3大運營商之所以要把它名名為“5G消息”,很大原因應該還是想借5G這個熱點,從營銷推廣的角度進行的考慮,與技術無關。

RCS,全稱是“Rich Communication Suite”,中文翻譯過來就是“富媒體通訊套件”。

什么是“富媒體(Rich Media)”?傳統電話只有語音,傳統短信只有文本。而“富媒體”,包括文本、語音、圖片、視頻、動畫、表情、位置等多種媒體形式。我們天天在用的微信,就是一種富媒體通信工具。

 

RCS,也被稱為融合通信。所謂“融合”,既可以理解為多種媒體形式融合,也可以理解為IP業務和傳統電信網業務的融合。

大白話來說,RCS可以理解為它是升級了傳統的短信產品,使“短信”豐富化。

3、RCS技術的發展歷程

我們先了解一下RCS技術的發展歷程。

3.1 傳統PC端IM的興起,讓電信廠商們蠢蠢欲動

我們把時間撥回到20多年前。當時,PC互聯網以驚人的速度發展壯大,給人類帶來了前所未有的信息大爆炸。

尤其是ICQ、MSN、OICQ(即QQ)等即時通訊工具的出現,讓人們見識到多媒體通訊的無限樂趣。

 

▲ 能認全這3個IM的,都是老網民

于是,人們想到,這么有趣的通訊方式,是不是可以移植到手機上?

3.2 IMS的出現

3G移動通信標準,就是在這樣的背景下建立起來的(2000年5月)。從3G起,手機的重點發展方向變成了數據業務,以滿足人們日益增長的多媒體通信需求。

3G向4G的發展過程中,負責牽頭標準制定的3GPP組織,考慮到傳統語音通話及短信業務也需要向多媒體演進。于是,在2002年的3GPP Release 5版本中正式提出了IMS。

搞通信的讀者一定對IMS這個詞非常熟悉。如果是非通信專業的讀者,我可以告訴你另外一個和IMS密切相關的詞,那就是這幾年特別火的VoLTE(Voice over LTE)。

是的,VoLTE業務,就是基于IMS實現的。

IMS的全稱,叫做IP多媒體子系統(IP Multimedia Subsystem)。它包括了一系列不同的通信設備網元。

IMS的網絡結構和業務流程非常復雜。對于IMS的作用,我們可以這么理解——它幫助4G LTE這個純數據網絡,實現對語音通話和短信的支持,并對它們進行強化(升級為多媒體形式)。

 

▲ IMS就是4G LTE網絡的一個“插件”。有了它,4G才能打電話和發短信

在IMS的基礎上,才有了VoLTE和RCS。

 

3.3 RCS的出現

2007年,RCS由一小部分GSMA(全球移動通信系統協會)成員提出,目的是為了運營商之間的多媒體消息互通。

2008年2月,GSMA正式成立RCS項目,并將其命名為“home”。此后,GSMA發布了多個版本的RCS、RCS-e(enhance,增強型)規范。

 

▲ GSMA,可以理解為全球運營商協會,主要代表運營商利益

RCS發布之后,得到了全球眾多運營商的擁護。尤其是2008年4G LTE標準發布之后,RCS成為運營商們建設4G的標配。

3.4 RCS在移動端IM的擠壓下持續演進

同樣是2008年前后,iPhone和安卓相繼問世,移動通信進入智能機時代,移動互聯網市場開始井噴。

2011年左右,以WhatsApp、LINE、Facebook Message為代表的OTT通訊工具出現并迅速崛起,大量蠶食了傳統運營商的語音、短信收入。

 

于是,海外運營商更加仰仗RCS,希望借此與OTT軟件進行競爭。當時Vodafone、Orange、SKT、Verizon、O2等海外知名運營商都推出了自己的RCS解決方案和品牌。

2016年,為了進一步推動RCS的產品開發及全球部署,GSMA推出了RCS Universal Profile(通用配置文件,簡稱UP,相當于是一個規范標準),并陸續更新了多個版本。目前最新的版本,就是2019年10月發布的Version 2.4。

 

▲ RCS和UP的版本演進

3.5 RCS在國內的發展

我們回過頭來看看RCS在國內的發展。

中國的3G和4G建設啟動普遍晚于歐美日韓。3G就不用說了,晚了8年。4G是晚了5年。2013年底,工信部才發放了LTE商用牌照。

作為LTE的積極建設者,中國移動在2014年LTE大規模建網的同時,就非??粗豂MS、VoLTE、RCS的商業價值。

因為飛信的前車之鑒,中國移動已經充分意識到傳統運營商正在出現管道化的趨勢,利潤空間將不斷被擠壓,急需和OTT搶占流量入口,尋找新的業務增長點。

 

2015年,就在國內LTE網絡覆蓋初具規模之后,中國移動大幅提前了國內各省IMS和VoLTE網絡的建設進度,并積極推動廣州研究院的RCS業務驗證和測試。

其實國內的三大運營商也都沒有閑著,在 2017 年 4 月就完成了 RCS 三方(3大運營商)互通測試規范編制。其中,中國移動較為積極,在 2017 年 12 月即商用 RCS,包含 Native、App、PC 以及 SDK 四種終端形態。2019 年中移終端公司要求,所有在終端公司入庫銷售的機型都要支持 RCS Native 功能。

隨著5G的到來,情況又發生了不同。

為了給5G網絡騰挪更多的頻譜空間,運營商必須加速2/3G網絡的退網。而依附在2/3G網絡上的傳統語音和短信業務,必須盡快遷移到LTE和IMS網絡上。(國內LTE網絡的成熟覆蓋,IMS的建設完成,使得RCS的推出具備了很好的時機。)

與此同時,面對OTT業務的持續打壓,運營商也希望通過RCS進行最后一搏。于是,就有了這次“5G消息”業務的聯合發布。

之所以叫“5G消息”,主要是希望借助5G的品牌,體現RCS業務和傳統消息業務之間的代差。

4、RCS到底能實現什么樣的功能和體驗?

接下來我們講講RCS到底能實現什么樣的功能,以及用戶體驗,何以讓3大運營商重燃對搞微信等IM巨頭的信心。

4.1 運營商對RCS的功能定位

中國移動在2014年曾經基于RCS提出了「三新」目標。這里面的三新,指的是:新通話、新消息以及新聯系,分別指代了手機上的電話,短信,通訊錄這三大入口。

  1. “新通話”以VoLTE為核心,增強用戶通話質量和體驗;
  2. “新消息”無縫融合多種媒體和消息格式,無縫與傳統短/彩信互通;
  3. “新聯系”以真實手機號碼為前提,構建全新的社交、公眾信息服務入口。

其實,這已經很明確地給出了RCS的功能和定位。

從總體上來看,運營商對RCS的應用場景定位分為兩種:

  • 一種是個人用戶與個人用戶之間的消息交互;
  • 一種是企業用戶與個人用戶之間的消息交互。
 

4.2 RCS在普通用戶間的消息交互與微信等IM相比,優勢并不明顯

針對場景1(即個人用戶與個人用戶之間的消息交互),RCS支持點對點消息,支持群發、群聊,支持語音、圖片、視頻多媒體消息,還支持發送位置、名片等,甚至還支持消息云備份和閱后即焚。

RCS的個人用戶聊天時可以支持以下消息類型(跟IM很像): 

這些功能和我們目前的微信都差不多,RCS并沒有體現出什么優勢??悸塹接沒骯叩仍?,RCS估計很難撬動微信的霸主地位,未來可能主要是處于一個輔助性的地位。

更受運營商及整個產業關注的,其實是場景2(即企業用戶與個人用戶之間的消息交互)。

4.3 RCS在企業與個人的消息交互場景下,有很大的想象空間

2017年,GSMA在UP2.0規范中引入MaaP,還發布了MaaP白皮書,明確提出了面向A2P(Application to Person)行業消息的“RCS商業富媒體消息(RCS Business Messaging)”,也就是我們所說的場景2。

 

▲ RCS商業富媒體消息

MaaP,就是Messaging as a Platform,消息即平臺。

RCS商業富媒體消息,為企業和個人用戶之間提供消息交互接口,在圖片和視頻等基礎上增加了交互能力,方便企業向用戶輸出個性化服務。

例如機票酒店預訂查詢、物流查詢、網購訂單查詢等一系列輕應用功能,都可以通過RCS商業富媒體消息實現。

 

RCS商業富媒體消息的價值在于,它為企業和用戶提供了一條新通道。借助這條通道,企業可以觸達用戶。用戶也可以觸達服務。

從某種意義上來說,它很像小程序、微信公眾號(服務號),甚至電話客服中心。

為了實現RCS商業富媒體消息,運營商在自身網絡上架設了MaaP能力增強開放平臺和Chatbot聊天機器人。平臺面向企業開放API接口,以提供服務。

技術架構大概是這樣的: 

4.4 RCS擁有普通IM所不具備的優勢

運營商對于“5G消息”(即RCS技術)這么有信心,源碼它的一些獨特的優勢。

4.4.1)RCS優勢1:它需要單獨安裝APP

它不需要單獨安裝第三方APP,手機原生就可以支持。這大幅降低了用戶使用門檻,也節約了推廣成本。

 

▲ 每個人的手機,都少不了這三個圖標

雖然目前大部分手機并不支持5G消息,但后續各大廠商對手機進行軟件升級,支持RCS UP 2.4規范之后,都可以支持。即使你不是5G手機(但至少是4G手機),也可以支持。

4.4.2)RCS優勢2:無需注冊賬號

RCS業務和手機號碼直接關聯,用戶號碼就是賬號,無需注冊。

這同樣降低了用戶使用業務的復雜度,不僅解決了身份認證問題,還打通了“平臺孤島”(無需在每個商戶單獨注冊賬號)。

 

▲ 手機號即賬號,一號通用

4.4.3)RCS優勢3:無需添加好友

RCS牢牢掌握住了用戶通信錄這個社交金鑰匙,無需添加好友,即刻就能建立社交網絡。

盡管RCS擁有以上優勢,但真正決定它能否走向成功的,并不是這些優勢,而是它的生態和商業模式。

RCS的產業鏈既包括運營商、設備商、終端廠商,也包括平臺服務商、內容提供商等。

設備商和終端廠商還好說,關鍵是平臺服務商和內容服務商。它們愿不愿意投入,平臺和應用該如何開發,開發能不能獲得回報,如何吸引商戶,要不要收費,如何收費,商戶愿不愿意買單,這些都是未知數。

如果生態不能做大做強,就無法孵化更多的5G消息應用場景,也就談不上商業價值回報。

5、現在才統一起來做“5G消息”,是否有點遲了?

從 3G 時代開始,全球電信運營商就受到 OTT(“OverTheTop”的縮寫,指通過互聯網向用戶提供各種應用服務)廠商的沖擊,國內三大運營商也不例外,傳統的話音和短信業務收入大幅下降,OTT 服務雖然能帶來流量收入,但也難以掩蓋其增量不增收的尷尬。

隨著微信等移動端IM互聯網應用的不斷擴張,運營商雖手握數億用戶,期間也有過大大小小的嘗試與掙扎,例如中國移動的飛信、中國聯通的沃友以及中國電信的易信,但最終都被邊緣化。對 RCS 也有不少投入和試點,卻還是雷聲大雨點小,掀不起水花。三大運營商依然淪為主要提供語音、短信、流量等基礎通信服務的“管道工”。

 

似乎,過度的競爭是導致運營商們錯失機遇的主因之一。

某運營商直言:“過去,移動披靡一切。但后來對內‘弄不死’電信和聯通,對外干不過阿里騰訊,對上交代不了國資委的考核。”。三大運營商終于聯手便是 5G 消息的最大意義。

與采用私有協議的 App“孤島式”的現狀相比,由于三家運營商基于同一的國際標準(GSMA RCS UP 2.4),5G 消息在互聯互通上的優勢更為明顯。

對比過去傳統的短信業務,5G 消息可快速迭代——相關技術標準在 3 年內已迭代 5 大版本,從 UP1.0(2016 年 Q4)到最新的 UP2.4(2020 年 Q4)。

6、RCS看起來很美,但并非無懈可擊

RCS確實具體先天優勢,但也并非無懈可擊。

RCS 仍面臨三大挑戰:

  • 1)用戶的服務體驗不一致,也給終端互聯互通帶來挑戰(它無法做到像微信這樣的IM一樣,每款手機上安裝的都是同一個應用);
  • 2)消息業務將會不斷創新演進,需要終端快速跟進和支持,傳統的技術研究、標準制定,終端研發,運營商測試等運營商長周期的流程,難以適應 RCS 快速發展;
  • 3)行業客戶對 RCS 業務仍不熟悉,開發門檻較高。

另一方面,要培養用戶使用短信入口的服務也不是件易事。

5G 時代,是多終端連接的物聯網時代,小程序也被視為物聯網眾多的入口之一,誰都不會想放過這個機遇。

但 5G 消息能否拿回被微信這種IM應用搶走的市場,又或者在新的物聯網增量市場分得一杯羹,尚需時日見證??梢鑰隙ǖ氖?,對于客戶來說,尤其是行業客戶,多了一個選擇。一個不是騰訊系,不是阿里系,也不是頭條系的選擇。

7、雖有不確定性,但RCS未來可期

目前,國內運營商的5G消息業務還處于試點大區聯調測試階段。

2020年4月10日,中興通訊助力中國移動在杭州成功打通了基于GSMA UP2.4標準的5G消息first call,標志著國內5G消息商用進入正式倒計時。

據業內消息,2020年6月份國內就可以推出5G消息的正式商用。國內手機的升級支持,估計需要3個月到1年的時間。

相信隨著5G建設的深入,RCS很快會成為大家手機中的標配。

“5G消息”到底會發展成什么樣,作為IM開發者和普通用戶來說,商業終究不是普通人該考慮的。從功能和體驗上來說,多一種選擇也未償不是件好事,我們期待它早日到來!

 

8、最新動態:中國移動已于2020年5月10日上線“5G消息”APP

“5G消息”App是中國移動基于國際RCS標準打造的一款通訊及服務軟件,支持發送文本、圖片、音視頻、地理位置等豐富消息;還可與商戶的聊天機器人進行交互,獲取7*24小時的智能服務。已于5月10日上線到蘋果App store。

 

不幸的是,“5G消息”App上線僅一天就被下架(下架時間為5月11日)。

中國移動回應下架事件時說:因當前一些終端尚未支持5G消息功能,中國移動開發了“5G消息”APP,可以讓開發者完成Chatbot(智能聊天機器人)應用開發后,真實體驗消息交互服務,吸引廣大開發者積極參與5G消息的合作生態構建,并非面向客戶商用發布的產品。

中國移動表示:由于前期三家運營商聯合發布5G消息白皮書,引發較高輿論關注,為?;?#8220;5G消息”名稱不被惡意搶占,中國移動近日在應用市場進行上線(指的就是上線“5G消息”App)。因存在一些技術問題,該APP目前臨時下線,稍后會重新上線。

在過去數年里,運營商與蘋果公司的溝通討論一直在進行中。目前通過安裝App體驗的做法,可以幫助蘋果公司和蘋果手機用戶體驗和使用5G消息。

9、《“5G消息”白皮書》附件下載

(附件無法上傳,請從此鏈接下載://www.52im.net/thread-3001-1-1.html

10、參考資料

[1] 5G消息白皮書

[2] 中國移動率先發布5G消息APP:支持iOS/Android

[3] “5G消息”來了,App小心了!

[4] 中國移動、中國電信、中國聯通聯合發布《5G消息白皮書》

[5] 5G消息(RCS),到底是什么?

[6] 5G消息來了,它會干掉微信還是變成另一個飛信?

附錄:更多IM產品方面的文章

技術往事:微信估值已超5千億,雷軍曾有機會收編張小龍及其Foxmail

QQ和微信兇猛成長的背后:騰訊網絡基礎架構的這些年

閑話即時通訊:騰訊的成長史本質就是一部QQ成長史

騰訊開發微信花了多少錢?技術難度真這么大?難在哪?

技術往事:史上最全QQ圖標變遷過程,追尋IM巨人的演進歷史》 

開發往事:深度講述2010到2015,微信一路風雨的背后》 

開發往事:記錄微信3.0版背后的故事(距微信1.0發布9個月時)》 

微信七年回顧:歷經多少質疑和差評,才配擁有今天的強大

前創始團隊成員分享:盤點微信的前世今生——微信成功的必然和偶然

QQ的成功,遠沒有你想象的那么順利和輕松

[技術腦洞] 如果把14億中國人拉到一個微信群里技術上能實現嗎?》 

QQ和微信止步不前,意味著即時通訊社交應用創業的第2春已來?

那些年微信開發過的雞肋功能,及其帶給我們的思考

為什么說即時通訊社交APP創業就是一個坑?

即時通訊創業必讀:解密微信的產品定位、創新思維、設計法則等

老羅最新發布了“子彈短信”這款IM,主打熟人社交能否對標微信?

盤點和反思在微信的陰影下艱難求生的移動端IM應用

QQ現狀深度剖析:你還認為QQ已經被微信打敗了嗎?

那些年微信開發過的雞肋功能,及其帶給我們的思考

漸行漸遠的人人網:十年親歷者的互聯網社交產品復盤和反思

中國互聯網社交二十年:全民見證的互聯網創業演義

讀懂微信:從1.0到7.0版本,一個主流IM社交工具的進化史

王欣回應微信封禁,解釋為何取名“馬桶MT”

同為IM社交產品中的王者,QQ與微信到底有什么區別

還原真實的騰訊:從最不被看好,到即時通訊巨頭的草根創業史

知識科普:IM聊天應用是如何將消息發送給對方的?(非技術篇)

QQ設計團隊分享:新版 QQ 8.0 語音消息改版背后的功能設計思路

社交應用教父級人物的張小龍和馬化騰的同與不同

技事往事:你知道IM聊天軟件中的“對方正在輸入…”功能的起源嗎?

盤點移動互聯網時代的社交產品進化史(上篇):誰主沉浮

盤點移動互聯網時代的社交產品進化史(下篇):大浪淘沙

IM熱門功能思考:為什么微信里沒有消息“已讀”功能?

IM熱門功能思考:聊天中加入“對方正在輸入…”真的好嗎?

別做夢了,社交產品哪有那么容易成功

微信那么牛,為什么海外成功的卻是抖音?

專訪馬化騰:首次開談個人經歷、管理心得、技術創新、微信的誕生等

一文讀懂微信之父張小龍:失敗天才、顛覆者、獨裁者、人性操控師

新技術展望:5G消息能取代IM應用?一文讀懂5G消息的前世今生!

>> 更多同類文章 ……

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

(本文同步更新于://www.52im.net/thread-3001-1-1.html

posted @ 2020-05-14 11:47 Jack Jiang 閱讀(172) | 評論 (0)編輯 收藏

2020年5月9日

本文引用了后端技術指南針公眾號“淺談RPC那些事兒1”和即時通訊網的“即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途”兩篇文章的部分內容。

1、引言

經常有開發者在糾結怎么開發IM集群,雖然真正的使用人數,可能用個人電腦單機都能支撐。

你也許會說,明明不需要用到IM集群,干嗎要自找麻煩?答曰:“老板說這個得有!”、“萬一產品做成了,用戶量達到百萬、千萬級呢?”,各種回答,反此種種。總之,IM集群就是得整一個(先甭管用不用的上...)。

當然,玩笑歸玩笑,真正要做到可投入到生產級別的IM集群系統,難度還是相當大的。必竟IM這種長連接應用相比傳統Http這種短連接應用太不標準。

我們以一個典型的IM聊天消息傳輸為例:

假設存在兩個正在聊天的用戶(用戶A和用戶B),當A連接的是IM集群中的IM實例1、B連接的是IM集群中的IM實例2,此時當用戶A向用戶B發送一條聊天消息時,這條消息應該如何傳遞呢?

我們梳理一下上面這個例子的消息流轉過程:

  • 1)IM聊天消息首先會由用戶A發往IM實例1;
  • 2)IM實例1會將此條消息轉交給IM實例2;
  • 3)IM實例2會將此條消息最終投遞給連接在本實例上的用戶B。

如上述流程所示,這就是一個IM集群系統中典型的聊天消息投遞過程。

那么,這其中涉及到一個關鍵步驟:即第2)步中如何實現“IM實例1會將此條消息轉交給IM實例2”?

此時,RPC技術出場了!

 

▲ 上圖是個典型的分布式IM架構,注意中間的“RPC通信”字樣本圖引用自《基于Go的馬蜂窩旅游網分布式IM系統技術實踐

本文將以通俗易懂的白話形式,幫你快速理解IM集群中的關鍵技術——RPC。

推薦閱讀:另一篇RPC基礎知識文章也值得一讀《即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途》。

本文已同步發布于“即時通訊技術圈”公眾號,歡迎關注:

▲ 本文在公眾號上的鏈接是:https://mp.weixin.qq.com/s/0RXTUWHXDmMddsPVWej2Qg

2、相關文章

▼ 以下兩篇文章有助于您對RPC和IM集群有個初步的概念:

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途》(推薦)

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?

▼ IM開發干貨系列文章(本文是其第24篇):

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要做手機掃碼登陸?先看看微信的掃碼登錄功能技術原理

IM開發基礎知識補課(九):想開發IM集群?先搞懂什么是RPC!》(本文)

如果您是IM開發初學者,強烈建議首先閱讀《新手入門一篇就夠:從零開發移動端IM》。

3、正文概述

限于篇幅原因,本文不會深入展開RPC的底層技術原理,會盡量用通俗白話的方式對概念性的東西進行講解。

通過本文你將主要了解到以下內容:

  • 1)什么是RPC;
  • 2)為什么需要RPC;
  • 3)RPC的重要組件;
  • 4)常見RPC框架和各自特點。

4、什么是RPC?

RPC 是1984年代由 Andrew D. Birrell & Bruce Jay Nelson 提出的(見二位大佬的論文《Implementing Remote Procedure Calls),所以它并不是最近才有的技術概念。

關于RPC的介紹,正經的資料上大概是這樣介紹的:

RPC(Remote Procedure Call)遠程過程調用,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的協議。也就是說兩臺服務器A,B,一個應用部署在A服務器上,想要調用B服務器上應用提供的方法,由于不在一個內存空間,不能直接調用,需要通過網絡來表達調用的語義和傳達調用的數據。

大白話理解RPC就是:RPC讓你用別人家的東西就像自己家的一樣。

看得我似懂非懂,于是我不得不問幾個問題:

  • 1)為啥要用別人家的東西——請求其他服務);
  • 2)我怎么可以借到別人家的東西——其他服務調用;
  • 3)要是借用的話哪種形式更好——確定一個合適的調用方法);
  • 4)怎么讓我用別人東西像自己的一樣——屏蔽底層細節透明通信)。

在解答這些問題之前,我們必須達到一個共識問題:RPC只是一種通信模式,和http并不沖突對立,相反http可以作為RPC傳輸數據的一種協議,把RPC當作一種模式和思想,我們才能更好地理解它。

更嚴謹的RPC基礎知識介紹,請閱讀:《即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途》。

5、為什么需要RPC?

以大家最熟悉的電商系統為例,這樣規模的分布式系統,需要拆分出用戶服務、商品服務、優惠券服務、支付服務、訂單服務、物流服務、售后服務等等。這些服務之間都相互調用,這時內部調用最好使用 RPC ,同時每個服務都可以獨立部署,獨立上線。 

也就說當我們的項目太大,需要解耦服務,擴展性強、部署靈活,這時就要用到 RPC ,這主要是解決了分布式系統中,服務與服務之間的調用問題。

 

▲ 上圖中的分布系統內部,就是用RPC實現的本圖引用自《從新手到架構師,一篇就夠:從100到1000萬高并發的架構演進之路

對于IM集群這樣的分布式系統來說,不同IM實例間的用戶聊天消息,就是通過RPC進行流轉的。

6、為什么不直接使用HTTP,而要搞RPC?

在日常業務中我們可以把功能封裝成靜態庫、動態庫、sdk、獨立服務等,最常見也最方便的還是HTTP這種形式的調用。

HTTP服務把需要提供的服務暴露成接口(也就是通常所說的http rest接口啦),使用方直接按約定的HTTP方法和URI進行數據交互。

我們都知道HTTP協議是應用層協議,是個非常標準的協議,在HTTP協議之下還有網絡層、傳輸層、數據鏈路層等,一個數據包packet除了凈荷payload之外還有很多header,由于標準和通用性的設計目標也使得HTTP一次數據交互真正傳輸的payload只是其中一部分。

 

HTTP是我們用的最多最熟悉的交互模式,在系統內部各個服務之間接口較少,交互不多的情況下工作得還不錯。

但如果在內部系統調用很復雜的前提下,HTTP調用的效率和安全性就不那么理想了。

 

以IM系統為例,單個IM實例的吞吐效率至少可以達到幾萬甚至數十萬QPS,使用HTTP這種短連接(調用時建立socket連接,完成后釋放連接)方式顯的相當低效(每次調用都要重新經歷TCP的3次握手、4次揮手過程),在分布式的情況下勢必拉低整個IM集群的吞吐效率。而對于RPC,這種socket長連接方式對于高性能場景來說,效果是顯而易見的。

更重要的是面對眾多的服務我們需要的不僅僅是一個通信方式,而是一個內部服務的管理系統,這也就是我們今天說的RPC框架。注意:RPC是一種模式策略和框架,并不是單純的通信協議。

題外話:實際上,HTTP在RPC系統中,并不是個你死我活的關系,必竟HTTP只是個通信協議,而HTTP有某些性能要求不敏感的場景來說,是完全可以作為RPC的具體實現協議之一來使用的。

7、RPC的調用過程是什么樣的?

 

▲ 典型的RPC調用過程

如上圖所示,一個典型的RPC調用過程是這樣(過程序號對應上圖中的數字):

  • 1)客戶端(client)以本地調用方式調用服務;
  • 2)客戶端存根(client stub)接收到調用后,負責將方法、參數等組裝成能夠進行網絡傳輸的消息體(將消息體對象序列化為二進制);
  • 3)客戶端通過 sockets 將消息發送到服務端;
  • 4)服務端存根(server stub)收到消息后進行解碼(將消息對象反序列化);
  • 5)服務端存根(server stub)根據解碼結果調用本地的服務;
  • 6)本地服務執行并將結果返回給服務端存根(server stub);
  • 7)服務端存根(server stub)將返回結果打包成消息(將結果消息對象序列化);
  • 8)服務端(server)通過 sockets 將消息發送到客戶端;
  • 9)客戶端存根(client stub)接收到結果消息,并進行解碼(將結果消息發序列化);
  • 10)客戶端(client)得到最終結果。

RPC的作用,其實就是要把上述2、3、4、7、8、9 這些步驟都封裝起來。是不是很神奇?

8、關于HTTP和RPC的一些爭議

HTTP和RPC是兩個很容易混淆的概念,對于剛開始接觸RPC的人來說,通常都會困惑:有HTTP了為什么還要用RPC?

在知乎上看到了這個很有趣的問題:《既然有http請求,為什么還要用rpc?

其中一個大佬的回答感覺很有意思: 

換個角度來說:HTTP 與 RPC 的關系就好比普通話與方言的關系。要進行跨企業服務調用時,往往都是通過 HTTP API,也就是普通話,雖然效率不高,但是通用,沒有太多溝通的學習成本。但是在企業內部還是 RPC 更加高效,同一個企業公用一套方言進行高效率的交流,要比通用的 HTTP 協議來交流更加節省資源。整個中國有非常多的方言,正如有很多的企業內部服務各有自己的一套交互協議一樣。雖然國家一直在提倡使用普通話交流,但是這么多年過去了,你回一趟家鄉探個親什么的就會發現身邊的人還是流行說方言。

如果再深入一點說,普通話本質上也是一種方言,只不過它是官方的方言,使用最為廣泛的方言,相比而言其它方言都是小語種,小語種之中也會有幾個使用比較廣泛比較特色的方言占比也會比較大。這就好比開源 RPC 協議中 Protobuf 和 Thrift 一樣,它們兩應該是 RPC 協議中使用最為廣泛的兩個。

總之:RPC是一種編程模式和概念,并不是非常具體的一種技術,實際上和HTTP沒有明確的沖突,HTTP可以作為RPC傳輸協議,原因還是RPCpid際上是一種內部服務框架而不是一個具體的通信協議,它可以涉及服務注冊、服務治理、服務發現、熔斷機制、負載均衡等。

9、典型的RPC框架

一個典型RPC框架中,包含了服務發現、負載、容錯、網絡傳輸、序列化等組件,其中“RPC 協議”就指明了程序如何進行網絡傳輸和序列化。

 

▲ 一個典型的 RPC 架構原理圖本圖引用自《即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途

 

▲ 著名RPC框架Dubbo的架構圖本圖引用自《即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途

一個 RPC 最重要的功能???,就是上圖中的”RPC 協議”部分: 

其中的序列化和反序列化的意思是:

  • 1)序列化:將數據結構或對象轉換成二進制串的過程;
  • 2)反序列化:將序列化中所生成的二進制串轉換成數據結構或者對象的過程。

在網絡消息傳輸中可以基于TCP、UDP、http來實現,各自都有各自的特點。

基于 TCP 實現的 RPC 調用,能夠靈活對協議字段進行定制,減少網絡開銷提高性能,實現更大的吞吐量和并發數,但要關注底層細節,在進行數據解析時更加復雜一些(比如最受歡迎的Protobuf的使用)。

基于 HTTP 實現的 RPC 可以使用 JSON 和 XML 格式的請求或響應數據,解析工具很成熟,在其上進行二次開發會非常便捷和簡單。但是 HTTP 是上層協議,所占用的字節數會比使用 TCP 協議傳輸所占用的字節數更高。

對于其他部分,本文不再展開。

10、市面上常見的RPC框架及其特點

常見 RPC 技術和框架有:

  • 1)應用級的服務框架:阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
  • 2)遠程通信協議:RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
  • 3)通信框架:MINA 和 Netty。

目前流行的開源 RPC 框架還是比較多的,有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。

下面重點介紹當前最流行的三種RPC框架主要特點:

  • 1)gRPC:是 Google 公布的開源軟件,基于最新的 HTTP 2.0 協議,并支持常見的眾多編程語言。RPC 框架是基于 HTTP 協議實現的,底層使用到了 Netty 框架的支持;
  • 2)Thrift:是 Facebook 的開源 RPC 框架,主要是一個跨語言的服務開發框架。用戶只要在其之上進行二次開發就行,應用對于底層的 RPC 通訊等都是透明的。不過這個對于用戶來說需要學習特定領域語言這個特性,還是有一定成本的;
  • 3)Dubbo:是阿里集團開源的一個極為出名的 RPC 框架,在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是極其鮮明的特色。

11、本文小結

小結一下,簡單地理解RPC就是:

RPC 就是從一臺機器(客戶端)上通過參數傳遞的方式調用另一臺機器(服務器)上的一個函數或方法(可以統稱為服務)并得到返回的結果。

RPC 會隱藏底層的通訊細節(不需要直接處理Socket通訊或Http通訊)。

RPC 是一個請求響應模型??突Ф朔⑵鵯肭?,服務器返回響應(類似于Http的工作方式)。

RPC 在使用形式上像調用本地函數(或方法)一樣去調用遠程的函數(或方法)。

12、參考資料

[1] 什么是 RPC 框架

[2] 誰能用通俗的語言解釋一下什么是 RPC 框架?

[3] 淺談RPC那些事兒[1]

[4] 即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途

[5] 即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?

附錄:有關IM架構設計的文章

淺談IM系統的架構設計

簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端

一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)

一套原創分布式即時通訊(IM)系統理論架構方案

從零到卓越:京東客服即時通訊系統的技術架構演進歷程

蘑菇街即時通訊/IM服務器開發之架構選擇

騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT

微信后臺基于時間序的海量數據冷熱分級架構設計實踐

微信技術總監談架構:微信之道——大道至簡(演講全文)

如何解讀《微信技術總監談架構:微信之道——大道至簡》

快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)

17年的實踐:騰訊海量產品的技術方法論

移動端IM中大規模群消息的推送如何保證效率、實時性?

現代IM系統中聊天消息的同步和存儲方案探討

IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?

IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議

IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token

WhatsApp技術實踐分享:32人工程團隊創造的技術神話

微信朋友圈千億訪問量背后的技術挑戰和實踐總結

王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等

IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?

騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面

以微博類應用場景為例,總結海量社交系統的架構設計步驟

快速理解高性能HTTP服務端的負載均衡技術原理

子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐

知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路

IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列

微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)

微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)

新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐

一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐

阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史

阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路

社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等

社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進

社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的

社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的

社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐

社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐

社交軟件紅包技術解密(八):全面解密微博紅包技術方案

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等

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

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途

多維度對比5款主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了

從游擊隊到正規軍(一):馬蜂窩旅游網的IM系統架構演進之路

從游擊隊到正規軍(二):馬蜂窩旅游網的IM客戶端架構演進和實踐總結

IM開發基礎知識補課(六):數據庫用NoSQL還是SQL?讀這篇就夠了!

瓜子IM智能客服系統的數據架構設計(整理自現場演講,有配套PPT)

阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處

從游擊隊到正規軍(三):基于Go的馬蜂窩旅游網分布式IM系統技術實踐

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

IM開發基礎知識補課(九):想開發IM集群?先搞懂什么是RPC!

>> 更多同類文章 ……

本文已同步發布于“即時通訊技術圈”公眾號,歡迎關注:


(本文同步發布于://www.52im.net/thread-2996-1-1.html

posted @ 2020-05-09 11:54 Jack Jiang 閱讀(158) | 評論 (0)編輯 收藏

2020年4月28日

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

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

2020年4月23日

阿里巴巴技術團隊于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、部分內容截圖預覽

 
 
 

6、歷史版及最新版下載地址

請從此下載:阿里技術結晶:阿里巴巴Java開發手冊-v1.6.0-泰山版》[附件下載]

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

2020年4月21日

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

1、引言

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

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

1)移動狀態網絡信號不穩定,高時延、易抖動丟包、通道狹窄;

2)移動狀態網絡接入類型和接入點變化頻繁;

3)移動狀態用戶使用高頻化、碎片化、非WIFI流量敏感。

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

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

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

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

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

(本文已同步發布于://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。由基線網絡庫定義的重載接口進行監控。

為了提高網絡請求成功率,首先需要建立監控體系,從而使得基線網絡庫能夠通過網絡統計??橄駻PM投遞各種維度的網絡請求數據。有了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)弱網檢測??椋和ü杓鳩acebook的弱網檢測是基于網速擬合的網絡等級分級,分為網絡情況非常差(2G或者無網)、網絡情況較差(3G)、網絡情況一般、網絡情況較好、網絡情況非常好五個等級;

6)HTTPDNS??椋河行У慕餼雋嗽擻探儷治侍?;

7)超級管道重試:基于HTTP的網關代理,具有異地容災代理能力;

8)ipv4/ipv6??椋菏侗鴝松鮮莍pv4 only環境、v4/v6雙棧還是ipv6 only環境;

9)復合連接??椋嚎梢栽趕erver 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端)

>> 更多同類文章 ……

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

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

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

2020年4月17日

本文同時發布于“即時通訊技術圈”公眾號,鏈接是: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。

(本文同步發布于://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老矣,尚能飯否?

>> 更多同類文章 ……

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

(本文同步發布于://www.52im.net/thread-2979-1-1.html

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

Jack Jiang的 Mail: [email protected], 聯系QQ: 413980957, 微信: hellojackjiang
{ganrao} 富贵棋牌游戏官网 兴动哈尔滨麻将安卓版3010 手机麻将神器免费下 pc蛋蛋单双大小规 GPK钱龙捕鱼涨分技巧 哈灵浙江游戏一好朋友一起 吉祥棋牌官方下载 二四六好彩免费资料 英超精华 詹俊 真钱娱乐棋牌 20选五走势图带连线 西甲联赛积分排名 明星三缺一2002手机版安卓 推荐几个玩现金的棋牌 内部精准一肖1码 白城麻将吉祥棋牌账号