前言

網(wǎng)絡(luò)優(yōu)化一直被認為是移動優(yōu)化水最深的領(lǐng)域之一，因此要想對網(wǎng)絡(luò)進行深入優(yōu)化，我們就必須先打下比較扎實的網(wǎng)絡(luò)基礎(chǔ)，在本文中，我們將再次重溫計算機網(wǎng)絡(luò)中的重點知識，以此在腦海中建立一個較為全面的網(wǎng)絡(luò)基礎(chǔ)知識體系。

大綱

一、重識計算機網(wǎng)絡(luò)

1、計算機網(wǎng)絡(luò)是什么？

• 1）、主要由 「通用、可編程的硬件互連」 而成。
• 2）、通過這些硬件，可以 「傳送不同類型的數(shù)據(jù)」。
• 3）、計算機網(wǎng)絡(luò)不僅包含 「軟件概念」，還包含 「硬件設(shè)備」。
• 4）、計算機網(wǎng)絡(luò)不僅僅是 「信息通信」，還可以 「支持廣泛和日益增長的應用」。

2、計算機網(wǎng)絡(luò)的分類

1）、按作用范圍

廣域網(wǎng)（WAN）

幾十 KM ~ 幾千 KM，跨省、跨國。

城域網(wǎng)（MAN）

5 KM ~ 50 KM，城市間、城市內(nèi)。

局域網(wǎng)（LAN）

1 KM 內(nèi)，地區(qū)內(nèi)、家庭間、公司內(nèi)。

2）、按網(wǎng)絡(luò)使用者

公用網(wǎng)絡(luò)

所有可以通過付費方式就可以加入的網(wǎng)絡(luò)。

專用網(wǎng)絡(luò)

某些部隊、組織或者某些人 「為了滿足特殊業(yè)務需求而建立起來的特殊的網(wǎng)絡(luò)」，例如軍隊、鐵路、銀行都有自己的專用網(wǎng)絡(luò)。

二、網(wǎng)絡(luò)歷史演進

1、世界互聯(lián)網(wǎng)發(fā)展歷史演進

1）、單個網(wǎng)絡(luò)

「ARPANET」，1969年美國國防部創(chuàng)建的一個網(wǎng)絡(luò)，可以連接周圍的計算機。

計算機直接通過交換機就可以進行信息交換。

2）、三級結(jié)構(gòu)

「現(xiàn)代互聯(lián)網(wǎng)的雛形」，也稱為 「互聯(lián)網(wǎng)絡(luò)」，可以把美國所有的大學、研究所、實驗室都連接起來。

從上至下，由 「主干網(wǎng)、地區(qū)網(wǎng)、校園網(wǎng)」 組成。

3）、多層次 ISP

ISP(Internet Service Provider)：網(wǎng)絡(luò)服務提供商，例如中國電信、中國移動、中國聯(lián)通等。「從上之下，由主干 ISP、地區(qū) ISP 組成」。

主干 ISP

中國的主干 ISP 包括 「中國電信、中國移動、中國聯(lián)通」，它們可以連接美國和其它國家的主干 ISP。

地區(qū) ISP

例如移動網(wǎng)絡(luò)，在北京叫 「北京移動」，在上海叫 「上海移動」，這些就屬于地區(qū) ISP。「地區(qū) ISP 可以連接公司、校園、家庭的網(wǎng)絡(luò)」。

4）、了解現(xiàn)代國際互聯(lián)網(wǎng)的主要線路

我們可以通過 infrapedia 網(wǎng)站了解國際互聯(lián)網(wǎng)的主要線路。

上圖刻畫了 「全球的所有主干網(wǎng)絡(luò)的線路」，可以看到，「中國的主干網(wǎng)絡(luò)出口基本都是位于廣東、福建等沿海地區(qū)，它們通過各自的海底電纜與位處于世界各地的主干網(wǎng)絡(luò)相互連接，最終形成了互聯(lián)網(wǎng)」。

2、中國互聯(lián)網(wǎng)發(fā)展歷史

1）、1980 年

中國鐵道部開始互聯(lián)網(wǎng)實驗。

2）、1989 年

建立并運行第一個公共網(wǎng)絡(luò)。

3）、1994 年

接入國際互聯(lián)網(wǎng)。

4）、至今

「當今中國最大的五個公用的計算機網(wǎng)絡(luò)」：

• 「中國電信互聯(lián)網(wǎng)(CHINANET)」
• 「中國聯(lián)通互聯(lián)網(wǎng)(UNINET)」
• 「中國移動互聯(lián)網(wǎng)(CMNET)」
• 「中國教育與科研計算機網(wǎng)(CERNET)」
• 「中國科學技術(shù)網(wǎng)(CSTNET)」

3、中國的互聯(lián)網(wǎng)企業(yè)

• 1996年，張朝陽創(chuàng)建搜狐。
• 1997年，丁磊創(chuàng)建網(wǎng)易。
• 1998年，王志東創(chuàng)建新浪，馬化騰、張志東創(chuàng)建騰訊。
• 1999年，馬云創(chuàng)建阿里巴巴。
• 2000年，李彥宏創(chuàng)建百度。

三、重識網(wǎng)絡(luò)層次結(jié)構(gòu)

網(wǎng)絡(luò)為什么要分層？

因為復雜的程序都要分層。這是一個架構(gòu)設(shè)計的通用問題，不僅僅是網(wǎng)絡(luò)協(xié)議的問題，「只要涉及復雜的邏輯或軟件需求需要經(jīng)常變動的情況通常都會通過分層來解決」。

思考🤔：設(shè)計一個計算機網(wǎng)絡(luò)需要解決哪些問題？

• 1）、傳輸數(shù)據(jù)時需要保證數(shù)據(jù)通路順暢。
• 2）、需要識別目的計算機。
• 3）、需要了解目的計算機的狀態(tài)。
• 4）、數(shù)據(jù)是否錯誤。

總之，計算機網(wǎng)絡(luò)需要解決的問題是繁多而復雜的，所以我們需要 「采用分層的設(shè)計分別去解決不同的問題，實現(xiàn)不同的功能」。

