首頁  >  文章  >  ip屬於電腦網路體系結構的什麼協議

ip屬於電腦網路體系結構的什麼協議

青灯夜游
青灯夜游原創
2022-08-29 16:12:185428瀏覽

ip屬於電腦網路體系結構的「網路層」協定。 IP指網路互連協議,是TCP/IP體系中的網路層協議,它可以向傳輸層提供各種協議的訊息,例如TCP、UDP等;對下可將IP資訊包放到鏈路層,透過乙太網路、令牌環網路等各種技術來傳送。

ip屬於電腦網路體系結構的什麼協議

本教學操作環境:windows7系統、Dell G3電腦。

ip屬於電腦網路體系結構的「網路層」協定。

IP協定簡述

IP指網路互連協議,Internet Protocol的縮寫,IP是整個TCP/IP協議族的核心,也是構成網路的基礎。 IP位於TCP/IP模型的網路層(相當於OSI模型的網路層),它可以提供傳輸層各種協定的訊息,例如TCP、UDP等;對下可將IP資訊包放到連結層,透過乙太網路、令牌環網路等各種技術來傳送。

ip屬於電腦網路體系結構的什麼協議

設計IP的目的是提高網路的可擴展性:一是解決網路問題,實現大規模、異質網路的互聯互通;二是分割頂層網路應用和底層網路技術之間的耦合關係,以利於兩者的獨立發展。根據端到端的設計原則,IP只為主機提供一種無連線、不可靠的、盡力而為的資料包傳輸服務。

雖然IPV4終將會被IPV6取代,但目前IPV4仍然是IP協定的主流版本,所以我們將重點放在IPV4版本。在學習TCP協定和socket套接字程式設計的時候我們知道,如果想要在網際網路這個共享網路中精確定位到一台主機,那麼就一定需要該主機的IP位址。主機是擁有IP位址,但不能進行路由控制(Routing,意思是中轉、分組封包),路由器(Router)這種設備既有IP位址,又可以進行路由控制;我們可以將接取網路中的主機和路由器都叫做節點。

舉個例子,我們一般人只有自己的地址,如果想要寄快遞給朋友或從別人那裡接受快遞,只能向郵差提供對方的地址或我們自己的地址,也就是我們只有地址標識,但是我們不能發送快遞;而快遞員就像是路由器,他自己也有自己的地址,也可以收到他的私人快遞,但是他還可以將用戶的快遞,根據目的地不同,選擇不同的快遞線路進行運輸。下圖可以清楚表達IP協定在網路環境中的作用。

IP協定首部格式(IPV4)

#和之前學習TCP、UDP協定一樣,先來介紹IP協定的首部格式

#我們可以發現IP協定首部與TCP協定首部非常相似,如果沒有特殊情況,都是20個字節,因此我們也常常會把兩者放在一起稱為TCP /IP協定。以下將IP協定首部每個欄位都詳細介紹一下:

  • 4位元版本號碼(Version):用來指定IP協定的版本,IPV4的版本號碼就是4,如果這個IP封包是IPV4版本,那麼這個欄位的值就是4,用4位元來標識就是0100。 IPV6的版本號則是6。
  • 4位元首長度(Internet Header Length):表示IP首部的大小,單位是4個位元組,length * 4的位元組數,因為這一字段共4個位元,所以這一字段最大值為2 ^ 4 - 1即15,所以IP首部最大長度為15 * 4即60位元組;在預設情況下,該字段被設定為5,所以預設IP首部20字節。
  • 8位元服務類型(Type Of Service):前三位表示優先權(已經棄用),第4位表示最低延遲、第5位表示最大吞吐、第6位表示最大可靠性、第7位表示最小代價,這四位互相衝突,只能選一個。需要根據不同情況進行選擇,如果是SSH/TELNET這類遠端登錄,那麼就應該選擇最小延時,如果是FTP類型的程序,則應該選擇最大吞吐量;第8位是保留位,目前沒有使用,必須填0。
  • 16位元總長度(Total Length):表示IP首部和後面攜帶的資料部分總共有多少個位元組。此欄位有16個位元位,因此IP資料封包整體最大長度為65535個位元組。
  • 16位元識別(ID):唯一地識別主機發送的封包,如果一份IP封包在資料鏈結層被分片,那麼每一片的該欄位應該都是相同值。幫助對端主機在接收後進行分片重組。
  • 3位元標誌(Flag):第一位保留(保留的意思是現在不使用,未來如果需要的話再使用),必須填0;第二位用來指明是否可以分片,如果為0則可以分片,如果為1則不能分片,假如一個IP報文禁止分片且長度還大於了MTU(Maximum Transmission Unit最大傳輸單元,後面詳細介紹),則該本文只能被丟棄;若報文被分片,第三位為1表示它是分片中段的報文,即後續還有分片報文,如果第三位為0則表示這是最後一片。
  • 13位元片偏移(Fragment Offset):該欄位表示分片相對於原始IP封包開始處的偏移量,其實就是表示目前分片在原報文中所處的位置,第一個分片對應值為0。由於此欄位總共13個位元位,因此最多可以表示2 ^ 13即8192個相對位置。 單位為8位元組,所以最大可以表示8192 * 8 = 65536個位元組的位置。
  • 8位元生存時間(Time To Live):資料封包到達目的地的最大封包跳數(Hop,指網路中一個區間,IP封包正是在網路中一個跳間被轉送) ,一般為64,每次經過一條路由,TTL–,如果TTL == 0時還沒到達目的地,那麼這個報文就會被丟棄。這個欄位主要是為了防止路由循環,封包在一個循環中一直轉發,浪費網路資源。
  • 8位元協定(Protocol):表示IP的上層是什麼協議,我們熟知的TCP、UDP、ICMP等都是在IP上層的。
  • 16位元首部校驗和(Header Checksum):使用CRC進行校驗,鑑別IP首部是否收到損壞,如果損壞直接丟棄,它只校驗IP頭部,不校驗下面的內容,因為內容部分的校驗是上層傳輸層(TCP)需要考慮的,IP協定只要發現首部有問題就直接丟棄該封包。
  • 32位元來源IP位址(Source Address):表示發送端的IP。
  • 32位元目的IP位址(Destination Address):表示接收端的IP。
  • 選項欄位(Options):不定長,最大可以到40個位元組。
