TCP/IP協議 定義了一個在因特網上傳輸的包，稱為IP數據報(IP Datagram)。這是一個與硬件無關的虛擬包, 由首部和數據兩部分組成，其格式如圖所示。首部的前一部分是固定長度，共20字節，是所有IP數據報必須具有的。在首部的固定部分的后面是一些可選字段，其長度是可變的。首部中的源地址和目的地址都是IP協議地址。

下面是IP報頭部 更詳細信息 http://baike.baidu.com/view/1519445.htm

3、UDP數據包包含(8字節UDP報文頭、我們要發送的實際數據)

下面是UDP包頭信息UDP報頭由4個域組成，其中每個域各占用2個字節，具體如下：

　　數據報的長度是指包括報頭和數據部分在內的總字節數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分（又稱為數據負載）。數據報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為65535字節。不過，一些實際應用往往會限制數據報的大小，有時會降低到8192字節。

　　UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。如果某個數據報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發送和接收方的校驗計算值將不會相符，由此UDP協議可以檢測是否出錯。這與TCP協議是不同的，后者要求必須具有校驗值。

　　許多鏈路層協議都提供錯誤檢查，包括流行的 以太網 協議，也許你想知道為什么UDP也要提供檢查和校驗。其原因是鏈路層以下的協議在源端和 終端 之間的某些通道可能不提供錯誤檢測。雖然UDP提供有錯誤檢測，但檢測到錯誤時，UDP不做錯誤校正，只是簡單地把損壞的消息段扔掉，或者給應用程序提供警告信息。

4、UDP一次最多發送多少數據？ 如果數據包長度超過 MTU那么就會分片發送。

在進行UDP編程的時候,我們最容易想到的問題就是,一次發送多少bytes好?
當然,這個沒有唯一答案，相對于不同的系統,不同的要求,其得到的答案是不一樣的,這里僅對像ICQ一類的發送聊天消息的情況作分析，對于其他情況，或許也能得到一點幫助:
首先,我們知道,TCP/IP通常被認為是一個四層協議系統,包括鏈路層,網絡層,傳輸層,應用層.UDP屬于運輸層,下面我們由下至上一步一步來看:
以太網(Ethernet)數據幀的長度必須在46-1500字節之間,這是由以太網的物理特性決定的.這個1500字節被稱為鏈路層的MTU(最大傳輸單元).但這并不是指鏈路層的長度被限制在1500字節,其實這個MTU指的是鏈路層的數據區.并不包括鏈路層的首部和尾部的18個字節.所以,事實上,這個1500字節就是網絡層IP數據報的長度限制.因為IP數據報的首部為20字節,所以IP數據報的數據區長度最大為1480字節.而這個1480字節就是用來放TCP傳來的TCP報文段或UDP傳來的UDP數據報的.又因為UDP數據報的首部8字節,所以UDP數據報的數據區最大長度為1472字節.這個1472字節就是我們可以使用的字節數。:)
當我們發送的UDP數據大于1472的時候會怎樣呢？這也就是說IP數據報大于1500字節,大于MTU.這個時候發送方IP層就需要分片(fragmentation).把數據報分成若干片,使每一片都小于MTU.而接收方IP層則需要進行數據報的重組.這樣就會多做許多事情,而更嚴重的是,由于UDP的特性,當某一片數據傳送中丟失時,接收方便無法重組數據報.將導致丟棄整個UDP數據報。
因此,在普通的局域網環境下，我建議將UDP的數據控制在1472字節以下為好.
進行Internet編程時則不同,因為Internet上的路由器可能會將MTU設為不同的值.如果我們假定MTU為1500來發送數據的,而途經的某個網絡的MTU值小于1500字節,那么系統將會使用一系列的機制來調整MTU值,使數據報能夠順利到達目的地,這樣就會做許多不必要的操作.鑒于Internet上的標準MTU值為576字節,所以我建議在進行Internet的UDP編程時.最好將UDP的數據長度控件在548字節(576-8-20)以內.

理論上，IP數據報的最大長度是65535字節，這是由IP首部16比特總長度字段所限制的。去除20字節的IP首部和8個字節的UDP首部，UDP數據報中用戶數據的最長長度為65507字節。但是，大多數實現所提供的長度比這個最大值小。
我們將遇到兩個限制因素。第一，應用程序可能會受到其程序接口的限制。socket API提供了一個可供應用程序調用的函數，以設置接收和發送緩存的長度。對于UDP socket，這個長度與應用程序可以讀寫的最大UDP數據報的長度直接相關。現在的大部分系統都默認提供了可讀寫大于8192字節的UDP數據報（使用這個默認值是因為8192是NFS讀寫用戶數據數的默認值）。
第二個限制來自于TCP/IP的內核實現。可能存在一些實現特性（或差錯），使IP數據報長度小于65535字節。
在SunOS 4.1.3下使用環回接口的最大IP數據報長度是32767字節。比它大的值都會發生差錯。
但是從BSD/386到SunOS 4.1.3的情況下，Sun所能接收到最大IP數據報長度為32786字節（即32758字節用戶數據）。
在Solaris 2.2下使用環回接口，最大可收發IP數據報長度為65535字節。
從Solaris 2.2到AIX 3.2.2，發送的最大IP數據報長度可以是65535字節。很顯然，這個限制與源端和目的端的實現有關。
主機必須能夠接收最短為576字節的IP數據報。在許多UDP應用程序的設計中，其應用程序數據被限制成512字節或更小，因此比這個限制值小。
由于IP能夠發送或接收特定長度的數據報并不意味著接收應用程序可以讀取該長度的數據。因此，UDP編程接口允許應用程序指定每次返回的最大字節數。如果接收到的數據報長度大于應用程序所能處理的長度，那么會發生什么情況呢？不幸的是，該問題的答案取決于編程接口和實現。
典型的Berkeley版socket API對數據報進行截斷，并丟棄任何多余的數據。應用程序何時能夠知道，則與版本有關（4.3BSD Reno及其后的版本可以通知應用程序數據報被截斷）。
SVR4下的socket API(包括Solaris 2.x) 并不截斷數據報。超出部分數據在后面的讀取中返回。它也不通知應用程序從單個UDP數據報中多次進行讀取操作。TLI API不丟棄數據。相反，它返回一個標志表明可以獲得更多的數據，而應用程序后面的讀操作將返回數據報的其余部分。在討論TCP時，我們發現它為應用程序提供連續的字節流，而沒有任何信息邊界。TCP以應用程序讀操作時所要求的長度來傳送數據，因此，在這個接口下，不會發生數據丟失。