九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)點(diǎn)整理

一、計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

OSI的七層協(xié)議體系結(jié)構(gòu)的概念清除，理論也比較完整，但它既復(fù)雜又不實(shí)用。

TCP/IP是一個(gè)四層體系結(jié)構(gòu)，TCP/IP體系結(jié)構(gòu)雖然簡(jiǎn)單，但它現(xiàn)在卻得到了非常廣泛的使用。

在學(xué)習(xí)中我們采用折中的辦法，學(xué)習(xí)具有五層協(xié)議的原理體系結(jié)構(gòu)

點(diǎn)擊加載圖片

二、五層協(xié)議原理體系結(jié)構(gòu)

物理層

物理層是原理體系結(jié)構(gòu)的最底層，負(fù)責(zé)完成計(jì)算機(jī)網(wǎng)絡(luò)中最基礎(chǔ)的任務(wù)，即在傳輸媒體上傳送比特流。

物理層作用：

實(shí)現(xiàn)計(jì)算機(jī)結(jié)點(diǎn)之間比特流的透明傳輸。（將數(shù)字信號(hào)轉(zhuǎn)換為電信號(hào)）

規(guī)定傳輸媒體接口標(biāo)準(zhǔn)，屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異，使數(shù)據(jù)鏈路層不必關(guān)心網(wǎng)絡(luò)的具體傳輸介質(zhì)。

為數(shù)據(jù)鏈路層提供服務(wù)。

數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層位于物理層之上，網(wǎng)絡(luò)層之下，將網(wǎng)絡(luò)層傳下的IP數(shù)據(jù)報(bào)封裝成 幀，通過差錯(cuò)控制、流量控制等方法，將分組從鏈路的一端傳送到另一端，丟棄有差錯(cuò)的幀保證物理層收到的分組是無差錯(cuò)的信息。

數(shù)據(jù)鏈路層的幾個(gè)基本方法：

封裝成幀：將網(wǎng)絡(luò)層的IP數(shù)據(jù)報(bào)加頭加尾，封裝成幀，幀中包括源MAC地址和目的MAC地址。

透明傳輸：零比特填充，轉(zhuǎn)義字符。

差錯(cuò)檢測(cè)：接收者檢測(cè)錯(cuò)誤時(shí)，如果發(fā)現(xiàn)差錯(cuò)，丟棄該幀。差錯(cuò)控制方法有CRC循環(huán)冗余校驗(yàn)

流量控制: 控制發(fā)送的傳輸速度，使得接收放來得及接收。傳輸層TCP也有流量控制功能，但是TCP是端到端的流量控制，鏈路層是點(diǎn)到點(diǎn)（比如一個(gè)路由器到下一個(gè)路由器）

網(wǎng)絡(luò)層（IP層）

網(wǎng)絡(luò)層負(fù)責(zé)為分組交換網(wǎng)上的不同 主機(jī)間 提供通信服務(wù)。

實(shí)現(xiàn)網(wǎng)絡(luò)地址與物理地址的轉(zhuǎn)換，并通過路由選擇算法為分組通過通信子網(wǎng)選擇最適當(dāng)?shù)穆窂健＞W(wǎng)絡(luò)層傳輸?shù)臄?shù)據(jù)單元為 IP數(shù)據(jù)報(bào)（數(shù)據(jù)報(bào)）

運(yùn)輸層（傳輸層）

運(yùn)輸層負(fù)責(zé)向兩臺(tái)主機(jī)中進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。

運(yùn)輸層主要的兩個(gè)運(yùn)輸層協(xié)議：

傳輸控制協(xié)議（TCP）:提供面向連接的，可靠的數(shù)據(jù)傳輸服務(wù)，其數(shù)據(jù)傳輸?shù)膯挝皇?strong>報(bào)文段

用戶數(shù)據(jù)報(bào)協(xié)議（UDP）:提供無連接的，盡最大努力的數(shù)據(jù)傳輸服務(wù)（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?，其?shù)據(jù)傳輸?shù)膯挝皇?strong>用戶數(shù)據(jù)報(bào)

應(yīng)用層

為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)，完成和實(shí)現(xiàn)用戶請(qǐng)求的各種服務(wù)。

三、五層協(xié)議模型

點(diǎn)擊加載圖片

該模型展示了主機(jī)1 向 主機(jī)2 發(fā)送數(shù)據(jù)時(shí)數(shù)據(jù)入?yún)f(xié)議棧和出協(xié)議棧的過程

入棧過程：數(shù)據(jù)發(fā)送方每層不斷的封裝首部和尾部，添加一些傳輸?shù)男畔?，確保能傳輸?shù)侥康牡亍?/p>

出棧過程：數(shù)據(jù)接收方每層不斷的拆除首部和尾部，得到最終傳輸?shù)臄?shù)據(jù)。

四、數(shù)據(jù)鏈路層

4.1 封裝成幀

點(diǎn)擊加載圖片

數(shù)據(jù)鏈路層以幀為單位傳輸和數(shù)據(jù)處理，網(wǎng)絡(luò)層的IP數(shù)據(jù)報(bào)必須向下傳遞到數(shù)據(jù)鏈路層，成為幀的數(shù)據(jù)部分，同時(shí)它的前面和后面同時(shí)添加了幀首部和幀尾部，封裝成一個(gè)完整的幀。幀的長度等于幀的數(shù)據(jù)部分長度加上幀首部和幀尾部的長度。

4.2 透明傳輸

點(diǎn)擊加載圖片

每個(gè)幀首和幀尾都為特定的字符，當(dāng)我們要傳輸?shù)臄?shù)據(jù)中出現(xiàn)了與幀首幀尾相同的字符時(shí)，原始數(shù)據(jù)就會(huì)被誤判幀首幀尾，這時(shí)候就需要將數(shù)據(jù)部分中與幀首幀尾相同的字符用一個(gè)轉(zhuǎn)義字符來填充進(jìn)行轉(zhuǎn)義，如果原始數(shù)據(jù)中也出現(xiàn)了轉(zhuǎn)義字符，這時(shí)候轉(zhuǎn)義字符也用轉(zhuǎn)義字符轉(zhuǎn)義，從而實(shí)現(xiàn)原始數(shù)據(jù)的透明傳輸

4.3 差錯(cuò)檢測(cè)

現(xiàn)實(shí)中的通信鏈路都不會(huì)是理想的，比特在傳輸過程中可能會(huì)產(chǎn)生差錯(cuò)：1可能會(huì)變成0，而0也可能變成1.這就叫做比特差錯(cuò)，為了防止這種差錯(cuò)，在數(shù)據(jù)鏈路層通常使用 **循環(huán)冗余校驗(yàn)（CRC）**技術(shù)進(jìn)行差錯(cuò)檢測(cè)

循環(huán)冗余校驗(yàn)計(jì)算方法：加法不進(jìn)位，減法不借位，等價(jià)于按位異或（XOR）,乘以2和除以2都等價(jià)于左/右移位。

點(diǎn)擊加載圖片

上圖為循環(huán)冗余校驗(yàn)原理的例子

若得出的余數(shù)R=0,則判定這個(gè)幀沒有差錯(cuò)，就接收。

若余數(shù)R≠0，則判斷這個(gè)幀有差錯(cuò)(但無法確定究竟是哪一位或哪幾位出現(xiàn)了差錯(cuò)),就丟棄。

五、網(wǎng)絡(luò)層（IP層）

5.1 IP地址及編址方式

IP地址

整個(gè)因特網(wǎng)就是一個(gè)單一的邏輯網(wǎng)絡(luò)。IP地址就是給英特網(wǎng)上的每一個(gè)主機(jī)(或路由器)的每一個(gè)接口分配一個(gè)在全世界范圍是唯一的32的標(biāo)識(shí)符。IP地址的結(jié)構(gòu)使我們可以在因特網(wǎng)上很方便的進(jìn)行尋址。

為了提高可讀性，我們常常把32位的IP地址中的每8位用其等效的十進(jìn)制數(shù)字表示，并且在這些數(shù)字之間加上一個(gè)點(diǎn)。這種表示稱為點(diǎn)分十進(jìn)制記法

如下圖：

點(diǎn)擊加載圖片

編址方式

分類編址：這是最基本的方法 ；IP地址::={<網(wǎng)絡(luò)號(hào)>,<主機(jī)號(hào)>} 缺點(diǎn)：地址分配不靈活，要么太大浪費(fèi)空間，要么太小不夠用。

劃分子網(wǎng)：在分類編址上的一個(gè)改進(jìn)； IP地址::={<網(wǎng)絡(luò)號(hào)>,<子網(wǎng)號(hào)>,<主機(jī)號(hào)>} 缺點(diǎn)：數(shù)量巨大的C類地址因?yàn)榈刂房臻g太小并沒有得到充分利用。

無分類編址：目前因特網(wǎng)使用的編址方法。IP地址::={<網(wǎng)絡(luò)前綴>,<主機(jī)號(hào)>}

下面重點(diǎn)介紹一下無分類編址：

無分類編址的網(wǎng)絡(luò)前綴是不定長的，用來代替分類編址的’'網(wǎng)絡(luò)號(hào)’'并指明網(wǎng)絡(luò)，后面的部分則用來指明主機(jī)。

