計算機網(wǎng)絡(luò)知識點整理

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

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

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

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

點擊加載圖片

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

物理層

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

物理層作用：

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

規(guī)定傳輸媒體接口標準，屏蔽掉具體傳輸介質(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ù)報封裝成 幀，通過差錯控制、流量控制等方法，將分組從鏈路的一端傳送到另一端，丟棄有差錯的幀保證物理層收到的分組是無差錯的信息。

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

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

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

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

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

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

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

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

運輸層（傳輸層）

運輸層負責向兩臺主機中進程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。

運輸層主要的兩個運輸層協(xié)議：

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

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

應(yīng)用層

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

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

點擊加載圖片

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

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

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

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

4.1 封裝成幀

點擊加載圖片

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

4.2 透明傳輸

點擊加載圖片

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

4.3 差錯檢測

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

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

點擊加載圖片

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

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

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

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

5.1 IP地址及編址方式

IP地址

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

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

如下圖：

點擊加載圖片

編址方式

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

劃分子網(wǎng)：在分類編址上的一個改進； IP地址::={<網(wǎng)絡(luò)號>,<子網(wǎng)號>,<主機號>} 缺點：數(shù)量巨大的C類地址因為地址空間太小并沒有得到充分利用。

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

下面重點介紹一下無分類編址：

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

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

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

點擊加載圖片

點擊加載圖片

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

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

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

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

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

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

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

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

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

5.3 ICMP協(xié)議

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

5.3.1 ICMP報文的種類

ICMP報文的種類有兩種，即ICMP差錯報告報文和ICMP詢問報文

ICMP差錯報告報文

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

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

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

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

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

ICMP詢問報文

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

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

5.4 路由選擇協(xié)議

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

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

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

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

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

若源主機和目的主機處在不同的自治系統(tǒng)中(這兩個自治系統(tǒng)可能使用不同的內(nèi)部網(wǎng)關(guān)協(xié)議)，就需要在自治系統(tǒng)之間進行路由選擇，使用一種協(xié)議將路由信息從一個自治系統(tǒng)傳遞到另一個自治系統(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 是力求尋找一條能夠到達目的網(wǎng)絡(luò) 且 較好的路由，而并非要尋找一條最佳路由。BGP采用路徑向量路由選擇協(xié)議。

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

六、傳輸層(運輸層)

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

6.1 TCP 和UDP

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

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

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

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

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

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

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

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

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

6.1.2 TCP和UDP的適用場景

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

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

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

6.1.3 TCP的報文格式

點擊加載圖片

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

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

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

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

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

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

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

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

確認ACK：僅當 ACK = 1 時確認號字段才有效，當 ACK = 0 時確認號無效。TCP 規(guī)定，在連接建立后所有傳送的報文段都必須把 ACK 置為 1。

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

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

同步SYN：SYN = 1 表示這是一個連接請求或連接接受報文。當 SYN = 1 而 ACK = 0 時，表明這是一個連接請求報文段。對方若同意建立連接，則應(yīng)在響應(yīng)的報文段中使 SYN = 1 且 ACK = 1。

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

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

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

緊急指針：16位。

6.2 TCP連接的建立和斷開

6.2.1 TCP三次握手建立連接

點擊加載圖片

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

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

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

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

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

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

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

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

三次握手可以防止已失效的連接請求報文段突然又傳送到了服務(wù)端，導致服務(wù)器錯誤地建立連接，浪費服務(wù)端的連接資源。

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

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

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

6.2.3 TCP四次揮手釋放連接

點擊加載圖片

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

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

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

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

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

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

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

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

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

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

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

如果存在兩個連接，第一個連接正常關(guān)閉，第二個相同的連接緊接著建立；如果第一個連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接之后才到達，則會干擾第二連接，等待 2MSL 可以讓上次連接的報文數(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ù)的能力，從而達到雙方都全部釋放連接的目的。

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

6.3 TCP可靠性傳輸

6.3.1 TCP如何保證可靠性傳輸

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

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

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

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

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

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

6.3.2 TCP的流量控制

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

流量控制實例

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

點擊加載圖片

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

6.3.3 TCP的擁塞控制

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

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

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

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

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

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

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

慢啟動算法

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

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

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

當 cwnd < ssthresh 時，使用上述的慢開始算法。

當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞控制避免算法。

當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。

擁塞避免算法

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

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

點擊加載圖片

快重傳

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

點擊加載圖片

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

快速恢復

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

點擊加載圖片

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

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

不同點：

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

流量控制指點對點通信量的控制，要做的就是控制發(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)用層使用計算機的名字來進行交互，而不需要直接使用IP地址。

7.1.1 域名服務(wù)器

點擊加載圖片

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

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

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

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

7.1.2 域名解析過程

點擊加載圖片

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

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

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

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

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

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

主機返回結(jié)果IP

7.1.3 DNS底層協(xié)議

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

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

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

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

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

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

7.2 HTTP協(xié)議：

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

7.2.1 Cookie 和 session的區(qū)別

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

cookie和session的區(qū)別

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

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

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

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

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

7.2.2 一個完整的http請求是怎樣的？

用戶在瀏覽器端輸入某一URL點擊回車，或者點擊某一超鏈接整個http請求流程：

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

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

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

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

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

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

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

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

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

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

構(gòu)建DOM樹(DOM tree)：從上到下解析HTML文檔生成DOM節(jié)點樹（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é)點樹的每一個節(jié)點布局在屏幕上的正確位置；

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

