IP協(xié)議,，主要負(fù)責(zé)通過網(wǎng)絡(luò)連接在數(shù)據(jù)源主機(jī)和目的主機(jī)間傳送數(shù)據(jù)包。

在 RFC 791 中對(duì)于 IP協(xié)議是這樣定義的:

"互聯(lián)網(wǎng)協(xié)議(IP)特指為實(shí)現(xiàn)在一個(gè)相互連接的網(wǎng)絡(luò)系統(tǒng)上從一個(gè)源到一個(gè)目的地傳輸比特?cái)?shù)據(jù)包(互聯(lián)網(wǎng)數(shù)據(jù)包)所提供必要功能的協(xié)議,。其中并沒有增加

IP通過多種屬性來定義數(shù)據(jù)是如何被傳輸?shù)?，而這些屬性對(duì)于我們將要討論的IPv4或IPv6話題來說至關(guān)重要。因此我們要詳細(xì)了解一下相關(guān)屬性:

· Host addressing主機(jī)尋址: IP 協(xié)議為網(wǎng)絡(luò)上每個(gè)主機(jī)定義了尋址方案,，通過主機(jī)地址使得數(shù)據(jù)包得以傳遞,。

· Protocol independence協(xié)議獨(dú)立性:IP協(xié)議被設(shè)計(jì)為可以通過協(xié)議棧技術(shù)與其它網(wǎng)絡(luò)協(xié)議聯(lián)合使用。

· Connectionless delivery無連接交付:IP協(xié)議不承擔(dān)在數(shù)據(jù)源主機(jī)和目的主機(jī)間建立連接的責(zé)任,。只負(fù)責(zé)從數(shù)據(jù)源主機(jī)建立數(shù)據(jù)報(bào)并發(fā)送出去的工作,。

· Best-effort delivery最大努力交付:IP協(xié)議會(huì)盡量確保目標(biāo)主機(jī)能夠獲得發(fā)送給它的數(shù)據(jù)包，但是并不是絕對(duì)保證,。

· No provision for delivery acknowledgments無需交付確認(rèn):目標(biāo)主機(jī)收到數(shù)據(jù)包后不需要向發(fā)送源主機(jī)提交確認(rèn)信息,。

也許有人會(huì)問，既然后三個(gè)屬性沒有實(shí)現(xiàn)一個(gè)良好的數(shù)據(jù)傳輸環(huán)境,，IP 協(xié)議數(shù)據(jù)包是如何知道自己該被發(fā)送到哪里?為什么協(xié)議沒有其它更多功能?答案很簡(jiǎn)單,，為了更好的數(shù)據(jù)傳輸性能。使用確立連接,，錯(cuò)誤校驗(yàn),，確認(rèn)交付等功能，都需要額外的處理器資源以及額外的網(wǎng)絡(luò)帶寬,。因此如果被傳輸?shù)臄?shù)據(jù)報(bào)不需要這些功能,，那么就最好不要。另外,，開發(fā)IP協(xié)議的人員也不是傻子,，可以通過協(xié)議堆棧更有效的實(shí)現(xiàn)上述功能,。

規(guī)定網(wǎng)絡(luò)地址的協(xié)議，叫做IP協(xié)議,。它所定義的地址,，就被稱為IP地址。

目前,，廣泛采用的是IP協(xié)議第四版,，簡(jiǎn)稱IPv4。這個(gè)版本規(guī)定,，網(wǎng)絡(luò)地址由32個(gè)二進(jìn)制位組成,。

習(xí)慣上，我們用分成四段的十進(jìn)制數(shù)表示IP地址,，從0.0.0.0一直到255.255.255.255,。

互聯(lián)網(wǎng)上的每一臺(tái)計(jì)算機(jī)，都會(huì)分配到一個(gè)IP地址,。這個(gè)地址分成兩個(gè)部分,，前一部分代表網(wǎng)絡(luò)，后一部分代表主機(jī),。比如,，IP地址172.16.254.1，這是一個(gè)32位的地址,，假定它的網(wǎng)絡(luò)部分是前24位(172.16.254)，那么主機(jī)部分就是后8位(最后的那個(gè)1),。處于同一個(gè)子網(wǎng)絡(luò)的電腦,，它們IP地址的網(wǎng)絡(luò)部分必定是相同的，也就是說172.16.254.2應(yīng)該與172.16.254.1處在同一個(gè)子網(wǎng)絡(luò),。

