史上最強Android保活思路：深入剖析騰訊TIM的進程永生技術

摘要: 1、引言隨著Android系統的不斷升級，即時通訊網技術群和社區里的IM和推送開發的程序員們，對于進程保活這件事是越來越悲觀，必竟系統對各種保活黑科技的限制越來越多了，想超越系統的摯肘，難度越來越大。但保活這件事就像“激情”之后的余味，總是讓人欲罷不能，想放棄又不甘心。那么，除了像上篇《2020年了，Android后臺保活還有戲嗎？看我如何優雅的實現！》這樣的正經白名單方式... 閱讀全文

posted @ 2020-01-14 14:33 Jack Jiang 閱讀(253) | 評論 (0) | 編輯收藏

IM的掃碼登錄功能如何實現？一文搞懂主流的掃碼登錄技術原理

摘要: 1、引言掃碼登錄這個功能，最早應該是微信的PC端開始搞，雖然有點反人類的功能（不掃碼也沒別的方式登錄），但不得不說還是很酷的。下面這張圖，不管是IM開發者還是普通用戶，應該很熟悉：于是，搞IM產品的老板和產品經理們，從此又多了一個要拋給程序員們的需求——“為什么微信有掃一掃登錄，而我們的沒有？”。好吧，每次只要是微信有的功能，IM程序員們... 閱讀全文

posted @ 2020-01-08 13:39 Jack Jiang 閱讀(129) | 評論 (0) | 編輯收藏

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

摘要: 本文由騰訊WXG應用研究員breezecheng原創發表于公眾號“騰訊技術工程”，原題“微信「掃一掃識物」的背后技術揭秘”。一、引言現在市面上主流的移動端IM應用于都有“掃一掃”功能，看起來好像也就能掃一掃加好友、加群，但實際上作為一個IM產品的重要信息入口，“掃一掃”功能也可以很強大。▲... 閱讀全文

posted @ 2020-01-02 20:54 Jack Jiang 閱讀(211) | 評論 (0) | 編輯收藏

2020年了，Android后臺保活還有戲嗎？看我如何優雅的實現！

1、引言

對于移動端IM應用和消息推送應用的開發者來說，Android后臺保活這件事是再熟悉不過了。

自從Android P（即Android 8.0）出現以后，Android已經從系統層面將后臺保活這條路給堵死了（詳見：《Android P正式版即將到來：后臺應用保活、消息推送的真正噩夢》），曾今那些層出不窮的保活黑科技能用的也越來越少了（詳見：《全面盤點當前Android后臺保活方案的真實運行效果（截止2019年前）》。雖然可以自已對接廠商的ROOM級推送通道，但一方面各廠商的推送接口都不一樣（而且同一廠商不同的系統版本間也存在推送接口的兼容性問題），很不方便。另一方面要一家家引入各自的推送服務SDK包會讓APP變的很大，這讓APP的下載變的很不友好。

總之，Android應用的后臺保活在某些場景下，還是有持續的需求。除了之前那些耳熟能詳的保活黑科技以外，在Android 9.0（甚至Android 10）時代，我們還有哪些保活方法可以用？那么，請跟著本文作者的思路，看看更優雅的后臺保活實現方法吧。

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

2、關于作者

網名NanBox：畢業于華中科技大學，現為"悅跑圈APP”高級Android開發工程師。主要負責公司 Android 項目，核心模塊的開發。涉及 GPS 定位、地圖、圖片編輯等功能。獨立開發了手表應用項目。在項目中應入了 Flutter 跨平臺開發技術，實現了原生和 Flutter 的混合開發。

本文作者樂于分享，平時會寫技術文章并分享在多個平臺，是掘金專欄作者的一員，文章總閱讀量超過 10 萬。在 GitHub 上有多個開源項目，多次在團隊內部進行技術分享。是 Android 和 Flutter 官方中文文檔譯者。

3、相關文章

如果你想詳細了解目前Android平臺上后臺保活技術的挑戰，請閱讀：

《Android P正式版即將到來：后臺應用保活、消息推送的真正噩夢》。

如果你想回顧那些曾今出現的Android保活黑科技，以下文章值得好好讀讀：

《全面盤點當前Android后臺保活方案的真實運行效果（截止2019年前）》
《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》
《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》
《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》
《Android進程保活詳解：一篇文章解決你的所有疑問》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《深入的聊聊Android消息推送這件小事》
《為何基于TCP協議的移動端IM仍然需要心跳保活機制？》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《融云技術分享：融云安卓端IM產品的網絡鏈路保活技術實踐》

4、Android保活現狀