1、層級結(jié)構(gòu)設(shè)計的基本原則

1）、相互獨立

每一層僅僅實現(xiàn)一個相對獨立的功能，并且需要確保層與層之間的耦合度是非常低的。

2）、靈活性

每一層的設(shè)計需要具備很好的靈活性、擴展性，以適應未來的網(wǎng)絡(luò)變化。

3）、耦合度

各層之間是完全解耦的，層與層之間的變化互不影響。

2、OSI 七層模型

OSI功能

應用層	為計算機用戶提供接口和服務。
表示層	數(shù)據(jù)處理：編解碼、加解密等等。
會話層	管理（建立、維護、重連）通信會話。
傳輸層	管理端到端的通信連接。
網(wǎng)絡(luò)層	數(shù)據(jù)路由：決定數(shù)據(jù)在網(wǎng)絡(luò)中的路徑。
數(shù)據(jù)鏈路層	管理相鄰節(jié)點之間的數(shù)據(jù)通信。
物理層	數(shù)據(jù)通信的光電物理特性。

1）、OSI 悲催的故事

• 1）、一開始，OSI 欲稱為全球計算機都遵守的標準。
• 2）、但是，OSI 在市場化的過程中困難重重，因為 TCP/IP 已經(jīng)在全球范圍成功運行。
• 3）、最終，OSI 并沒有稱為廣為使用的標準模型。

2）、OSI 七層模型失敗的原因

• 1）、OSI 的專家沒有充分將理論與實際進行結(jié)合。
• 2）、OSI 標準的制定周期過長，按 OSI 標準生產(chǎn)的設(shè)備無法及時進入市場。
• 3）、OSI 模型的設(shè)計不合理，某些功能在多層重復出現(xiàn)。

3、TCP/IP 四層模型

我們需要理解數(shù)據(jù)通信過程中不同設(shè)備之間協(xié)議的轉(zhuǎn)換。從下圖可以看到 「路由器僅包括網(wǎng)絡(luò)層與網(wǎng)絡(luò)接口層」。

從協(xié)議的數(shù)量來看，TCP/IP 四層模型構(gòu)成了中間窄，兩端大的?沙漏形狀。如下圖所示：

四、初識現(xiàn)代網(wǎng)絡(luò)拓撲

1、為什么要了解網(wǎng)絡(luò)拓撲？

因為它 「有助于我們在腦海里面形成一個形象的計算機網(wǎng)絡(luò)」。

2、網(wǎng)絡(luò)拓撲分類

1）、邊緣部分

家庭

由 「終端機器、路由器、網(wǎng)關(guān)、地區(qū) ISP」 組成。

企業(yè)

不同于家庭的網(wǎng)絡(luò)拓撲，其 「網(wǎng)關(guān)細分為內(nèi)部網(wǎng)關(guān)與統(tǒng)一網(wǎng)關(guān)」。

2）、核心部分

由 「地區(qū) ISP、主干 ISP、路由器、海底電纜或跨地區(qū)電纜」 組成。其中的 「通信設(shè)備（一般是華為）主要是由移動、聯(lián)通所鋪設(shè)的」。

現(xiàn)代互聯(lián)網(wǎng)的網(wǎng)絡(luò)拓撲形成了一個 「樹狀結(jié)構(gòu)」。

3）、C/S 模式

由 客戶端/服務端 模式組成，并可以相互進行通信。

4）、P2P 模式

不分為服務端和客戶端，它們都是 「對等地進行連接的」，優(yōu)勢在于可以使 「下載速度更快」，如迅雷下載器中就應用了這種模式。

五、網(wǎng)絡(luò)性能指標

1、速率

即 bps <==> bit/s

網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)母鞣N單位與之對應的常見設(shè)備

為什么電信拉的 100M 光纖，測試峰值速度只有 12M 每秒？

網(wǎng)絡(luò)常用單位為（Mbps），因此這里的 100M 指的是 100Mbps。

100 M/S = 100 Mbps = 100 Mbit/s 100 Mbit/s = （100/8）MB/s = 12.5 MB/s

2、時延

1）、發(fā)送時延

發(fā)送時延 = 數(shù)據(jù)長度（bit）/ 發(fā)送速率（bit/s）

數(shù)據(jù)長度是由用戶決定的，而發(fā)送速率是由計算機網(wǎng)卡所決定的。

2）、傳輸時延

傳播時延 = 傳輸路徑距離 / 傳播速率（bit/s）

傳輸路徑距離是由用戶決定的，而傳播速率則受限于傳輸介質(zhì)。

3）、排隊時延

數(shù)據(jù)包在網(wǎng)絡(luò)設(shè)備中等待被處理的時間，例如路由器需要一個一個處理完前面的數(shù)據(jù)包才能處理后面的。

4）、處理時延

數(shù)據(jù)包到達設(shè)備或者目的機器被處理所需的時間。

總時延 = 發(fā)送時延 + 排隊時延 + 傳播時延 + 處理時延

3、往返時間 RTT（Route-Trip Time）

• 評估網(wǎng)絡(luò)質(zhì)量的一項重要指標。
• 表示數(shù)據(jù)報文在端到端通信中來回一次的時間。

通常使用 ping 命令查看 RTT

1）、ping 查看當前城市中的 IP

quchao@quchaodeMacBook-Pro ~ % ping 119.29.148.149 PING 119.29.148.149 (119.29.148.149): 56 data bytes 64 bytes from 119.29.148.149: icmp_seq=0 ttl=116 time=13.210 ms 64 bytes from 119.29.148.149: icmp_seq=1 ttl=116 time=19.118 ms 64 bytes from 119.29.148.149: icmp_seq=2 ttl=116 time=34.384 ms

2）、ping 美國的 IP

quchao@quchaodeMacBook-Pro ~ % ping 191.101.238.160 PING 191.101.238.160 (191.101.238.160): 56 data bytes 64 bytes from 191.101.238.160: icmp_seq=0 ttl=52 time=191.791 ms 64 bytes from 191.101.238.160: icmp_seq=1 ttl=52 time=180.278 ms 64 bytes from 191.101.238.160: icmp_seq=2 ttl=52 time=186.399 ms