但是,，問題在于單單從IP地址，我們無法判斷網(wǎng)絡(luò)部分,。還是以172.16.254.1為例,，它的網(wǎng)絡(luò)部分，到底是前24位,，還是前16位,，甚至前28位，從IP地址上是看不出來的,。

那么,，怎樣才能從IP地址，判斷兩臺(tái)計(jì)算機(jī)是否屬于同一個(gè)子網(wǎng)絡(luò)呢?這就要用到另一個(gè)參數(shù)"

所謂"子網(wǎng)掩碼",，就是表示子網(wǎng)絡(luò)特征的一個(gè)參數(shù),。它在形式上等同于IP地址，也是一個(gè)32位二進(jìn)制數(shù)字,，它的網(wǎng)絡(luò)部分全部為1,，主機(jī)部分全部為0。比如,，IP地址172.16.254.1,，如果已知網(wǎng)絡(luò)部分是前24位，主機(jī)部分是后8位,，那么子網(wǎng)絡(luò)掩碼就是11111111.11111111.11111111.00000000,，寫成十進(jìn)制就是255.255.255.0。

知道"

比如,，已知IP地址172.16.254.1和172.16.254.233的子網(wǎng)掩碼都是255.255.255.0，請(qǐng)問它們是否在同一個(gè)子網(wǎng)絡(luò)?兩者與子網(wǎng)掩碼分別進(jìn)行AND運(yùn)算,，結(jié)果都是172.16.254.0,，因此它們?cè)谕粋€(gè)子網(wǎng)絡(luò)。

總結(jié)一下,，IP協(xié)議的作用主要有兩個(gè),，一個(gè)是為每一臺(tái)計(jì)算機(jī)分配IP地址，另一個(gè)是確定哪些地址在同一個(gè)子網(wǎng)絡(luò),。

TCP協(xié)議

UDP協(xié)議的優(yōu)點(diǎn)是比較簡(jiǎn)單,，容易實(shí)現(xiàn)，但是缺點(diǎn)是可靠性較差,，一旦數(shù)據(jù)包發(fā)出,，無法知道對(duì)方是否收到。

為了解決這個(gè)問題,，提高網(wǎng)絡(luò)可靠性,，TCP協(xié)議就誕生了。這個(gè)協(xié)議非常復(fù)雜,，但可以近似認(rèn)為,，它就是有確認(rèn)機(jī)制的UDP協(xié)議,，每發(fā)出一個(gè)數(shù)據(jù)包都要求確認(rèn)。如果有一個(gè)數(shù)據(jù)包遺失,，就收不到確認(rèn),，發(fā)出方就知道有必要重發(fā)這個(gè)數(shù)據(jù)包了。

因此,，TCP協(xié)議能夠確保數(shù)據(jù)不會(huì)遺失,。它的缺點(diǎn)是過程復(fù)雜、實(shí)現(xiàn)困難,、消耗較多的資源,。

數(shù)據(jù)包和數(shù)據(jù)報(bào)的區(qū)別

當(dāng)討論IP協(xié)議時(shí)，很多人(包括我在內(nèi))都會(huì)混淆packet 和 datagram 這兩個(gè)術(shù)語,，因?yàn)檫@兩者的定義非常類似(有些人認(rèn)為二者完全相同),。RFC 1594 對(duì)于數(shù)據(jù)源

既然定義是一樣的,，為什么還有這兩個(gè)術(shù)語是否相同的討論呢?實(shí)際上是一些專家對(duì)于packets和 datagrams有不同的定義,，從而導(dǎo)致了疑問的產(chǎn)生。這些專家在討論有關(guān)可靠數(shù)據(jù)傳輸協(xié)議,，比如TCP/IP時(shí),，會(huì)使用packet數(shù)據(jù)包這個(gè)術(shù)語，而在討論UDP 這樣的最大努力交付協(xié)議時(shí),，會(huì)使用datagram數(shù)據(jù)報(bào)這個(gè)術(shù)語。 在我們討論IP時(shí),，使用哪個(gè)術(shù)語都是可以的,，但是我傾向于使用數(shù)據(jù)報(bào)(稍后你們會(huì)知道為什么我要這樣)。