目錄
第1章 TCP/IP協(xié)議
1.1 TCP/IP協(xié)議族體系結(jié)構(gòu)以及主要協(xié)議
1.1.1 數(shù)據(jù)鏈路層
1.1.2 網(wǎng)絡(luò)層
1.1.3 傳輸層
1.1.4 應(yīng)用層
1.2 封裝
1.3 分用
1.5 ARP協(xié)議工作原理
1.5.1 以太網(wǎng)ARP請(qǐng)求/應(yīng)答報(bào)文詳解
1.5.2 ARP高速緩存的查看和修改
1.5.3 使用tcpdump觀察ARP通信過(guò)程所得結(jié)果如下
- 本篇核心關(guān)鍵所在不在于是跟大家分享多少知識(shí)點(diǎn),? 而在于推薦大家閱讀這本書籍。
- 小杰不是打廣告，這本書小杰研讀部分之后發(fā)現(xiàn)真實(shí)的是一本經(jīng)典數(shù)據(jù)，文章不僅僅只是枯燥乏味的介紹網(wǎng)絡(luò)基礎(chǔ)知識(shí)和僵硬的介紹網(wǎng)絡(luò)編程
- 而是把很多的系統(tǒng)調(diào)用細(xì)節(jié)知識(shí)點(diǎn)通過(guò)代碼實(shí)際案例來(lái)解釋，前后連貫，先打基礎(chǔ)后通過(guò)代碼前后呼應(yīng), 將學(xué)到的基礎(chǔ)知識(shí)落到實(shí)處上去.??
- 真的是一本特別經(jīng)典的書籍，不是虛吹，說(shuō)再多都沒(méi)啥用，小杰附上百度云盤鏈接一份，感興趣的兄弟可以獲取哈.
- 鏈接：https://pan.baidu.com/s/1FFveRbZDoVXr8ZSwhVPWNw?pwd=kczf?
提取碼：kczf
第1章 TCP/IP協(xié)議
1.1 TCP/IP協(xié)議族體系結(jié)構(gòu)以及主要協(xié)議
TCP/IP協(xié)議棧是一個(gè)四層協(xié)議, 由下而上分別是數(shù)據(jù)鏈路層, 網(wǎng)絡(luò)層, 傳輸層, 應(yīng)用層, 上層協(xié)議使用下層協(xié)議提供的服務(wù).? 下三層處在內(nèi)核態(tài)中, 應(yīng)用層處在用戶空間中.
1.1.1 數(shù)據(jù)鏈路層
鏈路層功能： 屏蔽物理層的電氣差異, 為上層提供統(tǒng)一服務(wù)接口
數(shù)據(jù)鏈路層實(shí)現(xiàn)了網(wǎng)卡接口的網(wǎng)絡(luò)驅(qū)動(dòng)程序, 處理數(shù)據(jù)在不同的物理媒介上的傳輸
不同的物理網(wǎng)絡(luò)具有不同的電氣特性，網(wǎng)絡(luò)驅(qū)動(dòng)程序隱藏了這些細(xì)節(jié)，為上層協(xié)議提供一個(gè)統(tǒng)一的接口。? ??下層協(xié)議為上層提供統(tǒng)一的接口服務(wù), 隱藏屏蔽掉物理層的不同電氣差別.
鏈路層常用協(xié)議: ARP協(xié)議 (地址解析協(xié)議), RARP協(xié)議（逆地址解析協(xié)議）
功能: ARP 將IP地址轉(zhuǎn)換為物理MAC地址.? ? RARP將MAC地址轉(zhuǎn)換為IP地址?
在網(wǎng)絡(luò)層使用IP地址唯一標(biāo)識(shí)一臺(tái)主機(jī), 在鏈路層使用MAC地址唯一標(biāo)識(shí)一臺(tái)主機(jī)
因此網(wǎng)絡(luò)層必須先將目標(biāo)機(jī)器的IP地址轉(zhuǎn)化成其物理地址，才能使用數(shù)據(jù)鏈路層提供的服務(wù)
1.1.2 網(wǎng)絡(luò)層
網(wǎng)絡(luò)層功能：網(wǎng)絡(luò)層實(shí)現(xiàn)數(shù)據(jù)包的選路和轉(zhuǎn)發(fā)
通常使用眾多分級(jí)的路由器來(lái)連接分散的主機(jī)或LAN (局域網(wǎng)), 往往路由器就作為局域網(wǎng)的網(wǎng)關(guān). (借助海關(guān)來(lái)理解).? ?每一個(gè)路由器都相當(dāng)于是一個(gè)中間結(jié)點(diǎn).
網(wǎng)絡(luò)層的任務(wù)就是選擇這些中間節(jié)點(diǎn)（路由），以確定兩臺(tái)主機(jī)之間的通信路徑.?
網(wǎng)絡(luò)層對(duì) 上層協(xié)議隱藏了網(wǎng)絡(luò)拓?fù)溥B接的細(xì)節(jié)，使得在傳輸層和網(wǎng)絡(luò)應(yīng)用程序看來(lái)，通信的雙方是直接相連的。? ? ?（為何要分層, 優(yōu)勢(shì)出來(lái)了, 不同層處理不同的通信細(xì)節(jié)問(wèn)題, 分化分工, 使得問(wèn)題簡(jiǎn)化, 下層協(xié)議為上層協(xié)議提供簡(jiǎn)單易用的接口, 隱藏下層處理的細(xì)節(jié)問(wèn)題）
網(wǎng)絡(luò)層重要協(xié)議：IP協(xié)議,? ICMP協(xié)議? (探路小兵, 主要用來(lái)檢測(cè)連接的)
IP協(xié)議根據(jù)數(shù)據(jù)包的目的IP地址來(lái)決定如何投遞它，如果數(shù)據(jù)包不能直接發(fā)送給目標(biāo)主機(jī)，那么IP協(xié)議就為它尋找一個(gè)合適的下一跳（next hop）路由器，并將數(shù)據(jù)包交付給該路由器來(lái)轉(zhuǎn)發(fā)
數(shù)據(jù)包是在網(wǎng)絡(luò)環(huán)境中, 一跳一跳的傳輸. TTL數(shù)據(jù)包的最長(zhǎng)生存時(shí)間, 單位也是hop, 跳過(guò)TTL還未到達(dá)目標(biāo)主機(jī), 就默認(rèn)發(fā)送失敗, 丟棄數(shù)據(jù)包了, 并且發(fā)送ICMP差錯(cuò)報(bào)文給源端.
ICMP報(bào)文分為差錯(cuò)報(bào)文 (回應(yīng)網(wǎng)絡(luò)錯(cuò)誤) eg: 上述的數(shù)據(jù)包不可達(dá)(3), 重定向(5)
查詢報(bào)文(ping查詢目標(biāo)是否可達(dá), 網(wǎng)絡(luò)是否連接)(8)，? 所以存在類型來(lái)區(qū)分他們.
ICMP報(bào)文還使用8位代碼字段來(lái)進(jìn)一步細(xì)分不同的條件
比如重定向報(bào)文使用代碼值0表示對(duì)網(wǎng)絡(luò)重定向，代碼值1表示對(duì)主機(jī)重定向
ICMP報(bào)文使用16位校驗(yàn)和字段 對(duì)整個(gè)報(bào)文（包括頭部和內(nèi)容部分）進(jìn)行循環(huán)冗余校驗(yàn)（Cyclic Redundancy Check，CRC），以檢驗(yàn)報(bào)文在傳輸過(guò)程中是否損壞
1.1.3 傳輸層
傳輸層只管端到端的傳輸, 傳輸層只關(guān)心通信的起始端和目的端，而不在乎數(shù)據(jù)包的中轉(zhuǎn)過(guò)程。
在傳輸層看來(lái), 兩端好似是直接通信的, 實(shí)際上中間的中轉(zhuǎn)細(xì)節(jié)是由網(wǎng)絡(luò)層處理的? ?(下層對(duì)上層隱藏細(xì)節(jié)，讓上層協(xié)議變得盡可能看起來(lái)很簡(jiǎn)單.)
實(shí)線箭頭表示TCP/IP協(xié)議族各層之間的實(shí)體通信 （數(shù)據(jù)包確實(shí)是沿著這些線路傳遞的），而水平的虛線箭頭表示邏輯通信線路.
該圖中還附帶描述了不同物理網(wǎng)絡(luò)的連接方法。可見(jiàn)，數(shù)據(jù)鏈路層（驅(qū)動(dòng)程序）封裝了物理網(wǎng)絡(luò)的電氣細(xì)節(jié)
傳輸層則為應(yīng)用程序封裝了一條端到端的邏輯通信鏈路，它負(fù)責(zé)數(shù)據(jù)的收發(fā)、鏈路的超時(shí)重連等
下層都是在為上層提供服務(wù), 提供便捷, 隱藏細(xì)節(jié).?
傳輸層重點(diǎn)協(xié)議： TCP, UDP.
TCP是可靠傳輸協(xié)議, 面向連接, 基于流.
可靠來(lái)源: 超時(shí)重傳, 排序號(hào), 確認(rèn)應(yīng)答等可靠機(jī)制
使用TCP協(xié)議通信的雙方必須先建立TCP連接， 并在內(nèi)核中為該連接維持一些必要的數(shù)據(jù)結(jié)構(gòu)，比如連接的狀態(tài)、讀寫緩沖區(qū)，以及諸多定時(shí)器等.? ? (超時(shí)重傳, 確認(rèn)應(yīng)答這些機(jī)制的實(shí)現(xiàn)必然攜帶著一些內(nèi)核數(shù)據(jù)結(jié)構(gòu). )
當(dāng)通信結(jié)束時(shí)，雙方必須關(guān)閉連接以釋放這些內(nèi)核數(shù)據(jù)。 ( 連接關(guān)閉細(xì)節(jié),內(nèi)核數(shù)據(jù)結(jié)構(gòu)的釋放, 避免內(nèi)存泄漏 )
UDP協(xié)議（User Datagram Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）則與TCP協(xié)議完全相反，它為應(yīng)用層提供不可靠、無(wú)連接和基于數(shù)據(jù)報(bào)的服務(wù)
不可靠是因?yàn)槭裁?? ?因?yàn)槿绻麛?shù)據(jù)在中途丟失，或者目的端通過(guò)數(shù)據(jù)校驗(yàn)發(fā)現(xiàn)數(shù)據(jù)錯(cuò)誤而將其丟棄，則UDP協(xié)議只是簡(jiǎn)單地通知應(yīng)用程序發(fā)送失敗? ? ?（不會(huì)重傳, 不會(huì)確認(rèn)應(yīng)答. 所以不可靠）
所以UDP傳輸?shù)氖褂猛枰约禾幚頂?shù)據(jù)確認(rèn)、超時(shí)重傳等邏輯? （自定義UDP可靠傳輸協(xié)議.在應(yīng)用層書寫）
UDP是無(wú)連接的, 所以每一次傳輸數(shù)據(jù)都需要指定對(duì)端的地址?ip + port
基于數(shù)據(jù)報(bào)的服務(wù)，是相對(duì)基于流的服務(wù)而言的。每個(gè)UDP數(shù)據(jù)報(bào)都有一個(gè)長(zhǎng)度，接收端必須以該長(zhǎng)度為最小單位將其所有內(nèi)容一次性讀出，否則數(shù)據(jù)將被截?cái)? ? ?
（數(shù)據(jù)報(bào)傳輸，每次都按照一個(gè)包裹傳輸, 包裹為最小傳輸單位, 大于包裹數(shù)據(jù)截?cái)?/strong>）
1.1.4 應(yīng)用層
應(yīng)用層負(fù)責(zé)處理應(yīng)用程序的邏輯? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(用戶空間應(yīng)用程序)
數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層和傳輸層負(fù)責(zé)處理網(wǎng)絡(luò)通信細(xì)節(jié)? ? ? ?(內(nèi)核數(shù)據(jù)結(jié)構(gòu), 穩(wěn)定, 安全, 高效)
?為啥不把應(yīng)用層服務(wù)也全部放入到內(nèi)核態(tài)中? ? ? ? ? ? ? ? ? （邏輯眾多,會(huì)使內(nèi)核變得非常龐大）
少數(shù)服務(wù)器程序是在內(nèi)核中實(shí)現(xiàn)的?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?（省去拷貝的代價(jià), 提高效率，但是代碼邏輯復(fù)雜, 不便于移植，書寫應(yīng)用）
應(yīng)用層重點(diǎn)協(xié)議，應(yīng)用程序列舉
- ping是應(yīng)用程序，而不是協(xié)議，前面說(shuō)過(guò)它利用ICMP報(bào)文檢測(cè)網(wǎng)絡(luò)連接，是調(diào)試網(wǎng)絡(luò)環(huán)境的必備工具
- DNS（Domain Name Service，域名服務(wù)）協(xié)議提供機(jī)器域名到IP 地址的轉(zhuǎn)換，我們將在后面簡(jiǎn)要介紹DNS協(xié)議
應(yīng)用層協(xié)議（或程序）可能跳過(guò)傳輸層直接使用網(wǎng)絡(luò)層提供的服務(wù)，比如ping程序
應(yīng)用層協(xié)議（或程序）通常既可以使 用TCP服務(wù)，又可以使用UDP服務(wù)，比如DNS協(xié)議。
我們可以通 過(guò)/etc/services文件查看所有知名的應(yīng)用層協(xié)議，以及它們都能使用哪些傳輸層服務(wù)
1.2 封裝
前文一直都在說(shuō)上層協(xié)議使用下層協(xié)議提供的服務(wù), 但是究竟是如何使用上的呢?? 封裝
應(yīng)用程序數(shù)據(jù)在發(fā)送到物理網(wǎng)絡(luò)上之前， 將沿著內(nèi)核協(xié)議棧從上往下依次傳遞? （封裝, 封包）
每層協(xié)議都將在上層數(shù)據(jù)的基礎(chǔ)上加上自己的頭部信息（有時(shí)還包括尾部信息），以實(shí)現(xiàn)該層的功能， 這個(gè)過(guò)程就稱為封裝
?每一層都可以進(jìn)行DDOS攻擊.? 洪水猛獸.? 網(wǎng)絡(luò)層（可以不斷發(fā)送連接請(qǐng)求, 或者不斷發(fā)送fin包.）
DDOS很有意思, 而且暫時(shí)沒(méi)有完全的解決方案, 大致做法就是， 不斷地發(fā)送無(wú)效請(qǐng)求, 占據(jù)服務(wù)器, 讓真正需要使用服務(wù)器地人無(wú)法建立連接, 或者無(wú)法使用.? ? ?
解決方法：前面放一臺(tái)大型地壁壘機(jī)器, 過(guò)濾無(wú)效請(qǐng)求.? ? ? ? (扯多了, 插曲)
經(jīng)過(guò)TCP封裝后的數(shù)據(jù)稱為TCP報(bào)文段（TCP message segment）， 或者簡(jiǎn)稱TCP段。
TCP協(xié)議為通信雙方維持一個(gè)連接，并且在內(nèi)核中存儲(chǔ)相關(guān)數(shù)據(jù)? ? ? ? ? （內(nèi)核數(shù)據(jù)結(jié)構(gòu)：屬于內(nèi)核協(xié)議棧）
深入內(nèi)核協(xié)議棧數(shù)據(jù)結(jié)構(gòu)去看這個(gè)封裝過(guò)程.? ?
發(fā)送地時(shí)候是 tcp header + tcp 內(nèi)核sendbuffer? ?接收地時(shí)候是? ?tcp header + tcp 內(nèi)核recvbuffer
send + write數(shù)據(jù), 是先寫到內(nèi)核協(xié)議棧的傳輸層的tcp sendbuffer中, 然后經(jīng)有內(nèi)核協(xié)議棧層層向下封裝, 經(jīng)由網(wǎng)卡接口驅(qū)動(dòng)程序?qū)⑵浞诺轿锢砭W(wǎng)絡(luò)傳輸層 (網(wǎng)線, 電氣傳輸)
經(jīng)過(guò)UDP封裝后的數(shù)據(jù)稱為UDP數(shù)據(jù)報(bào)（UDP datagram）。UDP 對(duì)應(yīng)用程序數(shù)據(jù)的封裝與TCP類似。不同的是，UDP無(wú)須為應(yīng)用層數(shù)據(jù)保存副本，因?yàn)樗峁┑姆?wù)是不可靠的.? ? ?（不保存副本在內(nèi)核態(tài)意味著不可靠, 不考慮重傳的問(wèn)題）
當(dāng)一個(gè)UDP數(shù)據(jù)報(bào)被成功發(fā)送之后，UDP內(nèi)核緩沖區(qū)中的該數(shù)據(jù)報(bào)就被丟棄了。如果應(yīng)用程序檢測(cè)到該數(shù)據(jù)報(bào)未能被接收端正確接收，并打算重發(fā)這個(gè)數(shù)據(jù)報(bào)，則應(yīng)用程序需要重新從用戶空間將該數(shù)據(jù)報(bào)拷貝到UDP內(nèi)核發(fā)送緩沖區(qū)中。
經(jīng)過(guò)IP封裝后的數(shù)據(jù)稱為IP數(shù)據(jù)報(bào)（IP datagram）
經(jīng)過(guò)數(shù)據(jù)鏈路層封裝的數(shù)據(jù)稱為幀（frame）。傳輸媒介不同，幀 的類型也不同
幀才是最終在物理網(wǎng)絡(luò)上傳送的字節(jié)序列?
1.3 分用
當(dāng)幀到達(dá)目的主機(jī)時(shí)，將沿著協(xié)議棧自底向上依次傳遞。各層協(xié)議依次處理幀中本層負(fù)責(zé)的頭部數(shù)據(jù)，以獲取所需的信息，并最終將 處理后的幀交給目標(biāo)應(yīng)用程序。這個(gè)過(guò)程稱為分用
上層協(xié)議那么多, 所以分用的一個(gè)核心問(wèn)題在于如何知道分用后應(yīng)該交付給哪個(gè)上層協(xié)議.
掐去頭部之后的身子應(yīng)該交付給誰(shuí)??
每一層的頭部中都會(huì)存在這樣一個(gè)字段可以標(biāo)識(shí)上層協(xié)議進(jìn)行交付
eg : IP協(xié)議, ARP協(xié)議, RAPR協(xié)議都使用幀傳輸數(shù)據(jù)，所以幀的頭部需要提供某個(gè)字段（具體情況取決于幀的類型）來(lái)區(qū)分它們，幀給出的是幀頭部的類型字段進(jìn)行區(qū)分
eg : 以太網(wǎng)幀類型字段的值為0x800，則幀的數(shù)據(jù)部分為IP數(shù)據(jù)報(bào)
同樣，因?yàn)镮CMP協(xié)議、TCP協(xié)議和UDP協(xié)議都使用IP協(xié)議，所以 IP數(shù)據(jù)報(bào)的頭部采用16位的協(xié)議（protocol）字段來(lái)區(qū)分它們。
TCP報(bào)文段和UDP數(shù)據(jù)報(bào)則通過(guò)其頭部中的16位的端口號(hào)（port number）字段來(lái)區(qū)分上層應(yīng)用程序。所有知名應(yīng)用層協(xié)議使用的端口號(hào)都可在 /etc/services 文件中找到。
幀通過(guò)上述分用步驟后，最終將封裝前的原始數(shù)據(jù)送至目標(biāo)服務(wù)
1.5 ARP協(xié)議工作原理
主機(jī)向自己所在的網(wǎng)絡(luò)廣播一個(gè)ARP請(qǐng)求，該請(qǐng)求包含目標(biāo)機(jī)器 的網(wǎng)絡(luò)地址。此網(wǎng)絡(luò)上的其他機(jī)器都將收到這個(gè)請(qǐng)求，但只有被請(qǐng)求 的目標(biāo)機(jī)器會(huì)回應(yīng)一個(gè)ARP應(yīng)答，其中包含自己的物理地址
核心原理: 廣播, 目標(biāo)MAC ff:ff:ff:ff:ff:ff? ? ? ?同網(wǎng)段的所有主機(jī)廣播, 對(duì)比發(fā)現(xiàn)ip等于目標(biāo)ip的機(jī)器，填寫自己的MAC物理地址并且發(fā)送ack應(yīng)答包
1.5.1 以太網(wǎng)ARP請(qǐng)求/應(yīng)答報(bào)文詳解
硬件地址長(zhǎng)度字段和協(xié)議地址長(zhǎng)度字段，顧名思義，其單位是字節(jié)。對(duì)MAC地址來(lái)說(shuō)，其長(zhǎng)度為6；對(duì)IP（v4）地址來(lái)說(shuō)，其長(zhǎng)度為 4。
操作字段指出4種操作類型：ARP請(qǐng)求（值為1）、ARP應(yīng)答（值 為2）、RARP請(qǐng)求（值為3）和RARP應(yīng)答（值為4）。
最后4個(gè)字段指定通信雙方的以太網(wǎng)地址和IP地址。發(fā)送端填充除目的端以太網(wǎng)地址外的其他3個(gè)字段，以構(gòu)建ARP請(qǐng)求并發(fā)送之。接 收端發(fā)現(xiàn)該請(qǐng)求的目的端IP地址是自己，就把自己的以太網(wǎng)地址填進(jìn) 去，然后交換兩個(gè)目的端地址和兩個(gè)發(fā)送端地址，以構(gòu)建ARP應(yīng)答并返回之（當(dāng)然，如前所述，操作字段需要設(shè)置為2）。
1.5.2 ARP高速緩存的查看和修改
通常，ARP維護(hù)一個(gè)高速緩存，其中包含經(jīng)常訪問(wèn)（比如網(wǎng)關(guān)地址）或最近訪問(wèn)的機(jī)器的IP地址到物理地址的映射。這樣就避免了重復(fù)的ARP請(qǐng)求，提高了發(fā)送數(shù)據(jù)包的速度。
Linux下可以使用arp命令來(lái)查看和修改ARP高速緩存。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-467994.html
- arp? -a 是查看ARP 緩存內(nèi)容? ?
- arp? -d? ip? ?是刪除ARP緩存內(nèi)容
- arp? -s? ip? MAC? 是添加? ARP緩存內(nèi)容
1.5.3 使用tcpdump觀察ARP通信過(guò)程所得結(jié)果如下
?注意點(diǎn):文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-467994.html
- ARP請(qǐng)求和應(yīng)答是從以太網(wǎng)驅(qū)動(dòng)程序發(fā)出的，而并非像圖 中描述的那樣從ARP模塊直接發(fā)送到以太網(wǎng)上，所以我們將它們用虛 線表示，這主要是為了體現(xiàn)攜帶ARP數(shù)據(jù)的以太網(wǎng)幀和其他以太網(wǎng)幀 （比如攜帶IP數(shù)據(jù)報(bào)的以太網(wǎng)幀）的區(qū)別。
- 路由器也將接收到以太網(wǎng)幀1，因?yàn)樵搸且粋€(gè)廣播幀。不 過(guò)很顯然，路由器并沒(méi)有回應(yīng)其中的ARP請(qǐng)求，正如前文討論的那樣
到了這里，關(guān)于強(qiáng)推Linux高性能服務(wù)器編程, 真的是后端開發(fā)技術(shù)提升, 沉淀自身不容錯(cuò)過(guò)的一本經(jīng)典書籍的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