網(wǎng)絡(luò)前綴計(jì)算方式：只需要將子網(wǎng)掩碼和IP地址進(jìn)行逐位的“與”運(yùn)算，就可以得出其網(wǎng)絡(luò)地址（主機(jī)號(hào)全為0的地址）。

相同IP地址和不同的子網(wǎng)掩碼得到的網(wǎng)絡(luò)地址：

點(diǎn)擊加載圖片

點(diǎn)擊加載圖片

這兩個(gè)例子說明，相同的IP地址和不同的子網(wǎng)掩碼可以得出相同的網(wǎng)絡(luò)地址，但是不同的子網(wǎng)掩碼效果是不同的。雖然這兩個(gè)例子中網(wǎng)絡(luò)地址空間起始地址是一樣的，但是最大地址是不一樣的，各自容納的最大主機(jī)數(shù)都是不一樣的。

5.2 地址解析協(xié)議（ARP）

我們知道，網(wǎng)絡(luò)層使用的是IP地址，但在具體物理網(wǎng)絡(luò)的鏈路上傳送數(shù)據(jù)幀時(shí)，最終還是必須使用該物理網(wǎng)絡(luò)的物理地址。但I(xiàn)P地址和物理網(wǎng)絡(luò)地址又不是單一的映射關(guān)系，這時(shí)候就需要用到 地址解析協(xié)議(ARP)

ARP地址解析協(xié)議工作原理

ARP是根據(jù)IP地址獲取MAC地址的一種協(xié)議，核心原理就是廣播發(fā)送ARP請(qǐng)求，單播發(fā)送ARP響應(yīng)。

每個(gè)主機(jī)都有自己的ARP高速緩存，在緩存中都存放有一個(gè)從IP地址到物理地址的映射表，并且這個(gè)映射表不斷動(dòng)態(tài)更新。(新增或超時(shí)刪除)

當(dāng)源主機(jī)要發(fā)送數(shù)據(jù)時(shí)，先檢查ARP列表中是否有該IP地址對(duì)應(yīng)的MAC地址，如果有，則直接發(fā)送數(shù)據(jù)；如果沒有，就向本網(wǎng)段的所有主機(jī)發(fā)送ARP數(shù)據(jù)包，用于查詢目的主機(jī)的MAC地址，該數(shù)據(jù)包包括的內(nèi)容有：源主機(jī)IP地址，源主機(jī)MAC地址，目的主機(jī)的IP。

當(dāng)本網(wǎng)絡(luò)的所有主機(jī)收到該ARP數(shù)據(jù)包時(shí)，首先檢查該包中的IP是否與自身IP相同。若不同，則丟棄數(shù)據(jù)包，如果是，則先取出該數(shù)據(jù)包的源主機(jī)IP地址和MAC地址寫入到自身的ARP高速緩存映射列表中。如果已經(jīng)存在，就覆蓋。然后將自己的MAC地址寫入到ARP響應(yīng)包中，告訴源主機(jī)自己的IP地址和MAC地址。

源主機(jī)收到ARP響應(yīng)包后,將目的主機(jī)的IP地址和MAC地址寫入ARP高速緩存映射列表中，并利用該信息發(fā)送數(shù)據(jù)，如果源主機(jī)一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

5.3 ICMP協(xié)議

因特網(wǎng)控制報(bào)文協(xié)議，用于在IP主機(jī)、路由器之間傳遞控制信息(控制信息是指網(wǎng)絡(luò)通不通，主機(jī)是否可達(dá)，路由器是否可用等網(wǎng)絡(luò)本身的信息)，確認(rèn)IP包是否成功到達(dá)目的地址。因?yàn)镮P協(xié)議并不是一個(gè)可靠的協(xié)議，它不保證數(shù)據(jù)被送達(dá)，當(dāng)傳送IP數(shù)據(jù)包發(fā)生錯(cuò)誤，比如主機(jī)不可達(dá)、路由不可達(dá)等等，ICMP協(xié)議將會(huì)把錯(cuò)誤信息封包，然后傳回給主機(jī)，給主機(jī)一個(gè)處理錯(cuò)誤的機(jī)會(huì)。

5.3.1 ICMP報(bào)文的種類

ICMP報(bào)文的種類有兩種，即ICMP差錯(cuò)報(bào)告報(bào)文和ICMP詢問報(bào)文

ICMP差錯(cuò)報(bào)告報(bào)文

終點(diǎn)不可達(dá)：當(dāng)路由器或主機(jī)不能交付數(shù)據(jù)報(bào)時(shí)，就向源點(diǎn)發(fā)送終點(diǎn)不可達(dá)報(bào)文。具體可再根據(jù)ICMP的代碼字段細(xì)分為目的網(wǎng)絡(luò)不可達(dá)、目的主機(jī)不可達(dá)、目的協(xié)議不可達(dá)、目的端口不可達(dá)、目的網(wǎng)絡(luò)未知、目的主機(jī)未知等。

源點(diǎn)抑制：當(dāng)路由器或主機(jī)由于擁塞而丟棄數(shù)據(jù)報(bào)時(shí)，就向源點(diǎn)發(fā)送源點(diǎn)抑制報(bào)文，使源點(diǎn)知道應(yīng)該應(yīng)該把數(shù)據(jù)報(bào)的發(fā)送速率放慢。

時(shí)間超過：當(dāng)路由器收到一個(gè)IP數(shù)據(jù)報(bào)，若目的地址不是自己，會(huì)將其TTL減1再轉(zhuǎn)發(fā)出去，但當(dāng)TTL減為零時(shí)，除丟棄該數(shù)據(jù)報(bào)外，還要向源點(diǎn)發(fā)送超時(shí)差錯(cuò)報(bào)告報(bào)文。另外，當(dāng)終點(diǎn)在預(yù)先規(guī)定的時(shí)間內(nèi)不能收到一個(gè)數(shù)據(jù)報(bào)的全部數(shù)據(jù)報(bào)的全部數(shù)據(jù)報(bào)片時(shí)，就把已收到的數(shù)據(jù)報(bào)片丟棄，也會(huì)向源點(diǎn)發(fā)送超時(shí)差錯(cuò)報(bào)告報(bào)文。

參數(shù)問題：當(dāng)路由器或目的主機(jī)收到的數(shù)據(jù)報(bào)的首部中有的字段的值不正確時(shí)，就丟棄該數(shù)據(jù)報(bào)，并向源點(diǎn)發(fā)送參數(shù)問題報(bào)文。

改變路由(重定向):路由器把改變路由報(bào)文發(fā)送給主機(jī)，讓主機(jī)知道下次應(yīng)將數(shù)據(jù)報(bào)發(fā)送給另外的路由器(可通過更好的路由)。

ICMP詢問報(bào)文

會(huì)送請(qǐng)求和回答：ICMP回送請(qǐng)求報(bào)文是由主機(jī)或路由器向一個(gè)特定的目的主機(jī)發(fā)出的詢問。收到此報(bào)文的主機(jī)必須給源主機(jī)或路由器發(fā)送ICMP回送回答報(bào)文。這種詢問報(bào)文用來測(cè)試目的站是否可達(dá)及了解其有關(guān)狀態(tài)。

時(shí)間戳請(qǐng)求和回答：ICMP時(shí)間戳請(qǐng)求報(bào)文是請(qǐng)求某個(gè)主機(jī)或路由器回答當(dāng)前的日期和時(shí)間。在ICMP時(shí)間戳回答報(bào)文中有一個(gè)32位的字段，其中寫入的整數(shù)代表從1900年起1月1日到當(dāng)前時(shí)刻一個(gè)多少秒。時(shí)間戳請(qǐng)求與回答可用來進(jìn)行時(shí)鐘同步和測(cè)量時(shí)間。

5.4 路由選擇協(xié)議

內(nèi)部網(wǎng)關(guān)協(xié)議(IGP)

內(nèi)部網(wǎng)關(guān)協(xié)議即在一個(gè)自治系統(tǒng)內(nèi)部使用的路由選擇協(xié)議，而這與在互聯(lián)網(wǎng)中的其他自治系統(tǒng)選用什么路由選擇協(xié)議無關(guān)。目前這類選擇協(xié)議很多，如RIP和OSPF協(xié)議。

RIP:是一種動(dòng)態(tài)路由選擇協(xié)議，基于距離矢量算法，使用“跳數(shù)”來衡量到達(dá)目標(biāo)地址的路由距離，并且只與自己相鄰的路由器交換信息，范圍限制在15跳之內(nèi)。

OSPF:開放最短路徑優(yōu)先協(xié)議，使用Dijskra算法計(jì)算出到達(dá)每一網(wǎng)絡(luò)的最短路徑，并在檢測(cè)到 鏈路的情況發(fā)生變化時(shí)（如鏈路失效），就執(zhí)行該算法快速收斂到新的無環(huán)路拓?fù)洹?/p>

外部網(wǎng)關(guān)協(xié)議(EGP)

