深刻探索 Android 網絡優化（2、網絡優化基礎篇）下

時間 2020-05-31

原文原文鏈接

前言

成爲一名優秀的Android開發，須要一份完備的知識體系，在這裏，讓咱們一塊兒成長爲本身所想的那樣~。

8、移動網絡

用 2G 看 txt，用 3G 看 jpg，用 4G 看 avi。html

一、G字號移動網絡簡介

代	峯值數據速率	說明
1G	無數據	模擬系統
2G	Kbit/s	第一代數字系統，做爲對模擬系統的替代或與之並存
3G	Mbit/s	專用數字網絡，與模擬系統並行部署
4G	Gbit/s	數字及分組網絡

1）、1G

最先的商業 1G 網絡於 1979 年部署於日本。這種網絡屬於模擬系統，沒有數據傳輸能力。android

2）、2G

1991 年，芬蘭基於新興的GSM(Global System for Mobile communications，全球移動通訊系統) 標準建設了第一個 2G 網絡，最先在無線電網絡中引入了數字信令。git

直到 1990 年代中期，GPRS(General Packet Radio Service，通用無線分組業務) 被引入 GSM 標準，無線互聯網才真正走向實用。而 GPRS 與早期 2G 語音技術的結合一般被稱爲 2.5G。github

3）、3G

1998 年，GSM 和 IS-95 組織又成立了兩個全球性的合做夥伴項目便於指定 3G 標準：web

「3GPP(3rd Generation Partnership Project，第三代合做夥伴項目)：負責制定 UMTS(Universal Mobile Telecommunication System，通用移動通訊系統)，其後來也負責維護 GSM 標準和制定新的 LTE 標準」。
「3GPP2(3rd Generation Partnership Project 2)：負責基於 CDMA2000，也就是高通制定的 IS-95 標準的後續技術制定 3G 規範」。

3GPP 和 3GPP2 共同管理每種技術的演進。在 Android 手機上，輸入:##4636##，能夠看到移動鏈接的類型、電池診斷等信息。算法

4）、知足 IMT-Advanced 的 4G

所謂 4G，背後是一組具體要求(IMT-Advanced)，這組要求是 ITU 在 2008 年就制定和公佈了的。任何達到這些要求的技術，均可以看做是 4G 技術。例如：json

以 IP 分組交換網絡爲基礎。
與以前的無線標準(3G 和 2G)兼容。
移動客戶端的速率達到 100 Mbit/s，靜止時的速率達到 Gbit/s 以上。

5）、長期演進(LTE)

隨着對高速率和低延遲的需求愈來愈強烈，3GPP 計劃從新設計核心及無線網絡，因而 LTE(Long Term Evolution，長期演進)標準應運而生。而它與前面介紹的 IMT-Advanced 要求很相似。瀏覽器

二、無線電資源控制器(RRC)

「2G、3G 和 4G 網絡都有 RRC」，它具備以下特色：緩存

1）、 「負責調度協調移動設備與無線電基站之間全部的通訊鏈接」。
2）、 「直接直接影響延遲、吞吐量和設備電池的使用時間」。
3）、 「2G 和 3G 網絡中的 RRC 處於核心運營網絡，而在 4G 中，爲提高性能、減小協調時間，RRC 被轉移到了無線信號塔 (eNodeB)」。

簡而言之，「RRC 就是無線電網絡的大腦。想要經過無線信道發送數據?你必須先向 RRC 申請無線電資源。想要接收互聯網上的數據? RRC 會通知你何時監聽接收到來的分組」。性能優化

三、移動網絡中的分組流

1）、初始化請求

核心流程

