IP數據包長度問題總結

首先要看TCP/IP協議，涉及到四層：鏈路層，網絡層，傳輸層，應用層。　　
其中以太網（Ethernet）的數據幀在鏈路層 　　
IP包在網絡層　　
TCP或UDP包在傳輸層 　　
TCP或UDP中的數據（Data)在應用層 　　
它們的關系是 數據幀｛IP包｛TCP或UDP包｛Data｝｝｝　　
---------------------------------------------------------------------------------
在應用程序中我們用到的Data的長度最大是多少，直接取決于底層的限制。 　　
我們從下到上分析一下： 　　
1.在鏈路層，由以太網的物理特性決定了數據幀的長度為（46＋18）－（1500＋18），其中的18是數據幀的頭和尾，也就是說數據幀的內容最大為1500（不包括幀頭和幀尾），即MTU（Maximum
Transmission Unit）為1500； 　
2.在網絡層，因為IP包的首部要占用20字節，所以這的MTU為1500－20＝1480；　
3.在傳輸層，對于UDP包的首部要占用8字節，所以這的MTU為1480－8＝1472； 　　
所以，在應用層，你的Data最大長度為1472。（當我們的UDP包中的數據多于MTU(1472)時，發送方的IP層需要分片fragmentation進行傳輸，而在接收方IP層則需要進行數據報重 組，由于UDP是不可靠的傳輸協議，如果分片丟失導致重組失敗，將導致UDP數據包被丟棄）。
　　
從上面的分析來看，在普通的局域網環境下，UDP的數據最大為1472字節最好（避免分片重組）。　　
但在網絡編程中，Internet中的路由器可能有設置成不同的值（小于默認值），Internet上的標準MTU值為576，所以Internet的UDP編程時數據長度最好在576－20－8＝548字節以內。
---------------------------------------------------------------------------------　　
MTU對我們的UDP編程很重要，那如何查看路由的MTU值呢？　　
對于windows OS: ping -f -l 　　如：ping-f -l 1472 192.168.0.1　　
如果提示：Packets needs to be fragmented but DF set. 　　則表明MTU小于1500，不斷改小data_length值，可以最終測算出gateway的MTU值； 　　
對于linux OS: ping -c -M do -s 　　如： ping -c 1 -M do -s 1472 192.168.0.1　　
如果提示 Frag needed and DF set…… 　　則表明MTU小于1500，可以再測以推算gateway的MTU。
---------------------------------------------------------------------------------　

IP數據包的最大長度是64K字節(65535)，因為在IP包頭中用2個字節描述報文長度，2個字節所能表達的最大數字就是65535。??
???
由于IP協議提供為上層協議分割和重組報文的功能，因此傳輸層協議的數據包長度原則上來說沒有限制。實際上限制還是有的，因為IP包的標識字段終究不可能無限長，按照IPv4，好像上限應該是4G(64K*64K)。依靠這種機制，TCP包頭中就沒有“包長度”字段，而完全依靠IP層去處理分幀。這就是為什么TCP常常被稱作一種“流協議”的原因，開發者在使用TCP服務的時候，不必去關心數據包的大小，只需講SOCKET看作一條數據流的入口，往里面放數據就是了，TCP協議本身會進行擁塞/流量控制。??
???
UDP則與TCP不同，UDP包頭內有總長度字段，同樣為兩個字節，因此UDP數據包的總長度被限制為65535，這樣恰好可以放進一個IP包內，使得 UDP/IP協議棧的實現非常簡單和高效。65535再減去UDP頭本身所占據的8個字節，UDP服務中的最大有效載荷長度僅為65527（好像還要減去IP頭20個字節，最后為65507）。這個值也就是
你在調用getsockopt()時指定SO_MAX_MSG_SIZE所得到返回值，任何使用SOCK_DGRAM屬性的socket，一次send的 數據都不能超過這個值，否則必然得到一個錯誤。??
???
那么，IP包提交給下層協議時將會得到怎樣的處理呢？這就取決于數據鏈路層協議了，一般的數據鏈路層協議都會負責將IP包分割成更小的幀，然后在目的端重 組它。在EtherNet上，數據鏈路幀的大小如以上幾位大俠所言。而如果是IP?? over?? ATM，則IP包將被切分成一個一個的ATM??
Cell，大小為53字節。

