Jaki jest największy rozmiar bezpiecznego pakietu UDP w Internecie

201

Przeczytałem wiele artykułów o rozmiarach pakietów UDP, ale nie byłem w stanie dojść do wniosku, co jest poprawne.

Wiele usług ogranicza największy pakiet UDP do 512 bajtów (jak dns)

Biorąc pod uwagę, że minimalna MTU w Internecie wynosi 576, a rozmiar nagłówka IPv4 wynosi 20 bajtów, a nagłówek UDP 8 bajtów. To pozostawia 548 bajtów dostępnych dla danych użytkownika

Czy byłbym w stanie używać pakietów do rozmiaru 548 bez fragmentacji pakietów? Czy jest coś, o czym wiedzieli twórcy DNS i dlatego ograniczyli go do 512 bajtów.

Czy mogę bezpiecznie przekroczyć 548 bajtów?

— KM
źródło

2

Duplikat, patrz stackoverflow.com/questions/900697/…

— ChrisW

10

To nieco inne pytanie. Pytam, jaki jest największy pakiet, jaki mogę wysłać przez Internet (bez znajomości innych sieci lub sondowania), który nie będzie miał fragmentacji. Zasadniczo maksymalny bezpieczny rozmiar, który będzie działał na evereything bez martwienia się o sondowanie połączenia.

— KM

2

Nie możesz wyeliminować możliwości fragmentacji, ale to nie czyni rzeczy mniej bezpiecznymi. Jeśli fragment zostanie upuszczony, będzie to tak samo, jakby cały pakiet został upuszczony, co zresztą dzieje się w przypadku UDP. Niebezpieczne byłoby, gdyby pakiet przekroczył minimalny rozmiar obsługiwany przez routery, a tym samym nie można zagwarantować dostarczenia (w porównaniu z gwarancją dostarczenia). W tym momencie pojawia się 512-bajtowa liczba.

— Beejor

129

Prawdą jest, że typowy nagłówek IPv4 ma 20 bajtów, a nagłówek UDP ma 8 bajtów. Możliwe jest jednak włączenie opcji IP, które mogą zwiększyć rozmiar nagłówka IP do nawet 60 bajtów. Ponadto czasami konieczne jest, aby węzły pośrednie hermetyzowały datagramy wewnątrz innego protokołu, takiego jak IPsec (używany dla VPN i tym podobnych), aby skierować pakiet do miejsca docelowego. Jeśli więc nie znasz MTU na konkretnej ścieżce sieci, najlepiej zostawić rozsądny margines na inne informacje nagłówkowe, których być może nie spodziewałeś się. Uważa się, że robi to 512-bajtowy ładunek UDP, chociaż nawet to nie pozostawia dość miejsca na nagłówek IP o maksymalnym rozmiarze.

— mark4o
źródło

36

Żeby było jasne: posiadanie małego rozmiaru w celu uniknięcia fragmentacji nie sprawia, że dostarczanie pakietu jest „bezpieczne”, wciąż istnieje nieskończona ilość możliwości, które powodują, że dostarczanie jest niewiarygodne, np. Pies zjada mój kabel sieciowy. To mówi; posiadanie mniejszej liczby fragmentów sprawia, że dostarczanie jest „bezpieczniejsze”, ponieważ jeśli było ich więcej, a żaden z nich nigdy tego nie zrobił - cały pakiet (datagram) jest odrzucany przez UDP.

— markmnl

3

Na potrzeby pytania zakłada się, że używa się definicji plakatu „bezpieczny”, a nie jakiejś definicji z jakiejś normy, której nigdy nie widzieli.

— Astara,

Czy znane są routery w świecie rzeczywistym, które upuszczają pakiety UDP zamiast je fragmentować?

— user253751,

60

Teoretyczny limit (w systemie Windows) maksymalnego rozmiaru pakietu UDP wynosi 65507 bajtów. Jest to udokumentowane tutaj :