六、應用層

「傳輸層與之下的層已經(jīng)提供了完整的通信服務」。而應用層是面向用戶的一層。它主要是用來 「定義應用間通信的規(guī)則」，例如應用進程的報文類型（請求報文、應答報文）、報文的語法、格式、應用進程發(fā)送數(shù)據(jù)的時機、規(guī)則等等。

1、DNS(Domain Name System) 域名系統(tǒng)服務

域即對應的網(wǎng)絡(luò)號，名即對應的主機名字。

1）、功能

通過把沒有規(guī)則的點分十進制 IP 地址轉(zhuǎn)換為可以理解的一些域名。

2）、域名

• 使用域名可以幫助記憶。
• 域名通過 DNS 服務可以被轉(zhuǎn)換成 IP 地址。
• 域名是由點、字母和數(shù)字組成的。
• 點分割不同的域。
• 「域名可以分為頂級域、二級域、三級域…，例如：www.taobao.com => - 三級域.二級域.頂級域」。

頂級域常見分類

• 國家

  • cn
  • us
  • uk
  • ca

• 通用

  • com
  • net
  • gov
  • org

二級域

例如：qq、aliyun、taobao、google、facebook 等等。

「頂級域、二級域、三級域組成了一個樹狀結(jié)構(gòu)。且在頂級域名服務器上面還有一個根域名服務器」。

3）、域名服務器

只要有一個外網(wǎng)的服務器就可以搭建一個域名的服務器。

2、DHCP(Dynamic Host Configuratin Protocol) 動態(tài)主機設(shè)置協(xié)議

1）、是什么？

「網(wǎng)絡(luò)管理員只需配置一段共享的 IP 地址，每一臺新接入的機器都可以通過 DHCP 來這個共享的 IP 地址里面申請 IP 地址，就可以自動配置。等用完還回去其它機器也能使用」。它的特點如下所示：

• 1、「DHCP 是一個局域網(wǎng)協(xié)議」。
• 2、「DHCP 是應用 UDP 協(xié)議的應用層協(xié)議」。

2）、功能

• 「即插即用聯(lián)網(wǎng)」。
• 「在 IP 配置界面選中 自動獲得 IP 地址、自動獲得 DNS 服務器地址即可啟用 DHCP 協(xié)議去獲取一個臨時 IP（通常是一個內(nèi)網(wǎng)地址）」。
• 「有一個租期，在租期過半時可以續(xù)租」。

3）、DHCP 的過程

• 1）、「DHCP 服務器監(jiān)聽默認端口：67」。
• 2）、「主機使用 UDP 協(xié)議廣播 DHCP 發(fā)現(xiàn)報文」。
• 3）、「DHCP 服務器發(fā)出 DHCP 提供報文」。
• 4）、「主機向 DHCP 服務器發(fā)出 DHCP 請求報文」。
• 5）、「DHCP 服務器回應并提供 IP 地址」。

4）、向 DHCP 租用的 IP 地址是有租期的，IP 地址如何實現(xiàn)續(xù)租呢？

客戶端會在租期過去50%的時候，直接向為其提供 IP 地址的 DHCP 服務器發(fā)送 DHCP request 消息報。客戶端接收到服務器回應的 DHCP ACK 消息包后，會根據(jù)消息報中提供的新的租期以及其他已經(jīng)更新的 TCP/IP 參數(shù)更新自己的配置。

3、HTTP(HyperText Tranfsfer Protocol) 超文本傳輸協(xié)議

1）、是什么？

• HyperText 即超文本、超鏈接，Http 是指在電腦中顯示的、「含有可以指向其他文本的鏈接文本」。
• 對于這些內(nèi)容都有一個統(tǒng)一的路徑，例如： http(s)://<主機>:<端口>/<路徑>。
• 「HTTP 協(xié)議底層是 TCP 協(xié)議，因此它是可靠的數(shù)據(jù)傳輸協(xié)議」。

2）、Web 服務器

分為硬件部分（計算機或云上的虛擬設(shè)備）和軟件部分（Nginx、Apache)。

過程

• 1）、「接受客戶端連接」
• 2）、「接受請求報文」
• 3）、「處理請求」
• 4）、「訪問 Web 資源」
• 5）、「構(gòu)造應答」
• 6）、「發(fā)送應答」

3）、HTTP 請求方法

header 1header 2

GET	獲取指定的服務端資源。
POST	提交數(shù)據(jù)到服務端。
DELETE	刪除指定的服務端資源。（很少用）
UPDATE	更新指定的服務端資源。
PUT	修改數(shù)據(jù)。
OPTIONS	列出可對資源實行的請求方法，用來跨域請求。
CONNECT	建立連接隧道，用于代理服務器
HEAD	獲取資源的元信息
TRACE	追蹤請求-響應的傳輸路徑

GET 和 POST 的區(qū)別

• 1、「get參數(shù)通過url傳遞，post放在request body中」。
• 2、「get請求在url中傳遞的參數(shù)是有長度限制的，而post沒有」。
• 3、「get比post更不安全，因為參數(shù)直接暴露在url中，所以不能用來傳遞敏感信息」。
• 4、「get請求只能進行url編碼，而post支持多種編碼方式」。
• 5、「get請求會瀏覽器主動cache，而post支持多種編碼方式」。
• 6、「get請求參數(shù)會被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會被保留」。
• 7、「GET和POST本質(zhì)上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務器的限制，導致他們在應用過程中體現(xiàn)出一些不同」。

4）、HTTP 指定資源

1）、在地址中指定

?

https://www.wanandroid.com/repo/100.html

?

repo/100.html 是指定的請求資源。

?

https://www.wanandroid.com/?sort=0&unlearn=0&page=2

?

? 后面用來指定請求參數(shù)。

2）、在請求數(shù)據(jù)中指定

5）、HTTP 請求報文

HTTP 的請求報文與響應報文都滿足如下結(jié)構(gòu)：

?

起始行 + 頭部 + 空行 + 實體