1）、「首先，因爲手機處於空閒 RRC 狀態，所以無線電模塊必須與附近的信號塔同步，而後發送一個請求，以便創建無線通訊環境，這次協商須要手機與信號塔之間的幾回往返，可能須要花 100ms。若是是前幾代網絡，那 RRC 由服務網關負責管理，這個協商過程要長得多，可達幾秒鐘」。
2）、 「創建了無線通訊環境後，設備就會從信號塔獲得相應資源，從而可以以特定的速度和功率傳輸數據」。
3）、 「分組經過核心網絡從 SGW 傳輸到 PGW」。
4）、 「最後向外傳到公共互聯網」。

其中各個步驟的延遲特色以下所示：

1）、 「控制面延遲：由 RRC 協商和狀態切換致使的固定的、一次性的延遲時間，從空閒到活動少於 100 ms，從休眠到活動少於 50 ms」。
2）、 「用戶面延遲：即用戶數據從無線電模塊傳輸到信號塔的時間，應用的每一個數據分組從設備到無線電信號塔之間都要花的固定的時間，少於 5 ms」。
3）、 「核心網絡延遲：分組從無線電信號塔傳輸到分組網關的時間，因運營商而不一樣，通常爲 30~ 100 ms」。
4）、 「互聯網路由延遲：從運營商分組網關到公共互聯網上的目標地址所花的時間，可變」。

2）、入站數據流

核心流程

1）、 「PGW 把入站分組路由到 SGW，SGW 進一步查詢 MME」。
2）、 「若是設備處於空閒狀態，MME 會向當前跟蹤區內的全部信號塔發送一條尋呼消息」。
3）、 「收到消息的信號塔接着經過共享的無線信道廣播一條通知，告知設備應該重建無線通訊環境，以便接收數據」。
4）、 「設備週期性地喚醒以監聽尋呼消息，若是在尋呼列表中發現了本身，它就會向無線電信號塔發送一條協商請求，請求重建無線通訊環境」。
5）、 「無線通訊環境重建以後，負責協商的信號塔向 MME 回發一條消息，表示它正在爲用戶服務」。
6）、 「而後，MME 向服務網關返回一個應答，服務網關因而就會把數據路由到該信號塔」。
7）、 「最後，該信號塔再把數據轉發給目標設備」。

「設備一旦處於鏈接狀態，無線信號塔與服務網關之間就會創建一條直連信道，從而讓後續到達的數據能跳過第2 ~ 5步(不用再通過尋呼)，直接被轉發到信號塔。所以，第一個分組的延遲是較長的」。

四、LTE-A（千兆級 LTE ）

理論上速度能夠達到光纖級別的 1Gbps（125MB/s），平常實際使用時平均速度 100Mbps 以上。

核心技術

1）、載波聚合

將多個載波聚合成更高的帶寬，理論上LTE-A系統中能夠實現2-5個LTE成員載波（ComponentCarrier，CC）的聚合。

當三個射頻信道變成一個更寬的信道，三個20MHz就至關於60MHz，那麼數據吞吐量便提高了3倍。

2）、高階調製

利用有限帶寬資源提供高數據速率一種的手段。

提升收發器的複雜程度可讓一個信號搬運更多的比特。例如將 64-QAM （64個樣點，樣點數目越多傳輸效率越高）提高到 256-QAM（256個樣點），一個信號能夠從承載6個比特提高到8個比特，帶寬效率提高了33%。

3）、更高階的 MIMO（Multiple-Input Multiple-Output）

在發射端和接收端分別使用多個發射天線和接收天線。這使信號經過發射端與接收端的多個天線傳送和接收，大大增大信道容量。

五、5G

通訊技術的極限，並非技術工藝方面的限制，而是創建在嚴謹數學基礎上的推論，在能夠碰見的將來是基本不可能突破的。而 1G ~ 5G 都逃脫不了下面這個公式：

光速 = 波長 × 頻率
複製代碼

1）、現代通訊技術的現狀

有線通訊

實驗室中的單條光纖最大速度 26 Tbps。

無線通訊（瓶頸）

4 G LTE 理論速率僅有 150 Mpbs。