我們知道，Android 系統會存在殺后臺進程的情況，并且隨著系統版本的更新，殺進程的力度還有越來越大的趨勢（見：《Android P正式版即將到來：后臺應用保活、消息推送的真正噩夢》）。

系統這種做法本身出發點是好的，因為可以節省內存，降低功耗，也避免了一些流氓行為。

但有一部分應用，應用本身的使用場景就需要在后臺運行，用戶也是愿意讓它在后臺運行的，比如跑步類應用、一些懶得對接廠商推送通道的IM應用、消息推送資訊類應用等。

一方面流氓軟件用各種流氓手段進行保活，另一方面系統加大殺后臺的力度，導致我們一些真正需要在后臺運行的應用被誤殺，苦不堪言。

5、優雅的保活？

為了做到保活，出現了不少「黑科技」，比如 1 個像素的 Activity，播放無聲音頻，雙進程互相守護等（可以讀讀這個系列：《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》、《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》、《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》）。

這些做法可以說是很流氓了，甚至破壞了 Android 的生態，好在隨著 Android 系統版本的更新，這些非常規的保活手段很多都已失效了。

對于那些確實需要在后臺運行的應用，我們如何做到優雅的保活呢？

6、加入后臺運行白名單，可以優雅的實現保活

從 Android 6.0 開始，系統為了省電增加了休眠模式，系統待機一段時間后，會殺死后臺正在運行的進程。但系統會有一個后臺運行白名單，白名單里的應用將不會受到影響，在原生系統下，通過：「設置」 - 「電池」 - 「電池優化」 - 「未優化應用」，可以看到這個白名單。

通常會看到下面這兩位：

下次被產品說「 XXX 都可以保活，為什么我們不行！」的時候，你就知道怎么懟回去了。大廠通過和手機廠商的合作，將自己的應用默認加入到白名單中。如果你在一個能談成這種合作的大廠，也就不用往下看了。

好在系統還沒有拋棄我們，允許我們申請把應用加入白名單。

首先，在 AndroidManifest.xml 文件中配置一下權限：

<uses-permissionandroid:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

可以通過以下方法，判斷我們的應用是否在白名單中：

@RequiresApi(api = Build.VERSION_CODES.M)
private boolean isIgnoringBatteryOptimizations() {
    boolean isIgnoring = false;
    PowerManager powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);
    if(powerManager != null) {
        isIgnoring = powerManager.isIgnoringBatteryOptimizations(getPackageName());
    }
    return isIgnoring;
}

如果不在白名單中，可以通過以下代碼申請加入白名單：

@RequiresApi(api = Build.VERSION_CODES.M)
public void requestIgnoreBatteryOptimizations() {
    try{
        Intent intent = newIntent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
        intent.setData(Uri.parse("package:"+ getPackageName()));
        startActivity(intent);
    } catch(Exception e) {
        e.printStackTrace();
    }
}

申請時，應用上會出現這樣一個窗口：

可以看到，這個系統彈窗會有影響電池續航的提醒，所以如果想讓用戶點允許，必須要有相關的說明。如果要判斷用戶是否點擊了允許，可以在申請的時候調用 startActivityForResult，在 onActivityResult 里再判斷一次是否在白名單中。

7、加入后臺運行白名單的多廠商適配方法

7.1 基本說明

Android 開發的一個難點在于，各大手機廠商對原生系統進行了不同的定制，導致我們需要進行不同的適配，后臺管理就是一個很好的體現。幾乎各個廠商都有自己的后臺管理，就算應用加入了后臺運行白名單，仍然可能會被廠商自己的后臺管理干掉。

如果能把應用加入廠商系統的后臺管理白名單，可以進一步降低進程被殺的概率。不同的廠商在不同的地方進行設置，一般是在各自的「手機管家」，但更難的是，就算同一個廠商的系統，不同的版本也可能是在不同地方設置。

最理想的做法是，我們根據不同手機，甚至是不同的系統版本，給用戶呈現一個圖文操作步驟，并且提供一個按鈕，直接跳轉到指定頁面進行設置。但需要對每個廠商每個版本進行適配，工作量是比較大的。我使用真機測試了大部分主流 Android 廠商的手機后，整理出了部分手機的相關資料。

首先我們可以定義這樣兩個方法：

/**
* 跳轉到指定應用的首頁
*/
private void showActivity(@NonNull String packageName) {
    Intent intent = getPackageManager().getLaunchIntentForPackage(packageName);
    startActivity(intent);
}