7.2.3 http的長鏈接和短連接

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

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

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

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

7.3 HTTPS協(xié)議

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

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

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

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

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

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

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

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

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

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

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

服務(wù)器會預先生成非對稱加密秘鑰，私鑰S.pri自己保留，而公鑰S.pub則發(fā)送給CA機構(gòu)進行簽名認證，當我們在使用HTTPS的時候都必須要先去CA機構(gòu)申請一份證書；

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

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

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

點擊加載圖片

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

7.3.3 為什么需要CA證書認證機構(gòu)呢？

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

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

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

服務(wù)端的公鑰

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

證書所用的簽名算法

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

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

7.4.1 HTTP的常見請求方式：

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

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

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

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

delete：刪除指定的URL資源。一般刪除操作用delete請求；

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

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

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

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

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

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

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

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

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

get在瀏覽器回退時是無害的，而post會再次提交請求。

get請求可以被緩存，可以被保留在瀏覽器的歷史記錄中；post請求不會被緩存，不會被保留在瀏覽器的歷史記錄中。

7.4.3 HTTP報文頭分析

HTTP報文是面向文本的，因此在報文中的每一個字段都是一些ASCII碼串。

報文類型分兩種：請求報文，響應(yīng)報文

請求報文：

請求行：包含請求方法、URI、HTTP版本信息

請求首部字段

請求內(nèi)容實體

點擊加載圖片

響應(yīng)報文：

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

響應(yīng)首部字段

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

點擊加載圖片

報文中各部分的簡要描述：

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

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

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

狀態(tài)碼(status-code)：標識請求過程中所發(fā)生的情況

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

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

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

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

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

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

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

Cache-Control：用于隨報文傳送緩存指示

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

Host：給出了接收請求的服務(wù)器的主機名和端口號

Referer：提供了包含當前請求URI的文檔的URL

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

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

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

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

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

If-Range：允許對文檔的某個范圍進行條件請求

Authorization：包含了客戶端提供給服務(wù)器，以便對其自身進行認證的數(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ù)時間

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

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

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

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

Allow：列出了可以對此實體執(zhí)行的請求方法

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

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

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

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

Content-Length：主體的長度

Content-Type：這個主體的對象類型

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

Last-Modified：這個實體最后一次被修改的日期和時間

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

1xx:請求處理中，請求已被接受，正在處理。

2xx:請求成功，請求被成功處理。

200：OK,客戶端請求成；

204：請求處理成功，但沒有資源返回；

3xx:重定向，要完成請求必須進一步處理。

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

302：暫時重定向

304：已緩存。

4xx:客戶端錯誤，請求不合法。

400：客戶端請求報文出現(xiàn)錯誤，通常是參數(shù)錯誤

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

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

404：未找到請求的資源

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

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

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

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

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

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

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

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

http2.0采用二進制而不是文本格式

7.4.6 HTTP和HTTPS的區(qū)別

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

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

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

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

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