Asi me unikla pointa.
Poslu dlouhej paket, ten se cestou rozseka na kratsi a na konci ho prislusna vrstva slozi. Tak v cem je problem? (Ze nejaky fragment dorazi pozde nebo nebo nedorazi vubec? To ale asi neni problem MTU...?)
Priznam se, ze s tim nemam zadnou praktickou zkusenost. (Jenom kdysi jsem programoval jednoho brouka, ve kterem jsem mel v pameti misto asi tak na ctyri pakety o cca 800 bajtech. Ale posilal jsem kratsi pakety, takze s tim fakt zkusenost nemam.)
Problém je, že u IPv6 žádná fragmentace neexistuje. Tím se výrazně zjednodušuje implementace směrování. Pokud velký paket dorazí na úzké hrdlo, router ho zahodí a pošle ICMP zprávu packet too big. Jestliže je ale po cestě zablokované ICMP (obvykle z pochybných bezpečnostních důvodů), pak tato zpráva nedorazí a je tma. Vy nevíte, co se děje, prohlížeč (třeba) točí a točí a nikdy nedotočí, protože netuší, že je něco špatně.
A ještě bych dodal (ale je to napsané v článku), že se to týká nejen IPv6, ale i IPv4, protože naprostá většina dnešních TCP/IP stacků posílá IPv4 datagramy s nastaveným příznakem DF.
A ještě mimochodem, na linuxu můžete staré chování s vypnutým příznakem DF vyvolat příkazem:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
Dekuji vsem za odpovedi, ale jeste chvili budu predstirat (nebo taky ne) hloupeho a furt to nechapu.
IPv6 ted neresim (to je v moji profesi daleka budoucnost), ale kdo a proc ma potrebu u IPv4 vypinat fragmentaci?
U TCP to nechapu vubec. Vzdyt prece tim, ze se (aplikacni) programator rozhodne pouzit TCP, tak od toho v podstate dava ruce pryc se slovy "delejte si s tim cestou, co chcete, hlavne at do dorazi neporuseny a ve spravnem poradi".
A u UDP uz programator tak nejak pocita s tim, ze se cestou muze stat cokoliv. A kdyz se boji, tak bude odesilat minimalni pakety, aby to proslo vzdycky.
> ale kdo a proc ma potrebu u IPv4 vypinat fragmentaci?
Bezne TCP/IP implementace v operacnich systemech standardne vypinaji fragmentaci u TCP paketu (flagem do not fragment) prave proto, ze fragmentace u TCP nema moc smysl - je lepsi rovnou ten proud dat od aplikace rozdelit do optimalne velkych TCP paketu, nez ho rozdelit do zbytecne moc velkych TCP paketu a ty nasledne po ceste nechat fragmentovat.
(Opet dekuji za odpoved. Prestoze me otazky nejspis vypadaji jako provokace, tak diky teto a podobnym diskuzim si "doplnuji vzdelani".)
Jenze pak se musi resit, co je "optimalne velke", protoze pro ruzne useky cesty je to optimum jine. Navic v case se muzou zmenit i useky cesty.
V pořádku :). Vzhledem k tomu, že IP je paketová síť, tak je nutné poslat paket, který se vejde po celé cestě. Je tedy potřeba zjistit optimum (maximální velikost) pro trasu jako celek.
Navíc typicky nejvíc zdržují úseky s nižším MTU (i když to tak nemusí být), takže i kdyby kritické uzly pracovali se čtvrtou vrstvou (TCP), fungovaly tedy jako TCP proxy a tím umožnily různou velikost paketů před proxy a za proxy, nepomohli bychom si tím.
Odpověď na tyto otázky jsem vložil do odstavce nad podnadpisem „Objevování MTU cesty,“ zkusím to tedy napsat ještě jinak a podrobněji.
U TCP to nechapu vubec. Vzdyt prece tim, ze se (aplikacni) programator rozhodne pouzit TCP, tak od toho v podstate dava ruce pryc se slovy "delejte si s tim cestou, co chcete, hlavne at do dorazi neporuseny a ve spravnem poradi".
Ano, a taky takový programátor chce, aby spojení fungovalo co nejkvalitněji. A k tomu právě pomůže vypnutí fragmentace. Fragmentace totiž neobsahuje žádné opravné prostředky pro náhradu ztracených fragmentů. Když se TCP segment velikosti 3000 B rozdělí na 1200, 1200 a 600 B dlouhé fragmenty a kterýkoli z nich se ztratí, je celý segment ztracený. Proto se snaží TCP stack přizpůsobit velikost segmentu MTU cesty, aby se segmenty dále nefragmentovaly.
Jenže TCP stack vidí jen MTU rozhraní, aby mohl zjistit MTU cesty, musí nutně odesílat pakety s flagem DF (a doufat v to, že obdrží ICMP zprávu při zahození). Kdyby přizpůsobil velikost segmentu pouze MTU rozhraní, dopadlo by to třeba u xDSL dost tragicky - odeslal by segment 1460+20(TCP)+20(IPv4) B, který by se hned na xDSL modemu rozfragmentoval na 1452+20+20 a 8+20+20 B. Takže i když by nebyl problém se ztrátovostí, rozhodně by přenos neprobíhal hospodárně a tedy ani nedosahoval maximální možné rychlosti.
A u UDP uz programator tak nejak pocita s tim, ze se cestou muze stat cokoliv. A kdyz se boji, tak bude odesilat minimalni pakety, aby to proslo vzdycky.
Ano, u UDP musí programátor počítat s tím, že se může kterýkoli paket ztratit. Zároveň ale předpokládá, že procento ztracených paketů se nebude blížit stovce. Odesílat vždy dostatečně krátké UDP zprávy je možnost (rozebíral jsem to ve vedlejším příspěvku), ale v podstatě to znamená vybudovat si v aplikaci něco jako TCP. Spousta aplikací pro UDP protokol je ale zprávově orientovaná (například DNS) a každá UDP zpráva je právě tak dlouhá, kolik v ní je potřeba přenést dat.
Mimochodem, pokud taková velká UDP zpráva někde na cestě zahozena (a odesílatel obdrží ICMP zprávu o zahození), odesílatelův UDP/IP stack stejně už nemá možnost zprávu rozdělit na fragmenty znovu, protože odesláním zprávy je vymazána z bufferu. Stane se tedy jenom to, že odesílatel si poznamená snížené MTU cesty k danému cíli a čeká na aplikační vrstvu, až se rozhodne UDP zprávu poslat znovu.
Dekuji. Ted jste to napsal lepe.
(V puvodnim textu je pouze: "Pokud jsou obsahem IP datagramů segmenty protokolu TCP (což je dnes pravděpodobně většina internetového provozu), je používání IP fragmentace nevhodné." Bez vysvetleni, proc.)
Cele to tedy chapu tak, ze odesilateluv TCP/IP stack holt potlaci mechanismus fragmentace a misto toho musi byt tak chytry, aby nejak poznal spravne optimalni MTU pro danou cestu. (No, je to jeho vec. Ja to nastesti programovat nemusim.)
V puvodnim textu je pouze: "Pokud jsou obsahem IP datagramů segmenty protokolu TCP (což je dnes pravděpodobně většina internetového provozu), je používání IP fragmentace nevhodné." Bez vysvetleni, proc.
Já v článku vysvětlení vidím, dvě věty před a čtyři věty po citované větě. Ale nevadí, hlavně, že si rozumíme. :)