UDP分片的問題?

時間 2021-06-02 23:01:13

1樓:gavin

IP分片指的是IP資料報大小超過資料鏈路層的最大值時會進行自動分片。

UDP包是裝在乙個IP包裡傳送的,大小不能超出乙個IP包的最大值。資料報大就拆成多個UDP傳送,這是應用層的事,跟協議層無關。

2樓:澪同學

所以data‐ grams cannot be fragmented.

是沒有問題的,因為相對TCP來說UDP的確不分片。

(3)UDP是面向報文的。傳送方的UDP對應用程式交下來的報文,在新增首部後就向下交付IP層。UDP對應用層交下來的報文,既不合併,也不拆分,而是保留這些報文的邊界。

也就是說,應用層交給UDP多長的報文,UDP就照樣傳送,即一次傳送乙個報文………………也就是說,UDP一次交付一整個報文………………

以上出自謝希仁《計算機網路》P208

當然你說的沒錯,考慮到MTU最終在網際層可能還是會分多個片,不過你似乎混淆了這裡分片的含義。

TCP分片每片都有自己的頭部,但是UDP就乙個頭部,而且TCP的分片是在運輸層而言的,所以TCP的分片是對下面三層完全透明的,網際層和鏈路層不管你運輸層是不是分片了,更不管傳輸的什麼協議的報文。

我覺得這裡不是說UDP不分片,意思就是

UDP一次交付一整個報文

題主還是應該從運輸層的角度來思考。

3樓:凡柯

這是我在看《High performance browse networking》一書時UDP那章遇到的問題,我試著解釋下。

在文中說的UDP報文不能分片(data‐grams cannot be fragmented)的意思,應該是和TCP資料報對比的,即在傳輸層的UDP報文不分片,而不是說在IP層的ip報文不分片。

原因也好理解:

簡單來說,就是乙個訊息,只能被封裝為乙個udp報文,這就是乙個整體訊息,這個訊息被拆解為多個udp報文了,那麼這個訊息實質上就失去意義了,因為udp報文間是沒有任何聯絡的。從這個層面上講的udp報文不能「分片「。

但如果這個訊息被tcp報文攜帶, 那麼這個訊息可以分為多個tcp報文,這些tcp報文在對端經過組合、排序後再形成這個訊息。這就是說tcp報文可以「分片」。

tcp報文可以分片的可行之處在於:tcp報文間是有聯絡的,每個tcp報文都有seq號,而且每個tcp報文都屬於某乙個連線,屬於同一連線上的多個tcp報文間經過seq號可以排序組裝,最終形成那個訊息。

記住一點:各個tcp報文間是有聯絡的,但各個udp報文間是無聯絡的。

4樓:祖春雷

ip分片的原因是因為鏈路層有mtu的限制,如果乙個資料報大於mtu,則需要ip分片進行傳輸。

有分片就一定有重組,重組就是只把屬於同乙個ip資料報的分片合併起來。

分片和重組主要依靠ip資料報頭中16位識別符號與3位標誌以及13位片偏移來進行。

分片不一定只發生在源端,如果中間路由裝置mtu過小,也會發生ip分片。

重組也不一定只發生在目的端,如果中間路徑上有防火牆需要完整的資料報,也是需要重組的。

tcp協議一般情況下不需要分片,因為tcp在建立連線的時候,兩端會根據路徑上mtu的狀況協商出乙個MSS,這樣就保證每次tcp協議的ip包都可以滿足路徑上的mtu傳輸,不需要分片。

不過,如果乙個承載著tcp資料的ip資料報路由到乙個mtu更加小的網路路徑上,也不得不對ip資料報進行分片傳輸。

udp協議沒有自己的傳輸控制機制,完全使用ip層提供的能力進行不可靠傳輸。與tcp流式協議不同的是,udp是有訊息邊界的,乙個udp包代表乙個完整訊息,所以udp包中資料全部傳輸完後應用層才能夠使用。