❝
5G 實際上如何工做？
❞

通訊技術並不神祕，5G 做爲通訊技術皇冠上最耀眼的寶石，也不是什麼高不可攀的創新革命技術，它更可能是對現有通訊技術的演進。而其實質就是 「向新的毫米波和其餘高頻頻段的轉變」。第五代移動通訊技術，5G速率是4G的100倍，實際使用至少是10倍。

2）、優點

1）、高性能
2）、低延遲
3）、高容量

3）、核心技術

一、毫米波

「目前主流的 4G LTE 波長都是集中在分米波與釐米波這兩個區間，而 5 G 的波長是位於毫米波的區間」。

二、微基站

「因爲電磁波頻率越高，衰減越大的特色，若是使用高頻，那麼傳輸距離與覆蓋能力都會減弱。所以覆蓋同一個區域，須要的 5G 數量將大大超過 4G。爲了下降基站成本，微基站應運而生」。

「基站分爲宏基站和微基站，宏基站在郊外、山上常常能夠看到，微基站一般在城區和室內，它能夠小到只有巴掌大」：）

三、Massive MIMO（大量的多輸入、多輸出 => 多天線技術）

「之前的手機有天線，其實如今的手機也有，只不過天線已經很是小了。由於天線的長度與波長成正比」，公式以下所示：

天線長度 = 波長/10 ~ 波長/4
複製代碼

「若是使用了 5 G 的毫米波通訊，天線也就能夠變成毫米級了，所以，高階版的多天線技術應運而生」。

須要注意的是，「不管是基站仍是手機中的天線製做，天線之間的距離都應該保持在半個波長以上，以免互相干擾」。

四、全雙工

手機與手機直接不只能夠直接進行通訊，並且能夠實現全雙工。

五、波束成形

「在基站佈設天線陣列（一大羣天線），經過對射頻信號相位的控制，使得互相做用後的電磁波的波瓣變得很是狹窄，並指向它所提供服務的手機，而且還可以根據手機的移動而轉變方向」。

優點

「將全向的信號覆蓋轉變爲精準指向性服務，這樣即可以在相同的空間中提供更多的通訊鏈路」。

而目前經常使用 WIFI 協議標準 5 G：802.11ac，它的特色以下所示：

「理想速率 866.7Mbps」
「支持8個 MIMO 空間流」

六、華爲 Link Turbo 網絡聚合加速技術

在理想環境下，手機開啓 Link Turbo 功能後，「速度相比只鏈接 WiFi 和只鏈接 4G 的速度分別提升了 135% 和 71%」，由於它在基礎網絡協議和算法兩方面作了大量的優化。

1）、 「它從業務類型、接入網絡的類型、用戶喜愛三方面進行感知建模，在通過處理以後找到最佳匹配的網絡協議」。
2）、「經過算法讓兩條通道（WIFI、4G）同時滿載，須要大量的計算與調試，才能平衡數據包在快慢通道之間的運送比例，最終達到運送效率最佳，速度最快」。

須要注意的是，硬件上 WIFI 與蜂窩網絡屬於基帶芯片的不一樣模塊 => 相似雙網卡。

MultiPath TCP（iOS 7 引入）

1）、 「可讓 TCP 鏈接使用多條路徑來最大化資源利用率」。
2）、 「須要解決跨路徑數據碎片化、SSL 解密效率低的問題」。
3）、 「MPTCP 會話同 TCP 同樣的方式啓動，不一樣的是在 TCP 的 SYN、SYN-ACK、最終的 ACK 數據包的選項中多添加了一個 MP_CAPABLE 選項」。

「而 Link Turbo 使用了自研 MultiPath UDP，Link Turbo 就是在使用 WIFI 的同時使用移動網絡加速」。

所以，嘗試跟手機廠商、芯片廠商或運營商合做也是一大優化方向。

七、移動網絡優化 Tips

1）、爆發傳輸數據並轉爲空閒