若源主機(jī)和目的主機(jī)處在不同的自治系統(tǒng)中(這兩個(gè)自治系統(tǒng)可能使用不同的內(nèi)部網(wǎng)關(guān)協(xié)議)，就需要在自治系統(tǒng)之間進(jìn)行路由選擇，使用一種協(xié)議將路由信息從一個(gè)自治系統(tǒng)傳遞到另一個(gè)自治系統(tǒng)中。這樣的協(xié)議就是外部網(wǎng)關(guān)協(xié)議EGP。目前因特網(wǎng)使用的外部網(wǎng)關(guān)協(xié)議就是BGP的版本4。

BGP:邊界網(wǎng)關(guān)協(xié)議，BGP 是力求尋找一條能夠到達(dá)目的網(wǎng)絡(luò) 且 較好的路由，而并非要尋找一條最佳路由。BGP采用路徑向量路由選擇協(xié)議。

自治系統(tǒng)之間的路由選擇也叫作域間路由選擇，而在自治系統(tǒng)內(nèi)部的路由選擇叫作域內(nèi)路由選擇

六、傳輸層(運(yùn)輸層)

傳輸層主要提供不同主機(jī)上進(jìn)程間 邏輯通信+可靠傳輸 或者 不可靠傳輸?shù)墓δ堋?/p>

6.1 TCP 和UDP

6.1.1 傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)報(bào)協(xié)議(UDP)的區(qū)別。

TCP是面向字節(jié)流的，基本傳輸單位是TCP報(bào)文段；UDP是面向報(bào)文的，基本傳輸單位是用戶數(shù)據(jù)報(bào)；

面向字節(jié)流：應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊(大小不等)，但TCP把應(yīng)用程序看成一連串的無結(jié)構(gòu)的字節(jié)流。TCP有一個(gè)緩沖，當(dāng)應(yīng)用程序傳送的數(shù)據(jù)塊太長，TCP就可以把它劃分短一些再傳送。

面向報(bào)文：面向報(bào)文的傳輸方式是應(yīng)用層交給UDP多長的報(bào)文，UDP就照樣發(fā)送，因此，應(yīng)用程序必須選擇合適大小的報(bào)文。太大會(huì)造成IP層對(duì)數(shù)據(jù)進(jìn)行分片，降低IP層效率；太小會(huì)造成首部相對(duì)較大，降低IP層效率。

TCP注重安全可靠性，連接雙方在通信前要進(jìn)行三次握手建立連接。UDP是面向無連接的，使用最大努力交付，即不保證可靠交互。

UDP不需要等待，所以數(shù)據(jù)傳輸較快，TCP傳輸效率相對(duì)較低。

TCP首部開銷是20個(gè)字節(jié)，UDP首部開銷是8個(gè)字節(jié)，UDP減少了網(wǎng)絡(luò)傳輸?shù)牟糠珠_銷。

TCP有流量控制和擁塞控制，UDP沒有流量控制和擁塞控制。

TCP支持點(diǎn)對(duì)點(diǎn)通信，提供全雙工通信，不提供廣播或者多播服務(wù)；UDP支持一對(duì)一，一對(duì)多，多對(duì)一，多對(duì)多的通信模式。

6.1.2 TCP和UDP的適用場(chǎng)景

當(dāng)對(duì)網(wǎng)絡(luò)通信質(zhì)量要求不高，并且要求網(wǎng)絡(luò)通信速度盡量的快，這時(shí)就可以使用UDP。比如即時(shí)通信：語音、視頻、直播等。

當(dāng)對(duì)網(wǎng)絡(luò)通信質(zhì)量有要求時(shí)，要求整個(gè)數(shù)據(jù)準(zhǔn)確無誤可靠的傳遞給對(duì)方，這時(shí)就適合使用TCP協(xié)議，一般用于文件傳輸、發(fā)送和接收郵件等場(chǎng)景。比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議，POP、SMTP等郵件傳輸?shù)膮f(xié)議都是使用的TCP協(xié)議。

使用UDP和TCP協(xié)議的各種應(yīng)用和應(yīng)用層協(xié)議：

6.1.3 TCP的報(bào)文格式

點(diǎn)擊加載圖片

源端口和目的端口：分別占用16位，指發(fā)送方應(yīng)用程序的端口和目的方應(yīng)用程序的端口號(hào)，通過 IP 地址 + 端口號(hào)就可以確定一個(gè)進(jìn)程地址

序號(hào)(Sequense Number,SN)：在一個(gè)TCP連接中傳送的字節(jié)流中每一個(gè)字節(jié)都按照順序編號(hào)，該字段表示本報(bào)文段所發(fā)送數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。(初始序號(hào)稱為 Init Sequence Number，ISN)

例如，一報(bào)文段的序號(hào)是 101，共有 100 字節(jié)的數(shù)據(jù)。這就表明：本報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是 101，最后一個(gè)字節(jié)的序號(hào)是 200。顯然，下一個(gè)報(bào)文段的數(shù)據(jù)序號(hào)應(yīng)當(dāng)從 201 開始，即下一個(gè)報(bào)文段的序號(hào)字段值應(yīng)為 201。

確認(rèn)號(hào)ack:期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。若確認(rèn)號(hào)為 N，則表明：到序號(hào) N-1 為止的所有數(shù)據(jù)都已正確收到。

數(shù)據(jù)偏移：指出 TCP報(bào)文段的數(shù)據(jù)起始處 距離 TCP報(bào)文段的起始處有多遠(yuǎn)。這個(gè)字段實(shí)際上是指出TCP報(bào)文段的首部長度。

保留位：占6位，應(yīng)置為 0，保留為今后使用。

6個(gè)控制位：用于說明該報(bào)文段的性質(zhì)：

緊急位URG：當(dāng) URG = 1 時(shí)，表明此報(bào)文段中有緊急數(shù)據(jù)，是高優(yōu)先級(jí)的數(shù)據(jù)，應(yīng)盡快發(fā)送，不用在緩存中排隊(duì)。

確認(rèn)ACK：僅當(dāng) ACK = 1 時(shí)確認(rèn)號(hào)字段才有效，當(dāng) ACK = 0 時(shí)確認(rèn)號(hào)無效。TCP 規(guī)定，在連接建立后所有傳送的報(bào)文段都必須把 ACK 置為 1。

推送PSH：接收方收到 PSH = 1 的報(bào)文段時(shí)，就直接發(fā)送給應(yīng)用進(jìn)程，而不用等到整個(gè)緩沖區(qū)都填滿了后再向上傳送。

復(fù)位RST：當(dāng) RST = 1 時(shí)，表明 TCP 連接中出現(xiàn)了嚴(yán)重錯(cuò)誤（如由于主機(jī)崩潰或其他原因），必須釋放連接，然后再重新建立傳輸連接。

同步SYN：SYN = 1 表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。當(dāng) SYN = 1 而 ACK = 0 時(shí)，表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接，則應(yīng)在響應(yīng)的報(bào)文段中使 SYN = 1 且 ACK = 1。

終止FIN：用來釋放一個(gè)連接。當(dāng) FIN = 1時(shí)，表明此報(bào)文段的發(fā)送發(fā)的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。

窗口大小：16位，用于控制發(fā)送端的滑動(dòng)窗口大小

校檢和：16位，校驗(yàn)數(shù)據(jù)段是否未被修改

緊急指針：16位。

6.2 TCP連接的建立和斷開

6.2.1 TCP三次握手建立連接

點(diǎn)擊加載圖片

客戶機(jī)A主動(dòng)發(fā)送一個(gè)SYN報(bào)文，該報(bào)文指明了第一個(gè)字節(jié)的初始化序列號(hào)(ISN)即seq=x；此時(shí)客戶端處于SYN-SENT狀態(tài)

三次握手的一個(gè)重要功能是客戶端和服務(wù)端交換 ISN，以便讓對(duì)方知道接下來接收數(shù)據(jù)時(shí)如何按序列號(hào)組裝數(shù)據(jù)。

ISN 是動(dòng)態(tài)生成的，并非固定，因此每個(gè)連接都將具有不同的 ISN。如果 ISN 是固定的，攻擊者很容易猜出后續(xù)的確認(rèn)號(hào)。

服務(wù)器B在收到客戶機(jī)A發(fā)送的SYN報(bào)文后，由于SYN=1知道客戶端請(qǐng)求建立連接，這時(shí)會(huì)對(duì)這個(gè)TCP連接分配緩存和變量(緩沖指的是一個(gè)字節(jié)流隊(duì)列)，接著返回客戶端一個(gè)確認(rèn)報(bào)文：設(shè)置SYN=1,ACK=1(表示確認(rèn)號(hào)有效) 同時(shí)指定自己的初始化序列號(hào)ISN,即seq=y,并把客戶端的ISN+1作為自己的ack值，表示已經(jīng)收到客戶端發(fā)送來的SYN報(bào)文，希望收到的下一個(gè)數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是x+1,此時(shí)服務(wù)端進(jìn)入SYN-RCVD狀態(tài)。