如果乙個udp資料大於mtu-28(ip包頭+udp包頭),則會發生ip分片。

因為tcp與udp都作為ip層的資料,所以在分片產生時,tcp header與udp header都在第乙個分片上。

我使用python向10.10.40.14:4000傳送節資料

zuchunlei@notebook ~ % ipython

Python 2.7.12 (default, Nov 20 2017, 18:23:56)

IPython 5.5.0 -- An enhanced Interactive Pythongt; Introduction and overview of IPython's features.

%quickref -> Quick reference.

help -> Python's own help system.

object? -> Details about 'object', use 'object??' for extra details.

In [1]: from socket import *

In [2]: sock = socket(AF_INET,SOCK_DGRAM)

In [3]: sock.sendto('1'*10000 ,('10.10.40.13',4000))

Out[3]: 10000

tcpdump可以看到分片的情況,udp header只出現在乙個ip分片中。

zuchunlei@notebook ~ % sudo tcpdump -i any host 10.10.40.13 -nn -vv

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

17:28:26.

005507 IP (tos 0x0, ttl 64, id 45186, offset 0, flags [+], proto UDP (17), length 1500)

10.10.40.103.58287 > 10.10.40.13.4000: UDP, bad length 10000 > 1472

17:28:26.

005521 IP (tos 0x0, ttl 64, id 45186, offset 1480, flags [+], proto UDP (17), length 1500)

10.10.40.103 > 10.10.40.13: ip-proto-17

17:28:26.

005526 IP (tos 0x0, ttl 64, id 45186, offset 2960, flags [+], proto UDP (17), length 1500)

10.10.40.103 > 10.10.40.13: ip-proto-17

17:28:26.

005529 IP (tos 0x0, ttl 64, id 45186, offset 4440, flags [+], proto UDP (17), length 1500)

10.10.40.103 > 10.10.40.13: ip-proto-17

17:28:26.

005533 IP (tos 0x0, ttl 64, id 45186, offset 5920, flags [+], proto UDP (17), length 1500)

10.10.40.103 > 10.10.40.13: ip-proto-17

17:28:26.

005540 IP (tos 0x0, ttl 64, id 45186, offset 7400, flags [+], proto UDP (17), length 1500)

10.10.40.103 > 10.10.40.13: ip-proto-17

17:28:26.

005543 IP (tos 0x0, ttl 64, id 45186, offset 8880, flags [none], proto UDP (17), length 1148)

10.10.40.103 > 10.10.40.13: ip-proto-17

udp檔案傳輸的問題,採用nack,怎麼處理最後幾個包丟失的情況

ggffss kcp 作者說的很清楚了,KCP是為了低延遲而生。例如流式傳輸等等。講道理用Kcp就是為了低延遲。所以。這些功能都有些多餘。傳輸效率Kcp就segment的報頭就至少是32位元組了。怎麼和TCP的20位元組比? SakyaZhu 可以考慮用飛馳傳輸的產品 http ftrans.cn ...

UDP提供的是無連線服務,那麼剛開始,UDP協議傳送方怎麼知道接收方的目的埠?

UDP是不可靠資料報的協議,決定資料是以不可靠資料報的形式被傳送的。與其對應的最典型的就是TCP,可靠的傳輸通訊協議。從這些語句能看出,無論是TCP還是UDP 傳輸層,四層協議 都是決定資料是以何種形式傳送的。但是決定要不要傳送的,是需要更上層的 應用 決定的。最典型的使用UDP協議傳輸的上次協議有...

UDP 和 TCP 的 socket 分別一般用在什麼地方?

硬體工程師 大家說的很全面了,我將乙個必須用UDP的例子。在某些情況下,使用UDP是因為它允許廣播資料報。在像DHCP協議這樣的情況下,因為客戶機還沒有收到IP位址 這是DHCP協商協議的目的 沒有IP位址本身就無法建立TCP連線。In certain situationsUDPis used be...