移動無線接口專門爲爆發性傳輸作過優化，咱們能夠 「儘量多和快地下載數據，而後讓無線模塊轉爲空閒。這樣，既能夠得到最大的網絡吞吐量，也能節約電量」。

若是須要大型音頻或視頻文件，考慮提早下載整個文件，而不要以比特爲單位地流式下載。

2）、把負載轉移到 Wi-Fi 網絡

「Wi-Fi 鏈接下的大數據量傳輸更省電，並且在通訊過程當中也不須要 RRC，相對於 4G 網絡，這將會節省 50~100 ms 的延遲」。

9、HTTP

一、非官方的 HTTP 0.9

1991 年出現，它是隻有一行的協議。其主要功能以下：

客戶端 / 服務器、請求 / 響應協議;
ASCII 協議，運行於 TCP/IP 連接之上;
設計用來傳輸超文本文檔(HTML);
服務器與客戶端之間的鏈接在每次請求以後都會關閉。

二、非互聯網標準的 HTTP 1.0

1994 年，IETF(Internet Engineering Task Force，互聯網工程任務組) 成立了 HTTP 工做組(HTTP-WG)，致力於改進 HTTP 協議。

1996 年，HTTP 工做組發佈了 RFC 1945，解釋說明了當時不少 HTTP 1.0 實現的「公共用法」。但 HTTP 1.0 並非一個正式的規範或互聯網標準。

因爲響應對象自己能夠是任何類型:HTML 文件、純文本文件、圖片，或其餘內容類型。所以，HTTP 中的「HTT」(Hypertext Transfer，超文本傳輸)在協議出現後不久就已經用詞不當了。在實踐中，HTTP 迅速發展爲 「超媒體傳輸協議」，但最初的名字則沿用至今。

注意：HTTP 1.0 對每一個請求都打開一個新 TCP 鏈接嚴重影響性能。

三、互聯網標準 HTTP 1.1

1997 年 1 月，定義正式 HTTP 1.1 標準的 RFC 2068 發佈了。

HTTP 1.1 中引入了大量加強性能的重要特性：

1）、 「持久化鏈接以支持鏈接重用」;
2）、 「分塊傳輸編碼以支持流式響應」;
3）、 「請求管道以支持並行請求處理」;
4）、 「字節服務以支持基於範圍的資源請求」;
5）、 「改進的更好的緩存機制」。

HTTP 1.1 改變了 HTTP 協議的語義，默認使用持久鏈接。換句話說，除非明確告知(經過 Connection: close 首部)，不然服務器默認會保持鏈接打開。

不過，這個功能也反向移植到了 HTTP 1.0，能夠經過 Connection: Keep- Alive 首部 來啓用。實際上，若是你使用的是 HTTP 1.1，從技術上說不須要 Connection: Keep-Alive 首部，但不少客戶端仍是選擇加上它。

1）、持久鏈接的優勢

「在啓用持久鏈接的狀況下，N 次請求節省的總延遲時間就是 (N-1) × RTT」。

2）、HTTP 管道

持久 HTTP 可讓咱們重用已有的鏈接來完成屢次應用請求，但屢次請求必須嚴格知足先進先出(FIFO)的隊列順序:發送請求，等待響應完成，再發送客戶端隊列中的下一個請求。HTTP 管道是一個很小但對上述工做流卻很是重要的一次優化。 「管道可讓咱們把 FIFO 隊列從客戶端(請求隊列)遷移到服務器(響應隊列)」。以下圖所示：

優點

「消除了發送請求和響應的等待時間。這種並行處理請求的能力對提高應用性能的幫助很是之大」。
「網絡延遲越高，請求越多，節省的時間就越多。而越是大型應用，網絡優化的影響就越大」。

HTTP 中的隊首阻塞

例如第一個請求無限期掛起，或者要花很長時間才能處理完，怎麼辦呢?在 HTTP 1.1 中，全部後續的請求都將被阻塞，等待它完成。

