Jack Jiang

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

          1、引言

          隨著互聯網安全意識的普遍提高,對安全要求稍高的應用中,HTTPS的使用是很常見的,甚至在1年前,蘋果公司就將使用HTTPS作為APP上架蘋果應用市場的先決條件之一(詳見:《蘋果即將強制實施 ATS,你的APP準備好切換到HTTPS了嗎?》)。

          所以,無論是即時通訊IM還是其它應用,在網絡安全意識增強的今天,很多場景下使用HTTPS是肯定沒錯的。對于即時通訊IM的開發人員來說,長連接用TLS這沒疑問,短連接用HTTPS也沒問題,但我想問你一個最基礎的面視問題:HTTPS到底用的是對稱加密還是非對稱加密?

          要回答這個問題,顯然需要再梳理一下HTTPS的技術原理了,本文將帶你了解HTTPS到底用的是對稱加密還是非對稱加密,以及具體又是怎么使用的。

          學習交流:

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

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

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

          2、相關文章

          ? 要理解HTTPS,須對HTTP協議有所了解,以下文章可能是您需要的:

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

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

          不為人知的網絡編程(八):從數據傳輸層深度解密HTTP

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

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

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

          可能會搞砸你的面試:你知道一個TCP連接上能發起多少個HTTP請求嗎?

          ? 想更好的理解本文有關HTTPS的知識,建議一并閱以下HTTPS的基礎文章:

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

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

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

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

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

          ? 本文是IM通訊安全知識系列文章中的第8篇,此系列總目錄如下:

          即時通訊安全篇(一):正確地理解和使用Android端加密算法

          即時通訊安全篇(二):探討組合加密算法在IM中的應用

          即時通訊安全篇(三):常用加解密算法與通訊安全講解

          即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險

          即時通訊安全篇(五):對稱加密技術在Android平臺上的應用實踐

          即時通訊安全篇(六):非對稱加密技術的原理與應用實踐

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

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

          3、HTTPS靈魂拷問

          隨著 HTTPS 建站的成本下降,現在大部分的網站都已經開始用上 HTTPS 協議。大家都知道 HTTPS 比 HTTP 安全,也聽說過與 HTTPS 協議相關的概念有 SSL 、非對稱加密、 CA證書等。

          但對于以下靈魂三拷問可能就答不上了:

          • 1)為什么用了 HTTPS 就是安全的?
          • 2)HTTPS 的底層原理如何實現?
          • 3)用了 HTTPS 就一定安全嗎?

          不用擔心,本文將在解答“HTTPS到底用的是對稱加密還是非對稱加密?”的同時層層深入,從原理上把 HTTPS 的安全性講透,您也將同時理解上述問題。

          4、HTTPS 的實現原理

          大家可能都聽說過 HTTPS 協議之所以是安全的是因為 HTTPS 協議會對傳輸的數據進行加密,而加密過程是使用了非對稱加密實現。但其實:HTTPS 在內容傳輸的加密上使用的是對稱加密,非對稱加密只作用在證書驗證階段。

          HTTPS的整體過程分為證書驗證和數據傳輸階段,具體的交互過程如下: 

          ① 證書驗證階段:

          1)瀏覽器發起 HTTPS 請求;

          2)服務端返回 HTTPS 證書;

          3)客戶端驗證證書是否合法,如果不合法則提示告警。

          ② 數據傳輸階段:

          1)當證書驗證合法后,在本地生成隨機數;

          2)通過公鑰加密隨機數,并把加密后的隨機數傳輸到服務端;

          3)服務端通過私鑰對隨機數進行解密;

          4)服務端通過客戶端傳入的隨機數構造對稱加密算法,對返回結果內容進行加密后傳輸。

          5、為什么數據傳輸是用對稱加密?

          首先:非對稱加密的加解密效率是非常低的,而 http 的應用場景中通常端與端之間存在大量的交互,非對稱加密的效率是無法接受的。

          另外:在 HTTPS 的場景中只有服務端保存了私鑰,一對公私鑰只能實現單向的加解密,所以 HTTPS 中內容傳輸加密采取的是對稱加密,而不是非對稱加密。

          6、為什么需要 CA 認證機構頒發證書?

          HTTP 協議被認為不安全是因為傳輸過程容易被監聽者勾線監聽、偽造服務器,而 HTTPS 協議主要解決的便是網絡傳輸的安全性問題。

          首先我們假設不存在認證機構,任何人都可以制作證書,這帶來的安全風險便是經典的“中間人攻擊”問題。

          “中間人攻擊”的具體過程如下: 

          如上圖所以,過程原理如下:

          • 1)本地請求被劫持(如DNS劫持等),所有請求均發送到中間人的服務器;
          • 2)中間人服務器返回中間人自己的證書;
          • 3)客戶端創建隨機數,通過中間人證書的公鑰對隨機數加密后傳送給中間人,然后憑隨機數構造對稱加密對傳輸內容進行加密傳輸;
          • 4)中間人因為擁有客戶端的隨機數,可以通過對稱加密算法進行內容解密;
          • 5)中間人以客戶端的請求內容再向正規網站發起請求;
          • 6)因為中間人與服務器的通信過程是合法的,正規網站通過建立的安全通道返回加密后的數據;
          • 7)中間人憑借與正規網站建立的對稱加密算法對內容進行解密;
          • 8)中間人通過與客戶端建立的對稱加密算法對正規內容返回的數據進行加密傳輸;
          • 9)客戶端通過與中間人建立的對稱加密算法對返回結果數據進行解密。

          由于缺少對證書的驗證,所以客戶端雖然發起的是 HTTPS 請求,但客戶端完全不知道自己的網絡已被攔截,傳輸內容被中間人全部竊取。

          7、瀏覽器是如何確保 CA 證書的合法性?

          7.1 證書包含什么信息?

          • 1)頒發機構信息;
          • 2)公鑰;
          • 3)公司信息;
          • 4)域名;
          • 5)有效期;
          • 6)指紋;
          • 7)......

          7.2 證書的合法性依據是什么?

          • 1)首先:權威機構是要有認證的,不是隨便一個機構都有資格頒發證書,不然也不叫做權威機構;
          • 2)另外:證書的可信性基于信任制,權威機構需要對其頒發的證書進行信用背書,只要是權威機構生成的證書,我們就認為是合法的。

          所以權威機構會對申請者的信息進行審核,不同等級的權威機構對審核的要求也不一樣,于是證書也分為免費的、便宜的和貴的。

          7.3 瀏覽器如何驗證證書的合法性?

          瀏覽器發起 HTTPS 請求時,服務器會返回網站的 SSL 證書,瀏覽器需要對證書做以下驗證:

          1)驗證域名、有效期等信息是否正確:證書上都有包含這些信息,比較容易完成驗證;

          2)判斷證書來源是否合法:每份簽發證書都可以根據驗證鏈查找到對應的根證書,操作系統、瀏覽器會在本地存儲權威機構的根證書,利用本地根證書可以對對應機構簽發證書完成來源驗證(如下圖所示): 

          3)判斷證書是否被篡改:需要與 CA 服務器進行校驗;

          4)判斷證書是否已吊銷:通過CRL(Certificate Revocation List 證書注銷列表)和 OCSP(Online Certificate Status Protocol 在線證書狀態協議)實現,其中 OCSP 可用于第3步中以減少與 CA 服務器的交互,提高驗證效率。

          以上任意一步都滿足的情況下瀏覽器才認為證書是合法的。

          這里插一個我想了很久的但其實答案很簡單的問題:

          既然證書是公開的,如果要發起中間人攻擊,我在官網上下載一份證書作為我的服務器證書,那客戶端肯定會認同這個證書是合法的,如何避免這種證書冒用的情況?

          其實這就是非加密對稱中公私鑰的用處,雖然中間人可以得到證書,但私鑰是無法獲取的,一份公鑰是不可能推算出其對應的私鑰,中間人即使拿到證書也無法偽裝成合法服務端,因為無法對客戶端傳入的加密數據進行解密。

          7.4 只有認證機構可以生成證書嗎?

          如果需要瀏覽器不提示安全風險,那只能使用認證機構簽發的證書。但瀏覽器通常只是提示安全風險,并不限制網站不能訪問,所以從技術上誰都可以生成證書,只要有證書就可以完成網站的 HTTPS 傳輸。

          例如早期的 12306 采用的便是手動安裝私有證書的形式實現 HTTPS 訪問: 

          8、本地隨機數被竊取怎么辦?

          證書驗證是采用非對稱加密實現,但是傳輸過程是采用對稱加密,而其中對稱加密算法中重要的隨機數是由本地生成并且存儲于本地的,HTTPS 如何保證隨機數不會被竊取?

          其實 HTTPS 并不包含對隨機數的安全保證,HTTPS 保證的只是傳輸過程安全,而隨機數存儲于本地,本地的安全屬于另一安全范疇,應對的措施有安裝殺毒軟件、反木馬、瀏覽器升級修復漏洞等。

          9、用了 HTTPS 會被抓包嗎?

          HTTPS 的數據是加密的,常規下抓包工具代理請求后抓到的包內容是加密狀態,無法直接查看。

          但是,正如前文所說,瀏覽器只會提示安全風險,如果用戶授權仍然可以繼續訪問網站,完成請求。因此,只要客戶端是我們自己的終端,我們授權的情況下,便可以組建中間人網絡,而抓包工具便是作為中間人的代理。通常 HTTPS 抓包工具的使用方法是會生成一個證書,用戶需要手動把證書安裝到客戶端中,然后終端發起的所有請求通過該證書完成與抓包工具的交互,然后抓包工具再轉發請求到服務器,最后把服務器返回的結果在控制臺輸出后再返回給終端,從而完成整個請求的閉環。

          既然 HTTPS 不能防抓包,那 HTTPS 有什么意義?

          HTTPS 可以防止用戶在不知情的情況下通信鏈路被監聽,對于主動授信的抓包操作是不提供防護的,因為這個場景用戶是已經對風險知情。要防止被抓包,需要采用應用級的安全防護,例如采用私有的對稱加密,同時做好移動端的防反編譯加固,防止本地算法被破解。

          10、本文小結

          以下用簡短的Q&A形式進行全文總結。

          Q: HTTPS 為什么安全?

          A: 因為 HTTPS 保證了傳輸安全,防止傳輸過程被監聽、防止數據被竊取,可以確認網站的真實性。

          Q: HTTPS 的傳輸過程是怎樣的?

          A: 客戶端發起 HTTPS 請求,服務端返回證書,客戶端對證書進行驗證,驗證通過后本地生成用于改造對稱加密算法的隨機數,通過證書中的公鑰對隨機數進行加密傳輸到服務端,服務端接收后通過私鑰解密得到隨機數,之后的數據交互通過對稱加密算法進行加解密。

          Q: 為什么需要證書?

          A: 防止”中間人“攻擊,同時可以為網站提供身份證明。

          Q: 使用 HTTPS 會被抓包嗎?

          A: 會被抓包,HTTPS 只防止用戶在不知情的情況下通信被監聽,如果用戶主動授信,是可以構建“中間人”網絡,代理軟件可以對傳輸內容進行解密。

          好了,回歸到本文標的問題,我們來總結回顧一下。

          Q: HTTPS用的是對稱加密還是非對稱加密?

          Q: HTTPS 在內容傳輸的加密上使用的是對稱加密,非對稱加密只作用在證書驗證階段。

          順手 po 一張學習的過程圖(點擊查看大圖):

          附錄:更多有關IM安全的文章

          傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示

          理論聯系實際:一套典型的IM通信協議設計詳解(含安全層設計)

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

          來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享

          簡述實時音視頻聊天中端到端加密(E2EE)的工作原理

          移動端安全通信的利器——端到端加密(E2EE)技術詳解

          Web端即時通訊安全:跨站點WebSocket劫持漏洞詳解(含示例代碼)

          通俗易懂:一篇掌握即時通訊的消息傳輸安全原理

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

          快速讀懂量子通信、量子加密技術

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

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

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

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

          >> 更多同類文章 ……

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

          posted @ 2019-12-10 12:15 Jack Jiang 閱讀(177) | 評論 (0)編輯 收藏

          1、引言

          在即時通訊網經常能看到各種高大上的高并發、分布式、高性能架構設計方面的文章,平時大家參加的眾多開發者大會,主題也都是各種高大上的話題——什么5G啦、AI人工智能啦、什么阿里雙11分分鐘多少萬QPS高并發等等。

          但實際上,對于普通的開發者(包括IM開發人員)來說,多數公司、多數團隊也都是干著默默無聞、平淡無奇的產品開發,并沒有那么多高并發、高大上的事情可以做。

          就拿一個IM系統來說,無論你的架構設計考慮了多少分布式、高吞吐、高可用,所有這些事情只要落地,那編碼的第一件事情就是要實現幾乎所有信息系統都要面對的任務——如何設計賬號登錄功能?

          本文將分享幾種典型的移動端賬號登陸方式的技術原理,以及設計思路,理解后,完全可以快速實施于你的各種應用系統(并不限于IM系統)中。本文閱讀對像主要為剛入門的開發人員,請程序老司機們嘴下留情哦。

           

          通過本篇文章, 你可以學到:

          1)主流賬號登陋技術方案細節;

          2)相應的表設計;

          3)相應的流程設計。

          通過本篇文章, 你無法學到:

          與其他原理性的文章一樣,本篇不涉及具體代碼實現細節(對于程序員來說,只要思路搞通,代碼咋寫都不會太爛,大家應該都有體會)。

          學習交流:

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

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

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

          2、IM開發干貨系列文章

          本文是系列文章中的第20篇,總目錄如下:

          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開發基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路》(本文)

          3、最經典的用戶名密碼注冊登陸方式

          一個典型的用戶名密碼注冊登陸功能類似于下面這樣:

           

          這種賬號登陸方式很經典也很常用,先注冊、再進行登錄,尤其在老一點的CMS系統、網站系統、聊天應用中都能找到這個影子。

          它的技術原理流程圖如下:

           
           

          如上圖所示,詳細的流程說明如下:

          • 1)前端將用戶名、密碼發送到服務器,服務器進行常規的判斷,判斷用戶名、密碼長度是否滿足,用戶名是否重復等條件,條件不通過直接返回對應錯誤碼給到前端,這里密碼字段,為了防止傳輸過程中被截胡,建議加密再上傳,我們的傳輸密碼默認都是會進行一個md5加密,然后記錄到數據庫再進行一層加密,就算是脫庫也沒事,密碼不要明文存儲。
          • 2)校驗通過后,就將用戶名密碼寫入數據庫,并進行后面積分發放等操作,這里不展開。
          • 3)現在進行登錄,前端將用戶名,密碼發送給到服務端,服務端首先會校驗登錄次數是否超過設置的閾值,如果超過只能繼續等待被關小黑屋。
          • 4)如果未超過繼續登錄邏輯,判斷用戶名、密碼是否正確,不正確密碼則進行閾值的判斷,如果超過則關小黑屋,記住小黑屋必須設置過期時間,要不然就會永久關上了,這個可以用redis的過期來做。
          • 5)登錄成功后進行后續的一切后置邏輯,比如加積分。。。等操作。

          這種經典的注冊登陸方式,具體怎么設計就不在這里贅述了,誰都懂。

          4、現今最主流的手機號注冊登陸方式

          4.1 基本原理

          典型的手機號注冊登陸功能類似于下圖:

           

          典型的手機號注冊技術原理流程圖如下:

           
           

          如上圖所示,詳細的流程說明如下:

          • 1)首先輸入手機號:然后發送到服務端,服務端將手機號記錄在我們數據庫中,然后生成隨機驗證碼,并將手機號和驗證碼綁定到一個redis里面,然后記錄過期時間,這個過期時間一般是10分鐘左右,這就是我們一般手機驗證碼的有效期;
          • 2)手機接收到手機短信后:那么就在界面填寫驗證碼發送服務端,服務端收到驗證碼后就會在redis里面查詢到這個手機號對應的驗證碼,失敗就返回錯誤碼。
          • 3)成功后:就進行登錄操作。

          這里看起來沒有明確的注冊登錄操作,其實在發送手機號碼就可以認為是一個常規的注冊,然后后面的驗證碼輸入就是一個登陸操作。

          但這種區別于常見的用戶名密碼注冊方式,是沒有密碼的的。

          問: 那我要密碼咋辦?

          答: 在后續產品里面增加一個手機號碼密碼補錄的功能即可,這也是現在很常規的手法,但是現在移動互聯網大爆炸時代,密碼已經顯得不是那么重要了,反正我從來記不住密碼,如果手機號碼能操作的app,絕對不用密碼來操作。

          4.2 具體的數據庫設計

          表結構: 

          說明:

          這里只是單純說明需要用到的數據,沒有擴展具體場景,這個表結構能夠滿足上面兩個方案的設計。

          5、一種輔助的登陸方式:第3方賬號登陸

          5.1 基本原理

          現在很多應用為了降低新用戶的使用門檻,都會對接第3方賬號進行登陸(比如:用微信號登陸、QQ號登陸、微博賬號登陸等)。

          這里我以QQ的開放平臺登錄邏輯為例進行講解。

          某團外賣的QQ賬號登陸功能如下圖:

           

          我們先來一波時序圖:

           
           

          時序流程詳細說明:

          • 1)客戶端自己調起登錄的界面,進行輸入用戶名、密碼,這里的是第三方的用戶名,密碼,登錄成功后,會返回access_token openid expire_in,這過程會使用到oauth2.0,不過在sdk里面進行內置回調獲取了,后面我們會說明我們自身實現的oauth2.0;
          • 2)客戶端拿到access_token、openid、login_type(qq、wechat...)請求應用服務器,應用服務器拿到這些數據后就會根據對應的login_type去對應的用戶中心進行access_token和openid進行校驗。校驗不通過則返回對應錯誤碼;
          • 3)校驗通過后就會判斷本地是否有這個login_type和openid是否存在,不存在則進行獲取遠程的用戶名、頭像等基礎信息來作為本地基礎數據,并且返回code值;
          • 4)如果已經存在,那就是進行登錄操作,返回code值;
          • 5)客戶端拿到code值后進行token值的換取,這個完全遵照oauth2.0的協議來走的,后續每次請求必須帶上token,token值在服務端的時間比較久,因為我們想要做的是那種永不下線的操作,所以每次請求我們都將token過期時間進行累加。

          想要深入了解第3方賬號登陸,可以讀讀這兩篇:《第三方登錄:QQ登錄接入指南》、《第三方賬號登錄功能接入完全流程》。

          5.2 具體的數據庫設計

          表結構:

          對于讀者的建議,我這里做一下數據庫的整理。

           

          用戶基礎表(users):

           

          用戶驗證關聯表(user_auth_rel): 

           

          本地用戶表(user_local_auth):

           

          第三方用戶表(user_third_auth): 

           

          表結說明:

          • 1)users表只是單純針對我們業務側的登錄,主要是做自身業務的oauth2.0業務;
          • 2)user_local_auth是做自己用戶名、密碼登錄,手機號碼登錄信息記錄;
          • 3)user_third_auth是我們第三方用戶體系的數據記錄;
          • 4)user_auth_rel是用來關聯我們users表與user_local_auth、user_third_auth;
          • 5)整個設計理念就是將自建用戶與第三方在存儲上區分,這在架構演進上也是合乎情理的,開始用戶體系大多自建,而后才是對外接入。

          6、本文小結

          總的來講,賬號注冊登錄功能在一般的系統里都是入口功能,一般情況下都不會太復雜。

          對于第三方用戶的接入技術,也同樣比較簡單,我文章里設計多一個user_thirds是可以支持足夠多的第三方接入,當然一般我們也就兩三個登錄就好,太多登錄方不僅自身維護成本,界面擺盤也不好看不是。

          希望大家能夠通過以上學習,能夠對于賬戶注冊登錄有一個比較好的認知,文章里設計方案不包含分表分庫、沒有服務化,就是簡單直接的設計,當然用戶量和需要的不一樣,在這個基礎上還要加很多東西,謝謝大家閱讀。

          附錄:更多IM開發方面的文章

          [1] IM開發綜合文章:

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

          移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”

          移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結

          從客戶端的角度來談談移動端IM的消息可靠性和送達機制

          現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障

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

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

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

          移動端IM開發需要面對的技術問題

          開發IM是自己設計協議用字節流好還是字符流好?

          請問有人知道語音留言聊天的主流實現方式嗎?

          一個低成本確保IM消息時序的方法探討

          完全自已開發的IM該如何設計“失敗重試”機制?

          通俗易懂:基于集群的移動端IM接入層負載均衡方案分享

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

          即時通訊系統的原理、技術和應用(技術論文)

          開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀

          QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)

          QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)

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

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

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

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

          基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的?

          騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)

          騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)

          字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8

          全面掌握移動端主流圖片格式的特點、性能、調優等

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

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

          自已開發IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)

          融云技術分享:解密融云IM產品的聊天消息ID生成策略

          適合新手:從零開發一個IM服務端(基于Netty,有完整源碼)

          拿起鍵盤就是干:跟我一起徒手開發一套分布式IM系統

          >> 更多同類文章 …… 

          [2] 有關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紅包的功能邏輯、容災、運維、架構等

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

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

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

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

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

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

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

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

          >> 更多同類文章 ……

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

          posted @ 2019-12-07 19:38 Jack Jiang 閱讀(143) | 評論 (0)編輯 收藏

          1、引言

          整個暑假去面試,面試了很多家公司(無論是小廠還是大廠)問到的深度不同,網絡原理是面試最容易問到的問題,雖然我們在項目中很少去實踐它,但是了解其原理,會讓我們背后網絡通信是如果工作的,既能在面試官面前體現出你的基礎是否扎實,也能對以后深入網絡這部分學習有更多的了解。

          很多同學面試在準備這部分的時候,都會去背,這部分確實很難掌握,我個人總結的最好的學習網絡原理的方法就是不用刻意的去記憶而是完全的結合實際去講整個原理融會貫通。雖然一開始學習起來很吃力,但是稍微用點心,多看幾遍,多問自己為什么,把自己當做是開發網絡原理的開發者,面試前的準備只要理清邏輯就足夠了,而不是去背這部分內容。

          而且這部分相同的知識點面試官有多種提問方式,但是其中很多都是換湯不換藥。我記得最多的問的是輸入URL,到頁面呈現出來,其中經歷了什么?這道面試題的背后,涉及到了很多網絡原理的知識,我們這篇文章不會全部分享到,而是先把由來和網絡層次劃分弄清楚,就完成了這篇文章的目的。

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

          相關文章:

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

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

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

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

          學習交流:

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

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

          2、關于作者

          小鹿(前端工程師):

          微信公眾號:小鹿動畫學編程

          Github地址:https://github.com/luxiangqiang

          個人博客:http://luxiangqiang.com/

          3、系列文章

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

          腦殘式網絡編程入門(一):跟著動畫來學TCP三次握手和四次揮手

          腦殘式網絡編程入門(二):我們在讀寫Socket時,究竟在讀寫什么?

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

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

          腦殘式網絡編程入門(五):每天都在用的Ping命令,它到底是什么?

          腦殘式網絡編程入門(六):什么是公網IP和內網IP?NAT轉換又是什么鬼?

          腦殘式網絡編程入門(七):面視必備,史上最通俗計算機網絡分層詳解》(本文)

          4、為什么要進行網絡層次劃分?

          說到網絡層次劃分并不陌生,我剛剛接觸到網絡層次的時候一臉懵逼,這么多層,一層不就行了嘛?層與層之間好多協議,還有各種數據包,第一次我放棄了。

          當我從新拾起網絡層次的時候,我下定決心從根上理解它。首先弄明白它的原理,那必定要知道它的由來,也就是為什么要進行網絡層次劃分?這個問題問的好。

          假如“小鹿”是網絡的開發人員,起初認為計算機與計算機之間的通信只需要一根線就可以完成通信,對沒錯,但是世界那么大,那么多計算機,距離又遠,不但浪費線,還沒出現各種線被你偷偷剪斷的情況,毋庸置疑,那計算機之間通信就不行了。(后邊出來了無線網,雖然其中網關、路由之間也需要連線,但不是讓每臺計算機兩兩連接,而是一個區域為單位計算機相互連接通信)

          不行,老板說,“小鹿”你給我想法子改,改不出來今晚不能睡覺,“小鹿”仔細想了想,這還是個技術活,需要進行全面的改進,也發現所謂的計算機之間的連線只能傳送0、1信號,另一臺計算并不知道那么多0、1代表什么,而且“小鹿”又發現不同廠商的生產的計算機既然有連線實現通信也是很麻煩的,干脆定義一套規則吧,無論“某碩”計算機還是“某想”計算機,都必須遵守這套規則,其實所說的這套規則就是我們經常說的“網絡協議”。

          不是說網絡層次的由來嗎,怎么講到網絡協議了。咱們繼續,通過上面的問題,那個計算機之間通過連線傳送0、1信號的問題雖然規定了通信規則,但是除了像0、1這種無意義的信號之外,網絡中還存在著其他各種各樣的問題,兩個計算機之間怎么進行識別?以及怎么才能知道對方的地址?以及不同計算機應用程序怎么知道是給自己傳遞的數據,還有不同的通信數據格式怎么來規定等等一系列的問題都出來了。

          “小鹿”發現,如果各種問題都寫成一套協議來規定雙方通信的規則,但是呢?萬一其中哪些規則通信中出現問題,影響到了其他規則,最常見的就是數據包,一個數據包中如果包含各種各樣的協議,不就亂套了。

          “小鹿”為了能夠把它設計的更好,決定采用分層劃分的結構,既能規定不同層的完成的功能,又能實現層與層之間的改動而不相互影響,這就是我們經常聽到網絡劃分層次的好處。

          5、網絡分層是如何進行分層的?

          既然我們決定要分層,那么分為幾層才好呢?

          起初網絡分層是標準的七層,也就是我們所說的 OSI 七層模型。

           

          ▲ OSI參考模型或七層模型

          我們所知道的還有 TCP/IP 四層模型和 TCP/IP 五層模型。這又是怎么出來的,其實所謂的 TCP/IP 四層模型和 TCP/IP 五層模型是以 OSI 七層優化而來,把某些層進行合并了,其實本質上還是相同的,但是我個人最喜歡用五層來解釋。

           

          ▲ 五層模型

          6、每一層的作用是什么?

          這一部分涉及到每一層的很多協議和知識點,但是我們這一節不具體分享,為什么?我們具體深入之前必須大腦里有個具體的網絡分層結構圖,先要知道每層是做什么的,層與層之間的關系,然后下一節再深入每層中的每個協議怎么通信的,這樣的好處學起來條理清晰,而不至于當時我學習的時候表面還不懂,就深入最后懵逼狀態。

          6.1 物理層

          物理層,顧名思義,用物理手段將電腦連接起來,就像我們上邊講到的計算機之間的物理連線。主要用來傳輸0、1信號,上邊也分析過了,0、1信號畢竟沒有任何的現實意義,所有我們用另一層用來規定不同0、1組合的意義是什么。

          6.2 數據鏈路層

          下層的物理層既然不能規定不同0、1組合的信號代表什么意義,那么我們在數據鏈路層規定一套協議,專門的給0、1信號進行分組,以及規定不同的組代表什么意思,從而雙方計算機都能夠進行識別,這個協議就是“以太網協議”(具體的以太網協議內容下節內容詳細講解)。

          但是問題又來了,我們要發送給對方計算機,怎么標識對方以及怎么知道對方的地址呢?

          6.2.1)MAC 地址:

          我們所說的MAC地址到底的作用是啥?說白了它就是作為網絡中計算機設備的唯一標識,從計算機在廠商生產出來就被十六進制的數標識為MAC地址。

          既然我們知道了用MAC地址作為標識,那么怎么才能知道我們要進行通信的計算機MAC地址呢?

          6.2.2)廣播:

          這里廣播詳細的在下一節講,這一節你只需要知道廣播可以幫助我們能夠知道對方的 MAC 地址。那么既然知道了MAC地址就可以通信了?沒有想得那么簡單,廣播中還存在兩種情況,一種是,在同一子網絡下(同一局域網下)的計算機是通過 ARP 協議獲取到對方 MAC地址的。不同自網絡中(不同局域網)中是交給兩個局域網的網關(路由器)去處理的。這里邊涉及到很多細節的知識,都會集中到下一節,但是這一節你了解怎么進行標識計算機和怎么獲取到MAC地址就可以了。

          6.3 網絡層

          物理層和數據鏈路層都有自己的事情要做,也就是我們上邊所講到的這些(里邊很多細節不在這節多說)。上邊兩層在我看來可以完成正常通信了,那么網絡層出來干啥子?

          網絡層的由來是因為在數據鏈路層中我們說說兩臺計算機之間的通信是分為同一子網絡和不同子網絡之間,那么問題就來了,怎么判斷兩臺計算機是否在同一子網絡(局域網)中?這就是網絡層要解決的問題。

          6.3.1)IP 協議:

          我們通常用到的 IP 地址,就是網絡層中的東西,所規定的的協議就是 IP 協議。很多小伙伴問,IP 地址想必也是地址吧,上邊都有唯一標識的 MAC 地址了,IP 地址出來是混飯吃的?為了能夠讓大家更方便的理解 IP 地址和 MAC 地址,我們可以將 IP 地址抽象成一種邏輯上的地址,也就是說 MAC 地址是物理上的地址,就是定死了。IP 地址呢,是動態分配的,不是固定死的。

          我們就是通過 IP 地址來判斷兩個計算機設備是否在同一子網絡中的,那么你會問它是怎么判斷的,以及 IP 地址誰給他分配的?又是如何分配的等一些列問題,我們不著急,這里只說一下大體的流程,詳細會后續寫一大篇。

          既然我們通過 IP 地址來判斷兩個計算機是否處于同一局域網中,那么首先要知道對方的 IP 地址吧?DNS 解析想必大家都知道,可以將域名解析為 IP 地址。好了,我們知道兩臺計算機的 IP 地址了,怎么進行判斷是否同一局域網中?

          6.3.2)子網掩碼:

          嘿嘿,又是一個只聽說過,但是不知道這個什么作用的一個名詞,沒事,等我聊完,你就明白是做什么的了。

          子網掩碼就是用來標識同一局域網中的 IP 地址的信息的?什么信息?IP 地址是由 32 個二進制位組成的,也就是四個十進制(如:255.255.255.000)。

          子網掩碼也是由 32 個二進制位組成的,但是只能用 0 或 1 來表示,如:11111111.11111111.11111111.00000000。

          到底什么意思呢?有 1 的部分表示網絡部分,有 0 表示主機部分,這和判斷兩臺計算機是否在同一局域網中有什么關系?沒錯,是有關系的!兩臺計算機的 IP 地址分別和子網掩碼進行一種運算(AND 運算),如果結果相同,兩臺計算機就在同一局域網中,否則就不在同一局域網中。

          AND 是如何進行運算的,IP 的數據包的組成等問題,不在這里多陳述。

          6.4 傳輸層

          好了,如果你認為計算機可以進行通信了,那么“小鹿”恭喜你,你已經基本知道了以上幾層劃分的作用,但是如果你正在一邊打 LOL,一邊和朋友在 QQ 聊天,突然,游戲中隊友聊天信息出現在了 QQ 窗口中,咦?出現了什么情況?

          其實是以上層級還是不夠,出現上邊的原因就是,兩臺計算機雖然可以通信了,但是每天計算機運行著好多的程序,誰知道你們傳輸的信息是屬于哪些程序的,怨不得 LOL 的聊天信息跑到了 QQ 窗口中。

          想必大家猜到了傳輸層主要用來干啥滴,是的,傳輸層的主要功能就是為了能夠實現“端口到端口”的通信。計算機上運行的不同程序都會分配不同的端口,所以才能使得數據能夠正確的傳送給不同的應用程序。

          6.4.1)UDP 協議:

          加入端口號也需要一套規則,那就是 UDP 協議,但是 UDP協議有個缺點,一旦進行通信,就不知道對方是否接收到數據了,我們再定義一套規則,讓其可以和對方進行確認,那么 TCP 出現了。

          6.4.2)TCP 協議:

          我們通常說 TCP 三次握手和四次揮手,沒錯,這就是傳輸層中完成的,TCP 三次握手涉及到的內容賊多,都可以單獨寫一篇長文,這里不多陳述,知道它是在傳輸層中完成的以及它的作用是什么,能夠認識到它就好了。

          6.5 應用層協議

          “喂,你發給我的是什么破數據,亂七八糟的,我TM能解析嗎?能不能按照我的規定給我傳送?“

          “好的,下次不敢了”

          想必大家已經猜到了應用層的協議,應用層的功能就是規定了應用程序的數據格式。我們經常用得到的電子郵件、HTTP協議、以及FTP數據的格式,就是在應用層定義的。

          7、每一層的的功能細節是什么?

          前面章節主要分享了網絡分層的基本概念,為什么要進行網絡分層?又是如何進行分層?每一層的基本功能是什么?而且對于每一層的的功能細節方面,比如數據包的組成以及每層包含的一些協議的使用都沒有細說,那么本節將繼續分享網絡分層每層中協議等深入講解。(PS:可能里邊有的講解不正確,還請大佬指出改正)

          7.1 物理層

          物理層里邊涉及到最多的是硬件底層的一些內容,沒有需要過多了解的內容,我們直接看數據鏈路層。

          7.2 數據鏈路層

          上回講到數據鏈路層中規定的“以太網協議”來規定電信號的分組形式,什么是以太網,以太網的數據包是什么樣子的?

          7.2.1)以太網協議:

          以太網規定,每組的電信號就是一個數據包,每個數據包我們可以成為“幀”。每幀的組成是由標頭(Head)和數據(Data)組成。

           

          那么你會問,標頭里有什么信息?Data 數據又會存放寫什么?為什么分為兩部分?放在一塊不好嗎?

          a)標頭:

          為什么傳輸數據會有標頭,我們想呀,在傳輸數據的時候,接收端怎么判斷是不是給自己發送的,那么就只取出標頭來進行判斷。

          數據包的標頭中通常會存放一些有關數據包的說明、發送者是誰、接受者又是誰等相關識別信息。

          標頭的長度固定為 18 字節,也就是說,一些標頭識別信息的大小不能超過 18 字節。

          b)數據:

          數據,顧名思義,你要傳輸給接收端什么數據都會放到數據包中,也就是整個數據包的具體內容,比如文件、字符串之類的。

          數據部分的長度最小至少為 46 個字節,最長 1500 字節。我們可能會想到,如果小于 46 字節沒啥問題可以存放開,那么大于 1500 字節怎么處理呢?很簡單,我們就分成兩個包處理(分割),兩個包存放不下就分割成三個包…

          7.2.2)廣播:

          上回說到,廣播的作用就是用來查找接收端的 MAC 地址,從而進行下一步的數據傳輸。注意,廣播只是一種發送數據的形式,而計算機想要知道另一臺計算機的 MAC 地址是通過 ARP 協議解決的,ARP 協議會在講完 IP 協議后再說,因為它會涉及到 IP 協議的一點內容,現在講可能會有點亂。

          如果你覺的上邊稍微有點亂,那怎們稍微屢一下,我們想要發送數據,首先要知道對方的唯一標識(MAC 地址),要想知道對方的 MAC 地址,需要使用 ARP 協議,假設我們通過 ARP 協議拿到了接收方的 MAC 地址。

          我們開始發送數據,將發送方的 MAC 地址和接收方的 MAC 地址封裝在數據包中,然后發送端向同一子網絡中(同一局域網)中的所有計算機發送該數據包,所有的計算機接收到該包之后,就對數據包的頭部進行提取,提取出里邊封裝好的接收端 MAC 地址和自己的 MAC 地址作比對,如果相同,就說明該數據包是給自己發送的,否則,就會丟棄該數據包,這個過程就是廣播的過程。

          上一篇文章在這個地方留下的一個問題就以上是在同一局域網中,如果不在同一局域網中我們怎么處理?我們平常使用無線網都知道每個無線局域網都會有一個路由器,我們先通過以上的方法將數據發送到路由器,然后路由器轉發數據到其他局域網中的計算機。

          7.3 網絡層

          網絡層中最重要的一個協議就是 IP 協議,我們一般發送端給服務端發送數據同時要知道兩個地址才能準確送達到對方,分別為 IP 地址和 MAC 地址。停!stop! 上邊講到的明明知道對方的 MAC 地址就可以傳輸數據了,為什么現在需要兩個地址呢?你給我說明白,說不明白取關!

          上邊確實是一個 MAC 地址就可以通信,但是前提是通過 ARP 協議獲得的 MAC 地址,而 ARP 協議正是利用的接收端的 IP 地址才獲取到接收端的 MAC 地址的,所以這兩個地址很重要,那么如果實現的,下邊會繼續講。

          7.3.1)IP 協議:

          IP 的數據包是直接放入到以太網數據包的“數據”部分的,這樣做有一個好處就是“上層的變動完全涉及不到下層的結構”。然后數據包就變成這個樣子了。

           

          IP 數據包也分為標頭(Head)和數據(Data)兩部分:

          • 1)標頭:IP 數據包的標頭是 20 ~ 60 字節,主要包括版本、IP 地址等信息;
          • 2)數據:數據的最大長度為 65515 字節。整個 IP 數據包的最大總長度為 65535 字節。主要存放 IP 數據包的具體內容。

          問題來了,以太網的數據部分最長為 1500 字節,你把一個長度為 65535 字節的 IP 數據包放到以太網的數據包匯總,不會被撐破嗎?你在逗我么?確實是呀,那我們就分割數據包吧,分割成幾個以太網數據包分開發送。

          7.3.2)AND 運算:

          IP 協議上篇文章中最重要的作用就是判斷兩個設備是否屬于同一子網中(同一局域網中)。

          將兩個IP地址與子網掩碼分別進行AND運算(兩個數位都為1,運算結果為1,否則為0),然后比較結果是否相同,如果是的話,就表明它們在同一個子網絡中,否則就不是。

          我們可以通過 DNS 解析知道對方的 IP ,除了判斷兩個計算機是否在同一局域網中,還有一個作用就是然后通過 ARP 協議獲取到對方的 MAC 地址。停!真想讓我取關嗎?ARP 就 TN 的說了多少遍了,該詳細說一下了吧?

          7.3.3)ARP 協議:

          前提:對方的 IP 地址是已知的,通過 DNS 解析得到。

          ARP 協議發出一個數據包,包含在以太網的數據包中(其中包含對方的 IP 地址,對方的 MAC 地址欄是 FF:FF:FF:FF:FF:FF)。子網絡中的每臺主機都會收到這個包,然后從中取出 IP 地址與自身對比,如果兩者相同,都做出回復,向對方報告自己的 MAC 地址,否則就丟棄這個包。

          7.4 傳輸層

          傳輸層主要涉及到兩個重要協議,UDP 和 TCP 協議,上篇講過主要用來確定端口到端口的通信,計算機中不同運行的程序端口號不相同。

          "端口"是 0 到 65535 之間的一個整數,正好 16 個二進制位。0 到 1023的端口被系統占用,我們只能選用大于1023 的端口。

          7.4.1)UDP 協議:

          UDP 協議也分為標頭(Head)和數據(Data)兩部分:

          • 1)標頭:標頭的長度為 8 字節。主要存放了發送和接收端口號;
          • 2)數據:數據部分和標頭部分的總長度不超過 65535 字節,正好放進一個IP數據包。

          前邊也講過,數據包之間是包含關系的,所以 UDP 的數據包是放到 IP 數據包的“數據”部分的,IP 數據包又放在以太網數據包的“數據”部分的。

           

          7.4.2)TCP 協議:

          TCP 和 UDP 是相同的,上一篇講了 UDP 和 TCP 的優缺點,TCP 保證了網絡的可靠性,TCP 三次握手和四次揮手就是這部分內容。

          TCP 的數據包和 UDP 相同嵌入在 IP 協議的“數據”部分,TCP 并沒有長度限制,但是為了保證傳輸效率,肯定要進行限制的,TCP 的數據包的長度一般不會超過 IP 數據包的長度了,保證單個的 TCP 數據包不再進行分割。

          7.5 應用層

          應用層是最高一層,直接面向用戶,它的數據包會放在 TCP 的數據包的“數據”部分,那么整個五層的數據包就會變成一下這樣。

           

          以上五層中的內容基本講完了,我是從下到上逐層寫的,這篇文章可以讓你入門網絡五層協議的基本內容了。

          8、寫在最后

          如果本文內容看完,還是有點懵,那怎么辦?

          可以繼續以下兩篇文章,它們應該可以讓你內力倍增:

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

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

          另外,關于計算機網絡協議的分層和關系,可以看看下面兩圖:

           

          * 上述兩張圖的清晰原圖,請見:《計算機網絡通訊協議關系圖(中文珍藏版)[附件下載]》。

          附錄:更多網絡編程基礎資料

          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技術之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協議的歷史演變和設計思路

          以網游服務端的網絡接入層設計為例,理解實時通信的技術挑戰

          邁向高階:優秀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請求嗎?

          知乎技術分享:知乎千萬級并發的高性能長連接網關技術實踐

          >> 更多同類文章 ……

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

          posted @ 2019-12-01 15:59 Jack Jiang 閱讀(344) | 評論 (0)編輯 收藏

               摘要: 本文引用了唐小智發表于InfoQ公眾號上的“釘釘企業級IM存儲架構創新之道”一文的部分內容,收錄時有改動,感謝原作者的無私分享。1、引言業界的 IM 產品在功能上同質化較高,而企業級的 IM 產品對于高可用、安全性又有更高的要求,如何打造具備差異化的產品,又在高可用、安全性、數據一致性等方面具備較高的品質,是企業級 IM 產品成功的關鍵。釘釘在過去短短幾年時間里,用戶數已破...  閱讀全文

          posted @ 2019-11-26 15:32 Jack Jiang 閱讀(153) | 評論 (0)編輯 收藏

               摘要: 本文原題“從實踐角度重新理解BIO和NIO”,原文由Object分享,為了更好的內容表現力,收錄時有改動。1、引言這段時間自己在看一些Java中BIO和NIO之類的東西,也看了很多博客,發現各種關于NIO的理論概念說的天花亂墜頭頭是道,可以說是非常的完整,但是整個看下來之后,發現自己對NIO還是一知半解、一臉蒙逼的狀態(請原諒我太笨)。 基于以上原因,就有了寫本文...  閱讀全文

          posted @ 2019-11-22 21:55 Jack Jiang 閱讀(627) | 評論 (0)編輯 收藏

               摘要: 1、引言如今我們所處的時代,是移動互聯網時代,也可以說是視頻時代。從快播到抖音,從“三生三世”到“延禧攻略”,我們的生活,被越來越多的視頻元素所影響。  而這一切,離不開視頻拍攝技術的不斷升級,還有視頻制作產業的日益強大。 此外,也離不開通信技術的飛速進步。試想一下,如果還是當年的56K Modem撥號,或者是2G手機,...  閱讀全文

          posted @ 2019-11-19 11:00 Jack Jiang 閱讀(698) | 評論 (0)編輯 收藏

               摘要: 本文引用了餓了么資深開發工程師萬汨“Redis 到底是怎么實現“附近的人”這個功能的呢?”一文的內容,感謝原作者的分享,為了提升文章品質,即時通訊收錄時有內容補充和修訂。1、引言基本上以陌生人社交為主的IM產品里,都會增加“附近的人”、“附近的xxx”這種以LBS(地理位置)為導向的產品特色(微信這個熟...  閱讀全文

          posted @ 2019-11-12 15:04 Jack Jiang 閱讀(509) | 評論 (0)編輯 收藏

          1、TCP協議到底怎么了?

          現時的互聯網應用中,Web平臺(準確地說是基于HTTP及其延伸協議的客戶端/服務器應用)的數據傳輸都基于 TCP 協議。

          但TCP 協議在創建連接之前需要進行三次握手(如下圖 1,更詳細原理請見《理論經典:TCP協議的3次握手與4次揮手過程詳解》),如果需要提高數據交互的安全性,既增加傳輸層安全協議(TLS),還會增加更多的更多握手次數(如下圖 2)。

           
          ▲ 圖 1 - TCP的三次握手原理圖
           
          ▲ 圖 2  - TLS的初始化握手原理圖

          正如上面兩張圖里演示的原理,TCP 協議連接建立的成本相對較高。

          所以,一般的穩定網絡傳輸都是通過TCP,但是在網絡基建本身就已經越來越完善的情況下,TCP設計本身的問題便暴露了出來,特別是在弱網環境下,讓我們不得不考慮一些新的可能性。

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

          2、QUIC協議登場

          和 TCP 相反,UDP 協議是無連接協議。客戶端發出 UDP 數據包后,只能“假設”這個數據包已經被服務端接收。這樣的好處是在網絡傳輸層無需對數據包進行確認,但存在的問題就是為了確保數據傳輸的可靠性,應用層協議需要自己完成包傳輸情況的確認。

          此時,QUIC 協議就登場了。

          QUIC 是 Quick UDP Internet Connections 的縮寫,谷歌發明的新傳輸協議。

          與 TCP 相比,QUIC 可以減少延遲。

          QUIC 協議可以在 1 到 2 個數據包(取決于連接的服務器是新的還是已知的)內,完成連接的創建(包括 TLS)(如下圖3所示)。

           

          ▲ 圖 3  - QUIC 協議握手原理圖

          從表面上看:QUIC 非常類似于在 UDP 上實現的 TCP + TLS + HTTP/2。由于 TCP 是在操作系統內核和中間件固件中實現的,因此對 TCP 進行重大更改幾乎是不可能的(TCP 協議棧通常由操作系統實現,如 Linux、Windows 內核或者其他移動設備操作系統。修改 TCP 協議是一項浩大的工程,因為每種設備、系統的實現都需要更新)。但是,由于 QUIC 建立在 UDP 之上,因此沒有這種限制。QUIC 可以實現可靠傳輸,而且相比于 TCP,它的流控功能在用戶空間而不在內核空間,那么使用者就不受限于 CUBIC 或是 BBR,而是可以自由選擇,甚至根據應用場景自由調整優化。

          QUIC 與現有 TCP + TLS + HTTP/2 方案相比,有以下幾點主要特征:

          1)利用緩存,顯著減少連接建立時間;

          2)改善擁塞控制,擁塞控制從內核空間到用戶空間;

          3)沒有 head of line 阻塞的多路復用;

          4)前向糾錯,減少重傳;

          5)連接平滑遷移,網絡狀態的變更不會影響連接斷線。

           

          從圖上可以看出,QUIC 底層通過 UDP 協議替代了 TCP,上層只需要一層用于和遠程服務器交互的 HTTP/2 API。這是因為 QUIC 協議已經包含了多路復用和連接管理,HTTP API 只需要完成 HTTP 協議的解析即可。

          有關QUIC的詳解請見:《技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》。

          3、QUIC協議的目標

          QUIC 協議的主要目的,是為了整合 TCP 協議的可靠性和 UDP 協議的速度和效率。

          一張圖看懂QUIC協議的優勢:

           

          對于 Google 來說優化 TCP 協議是一個長期目標,QUIC 旨在創建幾乎等同于 TCP 的獨立連接,但有著低延遲,并對類似 SPDY 的多路復用流協議有更好的支持。 如果 QUIC 協議的特性被證明是有效的,這些特性以后可能會被遷移入后續版本的 TCP 和 TLS 協議(它們都有很長的開發周期)。

          值得注意的是,雖然理論上來說,如果 QUIC 的特性被證明是有效的,這些特性以后可能會被遷移到后續版本的 TCP 協議中,但鑒于TCP協議長達幾十年在互聯網通信里的壟斷地位,以及這么多年積累下來的沉重歷史報復,想要根本性地優化或改進TCP協議,難度相當大(或許,有些事情,只能是想想而已,IPV6還喊了這么多年呢,不是一樣沒普及。。。)。

          4、QUIC協議這么好,可以大規模切換為QUIC嗎?

          理想和現實總是有一定的差距:雖然經過多年的推廣的應用,但QUIC協議目前仍未達到大量普及的階段,在 IETF上的QUIC 依然還是草稿,并且還存在Google QUIC與IETF QUIC兩類不穩定的協定。

          而且,QUIC還面臨以下挑戰:

          1)小地方,路由封殺UDP 443端口( 這正是QUIC 部署的端口);

          2)UDP包過多,由于QS限定,會被服務商誤認為是攻擊,UDP包被丟棄;

          3)無論是路由器還是防火墻目前對QUIC都還沒有做好準備。

          5、QUIC協議實踐

          Chrome 瀏覽器從 2014 年開始已經實驗性的支持了 QUIC 協議。可以通過在 Chrome 瀏覽器中輸入 chrome://net-internals/#quic 查看是否已經支持 QUIC 協議。如果還未支持,可以在 chrome://flags/#enable-quic 中進行開啟。

          開始 Chrome 瀏覽器對 QUIC 協議的支持之后,可以在 chrome://net-internals/#quic 中查看到當前瀏覽器的 QUIC 一些連接。當然目前只有 Google 服務才支持 QUIC 協議(如 YouTube、 Google.com)。

           

          Google 在 2015 年的一篇博文中分享了一些關于 QUIC 協議實現的結果,這些優勢在諸如 YouTube 的視頻服務上更為突出:用戶報告通過 QUIC 協議在觀看視頻的時候可以減少 30% 的重新緩沖時間。

          6、我想試試QUIC協議,可以怎么做?

          目前支持 QUIC 協議的 web 服務只有 0.9 版本以后的 Caddy 。其他常用 web 服務如 nginx、apache 等都未開始支持。

          整個 QUIC 協議比較復雜,想自己完全實現一套對筆者來說還比較困難。

          所以先看看開源實現有哪些。

          1)Chromium

          這個是官方支持的。優點自然很多,Google 官方維護基本沒有坑,隨時可以跟隨 chrome 更新到最新版本。不過編譯 Chromium 比較麻煩,它有單獨的一套編譯工具。暫時不建議考慮這個方案。

          2)proto-quic

          從 chromium 剝離的一個 QUIC 協議部分,但是其 github 主頁已宣布不再支持,僅作實驗使用。不建議考慮這個方案。

          3)goquic

          goquic 封裝了 libquic 的 go 語言封裝,而 libquic 也是從 chromium 剝離的,好幾年不維護了,僅支持到 quic-36, goquic 提供一個反向代理,測試發現由于 QUIC 版本太低,最新 chrome 瀏覽器已無法支持。不建議考慮這個方案。

          4)quic-go

          quic-go 是完全用 go 寫的 QUIC 協議棧,開發很活躍,已在 Caddy 中使用,MIT 許可,目前看是比較好的方案。

          那么,對于中小團隊或個人開發者來說,比較推薦的方案是最后一個,即采用 caddy 來部署實現 QUIC。caddy 這個項目本意并不是專門用來實現 QUIC 的,它是用來實現一個免簽的 HTTPS web 服務器的(caddy 會自動續簽證書)。而QUIC 只是它的一個附屬功能(不過現實是——好像用它來實現 QUIC 的人更多)。

          從Github的技術趨勢來說,有關QUIC的開源資源越來越多,有興趣可以自已逐一研究研究:https://github.com/search?q=quic

          7、本文小結

          QUIC 協議開創性的使用了 UDP 協議作為底層傳輸協議,通過各種方式減少了網絡延遲。

          雖然目前 QUIC 協議已經運行在一些較大的網站上,但離大范圍普及還有較長的一段距離,期待 QUIC 協議規范能夠成為終稿,并在除了谷歌瀏覽器之外的其他瀏覽器和應用服務器中也能夠實現。

          8、參考資料

          9、系列文章

          附錄:更多網絡編程相關資料推薦

          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技術之STUN、TURN、ICE詳解

          通俗易懂:快速理解P2P技術中的NAT穿透原理

          高性能網絡編程(一):單臺服務器并發TCP連接數到底可以有多少

          高性能網絡編程(二):上一個10年,著名的C10K并發連接問題

          高性能網絡編程(三):下一個10年,是時候考慮C10M并發問題了

          高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索

          高性能網絡編程(五):一文讀懂高性能網絡編程中的I/O模型

          高性能網絡編程(六):一文讀懂高性能網絡編程中的線程模型

          不為人知的網絡編程(一):淺析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轉換又是什么鬼?

          以網游服務端的網絡接入層設計為例,理解實時通信的技術挑戰

          邁向高階:優秀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請求嗎?

          知乎技術分享:知乎千萬級并發的高性能長連接網關技術實踐

          >> 更多同類文章 ……

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

          posted @ 2019-11-01 14:32 Jack Jiang 閱讀(1036) | 評論 (0)編輯 收藏

               摘要: 本文由ITPub根據封宇在【第十屆中國系統架構師大會(SACC2018)】現場演講內容整理而成。1、引言瓜子業務重線下,用戶網上看車、預約到店、成交等許多環節都發生在線下。瓜子IM智能客服系統的目的是要把這些線下的活動搬到線上,對線下行為進行追溯,積累相關數據。系統連接用戶、客服、電銷、銷售、AI機器人、業務后臺等多個角色及應用,覆蓋網上咨詢、瀏覽、預約看車、到店體驗、后服、投訴等眾多環節,各個角...  閱讀全文

          posted @ 2019-10-25 15:29 Jack Jiang 閱讀(150) | 評論 (0)編輯 收藏

               摘要: 1、引言 說道“心跳”這個詞大家都不陌生,當然不是指男女之間的心跳,而是和長連接相關的。顧名思義就是證明是否還活著的依據。 什么場景下需要心跳呢?目前我們接觸到的大多是一些基于長連接的應用需要心跳來“保活”。 由于在長連接的場景下,客戶端和服務端并不是一直處于通信狀態,如果雙方長期沒有溝通則雙方都不清楚對方目前的狀態,所以需要發送一段很小的...  閱讀全文

          posted @ 2019-10-22 10:48 Jack Jiang 閱讀(818) | 評論 (0)編輯 收藏

          僅列出標題
          共50頁: First 上一頁 31 32 33 34 35 36 37 38 39 下一頁 Last 
          Jack Jiang的 Mail: jb2011@163.com, 聯系QQ: 413980957, 微信: hellojackjiang
          主站蜘蛛池模板: 尚志市| 军事| 六安市| 大名县| 嘉黎县| 乌拉特中旗| 航空| 紫云| 托里县| 华阴市| 德化县| 赤峰市| 金昌市| 汉阴县| 海伦市| 方山县| 齐河县| 祁连县| 勃利县| 阳信县| 平武县| 板桥市| 水城县| 石嘴山市| 财经| 临洮县| 彰化市| 乃东县| 扶绥县| 湖南省| 宁远县| 讷河市| 台北县| 苍梧县| 富阳市| 崇文区| 英德市| 阳城县| 墨竹工卡县| 内黄县| 延长县|