Prawidłowy maksymalny rozmiar wiadomości UDP to 65507, zgodnie z następującą formułą: 0xffff - (sizeof (nagłówek IP) + sizeof (nagłówek UDP)) = 65535- (20 + 8) = 65507

To powiedziawszy, większość protokołów ogranicza się do znacznie mniejszego rozmiaru - zwykle 512 lub sporadycznie 8192. Często możesz bezpiecznie przekroczyć 548, jeśli jesteś w niezawodnej sieci - ale jeśli transmitujesz w Internecie, im większy idziesz, tym bardziej prawdopodobne jest, że będziesz mieć problemy z transmisją pakietów i utratą.

— Reed Copsey
źródło

39

Łącze Microsoft nie jest odniesieniem normatywnym. RFC są normatywnym odniesieniem; a to, co zacytowałeś, dotyczy tylko IPv4.

— Markiz Lorne

2

To, że MS pozwala, nie oznacza, że zawsze jest to dobry pomysł, ponieważ routery pośrednie itp. Mogą zostać zmuszone do fragmentacji większych rozmiarów pakietów (jak wspomniałeś).

— rogerdpack,

1

@EJP Nie wyjaśniają tego wyraźnie w łączu Microsoft, ale wydaje się, że jest to niezbędna konsekwencja IPv4: Pole całkowitej długości IPv4 ma 16 bitów, a wartość ta musi obejmować długość nagłówka IP i długość Nagłówek UDP.

— jtpereyda

@jtpereyda Jestem tego w pełni świadomy. Chodzi mi dokładnie o to, co już powiedziałem: powinieneś cytować odniesienia normatywne tam, gdzie istnieją.

— Markiz Lorne

Nie sądzę, aby maksymalny rozmiar pakietu UDP wynosiłby kiedykolwiek 65 507 bajtów, biorąc pod uwagę, że moja karta Wi-Fi (IEEE 802.3) może zrobić tylko 1500 MTU, a duże ramki mają tylko 9k bajtów.

— Christian Stewart,

52

Maksymalny bezpieczny ładunek UDP wynosi 508 bajtów. Jest to rozmiar pakietu 576, minus maksymalny 60-bajtowy nagłówek IP i 8-bajtowy nagłówek UDP. Każda ładunek UDP tego rozmiaru lub mniejszy ma gwarancję dostarczenia przez IP (choć nie gwarantuje się, że zostanie dostarczony). Z dowolnego powodu dowolny router może zostać zrzucony przez dowolny router. Z wyjątkiem trasy tylko IPv6, gdzie maksymalna ładowność wynosi 1212 bajtów. Jak wspomnieli inni, w niektórych okolicznościach mogą zostać dodane dodatkowe nagłówki protokołu. Zamiast tego może być preferowana bardziej konserwatywna wartość około 300-400 bajtów.

Każdy pakiet UDP może być pofragmentowany. Nie jest to jednak zbyt ważne, ponieważ utrata fragmentu ma taki sam efekt jak utrata niefragmentowanego pakietu: cały pakiet jest odrzucany. W przypadku UDP stanie się tak w obu przypadkach.

Co ciekawe, maksymalny teoretyczny rozmiar pakietu wynosi około 30 MB (1500 MTU sieci Ethernet - 60 nagłówków IP x 65 536 maksymalnej liczby fragmentów), choć prawdopodobieństwo jego przedostania się byłoby nieskończenie małe.

Źródła: RFC 791, RFC 2460

— Beejor
źródło

2

Każdy pakiet UDP jest domyślnie uważany za „_U_niedawny”. Jedynym bezpiecznym rozmiarem pakietu UDP, którego można się spodziewać, będzie 1, niefragmentowany pakiet. Jeśli chcesz „bezpiecznych” pakietów, użyj protokołu pakietów na górze TCP.

— Astara,

26

