網際網路協議

IP協議，主要負責通過網路連接在數據源主機和目的主機間傳送數據包。

在 RFC 791 中對於 IP協議是這樣定義的:

“網際網路協議（IP）特指為實現在一個相互連接的網路系統上從一個源到一個目的地傳輸比特數據包（網際網路數據包）所提供必要功能的協議。其中並沒有增加端到端數據可靠性機制、流量控制機制、排序機制或者其它在端到端協議常見的功能機制。網際網路協議可在其支持的網路上提供相應服務，實現多種類型和品質的服務。”

IP通過多種屬性來定義數據是如何被傳輸的，而這些屬性對於我們將要討論的IPv4或IPv6話題來說至關重要。因此我們要詳細了解一下相關屬性:

· Host addressing主機定址: IP 協議為網路上每個主機定義了定址方案，通過主機地址使得數據包得以傳遞。

IP協議被設計為可以通過協議棧技術與其它網路協議聯合使用。

· Connectionless delivery無連接交付:IP協議不承擔在數據源主機和目的主機間建立連接的責任。只負責從數據源主機建立數據報併發送出去的工作。

· Best-effort delivery最大努力交付:IP協議會盡量確保目標主機能夠獲得發送給它的數據包，但是並不是絕對保證。

· No provision for delivery acknowledgments無需交付確認：目標主機收到數據包后不需要向發送源主機提交確認信息。

也許有人會問，既然後三個屬性沒有實現一個良好的數據傳輸環境，IP 協議數據包是如何知道自己該被發送到哪裡？為什麼協議沒有其它更多功能？答案很簡單，為了更好的數據傳輸性能。使用確立連接，錯誤校驗，確認交付等功能，都需要額外的處理器資源以及額外的網路帶寬。因此如果被傳輸的數據報不需要這些功能，那麼就最好不要。另外，開發IP協議的人員也不是傻子，可以通過協議堆棧更有效的實現上述功能。

規定網路地址的協議，叫做IP協議。它所定義的地址，就被稱為IP地址。

目前，廣泛採用的是IP協議第四版，簡稱IPv4。這個版本規定，網路地址由32個二進位位組成。

習慣上，我們用分成四段的十進位數表示IP地址，從0.0.0.0一直到255.255.255.255。

網際網路上的每一台計算機，都會分配到一個IP地址。這個地址分成兩個部分，前一部分代表網路，后一部分代表主機。比如，IP地址172.16.254.1，這是一個32位的地址，假定它的網路部分是前24位（172.16.254），那麼主機部分就是后8位（最後的那個1）。處於同一個子網路的電腦，它們IP地址的網路部分必定是相同的，也就是說172.16.254.2應該與172.16.254.1處在同一個子網路。

但是，問題在於單單從IP地址，我們無法判斷網路部分。還是以172.16.254.1為例，它的網路部分，到底是前24位，還是前16位，甚至前28位，從IP地址上是看不出來的。

那麼，怎樣才能從IP地址，判斷兩台計算機是否屬於同一個子網路呢？這就要用到另一個參數"子網掩碼"（subnet mask）。

所謂"子網掩碼"，就是表示子網路特徵的一個參數。它在形式上等同於IP地址，也是一個32位二進位數字，它的網路部分全部為1，主機部分全部為0。比如，IP地址172.16.254.1，如果已知網路部分是前24位，主機部分是后8位，那麼子網路掩碼就是11111111.11111111.11111111.00000000，寫成十進位就是255.255.255.0。

知道"子網掩碼"，我們就能判斷，任意兩個IP地址是否處在同一個子網路。方法是將兩個IP地址與子網掩碼分別進行AND運算（兩個數位都為1，運算結果為1，否則為0），然後比較結果是否相同，如果是的話，就表明它們在同一個子網路中，否則就不是。

比如，已知IP地址172.16.254.1和172.16.254.233的子網掩碼都是255.255.255.0，請問它們是否在同一個子網路？兩者與子網掩碼分別進行AND運算，結果都是172.16.254.0，因此它們在同一個子網路。

總結一下，IP協議的作用主要有兩個，一個是為每一台計算機分配IP地址，另一個是確定哪些地址在同一個子網路。

UDP協議的優點是比較簡單，容易實現，但是缺點是可靠性較差，一旦數據包發出，無法知道對方是否收到。

為了解決這個問題，提高網路可靠性，TCP協議就誕生了。這個協議非常複雜，但可以近似認為，它就是有確認機制的UDP協議，每發出一個數據包都要求確認。如果有一個數據包遺失，就收不到確認，發出方就知道有必要重發這個數據包了。

因此，TCP協議能夠確保數據不會遺失。它的缺點是過程複雜、實現困難、消耗較多的資源。

TCP數據包和UDP數據包一樣，都是內嵌在IP數據包的"數據"部分。TCP數據包沒有長度限制，理論上可以無限長，但是為了保證網路的效率，通常TCP數據包的長度不會超過IP數據包的長度，以確保單個TCP數據包不必再分割。

當討論IP協議時，很多人（包括我在內）都會混淆packet 和 datagram 這兩個術語，因為這兩者的定義非常類似（有些人認為二者完全相同）。RFC 1594 對於數據包和數據報的共同定義如下：

“一個獨立的數據實體，攜帶從數據源主機到目的主機所需的足夠信息，而不依賴於源主機和目的主機之前建立的網路連接或者交換。”

既然定義是一樣的，為什麼還有這兩個術語是否相同的討論呢？實際上是一些專家對於packets和 datagrams有不同的定義，從而導致了疑問的產生。這些專家在討論有關可靠數據傳輸協議，比如TCP/IP時，會使用packet數據包這個術語，而在討論UDP 這樣的最大努力交付協議時，會使用datagram數據報這個術語。在我們討論IP時，使用哪個術語都是可以的，但是我傾向於使用數據報（稍後你們會知道為什麼我要這樣）。