目錄
-
IPv4協議
先看一個流傳得比較多的圖，這裏直入主題，只說與分片相關的字段。
標識(identification):佔16位。IP軟件在存儲器中維持一個計數器，每產生一個 數據報，計數器就加1,並將此值賦給標識字段。
標誌(flag):佔3位，但目前只有兩位有意義。最低位記爲MF (More Fragment)。MF = 1即表示後面“還有分片” 的數據報。MF = 0表示這已是若千數據報片中的最後一個。標誌字段中間的一位記爲DF (Don’t Fragment),意思是“不能分片”。只有當DF = 0時才允許分片。
片偏移 :佔13位。片偏移指出：較長的分組在分片後，某片在原分組中的相對 位置。也就是說，相對於用戶數據字段的起點，該片從何處開始。片偏移以8個字節爲偏移 單位。這就是說，每個分片的長度一定是8字節（64位）的整數倍。
總長度:總長度指數據報的長度，單位爲字節。總長度字段爲16位，因此數據報的最大長度爲2^16 - 1 = 65535字節。然而實際上傳送這樣長的數據報在現實中 是極少遇到的。
UDP單個數據包的長度由於總長度的原因，不會超過65535字節。而由於MTU的原因，udp數據包超過某一長度（爲MTU的值，通常爲1500字節）後，會分片傳輸。
舉個例子，主機A向主機B發送一個長度爲8000字節的udp數據包，假設mtu爲1500，那麼數據報將會如何分片傳送呢？
假設MTU是1500，實際上每個數據包要包括20字節固定大小的IP頭開銷，且第一個分片需要包括UDP協議頭（8字節），其它分片只需要僞首部即可。所以實際的數據分片載荷爲首包1472字節，中間6包1480字節，尾包608字節。
接收端根據包標識+片偏移組包，源地址與標識相同的認爲是同一個數據包，使用片偏移排序，最後使用第一個包的udp頭校驗和檢驗數據正確性，如果通過校驗，則分片組包成功，數據包通知到應用層。如果分片包超過一段時間未完整組包，或是校驗不通過，則數據丟棄。
分片可能引起的問題
由於包標識字段是自增的，所以這個驗證是不會有問題，乍一看，感覺簡直完美。
而實際上，標識字段只有16位，最多隻能表示65536個不同的udp數據包。假設分片組包超時的時間爲t秒，那麼t秒內，如果發送的udp數據包超過了65536會出現什麼問題呢？
當然，正常情況下是不會有問題的，我們假設一種異常的情況，一個udp包被分成了兩個分片，在包標識爲N的時候，分片1沒有被接收端接收到，分片2接收到並保留在接收端的內存中，等待超時時間t秒內，又接收到不一樣的數據，而標識爲N的分片1，這時內存中第一次接收到的分片2就與第二次接收到的分片1組包。由於數據本身不一致，udp校驗和不通過，該包丟棄。接下來第二次的分片2又停留在內存中，等待已經被丟棄並永遠不會到來的正確的分片1，超時時間又從0開始計時。假設數據發送端一直以相同的速率發送數據，那麼第二次分片2等待到的只會是第三次的分片1，然後丟棄。第三次的分片2等待到第四次的分片1，丟棄。。。。。。如此便是一個惡性循環。標識爲N的數據包永遠都是一個結果：被丟棄。
有人會覺得這不是一個問題，你把超時時間t設置小一點不就萬事大吉了嗎？然而很不幸，windows 2000之後的內核都是對t值是硬編碼，t=60秒，不可改變。
所以如果不是特殊需求的話，最好不要讓udp數據包的長度超過mtu的值。如果不得不這樣做的話，還有另外一種方法，可以在特定環境下曲線解決這個問題。這裏就不詳細說明了。
還有另一種情況， 當別有用心的客戶端每次發送一個不完整的分片到指定windows服務器，服務器一直等待超時，那麼服務器內存能否撐滿呢？（以下僅爲理論上的推測，未進行相關的測試。）
假設一個數據包是1514字節（mtu1500字節+14字節數據鏈路頭）。一個發送端理論上至少可在60秒內發送65535個不同標識的不完整數據包（或多個同一個標識的不完整分片。65535*（（最大UDP數據長度）%（MTU）個）,所以最多能發送4266459570字節≈4GB的數據，這些數據是常駐內存的。理想情況下，只需要16個不同的客戶端，就能對一個開放了UDP端口的且內存64GB以下的Windows 2000以上版本的服務器進行拒絕服務攻擊。
當然，這只是理想情況。實際呢，服務器可能設置了不允許udp分片，或者udp緩存本身很小、網絡丟包、帶寬限制、防火牆等因素也可能導致了攻擊不可行。
[經過2018-12-31實際測試win7 x64系統，使用大量分片並不會導致目標系統的內存暴漲或宕機，而對網絡佔用和CPU的增長是存在的。所以此類攻擊在新版系統中的影響是有限的]
參考文章
歡迎提問