@Astara Prawda, z natury UDP jest zawodna. Ale pytanie brzmi, czy paczka o danym rozmiarze ma gwarancję dostarczenia, czy nie. Pakiety o określonym rozmiarze mogą być (i są) upuszczane przez dowolny router z dowolnego powodu, podczas gdy mniejsze muszą być obsługiwane przez wszystkie routery, zgodnie ze standardami branżowymi. Zatem „bezpieczny” w tym przypadku oznacza „czy mój samochód zmieści się pod mostem”, a nie „czy mój samochód utknie w korku”.

— Beejor,

1

Polecam przestać powtarzać to, co powiedział jakiś przypadkowy facet i sprawdzić fakty, ponieważ UDP jest w rzeczywistości całkiem niezawodny. BTW Mam bezpieczne pakiety na UDP bez zbędnego narzutu TCP. openmymind.net/How-Unreliable-Is-UDP

— Pablo Ariel

5

UDP nie jest „zawodny” z powodu ilości upuszczonych pakietów, ale ponieważ pakiety mogą być (i są) upuszczane. Nie można „polegać” na dostawie, zamówieniu lub potwierdzeniu konkretnego pakietu. Dane są delikatne i przypomina to, że kierowanie samochodem, które działa przez 99% czasu, a 89% we właściwym kierunku, jest niezawodne. Nie oznacza to, że UDP nie jest świetny do wielu rzeczy, po prostu wymaga, aby napisać na nim własną wersję „TCP”. Oto fascynująca rzeczywistość w świecie deweloperów (choć nieco przestarzała): gamasutra.com/view/feature/131781

— Beejor

@Beejor Podążałeś właściwą ścieżką, ale „to wymaga, aby napisać własną wersję„ TCP ”na szczycie” jest rażąco błędne. UDP doskonale nadaje się do nadawania i nadaje się do szybkiego wysyłania „niekrytycznych” danych. (W odniesieniu do gier) możesz odkrywać serwery / usługi (LAN) za pomocą UDP i używać UDP do szybkiego wysyłania lokalizacji odtwarzacza. Jeśli jeden pakiet jest upuszczany; nie obchodzi cię to, ponieważ następny pakiet będzie zawierał bardziej aktualną lokalizację innych graczy. TCP może mieć pakiety „poza kolejnością”, ma narzut i nie do końca wykonuje połączenia jeden do wielu. W niektórych przypadkach UDP może mieć większe zastosowanie.

— Paul

46

576 to minimalny maksymalny rozmiar bufora ponownego składania , tzn. Każda implementacja musi mieć możliwość ponownego złożenia pakietów co najmniej tego rozmiaru. Szczegółowe informacje można znaleźć w IETF RFC 1122 .

— użytkownik607811
źródło

2

Jeśli i tylko jeśli masz sieć, która nie obsługuje IPv6. Jeśli przenosi IPv6, użyj maksymalnego rozmiaru pakietów nagłówków IPv6, a następnie odejmij nagłówki enkapsulacji, aby wykonać IPv4 przez IPv6. ;-)

— Astara,

@Astara W IPv6 nadawca dokonuje fragmentacji, więc nie ma problemu z podejrzanymi niezgodnymi routerami pośrednimi. A jeśli odbiorca nie ma ograniczonego rozmiaru pamięci, może prawdopodobnie ponownie złożyć pakiety o wielkości co najmniej 64 kB.

— user253751,

@ user253751 To nie tylko niezgodne routery mogą się fragmentować. Istnieje ścieżka MTU Discovery, ale nawet to nie wystarczy, aby całkowicie wyeliminować fragmentację.

— dstromberg

@dstromberg W jakich sytuacjach routery IPv6 mogą fragmentować datagramy?

— user253751

@ user253751 Nie mam jeszcze dużo IPv6, ale oto jeden przykład: wyobraź sobie sieć IPv6 wysyłającą jumbogramy (> 65536 bajtów) do innej sieci IPv6, która również obsługuje jumbogramy. Ponadto załóżmy, że Path MTU Discovery mówi, że te jumbogramy powinny być obsługiwane bez fragmentacji. Ale potem router zostaje wyłączony i część ścieżki sieciowej zostaje zastąpiona sprzętem, który nie jest skonfigurowany dla jumbogramów.