3)、計算圖片對內存的需求

「全部編碼的圖片經瀏覽器解析後都會以 RGBA 位圖的形式保存於內存當中。每一個 RGBA 圖片的像素須要佔用 4 字節:紅、綠、藍通道各佔 1 字節，Alpha(透明) 通道佔 1 字節」。

因此，「一張圖片佔用的內存量 = 圖片像素寬度 × 像素高度 × 4 字節」。

4）、謹慎使用 base64 編碼

「base64 編碼使用 64 個 ASCII 符號和空白符將任意字節流編碼爲 ASCII 字符串。編碼過程當中，base64 會致使被編碼的流變成原來的 4/3，即增大 33% 的字節開銷」。

四、改進傳輸性能的 HTTP 2.0

HTTP 工做組已經在 2012 年宣佈要開發 HTTP 2.0，HTTP 2.0 的主要目標是 「改進傳輸性能，實現低延遲和高吞吐量」。其具體是 「經過支持請求與響應的多路複用來減小延遲，經過壓縮 HTTP 首部字段將協議開銷降至最低，同時增長對請求優先級和服務器端推送的支持」。

1）、歷史及其與 SPDY 的淵源

SPDY 是谷歌開發的一個實驗性協議，於 2009 年年**中 發佈，其主要目標是經過解決 HTTP 1.1 中廣爲人知的一些性能限制，來減小網頁的加載延遲**。

2012 年初，HTTP-WG(HTTP Working Group) 把 HTTP 2.0 提到了議事日程，並吸收 SPDY 的經驗教訓，在此基礎上制定了官方 HTTP 2.0 標準。

2）、走向 HTTP 2.0

SPDY 是 HTTP 2.0 的催化劑，但 SPDY 並不是 HTTP 2.0。SPDY 規範僅僅是做爲制定 HTTP 2.0 標準的基礎。

3）、二進制分幀層

「HTTP 2.0 性能加強的核心，全在於新增的二進制分幀層，它定義瞭如何封裝 HTTP 消息並在客戶端與服務器之間傳輸」。

能夠看到，相較於 HTTP 1.1，編碼方式變了。HTTP 1.x 以換行符做爲純文本的分隔符，「而 HTTP 2.0 將全部傳輸的信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼」。

流、消息和幀

在 HTTP 2.0 中，全部通訊都在一個 TCP 鏈接上完成。而要理解 HTTP 2.0，就必須理解流、消息和幀這幾個基本概念，以下所示：

「流：已創建的鏈接上的雙向字節流。流是鏈接中的一個虛擬信道，能夠承載雙向的消息;每一個流都有一個惟一的整數標識符(一、2...N)」。
「消息：與邏輯消息對應的完整的一系列數據幀。消息是指邏輯上的 HTTP 消息，好比請求、響應等，由一或多個幀組成」。
「幀：HTTP 2.0 通訊的最小單位，每一個幀包含幀首部、負荷等等，至少也會標識出當前幀所屬的流」。

多向請求與響應

「在二進制分幀層的基礎上，客戶端和服務器能夠把 HTTP 消息分解爲互不依賴的幀，而後亂序發送，最後再在另外一端把它們從新組合起來」。

所以，「HTTP 2.0 的二進制分幀機制解決了 HTTP 1.x 中存在的隊首阻塞問題，也消除了並行處理和發送請求及響應時對多個鏈接的依賴」。

請求優先級

每一個流均可以帶有一個 31 比特的優先值:

「0 表示最高優先級」。
「2 ^ 31 - 1表示最低優先級」。

「服務器能夠根據流的優先級，控制資源分配(CPU、內存、帶寬)，而在響應數據準備好以後，優先將最高優先級的幀發送給客戶端」。

每一個來源一個鏈接