?

其中的 「空行是用來區(qū)分開頭部和實體的」。

HTTP 請求報文的格式如下所示：

例如：

POST https://www.wanandroid.com HTTP/1.1 Accept-Encoding:gzip Accept-Language:zh-CN ... { 請求的 jsonString 內(nèi)容}

6）、HTTP 應答報文

7）、HTTP 應答狀態(tài)碼

header 1header 2

100~199	協(xié)議處理的中間狀態(tài)，還需要后續(xù)操作
200~299	成功
300~399	重定向
400~499	客戶端錯誤
500~599	服務端錯誤

100~199

• 101：Switching Protocols，服務器同意將 HTTP 升級為 WebSocket 時發(fā)送。

200~299

• 200：在響應體中放有數(shù)據(jù)。
• 204：No Content，響應頭后沒有 body 數(shù)據(jù)。
• 206：Partial Content，通常用于 HTTP 分塊下載和斷點續(xù)傳，同時帶上相應的響應頭字段 Content-Range。

300~399

• 301：Moved Permanently，永久重定向。
• 302：Found，臨時重定向。
• 304：Not Modified，協(xié)商緩存命中時返回。

400~499

• 400：Bad Request，請求出錯。
• 403：Forbidden，服務器禁止訪問，原因有法律禁止、信息敏感等。
• 404：Not Found，資源未找到。
• 405：Method Not Allowed，請求方法不被允許。
• 406：Not Acceptable，資源無法滿足條件。
• 408：Request Timeout，請求超時。
• 409：Conflict，多個請求發(fā)生了沖突。
• 413：Request Entity Too Large，請求體的數(shù)據(jù)過大。
• 414：Request-URI Too Long，請求行里的 URI 太大。
• 429：Too Many Request，客戶端發(fā)送的請求過多。
• 431：Request Header Fields Too Large，請求頭的字段內(nèi)容太大。

500~599

• 500：Internal Server Error，服務內(nèi)部出錯。
• 501：Not Implemented: 請求的功能不支持。
• 502：Bad Gateway: 服務器自身是正常的，只是數(shù)據(jù)通道有問題。
• 503：Service Unavailable: 服務器很忙，無法響應服務。

8）、HTTP 工作結(jié)構(gòu)

Web 緩存

通常遵循 「二八原則」：一個網(wǎng)站的內(nèi)容通常分為20%的熱門內(nèi)容，80%的冷門內(nèi)容。因此可以優(yōu)先緩存熱門內(nèi)容。

存儲器層次結(jié)構(gòu)

緩存(CPU 高速緩存）/主存(內(nèi)存)/輔存（磁盤）

Web 代理

• 通過 Web 代理可以屏蔽服務器的部署結(jié)構(gòu)。
• 可以在 Web 代理里面設(shè)置規(guī)則，如防火墻來保證安全。

Web 代理的分類

• 1）、正向代理：代理客戶端去訪問 Server。
• 2）、反向代理：代理 Server 把數(shù)據(jù)返回給客戶端。例如 Nginx、HAProxy 就是一些著名的代理軟件。

CDN(Content Delivery Network)內(nèi)容分發(fā)網(wǎng)絡(luò)

• 「用于將一些大的內(nèi)容在臨近的服務器留一個備份」。
• 「使用 CDN 可以進行多媒體內(nèi)容的加速」。

CDN的基本原理是 「廣泛采用各種緩存服務器，將這些緩存服務器分布到用戶訪問相對集中的地區(qū)或網(wǎng)絡(luò)中，在用戶訪問網(wǎng)站時，利用全局負載技術(shù)將用戶的訪問指向距離最近的工作正常的緩存服務器上，由緩存服務器直接響應」。

爬蟲

用于在互聯(lián)網(wǎng)上采集信息， 例如百度、Google的本質(zhì)就是一個爬蟲，它們通過把整個網(wǎng)絡(luò)的數(shù)據(jù)給取下來，并且做一個索引，然后把這些內(nèi)容提供給大家，在進行搜索時就會匹配這些內(nèi)容并返回。

不好的爬蟲的缺點:

• 增加網(wǎng)絡(luò)擁塞。
• 損耗服務器資源。

4、HTTPS(Secure) 安全的 HTTP 協(xié)議

?

https://<主機>:<443>/<路徑>

?

HTTP 是明文傳輸?shù)?#xff0c;但是我們需要在網(wǎng)絡(luò)中傳輸 賬號密碼、個人信息、賬號金額、交易信息、敏感信息，這會導致中間人非法截取信息，導致信息泄露。

1）、加密模型

• 「對稱加密：加密與解密都使用同一個秘鑰」。

• 「非對稱加密：公鑰加密，私鑰解密，并且公鑰與私鑰是擁有一定數(shù)學關(guān)系的一組秘鑰」。

  • 「私鑰：自己使用，不對外公開」。
  • 「公鑰：給大家使用，對外公開」。

2）、數(shù)字證書 簽名校驗

「數(shù)字證書是可信任組織頒發(fā)給特定對象的認證。而可信任組織即客戶端與服務端都認為安全的組織」。

數(shù)字證書格式

• 證書格式、版本號
• 證書序列號
• 簽名算法
• 有效期
• 對象名稱
• 對象公開秘鑰

3）、SSL(Secure Sockets Layer)安全套接層

「SSL 位于傳輸層與應用層之間，它是一個子層，作用主要有兩點」：

• 1）、「數(shù)據(jù)安全（保證數(shù)據(jù)不會被泄漏）與數(shù)據(jù)完整（保證數(shù)據(jù)不會被篡改）」。
• 2）、「對數(shù)據(jù)進行加密后傳輸」。

HTTPS 的通信過程

• 1）、「443 端口的 TCP 連接」。
• 2）、「SSL 安全參數(shù)握手」。
• 3）、「客戶端發(fā)送數(shù)據(jù)」。
• 4）、「服務端發(fā)送數(shù)據(jù)」。

SSL(Secure Sockets Layer) 安全套接層握手過程

1）、生成隨機數(shù) 1、2、3 的過程

