本文引用了作者“大古同學”的“二維碼掃碼登錄是什么原理”一文的主要內容,為了更好的理解和閱讀,即時通訊網(wǎng)收錄時有修訂和改動,感謝原作者的分享。
本文引用了作者“大古同學”的“二維碼掃碼登錄是什么原理”一文的主要內容,為了更好的理解和閱讀,即時通訊網(wǎng)收錄時有修訂和改動,感謝原作者的分享。
1、引言
自從微信的PC端使用掃碼登陸認證邏輯后,這種方式似乎在越來越多的IM中看到(雖然我個人認為這種登錄方式很酷,但并不方便,尤其手機不大身邊的時候)。
▲ 上圖微信PC端的掃碼登錄界面最近剛好看到一個二維碼的技術原理講解視頻,正好借此機會將掃碼登錄的詳細技術原理梳理并總結一下,方便自已回顧,也希望能幫助到想在IM里開發(fā)類似功能的同行們。
補充說明:本文所涉及的掃碼登陸原理并不是僅僅針對IM系統(tǒng),同樣適用于IM之外的其它系統(tǒng)。
學習交流:
- 即時通訊/推送技術開發(fā)交流5群:215477170 [推薦]
- 移動端IM開發(fā)入門文章:《新手入門一篇就夠:從零開發(fā)移動端IM》
- 開源IM框架源碼:https://github.com/JackJiang2011/MobileIMSDK
(本文同步發(fā)布于:http://www.52im.net/thread-3525-1-1.html)
自從微信的PC端使用掃碼登陸認證邏輯后,這種方式似乎在越來越多的IM中看到(雖然我個人認為這種登錄方式很酷,但并不方便,尤其手機不大身邊的時候)。

最近剛好看到一個二維碼的技術原理講解視頻,正好借此機會將掃碼登錄的詳細技術原理梳理并總結一下,方便自已回顧,也希望能幫助到想在IM里開發(fā)類似功能的同行們。
補充說明:本文所涉及的掃碼登陸原理并不是僅僅針對IM系統(tǒng),同樣適用于IM之外的其它系統(tǒng)。
學習交流:
- 即時通訊/推送技術開發(fā)交流5群:215477170 [推薦]
- 移動端IM開發(fā)入門文章:《新手入門一篇就夠:從零開發(fā)移動端IM》
- 開源IM框架源碼:https://github.com/JackJiang2011/MobileIMSDK
(本文同步發(fā)布于:http://www.52im.net/thread-3525-1-1.html)
2、專題目錄
本文是系列文章的第3篇,總目錄如下:
《IM掃碼登錄技術專題(一):微信的掃碼登錄功能技術原理調試分析》
本文是系列文章的第3篇,總目錄如下:
《IM掃碼登錄技術專題(一):微信的掃碼登錄功能技術原理調試分析》
3、二維碼登錄的本質
3.1 掃碼登錄安全嗎?
在2維碼掃碼登錄的過程中,大家可能會有疑問:這二維碼安全嗎?會不會泄漏我的個人信息?我的im系統(tǒng)敢不敢也搞一個掃碼登錄呢?
針對這些顧慮,我們需要了解一下二維碼掃碼登錄背后的技術和邏輯本質。
在2維碼掃碼登錄的過程中,大家可能會有疑問:這二維碼安全嗎?會不會泄漏我的個人信息?我的im系統(tǒng)敢不敢也搞一個掃碼登錄呢?
針對這些顧慮,我們需要了解一下二維碼掃碼登錄背后的技術和邏輯本質。
3.2 掃碼登錄的技術本質
二維碼掃碼登錄本質上也是一種登錄認證方式。
既然是登錄認證,要做的也就兩件事情:
- 1)告訴系統(tǒng)我是誰;
- 2)向系統(tǒng)證明我是誰。
舉個實際的例子來理解一下:
- 比如賬號密碼登錄:賬號就是告訴系統(tǒng)我是誰, 密碼就是向系統(tǒng)證明我是誰;
- 比如手機驗證碼登錄:手機號就是告訴系統(tǒng)我是誰,驗證碼就是向系統(tǒng)證明我是誰。
那么掃碼登錄是怎么做到這兩件事情的呢?
以微作的掃碼登錄為例:手機端應用掃PC端二維碼,手機端確認后,賬號就在PC端登錄成功了!這里,PC端登錄的賬號肯定與手機端是同一個賬號。不可能手機端登錄的是賬號A,而掃碼登錄以后,PC端登錄的是賬號B。
所以,第一件事情——“告訴系統(tǒng)我是誰”,是比較清楚的!
PS:通過掃描二維碼,把手機端的賬號信息傳遞到PC端,至于具體是怎么傳的,我們后面再說。
第二件事情:“向系統(tǒng)證明我是誰”。掃碼登錄過程中,用戶并沒有去輸入密碼,也沒有輸入驗證碼,或者其他什么碼。那是怎么證明的呢?
有些同學會想到,是不是掃碼過程中,把密碼傳到了PC端呢?
但這是不可能的。因為那樣太不安全的,客戶端也根本不會去存儲密碼。
我們仔細想一下,其實手機端APP它是已經(jīng)登錄過的,就是說手機端是已經(jīng)通過登錄認證。所說只要掃碼確認是這個手機且是這個賬號操作的,其實就能間接證明我誰。
二維碼掃碼登錄本質上也是一種登錄認證方式。
既然是登錄認證,要做的也就兩件事情:
- 1)告訴系統(tǒng)我是誰;
- 2)向系統(tǒng)證明我是誰。
舉個實際的例子來理解一下:
- 比如賬號密碼登錄:賬號就是告訴系統(tǒng)我是誰, 密碼就是向系統(tǒng)證明我是誰;
- 比如手機驗證碼登錄:手機號就是告訴系統(tǒng)我是誰,驗證碼就是向系統(tǒng)證明我是誰。
那么掃碼登錄是怎么做到這兩件事情的呢?
以微作的掃碼登錄為例:手機端應用掃PC端二維碼,手機端確認后,賬號就在PC端登錄成功了!這里,PC端登錄的賬號肯定與手機端是同一個賬號。不可能手機端登錄的是賬號A,而掃碼登錄以后,PC端登錄的是賬號B。
所以,第一件事情——“告訴系統(tǒng)我是誰”,是比較清楚的!
PS:通過掃描二維碼,把手機端的賬號信息傳遞到PC端,至于具體是怎么傳的,我們后面再說。
第二件事情:“向系統(tǒng)證明我是誰”。掃碼登錄過程中,用戶并沒有去輸入密碼,也沒有輸入驗證碼,或者其他什么碼。那是怎么證明的呢?
有些同學會想到,是不是掃碼過程中,把密碼傳到了PC端呢?
但這是不可能的。因為那樣太不安全的,客戶端也根本不會去存儲密碼。
我們仔細想一下,其實手機端APP它是已經(jīng)登錄過的,就是說手機端是已經(jīng)通過登錄認證。所說只要掃碼確認是這個手機且是這個賬號操作的,其實就能間接證明我誰。
4、認識二維碼
那么如何做掃碼登陸的確認呢?我們后面會詳細說明,在這之前我們需要先認識一下二維碼! 在認識二維碼之前我們先看一下一維碼!