******************************************************************************************************************************

******************************************************************************************************************************

??? CP提供的是一種面向連接的，可靠的字節流服務，TCP提供可靠性的一種重要的方式就是MSS。通過MSS，應用數據被分割成TCP認為最適合發送的數據 塊，由TCP傳遞給IP的信息單位稱為報文段或段(segment)。代表一個TCP
socket的結構體struct tcp_sock中有多個成員用于確定應用數據被分割成最大為多大的數據塊較為合適(最大報文段長度MSS)。
??? 我們不難聯想到，跟最大報文段長度最為相關的一個參數是網絡設備接口的MTU，以太網的MTU是1500，基本IP首部長度為20，TCP首部是20，所以MSS的值可達1460(MSS不包括協議首部，只包含應用數據)。
??? 前面的TCP三次握手協議中我們看到，通訊的雙方都通過TCP選項通告了自己期望接收的MSS值，該值直接來源于struct tcp_sock的成員advmss，而這個值直接取自于網絡設備接口的MTU減去IP首部和TCP首部的長度。在本地以太網中可達1460(如果首部都
不含選項的話)。而成員rx_opt是一個結構體struct tcp_options_received，它記錄的是來自對端的TCP選項通告，其成員mss_clamp表示mss的上限值，其來源就是對端的MSS通告，而mss_user是用戶設置的mss,其優先級最高，如果有user_mss，則使用user_mss，忽略其它。
??? 從上面我們可以看到，MSS是可以通過SYN段進行協商的(MSS選項只能出現在SYN報文段中)，但它并不是任何條件下都可以協商的，如果一方不接受來 自另一方的MSS值，并且沒有user_mss，則MSS就定為默認值536字節（加上首部，允許576字節的IP數據報)。實際上，struct
tcp_sock->rx_opt->mss_clamp的初始值就定為536，等收到來自對端的MSS通告后，才進行修改。而結構體 struct tcp_sock的成員mss_cache用于緩存上次的有效的mss，其初始值也被定為536。
??? 函數mytcp_sync_mss為一個tcp socket中的mss相關的成員進行數據同步，其基本的一個算法是：
??? 1、當前的MSS正常情況下應該為mtu-IP首部-TCP首部(不包括選項)。
??? 2、structtcp_sock->rx_opt->mss_clamp中含有對端通告的能夠接受的MSS值，如果該值小于第一步計算所得到的MSS，則以該值為準。
??? 3、IP首部如果帶有IP選項，則MSS中要減去選項長度。
??? 4、如果MSS已經小于48了，則令其等于48。
??? 5、減去TCP首部中選項的長度。
??? 6、如果MSS當前已經大于滑動窗口大小的1/2，則取滑動窗口大小的1/2作為MSS值(但不能小于48)。
??? 7、成員mss_cache用于緩存下剛剛計算所得的MSS。
??? 所以，說本地以太網中MSS為1460的說法并不正確，它還會動態變化，如果IP首部和TCP首部中出現選項，則MSS要相應的減小，一般TCP首部中會有12字節的時間戳選項(外加兩字節的填充選項)，這時的MSS就等于1448。
??? MSS的主要作用是限制另一端主機發送的數據的長度，同時，主機本身也控制自己發送數據報的長度，這將使以較小MTU連接到一個網絡上的主機避免分段。
??? struct tcp_sock有一個成員xmit_size_goal，用于記錄該socket發送數據報時的segment的大小，一般情況下它的值就等于MSS(特殊情況有例外，以后再分析)。
----------------------------------------

?

以太網(IEEE 802.3)幀格式：

1、前導碼：7字節0x55,一串1、0間隔，用于信號同步

2、幀起始定界符：1字節0xD5(10101011)，表示一幀開始

3、DA(目的MAC)：6字節

4、SA(源MAC)：6字節

5、類型/長度：2字節，0～1500保留為長度域值，1536～65535保留為類型域值(0x0600～0xFFFF)

6、數據：46～1500字節

7、幀校驗序列(FCS)：4字節，使用CRC計算從目的MAC到數據域這部分內容而得到的校驗和。