2）、雙端根據(jù)隨機數(shù) 1、2、3 與相同的算法生成對稱秘鑰進行加密通信

「HTTPS 綜合地運用了對稱加密與非對稱加密，在進行隨機數(shù)校驗的階段是使用了非對稱加密來進行通信的，然后等雙方都確定了三個隨機數(shù)之后，就可以使用相同的算法來生成對稱秘鑰進行加密通信了。HTTPS 的優(yōu)勢在于雙端分別生成了秘鑰，沒有經(jīng)過傳輸，減少了秘鑰泄漏的可能性」。

5、Http2

它的特點如下所示：

• 1）、「頭部壓縮」。
• 2）、「多路復用：多路復用允許同時通過單一的HTTP/2連接發(fā)送多重請求-響應信息。改善了：在http1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數(shù)量限制（連接數(shù)量），超過限制會被阻塞」。
• 3）、「提升訪問速度：相比 http1.1 請求資源所需時間更少，訪問速度更快」。
• 4）、「二進制分幀：HTTP2.0 會將所有的傳輸信息分割為更小的信息或者幀，并對他們進行二進制編碼」。
• 5）、「設(shè)置請求優(yōu)先級」。
• 6）、「服務端推送」。

6、cookie

「HTTP 是一個無狀態(tài)協(xié)議，因此 Cookie 的最大的作用就是存儲 sessionId 用來唯一標識用戶。并且，Cookie 本質(zhì)上就是瀏覽器里面存儲的一個很小的文本文件，內(nèi)部以鍵值對的方式來存儲」。

生存周期

通過 Expires 和 Max-Age 兩個屬性來設(shè)置：

• Expires：過期時間。
• Max-Age：表示一段時間間隔，單位是秒，從瀏覽器收到報文開始計算。

作用域

「我們可以使用 Domain 和 path 屬性給 Cookie 綁定域名和路徑。如果在發(fā)送請求之前，發(fā)現(xiàn)域名或者路徑和這兩個屬性不匹配，那么就不會帶上 Cookie」。需要注意的是，路徑中含有 / 表示域名下的任意路徑都允許使用 Cookie。

安全

• 「帶上 Secure：說明只能通過 HTTPS 傳輸 cookie」。
• 「帶上 HttpOnly：說明只能通過 HTTP 協(xié)議傳輸」。
• 「帶上 SameSite：預防 CSRF 攻擊」。

缺點

• 1）、「安全缺陷：Cookie 很容易被非法用戶截獲，然后進行一系列的篡改，最后在 Cookie 的有效期內(nèi)重新發(fā)送給服務器」。
• 2）、「容量缺陷：體積上限只有4KB，只能用來存儲少量的信息」。
• 3）、「性能缺陷：Cookie 緊跟域名，因此域名下的請求都會攜帶上完整的 Cookie，這樣隨著請求數(shù)的增多，將會造成巨大的性能浪費，因為請求攜帶了很多不必要的內(nèi)容。這里可以通過 Domain 和 Path 指定作用域去解決」。

7、HTTP 傳輸中的常見問題

• 1）、「跨域問題」
• 2）、「數(shù)據(jù)傳輸」
• 3）、「隊頭阻塞」

七、傳輸層

現(xiàn)在，當設(shè)備 A 與 設(shè)備 B 相互通信時，我們可以認為它們就是通過一個虛擬的互連網(wǎng)絡(luò)進行連接的。「在虛擬的互連網(wǎng)絡(luò)里面已經(jīng)解決了網(wǎng)絡(luò)拓撲、數(shù)據(jù)路由的走向等問題。在傳輸層重點解決的是兩個設(shè)備它們直接是如何進行通信的」。

1、傳輸層的主要功能

1）、進程與進程的通信

不同于在單個操作系統(tǒng)內(nèi)使用的進程間通信（Unix 域套接字、共享內(nèi)存），網(wǎng)絡(luò)通信可以跨設(shè)備、跨網(wǎng)絡(luò)進行通信。

2）、端口的概念

• 「使用端口來標記不同的網(wǎng)絡(luò)進程」。
• 「端口使用16比特位表示（0~65535）」。

常見的協(xié)議端口有：

協(xié)議端口

FTP	21
HTTP	80
HTTPS	443
DNS	53
TELNET	23

2、UDP(User Datagram Protocol)用戶數(shù)據(jù)報協(xié)議

1）、功能

UDP 協(xié)議 「不會對數(shù)據(jù)報進行任何的處理，即不合并，也不拆分數(shù)據(jù)」。

2）、特點

1）、無連接

通信時并不需要提前建立連接。

2）、不保證可靠的數(shù)據(jù)交付

想發(fā)就發(fā)，無法保證數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中是否丟失。

3）、面向報文傳輸

不對數(shù)據(jù)做任何處理，而是直接將應用層數(shù)據(jù)塞進報文里面。

4）、沒有擁塞控制

不管網(wǎng)絡(luò)是否擁塞，它都會把數(shù)據(jù)給交付出去。

5）、首部開銷很小

首部僅僅占用8個字節(jié)。

3）、報文結(jié)構(gòu)

• 「UDP 長度最小值為 8， 即僅包括 UDP 首部」。
• 「校驗和是用來檢測 UDP 的數(shù)據(jù)報在傳輸過程中是否出錯」。

4）、基于 UDP 定制化的 5 個例子🌰

1、來自網(wǎng)頁或者 App 的訪問

目前，HTTP 往往采取多個數(shù)據(jù)通道共享一個連接的策略，這樣做本來是為了加快傳輸速度，但是 TCP 嚴格的順序策略使得哪怕共享通道，前一個包不來，后一個包即使與前一個包沒關(guān)系，也要等著，這樣就會使時延加大。

而 QUIC（Quick UDP Internet Connection，快速 UDP 互聯(lián)網(wǎng)連接）協(xié)議是 Google 提出的一種基于 UDP 改進的通信協(xié)議，其目的是降低網(wǎng)絡(luò)通信的延遲，提供更好的用戶互動體驗。

QUIC 會在應用層上自己快速建立連接、減少重傳時延、自適應擁塞控制，是應用層定制化的代表。