客戶端在收到服務(wù)器發(fā)送的確認(rèn)報(bào)文后，檢查ACK是否為1，ack是否是x+1,如果正確，則給服霧端發(fā)送一個(gè)ACK報(bào)文：設(shè)置ACK=1,把服務(wù)端的初始化序列號(hào)(ISN+1)設(shè)置為自己的ack,即ack=y+1,表示已經(jīng)收到服務(wù)端的確認(rèn)報(bào)文，希望收到服務(wù)端的下一個(gè)數(shù)據(jù)的字節(jié)序號(hào)是y+1,并指明此時(shí)客戶端的初始化序列號(hào)為x+1,即seq=x+1,此后客戶端和服務(wù)端狀態(tài)都變?yōu)镋STABLISHED。完成三次握手，此后服務(wù)器和客戶端就可以開始傳輸數(shù)據(jù)了。

此時(shí)SYN控制位已經(jīng)變成0，表示這不是建立連接的請(qǐng)求了，要正式發(fā)送數(shù)據(jù)了。

6.2.2 為什么不能使用兩次握手建立連接

兩次握手就只能讓服務(wù)器端對(duì)客戶端的初始化序列(ISN)進(jìn)行確認(rèn)，并不能讓客戶端對(duì)服務(wù)器端的初始化序列進(jìn)行確認(rèn)，不能達(dá)到可靠傳輸?shù)哪康摹?/p>

三次握手可以防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，導(dǎo)致服務(wù)器錯(cuò)誤地建立連接，浪費(fèi)服務(wù)端的連接資源。

客戶端發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)Server。本來這是一個(gè)早已失效的報(bào)文段，但Server收到此失效的連接請(qǐng)求報(bào)文段后：

(1) 假設(shè)不采用“三次握手”，那么只要Sever發(fā)出確認(rèn)，新的連接就建立了。但由于現(xiàn)在Client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬Server的確認(rèn)，也不會(huì)向Server發(fā)送數(shù)據(jù)。而Server卻以為新的連接已經(jīng)建立，并一直等待Client發(fā)來數(shù)據(jù)，這樣，Server的很多資源就白白浪費(fèi)掉了

(2) 而采用“三次握手”協(xié)議，只要Server收不到來自Client的確認(rèn)，就知道Client并沒有要求建立請(qǐng)求，就不會(huì)建立連接了。

6.2.3 TCP四次揮手釋放連接

點(diǎn)擊加載圖片

第一次揮手：客戶端發(fā)送FIN報(bào)文，設(shè)置FIN=1,并指定序列號(hào)seq=u(u是之前傳過來的最后一個(gè)字節(jié)的序號(hào)+1)，主動(dòng)關(guān)閉TCP連接，此時(shí)客戶端進(jìn)入FIN-WAIT_1狀態(tài)。

第二次揮手：服務(wù)端收到 FIN 報(bào)文后，由FIN=1 知道客戶端請(qǐng)求關(guān)閉連接，則返回確認(rèn)報(bào)文：設(shè)置ACK = 1，ack = u + 1，seq = v（v 的值取決于服務(wù)器發(fā)送給客戶端之前的一個(gè)包確認(rèn)號(hào)是多少）

服務(wù)端進(jìn)入CLOSE_WAIT狀態(tài)，此時(shí)TCP連接處于半關(guān)閉狀態(tài)，即客戶端不能向服務(wù)端發(fā)送報(bào)文，只能接收，但服務(wù)端仍然可以向客戶端發(fā)送數(shù)據(jù)。

客戶端收到服務(wù)端的確認(rèn)后，進(jìn)入 FIN_WAIT_2 狀態(tài)，等待服務(wù)端發(fā)出的連接釋放報(bào)文段。

第三次揮手:當(dāng)服務(wù)端沒有要向客戶端發(fā)送的數(shù)據(jù)時(shí)，就向客戶端發(fā)送一個(gè) FIN 報(bào)文，設(shè)置 FIN = 1 并指定序列號(hào) seq = w（w 的值取決于服務(wù)器發(fā)送給客戶端之前的一個(gè)包確認(rèn)號(hào)是多少），用于關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳送。此時(shí)服務(wù)器處于 LAST_ACK 狀態(tài)

第四次揮手:客戶端收到 FIN 報(bào)文后，發(fā)送給服務(wù)端一個(gè) ACK 報(bào)文作為應(yīng)答：設(shè)置 ACK=1 和 ack = w +1。發(fā)送之后，客戶端處于 TIME_WAIT狀態(tài)，如果服務(wù)端接收到這個(gè)數(shù)據(jù)包，則進(jìn)入CLOSED狀態(tài)，完成四次揮手。

6.2.4 為什么需要TIME-WAIT狀態(tài)

TIME_WAIT 狀態(tài)持續(xù) 2MSL（最大報(bào)文存活時(shí)間），約4分鐘才轉(zhuǎn)換成CLOSE狀態(tài)。由于TIME_WAIT 的時(shí)間會(huì)非常長，因此服務(wù)端應(yīng)盡量減少主動(dòng)關(guān)閉連接，TIME_WAIT 的主要作用有：

重發(fā)丟失的ACK報(bào)文，保證連接可靠關(guān)閉

如果客戶端連接沒有TIME-WAIT狀態(tài)，收到服務(wù)器的FIN報(bào)文就直接關(guān)閉，由于網(wǎng)絡(luò)傳輸?shù)脑?，可能客戶端發(fā)送的ACK報(bào)文在服務(wù)器端沒有被接收，這就導(dǎo)致服務(wù)器端無法確認(rèn)客戶端的連接關(guān)閉，重而再次發(fā)送FIN報(bào)文這時(shí)，客戶端并不能接收到FIN報(bào)文，導(dǎo)致連接異常關(guān)閉，就只關(guān)閉了客戶端，沒有關(guān)閉服務(wù)端。

保證本次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失。

如果存在兩個(gè)連接，第一個(gè)連接正常關(guān)閉，第二個(gè)相同的連接緊接著建立；如果第一個(gè)連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接之后才到達(dá)，則會(huì)干擾第二連接，等待 2MSL 可以讓上次連接的報(bào)文數(shù)據(jù)消逝在網(wǎng)絡(luò)中。

6.2.5 為什么需要4次揮手

TCP是全雙工模式，并且支持半關(guān)閉狀態(tài)特性，提供了連接的一端在結(jié)束發(fā)送后還能接收來自另一端數(shù)據(jù)的能力。在前面四次揮手圖解中我們能看到：前面兩次揮手是為了關(guān)閉客戶端到服務(wù)端的連接，客戶端處于半關(guān)閉狀態(tài)，但是服務(wù)端還有發(fā)送數(shù)據(jù)的能力，后兩次揮手是為了讓服務(wù)端也關(guān)閉發(fā)送數(shù)據(jù)的能力，從而達(dá)到雙方都全部釋放連接的目的。

兩次揮手只能釋放一端到另一端的連接，要釋放兩端的連接就需要四次揮手。

6.3 TCP可靠性傳輸

6.3.1 TCP如何保證可靠性傳輸

三次握手：同步客戶端和服務(wù)端的序列號(hào)。

應(yīng)答機(jī)制和超時(shí)重傳：應(yīng)答機(jī)制就是TCP接收端累積接收到發(fā)送端發(fā)來的數(shù)據(jù)后要對(duì)發(fā)來的數(shù)據(jù)進(jìn)行一個(gè)累積確認(rèn)。超時(shí)重傳就是當(dāng)TCP發(fā)送端發(fā)送一個(gè)報(bào)文段后，它會(huì)啟動(dòng)一個(gè)定時(shí)器，等待接收端的確認(rèn)報(bào)文，如果確認(rèn)報(bào)文不能及時(shí)收到，將重發(fā)這個(gè)報(bào)文段。

數(shù)據(jù)包校驗(yàn)和丟棄重復(fù)數(shù)據(jù)：接收方若收到有差錯(cuò)的報(bào)文段就丟棄(不發(fā)送否認(rèn)信息)。若收到重復(fù)的報(bào)文段，也要丟棄，但是要立即發(fā)回確認(rèn)信息。

對(duì)失序數(shù)據(jù)包進(jìn)行重排序：既然TCP報(bào)文段作為IP數(shù)據(jù)報(bào)來傳輸，而IP數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此TCP報(bào)文段的到達(dá)也可能會(huì)失序。TCP將對(duì)失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層；

流量控制：TCP連接的主機(jī)兩端都設(shè)置有緩存區(qū)，為了防止數(shù)據(jù)溢出緩存區(qū)，TCP通過可變大小的滑動(dòng)窗口來控制數(shù)據(jù)傳輸?shù)牧髁看笮　?/p>

擁塞控制：網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。

6.3.2 TCP的流量控制

流量控制的基本方法就是接受方根據(jù)自己的接收能力控制發(fā)送方的發(fā)送速率。因此可以說流量控制是一個(gè)速度匹配服務(wù)，即發(fā)送方的發(fā)送速率與接收方應(yīng)用程序的讀速率相匹配，利用滑動(dòng)窗口機(jī)制可以很方便的控制發(fā)送方的平均發(fā)送速率，TCP采用接收方控制發(fā)送方發(fā)送窗口的大小的方法來實(shí)現(xiàn)在TCP連接上的流量控制。在TCP報(bào)文段首部的窗口字段寫入的數(shù)值就是當(dāng)前給對(duì)方設(shè)置的發(fā)送窗口數(shù)值上限。

