成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

瀏覽器輸入一個網址發生了什么(三): IP模塊封裝、ARP協議、IP協議、ICMP協議和網卡原理

網絡
本節將會補充協議棧中的IP模塊對報文的封裝,以及網絡包是如何通過網卡發送出去計算機。

上一節我們探索了網絡消息在協議棧的TCP模塊內是如何封裝、發送和接收:瀏覽器輸入一個網址發生了什么(二) TCP模塊封裝和傳輸機制

本節將會補充協議棧中的IP模塊對報文的封裝,以及網絡包是如何通過網卡發送出去計算機。

1. IP模塊封裝IP頭部

當數據報文從TCP模塊傳遞給IP模塊時,IP模塊需要封裝IP頭部。IP頭部中包含以下信息,其中接收方的IP由TCP模塊傳遞給IP模塊,而發送方的IP是什么需要取決于IP模塊通過電腦的哪一塊網卡發送(由上一節我們知道IP不是與主機綁定,而是與主機上的網卡綁定,如果主機上有多個網卡,則該主機可以有多個IP)。

為了得知包由主機上的哪塊網卡發送,IP模塊會根據目標IP為條件查詢本機的“路由表”,該路由表在windows系統中可以通過 route print命令顯示,如下:

首先IP模塊會拿目標ip和第1列字段進行比對,這里的比對不是全值匹配,而是只匹配其網絡號。而網絡號的位數由第2列字段決定。

例如,當目標IP是192.168.1.21時會匹配到倒數第3行,因為這一行要求比對的網絡號是前24位,而192.168.1.21和192.168.1.0的前24位相同,都是192.168.1。同理,如果目標IP是10.10.1.166則匹配到第3行。

如果目標IP與路由表中的所有條目都不匹配,則會匹配到第1行,第一行的網絡號全為0,即默認網關(網關本質也是一個轉發路由器),也意味著這個包將被發送到局域網中默認的一個路由器,由該路由器進行轉發。

第4列Interface代表網卡的網絡接口,也就是本機網卡的IP。第3列Gateway代表包要被發送到的下一個路由器的IP。

如果目標IP是192.168.1.21,則會匹配到倒數第3行,此時IP模塊會用第4列的10.10.1.16代表的網卡發送包到第3列的10.10.1.2這個路由器。

從上面的路由表來看,該主機只有10.10.1.16這1個IP,1塊網卡。

第5列表示從發送方IP到目標IP需要經歷多少跳,即包傳輸的距離。

回到正題,除了發送方IP和目標IP,IP頭部還需要填寫協議號,它表示包的內容是來自哪個模塊的。例如,如果是TCP模塊委托的內容,則設置為06(十六進制),如果是UDP模塊委托的內容,則設置為 17(十六進制),這些值都是按照規則來設置的。

在現在我們使用的瀏覽器中, HTTP請求消息都是通過TCP來傳輸的,因此這里就會填寫表示TCP的06(十六進制)。其他字段內也需要填寫相應的值,但對大局沒什么影響,這里先省略。

2. IP模塊封裝以太網用的MAC頭部

IP頭部中的IP地址可以由網絡層的IP模塊進行識別(當包到達接收方的IP模塊后,在IP模塊中會檢查包頭部的目標IP地址是否為接收方的IP地址,如果不是則丟棄包;除了IP地址外,IP模塊還會識別IP頭部中的其他信息如協議號等)。

但是在以太網(以太網是局域網中的一種)中,有很多設備只有數據鏈路層而沒有網絡層,沒有IP模塊,因此也無法識別IP頭部,例如集線器等。此時需要為包添加以太網能識別的MAC頭部,如下所示:

MAC頭部實際上也是IP模塊生成的,它包含了接收方和發送方的MAC地址,此時包從IP包變成以太網包。以太網包的內容不一定是IP包,也可以是ARP包等,可以從MAC頭部的以太網類型字段得知。

MAC地址也是網卡的硬件地址。IP和MAC都是網卡的地址,但IP地址是可以動態變化的,這取決于主機所處的網絡環境,而MAC地址是固定的,當網卡生產時就寫入到ROM中,在上一步中根據目標IP查詢路由表得知該由哪塊網卡發送包后,再從這塊網卡中讀取MAC地址并寫入MAC頭部即可。

下面是MAC地址的格式:

得知發送方的MAC地址容易,那如何得知接收方的MAC地址呢?這里需要使用ARP協議和廣播。