以CSMA/CD作為MAC算法的一類LAN稱為以太網。CSMA/CD沖突避免的方法：先聽后發、邊聽邊發、隨機延遲后重發。一旦發生沖突，必須讓每臺主機都能檢測到。關于最小發送間隙和最小幀長的規定也是為了避免沖突。

考慮如下的情況，主機發送的幀很小，而兩臺沖突主機相距很遠。在主機A發送的幀傳輸到B的前一刻，B開始發送幀。這樣，當A的幀到達B時，B檢測到沖突，于是發送沖突信號。假如在B的沖突信號傳輸到A之前，A的幀已經發送完畢，那么A將檢測不到沖突而誤認為已發送成功。由于信號傳播是有時延的，因此檢測沖突也需要一定的時間。這也是為什么必須有個最小幀長的限制。

按照標準，10Mbps以太網采用中繼器時，連接的最大長度是2500米，最多經過4個中繼器，因此規定對10Mbps以太網一幀的最小發送時間為51.2微秒。這段時間所能傳輸的數據為512位，因此也稱該時間為512位時。這個時間定義為以太網時隙，或沖突時槽。512位＝64字節，這就是以太網幀最小64字節的原因。

512位時是主機捕獲信道的時間。如果某主機發送一個幀的64字節仍無沖突，以后也就不會再發生沖突了，稱此主機捕獲了信道。

由于信道是所有主機共享的，如果數據幀太長就會出現有的主機長時間不能發送數據，而且有的發送數據可能超出接收端的緩沖區大小，造成緩沖溢出。為避免單一主機占用信道時間過長，規定了以太網幀的最大幀長為1500。

100Mbps以太網的時隙仍為512位時，以太網規定一幀的最小發送時間必須為5.12μs。

1000Mbps以太網的時隙增至512字節，即4096位時，4.096μs。

*************************************

MTU的含義: MAC幀內的數據(Payload)字段的最大長度

??? 我們使用Ping命令時, -l參數所指定的數據包大小,是指的ICMP報文中的ICMPData字段的長度,不包括ICMPHeader,更不包括IPHeader.

以太網封裝IP數據包的最大長度是1500字節，也就是說以太網最大幀長應該是以太網首部加上1500，再加上7字節的前導同步碼和1字節的幀開始定界符，具體就是：7字節前導同步嗎＋1字節幀開始定界符＋6字節的目的MAC＋6字節的源
MAC＋2字節的幀類型＋1500＋4字節的FCS。

????按 照上述，最大幀應該是1526字節，但是實際上我們抓包得到的最大幀是1514字節，為什么不是1526字節呢？原因是當數據幀到達網卡時，在物理層上網卡要先去掉前導同步碼和幀開始定界符，然后對幀進行CRC檢驗，如果幀校驗和錯，就丟棄此幀。如果校驗和正確，就判斷幀的目的硬件地址是否符合自己的接收條件（目的地址是自己的物理硬件地址、廣播地址、可接收的多播硬件地址等），如果符合，就將幀交“設備驅動程序”做進一步處理。這時我們的抓包軟件才能抓
到數據，因此，抓包軟件抓到的是去掉前導同步碼、幀開始分界符、FCS之外的數據，其最大值是6＋6＋2＋1500＝1514。

???以 太網規定，以太網幀數據域部分最小為46字節，也就是以太網幀最小是6＋6＋2＋46＋4＝64。除去4個字節的FCS，因此，抓包時就是60字節。當數 據字段的長度小于46字節時，MAC子層就會在數據字段的后面填充以滿足數據幀長不小于64字節。由于填充數據是由MAC子層負責，也就是設備驅動程序。
不同的抓包程序和設備驅動程序所處的優先層次可能不同，抓包程序的優先級可能比設備驅動程序更高，也就是說，我們的抓包程序可能在設備驅動程序還沒有填充不到64字節的幀的時候，抓包程序已經捕獲了數據。因此不同的抓包工具抓到的數據幀的大小可能不同。下列是本人分別用wireshark和sniffer抓包的結果，對于TCP
的ACK確認幀的大小一個是54字節，一個是60字節，wireshark抓取時沒有填充數據段，sniffer抓取時有填充數據段。