[toc]

0. 概述與模型對比

參考地址1
參考地址2
TCP 可靠性傳輸
模型對比圖如下：

對比圖
OSI 參考模型分為 7 層：物理層哭靖、鏈路層砖茸、網(wǎng)路層侣诵、傳輸層、會話層边苹、表示層陵且、應(yīng)用層
TCP/IP 協(xié)議棧分為 4 層：網(wǎng)絡(luò)接口層(物理層、鏈路層)个束、網(wǎng)際層(網(wǎng)絡(luò)層IP)慕购、傳輸層(UDP/TCP)、應(yīng)用層(會話層播急、表示層脓钾、應(yīng)用層)
OSI 參考模型有點(diǎn)事概念清楚、理論完善桩警，缺點(diǎn)是復(fù)雜而不實(shí)用
TCP/IP 協(xié)議棧缺點(diǎn)為太簡單可训，但被廣泛使用
因此綜合上述優(yōu)缺點(diǎn)，我們討論專門用于學(xué)習(xí)的 TCP/IP 5 層參考模型
TCP/IP 5 層參考模型：物理層捶枢、數(shù)據(jù)鏈路層握截、網(wǎng)絡(luò)層、傳輸層烂叔、應(yīng)用層

1. 物理層（簡單了解）

任務(wù)：透明地傳輸比特流谨胞。確定與傳輸媒體的接口的一些特性，即：機(jī)械特性（接口所用接線器的一些物理屬性如形狀尺寸）蒜鸡，電氣特性（接口電纜的各條線上出現(xiàn)的電壓的范圍）胯努，功能特性（某條線上出現(xiàn)的某一電平的電壓的意義）牢裳，過程特性（對于不同功能能的各種可能事件的出現(xiàn)順序）
根據(jù)雙方信息交互的方式，通信可劃分為單向通信（或單工通信）叶沛，雙向交替通信（或半雙工通信）蒲讯，雙向同時(shí)通信（全雙工通信）
傳輸媒體可分為兩大類，即導(dǎo)引型傳輸媒體（雙絞線灰署，同軸電纜判帮，光纖）和非導(dǎo)引型傳輸媒體（無線，紅外溉箕，大氣激光）

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

數(shù)據(jù)鏈路層
幀：數(shù)據(jù)鏈路層的傳輸單元晦墙，由一個數(shù)據(jù)鏈路層首部和其攜帶的封包所組成協(xié)議數(shù)據(jù)單元，頭部表名數(shù)據(jù)發(fā)送者肴茄、接受者晌畅、數(shù)據(jù)類型
MAC 地址：每個設(shè)備具有的硬件地址。數(shù)據(jù)鏈路層負(fù)責(zé) MAC 地址独郎，在網(wǎng)卡的 ROM 中
鏈路：是從一個結(jié)點(diǎn)到相鄰節(jié)點(diǎn)的一段物理鏈路踩麦，數(shù)據(jù)鏈路則在鏈路的基礎(chǔ)上增加了一些必要的硬件（如網(wǎng)絡(luò)適配器）和軟件（如協(xié)議的實(shí)現(xiàn)）
無論在多么復(fù)雜的網(wǎng)絡(luò)中枚赡，從邏輯意義上講氓癌，真正的數(shù)據(jù)傳輸通道就是數(shù)據(jù)鏈路層中所定義的數(shù)據(jù)鏈路
數(shù)據(jù)鏈路層的三個基本問題是：封裝成幀、透明傳輸和差錯檢測（可能還有物理地址尋址贫橙、流量控制贪婉、重發(fā)等）
循環(huán)冗余檢驗(yàn) CRC 是一種檢錯方法，而幀檢驗(yàn)序列 FCS 是添加在數(shù)據(jù)后面的冗余碼
數(shù)據(jù)鏈路層使用的信道主要有兩種：點(diǎn)對點(diǎn)信道 和 廣播信道卢肃，對應(yīng)的兩種的常見的協(xié)議為：點(diǎn)對點(diǎn)協(xié)議 PPP與以太網(wǎng)協(xié)議
以太網(wǎng)協(xié)議與點(diǎn)對點(diǎn)協(xié)議 PPP 均是數(shù)據(jù)鏈路層協(xié)議疲迂，區(qū)別在于以太網(wǎng)被設(shè)計(jì)用于廣播網(wǎng)絡(luò)，ppp 協(xié)議用于點(diǎn)對點(diǎn)網(wǎng)絡(luò)莫湘，看幀格式就能明顯看出區(qū)別來尤蒿，以太網(wǎng)幀中有目標(biāo) Mac 地址，用于在多路信道確認(rèn)目標(biāo)端機(jī)器幅垮。而點(diǎn)對點(diǎn)協(xié)議中就沒有目標(biāo) mac腰池，點(diǎn)對點(diǎn)鏈路兩端的主機(jī)事先就已經(jīng)知道鏈路那頭是哪個 ip 了
以太網(wǎng)采用的無連接、不可靠的工作方式忙芒，對發(fā)送的數(shù)據(jù)幀不進(jìn)行編號示弓，也不要求對方發(fā)回確認(rèn)，目的站收到有差錯幀就把它丟掉呵萨，其他什么也不做

2.1 封裝成幀

其實(shí)就是在幀的數(shù)據(jù)部分添加幀首部和幀尾部奏属，幀首尾用于幀定界，而數(shù)據(jù)部分才是傳遞給上層的數(shù)據(jù)（即 IP 數(shù)據(jù)報(bào)）
MTU：Maximum Transfer Uint潮峦，幀的數(shù)據(jù)部分的最大長度囱皿，即 IP 數(shù)據(jù)報(bào)長度
我們將幀首部記作 SOH勇婴，幀尾部記作 EOT，用于幀定界
幀的邏輯結(jié)構(gòu)如下圖所示嘱腥，SOH咆耿、EOT 的具體內(nèi)容則和具體協(xié)議有關(guān)，例如 PPP 協(xié)議和以太網(wǎng)協(xié)議有不同的幀格式

幀結(jié)構(gòu)圖

2.2 透明傳輸

由于我們使用了幀定界符 SOH爹橱，EOT萨螺，但數(shù)據(jù)部分也有可能包含定界符，從而導(dǎo)致幀定界出錯愧驱，因此需要實(shí)現(xiàn)透明傳輸
數(shù)據(jù)部分如果出現(xiàn)了 SOH慰技，EOT，我們在其之前添加一個轉(zhuǎn)義字符 ESC组砚，這樣就能將其識別為數(shù)據(jù)而不是幀定界符吻商，如果數(shù)據(jù)部分也包含 ESC，則可以在 ESC 之前再添加一個 ESC

透明傳輸
透明傳輸?shù)姆椒ㄖ饕凶止?jié)填充和零比特填充兩種

2.3 差錯處理

差錯產(chǎn)生的原因：數(shù)據(jù)信號從發(fā)送端發(fā)送到物理線路時(shí)糟红，由于物理線路存在噪聲艾帐，因此數(shù)據(jù)信號經(jīng)過物理線路的噪聲，到達(dá)接收端時(shí)盆偿，已經(jīng)是數(shù)據(jù)+噪聲的疊加柒爸，因此差錯無法避免

差錯
由于存在噪聲，可能出現(xiàn)比特錯誤事扭、幀丟失捎稚、幀重復(fù)和幀失序等錯誤
差錯控制主要兩種策略：檢錯和糾錯
- 檢測碼：發(fā)送冗余信息讓接收端用于檢錯
- 糾錯碼：發(fā)送足夠的冗余信息讓接收端能發(fā)現(xiàn)并自動糾錯
由于糾錯碼實(shí)現(xiàn)比較復(fù)雜，檢測碼雖然不能糾錯求橄，但是足夠簡單今野，能夠檢測出差錯，配合重傳機(jī)制即可罐农。所以廣泛采用檢測碼
循環(huán)冗余檢驗(yàn)（CRC）即為最常見的檢錯方式

2.4 循環(huán)冗余檢驗(yàn) CRC

為了保證數(shù)據(jù)傳輸?shù)目煽啃蕴跛珻RC 是數(shù)據(jù)鏈路層廣泛使用的一種檢錯技術(shù)
其概念性運(yùn)算如圖所示

CRC校驗(yàn)概念
CRC 校驗(yàn)舉例如圖所示

CRC校驗(yàn)舉例

2.5 點(diǎn)對點(diǎn)協(xié)議 PPP

點(diǎn)對點(diǎn)協(xié)議 PPP 是數(shù)據(jù)鏈路層的一種協(xié)議，用于點(diǎn)對點(diǎn)信道涵亏，它的特點(diǎn)是：簡單宰睡，只檢測差錯而不去糾正差錯，不使用序號溯乒，也不進(jìn)行流量控制夹厌，可同時(shí)支持多種網(wǎng)絡(luò)層協(xié)議
簡單：接收方每接收一個幀，就進(jìn)行 CRC 檢驗(yàn)裆悄，檢驗(yàn)正確矛纹，就收下，否則就丟棄光稼，它是不可靠傳輸或南，所以這就是簡單的原因
用戶計(jì)算機(jī)和 ISP 進(jìn)行通信時(shí)使用 PPP 協(xié)議孩等，例如 PPPoE 為寬帶上網(wǎng)的主機(jī)使用的鏈路層協(xié)議（連著一條線，不用尋址）
PPP 協(xié)議幀格式如下

PPP幀格式
F：即幀定界標(biāo)志采够，規(guī)定為 0x7E肄方，即 01111110
A：下一個目的地的 MAC 地址，由于點(diǎn)對點(diǎn)無需 MAC 地址蹬癌，因此固定位 FF权她，沒什么用
C：控制字段，固定位 03逝薪，沒什么用
協(xié)議：2 字節(jié)隅要，描述協(xié)議類型
- 0x0021：PPP 幀的信息字段就是 IP 數(shù)據(jù)報(bào)
- 0xC021：PPP 鏈路控制協(xié)議 LCP 的數(shù)據(jù)
- 0x8021：網(wǎng)絡(luò)層的控制數(shù)據(jù)
FCS：用于 CRC 校驗(yàn)
透明傳輸采用字節(jié)填充或者零比特填充（SONET/SDH鏈路時(shí)），異步傳輸時(shí)使用字節(jié)填充董济，同步傳輸時(shí)使用零比特填充

2.6 廣播信道步清、以太網(wǎng)與局域網(wǎng)

2.6.1 概述與關(guān)系

以太網(wǎng)：以太網(wǎng)是通信協(xié)議標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)定義了在局域網(wǎng)（LAN）中采用的電纜類型和信號處理方法
局域網(wǎng)：在較小范圍內(nèi)組建的網(wǎng)絡(luò)虏肾，通過交換器什么的連接各個PC機(jī)廓啊，比如一個實(shí)驗(yàn)室，一棟樓封豪，一個校園內(nèi)谴轮，這都市局域網(wǎng)，拿網(wǎng)線將兩臺計(jì)算機(jī)連在一起撑毛，這也能算是局域網(wǎng)
區(qū)別：以太網(wǎng)是一種局域網(wǎng)书聚，而局域網(wǎng)卻不一定是以太網(wǎng)，大多數(shù)局域網(wǎng)就是采用了以太網(wǎng)的這個標(biāo)準(zhǔn)
在局域網(wǎng)中藻雌，就采用的是廣播信道：就是一臺PC機(jī)發(fā)送數(shù)據(jù)給另一臺PC機(jī)，在同一個局域網(wǎng)中的計(jì)算機(jī)都能接收到該數(shù)據(jù)斩个，這就像廣播一樣胯杭，所以這種就叫做廣播信道

2.6.2 CSMA/CD協(xié)議（半雙工通信）