2、流媒體協(xié)議

直播通常都使用 RTMP（Real Time Messaging Protocol，實時消息傳輸協(xié)議），基于 TCP。但對于直播來說實時性比較重要，寧可丟包，也不要卡頓。

對于視頻播放來說，有的包可以丟，有的包不能，因為在視頻的連續(xù)幀李，有的幀重要，有的不重要，如果一定要丟包，隔幾個丟一個，其實看視頻的人不會感知，但是如果是連續(xù)丟幀，就能感知到了，因此在網(wǎng)絡(luò)不好的情況下，應用一般會選擇性地丟幀。

當網(wǎng)絡(luò)不好的時候，TCP 會主動降低發(fā)送速度，這對本來當時就卡的視頻來講無疑是雪上加霜。TCP 應該讓應用層馬上重傳，而不是主動讓步。因此，很多直播應用都基于 UDP 實現(xiàn)了自己的視頻傳輸協(xié)議。

3、實時游戲

維護 TCP 連接需要在內(nèi)核維護一些數(shù)據(jù)結(jié)構(gòu)，但是一臺機器能夠支撐的 TCP 連接數(shù)目是有限的。由于 UDP 是沒有連接的，所以在異步 I/O 機制引入之前，UDP 常常是應對海量客戶端連接的策略。

在游戲?qū)崟r要求比較嚴格的情況下，可以采用自定義的可靠 UDP 來傳輸數(shù)據(jù)包，通過使用自定義重傳策略，能夠包丟包產(chǎn)生的延遲降到最低，盡量減少網(wǎng)絡(luò)問題對游戲造成的影響。

4、物聯(lián)網(wǎng)

Google 旗下的 Nest 建立了 Thread Group，推出了物聯(lián)網(wǎng)通信協(xié)議 Thread，該協(xié)議就是基于 UDP 的。

5、移動通信領(lǐng)域

在 4G 網(wǎng)絡(luò)里，通過移動通信傳輸數(shù)據(jù)面對的協(xié)議 GTP-U 就是基于 UDP 的。關(guān)于移動網(wǎng)絡(luò)的相關(guān)知識我們將在下一篇進行講解。

3、TCP(Transmission Control Protocol) 傳輸控制協(xié)議初識

1、TCP 報文詳解

1）、特點

• 1）、「面向連接：面向連接就像是打電話時需要先撥通電話」。
• 2）、「點對點通信」。
• 3）、「可靠的傳輸服務」。
• 4）、「全雙工通信：兩個設(shè)備在連接時，它們都可以同時地發(fā)送數(shù)據(jù)與接收數(shù)據(jù)」。
• 5）、「面向字節(jié)流的協(xié)議：TCP 處理的是一個一個的字節(jié)，所以TCP 很可能會取出數(shù)據(jù)中的某一段進行傳輸，而剩下的數(shù)據(jù)會把它放到第二個及之后的 TCP 報文中進行傳輸。因此 TCP 協(xié)議可能會對用戶的數(shù)據(jù)進行合并或分拆」。

TCP 的缺點在于 「傳輸效率慢，因為它需要建立連接、發(fā)送確認包等等」。

2）、報文首部字段

序號

• 表示范圍為 0 ~ 2^32 - 1。
• 「因為 TCP 是面向字節(jié)流的，所以每一個字節(jié)都有一個與之對應的序號」。
• 「TCP 數(shù)據(jù)報的序號就是數(shù)據(jù)報中第一個字節(jié)的序號」。

確認號

• 表示范圍為 0 ~ 2^32 - 1。
• 「表示期望收到數(shù)據(jù)的首字節(jié)序號，如果確認號為 S，則表示 S - 1 序號的數(shù)據(jù)都已經(jīng)收到了」。

數(shù)據(jù)偏移

• 「占4位：0 ~ 15，單位為：32位字。=> 首部范圍為20~60字節(jié)」。
• 「TCP 數(shù)據(jù)偏移首部的距離，因為 TCP 選項的大小是不確定的，所以需要此數(shù)據(jù)項」。

TCP 標記

「占6位」，每位都有不同的含義。

標記含義

URG(Urgent)	緊急位，URG = 1，表示緊急數(shù)據(jù)。
ACK(Acknowledgement	確認位，ACK = 1，確認號才生效。
PSH(Push)	推送位，PSH = 1，表示需要盡快地把數(shù)據(jù)交付給應用層。
RST(Reset)	重置位，RST = 1，重新建立連接。
SYN(Synchronization)	同步位，SYN = 1表示連接請求報文。
FIN(Finish)	終止位，FIN = 1表示釋放連接。

窗口

• 占16位：0 ~ 2 ^ 16 - 1。
• 「窗口指明允許對方發(fā)送的數(shù)據(jù)量。例如：確認號為201，窗口為300，那么可以接收序號的范圍為 201 ~ 500」。

校驗和

與 UDP 類似，用來檢測 TCP 的數(shù)據(jù)在傳輸過程中是否出錯。

緊急指針

• 「緊急數(shù)據(jù)（URG = 1）」。
• 「指定緊急數(shù)據(jù)在報文中的位置」。

TCP 選項

• 「最多40字節(jié)」。
• 「支持未來的擴展」。

4、可靠傳輸?shù)幕驹?/h2>

1）、停止等待協(xié)議

當發(fā)送方發(fā)送一個消息時，接收方接收到了并將確認信息發(fā)給發(fā)送方，這個過程中 「發(fā)送方需要停止等待接收方的確認信息」。

超時重傳

當消息發(fā)送出去后，發(fā)送方并沒有在超時時間內(nèi)接收到接收方的確認消息或者超時了之后消息才收到，此時會向發(fā)送方重新發(fā)送該消息。超時重傳**「通常都會處理三種異常情況」**，如下所示：

• 1）、「發(fā)送的消息在路上丟失了」。
• 2）、「確認的消息在路上丟失了」。
• 3）、「確認的消息超時了才到」。

超時定時器（超時重傳定時器）