ARP協議(地址解析協議)是一個實現從IP地址到MAC地址的映射,即詢問目標IP其 對應的MAC地址的協議。ARP協議僅用于IPv4,IPv6則是使用NDP(鄰居發現協議)。

ARP協議與IP協議處于同一層,也是網絡層協議,因此ARP報文是在網絡層被封裝的網絡包。

ARP的工作機制:

  • 首先IP模塊會封裝ARP請求包,ARP請求包中包括發送方的IP地址和MAC地址,以及目標主機的IP地址(這段話中的目標主機的IP地址其實是下一跳路由器的IP地址而非最終互聯網另一端的目標IP)和MAC地址(由于不知道目標主機的MAC地址,因此會填寫為全0)。
  • 客戶端計算機通過交換機向局域網內同一鏈路的所有機器發送ARP請求(即廣播),該ARP請求包在數據鏈路層會被同一鏈路上所有的主機、路由器和交換機接收和解析。

  • 交換機接收到這個ARP請求包(應該說是包含該ARP包的幀)會將其廣播到同一鏈路的其他機器(因為交換機只負責數據的轉發,它沒有網絡層且它沒有被分配IP);
  • 之后這個包被路由器或主機接收到,則他們會檢測ARP包頭部的目標IP地址,如果不是自己的IP地址則會丟棄該包。如果是則會將他們自己的MAC地址寫入到ARP響應包返回給發送方主機。并且目標主機會將發送方主機的IP地址和MAC地址的映射關系緩存到ARP表中。

ARP表是每個主機內存儲著其他機器的IP和MAC地址的映射關系表。通過查詢ARP緩存就不用每次查詢MAC地址時都去進行ARP請求廣播,從而防止ARP大量廣播。但是ARP表中的每條緩存都有自己的有效期,過期則刪除,有效期在幾分鐘到十幾分鐘。可以通過 arp -a命令查看ARP表內容。

回到正題,將目標主機的MAC地址寫入到MAC頭部之后,MAC包就封裝好了,接下來IP模塊會將MAC包傳遞給網卡,網卡對MAC包進一步封裝為幀(無論是IP包還是ARP包,都會在網卡被封裝為幀之后才發送出去)。

需要注意的是,此時網絡包MAC頭部的接收方MAC地址是下一跳路由器的MAC地址而非互聯網另一端目標主機的MAC地址。當然如果這個包的目標主機本身就是局域網中的一臺機器,那么發送ARP請求時的ARP頭部的目標IP就可能是目標主機的IP而非路由器IP,那么請求的MAC地址就直接是這個目標主機的MAC地址。

3. 網絡包封裝成幀

在介紹數據包封裝成幀并發送之前先介紹一下網卡和數據在網卡傳輸的路徑。

網卡和網卡驅動程序

IP模塊生成的網絡包是存在內存中的一堆數字信息,需要被轉為電或光信號才能在網線傳輸,而網卡負責這一任務。網卡本身是硬件,無法完成這些任務,還需要網卡驅動程序對網卡進行操作和控制。

網卡在電腦開機時會進行初始化,初始化時網卡驅動程序會讀取ROM中的MAC地址并分配給網卡中的MAC模塊,此時網卡的MAC地址才生效。

下圖是網卡的結構以及網絡包是如何在網卡中處理和發送的:

其中,MAC模塊負責將IP包封裝為幀,并檢測接收到其他機器發送過來的幀是否正確(FCS校驗)以及接收到的包中的目標MAC地址是否是自己的MAC地址;PHY(MUA)負責將幀從數字信息轉為能在網線傳輸的電信號。

IP模塊將以太網包傳遞給網卡驅動,網卡驅動會將其復制到網卡內的緩沖區,再向MAC模塊發送發送包的命令。MAC模塊將包從緩沖區取出在開頭加上報頭和起始幀分界符,在末尾加上用于檢測錯誤的幀校驗序列,此時網絡包被封裝成幀。

報頭是一串像10101010…這樣1和0交替出現的比特序列,長度為56比特,它的作用是確定包的讀取時機。起始幀分界符是一個用來表示包起始位置的標記。末尾的FCS(幀校驗序列)用來檢查包傳輸過程中因噪聲導致的波形紊亂、數據錯誤。

4. 向集線器發送網絡包

包封裝成幀后,MAC模塊從報頭開始將數字信息按每個比特轉換成電信號,然后由PHY,或者叫MAU的信號收發模塊發送出去。在網線中實際的輸出信號如下

