在粗略了解了IP接力和IP地址后减拭，我們?cè)俜催^來，看一看IP協(xié)議的具體細(xì)節(jié)和設(shè)計(jì)哲學(xué)筹淫。
IPv4與IPv6頭部的對(duì)比
我們已經(jīng)在IP接力中介紹過皱炉，一個(gè)IP包分為頭部(header)和數(shù)據(jù)(payload/data)兩部分。頭部是為了實(shí)現(xiàn)IP通信必須的附加信息溪厘，數(shù)據(jù)是IP通信所要傳送的信息胡本。
黃色區(qū)域 (同名區(qū)域)
我們看到，三個(gè)黃色區(qū)域跨越了IPv4和IPv6畸悬。Version(4位)用來表明IP協(xié)議版本侧甫，是IPv4還是IPv6(IPv4, Version=0100; IPv6, Version=0110)。Source Adrresss和Destination Address分別為發(fā)出地和目的地的IP地址蹋宦。
藍(lán)色區(qū)域 （名字發(fā)生變動(dòng)的區(qū)域）
Time to Live 存活時(shí)間(Hop Limit?in IPv6)披粟。Time to Live最初是表示一個(gè)IP包的最大存活時(shí)間：如果IP包在傳輸過程中超過Time to Live，那么IP包就作廢冷冗。后來守屉，IPv4的這個(gè)區(qū)域記錄一個(gè)整數(shù)(比如30)，表示在IP包接力過程中最多經(jīng)過30個(gè)路由接力蒿辙，如果超過30個(gè)路由接力拇泛，那么這個(gè)IP包就作廢。IP包每經(jīng)過一個(gè)路由器须板，路由器就給Time to Live減一碰镜。當(dāng)一個(gè)路由器發(fā)現(xiàn)Time to Live為0時(shí)兢卵，就不再發(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)先級(jí)窃款，比如語(yǔ)音通話需要實(shí)時(shí)性课兄，所以它的IP包應(yīng)該比Web服務(wù)的IP包有更高的優(yōu)先級(jí)。然而晨继，這個(gè)最初不錯(cuò)的想法沒有被微軟采納烟阐。在Windows下生成的IP包都是相同的最高優(yōu)先級(jí)，所以在當(dāng)時(shí)造成Linux和Windows混合網(wǎng)絡(luò)中，Linux的IP傳輸會(huì)慢于Windows (僅僅是因?yàn)長(zhǎng)inux更加守規(guī)矩蜒茄！)唉擂。后來，Type of Service被實(shí)際分為兩部分：Differentiated Service Field?(DS, 前6位)和Explicit Congestion Notification?(ECN, 后2位)檀葛，前者依然用來區(qū)分服務(wù)類型玩祟，而后者用于表明IP包途徑路由的交通狀況。IPv6的Traffic Class也被如此分成兩部分屿聋。通過IP包提供不同服務(wù)的想法空扎，并針對(duì)服務(wù)進(jìn)行不同的優(yōu)化的想法已經(jīng)產(chǎn)生很久了，但具體做法并沒有形成公認(rèn)的協(xié)議润讥。比如ECN區(qū)域转锈，它用來表示IP包經(jīng)過路徑的交通狀況。如果接收者收到的ECN區(qū)域顯示路徑上的很擁擠，那么接收者應(yīng)該作出調(diào)整蜕提。但在實(shí)際上席舍，許多接收者都會(huì)忽視ECN所包含的信息。交通狀況的控制往往由更高層的比如TCP協(xié)議實(shí)現(xiàn)甫煞。
Protocol 協(xié)議(Next Header?in IPv6)。Protocol用來說明IP包Payload部分所遵循的協(xié)議冠绢，也就是IP包之上的協(xié)議是什么抚吠。它說明了IP包封裝的是一個(gè)怎樣的高層協(xié)議包(TCP? UDP?)。
Total Length,?以及IPv6中Payload Length的討論要和IHL區(qū)域放在一起弟胀，我們即將討論楷力。
紅色區(qū)域 (IPv6中刪除的區(qū)域)
我們看一下IPv4和IPv6的長(zhǎng)度信息。IPv4頭部的長(zhǎng)度孵户。在頭部的最后萧朝，是options。每個(gè)options有32位夏哭，是選填性質(zhì)的區(qū)域检柬。一個(gè)IPv4頭部可以完全沒有options區(qū)域。不考慮options的話竖配，整個(gè)IPv4頭部有20 bytes(上面每行為4 bytes)何址。但由于有options的存在，整個(gè)頭部的總長(zhǎng)度是變動(dòng)的进胯。我們用IHL(Internet Header Length)來記錄頭部的總長(zhǎng)度用爪，用Total Length記錄整個(gè)IP包的長(zhǎng)度。IPv6沒有options胁镐，它的頭部是固定的長(zhǎng)度40 bytes偎血，所以IPv6中并不需要IHL區(qū)域诸衔。Payload Length用來表示IPv6的數(shù)據(jù)部分的長(zhǎng)度。整個(gè)IP包為40 bytes + Payload Length颇玷。
IPv4中還有一個(gè)Header Checksum區(qū)域署隘。這個(gè)checksum用于校驗(yàn)IP包的頭部信息。Checksum與之前在小喇叭中提到的CRC算法并不相同亚隙。IPv6則沒有checksum區(qū)域磁餐。IPv6包的校驗(yàn)依賴高層的協(xié)議來完成，這樣的好處是免去了執(zhí)行checksum校驗(yàn)所需要的時(shí)間阿弃，減小了網(wǎng)絡(luò)延遲 (latency)诊霹。
Identification,?flags和fragment offset，這三個(gè)包都是為碎片化(fragmentation)服務(wù)的渣淳。碎片化是指一個(gè)路由器將接收到的IP包分拆成多個(gè)IP包傳送脾还，而接收這些“碎片”的路由器或者主機(jī)需要將“碎片”重新組合(reassembly)成一個(gè)IP包。不同的局域網(wǎng)所支持的最大傳輸單元(MTU, Maximum Transportation Unit)不同入愧。如果一個(gè)IP包的大小超過了局域網(wǎng)支持的MTU鄙漏，就需要在進(jìn)入該局域網(wǎng)時(shí)碎片化傳輸(就好像方面面面餅太大了，必須掰碎才能放進(jìn)碗里)棺蛛。碎片化會(huì)給路由器和網(wǎng)絡(luò)帶來很大的負(fù)擔(dān)怔蚌。最好在IP包發(fā)出之前探測(cè)整個(gè)路徑上的最小MTU，IP包的大小不超過該最小MTU旁赊，就可以避免碎片化桦踊。IPv6在設(shè)計(jì)上避免碎片化。每一個(gè)IPv6局域網(wǎng)的MTU都必須大于等于1280 bytes终畅。IPv6的默認(rèn)發(fā)送IP包大小為1280 bytes籍胯。
綠色區(qū)域 (IPv6新增區(qū)域)
Flow Label是IPv6中新增的區(qū)域。它被用來提醒路由器來重復(fù)使用之前的接力路徑离福。這樣IP包可以自動(dòng)保持出發(fā)時(shí)的順序杖狼。這對(duì)于流媒體之類的應(yīng)用有幫助。Flow label的進(jìn)一步使用還在開發(fā)中妖爷。
“我盡力”
IP協(xié)議在產(chǎn)生時(shí)是一個(gè)松散的網(wǎng)絡(luò)蝶涩，這個(gè)網(wǎng)絡(luò)由各個(gè)大學(xué)的局域網(wǎng)相互連接成的，由一群碰頭垢面的Geek維護(hù)赠涮。所以子寓，IP協(xié)議認(rèn)為自己所處的環(huán)境是不可靠(unreliable)的：諸如路由器壞掉暗挑、實(shí)驗(yàn)室失火笋除、某個(gè)PhD踢掉電纜之類的事情隨時(shí)會(huì)發(fā)生。
這樣的兇險(xiǎn)環(huán)境下炸裆，IP協(xié)議提供的傳送只能是“我盡力” (best effort)式的垃它。所謂的“我盡力”，其潛臺(tái)詞是，如果事情出錯(cuò)不要怪我国拇，我只是答應(yīng)了盡力洛史，可沒保證什么。所以酱吝，如果IP包傳輸過程中出現(xiàn)錯(cuò)誤(比如checksum對(duì)不上也殖，比如交通太繁忙，比如超過Time to Live)务热，根據(jù)IP協(xié)議忆嗜，你的IP包會(huì)直接被丟掉。Game Over, 不會(huì)再有進(jìn)一步的努力來修正錯(cuò)誤崎岂。Best effort讓IP協(xié)議保持很簡(jiǎn)單的形態(tài)捆毫。更多的質(zhì)量控制交給高層協(xié)議處理，IP協(xié)議只負(fù)責(zé)有效率的傳輸冲甘。
(多么不負(fù)責(zé)任的郵遞系統(tǒng))
“效率優(yōu)先”也體現(xiàn)在IP包的順序(order)上绩卤。即使出發(fā)地和目的地保持不變，IP協(xié)議也不保證IP包到達(dá)的先后順序江醇。我們已經(jīng)知道濒憋，IP接力是根據(jù)routing table決定接力路線的。如果在連續(xù)的IP包發(fā)送過程中陶夜，routing table更新(比如有一條新建的捷徑出現(xiàn))跋炕，那么后發(fā)出的IP包選擇走不一樣的接力路線。如果新的路徑傳輸速度更快律适，那么后發(fā)出的IP包有可能先到辐烂。這就好像是多車道的公路上，每輛車都在不停變換車道捂贿，最終所有的車道都塞滿汽車纠修。這樣可以讓公路利用率達(dá)到最大。
IPv6中的Flow Label可以建議路由器將一些IP包保持一樣的接力路徑厂僧。但這只是“建議”扣草，路由器可能會(huì)忽略該建議。
Header Checksum算法
Header Checksum區(qū)域有16位颜屠。它是這樣獲得的辰妙，從header取得除checksum之外的0/1序列，比如：
9194 8073 0000 4000 4011 C0A8 0001 C0A8 00C7?(十六進(jìn)制hex, 這是一個(gè)為演示運(yùn)算過程而設(shè)計(jì)的header)
按照十六位(也就是4位hex)分割整個(gè)序列甫窟。將分割后的各個(gè)4位hex累積相加密浑。如果有超過16位的進(jìn)位出現(xiàn)，則將進(jìn)位加到后16位結(jié)果的最后一位：
Binary??????????????? Hex
1001000110010100????? 9194
+ 1000000001110011????? 8073
—————-
1 0001001000000111???? 11207
+??????????????? 1
—————-
0001001000001000????? 1208
上面的計(jì)算叫做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包之后餐济，可以求上面各個(gè)16位數(shù)的one’s complement sum，應(yīng)該得到FFFF胆剧。如果不是FFFF絮姆，那么header是不正確的，整個(gè)IP包會(huì)被丟棄秩霍。
(再次提醒滚朵，示例所用的IP header不是真實(shí)的header，它只是起演示算法的作用)
總結(jié)
每個(gè)網(wǎng)絡(luò)協(xié)議的形成都有其歷史原因前域。比如IP協(xié)議是為了將各個(gè)分散的實(shí)驗(yàn)室網(wǎng)絡(luò)連接起來辕近。由于當(dāng)時(shí)的網(wǎng)絡(luò)很小，所以IPv4(IPv4產(chǎn)生與70年代)的地址總量為40億匿垄。盡管當(dāng)時(shí)被認(rèn)為是很大的數(shù)字移宅，但數(shù)字浪潮很快帶來了地址耗盡危機(jī)。IPv6的主要目的是增加IPv4的地址容量椿疗，但同時(shí)根據(jù)IPv4的經(jīng)驗(yàn)和新時(shí)代的技術(shù)進(jìn)步進(jìn)行改進(jìn)漏峰，比如避免碎片化，比如取消checksum (由于高層協(xié)議TCP的廣泛使用)届榄。網(wǎng)絡(luò)協(xié)議技術(shù)上并不復(fù)雜浅乔，更多的考量是政策性的。
IP協(xié)議是”Best Effort”式的铝条，IP傳輸是不可靠的靖苇。但這樣的設(shè)計(jì)成就了IP協(xié)議的效率。
【TCP/IP詳解】系列教程
TCP-IP協(xié)議詳解(1)網(wǎng)絡(luò)協(xié)議概觀
TCP-IP協(xié)議詳解(2) 以太網(wǎng)與WiFi協(xié)議
TCP-IP協(xié)議詳解(3) IP/ARP/RIP/BGP協(xié)議
TCP-IP協(xié)議詳解(6) ICMP協(xié)議
TCP-IP協(xié)議詳解(8) TCP協(xié)議與流通信
TCP-IP協(xié)議詳解(13) DNS協(xié)議