局域網(wǎng)是用廣播信道的方式去傳送數(shù)據(jù)，那么就會遇到問題受啥，如果在局域網(wǎng)內(nèi)有兩個pc機(jī)同時(shí)在其中傳播數(shù)據(jù)呢做个？就會發(fā)生碰撞，使兩個數(shù)據(jù)都失效滚局，那么如何解決這個問題呢居暖，使用 CSMA/CD 協(xié)議來解決這類問題
CSMA/CD 可簡單描述為：多址接入、載波監(jiān)聽藤肢、碰撞檢測
多址接入：該協(xié)議為多址接入?yún)f(xié)議太闺，許多站點(diǎn)以多址接入的方式鏈接在一根總線上，其實(shí)就是局域網(wǎng)中總線網(wǎng)這種形式
載波監(jiān)聽：發(fā)送前監(jiān)聽嘁圈，就是在發(fā)送數(shù)據(jù)前監(jiān)聽總線中是否有數(shù)據(jù)在傳播省骂，如果有就不發(fā)送蟀淮。就是用電子技術(shù)檢測總線上有沒有其他計(jì)算機(jī)發(fā)送的數(shù)據(jù)信號
碰撞檢測：
- 邊發(fā)送邊監(jiān)聽，在發(fā)送數(shù)據(jù)的中途也會監(jiān)聽總線中是否會有其它數(shù)據(jù)钞澳，當(dāng)幾個站同時(shí)在總線上發(fā)送數(shù)據(jù)時(shí)怠惶，總線上的信號電壓擺動值將會增大（互相疊加）
- 當(dāng)一個站檢測到的信號電壓擺動值超過一定的門限值時(shí)，就認(rèn)為總線上至少有兩個站同時(shí)在發(fā)送數(shù)據(jù)轧粟，表明產(chǎn)生了碰撞策治。所謂“碰撞”就是發(fā)生了沖突。因此“碰撞檢測”也稱為“沖突檢測”
檢測到碰撞之后的處理 :
- 在發(fā)生碰撞時(shí)兰吟，總線上傳輸?shù)男盘柈a(chǎn)生了嚴(yán)重的失真览妖，無法從中恢復(fù)出有用的信息來
- 每一個正在發(fā)送數(shù)據(jù)的站，一旦發(fā)現(xiàn)總線上出現(xiàn)了碰撞揽祥，就要立即停止發(fā)送讽膏，免得繼續(xù)浪費(fèi)網(wǎng)絡(luò)資源，然后等待一段隨機(jī)時(shí)間后再次發(fā)送

傳播時(shí)延對載波監(jiān)聽的影響

爭用期：發(fā)生碰撞所需要的最遲時(shí)間拄丰，即 $2 \tau$
10 Mbps 的以太網(wǎng)標(biāo)準(zhǔn)規(guī)定連接的最大長度為 2500 m府树，對應(yīng)的爭用期為 51.2μs，則在爭用期內(nèi) 10 Mbps 的以太網(wǎng)可發(fā)送 64 字節(jié)數(shù)據(jù)料按，因此我們發(fā)送幀至少要大于 64 字節(jié)奄侠，否則協(xié)議無法檢測出是否發(fā)生碰撞
對于 100 Mbps 以太網(wǎng)，由于速度增大载矿，如果要保證發(fā)送幀的最短有效幀仍然為 64 秒垄潮，則我們需要將爭用期變?yōu)樵瓉淼氖种?5.12μs，因此百兆以太網(wǎng)允許最大連接長度要為 250 m闷盔，其爭用期為 5.12μs弯洗，在爭用期內(nèi)最多發(fā)送 64 字節(jié)數(shù)據(jù)，因此仍然符合最短有效幀的定義
由此可見逢勾，以太網(wǎng)的速率越快牡整，以太網(wǎng)的有效距離就越短，對于 1000 Mbps 的以太網(wǎng)溺拱，要么放棄 CSMA/CD 協(xié)議改用其他協(xié)議逃贝，若仍要使用該協(xié)議，為了在爭用期內(nèi)檢測出碰撞迫摔，就要再一次減小最大有效傳輸距離變?yōu)?25 m沐扳；若不想減小距離，則只能考慮將最短有效幀變?yōu)樵瓉戆僬滓蕴W(wǎng)的 10 倍
最短有效幀：64 字節(jié)句占，就是上面這樣算的沪摄，發(fā)送了 64 個字節(jié)之后，肯定就不會發(fā)生碰撞，以太網(wǎng)規(guī)定了最短有效幀長為 64 字節(jié)卓起，凡長度小于 64 字節(jié)的幀都是由于沖突而異常中止的無效幀
根據(jù) MAC 幀的格式和敬，還有目的 MAC 地址 6 字節(jié)、源 MAC 地址 6 字節(jié)戏阅、類型 2 字節(jié)昼弟、FCS 4 字節(jié)，因此以太網(wǎng)數(shù)據(jù)部分最短 46 字節(jié)奕筐，最長即 MTU = 1500 字節(jié)

二進(jìn)制指數(shù)類型退避算法

確定基本退避時(shí)間舱痘，一般就是爭用期 $2 \tau$
確定參數(shù) k = min(重傳次數(shù), 10)
從整數(shù)集合 [0, 1, ..., 2^k-1] 中隨機(jī)選取一個數(shù)，記作 r离赫，重傳所需要等待的時(shí)延就是 r 倍的基本退避時(shí)間( $2 \tau \times r$ )
當(dāng)重傳 16 次還不能成功則丟棄該幀芭逝，并向高層匯報(bào)

2.6.3 以太網(wǎng)

在局域網(wǎng)內(nèi)部，以太網(wǎng)廣播數(shù)據(jù)渊胸，并通過 MAC 地址確定目的方是否接受數(shù)據(jù)
MAC 地址：48 bit旬盯，6 字節(jié)，前 3 個字節(jié)是由管理機(jī)構(gòu)給各個廠家分配的翎猛，也就是說如果有廠家想生產(chǎn)網(wǎng)卡這類需要mac地址的東西胖翰，必須先像管理機(jī)構(gòu)申請前三位字節(jié); 所以網(wǎng)卡上的前三個字節(jié)就代表著某個廠家，后三個字節(jié)就是由廠家自己來設(shè)定的
每個網(wǎng)卡都擁有識別數(shù)據(jù)幀中 mac 地址的功能
以太網(wǎng)定義的數(shù)據(jù)幀格式如圖所示

以太網(wǎng)幀
目的地址切厘、源地址即 MAC 地址萨咳，類型為數(shù)據(jù)包的類型，數(shù)據(jù)部分即為 IP 數(shù)據(jù)包疫稿，F(xiàn)CS 用于 CRC 校驗(yàn)
開頭的 8 個字節(jié)為前同步碼（7 字節(jié)） + 幀定界（1 字節(jié)）
前同步碼是為了讓接收方有反應(yīng)時(shí)間培他，在接受 MAC 幀后，并不能馬上識別出幀開始定界符遗座，沒有那么快的反應(yīng)分辨出來舀凛，所以需要在幀定界前面加同步碼，使接收方有反應(yīng)的時(shí)間
同步碼都是 1010101010101 這樣的 bit员萍，前 7 個字節(jié)的同步碼跟最后一個字節(jié)中的前 6 個bit位相同腾降，只有最后兩位不同，如圖

前同步碼

3. 網(wǎng)絡(luò)層

網(wǎng)際協(xié)議 IP 是 TCP/IP 體系中兩個最主要的協(xié)議之一碎绎，是 TCP/IP 體系結(jié)構(gòu)網(wǎng)際層的核心，配套 ARP抗果、RARP筋帖、ICMP、IGMP 協(xié)議進(jìn)行工作
TCP/IP 協(xié)議中的網(wǎng)絡(luò)層向上只提供簡單靈活的冤馏，無連接的日麸，盡最大努力交付的數(shù)據(jù)報(bào)服務(wù)；網(wǎng)絡(luò)層不提供服務(wù)質(zhì)量的承諾，不保證分組交付的時(shí)限所傳送的分組可能出錯代箭，丟失墩划，重復(fù)和失序；進(jìn)程之間通信的可靠性由傳輸層負(fù)責(zé)

3.1 IP 地址

ip 地址由 32 bit 的 0 或 1 組成嗡综，為了書寫方便和易于理解乙帮，將 8 位劃分為一組，每組書寫對應(yīng)的二進(jìn)制數(shù)據(jù)极景，如 192.168.1.1
要上網(wǎng)就需要一個ip地址察净，這個ip地址不能和別人一樣，獨(dú)一無二盼樟，因?yàn)樵诰W(wǎng)絡(luò)上通信就是通過ip地址來找到你這臺主機(jī)的氢卡，但是這個ip地址不是固定的（雖然 ISP 并不會分配一個真正的 IP 地址給你，其內(nèi)部做了映射）
舊版的 IP 地址劃分采用按類別劃分晨缴，共分為 5 類译秦，并通過子網(wǎng)號劃分子網(wǎng) 劃分子網(wǎng) = <網(wǎng)絡(luò)號>+<子網(wǎng)號>+<主機(jī)號>

IP類別
我們現(xiàn)在采用的 ip 地址算法是：無分類編址 = <網(wǎng)路前綴>+<主機(jī)號>，利用子網(wǎng)掩碼劃分子網(wǎng)

3.2 ARP 協(xié)議

ARP 協(xié)議雖然歸為網(wǎng)絡(luò)層協(xié)議击碗，但其可以看做網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層的中間層筑悴，因?yàn)閿?shù)據(jù)報(bào)在封裝成幀時(shí)需要 MAC 地址，而 ARP 協(xié)議就是用于根據(jù) IP 地址獲取 MAC 地址
地址解析協(xié)議：通過 ip 地址來解析主機(jī)的 mac 地址
若在一個局域網(wǎng)中延都，A 知道 B 的 ip 地址蔬墩，想獲取 B 的 mac 地址，則發(fā)送廣播（若有緩存則不廣播罩抗，直接拿到）窍荧，B 收到后發(fā)現(xiàn)自己就是這個 ip 地址，因此將 mac 地址返回給源主機(jī)殊者，這樣就能拿到 mac 地址与境，封裝成幀進(jìn)行通信了
若不在一個局域網(wǎng)中而是跨網(wǎng)絡(luò)通信，A 通過 ARP 獲取到的是局域網(wǎng)中的路由器的 MAC 地址猖吴，封裝成幀交給路由器摔刁，路由器接收到后，解幀海蔽，后續(xù)操作則交由該路由器
注意：路由器工作在網(wǎng)絡(luò)層共屈，其具有 ARP 協(xié)議，每個路由器都能識別出目標(biāo) ip 地址在哪個路由器上党窜，這其中涉及到了很多算法拗引，路由器能根據(jù)目標(biāo) ip 地址找到下一跳路由器的 mac 地址，然后一步一步跳下去幌衣，直至路由器發(fā)現(xiàn)目標(biāo) ip 地址在當(dāng)前子網(wǎng)中矾削，則用 ARP 廣播得到 MAC 地址（有緩存則不廣播）

ARP 詳解