流量控制實(shí)例

設(shè)A向B發(fā)送數(shù)據(jù)。在連接建立時(shí)，B告訴了A：“我的接收窗口是 rwnd = 400 ”(這里的 rwnd 表示 receiver window) 。因此，發(fā)送方的發(fā)送窗口不能超過接收方給出的接收窗口的數(shù)值。假設(shè)每一個(gè)報(bào)文段為100字節(jié)長，而數(shù)據(jù)報(bào)文段序號(hào)的初始值設(shè)為1。

點(diǎn)擊加載圖片

從圖中可以看出，B進(jìn)行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最后減到 rwnd = 0 ，即不允許發(fā)送方再發(fā)送數(shù)據(jù)了。這種使發(fā)送方暫停發(fā)送的狀態(tài)將持續(xù)到主機(jī)B重新發(fā)出一個(gè)新的窗口值為止。B向A發(fā)送的三個(gè)報(bào)文段都設(shè)置了 ACK = 1 ，只有在 ACK=1 時(shí)確認(rèn)號(hào)字段才有意義。

6.3.3 TCP的擁塞控制

當(dāng)網(wǎng)絡(luò)中出現(xiàn)太多分分組時(shí)，網(wǎng)絡(luò)的性能開始下降，這種情況稱為擁塞。

如果網(wǎng)絡(luò)中的負(fù)載，即發(fā)送到網(wǎng)絡(luò)中的數(shù)據(jù)量，超過了網(wǎng)絡(luò)的容量，即網(wǎng)絡(luò)中能處理的數(shù)據(jù)量，那么在網(wǎng)絡(luò)中就可能發(fā)生擁塞。

擁塞控制的任務(wù)就是控制源點(diǎn)的發(fā)送速率，防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，使網(wǎng)絡(luò)中的路由器或鏈路不致過載。

發(fā)送方維持一個(gè)叫做**擁塞窗口 cwnd(congestion window)**的狀態(tài)變量。發(fā)送窗口不能大于擁塞窗口

擁塞窗口的大小隨網(wǎng)絡(luò)擁塞情況而動(dòng)態(tài)變化：

只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口就增大，以便把更多的分組發(fā)送出去

但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口就減小，以減少注入到網(wǎng)絡(luò)中的分組數(shù)。

慢啟動(dòng)算法

剛建立連接準(zhǔn)備發(fā)送數(shù)據(jù)時(shí)不知道網(wǎng)絡(luò)可用寬帶情況，先慢慢發(fā)送，再逐步提高發(fā)送速率，試探網(wǎng)絡(luò)可用寬帶。

一開始發(fā)送方先設(shè)置擁塞窗口 cwnd=1(一個(gè)最大報(bào)文段MSS數(shù)值)。然后每經(jīng)過一個(gè)傳輸輪次RTT，擁塞窗口就加倍。

為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個(gè) 慢啟動(dòng)門限 ssthresh 狀態(tài)變量 。

當(dāng) cwnd < ssthresh 時(shí)，使用上述的慢開始算法。

當(dāng) cwnd = ssthresh 時(shí)，既可使用慢開始算法，也可使用擁塞控制避免算法。

當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法。

擁塞避免算法

由于慢啟動(dòng)窗口很快，為避免很快又導(dǎo)致網(wǎng)絡(luò)擁塞，在cwnd>ssthresh時(shí)就進(jìn)入擁塞避免階段，讓擁塞窗口cwnd緩慢地增大，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。

無論在慢開始階段還是在擁塞避免階段，只要網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認(rèn)），就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的擁塞窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd 設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的數(shù)據(jù)量，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的數(shù)據(jù)處理完畢。過程圖如下：

點(diǎn)擊加載圖片

快重傳

快重傳要求接收方在收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)（使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對(duì)方）而不必等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)。發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期。

點(diǎn)擊加載圖片

如上圖：接收方收到了M1和M2后都分別發(fā)出了確認(rèn)?，F(xiàn)在假定接收方?jīng)]有收到M3但接著收到了M4。顯然，接收方不能確認(rèn)M4，因?yàn)镸4是收到的失序報(bào)文段。根據(jù)可靠傳輸原理，接收方可以什么都不做，也可以在適當(dāng)時(shí)機(jī)發(fā)送一次對(duì)M2的確認(rèn)。但按照快重傳算法的規(guī)定，接收方應(yīng)及時(shí)發(fā)送對(duì)M2的重復(fù)確認(rèn)，這樣做可以讓 發(fā)送方及早知道報(bào)文段M3沒有到達(dá)接收方。發(fā)送方接著發(fā)送了M5和M6。接收方收到這兩個(gè)報(bào)文后，也還要再次發(fā)出對(duì)M2的重復(fù)確認(rèn)。這樣，發(fā)送方共收到了 接收方的四個(gè)對(duì)M2的確認(rèn)，其中后三個(gè)都是重復(fù)確認(rèn)。

快速恢復(fù)

收到連續(xù)三個(gè)冗余ACK說明網(wǎng)絡(luò)出現(xiàn)輕度擁塞，將擁塞窗口直接降低為1則反映過于激烈，這會(huì)導(dǎo)致發(fā)送方要經(jīng)過很長時(shí)間才能恢復(fù)到正常的傳輸速率。因此TCP規(guī)定當(dāng)發(fā)送方收到連續(xù)三個(gè)冗余ACK時(shí)，執(zhí)行快速恢復(fù)算法，將擁塞窗口減半，直接進(jìn)入擁塞避免。

點(diǎn)擊加載圖片

6.3.4 流量控制和擁塞控制的差別

相同點(diǎn)：擁塞控制和流量控制的相同點(diǎn)都是控制丟包現(xiàn)象，實(shí)現(xiàn)機(jī)制都是讓發(fā)送方發(fā)得慢一點(diǎn)。

不同點(diǎn)：

擁塞控制是一個(gè)全局性的過程，防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，造成網(wǎng)絡(luò)擁塞

流量控制指點(diǎn)對(duì)點(diǎn)通信量的控制，要做的就是控制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接受。

七、應(yīng)用層

7.1 域名系統(tǒng)(DNS)

域名系統(tǒng)(Domain Name System,DNS)并不是直接和用戶打交道的網(wǎng)絡(luò)應(yīng)用，而是為其他網(wǎng)絡(luò)應(yīng)用提供一種核心服務(wù)，即名字服務(wù)，使各種網(wǎng)絡(luò)應(yīng)用能夠在應(yīng)用層使用計(jì)算機(jī)的名字來進(jìn)行交互，而不需要直接使用IP地址。

7.1.1 域名服務(wù)器

點(diǎn)擊加載圖片

域名服務(wù)器大致分為三種類型：根域名服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)限域名服務(wù)器，其中頂級(jí)域名服務(wù)器主要負(fù)責(zé)諸如com、org、net、edu、gov等頂級(jí)域名。

根域名服務(wù)器存儲(chǔ)了所有的頂級(jí)域名服務(wù)器的IP地址，可以通過根服務(wù)器找到頂級(jí)域名服務(wù)器(例如：www.baidu.com 根服務(wù)器會(huì)返回所有維護(hù)com這個(gè)頂級(jí)域服務(wù)器的IP地址)。

然后你任選其中一個(gè)頂級(jí)域服務(wù)器發(fā)送請(qǐng)求，該頂級(jí)域服務(wù)器拿到域名后能夠給出負(fù)責(zé)當(dāng)前域的權(quán)限服務(wù)器地址（以 baidu為例的話，頂級(jí)域名服務(wù)器將返回所有負(fù)責(zé) baidu 這個(gè)域的權(quán)限域名服務(wù)器地址）。

接著任選其中一個(gè)權(quán)威服務(wù)器地址查詢 「www.baidu.com」 的具體 IP 地址，最終權(quán)威服務(wù)器會(huì)返回給你具體的 IP 地址。此外，本地 DNS 服務(wù)器是具有緩存功能的，通常兩天內(nèi)的記錄都會(huì)被緩存。

7.1.2 域名解析過程

點(diǎn)擊加載圖片

操作系統(tǒng)先查詢本地hosts文件中是否有錄，如果有，則直接返回相映射的IP地址。

如果本地hosts文件沒有配置，則主機(jī)向自己的本地DNS服務(wù)器發(fā)送查詢報(bào)文，如果本地DNS服務(wù)器緩存中有，將直接返回結(jié)果。

如果本地服務(wù)器緩存中沒有，則從內(nèi)置在內(nèi)部的根服務(wù)器列表（全球13臺(tái)，固定的IP地址）中選一個(gè)發(fā)送查詢報(bào)文

根服務(wù)器解析域名中的后綴名，告訴本地服務(wù)器負(fù)責(zé)該后綴名的所有頂級(jí)服務(wù)器列表

本地服務(wù)器選擇其中一個(gè)頂級(jí)域服務(wù)器發(fā)送查詢請(qǐng)求，頂級(jí)域服務(wù)器拿到域名后繼續(xù)解析，返回對(duì)應(yīng)域的所有權(quán)限服務(wù)器列表