/**
* 跳轉到指定應用的指定頁面
*/
private void showActivity(@NonNull String packageName, @NonNull String activityDir) {
    Intent intent = new Intent();
    intent.setComponent(newComponentName(packageName, activityDir));
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);
}

以下是部分手機的廠商判斷，跳轉方法及對應設置步驟，跳轉方法不保證在所有版本上都能成功跳轉，都需要加 try catch。

7.2 華為

廠商判斷：

public boolean isHuawei() {
    if(Build.BRAND == null) {
        return false;
    } else{
        return Build.BRAND.toLowerCase().equals("huawei") || Build.BRAND.toLowerCase().equals("honor");
    }
}

跳轉華為手機管家的啟動管理頁：

private void goHuaweiSetting() {
    try{
        showActivity("com.huawei.systemmanager",
            "com.huawei.systemmanager.startupmgr.ui.StartupNormalAppListActivity");
    } catch(Exception e) {
        showActivity("com.huawei.systemmanager",
            "com.huawei.systemmanager.optimize.bootstart.BootStartActivity");
    }
}

操作步驟：應用啟動管理 -> 關閉應用開關 -> 打開允許自啟動。

7.3 小米

廠商判斷：

public static boolean isXiaomi() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("xiaomi");
}

跳轉小米安全中心的自啟動管理頁面：

private void goXiaomiSetting() {
showActivity("com.miui.securitycenter",
"com.miui.permcenter.autostart.AutoStartManagementActivity");
}

操作步驟：授權管理 -> 自啟動管理 -> 允許應用自啟動。

7.4 OPPO

廠商判斷：

public static boolean isOPPO() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("oppo");
}

跳轉 OPPO 手機管家：

private void goOPPOSetting() {
    try{
        showActivity("com.coloros.phonemanager");
    } catch(Exception e1) {
        try{
            showActivity("com.oppo.safe");
        } catch(Exception e2) {
            try{
                showActivity("com.coloros.oppoguardelf");
            } catch(Exception e3) {
                showActivity("com.coloros.safecenter");
            }
        }
    }
}

操作步驟：權限隱私 -> 自啟動管理 -> 允許應用自啟動。

7.5 VIVO

廠商判斷：

public static boolean isVIVO() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("vivo");
}

跳轉 VIVO 手機管家：

private void goVIVOSetting() {
showActivity("com.iqoo.secure");
}

操作步驟：權限管理 -> 自啟動 -> 允許應用自啟動。

7.6 魅族

廠商判斷：

public static boolean isMeizu() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("meizu");
}

跳轉魅族手機管家：

private void goMeizuSetting() {
showActivity("com.meizu.safe");
}

操作步驟：權限管理 -> 后臺管理 -> 點擊應用 -> 允許后臺運行。

7.7 三星

廠商判斷：

public static boolean isSamsung() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("samsung");
}

跳轉三星智能管理器：

private void goSamsungSetting() {
    try{
        showActivity("com.samsung.android.sm_cn");
    } catch(Exception e) {
        showActivity("com.samsung.android.sm");
    }
}

操作步驟：自動運行應用程序 -> 打開應用開關 -> 電池管理 -> 未監視的應用程序 -> 添加應用。

7.8 樂視

廠商判斷：

public static boolean isLeTV() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("letv");
}

跳轉樂視手機管家：

private void goLetvSetting() {
showActivity("com.letv.android.letvsafe",
"com.letv.android.letvsafe.AutobootManageActivity");
}

操作步驟：自啟動管理 -> 允許應用自啟動。

7.9 錘子

廠商判斷：

public static boolean isSmartisan() {
return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("smartisan");
}

跳轉手機管理：

private void goSmartisanSetting() {
showActivity("com.smartisanos.security");
}

操作步驟：權限管理 -> 自啟動權限管理 -> 點擊應用 -> 允許被系統啟動。

8、友商致敬？

在之前做的跑步應用中，我在設置里增加了一個權限設置頁面，將上面提到的設置放在這里面。

最近發現友商某咚也跟進了，圖 1 是我們做的，圖 2 是某咚做的：

某咚從設計、從我寫的不夠好的文案，甚至是我從十幾臺手機上一張一張截下來的圖，進行了全方位的致敬。感謝某咚的認可，但最近在某個發布會上聽到這么一句話：在致敬的同時，能不能說一句謝謝？

某咚的致敬，一方面說明了目前確實存在進程容易被殺，保活難度大的問題，另一方面也說明了這種引導用戶進行白名單設置的手段是有效的。

附錄：更多相關技術文章