注意路由器路由器間一般是直連的，大多采用 PPP 協(xié)議
發(fā)送方是主機(jī)，要把 IP 數(shù)據(jù)報(bào)發(fā)送到本網(wǎng)絡(luò)上的另一個主機(jī)哼凯，這時(shí)用 ARP 廣播找到目的主機(jī)的硬件地址
發(fā)送方是主機(jī)欲间，要把 IP 數(shù)據(jù)報(bào)發(fā)送到另一個網(wǎng)絡(luò)上的一個主機(jī)，這時(shí)用 ARP 找到本網(wǎng)絡(luò)上的一個路由器的 MAC 地址断部，用該 MAC 地址和最終 IP 地址封裝成幀發(fā)給路由器猎贴；路由器在接收到幀后，解幀家坎，然后根據(jù)最終 IP 地址轉(zhuǎn)發(fā)該數(shù)據(jù)報(bào)（根據(jù)緩存或者根據(jù)路由選擇算法確定）嘱能，這一步封裝成幀的 MAC 地址為下一個路由器的 MAC 地址，知道轉(zhuǎn)發(fā)至最終路由器確定 IP 在本子網(wǎng)上
發(fā)送方是路由器虱疏，要把 IP 數(shù)據(jù)報(bào)轉(zhuǎn)發(fā)到本網(wǎng)絡(luò)上的一個主機(jī)惹骂，這時(shí)用 ARP 廣播找到目的主機(jī)的硬件地址（最終的路由器找到最終的主機(jī)的 MAC 使用該步）
發(fā)送方是路由器，要把 IP 數(shù)據(jù)報(bào)轉(zhuǎn)發(fā)到另一個網(wǎng)絡(luò)上的一個主機(jī)做瞪。這時(shí)用 ARP 找到本網(wǎng)絡(luò)上的一個路由器的硬件地址对粪。剩下的工作由這個路由器來完成

3.3 IP 協(xié)議

IP 協(xié)議的責(zé)任就是把數(shù)據(jù)從源地址傳送到目的地，它不負(fù)責(zé)保證傳送可靠性装蓬，流控制著拭，包順序和其它對于主機(jī)到主機(jī)協(xié)議來說很普通的服務(wù)

IP 數(shù)據(jù)包

IP 數(shù)據(jù)包的格式如圖所示

IP 數(shù)據(jù)包
IP 數(shù)據(jù)包頭部的固定部分共 20 字節(jié)，每行 32 bit牍帚，4 字節(jié)儡遮，共 5 行
第一行：基本信息
- 版本：4 bit，IP 協(xié)議版本暗赶，普遍為 IPv4鄙币，以后可能 IPv6
- 首部長度：4 bit，最大值為 15蹂随，單位為 4 字節(jié)十嘿，因此首部最大長度為 60 字節(jié)，除去固定的 20 字節(jié)岳锁，可選字段和填充合起來不得超過 40 字節(jié)
- 服務(wù)類型：8 bit绩衷，有些要傳輸?shù)臄?shù)據(jù)要立馬傳達(dá)到對面，比如視頻激率，語音這樣的咳燕，不能跟郵件慢慢吞吞的達(dá)到對方一樣，需要立馬送達(dá)乒躺，這就是為什么需要這個區(qū)分服務(wù)了
- 總長度：16 bit迟郎，描述整個數(shù)據(jù)包的總長度（頭部+數(shù)據(jù)），但數(shù)據(jù)鏈路層中聪蘸，幀的數(shù)據(jù)部分最長不能超過 1500 個字節(jié)（MTU），因此數(shù)據(jù)包不能太大，如果太大就需要分片
第二行：分片信息
- 標(biāo)識：16 bit健爬，一個計(jì)數(shù)器控乾，每產(chǎn)生一個數(shù)據(jù)包，計(jì)數(shù)器就加 1娜遵，當(dāng)數(shù)據(jù)包被分片時(shí)蜕衡，他們的標(biāo)識是一樣的，這樣接收方能識別出各個數(shù)據(jù)包片是同一個數(shù)據(jù)包设拟，以重新組合在一起
- 標(biāo)志：3 bit慨仿，占3位，第一位暫時(shí)沒意義纳胧，第二位 DF：不能分片的意思镰吆，為1時(shí)，不能分片跑慕，為 0 就可以分片第三位 MF 后續(xù)還有分片的意思万皿，為 0 代表這是若干數(shù)據(jù)包中的最后一片
- 片偏移：13 bit，在較長的分組在分片后核行，某片在原分組中的相對位置牢硅，幾個例子，1111芝雪，1111减余，1111，1111 這16位惩系，分成4個數(shù)據(jù)包分片來發(fā)位岔，第一個數(shù)據(jù)包分片的片偏移為 1，第二個為 5蛆挫，第三個為 9赃承，第四個為 13，就是這個意思悴侵，但實(shí)際上片偏移以 8 個字節(jié)為偏移單位瞧剖，也就是說，每個分片的長度一定是 8 字節(jié)的整數(shù)倍可免，上面是以 4 bit 來舉例說明問題抓于，實(shí)際上單位是 8 個字節(jié)（64 bit）為單位
第三行：附加信息
- 生存時(shí)間：8 bit，也就是 ping 命令中顯示的 TTL 字段浇借，跳數(shù)限制捉撮，每經(jīng)過一個路由器，就減 1妇垢，當(dāng)跳到 0 后巾遭，就丟棄該數(shù)據(jù)包肉康。window 系統(tǒng)的起始 TTL 為32、Linux 64灼舍、xp：128
- 上層協(xié)議標(biāo)識：8 bit吼和，數(shù)據(jù)包中數(shù)據(jù)部分使用的是什么協(xié)議，方便目的主機(jī)的 IP 層知道講數(shù)據(jù)部分上交給哪個處理骑素。(也就是下一章要將的 TCP 還是 UDP 協(xié)議)
- 頭部檢驗(yàn)和：16 bit炫乓，這個字段只檢驗(yàn)數(shù)據(jù)報(bào)的首部，但不包括數(shù)據(jù)部分献丑。這是因?yàn)閿?shù)據(jù)報(bào)每經(jīng)過一個路由器末捣，路由器都要重新計(jì)算一下首部檢驗(yàn)和（一些字段，如生存時(shí)間创橄、標(biāo)志箩做、片偏移等都可能發(fā)生變化）不檢驗(yàn)數(shù)據(jù)部分可減少計(jì)算的工作量
第四行：源 IP 地址，32 bit
第五行：目標(biāo) IP 地址筐摘，32 bit
可選部分：為了使整個數(shù)據(jù)包為整數(shù)個字節(jié)而設(shè)置的

3.4 ICMP 協(xié)議

ICMP 協(xié)議是一種面向無連接的協(xié)議卒茬，用于傳輸出錯報(bào)告控制信息，它是一個非常重要的協(xié)議咖熟，它對于網(wǎng)絡(luò)安全具有極其重要的意義
它是 TCP/IP 協(xié)議族的一個子協(xié)議圃酵，屬于網(wǎng)絡(luò)層協(xié)議，主要用于在主機(jī)與路由器之間傳遞控制信息馍管，包括報(bào)告錯誤郭赐、交換受限控制和狀態(tài)信息等
當(dāng)遇到 IP 數(shù)據(jù)無法訪問目標(biāo)、IP 路由器無法按當(dāng)前的傳輸速率轉(zhuǎn)發(fā)數(shù)據(jù)包等情況時(shí)确沸，會自動發(fā)送 ICMP 消息
在 IP 首部中捌锭，其上層協(xié)議類型值為 1
主要包括：ICMP 差錯報(bào)告報(bào)文、ICMP 詢問報(bào)文

3.4.1 ICMP 差錯報(bào)告報(bào)文

檢測在傳送數(shù)據(jù)的過程中罗捎，發(fā)生的錯誤观谦，如果發(fā)生了錯誤，會通過該協(xié)議返回給源主機(jī)一個帶有錯誤原因的數(shù)據(jù)包桨菜，大致有如下可能原因
終點(diǎn)不可達(dá)：發(fā)送數(shù)據(jù)后豁状，路由器或主機(jī)不能完成交付數(shù)據(jù)報(bào)時(shí)，就會往源主機(jī)發(fā)送終點(diǎn)不可達(dá)報(bào)文
源點(diǎn)抑制：當(dāng)路由器或主機(jī)由于網(wǎng)絡(luò)擁塞而丟棄數(shù)據(jù)報(bào)時(shí)倒得，返回一個源點(diǎn)抑制報(bào)文
超時(shí)：
- 參數(shù)問題泻红，在 ip 數(shù)據(jù)包中的首部有的字段不正確時(shí)，丟棄該報(bào)霞掺，返回參數(shù)問題報(bào)文
- 改變路由(重定向)：路由器把改變路由報(bào)文發(fā)送給主機(jī)谊路，讓主機(jī)下次直接經(jīng)過改變后的路由器

3.4.2 ICMP 詢問報(bào)文

回送請求和回答：主機(jī)向特定目標(biāo)發(fā)出詢問，收到此報(bào)文必須返回一個 ICMP 回送回答報(bào)文菩彬，用于測試目的站是否可達(dá)（ping 命令）
時(shí)間戳請求和回答：請某個路由器或主機(jī)回答當(dāng)前的日期和時(shí)間缠劝，用于進(jìn)行時(shí)鐘的同步和測量時(shí)間

3.5 IGMP 協(xié)議

IGMP 是 TCP/IP 協(xié)議族中負(fù)責(zé) IP 組播成員管理的協(xié)議潮梯，用來在 IP 主機(jī)和與其直接相鄰的組播路由器之間建立、維護(hù)組播組成員關(guān)系
IGMP 提供多點(diǎn)傳送功能剩彬，將一個 ip 包拷貝給多個 host 采用該協(xié)議
IGMP 協(xié)議用于多播酷麦，即接收到一個 ip 包后，拷貝多份并并轉(zhuǎn)發(fā)給相連的路由器或主機(jī)

多播
其工作流程大致如圖

IGMP協(xié)議工作流程

3.6 路由

3.6.1 路由的原理

當(dāng)給同一個子網(wǎng)中的主機(jī)發(fā)送數(shù)據(jù)包時(shí)喉恋，直接將 IP 分組組幀廣播即可（APR 能直接獲取到 MAC 然后組幀）
若要給不同子網(wǎng)的主機(jī)發(fā)送數(shù)據(jù)包，則要選擇一個當(dāng)前子網(wǎng)中的可達(dá)路由器母廷，將 IP 分組轉(zhuǎn)發(fā)給該路由器轻黑，讓路由器將 IP 分組轉(zhuǎn)發(fā)到目的地
如果沒有找到這樣的路由器，主機(jī)就把 IP 分組轉(zhuǎn)發(fā)給默認(rèn)網(wǎng)關(guān)琴昆；默認(rèn)網(wǎng)關(guān)是每臺主機(jī)上的一個配置參數(shù)氓鄙，它是當(dāng)前子網(wǎng)的某個路由器端口的 IP 地址
路由器轉(zhuǎn)發(fā) IP 分組時(shí)，只根據(jù) IP 分組中的目的 IP 地址业舍，查表或做路由選擇把 IP 分組送出去
同主機(jī)一樣抖拦，路由器也要判定所處子網(wǎng)是否目的子網(wǎng)，如果是舷暮，就直接把分組發(fā)給對應(yīng)主機(jī)（APR 獲取 MAC态罪，然后組幀），否則下面，繼續(xù)選擇下一個路由轉(zhuǎn)發(fā)
路由器也有它的默認(rèn)網(wǎng)關(guān)复颈，用來傳送不知道往哪兒送的 IP 分組，這樣沥割，通過路由器把知道如何傳送的IP分組正確轉(zhuǎn)發(fā)出去耗啦，不知道的 IP 分組送給“默認(rèn)網(wǎng)關(guān)”路由器，這樣一級級地傳送机杜，IP 分組最終將送到目的地帜讲，送不到目的地的 IP 分組則被網(wǎng)絡(luò)丟棄了

3.6.2 其他補(bǔ)充