— dstromberg,

14

W tym artykule opisano maksymalną jednostkę transmisji (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit . Stwierdza, że hosty IP muszą być w stanie przetworzyć 576 bajtów na pakiet IP. Zwraca jednak uwagę, że minumum to 68. RFC 791: „Każdy moduł internetowy musi być w stanie przesłać datagram 68 oktetów bez dalszej fragmentacji. Wynika to z faktu, że nagłówek internetowy może mieć do 60 oktetów, a minimalny fragment to 8 oktetów . ”

Zatem bezpieczny rozmiar pakietu 508 = 576 - 60 (nagłówek IP) - 8 (nagłówek udp) jest rozsądny.

Jak wspomniano przez użytkownika 607811, fragmentacja według innych warstw sieciowych musi zostać ponownie złożona. https://tools.ietf.org/html/rfc1122#page-56 3.3.2 Ponowny montaż Warstwa IP MUSI realizować ponowny montaż datagramów IP. Wyznaczamy największy rozmiar datagramu, który może być ponownie złożony przez EMTU_R („Efektywna MTU do odbioru”); jest to czasami nazywane „rozmiarem bufora ponownego montażu”. EMTU_R MUSI być większy lub równy 576

— edW
źródło

11

Minimalny rozmiar bufora ponownego składania IPv4 to 576, IPv6 ma to 1500. Odejmij rozmiary nagłówków. Zobacz programowanie sieciowe UNIX W. Richarda Stevensa :)

— Nikołaj Fetissow
źródło

1

Oczywiście minimum. Dzięki za wykrycie tego. Nie mam pojęcia, jak przez lata nikt nie zauważył błędu.

— Nikolai Fetissov

1

Podczas gdy IPv6 może mieć minimalny bufor ponownego składania wynoszący 1500, pakiety IPv6 nie mogą być fragmentowane, a minimalna MTU IPv6 to 1280. Urządzenie końcowe nigdy nie powinno wymagać ponownego składania pofragmentowanego pakietu IPv6.

— Ron Maupin

1

@RonMaupin Pakiety IPv6 mogą być pofragmentowane według punktów końcowych. Tylko nie przez routery pomiędzy.

— Navin,

3

@Navin, nie, pakiety IPv6 nie zostaną pofragmentowane, dane muszą zostać pofragmentowane, zanim zostaną spakowane w pakiety IPv6, ale same pakiety nie zostaną pofragmentowane. Jest różnica. W przeciwieństwie do nagłówków pakietów IPv4, które mają pola do radzenia sobie z fragmentacją, nagłówki pakietów IPv6 nie mają nic wspólnego z fragmentacją. Nagłówek pakietu IPv6 jest znacznie prostszy niż nagłówek pakietu IPv4.

— Ron Maupin,

6

512 jest najlepszym wyborem. Jest używany gdzie indziej i jest ładną liczbą parzystą (połowa 1024).

— Justin Niessner
źródło

6

Biorąc pod uwagę, że IPV6 ma rozmiar 1500, zapewniłbym, że przewoźnicy nie zapewnią oddzielnych ścieżek dla IPV4 i IPV6 (oba są IP z różnymi typami), zmuszając ich do urządzeń dla IPv4, które byłyby stare, nadmiarowe, bardziej kosztowne w utrzymaniu i mniej niezawodny. To nie miałoby sensu. Poza tym robienie tego można łatwo uznać za preferencyjne traktowanie niektórych rodzajów ruchu - zgodnie z zasadami, na których prawdopodobnie nie dbają zbytnio (chyba że zostaną złapani).