全部 HTTP 2.0 鏈接都是持久化的，並且客戶端與服務器之間也只須要一個鏈接便可。
雖然 HTTP 2.0 消除了 HTTP 隊首阻塞現象，但 TCP 層次上仍然存在隊首阻塞。

4）、首部壓縮

每次都要傳輸 UserAgent、Cookie 這類不會頻繁變更的內容，網絡開銷隨着請求數的增多而變大。所以，HTTP 2.0 實現了首部壓縮。

實現原理

在支持 HTTP2 的客戶端與服務端之間：

1）、維護一份相同的靜態字典 Static Table

「常見頭部名稱、特別常見頭部名稱及值的組合」。

❝
HTTP2 靜態字典的做用是什麼？
❞

1）、 「徹底匹配的頭部鍵值對，例如 :method:POST, 直接使用一個字符表示」。
2）、 「匹配頭部名稱的鍵值對，例如 cookie: xxx，將名稱使用一個字符表示」。

2）、維護一份相同的動態字典 Dynamic Table

1）、 「用於動態添加內容」。
2）、 「客戶端與服務端能夠相互通知對方，將發送的 key-value，例如 cookie：xxx 添加到自身的動態字典中」。
3）、 「同一個鏈接上產生的請求和響應越多，動態字典積累得越全，頭部壓縮效果也就越好」。
4）、注意， 「須要爲每一個 HTTP2 鏈接維護不一樣的動態字典」。

3）、利用支持基於靜態哈夫曼碼錶的哈夫曼編碼 Huffman Coding

「若是靜態、動態字典中沒有對應的 key:value，則使用哈夫曼編碼減小體積」。

5）、幀首部

幀是 HTTP 2.0 中通訊的最小單位。「全部幀都共享一個 8 字節的首部」，以下圖所示：

「16 位的長度前綴：意味着一幀大約能夠攜帶 64 KB 數據，不包括 8 字節首部」。
「8 位的類型字段：決定如何解釋幀其他部分的內容」。
「8 位的標誌字段：容許不一樣的幀類型定義特定於幀的消息標誌」。
「1 位的保留字段：始終置爲 0」。
「31 位的流標識符：惟一標識 HTTP 2.0 的流」。

HTTP 2.0 規定了以下幀類型：

1）、 DATA： 「用於傳輸 HTTP 消息體」。
2）、 HEADERS： 「用於傳輸關於流的額外的首部字段」。
3）、 PRIORITY： 「用於指定或從新指定引用資源的優先級」。
4）、 RST_STREAM： 「用於通知流的非正常終止」。
5）、 SETTINGS： 「用於通知兩端通訊方式的配置數據」。
6）、 PUSH_PROMISE： 「用於發出建立流和服務器引用資源的要約」。
7）、 PING： 「用於計算往返時間，執行「活性」檢查」。
8）、 GOAWAY： 「用於通知對端中止在當前鏈接中建立流」。
9）、 WINDOW_UPDATE： 「用於針對個別流或個別鏈接實現流量控制」。
10）、 CONTINUATION： 「用於繼續一系列首部塊片斷」。

五、QUIC

Google 2013 實現，2018 基於 QUIC 協議的 HTTP 被確認爲 HTTP3。
QUIC 簡單理解爲 HTTP/2.0 + TLS 1.3 + UDP。弱網環境下表現於 TCP。

1）、優點

1）、 「解決了在鏈接複用中 HTTP2 + TCP 存在的隊首阻塞問題」，
2）、 「因爲是基於 UDP，因此能夠靈活控制擁塞協議。例如 Client 端能夠直接使用 Google 的 BBR 算法」。
3）、 「鏈接遷移：因爲 UDP 經過相似connection id 的特性,使得客戶端網絡切換的時候不須要重連，用戶使用 App 的體驗會更加流暢」。

2）、目前的缺點