路由選擇算法（了解）：將收集到的不同信息填入路由表中，根據(jù)路由表可將目的網(wǎng)絡(luò)與下一站(nexthop)的關(guān)系告訴路由器椒拗。路由器間互通信息進(jìn)行路由更新似将，更新維護(hù)路由表使之正確反映網(wǎng)絡(luò)的拓?fù)渥兓⒂陕酚善鞲鶕?jù)量度來決定最佳路徑陡叠。這就是路由選擇協(xié)議(routing protocol)玩郊，例如路由信息協(xié)議(RIP)、開放式最短路徑優(yōu)先協(xié)議(OSPF)和邊界網(wǎng)關(guān)協(xié)議(BGP)等
路由轉(zhuǎn)發(fā)協(xié)議（了解）：轉(zhuǎn)發(fā)即沿尋徑好的最佳路徑傳送信息分組枉阵。路由器首先在路由表中查找译红，判明是否知道如何將分組發(fā)送到下一個站點(diǎn)(路由器或主機(jī))，如果路由器不知道如何發(fā)送分組兴溜，通常將該分組丟棄;否則就根據(jù)路由表的相應(yīng)表項(xiàng)將分組發(fā)送到下一個站點(diǎn)侦厚，如果目的網(wǎng)絡(luò)直接與路由器相連耻陕，路由器就把分組直接送到相應(yīng)的端口上。這就是路由轉(zhuǎn)發(fā)協(xié)議(routed protocol)刨沦。

4. 傳輸層

4.1 概述

傳輸層提供端到端通信服務(wù)诗宣，即進(jìn)程和進(jìn)程之間的通信
通過 ip 僅能識別到主機(jī)，要識別到具體的進(jìn)程想诅，則需要利用端口
端口：16 bit 描述召庞，故端口范圍為 0 - 65535，進(jìn)程之間的通訊来破，都要依靠端口篮灼，一個進(jìn)程對應(yīng)一個端口
熟知端口：0 - 1023，描述一些固定的端口號徘禁，如 http 的 80
登記端口：1024 - 49151诅诱，比如 3306，8080 等
客戶端端口：49152-65535送朱，一般我們使用某個軟件娘荡，比如 QQ，其會隨機(jī)拿該范圍的端口驶沼，而不是去那前面固定的炮沐，以避免沖突，等通訊結(jié)束時(shí)商乎，會釋放該端口
傳輸層就是將兩個端口連起來通信的介質(zhì)央拖，其中重要的就是靠兩個協(xié)議，UDP 和 TCP 協(xié)議

4.2 UDP 協(xié)議

4.2.1 UDP 概述與特點(diǎn)

UDP 即用戶數(shù)據(jù)報(bào)協(xié)議鹉戚，其特點(diǎn)為無連接鲜戒、不可靠
無連接：通訊之前不需要建立連接，直接傳輸數(shù)據(jù)
不可靠：將數(shù)據(jù)報(bào)的分組從一臺主機(jī)發(fā)送到另一臺主機(jī)抹凳，但并不保證數(shù)據(jù)報(bào)能夠到達(dá)另一端
在 UDP 情況下遏餐，雖然可以確保發(fā)送消息的大小，卻不能保證消息一定會達(dá)到目的端
沒有超時(shí)和重傳功能赢底，當(dāng) UDP 數(shù)據(jù)封裝到 IP 數(shù)據(jù)報(bào)傳輸時(shí)失都，如果丟失，會發(fā)送一個 ICMP 差錯報(bào)文給源主機(jī)幸冻，即使出現(xiàn)網(wǎng)絡(luò)阻塞情況
UDP 也無法進(jìn)行流量控制粹庞，傳輸途中即使出現(xiàn)丟包，UDP 也不負(fù)責(zé)重發(fā)洽损，甚至當(dāng)出現(xiàn)包的到達(dá)順序雜亂也沒有糾正的功能

4.2.2 UDP 報(bào)文結(jié)構(gòu)

UDP 報(bào)文作為 IP 包的數(shù)據(jù)部分進(jìn)行封裝

UDP報(bào)文
UDP 報(bào)文的格式如圖

UDP 報(bào)文格式
UDP 首部共 64 bit庞溜，8 字節(jié)
源端口號：16 bit，源主機(jī)進(jìn)程端口
目標(biāo)端口號：16 bit碑定，目標(biāo)主機(jī)進(jìn)程端口
UDP 報(bào)文長度：16 bit流码，即 UDP 首部 + 數(shù)據(jù) 的總長度
檢驗(yàn)和：校驗(yàn)首部和偽首部
UDP 偽首部：概念上的東西又官，其實(shí)就是 IP 層的一些數(shù)據(jù)，主要用于檢驗(yàn)和
注意漫试，這里的檢驗(yàn)和是為了 UDP 首部的可靠性而設(shè)計(jì)的六敬，并不是為了 UDP 傳輸?shù)目煽啃裕ㄟ^檢驗(yàn)和驾荣，提供可靠的 UDP首部外构，
由于一個進(jìn)程可能接受多個進(jìn)程過來的報(bào)文，要通過 “源 IP 地址”秘车、“目的 IP 地址”典勇、“協(xié)議號”、“源端口號”叮趴、“目標(biāo)端口號” 進(jìn)行區(qū)分，因此檢驗(yàn)和需要檢驗(yàn)偽首部+首部权烧，不正確的 UDP 報(bào)文直接丟棄

4.2.3 UDP 應(yīng)用舉例

選擇 UDP 必須要謹(jǐn)慎眯亦，在網(wǎng)絡(luò)質(zhì)量令人十分不滿意的環(huán)境下，UDP 協(xié)議數(shù)據(jù)包丟失會比較嚴(yán)重
由于 UDP 的特性：它不屬于連接型協(xié)議般码，因而具有資源消耗小妻率，處理速度快的優(yōu)點(diǎn)，所以通常音頻板祝、視頻和普通數(shù)據(jù)在傳送時(shí)使用 UDP 較多宫静，因?yàn)樗鼈兗词古紶杹G失一兩個數(shù)據(jù)包，也不會對接收結(jié)果產(chǎn)生太大影響
應(yīng)用層協(xié)議中 DNS券时，也就是根據(jù)域名解析 ip 地址的一個協(xié)議孤里，他使用的就是 UDP
DHCP 這個是給各電腦分配 ip 地址的協(xié)議，其中用的也是 UDP 協(xié)議
IGMP橘洞，我們說的多播捌袜，也就是使用的 UDP

4.3 TCP 協(xié)議

4.3.1 TCP 概述

TCP 協(xié)議是面向連接的、可靠傳輸炸枣、有流量控制虏等、擁塞控制、面向字節(jié)流傳輸?shù)群芏鄡?yōu)點(diǎn)的協(xié)議
當(dāng)應(yīng)用層向 TCP 層發(fā)送用于網(wǎng)間傳輸?shù)氖食Α⒂?8 位字節(jié)表示的數(shù)據(jù)流霍衫，TCP 則把數(shù)據(jù)流分割成適當(dāng)長度的報(bào)文段，最大傳輸段大泻钛（MSS）通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳送單元（MTU）限制
之后 TCP 把數(shù)據(jù)包傳給 IP 層敦跌，由它來通過網(wǎng)絡(luò)將包傳送給接收端實(shí)體的 TCP 層

TCP 提供可靠性傳輸

在發(fā)送數(shù)據(jù)前先使用三次握手建立連接，數(shù)據(jù)發(fā)送完畢后使用四次揮手釋放連接
TCP 校驗(yàn)和會校驗(yàn)數(shù)據(jù)部分沸毁，同時(shí)采用連續(xù) ARQ 協(xié)議（回退N峰髓，Go-back-N傻寂；超時(shí)自動重傳）配合滑動窗口協(xié)議來傳輸數(shù)據(jù)以確保傳輸數(shù)據(jù)的可靠性
采用滑動窗口協(xié)議，通過動態(tài)調(diào)整窗口大小來進(jìn)行流量控制
TCP 使用慢啟動携兵、擁塞避免疾掰、快重傳和快恢復(fù)來進(jìn)行擁塞控制

4.3.2 TCP 報(bào)文結(jié)構(gòu)

TCP 報(bào)文結(jié)構(gòu)如圖所示，相比 UDP 報(bào)文結(jié)構(gòu)徐紧，其多了很多的控制字段

TCP 報(bào)文結(jié)構(gòu)
源端口號：16 bit
目標(biāo)端口號：16 bit
序列號：32 bit静檬，因?yàn)?TCP 是面向字節(jié)流的，他會將報(bào)文都分成一個個字節(jié)并级，給每個字節(jié)進(jìn)行序號編寫拂檩，比如一個報(bào)文有 900 個字節(jié)組成，那么就會編成 1-900 個序號嘲碧，然后分幾部分來進(jìn)行傳輸稻励，比如第一次傳，序列號就是 1愈涩，傳了 50 個字節(jié)望抽，那么第二次傳，序列號就為51履婉，所以序列號就是傳輸?shù)臄?shù)據(jù)的第一個字節(jié)相對所有的字節(jié)的位置
確認(rèn)應(yīng)答：如剛說的例子煤篙，第一次傳了 50 個字節(jié)給對方，對方也會回應(yīng)你毁腿，其中帶有確認(rèn)應(yīng)答辑奈，就是告訴你下一次要傳第 51 個字節(jié)來了，所以這個確認(rèn)應(yīng)答就是告訴對方要傳第多少個字節(jié)了（傳的的以確認(rèn) + 1）
首部長度：4 bit已烤，單位是 32 bit鸠窗，4 字節(jié)，因此報(bào)文頭部最長 60 字節(jié)
保留控制位：6 bit草戈，給以后有需要在用
控制位：6 bit
- URG：緊急塌鸯，當(dāng) URG 為 1 時(shí)，表名緊急指針字段有效唐片，標(biāo)識該報(bào)文是一個緊急報(bào)文丙猬，傳送到目標(biāo)主機(jī)后，不用排隊(duì)费韭，應(yīng)該讓該報(bào)文盡量往下排茧球，讓其早點(diǎn)讓應(yīng)用程序給接受
- ACK：確認(rèn)，當(dāng) ACK 為1時(shí)星持，確認(rèn)序號才有效抢埋。當(dāng) ACK 為0時(shí)俩莽，確認(rèn)序號沒用
- PSH：推送驹暑，當(dāng)為 1 時(shí)蛮位，當(dāng)遇到此報(bào)文時(shí)严蓖，會減少數(shù)據(jù)向上交付，本來想應(yīng)用進(jìn)程交付數(shù)據(jù)是要等到一定的緩存大小才發(fā)送的饥努，但是遇到它捡鱼，就不用在等足夠多的數(shù)據(jù)才向上交付，而是讓應(yīng)用進(jìn)程早點(diǎn)拿到此報(bào)文酷愧，這個要和緊急分清楚驾诈，緊急是插隊(duì)，但是提交緩存大小的數(shù)據(jù)不變溶浴，這個推送就要排隊(duì)乍迄，但是遇到他的時(shí)候，會減少交付的緩存數(shù)據(jù)士败，提前交付
- RST：復(fù)位闯两，報(bào)文遇到很嚴(yán)重的差錯時(shí)，比如 TCP 連接出錯等谅将，會將 RST 置為 1生蚁，然后釋放連接，全部重新來過
- SYN：同步戏自，在進(jìn)行連接的時(shí)候，也就是三次握手時(shí)用得到伤锚，下面會具體講到擅笔，配合 ACK 一起使用
- FIN：終止，在釋放連接時(shí)屯援，也就是四次揮手時(shí)用的
窗口：指發(fā)送報(bào)文段一方的接受窗口大小猛们，用來控制對方發(fā)送的數(shù)據(jù)量(從確認(rèn)號開始，允許對方發(fā)送的數(shù)據(jù)量)狞洋，也就是后面需要講的滑動窗口的窗口大小弯淘，用于流量控制
檢驗(yàn)和：檢驗(yàn)首部和數(shù)據(jù)這兩部分，和 UDP 一樣吉懊，需要拿到偽首部中的數(shù)據(jù)來幫助檢測（可靠性的基礎(chǔ)庐橙，此外還有重傳）
選項(xiàng)：長度可變，介紹一種選項(xiàng)借嗽，最大報(bào)文段長度态鳖，MSS；能夠告訴對方 TCP恶导，我的緩存能接受報(bào)文段的數(shù)據(jù)字段的最大長度是 MSS 個字節(jié)浆竭；如果沒有使用選項(xiàng)，那么首部固定是 20 個字節(jié)
填充：配合選項(xiàng)，就是為了讓其成為整數(shù)個字節(jié)

