全硬件TCP/IP協議棧學習筆記（第三天：TCP/IP協議學習三）

昨天我們結束時到了UDP協議，今天我們繼續

<2>.UDP協議頭

（1）UDP端口號：UDP協議通過端口號來區分不同程序的程序所需要的數據包。長度為16bit。

（2）UDP檢驗和：這是可選的選項，并不是所有系統都對UDP數據包加以檢驗，但是

RFC中標準要求發送端應該計算檢驗和。

UDP檢驗和覆蓋UDP協議頭和數據，這和IP的檢驗和不一樣，IP的檢驗和只覆蓋IP數據頭，并不覆蓋所有數據。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而設置的。偽首部還包括IP地址這樣的IP協議里都有的信息。目的是讓兩次檢查數據是否已經正確到達目的地。

（3）.UDP長度：它的長度可以達到65535字節。但是一般的網絡在傳輸的時候，一次一般傳送不了那么長的協議，就只好對數據分片。

<3>.IP分片：IP從上層接到數據之后，要根據IP地址來判斷從哪個接口發送數據，并進行MTU的查詢，如果數據大小超過MTU就進行數據分片。數據的分片是對上下層透明的，而數據也只是達到目的地還會被重新組裝。IP層提供了足夠多的信息進行數據的再組裝。

在IP頭內，16bit識別號唯一記錄了一個IP包的ID，具有同一個ID的IP片將會被重新組裝，而13位片偏移則記錄了某IP片相對于整個包的位置；而這兩個表示中間3bit標志表示著該分片后邊是否還有新的分片。這三個標示就組成了IP分片的所有信息，接收方就可以利用這些信息對IP數據重新組織。

但是，由于分片技術在網絡上經常被使用，所以偽造IP分片包進行流氓攻擊的軟件也就多了起來，可以使用Trancdroute程序來進行簡單的MTU偵測。

<3>.UDP和ARP之間的交互使用

當ARP緩存還是空的時候，UDP在被發送之前需要發送一個ARP請求來獲得目的主機的MAC地址，如果這個UDP的數據包足夠大，大到IP層一定要對其進行分片的時候，該UDP數據包的第一個分片會發送一個ARP查詢請求，但是有些系統會讓每一個分片都發送一個ARP查詢，所有的片都在等待，但是接受到第一個回應的時候，，主機卻發送了最后一個數據片而拋棄了其他的...，這樣的數據不能被及時組裝，接收主機將會在一段時間內無法組裝的IP數據包拋棄，并發送組裝超時的ICMP報文。以保證接收主機不會自己的接收端緩存不會被那些總也得不到組裝的分片裝滿。

3.TCP協議

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

為了解決這個問題，提高網絡的可靠性，TCP協議就誕生了，它可被近似認為是一個有確認機制的UDP協議，每發出一個數據包都被要求確認。如果有一個數據包遺失，就收不到確認，發出方就知道有必要重新發送這個數據包了。TCP協議能夠確保數據不會遺失，但是他的缺點就是過程復雜，實現困難，消耗較多的資源。

TCP數據包和UDP數據包都是內嵌在IP數據包的數據部分。TCP數據包沒有長度限制，；理論上可以無限長。通常TCP數據包不會超過IP數據包的長度，以確保單個TCP數據包不必再分割。