補充:分片與組裝

MTU(Maximum Transmission Unit最大傳輸單元)是在IP層下面的MAC協定中的概念,MAC協定我們可以理解為是物理層的一些協議,它位於IP協議的下層,那麼在發送數據時相當於是用戶數據應用層協議報頭(如HTTP請求報頭)作為有效載荷交給傳輸層(如TCP協議), TCP協定再將TCP標頭應用層傳來的資料下交給IP層,IP層再將IP協定首部TCP層傳來的TCP封包交付給MAC訊框。因此每個MAC訊框其實是IP協定首部 IP層的有效載重。而MAC幀是有長度限制的,所以就要求IP資料報向下交付時並不是隨心所欲想發多長就發多長,如果MAC幀要求MTU為1500字節,而IP資料包總長度有2000字節,那就需要分片,將原有的IP資料包分成兩片,依序發送,對端的主機在接收後,由對端的IP層再完成組裝。我們在Linux環境下可以使用ifconfig指令查看到MTU。

ip屬於電腦網路體系結構的什麼協議

分片和組裝對於上層TCP/UDP和下層的MAC都是透明的,即上層和下層都不知道IP層將資料包進行了分片操作,因此分片和組裝操作會由發送方IP層和接收方IP層自動完成。但是分片意味著需要把一份資料變成多組資料傳輸,並且在對端還需要進行組裝,這樣會大大降低網路傳輸效率以及提升錯誤風險,因此在傳輸過程中應盡量避免分片,即盡量不要發送超過MTU長度的IP資料報。

IP位址

IP位址的定義:

IPV4中我們由32位元正整數來表示IP位址,電腦內部會直接以二進位來保存IP位址,不過人並不善於記憶二進制整數,所以我們採用點分十進制來記錄IP位址:即將32位IP位址每8位一組,分成4組,組間用' . '進行分隔,再將每組轉換為十進制。

因此我們可以直接算出,在IPV4標準下最多有2 ^ 32 = 4292967296個IP位址,但是能被人們使用的遠遠不足這個數字。 (例如某些IP位址是有特殊作用被預留的,某些裝置如路由器會佔有多個IP位址)

#IP位址的組成:

IP位址由網路標識(網路位址)和主機標識(主機位址)兩部分組成

我們查找到一個IP地址的過程就像是去某個地方旅遊一樣,例如我們想要去天安門玩,不可能直接坐高鐵到達天安門,我們一定是先抵達北京市(目的網絡),再經由北京市內的交通抵達天安門(目的主機)。因此我們在路由選擇時,應該先找到目標主機所在的區域網,然後再在該區域網路中找到目標主機。這種方式可以快速幫我們定位到目標區域網,在區域網路內搜尋目標主機就比在茫茫的網路中找一台主機要快速多了。

網路號碼:保證互相連接的兩個網段有不同的識別。

主機號碼:保證在同一個網段中,兩台主機有不同的識別。

IP位址的劃分:

IP位址分為五個級別,分別為A類、B類、C類、D類和E類(一直沒有使用過),所以目前我們所能見到的IP位址只有A、B、C、D四類。劃分的依據就是IP位址從第1位到第4位的位元。

  • A類別位址:0.0.0.0 ~ 127.255.255.255
  • B類別位址:128.0.0.0 ~ 191.255.255.255
  • C類別位址:192.0.0.0 ~ 223.255.255.255
  • D類別位址:224.0.0.0 ~ 239.255.255.255
  • E25.240.20.025.

