Jack Jiang

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

置頂隨筆

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

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

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

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

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

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

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

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

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

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

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

posted @ 2016-07-28 11:07 Jack Jiang 閱讀(1343) | 評論 (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 閱讀(1565) | 評論 (2)編輯 收藏

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

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

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

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

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

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

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

posted @ 2016-06-24 14:38 Jack Jiang 閱讀(568) | 評論 (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 閱讀(2606) | 評論 (0)編輯 收藏

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

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

2020年5月21日

1、引言

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

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

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

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

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

本文將根據微信官方目前已公開的資料,將它的一些常用功能參數和邏輯規則資料進行了匯總整理,希望能助力你的IM開發?。ū疚囊寻l布于:http://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版微信的臃腫之困與模塊化實踐之路

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

微信團隊原創分享:微信客戶端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開發寶典:史上最全,微信各種功能參數和邏輯規則資料匯總

>> 更多同類文章 ……

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

posted @ 2020-05-21 13:23 Jack Jiang 閱讀(54) | 評論 (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消息白皮書,引發較高輿論關注,為保護“5G消息”名稱不被惡意搶占,中國移動近日在應用市場進行上線(指的就是上線“5G消息”App)。因存在一些技術問題,該APP目前臨時下線,稍后會重新上線。

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

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

(附件無法上傳,請從此鏈接下載:http://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消息的前世今生!

>> 更多同類文章 ……

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

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

posted @ 2020-05-14 11:47 Jack Jiang 閱讀(120) | 評論 (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 是一個請求響應模型??蛻舳税l起請求,服務器返回響應(類似于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!

>> 更多同類文章 ……

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


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

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

2020年4月28日

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

posted @ 2020-04-28 12:05 Jack Jiang 閱讀(206) | 評論 (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 閱讀(729) | 評論 (0)編輯 收藏

2020年4月21日

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

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重試??鄢裏o網情況,首頁推薦頁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 閱讀(160) | 評論 (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。

(本文同步發布于: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來說,也意味著很大的資金投入?,F在新設備基本都是支持的,但畢竟還是有一些老設備,如果在使用壽命到期之前就換,就是虧錢。

所以,運營商和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 閱讀(235) | 評論 (0)編輯 收藏

2020年4月13日

本文已同時發布于我的“即時通訊技術圈”公眾號。

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的互聯網原本是為固定網絡和網絡互聯設計,而運營商的移動網絡是為移動性連接而生?;ヂ摼W的連接是分布式的,而移動通信網絡是集中控制的。

這兩者的技術基因確實有很大不同,在早期移動網絡網絡性能較慢的情況下,這兩者的結合,矛盾似乎并不突出。

實際上,在傳統電信網(就是大家最常用的電話、短信網絡)與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 閱讀(278) | 評論 (0)編輯 收藏

2020年4月9日

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

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

2020年4月6日

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

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

Jack Jiang的 Mail: [email protected], 聯系QQ: 413980957, 微信: hellojackjiang
魔法糖果闯关 下载股票大盘 新十一选五最新走势 自动刷单赚钱软件 微乐捉鸡麻将最新版下载安装 云南11选5开奖时间 河北十一选五推荐任 贵州快3开奖结果今天开奖结果 免费刮刮乐刮现金红包下载 四川血战麻将技巧 广西十一选五基本走势图百度彩票 北京小赛车群怎么赚 海口小姐上门特色服务 喜迎棋牌手机客户端下载安 辽宁快乐12选5走 福彩3d分析预测 足球比分直播188比分