遇到的問題：以太網的數據幀封裝如下圖所示,包含在IP數據報中的數據部分最長應該是( )字節？
A.1434
B.1460
C.1480
D.1500
答案:C
原因：
以太網(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。
IP數據包長度問題總結
TCP/IP協議，涉及到四層：鏈路層、網絡層、傳輸層、應用層。
其中以太網的數據幀在鏈路層
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包中的數據多於1472時，發送方的IP層需要分片fragmentation進行傳輸，而在接收方IP層則需要進行數據報重組，由於UDP是不可靠的傳輸協議，如果分片丟失導致重組失敗，將導致UDP數據包被丟棄。）
從上面的分析來看，普通的局域網環境下，UDP的數據最大是1472字節最好，避免分片重組。
但是在網絡編程中，Internet中的路由器可能設置成不同的值（小於默認值），Internet上的標准MTU值為576，所以Internet的UDP編程時的數據長度最好在576 - 20 -8 = 548字節以內。
Mac OS點擊系統偏好設置——網絡——高級——硬件可以查看本機的MTU設置。
IP數據包的最大長度是64K字節（2^16 -1），因為在IP包頭中用2個字節描述報文長度，2個字節所能表示的最大數字就是2^16-1 = 65536 -1 = 65535.
由於IP協議提供為上層協議分割和重組報文的功能，因此傳輸層協議的數據包長度原則上來說沒有限制。實際上限制還是有的，因為IP包的標識字段終究不可能無限長，按照IPv4，上限是2^32=4G字節。依照這種機制，TCP包頭中就沒有“包長度”字段，而完全依靠IP層去處理分幀。這就是為什么TCP常常被稱作一種“流協議”的原因，開發者在使用TCP服務的時候，不必關心數據包的大小，只需要將SOCKET看作一條數據流的入口，往里面放數據就是了，TCP協議本身會進行擁塞/流量控制。
UDP則和TCP不同，UDP包頭內有總長度字段，同樣為2個字節，因此UDP數據包的總長度被限制為(2^16-1)，這樣恰好可以放進一個IP包內，使得UDP/IP協議棧的實現非常簡單高效。65535再減去UDP頭本身所占據的8個字節，UDP服務中的最大有效負載長度僅為65527.這個值也就是調用getsockopt()時指定SO_MAC_MSG_SIZE所得到的返回值，任何使用SOCK_DGRAM屬性的socket,一次send的數據都不能超過這個值，否則必然得到一個錯誤。
那么，IP包提交給下層協議時將會得到怎樣的處理呢？取決於數據鏈路層協議，一般得到數據鏈路層協議都會負責將IP包分割成更小的幀，然后在目的端重組它，在EtherNet上，數據鏈路幀的大小如開篇所述。而如果是IP over ATM,則IP包將被切分成一個一個的ATM Cell，大小為53字節。