1472 powinien więc być bezpieczny do użytku zewnętrznego (choć nie oznacza to, że aplikacja taka jak DNS, która nie wie o EDNS, zaakceptuje go), a jeśli mówisz o wewnętrznych sieciach, bardziej prawdopodobne jest, że znasz układ sieci. Wielkie rozmiary pakietów dotyczą pakietów niepodzielonych na fragmenty, czyli 4096 - 4068 bajtów, a także kart Intel z buforami 9014 bajtów, rozmiar pakietu ... czekaj ... 8086 bajtów, czy byłby to maksymalny ... zbieg okoliczności? chichot

****AKTUALIZACJA****

Różne odpowiedzi dają maksymalne wartości dozwolone przez 1 dostawcę oprogramowania lub różne odpowiedzi zakładające hermetyzację. Użytkownik nie poprosił o najniższą możliwą wartość (np. „0” dla bezpiecznego rozmiaru UDP), ale największy bezpieczny rozmiar pakietu.

Wartości enkapsulacji dla różnych warstw można dołączyć wiele razy. Odkąd po enkapsulacji strumienia - nic nie stoi na przeszkodzie, powiedzmy, warstwa VPN poniżej i całkowite powielenie warstw enkapsulacji powyżej.

Ponieważ pytanie dotyczyło maksymalnych bezpiecznych wartości, zakładam, że chodzi o maksymalną bezpieczną wartość pakietu UDP, który można otrzymać. Ponieważ nie jest gwarantowany żaden pakiet UDP, jeśli otrzymasz pakiet UDP, największy bezpieczny rozmiar to 1 pakiet w IPv4 lub 1472 bajtów.

Uwaga - jeśli używasz IPv6, maksymalny rozmiar wynosiłby 1452 bajtów, ponieważ rozmiar nagłówka IPv6 wynosi 40 bajtów w porównaniu z 20-bajtowym rozmiarem IPv4 (w obu przypadkach nagłówek UDP musi nadal pozwalać na 8 bajtów).

— Astara
źródło

1

jak obliczasz 1472? Ethernet ma MTU 1500, czy o to ci chodzi?

— rogerdpack

4

@rogerdpack Myślę, że ma na myśli to, że ponieważ IPv4 i IPv6 prawdopodobnie mają wspólną infrastrukturę, a IPv6 staje się stosunkowo popularny, należy bezpiecznie przyjąć limity IPv6 (a więc 1500). Jednak jak uzasadnione jest to rozumowanie, nie mogę powiedzieć.

— Thomas

2

1500 musi być wspierane przez komponenty kompatybilne z IPv6 w „łańcuchu” sieci - jeśli ktoś używa IPv4, który może podróżować przez łańcuch obsługujący IPv6 (choć odwrotność nie jest prawdą), ponieważ rozmiar nagłówka IPv4 wynosi 20 bajtów, i Rozmiar nagłówka UDP wynosi 8 bajtów, co pozostawiłoby 1500-20-8 = 1472 jako maksymalny bezpieczny rozmiar (ponieważ IPv6 nie pozwala na fragmentację). Uwaga - jeśli ludzie dodadzą wystarczającą liczbę warstw enkapsulacji, możliwe, że nie ma miejsca na DANE. Ponieważ poprosiłeś o MAX, zakładasz, że NIE będzie używanych wiele warstw narzutu enkapsulacji.

— Astara,

„ 1500 musi być wspierane przez komponenty kompatybilne z IPv6 w łańcuchu sieci. ” Nie, minimalna MTU IPv6 to 1280. Ethernet MTU to 1500.

— Ron Maupin

@RonMaupin - oryginalny Q był największym bezpiecznym rozmiarem pakietu UDP, a nie MTU. Zobacz RFC2460. Oprócz wzmianki o MTU 1280 oktetów, stwierdza: Węzły muszą być w stanie zaakceptować pofragmentowany pakiet, który po ponownym złożeniu ma do 1500 oktetów. Obsługa pakietów większych niż 1500 jest opcjonalna.

— Astara,

6