▲ 這就是一維碼
所謂一維碼,也就是條形碼,條形碼實際上就是一串數(shù)字,以平時生活中的商品為例,它上面的一維碼存儲的就是商品的編號。
二維碼其實與條形碼類似,只不過它存儲的不一定是數(shù)字,還可以是任何的字符串,你可以認為,它就是字符串的另外一種表現(xiàn)形式。
在搜索引擎中搜索二維碼,你可以找到很多在線生成二維碼的工具網(wǎng)站,這些網(wǎng)站可以提供字符串與二維碼之間相互轉換的功能,比如 草料二維碼網(wǎng)站。

▲ 輸入一段字符串就能生成二維碼
在左邊的輸入框就可以輸入你的內容,它可以是文本、網(wǎng)址,文件........。然后就可以生成代表它們的二維碼。

▲ 這是二維碼(已經(jīng)將內容模糊處理)
你也可以把二維碼上傳,進行”解碼“,然后就可以解析出二維碼代表的含義。
那么如何做掃碼登陸的確認呢?我們后面會詳細說明,在這之前我們需要先認識一下二維碼! 在認識二維碼之前我們先看一下一維碼!

▲ 這就是一維碼
所謂一維碼,也就是條形碼,條形碼實際上就是一串數(shù)字,以平時生活中的商品為例,它上面的一維碼存儲的就是商品的編號。
二維碼其實與條形碼類似,只不過它存儲的不一定是數(shù)字,還可以是任何的字符串,你可以認為,它就是字符串的另外一種表現(xiàn)形式。
在搜索引擎中搜索二維碼,你可以找到很多在線生成二維碼的工具網(wǎng)站,這些網(wǎng)站可以提供字符串與二維碼之間相互轉換的功能,比如 草料二維碼網(wǎng)站。