1）、 「NAT 局域網路由、交換機、防火牆等會禁止 UDP 443 通行，所以 QUIC 建立鏈接成功率只有95%」。
2）、 「運營商針對 UDP 通道不支持/支持不足」。
3）、 「使用 UDP 不必定會比 TCP 更快，客戶端可同時使用 TCP 和 QUIC 競速，從而選擇更優鏈路」。

3）、使用場景

1）、實時性
2）、可丟棄
3）、請求互相依賴
4）、可同時使用 TCP & QUIC

六、瀏覽器性能優化 Tips

大多數瀏覽器都利用了以下四種優化技術：

1）、資源預取和排定優先次序：文檔、CSS 和 JavaScript 解析器能夠與網絡協議層溝通，聲明每種資源的優先級:初始渲染必需的阻塞資源具備最高優先級，而低優先級的請求可能會被臨時保存在隊列中。一樣，客戶端也能夠對請求作優先級排序處理。
2）、DNS 預解析：對可能的域名進行提早解析，避免未來 HTTP 請求時的 DNS 延遲。預解析能夠經過學習導航歷史、用戶的鼠標懸停，或其餘頁面信號來觸發。而在客戶端中可使用 HTTPDNS。
3）、TCP 預鏈接：DNS 解析以後，瀏覽器能夠根據預測的 HTTP 請求，推測性地打開 TCP 鏈接。若是猜對的話，則能夠節省一次完整的往返(TCP 握手)時間。
4）、頁面預渲染：某些瀏覽器可讓咱們提示下一個可能的目標，從而在隱藏的標籤頁中預先渲染整個頁面。這樣，當用戶真的觸發導航時，就能當即切換過來。

10、網絡 IO

網絡 IO 的本質是 Socket 的讀取，Socket 在 Linux 系統被抽象爲流，而 IO 能夠理解爲對流的操做。

一、Socket recvfrom 讀取數據過程

1）、 「等待 Socket 數據準備好，即網絡數據已下載至內核的緩衝區中」。
2）、 「將數據從內核的緩衝區中拷貝到應用進程的地址空間」。

二、Unix 網絡 IO 模型

共有五種類型，分別以下所示：

1）、同步

一、阻塞 I/O(blockig I/O)

特色

默認 I/O 行爲，整個 Socket 的讀取或發送都要阻塞應用進程。
一、2階段均阻塞。

優勢

及時返回數據。

缺點

對用戶來講等待太耗性能。

二、非阻塞 I/O(non-blocking I/O)

特色

經過 O_NONBLOCK 將 Socket 設爲非阻塞。
第1階段
- 不阻塞，數據沒有準備好會當即返回。
- 一直沒有獲取到數據的話會每隔必定時間輪詢進行 recvform 系統調用。
第2階段：阻塞。

優勢

可以在等待數據準備的時間裏幹其它事。

缺點

任務可能在兩次輪詢間的任意時刻完成，這將會下降總體數據的吞吐量。

三、多路複用 I/O(multiplexing I/O)

特色

通常使用 select/poll/epoll 實現，它們的好處在於「單個進程能夠同時處理多個網絡鏈接的 IO。其在內部會不斷地輪詢所負責的全部 socket，當某個 socket 有數據到達了，就通知用戶進程。經過把多個 I/O 的阻塞複用到同一個 select 的阻塞上，從而使得系統在單線程的狀況下能夠同時處理多個客戶端請求」。

第1階段：阻塞在 select/poll/epoll 調用處。
第2階段：阻塞。

優勢

「相比於多線程/多進程模型，系統開銷更小」。

四、信號驅動式 I/O(signal-driven I/O)

經過 SIGIO 信息處理，不多用到。

1階段不阻塞：「首先須要開啓 socket 信號驅動 IO 功能，並經過系統調用 sigaction 執行一個信號處理函數（非阻塞，當即返回）。當數據準備好時，進程會受到一個 SIGIO 信號，能夠在信號處理函數中調用 I/O 操做函數處理數據」。
2階段：阻塞。