4.3.3 面向連接：三次握手

TCP 是面向連接的邦泄，在通信之前删窒，會先通過三次握手的機(jī)制來確認(rèn)兩端口之間的連接是否可用；而 UDP 不需要確認(rèn)是否可用顺囊，直接傳
三次握手的步驟如圖所示：

三次握手
說明：ACK 為確定標(biāo)志肌索，SYN 為同步標(biāo)志，seq 為序號包蓝，ack 為確認(rèn)序號（值為成功接收的序號+1）驶社；只有 ACK=1 時(shí)，ack 才有用测萎，此時(shí)表示該報(bào)文為確認(rèn)報(bào)文
一開始客戶端和服務(wù)端都是關(guān)閉狀態(tài)亡电，但是在某個時(shí)刻，客戶端需要和服務(wù)端進(jìn)行通信硅瞧，此時(shí)雙方都會各自準(zhǔn)備好端口份乒，服務(wù)器段的端口會處于監(jiān)聽狀態(tài)，等待客戶端的連接
首先腕唧，客戶端要知道自身的端口號或辖，和目的進(jìn)程的端口號，這樣才能發(fā)起請求枣接，且服務(wù)端要處于監(jiān)聽狀態(tài)（LISTEN）颂暇，才能握手
第一次握手：客戶端想與服務(wù)器進(jìn)行連接了，所以狀態(tài)變?yōu)橹鲃哟蜷_但惶，同時(shí)發(fā)送一個連接請求報(bào)文給服務(wù)器段 SYN=1耳鸯，并且會攜帶 x 個字節(jié)過去；發(fā)送完請求連接報(bào)文后膀曾，客戶端的狀態(tài)就變?yōu)榱?SYN_SENT县爬，可以說這個狀態(tài)是等待發(fā)送確認(rèn)(為了發(fā)送第三次握手時(shí)的確認(rèn)包)
第二次握手：服務(wù)端接收到連接請求報(bào)文后，從 LSTTEN 狀態(tài)變?yōu)楸粍哟蜷_狀態(tài)添谊，然后給客戶端返回一個報(bào)文财喳；這個報(bào)文有兩層意思，一是確認(rèn)報(bào)文斩狱，而可以達(dá)到告訴客戶端耳高，我也打開連接了；發(fā)完后喊废，變?yōu)镾YN_RCVD 狀態(tài)(也可以說是等待接受確認(rèn)狀態(tài)祝高，接受客戶端發(fā)過來的確認(rèn)包)
第三次握手：客戶端得到服務(wù)器端的確認(rèn)和知道服務(wù)器端也已經(jīng)準(zhǔn)備好了連接后，還會發(fā)一個確認(rèn)報(bào)文到服務(wù)器端污筷，告訴服務(wù)器端工闺，我接到了你發(fā)送的報(bào)文乍赫，接下來就讓我們兩個進(jìn)行連接了÷襟。客戶端發(fā)送完確認(rèn)報(bào)文后雷厂，進(jìn)入 ESTABLISHED，而服務(wù)器接到了叠殷，也變?yōu)?ESTABLISHED

為什么是三次握手

參考回答

4.3.4 同時(shí)打開連接請求

正常情況下改鲫，通信一方請求建立連接，另一方響應(yīng)該請求林束，但是如果出現(xiàn)像棘，通信雙方同時(shí)請求建立連接時(shí)，則連接建立過程并不是三次握手過程壶冒，而且這種情況的連接也只有一條缕题，并不會建立兩條連接
同時(shí)打開連接時(shí)，兩邊幾乎同時(shí)發(fā)送 SYN胖腾，并進(jìn)入 SYN_SENT 狀態(tài)烟零，當(dāng)每一端收到 SYN 時(shí)，狀態(tài)變?yōu)?SYN_RCVD咸作，同時(shí)雙方都再發(fā) SYN 和 ACK 作為對收到的 SYN 進(jìn)行確認(rèn)應(yīng)答
當(dāng)雙方都收到 SYN 及相應(yīng)的 ACK 時(shí)锨阿，狀態(tài)變?yōu)?ESTABLISHED

同時(shí)建立連接

4.3.5 可靠傳輸：連續(xù) ARQ 協(xié)議、滑動窗口協(xié)議

主要通過數(shù)據(jù)編號记罚、積累確認(rèn)墅诡、以字節(jié)為單位的滑動窗口、超時(shí)重傳時(shí)間桐智、快速重傳這四個方面來達(dá)到可靠傳輸?shù)哪康?/li>
快速重傳：在滑動窗口中的應(yīng)用书斜，比如傳了1234 6到服務(wù)器端，老辦法是在 4 之后的所有數(shù)據(jù)度要重新傳酵使，而引入擁塞控制的快速重傳就只需要等待傳了 5 這個序號，就可以繼續(xù)往下接收數(shù)據(jù)了（連發(fā)三個 5 的確認(rèn)包）

停止等待 ARQ 協(xié)議

ARQ 協(xié)議焙糟，即自動重傳請求協(xié)議口渔，是 OSI 模型中用于數(shù)據(jù)鏈路層和傳輸層的糾錯協(xié)議之一，通過確認(rèn)和超時(shí)兩個機(jī)制來在不可靠的信道上實(shí)現(xiàn)可靠性傳輸
ARQ 包括停止等待 ARQ 協(xié)議和連續(xù) ARQ 協(xié)議穿撮，其中后者需要配合滑動窗口協(xié)議使用
TCP 會劃分報(bào)文缺脉，對數(shù)據(jù)進(jìn)行按序分組并按序發(fā)送，停止等待 ARQ 協(xié)議在發(fā)送完一個分組后悦穿，就會暫停下來等待收到確認(rèn)攻礼，若收到了確認(rèn)就繼續(xù)發(fā)送下一個分組
若超過一定的時(shí)間沒有收到確認(rèn)，則認(rèn)為剛才的分組丟失栗柒，所以會自動重新發(fā)送剛才發(fā)送過的分組礁扮，然后再次停下來等待確認(rèn)，即所謂的超時(shí)重傳
超時(shí)重傳的原理即通過一個超時(shí)定時(shí)器實(shí)現(xiàn)，每發(fā)送完一個分組太伊，則設(shè)置一個超時(shí)定時(shí)器雇锡，若計(jì)時(shí)器到期之前未收到確認(rèn)則觸發(fā)超時(shí)重傳，若收到確認(rèn)信息則撤銷該定時(shí)器僚焦，繼續(xù)發(fā)送下一分組數(shù)據(jù)
通過上述確認(rèn)和超時(shí)重傳機(jī)制锰提，就可以在不可靠的網(wǎng)絡(luò)上實(shí)現(xiàn)可靠性傳輸
停止等待 ARQ 協(xié)議的優(yōu)點(diǎn)是簡答，但也有很嚴(yán)重的缺點(diǎn)芳悲，就是信道利用率太低

連續(xù) ARQ 協(xié)議

由于停止等待 ARQ 協(xié)議信道利用率太低立肘，所以需要使用連續(xù) ARQ 協(xié)議來進(jìn)行改善，這個協(xié)議會連續(xù)發(fā)送一組數(shù)據(jù)包名扛，然后再等待這些數(shù)據(jù)包的 ACK
連續(xù) ARQ 協(xié)議以字節(jié)為單位進(jìn)行傳輸谅年，即會對數(shù)據(jù)以字節(jié)為大小按序編號，但我們在描述時(shí)使用術(shù)語分組（停止等待 ARQ 協(xié)議可能是多個字節(jié)的分組為單位）
發(fā)送方采用流水線傳輸罢洲，即發(fā)送方可以連續(xù)發(fā)送多個分組踢故，不必每發(fā)完一個分組就停下來等待對方確認(rèn)
連續(xù) ARQ 協(xié)議通常是結(jié)合滑動窗口協(xié)議來使用的，發(fā)送方需要維持一個發(fā)送窗口
位于發(fā)送窗口內(nèi)的分組都可以連續(xù)發(fā)送出去惹苗，而不需要等待對方的確認(rèn)殿较，這樣就提高了信道利用率
而接收方采用累積確認(rèn)的方式，也就是說接收方不必對收到的分組逐個發(fā)送確認(rèn)桩蓉，而是在收到幾個分組后淋纲，對按序到達(dá)的最后一個分組發(fā)送確認(rèn)，發(fā)送方如果收到了這個分組確認(rèn)信息院究，則表示到這個分組為止的所有分組都已經(jīng)正確接收到了
發(fā)送方收到確認(rèn)后洽瞬，根據(jù)確認(rèn)序號往后滑動窗口，若一定時(shí)間后未收到確認(rèn)业汰，則觸發(fā)超時(shí)重傳機(jī)制伙窃，重發(fā)窗口內(nèi)的數(shù)據(jù)
累積確認(rèn)的優(yōu)點(diǎn)是容易實(shí)現(xiàn)，即使窗口中間數(shù)據(jù)的確認(rèn)丟失也不必重傳样漆；但缺點(diǎn)是为障，不能正確的向發(fā)送方反映出接收方已經(jīng)正確收到的所以分組的信息；比如發(fā)送方發(fā)送了前 5 個分組放祟，而中間的第 3 個分組丟失了鳍怨，這時(shí)候接收方只能對前 2 個發(fā)出確認(rèn)，而不知道后面 3 個分組的下落跪妥，因此只能把后面的 3 個分組都重傳一次鞋喇，這種機(jī)制叫 Go-back-N（回退N），表示需要再退回來重傳已發(fā)送過的 N 個分組

滑動窗口協(xié)議

滑動窗口協(xié)議在在發(fā)送方和接收方之間各自維持一個滑動窗口眉撵，發(fā)送發(fā)是發(fā)送窗口侦香，接收方是接收窗口落塑，而且這個窗口是隨著時(shí)間變化可以向前滑動的
它允許發(fā)送方發(fā)送多個分組而不需等待確認(rèn)，TCP 的滑動窗口是以字節(jié)為單位的
如下圖所示鄙皇，發(fā)送窗口中有四個概念：

發(fā)送窗口
- 已發(fā)送并收到確認(rèn)的數(shù)據(jù)（不在發(fā)送窗口和發(fā)送緩沖區(qū)之內(nèi)）
- 已發(fā)送但未收到確認(rèn)的數(shù)據(jù)（位于發(fā)送窗口之內(nèi)芜赌，會觸發(fā)超時(shí)重傳）
- 允許發(fā)送但尚未發(fā)送的數(shù)據(jù)（位于發(fā)送窗口之內(nèi)，且在下次窗口滑動后發(fā)送）
- 發(fā)送窗口之外的緩沖區(qū)內(nèi)暫時(shí)不允許發(fā)送的數(shù)據(jù)
對于已發(fā)送但未收到確認(rèn)的數(shù)據(jù)伴逸，都暫時(shí)保留在緩沖區(qū)缠沈，以便在超時(shí)重傳時(shí)使用
只有當(dāng)發(fā)送方接收到接收方的確認(rèn)報(bào)文時(shí)，發(fā)送方才會使用滑動窗口協(xié)議向前滑動窗口