▲ 輸入一段字符串就能生成二維碼
在左邊的輸入框就可以輸入你的內容,它可以是文本、網(wǎng)址,文件........。然后就可以生成代表它們的二維碼。

▲ 這是二維碼(已經(jīng)將內容模糊處理)
你也可以把二維碼上傳,進行”解碼“,然后就可以解析出二維碼代表的含義。
5、傳統(tǒng)系統(tǒng)是如何登陸認證的?
認識了二維碼,我們了解一下移動互聯(lián)網(wǎng)下的傳統(tǒng)登錄認證機制。
前面我們說過,為了安全,手機端它是不會存儲你的登錄密碼的。 但是在日常使用過程中,我們應該會注意到,只有在你的應用下載下來后,第一次登錄的時候,才需要進行一個賬號密碼的登錄, 那之后呢 即使這個應用進程被殺掉,或者手機重啟,都是不需要再次輸入賬號密碼的,它可以自動登錄。
其實這背后就是一套基于token的認證機制,我們來看一下這套機制是怎么運行的。

如上圖所示:
- 1)賬號密碼登錄時,客戶端會將設備信息一起傳遞給服務端;
- 2)如果賬號密碼校驗通過,服務端會把賬號與設備進行一個綁定,存在一個數(shù)據(jù)結構中,這個數(shù)據(jù)結構中包含了賬號ID、設備ID、設備類型等等。
const token = {
acountid: '賬號ID',
deviceid: '登錄的設備ID',
deviceType: '設備類型,如 iso,android,pc......',
}
然后服務端會生成一個token,用它來映射數(shù)據(jù)結構,這個token其實就是一串有著特殊意義的字符串,它的意義就在于,通過它可以找到對應的賬號與設備信息。
具體是:
- 1)客戶端得到這個token后,需要進行一個本地保存,每次訪問系統(tǒng)API都攜帶上token與設備信息;
- 2)服務端就可以通過token找到與它綁定的賬號與設備信息,然后把綁定的設備信息與客戶端每次傳來的設備信息進行比較, 如果相同,那么校驗通過,返回AP接口響應數(shù)據(jù), 如果不同,那就是校驗不通過拒絕訪問。
從前面這個流程,我們可以看到,客戶端不會也沒必要保存你的密碼,相反,它是保存了token。
可能有些同學會想,這個token這么重要,萬一被別人知道了怎么辦。
實際上:知道了也沒有影響, 因為設備信息是唯一的,只要你的設備信息別人不知道, 別人拿其他設備來訪問,驗證也是不通過的。
可以說,客戶端登錄的目的,就是獲得屬于自己的token。
限于篇幅,這方面的文章,可以詳細讀一下以下幾篇:
《IM開發(fā)基礎知識補課(一):正確理解前置HTTP SSO單點登陸接口的原理》
那么在掃碼登錄過程中,PC端是怎么獲得屬于自己的token呢?不可能手機端直接把自己的token給PC端用!token只能屬于某個客戶端私有,其他人或者是其他客戶端是用不了的。
在分析這個問題之前,我們有必要先梳理一下,掃描二維碼登錄的一般步驟是什么樣的。這可以幫助我們梳理清楚整個過程。
認識了二維碼,我們了解一下移動互聯(lián)網(wǎng)下的傳統(tǒng)登錄認證機制。
前面我們說過,為了安全,手機端它是不會存儲你的登錄密碼的。 但是在日常使用過程中,我們應該會注意到,只有在你的應用下載下來后,第一次登錄的時候,才需要進行一個賬號密碼的登錄, 那之后呢 即使這個應用進程被殺掉,或者手機重啟,都是不需要再次輸入賬號密碼的,它可以自動登錄。
其實這背后就是一套基于token的認證機制,我們來看一下這套機制是怎么運行的。