• 1）、「每發(fā)送一個消息，都需要設(shè)置一個超時定時器」。
• 2）、「主要應用在 TCP 的可靠傳輸協(xié)議里面，它是為了控制可能發(fā)生丟失的報文而設(shè)計的定時器，當 TCP 協(xié)議發(fā)送端發(fā)送一個報文時，就會為該報文設(shè)置一個超時定時器」。
• 3）、「如果超時定時器在結(jié)束之前收到了來自接收端對該報文段的確認，則撤銷這個定時器」。
• 4）、「如果在超時定時器結(jié)束之前仍然沒有收到來自接收端對該報文段的確認（超時），則認為這個報文可能已經(jīng)丟棄，發(fā)送端會重新發(fā)送該報文，并設(shè)置一個超時定時器」。
• 5）、「需要注意的是，發(fā)送端在超時定時器撤銷之前，必須繼續(xù)緩存已發(fā)送未確認的報文，直到發(fā)送端收到了來自接收端的確認」。

特點

• 1、「停止等待協(xié)議是最簡單的可靠傳輸協(xié)議」。
• 2、「對信道的利用效率不高」。

?

既然單個發(fā)送和確認效率低，那么我們可以批量發(fā)送和確認嗎？

?

2）、連續(xù) ARQ(Automatic Repeat Request) 自動重傳請求協(xié)議

ARQ 是對停止等待協(xié)議的改進，可以 「大幅提升信道利用率」 的一個協(xié)議。

滑動窗口

• 1）、「窗口中的數(shù)據(jù)都可以發(fā)送」。
• 2）、「通過移動窗口的方式來標識沒有接收到確認的消息」。
• 3）、「采用了累積確認的方式，并不需要對每一個消息都進行確認」。

累積確認

只要我收到第5個消息的確認了，就表示第 1 ~ 5 個消息接收方都收到了。

5、TCP 協(xié)議的可靠傳輸

TCP 的可靠傳輸基于連續(xù) ARQ 協(xié)議。

• 1）、「滑動窗口」
• 2）、「累積確認」
• 3）、「選擇重傳」

選擇重傳

• 1）、「選擇重傳需要制定需要重傳的字節(jié)」。
• 2）、「每一個字節(jié)都有唯一的32位序號（4字節(jié)）」。
• 3）、「要重傳的數(shù)據(jù)是存儲在 TCP 選項 中，其中最多只能存儲10個序號，即 5 個范圍段的信息」。
• 4）、「選擇重傳的是一個信息邊界，即一段字節(jié)流，例如：傳送 1000 ~ 1200， 2000 ~ 3000 這個范圍內(nèi)的信息」。

6、TCP 協(xié)議的流量控制

流量控制指的是 「讓發(fā)送方發(fā)送速率不要太快。TCP 使用了滑動窗口來實現(xiàn)流量控制」。

1）、滑動窗口

• rwnd = 300 ，表示窗口大小為300。
• 占16位：0 ~ 2 ^ 16 - 1。
• 窗口指明允許對方發(fā)送的數(shù)據(jù)量。例如：確認號為201，窗口為300，那么可以接收序號的范圍為 201 ~ 500。
• 「接收方可以調(diào)整滑動窗口的大小來控制發(fā)送方發(fā)送數(shù)據(jù)的效率」。
• 「當接收方將 rwnd 從0調(diào)整為1000并將這個信息發(fā)送給發(fā)送方時，消息丟失了，這就會導致發(fā)送方和接收方都會等待，形成一個死鎖局面」。

?

如何解決這種死鎖局面呢？

?

2）、堅持定時器

堅持定時器是使用滑動窗口進行流量控制的時候設(shè)置的。

• 1）、「當接收到窗口為0的消息，則啟動堅持定時器」。
• 2）、「堅持定時器每隔一段時間發(fā)送一個窗口探測報文」。

7、TCP 協(xié)議的擁塞控制

問題

• 一條數(shù)據(jù)鏈路經(jīng)過非常多的設(shè)備。
• 數(shù)據(jù)鏈路中各個部分都有可能成為網(wǎng)絡(luò)傳輸?shù)钠款i。

流量控制與擁塞控制的區(qū)別

「不同于流量控制考慮的是點對點的通信量的控制，擁塞控制考慮的是整個網(wǎng)絡(luò)，是一個全局性的考慮」。

?

如何判斷是否發(fā)生了擁塞？

?

「簡單地認為報文超時就發(fā)生了擁塞」。

TCP 的擁塞控制

1）、慢啟動算法

• 「由小到大逐漸增加發(fā)送數(shù)據(jù)量（呈指數(shù)增長，例如：1、2、4、8、16）」。
• 「每收到一個報文確認，就加一」。
• 「超過慢啟動閾值(ssthresh) 則不再增長」。

2）、擁塞避免算法

• 「維護一個擁塞窗口的變量」。
• 「只要網(wǎng)絡(luò)不擁塞，就試探著將擁塞窗口調(diào)大」。

「TCP 的擁塞控制在前期使用了 慢啟動 算法對窗口大小進行指數(shù)增長，直到超過慢啟動閾值(ssthresh)則不再增長，后續(xù)則啟動擁塞避免算法對窗口進行線性增長」。

8、TCP 鏈接的建立 - 三次握手

為什么發(fā)送方要發(fā)出第三個確認報文呢？

• 1）、「已經(jīng)失效的連接請求報文傳送到對方，引起錯誤：假設(shè)兩次握手就可以，失效的鏈接請求報文就會被接收并建立了重復的連接。當使用三次握手時，比較慢到達接收方的報文也會發(fā)送一個確認給發(fā)送方，但是發(fā)送方已經(jīng)進行了第三次握手了，因此發(fā)送方會忽略掉第二次的確認，不會進行任何的操作」。
• 2）、「因為信道不可靠，而 TCP 想在不可靠信道上建立可靠地傳輸，那么三次通信是理論上的最小值。（而 UDP 則不需建立可靠傳輸，因此 UDP 不需要三次握手）」
• 3）、「因為雙方都需要確認對方收到了自己發(fā)送的序列號，確認過程最少要進行三次通信」。

