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

1、? 數(shù)據(jù)幀??? OSI數(shù)據(jù)鏈路層數(shù)據(jù)的表現(xiàn)形式。 IP數(shù)據(jù)報在 數(shù)據(jù)幀的數(shù)據(jù)部分。

??????? 數(shù)據(jù)幀? 包括幀頭 、數(shù)據(jù)部分、 幀尾。 具體解釋如下:

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

　　在發(fā)送端，數(shù)據(jù)鏈路層把網(wǎng)絡(luò)層傳下來得數(shù)據(jù)封裝成幀，然后發(fā)送到鏈路上去；在接收端，數(shù)據(jù)鏈路層把收到的幀中的數(shù)據(jù)取出并交給網(wǎng)絡(luò)層。不同的數(shù)據(jù)鏈路層協(xié)議對應(yīng)著不同的幀，所以，幀有多種，比如PPP幀、MAC幀等，其具體格式也不盡相同。

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

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

　　MAC幀的數(shù)據(jù)部分只有一個字段，其長度在46到1500字節(jié)之間，包含的信息是網(wǎng)絡(luò)層傳下來的數(shù)據(jù)。

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

2、? IP數(shù)據(jù)報以及解釋?? IP數(shù)據(jù)報包含（20個字節(jié)的IP數(shù)據(jù)報頭 、UDP數(shù)據(jù)包）??

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

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

3、UDP數(shù)據(jù)包包含(8字節(jié)UDP報文頭、我們要發(fā)送的實際數(shù)據(jù))

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

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

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

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

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

4、UDP一次最多發(fā)送多少數(shù)據(jù)？?? 如果數(shù)據(jù)包長度超過 MTU那么就會分片發(fā)送。

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/mosatsu/archive/2012/04/22/2466775.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。