IP協議詳解

協議森林我盡力 (ip協議詳解)

在粗略了解了ip接力和ip位址後，我們再反過來，看一看ip協議的具體細節和設計哲學。

ipv4與ipv6頭部的對比

我們已經在ip接力中介紹過，乙個ip包分為頭部(header)和資料(payload/data)兩部分。頭部是為了實現ip通訊必須的附加資訊，資料是ip通訊所要傳送的資訊。

黃色區域 (同名區域)

我們看到，三個黃色區域跨越了ipv4和ipv6。version(4位)用來表明ip協議版本，是ipv4還是ipv6(ipv4, version=0100; ipv6, version=0110)。source adrresss和destination address分別為發出地和目的地的ip位址。

藍色區域（名字發生變動的區域）

type of service 服務型別(traffic class in ipv6)。type of service最初是用來給ip包分優先順序，比如語音通話需要實時性，所以它的ip包應該比web服務的ip包有更高的優先順序。然而，這個最初不錯的想法沒有被微軟採納。在windows下生成的ip包都是相同的最高優先順序，所以在當時造成linux和windows混合網路中，linux的ip傳輸會慢於windows (僅僅是因為linux更加守規矩！)。後來，type of service被實際分為兩部分：differentiated service field (ds, 前6位)和explicit congestion notification (ecn, 後2位)，前者依然用來區分服務型別，而後者用於表明ip包途徑路由的交通狀況。ipv6的traffic class也被如此分成兩部分。通過ip包提供不同服務的想法，並針對服務進行不同的優化的想法已經產生很久了，但具體做法並沒有形成公認的協議。比如ecn區域，它用來表示ip包經過路徑的交通狀況。如果接收者收到的ecn區域顯示路徑上的很擁擠，那麼接收者應該作出調整。但在實際上，許多接收者都會忽視ecn所包含的資訊。交通狀況的控制往往由更高層的比如tcp協議實現。

protocol 協議(next header in ipv6)。protocol用來說明ip包payload部分所遵循的協議，也就是ip包之上的協議是什麼。它說明了ip包封裝的是乙個怎樣的高層協議包(tcp? udp?)。

total length, 以及ipv6中payload length的討論要和ihl區域放在一起，我們即將討論。

紅色區域 (ipv6中刪除的區域)

我們看一下ipv4和ipv6的長度資訊。ipv4頭部的長度。在頭部的最後，是options。每個options有32位，是選填性質的區域。乙個ipv4頭部可以完全沒有options區域。不考慮options的話，整個ipv4頭部有20 bytes(上面每行為4 bytes)。但由於有options的存在，整個頭部的總長度是變動的。我們用ihl(internet header length)來記錄頭部的總長度，用total length記錄整個ip包的長度。ipv6沒有options，它的頭部是固定的長度40 bytes，所以ipv6中並不需要ihl區域。payload length用來表示ipv6的資料部分的長度。整個ip包為40 bytes + payload length。

ipv4中還有乙個header checksum區域。這個checksum用於校驗ip包的頭部資訊。checksum與之前在小喇叭中提到的crc演算法並不相同。ipv6則沒有checksum區域。ipv6包的校驗依賴高層的協議來完成，這樣的好處是免去了執行checksum校驗所需要的時間，減小了網路延遲 (latency)。

identification, flags和fragment offset，這三個包都是為碎片化(fragmentation)服務的。碎片化是指乙個路由器將接收到的ip包分拆成多個ip包傳送，而接收這些「碎片」的路由器或者主機需要將「碎片」重新組合(reassembly)成乙個ip包。不同的區域網所支援的最大傳輸單元(mtu, maximum transportation unit)不同。如果乙個ip包的大小超過了區域網支援的mtu，就需要在進入該區域網時碎片化傳輸(就好像方面面麵餅太大了，必須掰碎才能放進碗裡)。碎片化會給路由器和網路帶來很大的負擔。最好在ip包發出之前探測整個路徑上的最小mtu，ip包的大小不超過該最小mtu，就可以避免碎片化。ipv6在設計上避免碎片化。每乙個ipv6區域網的mtu都必須大於等於1280 bytes。ipv6的預設傳送ip包大小為1280 bytes。