在不考慮E類IP位址的時候,我們可以發現,A、B、C、D類別位址的網路號碼所佔位元位逐漸增加,而主機號碼所佔的位元位在逐漸減少。這意味著在上述四類位址中,一類位址中的子網路數量越來越多,但是子網路中可以連接的主機變得越來越少。以國內一所普通高校為例,全校師生大約3萬人,如果每個人都有一台筆記型電腦需要連接到校園區域網路中,有些同學還會有一些平板電腦等其他需要連接網路的終端設備,那麼在申請網路時就應該以5~6萬個IP位址去申請,如果使用A類位址,那麼主機號碼24位元會產生2 ^ 24 = 16777216個IP位址,遠遠超過實際所需要的,如果使用C類別位址,則只有2 ^ 8 = 256個IP位址,遠少於所需IP位址,所以最適合的是B類位址,有2 ^ 16 = 65536個IP位址。這個例子也告訴我們,IP位址不能太多,會造成大量浪費;也不能太少,否則很多設備會無法連接網路。

引入子網路遮罩:

隨著Internet的發展,使用前四位是否為1來分類的方案弊端開始顯現:那就是很多子網路的申請者都會去申請B類網路位址,因為A類根本用不完,而C類不夠用。導致B類的網路位址很快就被分配完了。而申請了A類的網路又會浪費大量的IP位址,在這種情況下,人們提出了新的分割方案:CIDR(Classless Interdomain Routing無類型域間選路)

  • 引入子網路遮罩來區分網路號碼和主機號碼
  • 子網路遮罩也是32位元的正整數,但結尾通常是一串0
  • 將IP位址與子網路遮罩進行&操作,所得結果就是網路號碼
  • 網路號碼與主機號碼的分割就與這個IP位址是A類、B類別或C類別無關了

舉兩個例子幫助理解透過子網路遮罩來分割網路號碼和主機號碼

範例:
IP位址 二進位表達
#140.252.20.68 1000 1100 1111 1100 0001 0100 0100# 01000
#子網路遮罩二進位表達
######## #255.255.255.0######1111 1111 1111 1111 1111 1111 0000 0000#############

將IP位址與子網路遮罩進行位元與操作後得到1000 1100 1111 1100 0001 0100 0000 0000,再轉換為方便人們使用的點分十進位為140.252.20.0 ,這就是該子網路的網路號碼了。而它的子網路遮罩末尾的8個位元位元為0,這個子網路可以表示2 ^ 8 = 256台主機,因此這個子網路的位址範圍是140.252.20.0 ~ 140.252.20.255

#範例二:
IP位址 #二進位表達
#140. 252. 20. 68 #1000 1100 1111 1100 0001 0100 0100 0100

#子網路子網子網#碼

二進位表達

  • 255.255.255.240
  • ##255.255.255.240

1111 1111 1111 1111 1111 1111 1111

    #將IP位址與子網路遮罩進行位元與操作後得到
  • 1000 1100 1111 1100 0001 0110 0100 0000
  • ,即該子網路的網路編號,同樣轉換成常用的點分十進位為
  • 140.252.20.64
  • ,它的子網路遮罩結束時的4個位元為0,這個子網路可以表示2 ^ 4 = 16台主機,因此這個子網路的位址範圍就是
  • 140.252.20.64 ~ 140.252.20.79

一些特殊的IP位址

將IP位址中的主機位址全設為0,即該區域網路位址

###將IP位址中的主機位址全設為0,即該區域網路位址的網路號,這個IP位址代表這個區域網路。 ######將IP位址中的主機位址全設定為1,可以變成廣播位址,這個廣播位址可以給同一個連結中互相連接的所有主機發送封包######127. *的IP位址用於本地環回測試,通常是127.0.0.1#########私有IP位址和公網IP位址######假如某個大學要在校園內部組成一個區域網路,只實現校園內部的網路通訊而不與外界任何一台機器進行通信,那麼理論上2 ^ 32個IP位址都可以使用,因為只在這個區域網路中,不會出現相同的IP位址。不過RFC1918規定了組成區域網路的私有IP位址的規格:#########10.* 前8位是網路號,共有16,777,216個位址######172.16.*~172.31.* 前12位是網路號,共有1,048,576個位址######192.168.* 前16位是網路號,共有65,536個位址#########上述範圍內的IP位址都是私有IP,不在上述範圍內的IP則為全域IP位址(公網IP位址)。 ######更多相關知識,請造訪###常見問題###欄位! ###

以上是ip屬於電腦網路體系結構的什麼協議的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn