本文關(guān)鍵詞：ip協(xié)議，由筆耕文化傳播整理發(fā)布。

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

作者：Vamei 出處： 歡迎轉(zhuǎn)載，也請保留這段聲明。謝謝！

在粗略了解了IP接力和IP地址后，我們再反過來，看一看ip協(xié)議的具體細節(jié)和設(shè)計哲學。

我們已經(jīng)在IP接力中介紹過，一個IP包分為頭部(header)和數(shù)據(jù)(payload/data)兩部分。頭部是為了實現(xiàn)IP通信必須的附加信息，數(shù)據(jù)是IP通信所要傳送的信息。

我們看到，三個黃色區(qū)域跨越了IPv4和IPv6。Version(4位)用來表明ip協(xié)議版本，是IPv4還是IPv6(IPv4, Version=0100; IPv6, Version=0110)。Source Adrresss和Destination Address分別為發(fā)出地和目的地的IP地址。

Time to Live 存活時間(Hop Limit in IPv6)。Time to Live最初是表示一個IP包的最大存活時間：如果IP包在傳輸過程中超過Time to Live，那么IP包就作廢。后來，IPv4的這個區(qū)域記錄一個整數(shù)(比如30)，表示在IP包接力過程中最多經(jīng)過30個路由接力，如果超過30個路由接力，那么這個IP包就作廢。IP包每經(jīng)過一個路由器，路由器就給Time to Live減一。當一個路由器發(fā)現(xiàn)Time to Live為0時，就不再發(fā)送該IP包。IPv6中的Hop Limit區(qū)域記錄的也是最大路由接力數(shù)，與IPv4的功能相同。Time to Live/Hop Limit避免了IP包在互聯(lián)網(wǎng)中無限接力。

Type of Service 服務(wù)類型(Traffic Class in IPv6)。Type of Service最初是用來給IP包分優(yōu)先級，比如語音通話需要實時性，所以它的IP包應(yīng)該比Web服務(wù)的IP包有更高的優(yōu)先級。然而，這個最初不錯的想法沒有被微軟采納。在Windows下生成的IP包都是相同的最高優(yōu)先級，所以在當時造成Linux和Windows混合網(wǎng)絡(luò)中，Linux的IP傳輸會慢于Windows (僅僅是因為Linux更加守規(guī)矩！)。后來，Type of Service被實際分為兩部分：Differentiated Service Field (DS, 前6位)和Explicit Congestion Notification (ECN, 后2位)，前者依然用來區(qū)分服務(wù)類型，，而后者用于表明IP包途徑路由的交通狀況。IPv6的Traffic Class也被如此分成兩部分。通過IP包提供不同服務(wù)的想法，并針對服務(wù)進行不同的優(yōu)化的想法已經(jīng)產(chǎn)生很久了，但具體做法并沒有形成公認的協(xié)議。比如ECN區(qū)域，它用來表示IP包經(jīng)過路徑的交通狀況。如果接收者收到的ECN區(qū)域顯示路徑上的很擁擠，那么接收者應(yīng)該作出調(diào)整。但在實際上，許多接收者都會忽視ECN所包含的信息。交通狀況的控制往往由更高層的比如TCP協(xié)議實現(xiàn)。

Protocol 協(xié)議(Next Header in IPv6)。Protocol用來說明IP包Payload部分所遵循的協(xié)議，也就是IP包之上的協(xié)議是什么。它說明了IP包封裝的是一個怎樣的高層協(xié)議包(TCP? UDP?)。

Total Length, 以及IPv6中Payload Length的討論要和IHL區(qū)域放在一起，我們即將討論。

我們看一下IPv4和IPv6的長度信息。IPv4頭部的長度。在頭部的最后，是options。每個options有32位，是選填性質(zhì)的區(qū)域。一個IPv4頭部可以完全沒有options區(qū)域。不考慮options的話，整個IPv4頭部有20 bytes(上面每行為4 bytes)。但由于有options的存在，整個頭部的總長度是變動的。我們用IHL(Internet Header Length)來記錄頭部的總長度，用Total Length記錄整個IP包的長度。IPv6沒有options，它的頭部是固定的長度40 bytes，所以IPv6中并不需要IHL區(qū)域。Payload Length用來表示IPv6的數(shù)據(jù)部分的長度。整個IP包為40 bytes + Payload Length。

IPv4中還有一個Header Checksum區(qū)域。這個checksum用于校驗IP包的頭部信息。Checksum與之前在小喇叭中提到的CRC算法并不相同。IPv6則沒有checksum區(qū)域。IPv6包的校驗依賴高層的協(xié)議來完成，這樣的好處是免去了執(zhí)行checksum校驗所需要的時間，減小了網(wǎng)絡(luò)延遲 (latency)。