Przeczytałem tutaj kilka dobrych odpowiedzi; są jednak drobne błędy. Niektórzy odpowiedzieli, że pole Długość wiadomości w nagłówku UDP wynosi maksymalnie 65535 (0xFFFF); jest to technicznie prawdą. Niektórzy odpowiedzieli, że faktyczne maksimum wynosi (65535 - IPHL - UDPHL = 65507). Błąd polega na tym, że pole Długość komunikatu w nagłówku UDP zawiera cały ładunek (warstwy 5-7) plus długość nagłówka UDP (8 bajtów). Oznacza to, że jeśli pole długości wiadomości wynosi 200 bajtów (0x00C8), ładunek to w rzeczywistości 192 bajty (0x00C0).

Trudne i szybkie jest to, że maksymalny rozmiar datagramu IP wynosi 65535 bajtów. Ta liczba jest uzyskiwana jako suma sumy nagłówków L3 i L4, plus ładunek warstw 5-7. Nagłówek IP + nagłówek UDP + warstwy 5-7 = 65535 (maks.)

Najbardziej poprawną odpowiedzią na maksymalny rozmiar datagamu UDP jest 65515 bajtów (0xFFEB), ponieważ datagram UDP zawiera nagłówek UDP. Najbardziej poprawną odpowiedzią na maksymalny rozmiar ładunku UDP jest 65507 bajtów, ponieważ ładunek UDP nie zawiera nagłówka UDP.

— Wieprz
źródło

1

Nie odpowiedziałeś na pytanie. Pytający chciał wiedzieć, jaki był największy rozmiar, jakiego mogli użyć, aby uniknąć fragmentacji pakietu.

— Astara,

0

Obawiam się, że wywołuję zdenerwowane reakcje, ale dla wyjaśnienia mi, czy się mylę, czy też widzących to pytanie i zainteresowanych odpowiedzią:

moje rozumienie https://tools.ietf.org/html/rfc1122 którego status to „oficjalna specyfikacja” i jako takie stanowi odniesienie do terminologii stosowanej w tym pytaniu i która nie jest ani zastąpiona przez inne RFC, ani nie ma sprzecznych z następujący:

teoretycznie tj. na podstawie zapisanej specyfikacji. UDP, taki jak podany przez https://tools.ietf.org/html/rfc1122#section-4, nie ma „rozmiaru pakietu”. Zatem odpowiedź może być „nieokreślona”

W praktyce, o to prawdopodobnie chodziło o te pytania (i które można by zaktualizować w związku z obecną technologią w akcji), może być inaczej i nie wiem.

Przepraszam, jeśli spowodowałem zdenerwowanie. https://tools.ietf.org/html/rfc1122#page-8 „Internet Protocol Suite” i „Architectural Assumptions” nie wyjaśniają mi „założenia”, na którym się opierałem, w oparciu o to, co słyszałem, że te warstwy są oddzielone . To znaczy. warstwa, w której znajduje się UDP, nie musi zajmować się warstwą, w której jest IP (a warstwa IP zawiera takie rzeczy, jak Reassembly, EMTU_R, Fragmentation i MMS_R ( https://tools.ietf.org/html/rfc1122#page- 56 ))

— użytkownik5588495
źródło

1

Nagłówek UDP ma pole długości datagramu, które wynosi 16 bitów, co oznacza, że największy teoretyczny datagram UDP ma 65 535, ale nigdy nie można go osiągnąć, ponieważ UDP jest zamknięty w pakiecie IP, który ma teoretyczną całkowitą maksymalną długość 65 535 ( to samo), ale musisz odjąć nagłówki IP i UDP od tego rozmiaru, aby obliczyć teoretyczny maksymalny rozmiar danych.

— Ron Maupin

Zapytałem o to dawno temu, ale szukało ono pragmatycznej odpowiedzi (co działa w prawdziwym życiu), a nie tego, co jest napisane w specyfikacji / lub w teorii. Chciałem uzyskać pakiety od a do b bez fragmentacji, dotyczyło to problemu sieci z grami w czasie rzeczywistym - myślę, że istnieje wiele rozwiązań opracowanych przez mądrzejszych ludzi :)

— KM