TCP，UDP和IP分區

1.  IP分區

 

IP頭的一部分為

++++++++++++++++++++++++++++++++++++++++++++++++

|           16 bit  標識              | 3 bit 標誌 |  13 bit 片位移                        |

++++++++++++++++++++++++++++++++++++++++++++++++

 

對於IP層來說，收到上層（UDP/TCP）發過來的資料，會先檢查鏈路層的MTU： 1）如果 “上層資料+IP頭” 的總長度沒有超過MTU，則直接進行發送。 2）如果長度超過了MTU，則要進行分區，根據IP頭部的格式，有一個16位的標識，分區的時候會把這個標識複製到所有的分區中去，也就是說同一個IP的分區，他們的標識是一樣的；然後3bit標誌中有一位是表示是否最後一片，除了最後一片為0，其它片這個標識位都為1；修改IP的長度為分區中實際資料的長度；片位移量是該片位移未經處理資料的位置。 接收端根據 標識，是否為最後一片，各個片的長度，位移量就可以把分區的包重新組裝起來。

 

在3位標識中還有一位是表示是否允許分區，如果該位是1，而且長度又大於MTU，那麼，IP層不對資料進行分區，而是把包丟棄，然後發送一個ICMP訊息給開始端點。

 

note：

1） 經過每一個路由或網路都有可能對原來的IP包進行分區，也就是說開始端點並不清楚具體的分區情況，因為中間的過程中可能又產生了很多分區。

2） 因為分區可以選擇不同的路由，所以分區的到達順序是亂的，最後一片有可能最先到達。

3） IP分區對於傳輸層是透明的，但是如果IP的接收端收到的分區少了一片，那麼整個IP包都會被丟棄，如果上層有逾時重傳機制則發重發整個包，而不是一個分區，因為IP層本身是沒有逾時重傳機制的。

4） 任何傳輸層的部首隻會在第一個分區中出現，後續分區中是沒有的。

 

 

2.  UDP分區

 

對於UDP層來說，其實是沒有分區這個概念的，它都是整包發送，接收端整包接收的，如果發送的長度超過了限制就不能發送。

 

從理論上來說，UDP資料的總長度為 65535（IP最大長度）-20（IP頭）-8（UDP頭） = 65507個位元組，但大多數系統都達不到這個長度。這一般是受到兩個方面的因素限制：

1） API限制。一般socket的緩衝區大小是8K，但都提供API來設定緩衝區的大小（SetSockOpt）。一般發送UDP最好不要超過512位元組，這樣基本可以保證不丟包（因為大部分網路和主機的MTU都大於512）.

2） TCP/IP核心的限制。可能存在一些實現特性使得IP長度不能達到65535。

 

由於IP能夠發送或接收特定長度的資料報並不意味著接收應用程式可以讀取該長度的資料。因此，UDP編程介面允許應用程式指定每次返回的最大位元組數。如果接收到的資料報長度大於應用程式所能處理的長度，那麼會發生什麼情況呢？典型的Berkeley版socket API對資料報進行截斷，並丟棄任何多餘的資料；SVR4下的socket API(包括Solaris 2.x) 並不截斷資料報。超出部分資料在後面的讀取中返回。它也不通知應用程式從單個UDP資料報中多次進行讀取操作；TLI API不丟棄資料。相反，它返回一個標誌表明可以獲得更多的資料，而應用程式後面的讀操作將返回資料報的其餘部分。

 

 

3.  TCP分區

 

應用資料被分割成TCP認為最適合發送的資料區塊。這和 UDP完全不同，應用程式產生的資料報長度將保持不變。由 TCP傳遞給IP的資訊單位稱為報文段或段（segment）。如果一方的應用程式先傳10位元組，又傳20位元組，再傳50位元組，串連的另一方將無法瞭解發方每次發送了多少位元組。收方可以分4次接收這80個位元組，每次接收 20位元組，也可以一次性收全80個位元組。而且TCP不對內容進行解釋，對它來說都是二進位流，解釋是由應用程式層進行的。