2）、異步

一、異步 I/O(asynchronous I/O)

Linux AIO庫函數實現，但一般使用開源的異步 IO 庫，例如 libevent、libev、libuv。一、2階段非阻塞。

三、常見問題

1）、同步 IO 與異步 IO 的區別？

異步 IO 作 IO 操做時不會將 process 阻塞。

2）、非阻塞 IO 與異步 IO 的區別？

在非阻塞 IO 中，進程大部分時間都不會阻塞，可是須要進程主動去 check，而且當數據準備後，也還須要進程主動再次調用 recvfrom 將數據拷貝到用戶內存。

而在異步 IO 中，用戶進程將整個 IO 操做交給了內核完成，而後他人作完後發信號通知。在此期間，用戶進程不須要去 check IO 操做的狀態，也不須要主動地去拷貝數據。

3）、網絡 IO 同時使用了軟中斷和硬中斷？

首先，經過硬中斷通知 CPU 有數據來了，處理過程很是輕量。而後，經過軟中斷處理函數去慢慢處理耗時操做。

4）、多路複用 I/O 必定比阻塞 I/O 好？

同通常的多線程 + 阻塞 I/O 模式相比，多路複用 I/O 在網絡鏈接很是多的時刻確定性能更好，但當在同一時刻的網絡鏈接不多時，頻繁使用 select/poll 系統調用消耗的性能會得不償失。

5）、epoll 必定比 select/poll 好？

同一時間鏈接數不多時 select 性能會比 epoll 更好。

6）、epoll 使用了 mmap 減小內核到用戶空間的拷貝？

不管是在單純的 Linux 內核上仍是 Android 的 Linux 內核上均沒有使用 mmap 去實現 epoll。

11、IPv6

中國 0.4% 用戶使用。預計從 IPv4 所有切換到 IPv6，須要 5-10 年的時間。相比 IPv4 鏈接耗時下降 10%~20%。

IPv6 過渡技術分類

1）、翻譯技術

實現純 IPv4 與 IPv6 網絡互通，相似於 IPv4 NAT。
根據 IP 報文頭的地址和協議進行翻譯。
最經常使用的 NAT64 翻譯技術使用地址池的方式將大量的 IPV6 地址轉換爲少許的 IPv4 地址，經常使用於 IPv6 網絡發起鏈接到 IPV4 網絡。

2）、雙棧技術

目前大部分的網絡設備和主機操做系統均已支持雙棧協議—同時運行 IPv4 與 IPv6 兩套協議。

鏈路協議支持雙協議棧，例如在 「以太網協議的以太幀中」：

「協議 ID 0x0800 表示網絡層協議採用 IPv4」。
「協議 ID 0x86DD 表示網絡層協議採用的是 IPv6」。

應用支持雙協議棧，DNS 優先選擇 IPv6 協議棧做爲網絡層協議。

3）、隧道技術

經過 IPv4 骨幹網絡鏈接兩端的 IPv6 孤島：隧道技術經過網絡邊界設備將 IPv6 源封裝到 IPv4 的報文中通過 IPv4 骨幹網傳遞到另外一邊的網絡邊界設備還原 IPv6 報文。
經過 IPv6 骨幹網絡鏈接兩端的 IPv4 孤島：類好比上。

例如 GRE 隧道技術提供了點對點鏈接服務，須要手工指定隧道的端點地址。

12、總結

在本文中，咱們深刻學習地了網絡優化相關的必備基礎知識，能夠看到，「每一處優化基礎知識點都是在原先的網絡基礎知識點上再深刻了一層，這不只有助於咱們更好地理解網絡核心基礎知識，並且也爲咱們後續深刻探討網絡優化相關的課題提供了良好的基礎儲備」。最後，再多提一句，在學習的過程當中，「必定要注意多使用隔期複習法」，特別是針對於計算機基礎學科類的知識。