A legelején szükséges tisztázni azt a kérdést, hogy Layer 3-as MTU csomagokról vagy Layer 2-es MTU keretekről beszélünk.
Egy ETH keret a hasznos adaton felül áll egy ETH fejlécből (header), amely minden esetben tartalmazza a cél MAC address-t, ahova az adott keretet küldeni kell. Emellett megtalálható benne a forrás MAC cím is, amelyre a keretet megkapó eszköz továbbítani tudja válaszát, valamint egy 2 byte-os Ether type elnevezésű indikátor, amely azt mondja el, hogy a payload-ban milyen jellegű adat lehet és azt miként kell értelmeznie a fogadó eszköznek.
Arra a kérdésre, hogy miért a cél MAC address található az ETH keret elején egyszerű a válasz. A protokoll kialakításakor a maximális optimalizációra törekedtek a fejlesztők ezért azt mondták, hogy elég az első 6 byte-ot elolvasni a kommunikáció kezdetén, hogy megállapítható legyen az hová is kell pontosan küldeni az adott keretet.
Az IP csomagok szintén két részre oszthatóak. Az első rész az IP header, amely a csomag elküldéséhez szükséges információkat tartalmazza. A második rész pedig a payload, amelyben a felhasználó számára érdekes és hasznos kommunikáció történik. Például megtalálható benne egy TCP szegmens, amelyben az általunk indított http kérés található, amely egy kép letöltéséről szól.
Mi történik akkor, ha egy nagyobb csomagot szeretnénk elküldeni, mint amennyi maximálisan megengedett a hálózaton? A jellemző maximális MTU érték a hálózatokon 1500 byte. Amíg a célállomás és a kiindulópont között e maximális MTU értékeken belül történik a kommunikáció minden probléma nélkül sikeresen végbemegy az adatcsere. De mi történik akkor, ha a hálózaton nagyobb csomag próbál átmenni, mint amennyi megengedett?
Nagyobb méretű csomagoknál IPV4 esetén ezt könnyen megoldhatjuk. Nincs más teendőnk, mint az adott csomagot akkora darabokra vágni, hogy azok egyes elemei beleférjenek a meghatározott MTU méretkorlátba. Ezt a metódust IP fragmentációnak nevezzük, amely ugyan hatékonyan orvosolja a fenti problémát azonban nagy extra terhelést ró a routerekre mind az adó, mind a vevő oldalon, amely végső eredményként teljesítménycsökkenéshez vezethet. Plusz megemlítendő, hogy ha a feldarabolt csomagnak akár egyetlen egy része is elvész akkor a másik oldalon már az eszköz képtelen lesz összefűzni az adott keret darabjait és így egy értelmezhetetlen csomag keletkezik, amit végső megoldásként teljes egészében kénytelen eldobni. Ez a probléma egy szolgáltató hálózatban róhat rendkívül nagy terhet adott routerekre hiszen ott nem 1-2 felhasználóról, hanem akár 10.000-es nagyságrendekről beszélhetünk egy időben.
De mi történik akkor, ha ezt a fragmentálást adott szolgáltató úgy dönt, hogy kikapcsolja? Ekkor futhat bele a felhasználó egy olyan jellegű hibába, hogy adott weboldalt felkeresve a böngészőn keresztül nem kap választ a kérésére viszont, ha parancssorban „megpingeti” az adott oldalt a szerver válaszol. Ennek az oka rendkívül egyszerű. A weboldal lekérése meghaladja azt a maximum méretet, amely fragmentálás nélkül feldolgozható és mivel ez a funkció tiltva van így a csomag eldobásra kerül. Míg a ping csomag általában kis MTU érékkel kerül kiküldésre.
Természetesen léteznek megoldások a különböző méretű MTU problémák kezelésére. TCP protokollon keresztül állítható magának a TCP-nek a szegmens mérete ezáltal a köré csomagolt IP csomagoknak és ETH kereteknek több mozgásterük marad. Ezt az MSS (maximum segment size) beállítást akár kézzel is elvégezhetjük. Bizonyos eszközök már maguk is képesek ennek feltérképezésére a hálózati útvonalon majd ezután igazodva a kapott információhoz automatikusan elvégzik a szükséges beállítást.
Egy másik megoldás is létezik melynek az alapja, hogy a host-ok egymás közt érzékelik (feltérképezik) és megállapítják, hogy a szóban forgó hálózatnak mennyi a maximális átviteli MTU értékük. Ezt az ICMP (Internet Control Message Protocol) protokollt használó módszert hívják PMTUD (Path MTU Discovery) -nek.
Az ICMP protokoll alapja, hogy egy nagy méretű csomagot küldünk ki a hálózatba melyet ellátunk egy DF (don’t fragment) bittel. Ez a csomag mindaddig tovább halad amíg nem találkozik egy olyan routerrel, amelynél a kimenő interfész már kisebb, mint a kérdéses csomag mérete. Ekkor kezdődne a fragmentálálás, amelyet viszont megakadályoz a fent már említett DF bit. Ezzel egy időben pedig egy ICMP üzenet kerül továbbításra a küldő részére, amely tartalmazza azt az információt, hogy ez a csomag meghaladja a maximális méretet.
Mi történik akkor, ha nem csökkenteni szeretném ezt a maximum MTU értéket, hanem növelni, hogy megkönnyítsem a kommunikációt? Ez a megoldás abban az esetben lehetséges, ha hálózat teljes egészét felügyeletünk alatt tudhatjuk és biztosak vagyunk benne, hogy a rendszer teljes egésze képes feldolgozni és értelmezni a megnövelt MTU értéket, ez általánosságban 9000 byte méretű.
VPN tunnel-ek esetében további „csomagolással” is számolnunk kell. Kiragadva egyet vegyük alapul a PPPoE-t. Napjainkban tipikusan optikai GPON hálózatoknál használják még ezt, vagy olyan környezetben, ahol a régi DSL hálózatokon keresztül működik a rendszer. A PPPoE-nél számszerűsítve egy 8 byte-os header-el kell kalkulálnunk fixen minden IP csomag előtt, ami azt jelenti, hogy az 1500-as MTU mérettel már akár itt is problémába ütközhetünk hiszen már csak 1492 byte számára marad szabad hely. Ebben a környezetben a fragmentálást elkerülve alkalmazható akár a fent már említett MSS mechanizmus.
Ha a készülék olyan helyzetben van, hogy nem lát rá a hálózat adott részére akkor egy további lehetőség, hogy a hálózat legszűkebb szegmense interakcióba lép a kommunikáció közben és a TCP session felépülésekor tudatosan lecsökkenti az MSS méretét akkorára, hogy ne legyen szükség fragmentációra. Természetesen ezek a megoldások kizárólag TCP protokollon keresztül érvényesek.
UDP esetén a legjobb választás a kis csomagméretek alkalmazása. Jellemzően UDP-t használunk videóstreamingre, videóhívásokra. Az itt használt RTP protokoll saját maga rendelkezik fragmentálási metódussal, amellyel így a továbbiakban nekünk nincs dolgunk. Példaként VOIP esetén jellemzően 200 byte alatti, videónál 576 byte alatti csomagméretekről beszélhetünk. Az 576 byte az a méret, amelyet minden egyes IP eszköznek IPV4 protokollon keresztül képesnek kell lennie átvinni és feldolgozni.
Jövő héten folytatjuk sorozatunkat, ahol az overheadek-ről lesz szó bővebben.