滑動窗口
若發(fā)送方經(jīng)過一段時(shí)間后沒有收到已發(fā)送的數(shù)據(jù)的確認(rèn)（由超時(shí)控制器控制）错蝴，則觸發(fā)超時(shí)重傳洲愤，在滑動窗口中即 Go-back-N 回退機(jī)制
此外，通過設(shè)置發(fā)送方的窗口大小進(jìn)行流量控制和擁塞控制

4.3.6 流量控制：動態(tài)調(diào)整窗口大小

所謂的流量控制就是讓發(fā)送方的發(fā)送速率不要太快顷锰，讓接收方來得及接受柬赐，利用滑動窗口機(jī)制可以很方便的在 TCP 連接上實(shí)現(xiàn)對發(fā)送方的流量控制
我們已經(jīng)知道，基于連續(xù) ARQ 的可靠性傳輸中官紫，接收方會給出確認(rèn)報(bào)文肛宋，而流量控制就是通過在確認(rèn)報(bào)文中告訴接口方可用窗口大小來進(jìn)行的
接收方在發(fā)送確認(rèn)報(bào)文時(shí)，會同時(shí)給出接收方的可用窗口大小束世，
發(fā)送方在接收到確認(rèn)報(bào)文時(shí)酝陈，通過報(bào)文中的可用窗口大小動態(tài)調(diào)整發(fā)送窗口大小，其不能超過接收方給出的接收窗口的數(shù)值毁涉，從而達(dá)到流量控制的目的

死鎖的產(chǎn)生和避免

當(dāng)發(fā)送方收到了一個窗口為 0 的確認(rèn)報(bào)文后沉帮，發(fā)送者便停止發(fā)送，等待接收者的后續(xù)確認(rèn)報(bào)文以整窗口大小
但是如果這個窗口不為 0 的后續(xù)確認(rèn)報(bào)文在傳輸過程丟失贫堰，會導(dǎo)致發(fā)送方一直等待下去穆壕，而接收方以為發(fā)送方已經(jīng)收到該應(yīng)答，等待接收新數(shù)據(jù)其屏，這樣雙方就相互等待喇勋，從而產(chǎn)生死鎖
為了避免流量控制引發(fā)的死鎖，TCP 引入持續(xù)計(jì)時(shí)器
若發(fā)送方收到對方的零窗口通知偎行，就啟動持續(xù)計(jì)時(shí)器茄蚯，若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期，就發(fā)送一個零窗口探測報(bào)文段（僅攜帶1字節(jié)的數(shù)據(jù)）- 若接收方仍然返回零窗口睦优，則重置該計(jì)時(shí)器繼續(xù)等待
若窗口不為0，則表示應(yīng)答報(bào)文丟失了壮不，此時(shí)重置發(fā)送窗口后開始發(fā)送汗盘，這樣就避免了死鎖的產(chǎn)生

4.3.7 擁塞控制

其實(shí)跟流量控制差不多，但是站的角度更大询一，此時(shí)既考慮了對方接收不過來隐孽，緩存太多溢出導(dǎo)致癌椿，又考慮在線路中，線路上的傳輸速率就那么大菱阵，但是有很多人同時(shí)用踢俄，發(fā)送的數(shù)據(jù)太多，就會使線路發(fā)現(xiàn)擁塞晴及，也就是路由器可能轉(zhuǎn)發(fā)不過來都办，導(dǎo)致大量數(shù)據(jù)丟失這兩個問題
所以擁塞控制這個解決方案，大概意思就是當(dāng)檢測到有網(wǎng)絡(luò)擁塞時(shí)虑稼，就會讓自己的滑動窗口變小琳钉，但具體是怎么變化的，就是根據(jù)算法來算了
發(fā)送窗口的上限值 = Min[rwnd蛛倦，cwnd]
rwnd：接收端窗口（Reciver Window)歌懒，即確認(rèn)報(bào)文中給出的窗口大小
cwnd：擁塞窗口（Congestion Window)，發(fā)送端根據(jù)自己估計(jì)的網(wǎng)絡(luò)擁塞程度而設(shè)置的窗口值溯壶，是來自發(fā)送端的擁塞控制
發(fā)送窗口是取兩個中較小值及皂，通過設(shè)置發(fā)送窗口的大小進(jìn)行流量控制和擁塞控制
擁塞控制主要涉及 4 個算法：慢啟動（Slow-start)，擁塞避免（Congestion Avoidance)且改，快重傳（Fast Restrangsmit)和快恢復(fù)（Fast Recovery）

慢啟動原理

當(dāng)主機(jī)開始發(fā)送數(shù)據(jù)時(shí)验烧，如果立即將較大的發(fā)送窗口的全部數(shù)據(jù)字節(jié)都注入到網(wǎng)絡(luò)中，那么由于不清楚網(wǎng)絡(luò)的情況钾虐，有可能引其網(wǎng)絡(luò)擁塞
因此比較好的方法是試探一下噪窘，即從小到達(dá)逐漸增大發(fā)送端的擁塞控制窗口數(shù)值
通常在剛剛開始發(fā)送報(bào)文段時(shí)可先將擁塞窗口 cwnd 設(shè)置為一個最大報(bào)文段的 MSS 的數(shù)值
在每收到一個對新報(bào)文段確認(rèn)后，將擁塞窗口增加至多一個 MSS 的數(shù)值效扫，當(dāng) rwind 足夠大的時(shí)候倔监，為了防止 cwind 的過快增長引起網(wǎng)絡(luò)擁塞，還需要引入另外一個變量：慢開始門限 ssthresh 來進(jìn)行擁塞避免
當(dāng) cwind 到達(dá) ssthresh 值后則過了慢啟動階段菌仁，不再指數(shù)增長浩习，而是改為線性增長

擁塞控制：慢啟動 + 擁塞避免

TCP 初始化連接，將 cwind 設(shè)置為 1济丘，并設(shè)置 ssthresh 初始值
執(zhí)行慢開始算法：cwind 以指數(shù)規(guī)律增長谱秽，直到 cwind == ssthresh 后，開始執(zhí)行擁塞避免摹迷，即讓 cwind 線性增長
當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時(shí)疟赊，把 ssthresh 更新為原值的一半， cwind 設(shè)置為 1峡碉，重新開始慢啟動

快重傳和快恢復(fù)

一條 TCP 連接有時(shí)會因等待重傳計(jì)時(shí)器的超時(shí)而空閑較長的時(shí)間近哟，慢啟動和擁塞避免無法很好的解決這類問題，因此提出了快重傳和快恢復(fù)的擁塞控制方法
快重傳算法并非取消了重傳機(jī)制鲫寄，只是在某些情況下更早的重傳丟失的報(bào)文段 :
- 如果當(dāng)發(fā)送端接收到三個重復(fù)的確認(rèn) ACK 時(shí)吉执，則斷定分組丟失疯淫，立即重傳丟失的報(bào)文段，而不必等待重傳計(jì)時(shí)器超時(shí)
- 相當(dāng)于利用接收方報(bào)告擁塞丟失戳玫，由于重傳計(jì)時(shí)器可能要等比較長熙掺，因此讓接收方重復(fù)報(bào)告三次確認(rèn)，讓發(fā)送方明白丟失了對應(yīng)的內(nèi)容
- 例如：M1咕宿，M2币绩，M3 -----> M1，M3荠列，缺失 M2类浪，則接收方向發(fā)送方持續(xù)發(fā)送 M2 重復(fù)確認(rèn)，當(dāng)發(fā)送方收到 M2 的三次重復(fù)確認(rèn)肌似，則認(rèn)為 M2 報(bào)文丟失费就，啟動快重傳機(jī)制，重傳數(shù)據(jù)川队，其他數(shù)據(jù)發(fā)送數(shù)據(jù)放入隊(duì)列力细，待快重傳結(jié)束后再正常傳輸
快恢復(fù)算法則用于讓 cwind 跳過慢啟動階段 :
- 當(dāng)發(fā)送方連續(xù)收到接收方發(fā)來的三個重復(fù)確認(rèn)時(shí)，就執(zhí)行“乘法減小”算法固额，把 ssthresh 減半眠蚂，這是為了預(yù)防網(wǎng)絡(luò)發(fā)生擁塞
- 由于發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)很可能沒有發(fā)生擁塞，因此現(xiàn)在不執(zhí)行慢開始算法斗躏，而是直接把 cwnd 設(shè)置為 ssthresh 減半后的值逝慧，然后開始執(zhí)行擁塞避免算法，使擁塞窗口的線性增大啄糙，這樣就跳過了慢啟動階段

4.3.8 釋放連接：四次揮手

通信完成后笛臣，需要釋放連接，TCP 通過四次揮手釋放連接隧饼，其步驟大致如圖所示

四次揮手
第一次揮手：從 ESTABLISHED 變?yōu)橹鲃雨P(guān)閉狀態(tài)沈堡，客戶端主動發(fā)送釋放連接請求給服務(wù)器端，F(xiàn)IN=1燕雁；發(fā)送完之后就變?yōu)?FIN_WAIT_1 狀態(tài)诞丽，這個狀態(tài)可以說是等待確認(rèn)狀態(tài)
第二次揮手：
- 服務(wù)器接收到客戶端發(fā)來的釋放連接請求后，狀態(tài)變?yōu)镃LOSE_WAIT拐格，然后發(fā)送確認(rèn)報(bào)文給客戶端僧免，告訴他我接收到了你的請求
- 為什么變?yōu)?CLOSE_WAIT，原因是是客戶端發(fā)送的釋放連接請求捏浊，可能自己這端還有數(shù)據(jù)沒有發(fā)送完呢懂衩，所以這個時(shí)候整個 TCP 連接的狀態(tài)就變?yōu)榱税腙P(guān)閉狀態(tài)，服務(wù)器端還能發(fā)送數(shù)據(jù)，并且客戶端也能接收數(shù)據(jù)勃痴，但是客戶端不能在發(fā)送數(shù)據(jù)了，只能夠發(fā)送確認(rèn)報(bào)文
- 客戶端接到服務(wù)器的確認(rèn)報(bào)文后热康，就進(jìn)入了FIN_WAIT_2狀態(tài)沛申。也可以說這是等待服務(wù)器釋放連接狀態(tài)
第三次揮手：服務(wù)器端所有的數(shù)據(jù)度發(fā)送完了，認(rèn)為可以關(guān)閉連接了姐军，狀態(tài)變?yōu)楸粍雨P(guān)閉铁材，所以向客戶端發(fā)送釋放連接報(bào)文，發(fā)完之后自己變?yōu)?LAST_WAIT 狀態(tài)奕锌，也就是等待客戶端確認(rèn)狀態(tài)
第四次揮手：
- 客戶端接到釋放連接報(bào)文后著觉，發(fā)送一個確認(rèn)報(bào)文，然后自己變?yōu)?TIME_WAIT惊暴，而不是立馬關(guān)閉饼丘，因?yàn)榭蛻舳税l(fā)送的確認(rèn)報(bào)文可能會丟失，丟失的話服務(wù)器就會重傳一個FIN辽话，也就是釋放連接報(bào)文肄鸽，這個時(shí)候客戶端必須還沒關(guān)閉
- 當(dāng)服務(wù)器接受到確認(rèn)報(bào)文后，服務(wù)器就進(jìn)入 CLOSE 狀態(tài)油啤，也就是關(guān)閉了
- 但是由于上面說的這個原因典徘，客戶端必須等待一定的時(shí)間才能夠進(jìn)入 CLOSE 狀態(tài)

4.3.9 同時(shí)釋放連接

正常情況下，通信一方請求連接關(guān)閉益咬，另一方響應(yīng)連接關(guān)閉請求逮诲，并且被動關(guān)閉連接
但是若出現(xiàn)同時(shí)關(guān)閉連接請求時(shí)，通信雙方均從 ESTABLISHED 狀態(tài)轉(zhuǎn)換為 FIN_WAIT_1 狀態(tài)幽告。
任意一方收到對方發(fā)來的 FIN 報(bào)文段后梅鹦，其狀態(tài)均由 FIN_WAIT_1 轉(zhuǎn)變到 CLOSING 狀態(tài)，并發(fā)送最后的 ACK 數(shù)據(jù)段评腺。當(dāng)收到最后的 ACK 數(shù)據(jù)段后帘瞭，狀態(tài)轉(zhuǎn)變化 TIME_WAIT，
在等待 2MSL 時(shí)間后進(jìn)入到 CLOSED 狀態(tài)蒿讥，最終釋放整個 TCP 傳輸連接
上述過程大致如圖所示

同時(shí)釋放連接

4.3.10 補(bǔ)充

關(guān)閉連接時(shí)等待 2 MSL 的原因

TIME_WAIT 狀態(tài)就是用來重發(fā)可能丟失的剛發(fā)出去的 ACK 報(bào)文：在 Client 發(fā)送出最后的 ACK 蝶念，但該 ACK 可能丟失，Server 如果沒有收到 ACK芋绸，將不斷重復(fù)發(fā)送 FIN 片段以再次關(guān)閉
2MSL 是兩倍的 MSL(Maximum Segment Lifetime)媒殉，MSL 指一個片段在網(wǎng)絡(luò)中最大的存活時(shí)間，2MSL 就是一個發(fā)送和一個回復(fù)所需的最大時(shí)間摔敛，如果直到 2MSL廷蓉，Client都沒有再次收到 FIN，推斷服務(wù)端收到信息马昙，結(jié)束 TCP

為什么連接的時(shí)候是三次握手桃犬，關(guān)閉的時(shí)候卻是四次揮手

因?yàn)楫?dāng) Server 端收到 Client 端的 SYN 連接請求報(bào)文后刹悴，可以直接發(fā)送 SYN+ACK 報(bào)文。其中 ACK 報(bào)文是用來應(yīng)答的攒暇，SYN 報(bào)文是用來同步的
但是關(guān)閉連接時(shí)土匀，當(dāng) Server 端收到 FIN 報(bào)文時(shí)，很可能并不會立即關(guān)閉 SOCKET形用，所以只能先回復(fù)一個 ACK 報(bào)文就轧，告訴 Client 端，"你發(fā)的 FIN 報(bào)文我收到了"田度；只有等到我 Server 端所有的報(bào)文都發(fā)送完了妒御，我才能發(fā)送 FIN 報(bào)文淑履，因此不能一起發(fā)送眨业，故需要四步握手

TCP 的 4 個定時(shí)器

超時(shí)重傳定時(shí)器：對報(bào)文段的等待確認(rèn)時(shí)間（連續(xù) ARQ 協(xié)議）
持續(xù)定時(shí)器：用于解決流量控制時(shí)的死鎖問題
Time_Wait 計(jì)時(shí)器：關(guān)閉連接時(shí)的計(jì)時(shí)器吕粗，值一般為 2 MSL
keep alive 計(jì)時(shí)器：連接后很久沒發(fā)送信息辙芍，確認(rèn)是否還活著

5. 應(yīng)用層

5.1 概述

位于計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)的最上層威始，前面四層做的所有事情就是為了他服務(wù)克蚂，也是設(shè)計(jì)和建立計(jì)算機(jī)網(wǎng)絡(luò)的最終目的
通俗的講集绰，就是我們開發(fā)的應(yīng)用軟件十电，就處于這一層揭保，比如肥橙，QQ、瀏覽器訪問網(wǎng)頁等
應(yīng)用層的通信模式大致有兩種：C/S 模式和 P2P 模式
C/S 模式：經(jīng)典的客戶端/服務(wù)端模型秸侣，客戶端請求服務(wù)器數(shù)據(jù)存筏，服務(wù)端給出響應(yīng)，B/S 可以看成該模式的衍生
P2P 模式：也稱為對等體系結(jié)構(gòu)味榛，每個人的電腦度可以當(dāng)服務(wù)器椭坚，也可以當(dāng)客戶端，不單單限制于只能客戶端訪問服務(wù)器

5.2 DNS 協(xié)議

Domain Name System 域名系統(tǒng)搏色，也叫作域名解析協(xié)議善茎，其作用是將域名解析成對應(yīng)的 IP 地址

工作流程

通過域名訪問網(wǎng)頁
計(jì)算機(jī)會先將域名發(fā)送到一個解析域名的服務(wù)器上，該服務(wù)器有如下解析過程：
- 在其服務(wù)器上游很多服務(wù)器频轿，能解析各種各樣的域名垂涯，比如有專門解析 org、com航邢、net 等耕赘，最重要的還有一個根域名服務(wù)器
- 域名解析(在服務(wù)器上查找 IP 地址)的過程有兩種算法，迭代查詢膳殷，遞歸查詢操骡，一般是兩種查詢的結(jié)合
- 本機(jī)計(jì)算機(jī)找到其中一臺解析域名的服務(wù)器(可能是.com)，如果沒有找到對應(yīng)的 IP 地址，那么就會去找根域名服務(wù)器册招，根域名服務(wù)器知道所有的子服務(wù)器岔激，所以他肯定知道該域名所對應(yīng)的 IP 地址在那個子服務(wù)器中，所以告訴第一次查詢的服務(wù)器要他去另一臺服務(wù)器上找是掰，找到了鹦倚，就將其返回給計(jì)算機(jī)，以后在有另一臺計(jì)算機(jī)也通過這個域名訪問冀惭，那么第一臺服務(wù)器會有原來的域名IP地址的緩存，就不用去找根服務(wù)器了
找到了掀鹅，就能找到我們要訪問的服務(wù)器了

DNS解析

5.3 HTTP 協(xié)議

見 HTTP

5.4 HTTPS 協(xié)議

見 HTTPS

6. HTTP 協(xié)議

6.1 概述

6.1.1 http 簡介

協(xié)議：計(jì)算機(jī)通信網(wǎng)絡(luò)中兩臺計(jì)算機(jī)之間進(jìn)行通信所必須共同遵守的規(guī)定或規(guī)則散休，超文本傳輸協(xié)議 HTTP 是一種通信協(xié)議，它允許將超文本標(biāo)記語言 HTML 文檔從 Web 服務(wù)器傳送到客戶端的瀏覽器
HTTP 協(xié)議是 Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫乐尊，是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議戚丸，其是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，所有的 WWW 文件都必須遵守這個標(biāo)準(zhǔn)
HTTP 是一個基于 TCP/IP 通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件扔嵌，圖片文件限府，查詢結(jié)果等）
HTTP是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷痢缎、快速的方式胁勺，適用于分布式超媒體信息系統(tǒng)；它于1990年提出独旷，經(jīng)過幾年的使用與發(fā)展署穗，得到不斷地完善和擴(kuò)展
HTTP 協(xié)議工作于 C/S 架構(gòu)為上：瀏覽器作為 HTTP 客戶端通過 URL 向 HTTP 服務(wù)端即 WEB 服務(wù)器發(fā)送所有請求；Web 服務(wù)器根據(jù)接收到的請求后嵌洼，向客戶端發(fā)送響應(yīng)信息
在上述請求中案疲，我們稱這個客戶端叫用戶代理（user agent）；應(yīng)答的服務(wù)器上存儲著（一些）資源麻养，比如 HTML 文件和圖像褐啡，我們稱這個應(yīng)答服務(wù)器為源服務(wù)器（origin server）
在用戶代理和源服務(wù)器中間可能存在多個中間層，比如代理鳖昌，網(wǎng)關(guān)备畦，或者隧道（tunnels）
盡管 TCP/IP 協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP 協(xié)議并沒有規(guī)定必須使用它和（基于）它支持的層遗遵；事實(shí)上萍恕，HTTP 可以在任何其他互聯(lián)網(wǎng)協(xié)議上，或者在其他網(wǎng)絡(luò)上實(shí)現(xiàn)车要，HTTP 只假定（其下層協(xié)議提供）可靠的傳輸允粤，任何能夠提供這種保證的協(xié)議都可以被其使用
通常，由 HTTP 客戶端發(fā)起一個請求，建立一個到服務(wù)器指定端口（默認(rèn)是 80 端口）的 TCP 連接类垫；HTTP 服務(wù)器則在那個端口監(jiān)聽客戶端發(fā)送過來的請求司光，一旦收到請求，服務(wù)器（向客戶端）發(fā)回一個狀態(tài)行悉患，比如 "HTTP/1.1 200 OK"残家，和響應(yīng)的消息，消息的消息體可能是請求的文件售躁、錯誤消息坞淮、或者其它一些信息
HTTP 使用 TCP 而不是 UDP 的原因在于（打開）一個網(wǎng)頁必須傳送很多數(shù)據(jù)，而 TCP 協(xié)議提供傳輸控制陪捷，按順序組織數(shù)據(jù)回窘，和錯誤糾正

6.1.2 http 特點(diǎn)

簡單快速：客戶向服務(wù)器請求服務(wù)時(shí)，只需傳送請求方法和路徑市袖，請求方法常用的有 GET啡直、HEAD、POST苍碟；每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同酒觅；由于 HTTP 協(xié)議簡單，使得 HTTP 服務(wù)器的程序規(guī)模小微峰，因而通信速度很快
靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對象舷丹，正在傳輸?shù)念愋陀?Content-Type 加以標(biāo)記
短連接：短連接的含義是限制每次連接只處理一個請求，服務(wù)器處理完客戶的請求蜓肆，并收到客戶的應(yīng)答后掂榔，即斷開連接，采用這種方式可以節(jié)省傳輸時(shí)間
無狀態(tài)：HTTP 協(xié)議是無狀態(tài)協(xié)議症杏，無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力装获，缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳厉颤，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大穴豫；另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快
支持 B/S 及 C/S 模式

6.2 URL 和 URI

6.2.1 URL

HTTP 使用統(tǒng)一資源標(biāo)識符（Uniform Resource Identifiers, URI）描述一個網(wǎng)絡(luò)上的資源逼友，來傳輸數(shù)據(jù)和建立連接
URL：統(tǒng)一資源定位符精肃，用來定位我們所需要資源在服務(wù)器上的位置
URL是一種特殊類型的 URI，包含了用于查找某個資源的足夠的信息
格式：<協(xié)議>://<主機(jī)>:<端口>/<路徑>
協(xié)議：http （在 Internet 中可以使用多種協(xié)議帜乞，如 HTTP司抱、FTP 等）
主機(jī)：域名或 IP 地址，原理一樣黎烈，因?yàn)橛蛎罱K會通過 DNS 協(xié)議轉(zhuǎn)化為 IP 地址习柠，通過 IP 地址才能找到目標(biāo)服務(wù)器
端口：在傳輸層需要使用的匀谣，訪問目的主機(jī)的哪個端口號。
路徑：精準(zhǔn)的定位我們所需要的資源位置
錨：從“#”開始到最后资溃，都是錨部分武翎，錨部分也不是一個URL必須的部分
查詢參數(shù)：從 "?" 開始到 "#" 之間的部分為查詢參數(shù)部分，參數(shù)可以允許有多個參數(shù)溶锭，參數(shù)與參數(shù)之間用 "&" 作為分隔符
平常會省略協(xié)議和端口號宝恶，因?yàn)檫@些都是默認(rèn)的，在訪問主頁時(shí)趴捅，路徑也會省略垫毙，比如 www.baidu.com 這個默認(rèn)進(jìn)入百度的主頁的完整寫法為 http://www.baidu.com:80/index.html

6.2.2 URI 和 URL 的區(qū)別

URI：即 uniform resource identifier，統(tǒng)一資源標(biāo)識符拱绑，用來唯一的標(biāo)識一個資源
URL：即 uniform resource locator露久，統(tǒng)一資源定位器，它是一種具體的 URI欺栗，即使用 URL 作為這個唯一標(biāo)識，該標(biāo)識指明了如何 locate 這個資源
采用 URL 可以用一種統(tǒng)一的格式來描述各種信息資源征峦，包括文件迟几、服務(wù)器的地址和目錄等
URL 一般由三部組成：協(xié)議 + 主機(jī) + 端口 + 資源地址

6.3 工作流程

一次 HTTP 操作稱為一個事務(wù)，其工作過程可分為四步：
客戶端發(fā)出 HTTP 請求栏笆，HTTP 的工作開始类腮，首先客戶機(jī)與服務(wù)器需要建立連接（三次握手）
建立連接后，客戶機(jī)發(fā)送一個請求給服務(wù)器蛉加，請求方式的格式為：統(tǒng)一資源標(biāo)識符（URL）蚜枢、協(xié)議版本號，后邊是 MIME 信息包括請求修飾符针饥、客戶機(jī)信息和可能的內(nèi)容
服務(wù)器接到請求后厂抽，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行丁眼，包括信息的協(xié)議版本號筷凤、一個成功或錯誤的代碼，后邊是 MIME 信息包括服務(wù)器信息苞七、實(shí)體信息和可能的內(nèi)容
客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上藐守，然后客戶機(jī)與服務(wù)器斷開連接（四次揮手）
如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端蹂风，有顯示屏輸出
對于用戶來說卢厂，這些過程是由 HTTP 自己完成的，用戶只要用鼠標(biāo)點(diǎn)擊惠啄，等待信息顯示就可以了
HTTP 是基于傳輸層的 TCP 協(xié)議慎恒，而 TCP 是一個端到端的面向連接的協(xié)議任内，所以 HTTP 在開始傳輸之前，首先需要建立 TCP 連接巧号，而 TCP 連接的過程需要所謂的“三次握手”族奢，在 TCP 三次握手之后，建立了 TCP 連接丹鸿，此時(shí) HTTP 就可以進(jìn)行傳輸了
需要注意越走，在 HTTP/1.0 中，默認(rèn)使用的是短連接靠欢，也就是說廊敌，瀏覽器和服務(wù)器每進(jìn)行一次 HTTP 操作，就建立一次連接门怪，但任務(wù)結(jié)束就中斷連接骡澈；如果客戶端瀏覽器訪問的某個 HTML 或其他類型的 Web 頁中包含有其他的 Web 資源，如 JavaScript 文件掷空、圖像文件肋殴、CSS 文件等；當(dāng)瀏覽器每遇到這樣一個 Web 資源坦弟，就會建立一個 HTTP 會話
從 HTTP/1.1 起护锤，默認(rèn)使用長連接，通過請求頭 Connection:keep-alive 設(shè)置長連接酿傍，當(dāng)然同時(shí)需要服務(wù)端的支持烙懦，可以在瀏覽器中查看多個 http 請求的 Connection ID 是否一致驗(yàn)證

6.4 HTTP 請求

6.4.1 HTTP 請求格式

HTTP 請求格式大致如圖所示

HTTP 請求格式
從圖中可以看出，HTTP 請求包括 4 部分：請求行赤炒、請求頭氯析、空行、請求數(shù)據(jù)（也叫請求體）
請求行中包括：
- 請求方法莺褒，如 GET掩缓、POST 等
- 請求 url
- http 版本
請求頭為一對對的鍵值對，附帶一些必要的信息遵岩，例如識別身份等
請求數(shù)據(jù)也叫請求體拾因，放置需要額外傳遞的數(shù)據(jù)，一般 GET 請求請求體為空旷余，因?yàn)楦鶕?jù)標(biāo)準(zhǔn)绢记，有的服務(wù)器會忽略 GET 請求的請求體，若需要傳遞參數(shù)一般通過 URL 中的查詢參數(shù)傳遞

6.4.2 GET 請求報(bào)文舉例

如圖為搜狐官網(wǎng)的 GET 請求報(bào)文

GET 請求報(bào)文

第一部分：請求行

請求行正卧，主要說明請求類型蠢熄、請求的 URL 以及所使用的 HTTP 版本
該請求的請求行為 GET /http://www.sohu.com HTTP/1.1，只不過這里顯示時(shí)被分開了

第二部分：請求頭部分

請求頭跟在請求行之后炉旷，用來說明服務(wù)器要使用的附加信息
HOST：主機(jī)名 www.solu.com签孔，沒有指定端口叉讥，使用默認(rèn)端口 80
User-Agent：用戶代理，此處即為火狐瀏覽器
Accept：能接受的數(shù)據(jù)類型饥追，值為 MIME 的可能取值
Accept-Language：表示用戶希望優(yōu)先想得到的版本图仓，依次排列下去，先是中文但绕，再是英文
Accept-Encoding：通知服務(wù)端可以發(fā)送的數(shù)據(jù)壓縮格式
Cookie：瀏覽器端的一個技術(shù)救崔，在服務(wù)器上記錄用戶信息，但是也會在瀏覽器中保存一份
Connection：連接的方式捏顺，長連接或短連接六孵，HTTP/1.1 默認(rèn)為 keep-alive 即長連接
Upgrade-Insecure-Requests：該指令用于讓瀏覽器自動升級請求從 http 到 https，用于大量包含 http 資源的 http 網(wǎng)頁直接升級到 https 而不會報(bào)錯幅骄，簡潔的來講劫窒，就相當(dāng)于在 http 和 https 之間起的一個過渡作用

第三部分：空行

請求頭部后面的空行是必須的
即使第四部分的請求體為空，也必須有空行

第四部分：請求數(shù)據(jù)/請求體

請求體用于添加額外的數(shù)據(jù)拆座，多用于 POST主巍、PUT 等涉及修改作用的請求
GET 請求理論上也能添加請求體但不建議，因?yàn)榭赡苡械姆?wù)器會直接忽略 GET 請求中的請求體挪凑，因此對于 GET 請求若要傳遞參數(shù)建議使用 url 中的查詢參數(shù)

6.4.3 POST 請求報(bào)文舉例

POST 請求報(bào)文格式如圖孕索，其實(shí)和 GET 差不多

POST 請求報(bào)文
第一部分：請求行，post 請求岖赋，HTTP/1.1 版本
第二部分：請求頭，2 - 6 行
第三部分：空行瓮孙，第 7 行
第四部分：請求體唐断，最常見的有 applicatiopn/x-www-form-urlencoded，application/json 兩種類型

6.4.4 HTTP 常見請求方法

根據(jù) HTTP 標(biāo)準(zhǔn)杭抠，目前為止共有 9 種 HTTP 方法
HTTP/1.0 定義了 3 種請求方法：GET脸甘、POST 和 HEAD 方法
HTTP/1.1 新增了 6 種請求方法：OPTIONS、PUT偏灿、PATCH丹诀、DELETE、TRACE 和 CONNECT 方法
GET：請求指定的頁面信息翁垂，并返回實(shí)體主體
HEAD：類似于 GET 請求铆遭，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報(bào)頭
POST：向指定資源提交數(shù)據(jù)進(jìn)行處理請求（例如提交表單或者上傳文件）沿猜。數(shù)據(jù)被包含在請求體中枚荣，POST 請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改
PUT：從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容
DELETE：請求服務(wù)器刪除指定的頁面
CONNECT：HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器
OPTIONS：允許客戶端查看服務(wù)器的性能
TRACE：回顯服務(wù)器收到的請求，主要用于測試或診斷
PATCH：是對 PUT 方法的補(bǔ)充啼肩，用來對已知資源進(jìn)行局部更新
RESTful Api 約定橄妆，增刪改查對應(yīng) POST衙伶，DELETE，PUT/PATCH害碾，GET
跨域會涉及到 OPTIONS 請求

6.4.5 補(bǔ)充內(nèi)容

GET 和 POST 請求的區(qū)別

GET 一般用于獲取/查詢資源信息矢劲，而 POST 一般用于更新資源信息
GET 請求一般會將參數(shù)放在 url 查詢參數(shù)中，而 POST 請求一般會將數(shù)據(jù)放在請求體中慌随，如經(jīng)典的 application/x-www-form-urlencoded
傳輸數(shù)據(jù)大小的限制：
- 首先明確：HTTP 協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制芬沉，HTTP 協(xié)議規(guī)范也沒有對 URL 長度進(jìn)行限制，這些限制來自于具體實(shí)現(xiàn)
- GET：特定瀏覽器和服務(wù)器對 url 長度的限制儒陨，因此 GET 請求的傳輸數(shù)據(jù)會受到 url 長度限制
- POST：由于不是 url 傳值花嘶，理論上沒有限制，但實(shí)際上各個 Web 服務(wù)器都會對 post 請求的請求體大小進(jìn)行限制
安全性：
- POST 的安全性要比 GET 的安全性高蹦漠，比如通過 GET 提交數(shù)據(jù)椭员，用戶名和密碼將明文出現(xiàn)在 URL 上
- 使用 GET 提交數(shù)據(jù)還可能會造成 Cross-site request forgery 攻擊

打開一個網(wǎng)頁需要瀏覽器發(fā)送多次 HTTP 請求

當(dāng)你在瀏覽器輸入U(xiǎn)RL http://www.cnblogs.com 的時(shí)候，瀏覽器發(fā)送一個 Request 去獲取 http://www.cnblogs.com 的html笛园，服務(wù)器把Response 發(fā)送回給瀏覽器
瀏覽器分析 Response 中的 HTML隘击，發(fā)現(xiàn)其中引用了很多其他文件，比如圖片研铆，CSS文件埋同，JS文件
瀏覽器會自動再次發(fā)送 Request 去獲取圖片，CSS 文件棵红，或者 JS 文件
等所有的文件都下載成功后凶赁。網(wǎng)頁就被顯示出來了

6.5 HTTP 響應(yīng)

6.5.1 HTTP 響應(yīng)格式

HTTP 響應(yīng)格式如圖所示

HTTP 響應(yīng)格式
可以看出，HTTP 響應(yīng)格式和 HTTP 請求格式基本一致逆甜，也包括 4 個部分：響應(yīng)狀態(tài)行虱肄、響應(yīng)頭/消息報(bào)頭、空行交煞、響應(yīng)主體

6.5.2 HTTP 響應(yīng)報(bào)文舉例

如圖

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

第一部分：狀態(tài)行

狀態(tài)行由 HTTP 協(xié)議版本號咏窿，狀態(tài)碼，狀態(tài)消息三部分組成
版本：HTTP/1.1
狀態(tài)碼：200
狀態(tài)消息：OK （狀態(tài)碼基本和狀態(tài)消息一一對應(yīng)）

第二部分：響應(yīng)頭/消息報(bào)頭

消息報(bào)頭用來說明客戶端要使用的一些附加信息
Date：生成響應(yīng)的日期和時(shí)間
Content-Type：響應(yīng)的 MIME 類型及編碼素征，此處為 text/html; charset=UTF-8