《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》
《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》
《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》
《Android進程保活詳解：一篇文章解決你的所有疑問》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《深入的聊聊Android消息推送這件小事》
《為何基于TCP協議的移動端IM仍然需要心跳保活機制？》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《Android P正式版即將到來：后臺應用保活、消息推送的真正噩夢》
《全面盤點當前Android后臺保活方案的真實運行效果（截止2019年前）》
《一文讀懂即時通訊應用中的網絡心跳包機制：作用、原理、實現思路等》
《融云技術分享：融云安卓端IM產品的網絡鏈路保活技術實踐》
《正確理解IM長連接的心跳及重連機制，并動手實現（有完整IM源碼）》
《2020年了，Android后臺保活還有戲嗎？看我如何優雅的實現！》
>> 更多同類文章 ……

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

posted @ 2019-12-27 14:51 Jack Jiang 閱讀(425) | 評論 (0) | 編輯收藏

P2P技術詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進階分析篇)

摘要: 原作者：黃日成，手Q游戲中心后臺開發，騰訊高級工程師。從事C++服務后臺開發4年多，主要負責手Q游戲中心后臺基礎系統、復雜業務系統開發，主導過手Q游戲公會、企鵝電競App-對戰系統等項目的后臺系統設計，有豐富的后臺架構經驗。1、引言接本系列的上一篇《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》，本篇將深入分析各種NAT穿越(打洞)方案的技術實現原理和數據交互過程，希望... 閱讀全文

posted @ 2019-12-24 11:25 Jack Jiang 閱讀(301) | 評論 (0) | 編輯收藏

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

摘要: 1、引言歲月真是個養豬場，這幾年，人胖了，微信代碼也翻了。記得 14 年轉崗來微信時，用自己筆記本編譯微信工程才十來分鐘。如今用公司配的 17 年款 27-inch iMac 編譯要接近半小時；偶然間更新完代碼，又莫名其妙需要全新編譯。在這么低的編譯效率下，開發心情受到嚴重影響。于是年初我向上頭請示，優化微信編譯效率，上頭也同意了。學習交流：- 即時通訊/推送技術開發交流5... 閱讀全文

posted @ 2019-12-19 20:22 Jack Jiang 閱讀(149) | 評論 (0) | 編輯收藏

史上最通俗，徹底搞懂字符亂碼問題的本質

摘要: 1、引言IM等社交應用的開發工作中，亂碼問題也很常見，比如:1）IM聊天消息中的Emoji表情為什么發給后端后MySQL數據庫里會亂碼；2）文件名中帶有中文的大文件聊天消息發送后，對方看到的文名是亂碼；3）Http rest接口調用時，后端讀取到APP端傳過來的參數有中文亂碼問題；... ...那么，對于亂碼這個看似不起眼，但并不是一兩話能講清楚的問題，是很有必要從根源了解字符集和編碼原理，知其然... 閱讀全文

posted @ 2019-12-17 19:36 Jack Jiang 閱讀(184) | 評論 (0) | 編輯收藏

你知道，HTTPS用的是對稱加密還是非對稱加密？

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 閱讀(178) | 評論 (0) | 編輯收藏

IM開發基礎知識補課(七)：主流移動端賬號登錄方式的原理及設計思路

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 閱讀(144) | 評論 (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 閱讀(346) | 評論 (0) | 編輯收藏

僅列出標題

導航

公告

常用鏈接

留言簿(292)

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜

60天內閱讀排行

1、引言

2、關于作者

3、相關文章

4、Android保活現狀

5、優雅的保活？

6、加入后臺運行白名單，可以優雅的實現保活

7、加入后臺運行白名單的多廠商適配方法

7.1 基本說明

7.2 華為

7.3 小米

7.4 OPPO

7.5 VIVO

7.6 魅族

7.7 三星

7.8 樂視

7.9 錘子

8、友商致敬？

附錄：更多相關技術文章

1、引言

2、相關文章

3、HTTPS靈魂拷問

4、HTTPS 的實現原理

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

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

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

7.1 證書包含什么信息？

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

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

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

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

9、用了 HTTPS 會被抓包嗎？

10、本文小結

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

1、引言

2、IM開發干貨系列文章

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

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

4.1 基本原理

4.2 具體的數據庫設計

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

5.1 基本原理

5.2 具體的數據庫設計

6、本文小結

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

1、引言

2、關于作者

3、系列文章

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

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

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

6.1 物理層

6.2 數據鏈路層

6.3 網絡層

6.4 傳輸層

6.5 應用層協議

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

7.1 物理層

7.2 數據鏈路層

7.3 網絡層

7.4 傳輸層

7.5 應用層

8、寫在最后

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