最近在做項目的時候發現了一個嚴重問題,可能不光是我多人在使用 win32 socket 進行開發的時候也會遇到的問題。首先我分析的模塊是 我項目中文件傳輸的部分，我做的是一個基于UDP協議的一個局域網通信軟件,里面有一個文件傳輸的模塊 ，起初的時候我也完成了文件傳輸的功能,以為這就可以了,其實我在做的時候忽略了很多細節部分,比如數據應該如何傳輸 ,一次最多發送多少數據 以及如何控制同步問題 。這些問題我都沒有詳細去追究,直到最近我去某公司面試的時候,那位很牛逼的大哥跟我說了一句,"你知道windos底層一次最多發送多少字節的數據嗎?" ，我驚了。。我還真的不知道。還有剩下很多對話點明了我 ,說實話面試 我學到了不少的東西 。。呵呵、? 。? 我廢話不多說了，我查詢了一些資料終于整明白了這些問題 ，整理出來分享給大家。我將從IP數據包 以及OSI各層逐步分析UDP協議以及 win32 socket函數的原理 。以及在發送數據的時候應該注意的一些問題。 要明白? IP數據報??? 數據幀?? UDP數據包? 的結構以及他們之間的聯系。?? 數據在OSI各層的表現形式??? MTU 等等 我的理解是???? 數據幀包含（幀頭、IP數據包、幀尾）??????? ?????????????????????? IP數據報包含（20個字節的IP數據報頭 、UDP數據包） ?????????????????????? UDP數據包包含(8字節UDP報文頭、我們要發送的實際數據) ????????????????????? UDP報頭包含（源端口、目的端口、數據包長度、校驗)? 每個部分都是2個字節。? win32的socket函數庫中的? sendto函數在發送數據的時候 實際上是根據我們所提供的參數在他的實現函數的內部 進行了UDP數據包的構造到----->（數據幀）-------->IP數據報----->接收方數據幀---->提取數據包?? 的這么一個流程 、 ? 在Internet上傳輸的只有IP數據報 、 ? 數據包組成數據幀 sendto的發送以及recvform的接收： 我們可能調用了多次sendto 發送的數據，在接收方一次recvfrom就接收完了 。這就意味著每個sendto不一定必須對應一個recvfrom 。 反之也可能 我們一次sendto的數據可能被recvfrom多次調用才接收完畢了 ,這對于TCP一樣好用。 如果不明白繼續往下看

1、? 數據幀??? OSI數據鏈路層數據的表現形式。 IP數據報在 數據幀的數據部分。

??????? 數據幀? 包括幀頭 、數據部分、 幀尾。 具體解釋如下:

所謂數據幀，就是數據鏈路層的協議數據單元，它包括三部分：幀頭，數據部分，幀尾。其中，幀頭和幀尾包含一些必要得控制信息，比如同步信息、地址信息、差錯控制信息等；數據部分則包含網絡層傳下來的數據，比如ip數據報。

　　在發送端，數據鏈路層把網絡層傳下來得數據封裝成幀，然后發送到鏈路上去；在接收端，數據鏈路層把收到的幀中的數據取出并交給網絡層。不同的數據鏈路層協議對應著不同的幀，所以，幀有多種，比如PPP幀、MAC幀等，其具體格式也不盡相同。

　　下面以MAC幀的格式為例進行說明：

　　MAC幀的幀頭包括三個字段。前兩個字段分別為6字節長的目的地址字段和源地址字段，目的地址字段包含目的MAC地址信息，源地址字段包含源MAC地址信息。第三個字段為2字節的類型字段，里面包含的信息用來標志上一層使用的是什么協議，以便接收端把收到的MAC幀的數據部分上交給上一層的這個協議。例如，當類型字段的值是0x0800時，就表示上層使用的是IP數據報；若類型字段的值為0x8137，則表示該幀是由Novell IPX 發過來的。

　　MAC幀的數據部分只有一個字段，其長度在46到1500字節之間，包含的信息是網絡層傳下來的數據。

　　MAC幀的幀尾也只有一個字段，為4字節長，包含的信息是幀校驗序列FCS（使用CRC校驗）。

2、? IP數據報以及解釋?? IP數據報包含（20個字節的IP數據報頭 、UDP數據包）??

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

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

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

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

　UDP協議使用端口號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是采用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方（可以是客戶端或服務器端）將UDP數據報通過源端口發送出去，而數據接收一方則通過目標端口接收數據。有的網絡應用只能使用預先為其預留或注冊的靜態端口；而另外一些網絡應用則可以使用未被注冊的動態端口。因為UDP報頭使用兩個字節存放端口號，所以端口號的有效范圍是從0到65535。一般來說，大于49151的端口號都代表動態端口。

　　數據報的長度是指包括報頭和數據部分在內的總字節數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分（又稱為數據負載）。數據報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為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以應用程序讀操作時所要求的長度來傳送數據，因此，在這個接口下，不會發生數據丟失。

轉載于:https://www.cnblogs.com/mosatsu/archive/2012/04/22/2466775.html

總結

以上是生活随笔為你收集整理的UDP协议下数据的传输分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。