令人痛苦的碎片化

綠色區域 (ipv6新增區域)

flow label是ipv6中新增的區域。它被用來提醒路由器來重複使用之前的接力路徑。這樣ip包可以自動保持出發時的順序。這對於流**之類的應用有幫助。flow label的進一步使用還在開發中。

「我盡力」

ip協議在產生時是乙個鬆散的網路，這個網路由各個大學的區域網相互連線成的，由一群碰頭垢面的geek維護。所以，ip協議認為自己所處的環境是不可靠(unreliable)的：諸如路由器壞掉、實驗室失火、某個phd踢掉電纜之類的事情隨時會發生。

不靠譜的網路

這樣的凶險環境下，ip協議提供的傳送只能是「我盡力」 (best effort)式的。所謂的「我盡力」，其潛台詞是，如果事情出錯不要怪我，我只是答應了盡力，可沒保證什麼。所以，如果ip包傳輸過程中出現錯誤(比如checksum對不上，比如交通太繁忙，比如超過time to live)，根據ip協議，你的ip包會直接被丟掉。game over, 不會再有進一步的努力來修正錯誤。best effort讓ip協議保持很簡單的形態。更多的質量控制交給高層協議處理，ip協議只負責有效率的傳輸。

(多麼不負責任的郵遞系統)

「效率優先」也體現在ip包的順序(order)上。即使出發地和目的地保持不變，ip協議也不保證ip包到達的先後順序。我們已經知道，ip接力是根據routing table決定接力路線的。如果在連續的ip包傳送過程中，routing table更新(比如有一條新建的捷徑出現)，那麼後發出的ip包選擇走不一樣的接力路線。如果新的路徑傳輸速度更快，那麼後發出的ip包有可能先到。這就好像是多車道的公路上，每輛車都在不停變換車道，最終所有的車道都塞滿汽車。這樣可以讓公路利用率達到最大。

「插隊」

ipv6中的flow label可以建議路由器將一些ip包保持一樣的接力路徑。但這只是「建議」，路由器可能會忽略該建議。

header checksum演算法

header checksum區域有16位。它是這樣獲得的，從header取得除checksum之外的0/1序列，比如：

9194 8073 0000 4000 4011 c0a8 0001 c0a8 00c7 (十六進製制hex, 這是乙個為演示運算過程而設計的header)

按照十六位(也就是4位hex)分割整個序列。將分割後的各個4位hex累積相加。如果有超過16位的進製出現，則將進製加到後16位結果的最後一位：

binary hex

1001000110010100 9194

1 0001001000000111 11207

0001001000001000 1208

上面的計算叫做one』s complement sum。求得所有十六位數的和，

one』s complement sum(4500, 0073, 0000, 4000, 4011, c0a8, 0001, c0a8, 00c7) = 1433

然後，將1433的每一位取反(0->1, 1->0)，就得到checksum：ebcc

這樣，我們的header就是:

9194 8073 0000 4000 4011 ebcc c0a8 0001 c0a8 00c7

ip包的接收方在接收到ip包之後，可以求上面各個16位數的one』s complement sum，應該得到ffff。如果不是ffff，那麼header是不正確的，整個ip包會被丟棄。

(再次提醒，示例所用的ip header不是真實的header，它只是起演示演算法的作用)

總結每個網路協議的形成都有其歷史原因。比如ip協議是為了將各個分散的實驗室網路連線起來。由於當時的網路很小，所以ipv4(ipv4產生與70年代)的位址總量為40億。儘管當時被認為是很大的數字，但數字浪潮很快帶來了位址耗盡危機。ipv6的主要目的是增加ipv4的位址容量，但同時根據ipv4的經驗和新時代的技術進步進行改進，比如避免碎片化，比如取消checksum (由於高層協議tcp的廣泛使用)。網路協議技術上並不複雜，更多的考量是政策性的。

ip協議是」best effort」式的，ip傳輸是不可靠的。但這樣的設計成就了ip協議的效率。

IP協議詳解

IP協議詳解

IP協議詳解

IP協議詳解

相關推薦