Re: Re: tcp/ip
Iskoristiću priliku da na samom početku naglasim da je ovaj mail nakon što je zadovoljio moje literarne nagone prenoćio u drafts folderu, sa tužnom perspektivom da tamo zauvek i ostane, ali je vaskrsao istog trenutka kada su neki subjekti probudili moj usnuli teoretičarski ego...
IP ruteri sprezu racunare u lokalnoj mrezi sa spoljnom mrezom i ne vidim razlog zasto bi neki gateway koji ima recimo samo 2 mrezne kartice kako je cesto i slucaj imao vecu potrebu sa hardverskim rjesenjem od nekog IP-klijenta koji ima potrebu za ogromnim propusnim opsegom koji bi se mogao pojaviti kod nekih hardverski specificnih uredjaja. Pa i sami hubovi i switchevi prenose nista manje paketa koliko i gateway. Dakle jednako su optereceni i Ethernet ruteri i IP ruteri, tako da "ozicavanje" IP rutera je itekako aktuelno. Druga je prica oko teskoce realizacije svega toga i naknadne modifikacije i monitoringa svega toga, ali zato je jos i veci izazov, a sa druge strane svi ti problemi su manje kriticni za ovaj projekat.
Da sam nekim (ne)srećnim spletom okolnosti na ovaj svet došao kao ruter, teško bih podneo da neko na tako grub način pojednostavi svrhu moga bitisanja ("ruter spreže računare u lokalnoj mreži sa spoljnom mrežom"). Ruter može da ima i više od dva mrežna interfejsa, a iako je svaki interfejs priključen na po jednu fizičku mrežu, "iza" tog interfejsa (iza te fizičke mreže) može biti veliki broj mreža. Pomenuti ruter sa 2 mrežna interfejsa je ono što prvo pada na pamet kada se podešava famozni "default gateway". Drugo, hubovi i switchevi ne prenose (IP) pakete nego (Ethernet) frejmove jer su to po referentnom ISO OSI modelu Layer-2 (Data Link) devices, za razliku od IP rutera koji je Layer-3 (Network) device (mada postoje i Layer-3 switches tipa onaj CISCO 6509 u RCUBu). I nije stvar u tome ko koliko paketa prenosi, nego koliko taj prenos košta (mereno procesorskim vremenom). A koliko je procesorskog vremena potrebno hub-u da prenese jedan frame? Nula (jer prosto broadcastuje). A switch-u? "Malo" više (ali praktično O(1) - seća li se iko šta to beše), jer treba da izdvoji iz frejma odredišnu adresu, sračuna hash funkciju, i iz odgovarajućeg ulaza hash tabele pročita redni broj interfejsa na koji treba da prosledi frejm (ili eventualno broadcastuje). Mora još malo da pripazi i oko petlji i to je to. A ruteru? Mnogo više, jer (barem) mora da:
- Proveri da li je frame ispravan (checksum)
- Izdvoji IP datagram iz frejma
- Proveri da li je datagram ispravan (checksum)
- Ažurira TTL
- Ponovo sračuna checksum datagrama
- Odredi na koji interfejs treba da prosledi datagram (zbog prirode IP adresiranja, ne može da koristi heširanje, nego neku drugu strukturu podataka, tipa stablo digitalnog pretraživanja trie ili patricia - vrlo time consuming)
- Razreši IP adresu u fizičku (ARP)
- Napravi novi frame (sa sve checksumom koji izračuna)
- Pošalje frame
Ako na sve ovo dodamo i overhead koji se sastoji u izvršavanju nekog protokola za rutiranje tipa RIP2 ili OSPF (ovde čak mora da ima i nekakvu varijantu Dijkstra algoritma), fragmentaciju, slanje ICMP poruka, (eventualno) filtriranje paketa, izvršavanje nekog softvera za daljinsko administriranje (tipa CISCO IOS) dobijamo da je "cena" prenosa jednog IP paketa preko rutera barem za red veličine veća nego što je to slučaj sa, na primer, prenosom preko switcha. Uostalom, ako razmišljamo čisto inženjerski, zašto uopšte postoje i hubovi i switchevi i ruteri, zašto se kaže da su "switchevi brži od rutera" (mada se meni ovakva formulacija nikada nije dopadala), zašto 1Gb ruter košta mnogo više od 1Gb switcha? Pa dovoljno je pogledati koliko jedan CISCO ruter ima procesora, magistrala, memorije, DMA kontrolera i koliko se ti siroti inženjeri trude da tu čitavu skalameriju izoptimizuju... Uostalom, zašto se kaže da nije dobra praksa da multihome računari (sa dva ili više mrežnih interfejsa) ne učestvuju u rutiranju iako postoje deamons koji to rade (na primer routed na raznim UNIX distribucijama)?
Kada se vec odradi TCP automat i ostalo, HTTP je OK. Ja sam pisao proxy servere u Perlu sa samo par desetina redova, a web server je jos manji. Overhead samog HTTP protokola nije ni priblizno kritican po tom pitanju, jer nama ne trebaju takve egzotike kao sto su PRAGMA, PROXY-CONNECTION, niti negotiation, ... vec ono sto je nuzno, a to nuzno nam bas olaksava rad i omogucava fantasticnu kontrolu, npr. virtualizaciju uredjaja preko njihovih URL-ova kao da ih na UNIXu mauntujemo na fajlove, ... Jedno smo za Veljka radili neki distribuirani sistem u Perlu koji je komunicirao preko HTTP protokola (koji je blago modifikovan zbog pracenja sesija) i bila je super stvar jer se cijeli sistem mogao testirati preko standardnih brauzera i lako su se dibagirali svi nastali problemi, ali overhead koji takav pristup daje je po meni kontradiktoran sa hardverskom realizacijom svega ovoga. Po meni bolje rjesenje je UDP.
Zašto UDP? Jeste da je to jeftino za implementaciju, ali to je "best-effort service" i onda ćeš na aplikativnom nivou morati da implementiraš kontrolu toka (potvrđivanje/ponovni prenos/...), a teško da će to moći da se približi performansama TCP-a (koji ima klizni prozor, congestion avoidance i sl.)... Jeste da je lepo uživati u blagodetima browsera i HTTP-a, ali HTTP zaglavlje je priličan overhead (em veći bandwidth, em onom mučenom hardveru treba vreme dok isparsira HTTP GET/POST request) kada je, na primer, uređaju potrebno samo reći "Sezame, otvori se". A rešenje sa TCP-om i Java appletom je opet "iz browsera", ali se na uređaj prenosi i obrađuje mnogo manje informacija. Takođe, moguće je i treće rešenje, sa posrednim web serverom (računar opšte namene) koji obrađuje HTTP zahteve i pomoću TCP-a kontroliše uređajčiće (ovo jedino ima smisla ako ima puuuno uređajčičića ili ako je potrebna autentifikacija ili nešto slično)...
> Btw, jel' se misli na 10BaseT ili 100BaseT Ethernet?
Sta je uopste frka za to?
Treba brža (skuplja) gvožđurija za 100Mbit nego za 10Mbit Ethernet, što se samog TCP/IP steka tiče, potpuno je isto.
I na kraju, što se tiče "ožičavanja" rutera, meni se oduvek činilo kao straaašno romantično (izvini M.) i kao veliki izazov, ali je veliko pitanje ekonomske isplativosti toga (tu se slažem sa tobom).
Pozdrav,
Damjan S. Vujnović, Teoretičar-lenja-buba, samozvani ekspert za TCP/IP i mrežne tehnologije i iskreni poklonik slova šđčćž
IP ruteri sprezu racunare u lokalnoj mrezi sa spoljnom mrezom i ne vidim razlog zasto bi neki gateway koji ima recimo samo 2 mrezne kartice kako je cesto i slucaj imao vecu potrebu sa hardverskim rjesenjem od nekog IP-klijenta koji ima potrebu za ogromnim propusnim opsegom koji bi se mogao pojaviti kod nekih hardverski specificnih uredjaja. Pa i sami hubovi i switchevi prenose nista manje paketa koliko i gateway. Dakle jednako su optereceni i Ethernet ruteri i IP ruteri, tako da "ozicavanje" IP rutera je itekako aktuelno. Druga je prica oko teskoce realizacije svega toga i naknadne modifikacije i monitoringa svega toga, ali zato je jos i veci izazov, a sa druge strane svi ti problemi su manje kriticni za ovaj projekat.
Da sam nekim (ne)srećnim spletom okolnosti na ovaj svet došao kao ruter, teško bih podneo da neko na tako grub način pojednostavi svrhu moga bitisanja ("ruter spreže računare u lokalnoj mreži sa spoljnom mrežom"). Ruter može da ima i više od dva mrežna interfejsa, a iako je svaki interfejs priključen na po jednu fizičku mrežu, "iza" tog interfejsa (iza te fizičke mreže) može biti veliki broj mreža. Pomenuti ruter sa 2 mrežna interfejsa je ono što prvo pada na pamet kada se podešava famozni "default gateway". Drugo, hubovi i switchevi ne prenose (IP) pakete nego (Ethernet) frejmove jer su to po referentnom ISO OSI modelu Layer-2 (Data Link) devices, za razliku od IP rutera koji je Layer-3 (Network) device (mada postoje i Layer-3 switches tipa onaj CISCO 6509 u RCUBu). I nije stvar u tome ko koliko paketa prenosi, nego koliko taj prenos košta (mereno procesorskim vremenom). A koliko je procesorskog vremena potrebno hub-u da prenese jedan frame? Nula (jer prosto broadcastuje). A switch-u? "Malo" više (ali praktično O(1) - seća li se iko šta to beše), jer treba da izdvoji iz frejma odredišnu adresu, sračuna hash funkciju, i iz odgovarajućeg ulaza hash tabele pročita redni broj interfejsa na koji treba da prosledi frejm (ili eventualno broadcastuje). Mora još malo da pripazi i oko petlji i to je to. A ruteru? Mnogo više, jer (barem) mora da:
- Proveri da li je frame ispravan (checksum)
- Izdvoji IP datagram iz frejma
- Proveri da li je datagram ispravan (checksum)
- Ažurira TTL
- Ponovo sračuna checksum datagrama
- Odredi na koji interfejs treba da prosledi datagram (zbog prirode IP adresiranja, ne može da koristi heširanje, nego neku drugu strukturu podataka, tipa stablo digitalnog pretraživanja trie ili patricia - vrlo time consuming)
- Razreši IP adresu u fizičku (ARP)
- Napravi novi frame (sa sve checksumom koji izračuna)
- Pošalje frame
Ako na sve ovo dodamo i overhead koji se sastoji u izvršavanju nekog protokola za rutiranje tipa RIP2 ili OSPF (ovde čak mora da ima i nekakvu varijantu Dijkstra algoritma), fragmentaciju, slanje ICMP poruka, (eventualno) filtriranje paketa, izvršavanje nekog softvera za daljinsko administriranje (tipa CISCO IOS) dobijamo da je "cena" prenosa jednog IP paketa preko rutera barem za red veličine veća nego što je to slučaj sa, na primer, prenosom preko switcha. Uostalom, ako razmišljamo čisto inženjerski, zašto uopšte postoje i hubovi i switchevi i ruteri, zašto se kaže da su "switchevi brži od rutera" (mada se meni ovakva formulacija nikada nije dopadala), zašto 1Gb ruter košta mnogo više od 1Gb switcha? Pa dovoljno je pogledati koliko jedan CISCO ruter ima procesora, magistrala, memorije, DMA kontrolera i koliko se ti siroti inženjeri trude da tu čitavu skalameriju izoptimizuju... Uostalom, zašto se kaže da nije dobra praksa da multihome računari (sa dva ili više mrežnih interfejsa) ne učestvuju u rutiranju iako postoje deamons koji to rade (na primer routed na raznim UNIX distribucijama)?
Kada se vec odradi TCP automat i ostalo, HTTP je OK. Ja sam pisao proxy servere u Perlu sa samo par desetina redova, a web server je jos manji. Overhead samog HTTP protokola nije ni priblizno kritican po tom pitanju, jer nama ne trebaju takve egzotike kao sto su PRAGMA, PROXY-CONNECTION, niti negotiation, ... vec ono sto je nuzno, a to nuzno nam bas olaksava rad i omogucava fantasticnu kontrolu, npr. virtualizaciju uredjaja preko njihovih URL-ova kao da ih na UNIXu mauntujemo na fajlove, ... Jedno smo za Veljka radili neki distribuirani sistem u Perlu koji je komunicirao preko HTTP protokola (koji je blago modifikovan zbog pracenja sesija) i bila je super stvar jer se cijeli sistem mogao testirati preko standardnih brauzera i lako su se dibagirali svi nastali problemi, ali overhead koji takav pristup daje je po meni kontradiktoran sa hardverskom realizacijom svega ovoga. Po meni bolje rjesenje je UDP.
Zašto UDP? Jeste da je to jeftino za implementaciju, ali to je "best-effort service" i onda ćeš na aplikativnom nivou morati da implementiraš kontrolu toka (potvrđivanje/ponovni prenos/...), a teško da će to moći da se približi performansama TCP-a (koji ima klizni prozor, congestion avoidance i sl.)... Jeste da je lepo uživati u blagodetima browsera i HTTP-a, ali HTTP zaglavlje je priličan overhead (em veći bandwidth, em onom mučenom hardveru treba vreme dok isparsira HTTP GET/POST request) kada je, na primer, uređaju potrebno samo reći "Sezame, otvori se". A rešenje sa TCP-om i Java appletom je opet "iz browsera", ali se na uređaj prenosi i obrađuje mnogo manje informacija. Takođe, moguće je i treće rešenje, sa posrednim web serverom (računar opšte namene) koji obrađuje HTTP zahteve i pomoću TCP-a kontroliše uređajčiće (ovo jedino ima smisla ako ima puuuno uređajčičića ili ako je potrebna autentifikacija ili nešto slično)...
> Btw, jel' se misli na 10BaseT ili 100BaseT Ethernet?
Sta je uopste frka za to?
Treba brža (skuplja) gvožđurija za 100Mbit nego za 10Mbit Ethernet, što se samog TCP/IP steka tiče, potpuno je isto.
I na kraju, što se tiče "ožičavanja" rutera, meni se oduvek činilo kao straaašno romantično (izvini M.) i kao veliki izazov, ali je veliko pitanje ekonomske isplativosti toga (tu se slažem sa tobom).
Pozdrav,
Damjan S. Vujnović, Teoretičar-lenja-buba, samozvani ekspert za TCP/IP i mrežne tehnologije i iskreni poklonik slova šđčćž
- References:
- Re: tcp/ip
- From: Sasa Rudan <mprinc@galeb.etf.bg.ac.yu>
- Re: tcp/ip
Previous by date: Re: Re: tcp/ip
Next by date: Nesto u vezi f-ja za 8051
Previous by thread: Re: Re: tcp/ip Next by thread: Januarski domaci
Previous by thread: Re: Re: tcp/ip Next by thread: Januarski domaci