本地服務(wù)器再向返回的權(quán)威服務(wù)器發(fā)送查詢報(bào)文，最終會(huì)從某一個(gè)權(quán)威服務(wù)器上得到具體的 IP 地址

主機(jī)返回結(jié)果IP

7.1.3 DNS底層協(xié)議

DNS域名系統(tǒng)：用于域名解析服務(wù)，將域名地址轉(zhuǎn)換為IP地址，基于UDP服務(wù)，使用53端口。

DNS底層既使用TCP又使用UDP協(xié)議：

(1) 域名解析時(shí)使用UDP協(xié)議：客戶端向DNS服務(wù)器查詢域名，一般返回的內(nèi)容都不超過512字節(jié)，用UDP傳輸即可，不用經(jīng)過TCP三次握手，這樣DNS服務(wù)器負(fù)載更低，響應(yīng)更快。

(2) 區(qū)域傳送時(shí)使用TCP，主要有一下兩點(diǎn)考慮：

輔助域名服務(wù)器會(huì)定時(shí)（一般時(shí)3小時(shí)）向主域名服務(wù)器進(jìn)行查詢以便了解數(shù)據(jù)是否有變動(dòng)。如有變動(dòng)，則會(huì)執(zhí)行一次區(qū)域傳送，進(jìn)行數(shù)據(jù)同步。區(qū)域傳送將使用TCP而不是UDP，因?yàn)閿?shù)據(jù)同步傳送的數(shù)據(jù)量比一個(gè)請(qǐng)求和應(yīng)答的數(shù)據(jù)量要多得多。

TCP是一種可靠的連接，保證了數(shù)據(jù)的準(zhǔn)確性。

7.2 HTTP協(xié)議：

http協(xié)議即超文本傳輸協(xié)議，基于TCP協(xié)議，用于從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

7.2.1 Cookie 和 session的區(qū)別

http協(xié)議是無狀態(tài)協(xié)議，自身不對(duì)請(qǐng)求和響應(yīng)直接的通信狀態(tài)進(jìn)行保存，但有些場(chǎng)景下我們需要保存用戶的登錄信息，因此引入了cookies和session來管理狀態(tài)。

cookie和session的區(qū)別

保存位置與安全性：cookie保存在客戶端，session保存在服務(wù)端，所以在安全性方面，cookie存在安全隱患，可以通過攔截本地文件找到cookie后進(jìn)行攻擊，而session相對(duì)更加安全。因此，可以將登陸信息等重要信息保存在session中；其他信息如果需要保留，可以存在cookie中。

存儲(chǔ)容量：?jiǎn)蝹€(gè)cookie最大只允許4KB，一個(gè)站點(diǎn)最多保存20個(gè)Cookie；session沒有大小限制，個(gè)數(shù)只跟服務(wù)器的內(nèi)存大小有關(guān)。

有效期于實(shí)現(xiàn)機(jī)制：cookie可以長期有效存在；session依賴于cookie，過期時(shí)間默認(rèn)為-1，只需關(guān)閉窗口該session就會(huì)失效。每個(gè)客戶端對(duì)應(yīng)一個(gè)session，客戶端之間的session相互獨(dú)立；

cookie：cookie是一小段的文本信息，當(dāng)客戶端請(qǐng)求服務(wù)器時(shí)，如果服務(wù)器需要記錄該用戶狀態(tài)，就在響應(yīng)頭中向客戶端瀏覽器頒發(fā)一個(gè)Cookie，而客戶端瀏覽器會(huì)把cookie保存起來。當(dāng)再次請(qǐng)求該網(wǎng)站時(shí)，瀏覽器把請(qǐng)求的網(wǎng)站連同該cookie一起提交給服務(wù)器，服務(wù)器會(huì)檢查該cookie，以此來辨認(rèn)用戶狀態(tài)。

session：當(dāng)客戶端請(qǐng)求服務(wù)器時(shí)，都會(huì)帶上cookie，cookie里面一般都會(huì)有一個(gè)JSESSIONID，服務(wù)器就按照 JSESSIONID 來找到對(duì)應(yīng)的 session；如果客戶端請(qǐng)求不包含 JSESSIONID，則為此客戶端創(chuàng)建session并生成相關(guān)聯(lián)的JSESSIONID，并將這個(gè)JSESSIONID在本次響應(yīng)中返回給客戶端保存。客戶端保存這個(gè) JSESSIONID 的方式可以使用cookie機(jī)制。若瀏覽器禁用Cookie的話，可以通過 URL重寫機(jī)制 將JSESSIONID傳回服務(wù)器。

7.2.2 一個(gè)完整的http請(qǐng)求是怎樣的？

用戶在瀏覽器端輸入某一URL點(diǎn)擊回車，或者點(diǎn)擊某一超鏈接整個(gè)http請(qǐng)求流程：

解析URL,獲取URL中包含的域名；

通過DNS系統(tǒng)查詢域名對(duì)應(yīng)的IP;

瀏覽器得到域名對(duì)應(yīng)的IP后，向服務(wù)器發(fā)起三次握手，建立TCP連接；

TCP連接建立起來后，瀏覽器向服務(wù)器發(fā)送http請(qǐng)求，如果HTML文件在緩存中，瀏覽器則直接返回，如果沒有，則去服務(wù)器端拿；

(1) 瀏覽器首次加載資源成功時(shí)，服務(wù)器返回200，此時(shí)瀏覽器不僅將資源下載下來，而且把response的header(里面的date屬性非常重要，用來計(jì)算第二次相同資源時(shí)當(dāng)前時(shí)間和date的時(shí)間差)一并緩存;

(2) 下一次加載資源時(shí)，首先要經(jīng)過強(qiáng)緩存的處理，cache-control的優(yōu)先級(jí)最高，比如cache-control：no-cache,就直接進(jìn)入到協(xié)商緩存的步驟了，如果cache-control：max-age=xxx,就會(huì)先比較當(dāng)前時(shí)間和上一次返回200時(shí)的時(shí)間差，如果沒有超過max-age，命中強(qiáng)緩存，不發(fā)請(qǐng)求直接從本地緩存讀取該文件（這里需要注意，如果沒有cache-control，會(huì)取expires的值，來對(duì)比是否過期），過期的話會(huì)進(jìn)入下一個(gè)階段，協(xié)商緩存

(3) 協(xié)商緩存階段，則向服務(wù)器發(fā)送header帶有If-None-Match和If-Modified-Since的請(qǐng)求，服務(wù)器會(huì)比較Etag，如果相同，命中協(xié)商緩存，返回304；如果不一致則有改動(dòng)，直接返回新的資源文件帶上新的Etag值并返回200;

(4) 協(xié)商緩存第二個(gè)重要的字段是，If-Modified-Since，如果客戶端發(fā)送的If-Modified-Since的值跟服務(wù)器端獲取的文件最近改動(dòng)的時(shí)間，一致則命中協(xié)商緩存，返回304；不一致則返回新的last-modified和文件并返回200;

服務(wù)器接收到請(qǐng)求后，根據(jù)路徑映射到特定的處理器進(jìn)行處理，并將處理結(jié)果以及相應(yīng)的視圖返回給瀏覽器。

瀏覽器解析視圖，并根據(jù)請(qǐng)求到的資源，數(shù)據(jù)進(jìn)行渲染頁面，最終向用戶呈現(xiàn)一個(gè)完整的頁面。

構(gòu)建DOM樹(DOM tree)：從上到下解析HTML文檔生成DOM節(jié)點(diǎn)樹（DOM tree），也叫內(nèi)容樹（content tree）；

構(gòu)建CSSOM(CSS Object Model)樹：加載解析樣式生成CSSOM樹；

執(zhí)行JavaScript：加載并執(zhí)行JavaScript代碼（包括內(nèi)聯(lián)代碼或外聯(lián)JavaScript文件）；

構(gòu)建渲染樹(render tree)：根據(jù)DOM樹和CSSOM樹,生成渲染樹(render tree)；

渲染樹：按順序展示在屏幕上的一系列矩形，這些矩形帶有字體，顏色和尺寸等視覺屬性。

布局（layout）：根據(jù)渲染樹將節(jié)點(diǎn)樹的每一個(gè)節(jié)點(diǎn)布局在屏幕上的正確位置；

繪制（painting）：遍歷渲染樹繪制所有節(jié)點(diǎn)，為每一個(gè)節(jié)點(diǎn)適用對(duì)應(yīng)的樣式，這一過程是通過UI后端模塊完成；

7.2.3 http的長鏈接和短連接

http的長連接和短連接其本質(zhì)是TCP的長鏈接和短連接，從http1.1開始就默認(rèn)使用長鏈接。

短連接：客戶端向服務(wù)端每發(fā)送一次請(qǐng)求，就會(huì)去建立一次TCP連接，收到服務(wù)端響應(yīng)，請(qǐng)求完畢后就斷開TCP連接。