發送信號的操作分為兩種,一種是使用集線器的半雙工模式,另一種是使用交換機的全雙工模式。

在使用集線器的半雙工模式中,發送和接收不能同時進行,PHY(MAU)模塊會保證網線中沒有其他設備發送信號給自己才會將自己的信號發送出去(如果有則等待其他信號傳輸完)。如果網線中有其他信號在傳輸的情況下發送出去自己的信號,則兩組信號會發生碰撞。在全雙工模式中,發送和接收能夠同時進行。

電信號由PHY(MUA)信號收發模塊發送給自己連接的集線器,再由集線器轉發給連接到該集線器上的所有設備。數據在網絡中(局域網中)傳遞的過程如下:

信號經集線器發給所有設備后,這些設備都會接收到這個信號,然后由他們的PHY(MUA)模塊從電信號轉為通用格式給MAC模塊。

MAC模塊先將信號轉為數字信息(還原為數據幀),然后檢測數據幀是否受到噪聲干擾而紊亂,即把包開頭到結尾的比特套用公式計算出的內容與幀末尾的FCS比對,如果不一致則會被當做錯誤包丟棄。

如果FCS校驗沒問題,MAC模塊會檢測包MAC頭部的接收方MAC地址是否是自己的MAC地址,不是則直接丟棄,是則存到網卡緩沖區中。

之后網卡會發出中斷信號給CPU。換句話說,計算機不會一直監控網卡的活動而是在運行其他的任務,因此操作系統是無法得知包到達網卡這件事。

因此包到達后需要由網卡向擴展總線中的中斷信號線發送信號,該信號線通過中斷控制器連接到CPU,CPU接收到中斷信號后會掛起正在處理的任務,切換到操作系統的中斷處理程序,中斷處理程序會調用網卡驅動,網卡驅動從網卡緩沖區取出包交給TCP/IP協議棧。

協議棧中,IP模塊會校驗IP頭部格式是否正確,以及包的頭部接收方IP地址是否是自己的地址,如果不是自己的地址,IP模塊會通過ICMP消息將錯誤告知發送方,但不會將這個包轉發給真正的目標IP主機。

接下來需要再說一下 ICMP 互聯網控制協議。

該協議用于在主機和路由器之間發送控制消息,這里的控制消息是指“網絡不通”,“主機是否可到達”等消息,這些消息不傳輸用戶數據。ICMP位于網絡層,但是在IP之上,ICMP報文和TCP與UDP一樣會被添加IP頭部封裝為包。ICMP是無連接的協議。

ICMP的主要功能有兩個:

  • 確認IP包是否成功到達目標地址,當IP包從源發送方到目標主機之間的任何一個設備(如路由器)出錯(如包無法到達下一跳的設備),則中間的設備會生成ICMP數據包發送給源發送方。
  • 網絡診斷,ICMP可以檢測兩臺設備之間能否互連,即主機A能否到達主機B,以及主機A與主機B的連接速度,準確報告ICMP包到達目標地的時間。ping和traceroute命令就是通過發送ICMP包實現的功能。其中traceroute可以顯示兩臺機器之間可能的路徑并測量數據包在IP網絡上的時延,ping則是traceroute的簡化版,功能與traceroute類似。

IP包不可到達目標主機情況下發送ICMP包的流程:

圖中,主機A發送了一個IP數據包,其目標地址是主機B。IP包經過路由器1到達路由器2,假設路由器2和主機B在同一鏈路,為了根據主機B的IP獲取B的MAC地址,路由器2在局域網內廣播了ARP包。由于主機B關機導致該ARP包沒有被響應,多次重發ARP無果后,路由器2會生成一個類型為“目標不可到達類型”的ICMP包經過路由器1發送主機A。

“目標不可到達”是其中的一種ICMP消息類型。

主要的ICMP的消息類型如下:

通知類型(十進制數)

具體內容

0

回送應答(Echo Reply)

3

目標不可達(Destination Unreachable)

4

原點抑制(Source Quench)

5

重定向或改變路由(Redirect)

8

回送請求(Echo Request)

9

路由器公告(Router Advertisement)

10

路由器請求(Router Solicitation)

11

ICMP 超時(Time Exceeded)

17

地址子網請求(Address Mask Request)

18

地址子網應答(Address Mask Reply)

ICMP通知類型分為兩類:對于發送錯誤消息的ICMP報文叫差錯報文;對于為了采集信息和配置的ICMP報文叫信息類報文(如ping和traceroute命令所發的ICMP報文)。

