以前總覺得類似IP和UDP在報文長度上應該是32位長度的，近期討論媒體流某些比較大的幀爲什麼會被分片時，和同事討論後深入地看了下協議，才發現報文長度確實只有16位。
我們知道IP包是因特網的精靈，它是網絡傳輸的基本單位。對於這個基本單位受限於網絡特質既存在最小報文限制也存在最大報文限制。IP報文的分片，在網絡層提供了基本能力能夠完成IP報文的組裝。這樣，我們可以認爲，無論是TCP還是UDP，從網絡側得到的最小數據包就是單個IP包。所以，TCP一次讀取socket操作能夠讀取多個字節，跟IP包的累積和IP包到的時機相關。UDP被稱爲數據報協議，我猜想的一個原因，就是源端儘量按照一個IP包進行承載，實在不行就發生IP分片，然後在目的段再次組成一個完整的IP包投送給UDP，在UDP協議頭上並不支持UDP包的分片，所以，一次UDP數據發送，應該是小於65535個字節，大致64K。（至於應用層的分包，就是後續要講到的幀分片）
我們在在處理流媒體的時間，一個完整的幀被收到，才能放到解碼器中進行解碼。當然我們也就自然地希望在流媒體的源端，最好就是按照一幀一幀發送，但是我們知道流媒體編解碼算法，都是會產生好幾種類型的幀，而其每個幀的大小，也不盡相同，有的幀類型的大小甚至是別的幀的好多倍。雖然視頻編碼部分，可以一次行地輸出一幀數據，但是傳輸層，需要應對一些技術考慮(大報文丟失，誤碼率等)以及網絡IP報文的基本限制(16位長度)，一包一幀，基本上很難，源端需要處理幀分片有關的邏輯。