長連接：客戶端和服務(wù)器端建立起TCP連接后，他們之間的連接會(huì)持續(xù)存在，不會(huì)應(yīng)為一次HTTP請(qǐng)求后關(guān)閉，后續(xù)的請(qǐng)求也用這個(gè)連接進(jìn)行通信，使用長連接的HTTP協(xié)議，會(huì)在響應(yīng)頭加入：Connection：keep-alive。長連接可以省去每次建立連接和斷開的握手和揮手操作，節(jié)約時(shí)間提高效率。但在長連接下，客戶端一般不會(huì)主動(dòng)關(guān)閉連接，如果客戶端和服務(wù)端之間的連接一直不關(guān)閉的話，隨著連接數(shù)越來越多，會(huì)對(duì)服務(wù)端造成壓力。

各自適用場(chǎng)景：長連接適合頻繁請(qǐng)求資源并且連接數(shù)并不多的場(chǎng)景，例如數(shù)據(jù)庫的連接使用長連接。而向Web網(wǎng)站這種并發(fā)量大，但是每個(gè)用戶無需頻繁操作的場(chǎng)景，一般都使用短連接，因?yàn)殚L連接對(duì)服務(wù)端來說會(huì)消耗一定的資源。

7.3 HTTPS協(xié)議

https 是基于tcp協(xié)議，在http的基礎(chǔ)上加入了SSL/TLS，可看成是添加了加密和認(rèn)證機(jī)制的http，使用對(duì)稱加密、非對(duì)稱加密、證書等技術(shù)進(jìn)行進(jìn)行客戶端與服務(wù)端的數(shù)據(jù)加密傳輸，最終達(dá)到保證整個(gè)通信的安全性。

對(duì)稱加密：對(duì)稱加密指加密和解密都需要同一個(gè)密鑰，這種方式存在如何安全的將密鑰發(fā)送對(duì)方的問題。

非對(duì)稱加密：非對(duì)稱加密使用兩個(gè)密鑰，公鑰加密則需要私鑰解密，私鑰加密則需要公鑰解密，不能同一個(gè)秘鑰既加密又解密。

非對(duì)稱加密不需要發(fā)送用來解密的私鑰，所以可以保證安全性，但是和對(duì)稱加密相比，速度非常慢，所以我們還是用對(duì)稱加密進(jìn)行數(shù)據(jù)傳輸，但對(duì)對(duì)稱加密的秘鑰用非對(duì)稱加密加密的方式發(fā)送出去。

7.3.1 HTTPS的認(rèn)證加密過程是如何保證內(nèi)容不被篡改的？

HTTPS是基于TCP協(xié)議的,首先客戶端會(huì)和服務(wù)端發(fā)起連接建立；

服務(wù)端返回他的證書給客戶端，證書中包含了服務(wù)端公鑰S.pub、頒發(fā)機(jī)構(gòu)和有效期等信息；

客戶端通過瀏覽器內(nèi)置的的根證書(內(nèi)部包含CA機(jī)構(gòu)的公鑰C.pub) 驗(yàn)證證書的合法性；

客戶端生成隨機(jī)的對(duì)稱加密秘鑰Z,然后通過服務(wù)端的公鑰S.pub加密發(fā)送給服務(wù)端；

客戶端和服務(wù)端之后就通過對(duì)稱加密秘鑰Z加密數(shù)據(jù)進(jìn)行http通信。

7.3.2 根證書是如何保證簽發(fā)的證書是安全有效的？

服務(wù)器會(huì)預(yù)先生成非對(duì)稱加密秘鑰，私鑰S.pri自己保留，而公鑰S.pub則發(fā)送給CA機(jī)構(gòu)進(jìn)行簽名認(rèn)證，當(dāng)我們?cè)谑褂肏TTPS的時(shí)候都必須要先去CA機(jī)構(gòu)申請(qǐng)一份證書；

CA機(jī)構(gòu)也會(huì)預(yù)先生成非對(duì)稱加密秘鑰，其私鑰C.pri用來對(duì)服務(wù)器的公鑰S.pub進(jìn)行簽名，生成CA證書；

CA機(jī)構(gòu)將簽名生成的CA證書返回給服務(wù)器，也就是前面服務(wù)端給客戶端那個(gè)證書；

因?yàn)镃A機(jī)構(gòu)比較權(quán)威，所以很多瀏覽器會(huì)內(nèi)置包含它公鑰C.pub的證書，稱之為根證書，然后可以使用根證書來驗(yàn)證其頒發(fā)證書的合法性了。

點(diǎn)擊加載圖片

整個(gè)過程中一共涉及到2對(duì)公私密鑰對(duì)，一對(duì)由服務(wù)器產(chǎn)生，用于加密對(duì)稱秘鑰，一對(duì)由CA機(jī)構(gòu)產(chǎn)生，用于生成證書驗(yàn)證服務(wù)器的公鑰S.pub是否合法。

7.3.3 為什么需要CA證書認(rèn)證機(jī)構(gòu)呢？

CA機(jī)構(gòu)的作用就是保證服務(wù)器端的公鑰是準(zhǔn)確無誤的，合法未修改的；雖然HTTPS是加密的，但是請(qǐng)求還是會(huì)被攔截，假設(shè)沒有CA證書，如果服務(wù)器返回的包含公鑰的數(shù)據(jù)包被攻擊人截取，然后攻擊人也生成一份自己的公私鑰，他將自己的公鑰發(fā)送給客戶端，攻擊者得到客戶端的數(shù)據(jù)進(jìn)行解密后，然后再通過服務(wù)器的公鑰加密發(fā)送給服務(wù)器，這樣數(shù)據(jù)就被攻擊者獲取到了。

所以當(dāng)我們?cè)谑褂肏TTPS協(xié)議的時(shí)候都必須提前向CA機(jī)構(gòu)申請(qǐng)一份自己的CA證書用來作為持有者的身份證唯一標(biāo)識(shí)；然后瀏覽器內(nèi)置的根證書能夠驗(yàn)證服務(wù)器發(fā)來的證書是否合法有效，如果是攻擊者的偽造證書很容易發(fā)現(xiàn)證書中的網(wǎng)站信息不合法。從而達(dá)到了服務(wù)器的公鑰實(shí)現(xiàn)秘密傳輸給客戶端的效果。

證書內(nèi)容通常包括：

服務(wù)端的公鑰

證書發(fā)行者（CA）對(duì)證書的數(shù)字簽名

證書所用的簽名算法

證書發(fā)布機(jī)構(gòu)、有效期、所有者的信息等其他信息

7.4 HTTP的請(qǐng)求和響應(yīng)

7.4.1 HTTP的常見請(qǐng)求方式：

get ：向服務(wù)器端獲取資源，所以一般查詢采用get請(qǐng)求；

post：向服務(wù)器端提交請(qǐng)求字段，創(chuàng)建操作使用post請(qǐng)求，該操作不是冪等的，多次請(qǐng)求會(huì)導(dǎo)致多條數(shù)據(jù)被創(chuàng)建，所以一般新增操作用post請(qǐng)求；

put:修改自定URL的資源，如果指定資源不存在，則進(jìn)行創(chuàng)建，在http中，put被定義為冪等的，多次操作會(huì)導(dǎo)致前面的數(shù)據(jù)被覆蓋，所以一般修改操作用put請(qǐng)求；

patch：局部修改URL所在資源的數(shù)據(jù)，是對(duì)put的補(bǔ)充；

delete：刪除指定的URL資源。一般刪除操作用delete請(qǐng)求；

head：獲取響應(yīng)報(bào)文的首部，即獲取URL資源的頭部；

options:詢問服務(wù)器支持哪些方法，響應(yīng)頭中返回Allow：GET、POST、HEAD;

trace:追蹤路徑，主要用于測(cè)試或診斷；在請(qǐng)求頭中在Max-Forwards字段設(shè)置數(shù)字，每經(jīng)過一個(gè)服務(wù)器該數(shù)字就減一，當(dāng)?shù)?的時(shí)候就直接返回，一般通過該方法檢查請(qǐng)求發(fā)送出去是否被篡改

7.4.2 get和post請(qǐng)求的區(qū)別

功能：get一般用于從服務(wù)器上面獲取資源，post一般用來更新服務(wù)器上面的資源。

冪等性：get是冪等的，post是非冪等的

安全性：get請(qǐng)求的參數(shù)會(huì)被明文附加在URL之后，而post請(qǐng)求提交的數(shù)據(jù)會(huì)被封裝到請(qǐng)求體中，相對(duì)更安全

傳輸數(shù)據(jù)量的大?。篻et請(qǐng)求允許發(fā)送的數(shù)據(jù)量比較小，大多數(shù)瀏覽器都會(huì)限制請(qǐng)求的url長度在2048個(gè)字節(jié)，而大多數(shù)服務(wù)器最多處理64K大小的url；而post請(qǐng)求提交的數(shù)據(jù)量則是沒有大小限制的。

參數(shù)的數(shù)據(jù)類型：get只接受ASCII字符，而post沒有限制。

get在瀏覽器回退時(shí)是無害的，而post會(huì)再次提交請(qǐng)求。

get請(qǐng)求可以被緩存，可以被保留在瀏覽器的歷史記錄中；post請(qǐng)求不會(huì)被緩存，不會(huì)被保留在瀏覽器的歷史記錄中。

7.4.3 HTTP報(bào)文頭分析