9、TCP 鏈接的釋放 - 四次揮手

1）、等待計時器

• 會等待 2MSL 時間 => 4分鐘。
• 時間等待定時器是由是在四次揮手時由主動關(guān)閉 TCP 連接的一方設(shè)置的，它主要是為了 「保證主動關(guān)閉方在對最后一個 FIN 報文（第三次揮手）發(fā)送確認的報文可以到達接收方」。
• MSL(Max Segment Lifetime): 最長報文段壽命。MSL 建議設(shè)置為2分鐘。

2）、為什么需要等待 2MSL？

• 1）、「因為最后一個報文沒有確認，我們需要確保發(fā)送方的 ACK 可以達到接收方，如果 2MSL 時間內(nèi)沒有收到，則接收方會重發(fā)」。
• 2）、「2MSL 時間可以保證當發(fā)送方?jīng)]有收到確認時，接收方可以再次發(fā)送 FIN 報文，并且接收方可以再次收到并重新發(fā)送確認，所以 2MSL 的時間可以保證連接正常結(jié)束」。
• 3）、「確保當前連接的所有報文都已經(jīng)過期了」。

10、TCP 與UDP 的區(qū)別

• 1）、「UDP 通常用于多媒體信息分發(fā)，即視頻、語音、實時信息 等等。而 TCP 通常用于可靠信息的傳輸，應用場景包括金融交易、可靠通信、MQ 等等」。
• 2）、「TCP 面向連接，UDP 是無連接的」。
• 3）、「TCP 提供可靠的服務，也就是說，通過 TCP 連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復，且按序到達；UDP 盡最大努力交付，即不保證可靠交付」。
• 4）、「TCP 的邏輯通信信道是全雙工的可靠信道；UDP 則是不可靠信道」。
• 5）、「每一條 TCP 連接只能是點到點的；UDP 支持一對一，一對多，多對一和多對多的交互通信」。
• 6）、「TCP 面向字節(jié)流（可能出現(xiàn)黏包問題），實際上是 TCP 把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流；UDP 是面向報文的（不會出現(xiàn)黏包問題）」。
• 7）、「UDP 沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應用很有用，如 IP 電話，實時視頻會議等）」
• 8）、「TCP 首部開銷20字節(jié)；UDP 的首部開銷小，只有 8 個字節(jié)」。

11、套接字(Socket)

我們可以使用端口（Port）來標記不同的網(wǎng)絡(luò)進程，而端口使用了16比特位表示(0~65535)。

1）、Socket 概念

• 套接字是一個抽象的概念，表示 TCP 連接的一端。
• 通過套接字可以進行數(shù)據(jù)的發(fā)送或接收。
• TCP = { Socket1:Socket2} = {{IP:Port}{IP:Port}}，可以看到，TCP 由兩個套接字組成。

2）、Socket 編程

服務端編程

• 1）、「創(chuàng)建 Socket」。
• 2）、「綁定 Socket」。
• 3）、「監(jiān)聽 Socket」。
• 4）、「接收 & 處理信息」。

其代碼如下所示：

import socketdef server():# 1、創(chuàng)建 Sockets = socket.socket()host = "127.0.0.1"port = 5678# 2、綁定 Sockets.bind(host, port)# 3、監(jiān)聽s.listen()# 4、發(fā)送數(shù)據(jù)while True:c, addr = s.accept()print("connect addr", addr)c.send(b'Socket Study.')c.close()

客戶端編程

• 1）、「創(chuàng)建 Socket」。
• 2）、「連接 Socket」。
• 3）、「發(fā)送消息」。

其代碼如下所示：

import socketdef client(i):# 1、創(chuàng)建 Sockets = socket.socket()# 2、連接 Sockets.connect(('127.0.0.1', 5678))# 3、接收消息print("Received message:%s, client Id:%d" % (s.recv(1024), i))s.close()if __name__ == '__main__':for i in range(10):client(i)

單機通信更推薦使用域 Socket，相比網(wǎng)絡(luò)通信數(shù)據(jù)需要在整個協(xié)議棧走一輪，域 Socket 它的處理流程更加簡單，系統(tǒng)消耗更加小。此外，如果對 Socket IO 實現(xiàn)機制有興趣的同學可以 點擊此處.

12、TCP 協(xié)議細節(jié)之 TCP 協(xié)議的四個定時器

• 1）、「超時定時器」
• 2）、「堅持定時器」
• 3）、「時間等待定時器」
• 4）、「保活定時器」：服務端一般都會設(shè)置一個保活定時器，它是為了保活 TCP 連接而設(shè)計的，可以防止 TCP 連接的兩端出現(xiàn)長時間的空閑，當一方出現(xiàn)變化或故障時，另一方?jīng)]有察覺的情況。 當服務端每次收到對方的數(shù)據(jù)則重置這個定時器，如果定時器超時，則會發(fā)送彈出報文段，以此探測客戶端是否在線，如果沒有收到響應的話，那么則認為客戶端已經(jīng)斷開連接了，因此服務端也會終止這個鏈接。現(xiàn)如今，很多的分布式系統(tǒng)都會使用保活定時器來檢測其它節(jié)點是否在線還是已經(jīng)故障，或者其它節(jié)點也會每隔一段時間向主節(jié)點上報心跳信息以證明在線。

13、TCP 在三次握手的時候，IP 層和 MAC(Medium Access Control) 層在做什么呢？

其實 TCP 每發(fā)送一個消息，都會帶著 IP 層和 MAC 層。因為 TCP 每發(fā)送一個消息，IP 層和 MAC 層的所有機制都要運行一篇。

需要注意的是，「只要是在網(wǎng)絡(luò)上跑的包，都是完整的。可以有下層沒上層，絕對不可能有上層沒下層。所以，對 TCP 來說，無論是三次握手還是重試，只要想包網(wǎng)絡(luò)包發(fā)送出去，就要有 IP 層和 MAC 層，不然是發(fā)不出去的」。
原文：jsonchao

總結(jié)

以上是生活随笔為你收集整理的究极深入Android网络优化——网络筑基（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。