Identification, flags和fragment offset，這三個包都是為碎片化(fragmentation)服務(wù)的。碎片化是指一個路由器將接收到的IP包分拆成多個IP包傳送，而接收這些“碎片”的路由器或者主機需要將“碎片”重新組合(reassembly)成一個IP包。不同的局域網(wǎng)所支持的最大傳輸單元(MTU, Maximum Transportation Unit)不同。如果一個IP包的大小超過了局域網(wǎng)支持的MTU，就需要在進入該局域網(wǎng)時碎片化傳輸(就好像方面面面餅太大了，必須掰碎才能放進碗里)。碎片化會給路由器和網(wǎng)絡(luò)帶來很大的負擔。最好在IP包發(fā)出之前探測整個路徑上的最小MTU，IP包的大小不超過該最小MTU，就可以避免碎片化。IPv6在設(shè)計上避免碎片化。每一個IPv6局域網(wǎng)的MTU都必須大于等于1280 bytes。IPv6的默認發(fā)送IP包大小為1280 bytes。

令人痛苦的碎片化

Flow Label是IPv6中新增的區(qū)域。它被用來提醒路由器來重復使用之前的接力路徑。這樣IP包可以自動保持出發(fā)時的順序。這對于流媒體之類的應(yīng)用有幫助。Flow label的進一步使用還在開發(fā)中。

IP協(xié)議在產(chǎn)生時是一個松散的網(wǎng)絡(luò)，這個網(wǎng)絡(luò)由各個大學的局域網(wǎng)相互連接成的，由一群碰頭垢面的Geek維護。所以，ip協(xié)議認為自己所處的環(huán)境是不可靠(unreliable)的：諸如路由器壞掉、實驗室失火、某個PhD踢掉電纜之類的事情隨時會發(fā)生。

不靠譜的網(wǎng)絡(luò)

這樣的兇險環(huán)境下，ip協(xié)議提供的傳送只能是“我盡力” (best effort)式的。所謂的“我盡力”，其潛臺詞是，如果事情出錯不要怪我，我只是答應(yīng)了盡力，可沒保證什么。所以，如果IP包傳輸過程中出現(xiàn)錯誤(比如checksum對不上，比如交通太繁忙，比如超過Time to Live)，根據(jù)IP協(xié)議，你的IP包會直接被丟掉。Game Over, 不會再有進一步的努力來修正錯誤。Best effort讓IP協(xié)議保持很簡單的形態(tài)。更多的質(zhì)量控制交給高層協(xié)議處理，ip協(xié)議只負責有效率的傳輸。

(多么不負責任的郵遞系統(tǒng))

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

“插隊”

IPv6中的Flow Label可以建議路由器將一些IP包保持一樣的接力路徑。但這只是“建議”，路由器可能會忽略該建議。

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

9194 8073 0000 4000 4011 C0A8 0001 C0A8 00C7 (十六進制hex, 這是一個為演示運算過程而設(shè)計的header)

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

  Binary                Hex

  1001000110010100      9194

+ 1000000001110011      8073

  ----------------

1 0001001000000111     11207

+                1

  ----------------

  0001001000001000      1208
上面的計算叫做one's complement sum。求得所有十六位數(shù)的和，

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位數(shù)的one's complement sum，應(yīng)該得到FFFF。如果不是FFFF，那么header是不正確的，整個IP包會被丟棄。

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

每個網(wǎng)絡(luò)協(xié)議的形成都有其歷史原因。比如ip協(xié)議是為了將各個分散的實驗室網(wǎng)絡(luò)連接起來。由于當時的網(wǎng)絡(luò)很小，所以IPv4(IPv4產(chǎn)生與70年代)的地址總量為40億。盡管當時被認為是很大的數(shù)字，但數(shù)字浪潮很快帶來了地址耗盡危機。IPv6的主要目的是增加IPv4的地址容量，但同時根據(jù)IPv4的經(jīng)驗和新時代的技術(shù)進步進行改進，比如避免碎片化，比如取消checksum (由于高層協(xié)議TCP的廣泛使用)。網(wǎng)絡(luò)協(xié)議技術(shù)上并不復雜，更多的考量是政策性的。

IP協(xié)議是"Best Effort"式的，IP傳輸是不可靠的。但這樣的設(shè)計成就了ip協(xié)議的效率。

歡迎繼續(xù)閱讀“協(xié)議森林”系列

posted @

  本文關(guān)鍵詞：ip協(xié)議，由筆耕文化傳播整理發(fā)布。