ping命令檢測兩端主機能否互連情況下發送ICMP包的流程:

圖中主機A執行ping命令檢測能否與主機B通信,此時主機A會生成一個通知類型為“8 回送請求”的ICMP包給B。ICMP包經過多個路由器如果能夠到達主機B則B接收到“回送請求”的ICMP包后會返回一個“0 回送應答”的ICMP包給A,這個包會沿著原路經過路由器4~1到達主機A,主機A就知道能夠與B通信,以及包送達B花費的時間。

回到正題,當接收方主機發現數據包頭部的接收方IP地址不是自己的IP地址,則會由IP模塊生成一個類型為 “目標不可到達類型”的ICMP包給源發送方。

如果IP正確,則這個包會被接收。如果這個包是經過分片的,則IP模塊會將其暫存到內存中,等IP頭部具有相同ID號的包全部到達,會根據ID號以及IP頭部的“分片偏移量”將所有分片重組完整的IP包。(這里的分片不是指TCP模塊對應用程序數據[即http消息]的拆分,而是指路由器對某個以太網包內部IP包數據[即TCP頭部+http消息]的拆分,這部分知識會在之后介紹路由器時介紹)。

之后,這個完整IP包的數據會被遞交給TCP模塊,TCP模塊根據IP頭部的接收方IP地址和TCP頭部的接收方端口號查找對應的套接字,根據套接字記錄的通信狀態執行相應操作:如果包的數據是應用程序數據則返回確認接收的ACK包,并將數據存放到緩沖區等待應用程序來讀取;如果是建立或斷開連接的控制包,則返回響應控制包,并告知應用程序建立和斷開連接的操作狀態。

說到這里,我們可以說已經大概了解了發送方數據從本機的應用層到本機網絡層的傳輸和處理,以及接收方接收數據時數據從接收方機器的網絡層到應用層的傳輸與處理過程了。

下節預告:瀏覽器輸入一個網址發生了什么(四) 網絡包在局域網中的傳輸

責任編輯:趙寧寧 來源: 程序員阿沛
相關推薦

2014-06-11 13:25:14

IPARPRARP

2024-11-04 09:10:00

2020-12-03 08:37:38

TCPIPARP協議

2010-06-12 17:07:17

TCP IP協議

2019-10-31 08:43:43

ICMPARP協議ARP欺騙

2024-11-04 08:10:00

2010-07-08 15:08:12

2010-06-17 17:57:32

ARP協議

2010-07-02 09:28:18

IP交換機GSMP協議IFMP協議

2014-09-24 09:56:05

IP ARP RIP

2010-08-02 16:14:54

2010-06-21 13:43:46

2010-09-10 14:15:19

daytime協議時間協議

2011-05-13 10:11:34

IP協議ARP協議配置

2010-08-02 16:43:46

ICMP協議

2010-06-12 15:54:09

TCP IP協議

2010-06-18 14:37:20

TCP IP協議

2015-10-27 13:37:14

瀏覽器HTTP緩存

2011-08-24 09:56:13

網絡協議BOOTP協議TFTP協議

2010-07-30 15:04:02

協議配置
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 日韩免费毛片视频 | 日日夜夜精品视频 | 久久黄色网 | 久久综合亚洲 | 欧美一级欧美一级在线播放 | 欧美日本高清 | 日韩欧美在线不卡 | 色性av | 亚洲精品久久久久中文字幕欢迎你 | 亚洲欧美综合 | 亚洲xxxxx| 亚洲成人蜜桃 | 亚洲第一视频网站 | 91精品国产91久久久久久最新 | 国产激情视频网 | 国产专区在线 | 久久久国产一区二区三区 | 99re在线视频精品 | av在线一区二区三区 | 香蕉视频1024 | 亚洲成人观看 | 国产三级日本三级 | 一区二区高清在线观看 | 日韩欧美中文字幕在线观看 | 亚洲一区二区三区免费观看 | 日韩一区二区三区在线 | 特级黄一级播放 | 亚洲一区二区免费看 | 成年人的视频免费观看 | 国产精品成人一区二区三区 | 天天做日日做 | 国产免费一区二区三区 | 亚洲精品久久久久中文字幕欢迎你 | 在线观看深夜视频 | 一区二区中文 | 9久9久| 久久国产精品免费一区二区三区 | 99re在线免费视频 | 亚洲免费一区二区 | 国产精品九九九 | 久久久性 |