HTTP報(bào)文是面向文本的，因此在報(bào)文中的每一個(gè)字段都是一些ASCII碼串。

報(bào)文類型分兩種：請(qǐng)求報(bào)文，響應(yīng)報(bào)文

請(qǐng)求報(bào)文：

請(qǐng)求行：包含請(qǐng)求方法、URI、HTTP版本信息

請(qǐng)求首部字段

請(qǐng)求內(nèi)容實(shí)體

點(diǎn)擊加載圖片

響應(yīng)報(bào)文：

狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語

響應(yīng)首部字段

響應(yīng)內(nèi)容實(shí)體

點(diǎn)擊加載圖片

報(bào)文中各部分的簡(jiǎn)要描述：

方法(method)：客戶端希望服務(wù)器對(duì)資源執(zhí)行的動(dòng)作，是一個(gè)單獨(dú)的詞，比如：get 或者 post

請(qǐng)求URL(request-URL)：請(qǐng)求URL是資源的絕對(duì)路徑，服務(wù)器可以假定自己是URL的主機(jī)/端口

版本(version)：報(bào)文所使用的Http版本，其格式：HTTP/<主要版本號(hào)>.<次要版本號(hào)>

狀態(tài)碼(status-code)：標(biāo)識(shí)請(qǐng)求過程中所發(fā)生的情況

原因短語(reason-phrase)：數(shù)字狀態(tài)碼的可讀版本，包含行終止序列之前的所有文本。

請(qǐng)求頭部(header)：可以有零個(gè)或多個(gè)頭部，每個(gè)首部都包含一個(gè)名字，后面跟著一個(gè)冒號(hào)( : )，然后是一個(gè)可選的空格，接著是一個(gè)值，最后是一個(gè)CRLF首部是由一個(gè)空行(CRLF)結(jié)束的，表示了頭部列表的結(jié)束和實(shí)體主體部分的開始

實(shí)體的主體部分(entity-body)：實(shí)體的主體部分包含一個(gè)由任意數(shù)據(jù)組成的數(shù)據(jù)塊，并不是所有的報(bào)文都包含實(shí)體的主體部分，有時(shí)，報(bào)文只是以一個(gè)CRLF結(jié)束。

通用頭部：既可以出現(xiàn)在請(qǐng)求報(bào)文中，也可以出現(xiàn)在響應(yīng)報(bào)文中，它提供了與報(bào)文相關(guān)的最基本的信息：

Connection：允許客戶端和服務(wù)器指定與請(qǐng)求/響應(yīng)連接有關(guān)的選項(xiàng)，http1.1之后默認(rèn)是 keep-alive

Date：日期和時(shí)間標(biāo)志，說明報(bào)文是什么時(shí)間創(chuàng)建的

Transfer-Encoding：告知接收端為了保證報(bào)文的可靠傳輸，對(duì)報(bào)文采用了什么編碼方式

Cache-Control：用于隨報(bào)文傳送緩存指示

請(qǐng)求頭部：請(qǐng)求頭部是只在請(qǐng)求報(bào)文中有意義的頭部。用于說明是誰或什么在發(fā)送請(qǐng)求、請(qǐng)求源自何處，或者客戶端的喜好及能力

Host：給出了接收請(qǐng)求的服務(wù)器的主機(jī)名和端口號(hào)

Referer：提供了包含當(dāng)前請(qǐng)求URI的文檔的URL

User-Agent：將發(fā)起請(qǐng)求的應(yīng)用程序名稱告知服務(wù)器

Accept：告訴服務(wù)器能夠發(fā)送哪些媒體類型

Accept-Encoding：告訴服務(wù)器能夠發(fā)送哪些編碼方式

Accept-Language：告訴服務(wù)器能夠發(fā)送哪些語言

Range：如果服務(wù)器支持范圍請(qǐng)求，就請(qǐng)求資源的指定范圍

If-Range：允許對(duì)文檔的某個(gè)范圍進(jìn)行條件請(qǐng)求

Authorization：包含了客戶端提供給服務(wù)器，以便對(duì)其自身進(jìn)行認(rèn)證的數(shù)據(jù)

Cookie：客戶端用它向服務(wù)器傳送數(shù)據(jù)

響應(yīng)頭部：響應(yīng)頭部為客戶端提供了一些額外信息，比如誰在發(fā)送響應(yīng)、響應(yīng)者的功能，甚至與響應(yīng)相關(guān)的一些特殊指令

Age：(從最初創(chuàng)建開始)響應(yīng)持續(xù)時(shí)間

Server：服務(wù)器應(yīng)用程序軟件的名稱和版本

Accept-Ranges：對(duì)此資源來說，服務(wù)器可接受的范圍類型

Set-Cookie：在客戶端設(shè)置數(shù)據(jù)，以便服務(wù)器對(duì)客戶端進(jìn)行標(biāo)識(shí)

實(shí)體首部：描述主體的長度和內(nèi)容，或者資源自身

Allow：列出了可以對(duì)此實(shí)體執(zhí)行的請(qǐng)求方法

Location：告知客戶端實(shí)體實(shí)際上位于何處，用于將接收端定向到資源的位置(URL)上去

Content-Base：解析主體中的相對(duì)URL時(shí)使用的基礎(chǔ)URL

Content-Encoding：對(duì)主體執(zhí)行的任意編碼方式

Content-Language：理解主體時(shí)最適宜使用的自然語言

Content-Length：主體的長度

Content-Type：這個(gè)主體的對(duì)象類型

ETag：與此實(shí)體相關(guān)的實(shí)體標(biāo)記

Last-Modified：這個(gè)實(shí)體最后一次被修改的日期和時(shí)間

7.4.4 HTTP常見的狀態(tài)碼：

1xx:請(qǐng)求處理中，請(qǐng)求已被接受，正在處理。

2xx:請(qǐng)求成功，請(qǐng)求被成功處理。

200：OK,客戶端請(qǐng)求成；

204：請(qǐng)求處理成功，但沒有資源返回；

3xx:重定向，要完成請(qǐng)求必須進(jìn)一步處理。

301：永久性轉(zhuǎn)移，請(qǐng)求的資源已經(jīng)被分配到了新的地址

302：暫時(shí)重定向

304：已緩存。

4xx:客戶端錯(cuò)誤，請(qǐng)求不合法。

400：客戶端請(qǐng)求報(bào)文出現(xiàn)錯(cuò)誤，通常是參數(shù)錯(cuò)誤

401：客戶端未認(rèn)證授權(quán)

403：沒有權(quán)限訪問該資源

404：未找到請(qǐng)求的資源

405：不支持該請(qǐng)求方法，如果服務(wù)器支持GET，客戶端用POST請(qǐng)求就會(huì)出現(xiàn)這個(gè)錯(cuò)誤碼

5xx:服務(wù)端錯(cuò)誤，服務(wù)端不能處理合法請(qǐng)求。

服務(wù)器內(nèi)部錯(cuò)誤。

服務(wù)不可用，一段時(shí)間后可能恢復(fù)正常。

7.4.5 HTTP/1.1和HTTP/2.0的區(qū)別：

多路復(fù)用：做到同一個(gè)連接并發(fā)處理多個(gè)請(qǐng)求：HTTP2.0 使用了多路復(fù)用的技術(shù)，做到同一個(gè)連接并發(fā)處理多個(gè)請(qǐng)求，并發(fā)請(qǐng)求的數(shù)量比HTTP1.1大了好幾個(gè)數(shù)量級(jí)。

支持首部壓縮：HTTP2.0使用HPACK算法對(duì)header的數(shù)據(jù)進(jìn)行壓縮，這樣數(shù)據(jù)體積小了，在網(wǎng)絡(luò)上傳輸就會(huì)更快。

服務(wù)器推送：當(dāng)向支持HTTP2.0的web服務(wù)器請(qǐng)求時(shí)，服務(wù)器會(huì)順便把客戶端需要的資源一起推送到客戶端，避免客戶端再次創(chuàng)建連接發(fā)送請(qǐng)求到服務(wù)器端獲取，這種方式非常合適加載靜態(tài)資源。

http2.0采用二進(jìn)制而不是文本格式

7.4.6 HTTP和HTTPS的區(qū)別

http 和 https 都是基于 TCP 協(xié)議，但是 http 是使用明文傳輸，通訊內(nèi)容可能被竊聽和篡改，客戶端也無法驗(yàn)證通訊方的身份，無法保證數(shù)據(jù)發(fā)送到正確的機(jī)器上；https 是在 http 的基礎(chǔ)上加入了 SSL/TLS，可看成是添加了加密和認(rèn)證機(jī)制的http，使用對(duì)稱加密、非對(duì)稱加密、證書等技術(shù)進(jìn)行進(jìn)行客戶端與服務(wù)端的數(shù)據(jù)加密傳輸，最終達(dá)到保證整個(gè)通信的安全性。

端口不同：http 使用的是80端口，https 使用的443端口

資源消耗：和 http 通信相比，https通信會(huì)由于加解密處理消耗更多的CPU和內(nèi)存資源

參考書目：[1]謝鈞 謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)教程.第五版|微課版

參考博客：計(jì)算機(jī)網(wǎng)絡(luò)常見面試總結(jié)