1. IP介紹
IP是TCP/IP協議族中最為核心的協議。大家,如TCP、UDP、ICMP及IGMP數據,都是在IP數據報格式基礎上再封裝一層再來傳輸的(見圖1 - 4)。
不可靠(unreliable)的意思是它不能保證 IP數據報能成功地到達目的地。 IP僅提供最好的傳輸服務。如果發生某種錯誤時,如某個路由器暫時用完了緩沖區, IP有一個簡單的錯誤處理算法:丟棄該數據報,然后發送 ICMP消息報給信源端。任何要求的可靠性必須由上層來提供(如TCP) 。
無連接(connectionless)這個術語的意思是I P并不維護任何關于后續數據報的狀態信息。每個數據報的處理是相互獨立的。這也說明, IP數據報可以不按發送順序接收。如果一信源向相同的信宿發送兩個連續的數據報(先是 A,然后是B) ,每個數據報都是獨立地進行路由選擇,可能選擇不同的路線,因此B可能在A到達之前先到達。
2. IP首部
I P數據報的格式如圖3 - 1所示。普通的IP首部長為20個字節,除非含有選項字段。
分析圖3 - 1中的首部。最高位在左邊,記為0 bit;最低位在右邊,記為31 bit。4個字節的32 bit值以下面的次序傳輸:首先是0~7 bit,其次8~15 bit,然后1 6~23 bit,最后是24~31 bit。這種傳輸次序稱作big endian字節序。由于TCP/IP首部中所有的二進制整數在網絡中傳輸時都要求以這種次序,因此它又稱作網絡字節序。
目前的協議版本號是4,因此IP有時也稱作IPv4。
服務類型(TOS)字段包括一個3 bit的優先權子字段(現在已被忽略) ,4 bit的TO S子字段和1 bit未用位但必須置0。4 bit的TO S分別代表:最小時延、最大吞吐量、最高可靠性和最小費用。
總長度字段是指整個I P數據報的長度,以字節為單位。
標識字段唯一地標識主機發送的每一份數據報。通常每發送一份報文它的值就會加 1。在大多數從伯克利派生出來的系統中,每發送一個I P數據報,I P層都要把一個內核變量的值加1,不管交給IP的數據來自哪一層。內核變量的初始值根據系統引導時的時間來設置。
TTL(time-to-live)生存時間字段設置了數據報可以經過的最多路由器數。TTL的初始值由源主機設置(通常為3 2或6 4) ,一旦經過一個處理它的路由器,它的值就減去1。當該字段的值為0時,數據報就被丟棄,并發送 ICMP報文通知源主機。
協議字段可以識別是哪個協議向I P傳送數據。
首部檢驗和字段是根據IP首部計算的檢驗和碼。它不對首部后面的數據進行計算。 ICMP、IGMP、UDP和TCP在它們各自的首部中均含有同時覆蓋首部和數據檢驗和碼。
目前,這些任選項定義如下:
? 安全和處理限制(用于軍事領域,詳細內容參見 RFC 1108[Kent 1991])
? 記錄路徑(讓每個路由器都記下它的IP地址,見7 . 3節)
? 時間戳(讓每個路由器都記下它的IP地址和時間,見7 . 4節)
? 寬松的源站選路(為數據報指定一系列必須經過的 IP地址,見8 . 5節)
? 嚴格的源站選路(與寬松的源站選路類似,但是要求只能經過指定的這些地址,不能經過其他的地址) 。
------------------------------------------以上內容整理于《TCP/IP協議詳解:卷1》--------------------------------------
------------------------------------------以下內容產生于代碼及分析--------------------------------------
3. IP宏定義實現
C++ Code
1 | // ******* IP ******* |
4. IP函數實現
以太網的header在IP的header之前,很簡單的,介紹先。
配置以太網的頭,為14字節:6字節目的mac地址+6字節源mac地址+2字節協議類型
1 | // make a return eth header from a received eth packet |
展開之后如下所示,其在以太網幀中的位置與之前的宏定義是一一對應的。
IP與ARP一樣,需要判定是不是發給本機的(eth_type_is_ip_and_my_ip函數),還有與填充make_eth 函數一樣需要填充函數(make_ip函數),此外還有填充其他雜七雜八和16位首部校驗和函數(fill_ip_hdr_checksum函數)
C++ Code
1 | //判定過程與eth_type_is_arp_and_my_ip類似 |
5. IP校驗和實現
校驗和函數式如何得出校驗和值的呢?看《TCP/IP協議詳解:卷1》里面咋說的吧。
”為了計算一份數據報的 IP檢驗和,首先把檢驗和字段置為 0。然后,對首部中每個 16 bit進行二進制反碼求和(整個首部看成是由一串 16 bit的字組成) ,結果存在檢驗和字段中。當收到一份I P數據報后,同樣對首部中每個16 bit進行二進制反碼的求和。由于接收方在計算過程中包含了發送方存在首部中的檢驗和,因此,如果首部在傳輸過程中沒有發生任何差錯,那么接收方計算的結果應該為全 1。如果結果不是全1(即檢驗和錯誤) ,那么I P就丟棄收到的數據報。但是不生成差錯報文,由上層去發現丟失的數據報并進行重傳。
ICMP、IGMP、UDP和TCP都采用相同的檢驗和算法,盡管TCP和UDP除了本身的首部和數據外,在IP首部中還包含不同的字段。在RFC 1071[Braden, Borman and Patridge 1988]中有關于如何計算Internet檢驗和的實現技術。由于路由器經常只修改 TTL段(減1) ,因此當路由器轉發一份報文時可以增加它的檢驗和,而不需要對 IP整個首部進行重新計算。 RFC1141[Mallory and Kullberg 1990]為此給出了一個很有效的方法。“
但是本協議棧的實現順序上與以上說的略有不同,《TCP/IP協議詳解:卷1》是先反碼再求和,本協議棧里面是先求和再反碼,當然都是按照16bit單位的單元來的。那結果一樣么?
比如:
11101010 01010100
10000000 11111110
先反碼再求和:
取反
00010101 10101011
01111111 00000001
求和
10010100 10101100
先求和再反碼:
求和
1 01101011 01010010
將進位加置最后來保持16位(下面的代碼如是說)
01101011 01010011
取反
10010100 10101100
沒錯,不完全驗證兩種方法的結果是一致的,不是科班出身,感覺上有啥子理論來說明某種順序的調換在對二進制運算結果方面的影響是無關的。
C++ Code
1 | unsigned int checksum(unsigned char * buf, unsigned int len,unsigned char type) |
------------------------------------------------------------------------------------------------------
6. ICMP簡介
注意:ICMP在TCP/IP分層上與IP屬于同一層,因此放在與IP一塊,但是ICMP是封裝在IP數據報里面的。
ICMP:Internet Control Messages Protocol, 網間控制報文協議
ICMP報文的格式如圖6 - 2所示。所有報文的前4個字節都是一樣的,但是剩下的其他字節則互不相同。下面我們將逐個介紹各種報文格式。類型字段可以有1 5個不同的值,以描述特定類型的 ICMP報文。某些ICMP報文還使用代碼字段的值來進一步描述不同的條件。
檢驗和字段覆蓋整個ICMP報文。使用的算法與I P首部檢驗和算法相同。ICMP的檢驗和是必需的。
7. ICMP宏定義及函數實現
雖然ICMP具有很多的子協議,但是其中最著名的要數ping程序,即ICMP回顯請求和應答報文。通過使用ping命令來判斷報文是否可以到達目標地址。ICMP的實現是一個逐步遵守規則的過程,即向固定的字節填充數據,其實本協議棧也就實現了這個ping。
“ping”這個名字源于聲納定位操作。 Ping程序由Mike Muuss編寫,目的是為了測試另一臺主機是否可達。該程序發送一份 ICMP回顯請求報文給主機,并等待返回 ICMP回顯應答。
當返回ICMP回顯應答時,要打印出序列號和TTL,并計算往返時間(TTL位于 IP首部中的生存時間字段)。
ICMP回顯應答需要做好兩步,第一步檢查IP首部中的協議類型是否為ICMP報文;第二,檢查ICMP首部中的ICMP類型是否為ICMP請求,如果是則生成ICMP回顯應答并通過以太網驅動芯片發送。為了便于調試,在接收到ICMP回顯請求時通過串口輸出發起方的IP地址,ping命令發起方的IP地址存在于IP首部中的源IP地址部分。
C++ Code
1 | // ******* ICMP ******* //ICMP_DEBUG插入此處 |
8 ICMP實驗調試
C++ Code
1 | void make_echo_reply_from_request(unsigned char * buf,unsigned int len) |
在程序的無線循環中,需要層層進行查詢。其實就是各種if語句來判定以太網幀的那些個標記為是不是所要找的類型。
1.查詢以太網中是否有數據,若無數據則返回。
2.保存源MAC地址,待返回時使用。
3.查詢是否為ARP報文并返回ARP報文
4.保存源IP地址,待返回時使用。
6.查詢是否為IP報文,若非IP報文返回。
5.查詢是否為ICMP報文并返回ICMP回顯應答。
這里可以修改fill_ip_hdr_checksum函數里面的ttl(time to live)值,來確定IP包的生存周期,就是經過幾個路由之后被丟棄掉。修改為以下的125。
如果按照注釋里面改正之后~~~
上一篇:分析TCP/IP協議棧代碼之ARP(STM32平臺)
下一篇:分析TCP/IP協議棧代碼之TCP(STM32平臺)
推薦閱讀
史海拾趣
設計資源 培訓 開發板 精華推薦
- 英飛凌發布“在中國、為中國”本土化戰略 三十而勵啟新篇
- 智慧農業:英特爾處理器驅動更加可持續、高效的農業發展
- 英偉達正在用“物理AI”,徹底顛覆自動駕駛、工業、機器人和智慧城市
- 臺積電-東京大學實驗室啟用,雙方聯手推動半導體研究和教育
- ?意法半導體大巴窯工廠落地創新冷卻系統,提升可持續發展能力
- Nordic Semiconductor聯同Omnispace和Gatehouse Satcom完成5G NB-IoT衛星演示
- 英偉達開啟“攻城略地”模式,擬在歐洲建設20座AI工廠
- 臺積電:日本JASM第二晶圓廠預計今年下半年動工
- 工信部:支持車企“60天賬期”承諾,促進產業健康發展
- 全球十大芯片代工廠最新排名!中芯國際沖擊世界第二