如上圖所示:
- 1)賬號密碼登錄時,客戶端會將設備信息一起傳遞給服務端;
- 2)如果賬號密碼校驗通過,服務端會把賬號與設備進行一個綁定,存在一個數(shù)據(jù)結構中,這個數(shù)據(jù)結構中包含了賬號ID、設備ID、設備類型等等。
const token = {
acountid: '賬號ID',
deviceid: '登錄的設備ID',
deviceType: '設備類型,如 iso,android,pc......',
}
然后服務端會生成一個token,用它來映射數(shù)據(jù)結構,這個token其實就是一串有著特殊意義的字符串,它的意義就在于,通過它可以找到對應的賬號與設備信息。
具體是:
- 1)客戶端得到這個token后,需要進行一個本地保存,每次訪問系統(tǒng)API都攜帶上token與設備信息;
- 2)服務端就可以通過token找到與它綁定的賬號與設備信息,然后把綁定的設備信息與客戶端每次傳來的設備信息進行比較, 如果相同,那么校驗通過,返回AP接口響應數(shù)據(jù), 如果不同,那就是校驗不通過拒絕訪問。
從前面這個流程,我們可以看到,客戶端不會也沒必要保存你的密碼,相反,它是保存了token。
可能有些同學會想,這個token這么重要,萬一被別人知道了怎么辦。
實際上:知道了也沒有影響, 因為設備信息是唯一的,只要你的設備信息別人不知道, 別人拿其他設備來訪問,驗證也是不通過的。
可以說,客戶端登錄的目的,就是獲得屬于自己的token。
限于篇幅,這方面的文章,可以詳細讀一下以下幾篇:
《IM開發(fā)基礎知識補課(一):正確理解前置HTTP SSO單點登陸接口的原理》
那么在掃碼登錄過程中,PC端是怎么獲得屬于自己的token呢?不可能手機端直接把自己的token給PC端用!token只能屬于某個客戶端私有,其他人或者是其他客戶端是用不了的。
在分析這個問題之前,我們有必要先梳理一下,掃描二維碼登錄的一般步驟是什么樣的。這可以幫助我們梳理清楚整個過程。
6、掃碼登錄的詳細技術步驟
6.1 大概流程

如上圖所示:
- 1)掃碼前,手機端應用是已登錄狀態(tài),PC端顯示一個二維碼,等待掃描;
- 2)手機端打開應用,掃描PC端的二維碼,掃描后,會提示“已掃描,請在手機端點擊確認”;
- 3)用戶在手機端點擊確認,確認后PC端登錄就成功了。
可以看到,二維碼在中間有三個狀態(tài):待掃描、已掃描待確認、已確認。
那么可以想象:

具體解釋就是:
- 1)二維碼的背后它一定存在一個唯一性的ID,當二維碼生成時,這個ID也一起生成,并且綁定了PC端的設備信息;
- 2)手機去掃描這個二維碼;
- 3)二維碼切換為 已掃描待確認狀態(tài), 此時就會將賬號信息與這個ID綁定;
- 4)當手機端確認登錄時,它就會生成PC端用于登錄的token,并返回給PC端。
好了,到這里,基本思路就已經(jīng)清晰了,接下來我們把整個過程再具體化一下。

如上圖所示:
- 1)掃碼前,手機端應用是已登錄狀態(tài),PC端顯示一個二維碼,等待掃描;
- 2)手機端打開應用,掃描PC端的二維碼,掃描后,會提示“已掃描,請在手機端點擊確認”;
- 3)用戶在手機端點擊確認,確認后PC端登錄就成功了。
可以看到,二維碼在中間有三個狀態(tài):待掃描、已掃描待確認、已確認。
那么可以想象:

具體解釋就是:
- 1)二維碼的背后它一定存在一個唯一性的ID,當二維碼生成時,這個ID也一起生成,并且綁定了PC端的設備信息;
- 2)手機去掃描這個二維碼;
- 3)二維碼切換為 已掃描待確認狀態(tài), 此時就會將賬號信息與這個ID綁定;
- 4)當手機端確認登錄時,它就會生成PC端用于登錄的token,并返回給PC端。
好了,到這里,基本思路就已經(jīng)清晰了,接下來我們把整個過程再具體化一下。
6.2 二維碼準備
按二維碼不同狀態(tài)來看, 首先是等待掃描狀態(tài),用戶打開PC端,切換到二維碼登錄界面時。

如上圖所示:
- 1)PC端向服務端發(fā)起請求,告訴服務端,我要生成用戶登錄的二維碼,并且把PC端設備信息也傳遞給服務端;
- 2)服務端收到請求后,它生成二維碼ID,并將二維碼ID與PC端設備信息進行綁定;
- 3)然后把二維碼ID返回給PC端;
- 4)PC端收到二維碼ID后,生成二維碼(二維碼中肯定包含了ID);
- 5)為了及時知道二維碼的狀態(tài),客戶端在展現(xiàn)二維碼后,PC端不斷的輪詢服務端,比如每隔一秒就輪詢一次,請求服務端告訴當前二維碼的狀態(tài)及相關信息。
二維碼已經(jīng)準好了,接下來就是掃描狀態(tài)。
按二維碼不同狀態(tài)來看, 首先是等待掃描狀態(tài),用戶打開PC端,切換到二維碼登錄界面時。

如上圖所示:
- 1)PC端向服務端發(fā)起請求,告訴服務端,我要生成用戶登錄的二維碼,并且把PC端設備信息也傳遞給服務端;
- 2)服務端收到請求后,它生成二維碼ID,并將二維碼ID與PC端設備信息進行綁定;
- 3)然后把二維碼ID返回給PC端;
- 4)PC端收到二維碼ID后,生成二維碼(二維碼中肯定包含了ID);
- 5)為了及時知道二維碼的狀態(tài),客戶端在展現(xiàn)二維碼后,PC端不斷的輪詢服務端,比如每隔一秒就輪詢一次,請求服務端告訴當前二維碼的狀態(tài)及相關信息。
二維碼已經(jīng)準好了,接下來就是掃描狀態(tài)。
6.3 掃描狀態(tài)切換

如上圖所示:
- 1)用戶用手機去掃描PC端的二維碼,通過二維碼內容取到其中的二維碼ID;
- 2)再調用服務端API將移動端的身份信息與二維碼ID一起發(fā)送給服務端;
- 3)服務端接收到后,它可以將身份信息與二維碼ID進行綁定,生成臨時token。然后返回給手機端;
- 4)因為PC端一直在輪詢二維碼狀態(tài),所以這時候二維碼狀態(tài)發(fā)生了改變,它就可以在界面上把二維碼狀態(tài)更新為已掃描。
那么為什么需要返回給手機端一個臨時token呢?
臨時token與token一樣,它也是一種身份憑證,不同的地方在于它只能用一次,用過就失效。
在上圖中的第三步驟中返回臨時token,為的就是手機端在下一步操作時,可以用它作為憑證。以此確保掃碼,登錄兩步操作是同一部手機端發(fā)出的。

如上圖所示:
- 1)用戶用手機去掃描PC端的二維碼,通過二維碼內容取到其中的二維碼ID;
- 2)再調用服務端API將移動端的身份信息與二維碼ID一起發(fā)送給服務端;
- 3)服務端接收到后,它可以將身份信息與二維碼ID進行綁定,生成臨時token。然后返回給手機端;
- 4)因為PC端一直在輪詢二維碼狀態(tài),所以這時候二維碼狀態(tài)發(fā)生了改變,它就可以在界面上把二維碼狀態(tài)更新為已掃描。
那么為什么需要返回給手機端一個臨時token呢?
臨時token與token一樣,它也是一種身份憑證,不同的地方在于它只能用一次,用過就失效。
在上圖中的第三步驟中返回臨時token,為的就是手機端在下一步操作時,可以用它作為憑證。以此確保掃碼,登錄兩步操作是同一部手機端發(fā)出的。
6.4 狀態(tài)確認
最后就是狀態(tài)的確認了。

如上圖所示:
- 1)手機端在接收到臨時token后會彈出確認登錄界面,用戶點擊確認時,手機端攜帶臨時token用來調用服務端的接口,告訴服務端,我已經(jīng)確認;
- 2)服務端收到確認后,根據(jù)二維碼ID綁定的設備信息與賬號信息,生成用戶PC端登錄的token;
- 3)這時候PC端的輪詢接口,它就可以得知二維碼的狀態(tài)已經(jīng)變成了"已確認"。并且從服務端可以獲取到用戶登錄的token;
- 4)到這里,登錄就成功了,后端PC端就可以用token去訪問服務端的資源了。
掃碼動作的基礎流程都講完了,有些細節(jié)還沒有深入介紹。
比如二維碼的內容是什么?
- 1)可以是二維碼ID;
- 2)可以是包含二維碼ID的一個url地址。
在掃碼確認這一步,用戶取消了怎么處理? 這些細節(jié)都留給大家思考。
最后就是狀態(tài)的確認了。

如上圖所示:
- 1)手機端在接收到臨時token后會彈出確認登錄界面,用戶點擊確認時,手機端攜帶臨時token用來調用服務端的接口,告訴服務端,我已經(jīng)確認;
- 2)服務端收到確認后,根據(jù)二維碼ID綁定的設備信息與賬號信息,生成用戶PC端登錄的token;
- 3)這時候PC端的輪詢接口,它就可以得知二維碼的狀態(tài)已經(jīng)變成了"已確認"。并且從服務端可以獲取到用戶登錄的token;
- 4)到這里,登錄就成功了,后端PC端就可以用token去訪問服務端的資源了。
掃碼動作的基礎流程都講完了,有些細節(jié)還沒有深入介紹。
比如二維碼的內容是什么?
- 1)可以是二維碼ID;
- 2)可以是包含二維碼ID的一個url地址。
在掃碼確認這一步,用戶取消了怎么處理? 這些細節(jié)都留給大家思考。
7、本文小結
通俗地總結一下本文的掃碼登陸邏輯就是:

掃碼登錄的本質就是:
- 1)告訴系統(tǒng)我是誰;
- 2)向系統(tǒng)證明我誰。
在這個過程中,我們先簡單講了兩個前提知識:
- 1)一個是二維碼原理;
- 2)一個是基于token的認證機制。
然后我們以二維碼狀態(tài)為軸,分析了這背后的邏輯: 通過token認證機制與二維碼狀態(tài)變化來實現(xiàn)掃碼登錄。
需要指出的是,前面的講的登錄流程,它適同樣用于同一個系統(tǒng)的PC端,WEB端,移動端。
平時我們還有另外一種場景也比較常見,那就是通過第三方應用來掃碼登錄,比如極客時間/掘金 都可以選擇微信/QQ等掃碼登錄,那么這種通過第三方應用掃碼登錄又是什么原理呢?
感興趣的同學可以思考研究一下,歡迎在評論留下你的見解。
通俗地總結一下本文的掃碼登陸邏輯就是:

掃碼登錄的本質就是:
- 1)告訴系統(tǒng)我是誰;
- 2)向系統(tǒng)證明我誰。
在這個過程中,我們先簡單講了兩個前提知識:
- 1)一個是二維碼原理;
- 2)一個是基于token的認證機制。
然后我們以二維碼狀態(tài)為軸,分析了這背后的邏輯: 通過token認證機制與二維碼狀態(tài)變化來實現(xiàn)掃碼登錄。
需要指出的是,前面的講的登錄流程,它適同樣用于同一個系統(tǒng)的PC端,WEB端,移動端。
平時我們還有另外一種場景也比較常見,那就是通過第三方應用來掃碼登錄,比如極客時間/掘金 都可以選擇微信/QQ等掃碼登錄,那么這種通過第三方應用掃碼登錄又是什么原理呢?
感興趣的同學可以思考研究一下,歡迎在評論留下你的見解。
附錄:更多IM開發(fā)熱門知識
《移動端IM開發(fā)者必讀(一):通俗易懂,理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二):史上最全移動弱網(wǎng)絡優(yōu)化方法總結》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結:請求速度、弱網(wǎng)適應、安全保障》
《騰訊技術分享:社交網(wǎng)絡圖片的帶寬壓縮技術演進之路》
《小白必讀:閑話HTTP短連接中的Session和Token》
《IM開發(fā)基礎知識補課:正確理解前置HTTP SSO單點登錄接口的原理》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性?》
《開發(fā)IM是自己設計協(xié)議用字節(jié)流好還是字符流好?》
《IM消息送達保證機制實現(xiàn)(一):保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(xiàn)(二):保證離線消息的可靠投遞》
《IM單聊和群聊中的在線狀態(tài)同步應該用“推”還是“拉”?》
《談談移動端 IM 開發(fā)中登錄請求的優(yōu)化》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量?》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀:一場有始無終的開源秀》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)》
《騰訊原創(chuàng)分享(一):如何大幅提升移動網(wǎng)絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二):如何大幅壓縮移動網(wǎng)絡下APP的流量消耗(上篇)》
《騰訊原創(chuàng)分享(三):如何大幅壓縮移動網(wǎng)絡下APP的流量消耗(下篇)》
《如約而至:微信自用的移動端IM網(wǎng)絡層跨平臺組件庫Mars已正式開源》
《基于社交網(wǎng)絡的Yelp是如何實現(xiàn)海量用戶圖片的無損壓縮的?》
《騰訊技術分享:騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(圖片壓縮篇)》
《騰訊技術分享:騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(音視頻技術篇)》
《字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移動端主流圖片格式的特點、性能、調優(yōu)等》
《子彈短信光鮮的背后:網(wǎng)易云信首席架構師分享億級IM平臺的技術實踐》
《IM開發(fā)基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列》
《微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)》
《自已開發(fā)IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)》
《IM開發(fā)基礎知識補課(六):數(shù)據(jù)庫用NoSQL還是SQL?讀這篇就夠了!》
《適合新手:從零開發(fā)一個IM服務端(基于Netty,有完整源碼)》
《拿起鍵盤就是干:跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》
《適合新手:手把手教你用Go快速搭建高性能、可擴展的IM系統(tǒng)(有源碼)》
《IM里“附近的人”功能實現(xiàn)原理是什么?如何高效率地實現(xiàn)它?》
《IM開發(fā)基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路》
《IM開發(fā)基礎知識補課(八):史上最通俗,徹底搞懂字符亂碼問題的本質》
《IM“掃一掃”功能很好做?看看微信“掃一掃識物”的完整技術實現(xiàn)》
《IM的掃碼登錄功能如何實現(xiàn)?一文搞懂主流應用的掃碼登錄技術原理》
《IM消息ID技術專題(一):微信的海量IM聊天消息序列號生成實踐(算法原理篇)》
《IM消息ID技術專題(二):微信的海量IM聊天消息序列號生成實踐(容災方案篇)》
《IM消息ID技術專題(三):解密融云IM產品的聊天消息ID生成策略》
《IM消息ID技術專題(四):深度解密美團的分布式ID生成算法》
《IM消息ID技術專題(五):開源分布式ID生成器UidGenerator的技術實現(xiàn)》
《IM消息ID技術專題(六):深度解密滴滴的高性能ID生成器(Tinyid)》
《IM開發(fā)寶典:史上最全,微信各種功能參數(shù)和邏輯規(guī)則資料匯總》
《IM開發(fā)干貨分享:我是如何解決大量離線消息導致客戶端卡頓的》
《零基礎IM開發(fā)入門(一):什么是IM系統(tǒng)?》
《零基礎IM開發(fā)入門(二):什么是IM系統(tǒng)的實時性?》
《零基礎IM開發(fā)入門(三):什么是IM系統(tǒng)的可靠性?》
《零基礎IM開發(fā)入門(四):什么是IM系統(tǒng)的消息時序一致性?》
《IM開發(fā)干貨分享:如何優(yōu)雅的實現(xiàn)大量離線消息的可靠投遞》
《IM開發(fā)干貨分享:有贊移動端IM的組件化SDK架構設計實踐》
《一套億級用戶的IM架構技術干貨(下篇):可靠性、有序性、弱網(wǎng)優(yōu)化等》
>> 更多同類文章 ……
本文已同步發(fā)布于“即時通訊技術圈”公眾號。

▲ 本文在公眾號上的鏈接是:點此進入。同步發(fā)布鏈接是:http://www.52im.net/thread-3525-1-1.html
《移動端IM開發(fā)者必讀(一):通俗易懂,理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二):史上最全移動弱網(wǎng)絡優(yōu)化方法總結》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結:請求速度、弱網(wǎng)適應、安全保障》
《騰訊技術分享:社交網(wǎng)絡圖片的帶寬壓縮技術演進之路》
《小白必讀:閑話HTTP短連接中的Session和Token》
《IM開發(fā)基礎知識補課:正確理解前置HTTP SSO單點登錄接口的原理》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性?》
《開發(fā)IM是自己設計協(xié)議用字節(jié)流好還是字符流好?》
《IM消息送達保證機制實現(xiàn)(一):保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(xiàn)(二):保證離線消息的可靠投遞》
《IM單聊和群聊中的在線狀態(tài)同步應該用“推”還是“拉”?》
《談談移動端 IM 開發(fā)中登錄請求的優(yōu)化》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量?》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀:一場有始無終的開源秀》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》
《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)》
《騰訊原創(chuàng)分享(一):如何大幅提升移動網(wǎng)絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二):如何大幅壓縮移動網(wǎng)絡下APP的流量消耗(上篇)》
《騰訊原創(chuàng)分享(三):如何大幅壓縮移動網(wǎng)絡下APP的流量消耗(下篇)》
《如約而至:微信自用的移動端IM網(wǎng)絡層跨平臺組件庫Mars已正式開源》
《基于社交網(wǎng)絡的Yelp是如何實現(xiàn)海量用戶圖片的無損壓縮的?》
《騰訊技術分享:騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(圖片壓縮篇)》
《騰訊技術分享:騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(音視頻技術篇)》
《字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移動端主流圖片格式的特點、性能、調優(yōu)等》
《子彈短信光鮮的背后:網(wǎng)易云信首席架構師分享億級IM平臺的技術實踐》
《IM開發(fā)基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列》
《微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)》
《自已開發(fā)IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)》
《IM開發(fā)基礎知識補課(六):數(shù)據(jù)庫用NoSQL還是SQL?讀這篇就夠了!》
《適合新手:從零開發(fā)一個IM服務端(基于Netty,有完整源碼)》
《拿起鍵盤就是干:跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》
《適合新手:手把手教你用Go快速搭建高性能、可擴展的IM系統(tǒng)(有源碼)》
《IM里“附近的人”功能實現(xiàn)原理是什么?如何高效率地實現(xiàn)它?》
《IM開發(fā)基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路》
《IM開發(fā)基礎知識補課(八):史上最通俗,徹底搞懂字符亂碼問題的本質》
《IM“掃一掃”功能很好做?看看微信“掃一掃識物”的完整技術實現(xiàn)》
《IM的掃碼登錄功能如何實現(xiàn)?一文搞懂主流應用的掃碼登錄技術原理》
《IM消息ID技術專題(一):微信的海量IM聊天消息序列號生成實踐(算法原理篇)》
《IM消息ID技術專題(二):微信的海量IM聊天消息序列號生成實踐(容災方案篇)》
《IM消息ID技術專題(三):解密融云IM產品的聊天消息ID生成策略》
《IM消息ID技術專題(四):深度解密美團的分布式ID生成算法》
《IM消息ID技術專題(五):開源分布式ID生成器UidGenerator的技術實現(xiàn)》
《IM消息ID技術專題(六):深度解密滴滴的高性能ID生成器(Tinyid)》
《IM開發(fā)寶典:史上最全,微信各種功能參數(shù)和邏輯規(guī)則資料匯總》
《IM開發(fā)干貨分享:我是如何解決大量離線消息導致客戶端卡頓的》
《零基礎IM開發(fā)入門(一):什么是IM系統(tǒng)?》
《零基礎IM開發(fā)入門(二):什么是IM系統(tǒng)的實時性?》
《零基礎IM開發(fā)入門(三):什么是IM系統(tǒng)的可靠性?》
《零基礎IM開發(fā)入門(四):什么是IM系統(tǒng)的消息時序一致性?》
《IM開發(fā)干貨分享:如何優(yōu)雅的實現(xiàn)大量離線消息的可靠投遞》
《IM開發(fā)干貨分享:有贊移動端IM的組件化SDK架構設計實踐》
《一套億級用戶的IM架構技術干貨(下篇):可靠性、有序性、弱網(wǎng)優(yōu)化等》
>> 更多同類文章 ……
本文已同步發(fā)布于“即時通訊技術圈”公眾號。
▲ 本文在公眾號上的鏈接是:點此進入。同步發(fā)布鏈接是:http://www.52im.net/thread-3525-1-1.html
作者:Jack Jiang (點擊作者姓名進入Github)
出處:http://www.52im.net/space-uid-1.html
交流:歡迎加入即時通訊開發(fā)交流群 215891622
討論:http://www.52im.net/
Jack Jiang同時是【原創(chuàng)Java
Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
本博文
歡迎轉載,轉載請注明出處(也可前往 我的52im.net 找到我)。