12 internetowych mitów

Minęło trzydzieści lat od momentu opublikowania pierwszych dokumentów opisujących pracę protokołu IP.

Minęło trzydzieści lat od momentu opublikowania pierwszych dokumentów opisujących pracę protokołu IP.

Mimo tak długiej historii, protokół IP cały czas ewoluuje i zmienia się. Proces jego dostosowywania do aktualnych potrzeb trwa do dzisiaj, ponieważ całe otoczenie sieciowe bezustannie się przeobraża. Jednocześnie narosło trochę mitów i nieporozumień dotyczących tego, jak pracuje ta ogólnoświatowa sieć komputerowa. 12 z nich zaprezentowano poniżej.

1. Jeśli Stacja A ma dostęp do Stacji B, to oznacza to, że Stacja B ma dostęp do Stacji A

Jest to mit wynikający z przekonania, że „dostępność jest symetryczna”. Aplikacje przyjmują takie założenie np. wtedy, gdy realizują funkcje request-response lub callback. Założenia takie nie są jednak zawsze prawdziwe, ponieważ warstwy pośrednie - takie jak mechanizmy NAT czy zapory - mogą obsługiwać komunikację IP tylko w jedną stronę. Zdarza się to często w sieciach bezprzewodowych 802.11 lub w przypadku łączy satelitarnych.

2. Jeśli Stacja A ma dostęp do Stacji B, a Stacja B ma dostęp do Stacji C, to Stacja A może mieć również dostęp do Stacji C

Jest to mit wynikający z przekonania, że „dostępność jest przechodnia”. Teza taka jest stawiana wtedy, gdy w aplikacjach internetowych znajdują się odwołania lub przekierowania do innych zasobów. Przypuszczenie to nie zawsze się sprawdza (patrz pkt 1).

3. Transmitowanie danych w trybie multicast zawsze pracuje poprawnie

Polega ono na tym, że stacja źródłowa może rozsyłać jednocześnie pakiety do wielu stacji docelowych, jeśli tylko akceptują one taki rodzaj komunikowania się. Wiele aplikacji zakłada, że ruch multicast może być obsługiwany przez wszystkie rodzaje połączeń. Nie jest to jednak zawsze prawda w przypadku bezprzewodowych sieci LAN 802.11 i stosowania mechanizmów tunelowania pakietów, takich jak Teredo lub 6to4.

4. Opóźnienie, jakie aplikacja rejestruje przy przesyłaniu pierwszego pakietu, będzie obowiązywać podczas całego procesu transmitowania danych

Wiele aplikacji zakłada, iż opóźnienie end-to-end odnotowane przy wysłaniu do stacji przeznaczenia pierwszego pakietu będzie obowiązywać również przy przesyłaniu następnych pakietów. W rzeczywistości opóźnienie pierwszego pakietu może być dłuższe niż dla następnych, ponieważ serwer musi wykonać dodatkowo czynność, jak np. przeglądanie tabel routingu. Aplikacje przyjmują wtedy błędne założenia dotyczące opóźnień. Trzeba tu też wziąć pod uwagę to, że niektóre aplikacje (np. Mobile IPv6 czy Protocol Independent Multicast) przesyłają pakiety najpierw przez jedną ścieżkę, a następnie potrafią ją zmienić na krótszą, oferującą mniejsze opóźnienia.

5. Adresy IP zmieniają się bardzo rzadko

Istnieje założenie, że adresy IP pozostają takie same przez dłuższy czas. Aplikacje zamieniają najpierw nazwę stacji docelowej na adres i przechowują go w swoich buforach, nie dołączając żadnych uwag dotyczących czasu życia informacji przyporządkowującej adres IP do nazwy. Przypuszczenie takie nie sprawdza się obecnie, ponieważ wiele systemów komputerowych korzysta z usług protokołu DHCP (Dynamic Host Configuration Protocol) oraz z różnych mechanizmów roamingu.

6. Komputer ma tylko jeden adres IP i jeden interfejs łączący go z siecią

Przypuszczenie to nigdy nie było prawdziwe. Odkąd istnieje protokół IP, komputery mogły zawsze zawierać wiele interfejsów sieciowych i każdy z nich mógł mieć inny adres. Komputery obsługujące łączność kablową i bezprzewodową oraz protokoły IPv4 i IPv6 mogą posiadać wiele interfejsów, a każdy z nich może mieć wiele przypisanych adresów IP.

7. Jeśli adresy obu systemów znajdują się w tej samej podsieci, to są one zlokalizowane blisko siebie

Niektóre aplikacje zakładają, że adres IP używany przez inną aplikację jest tym samym adresem, który został użyty w procesie routingu. Oznacza to, że aplikacja może „wysnuć” wniosek, iż dwa systemy znajdujące się w tej samej podsieci (subnet) są zlokalizowane blisko siebie i będą między sobą wymieniać dane bardzo szybko. Nie jest to prawdą w tych środowiskach, w których mamy do czynienia z mechanizmami tunelowania i mobilnością. Trzeba też wziąć pod uwagę to, że nowe aplikacje stosują nieraz schemat, znany pod nazwą „identifier/locator split” (rozdzielanie identyfikatora od lokalizatora), który używa innych adresów IP do identyfikowania systemów, a innych do ich lokalizowania.

8. Nowe protokoły operujące w warstwie transportu (pracują poprawnie w całym Internecie)

Teza, iż protokół IP (warstwa sieci) został tak zaprojektowany, że może obsługiwać nowe protokoły operujące w warstwie transportu, nie jest prawdziwa. Większość mechanizmów NAT i zapór obsługuje tylko dwa protokoły warstwy transportu: Transmission Control Protocol (TCP) i User Datagram Protocol (UDP). Poza tym aplikacje webowe wykorzystują protokół warstwy aplikacji Hypertext Transfer Protocol (HTTP).

9. Aplikacje mogą - obsługując komunikację między stacjami - otwierać wiele połączeń

Niektórzy sądzą, że aplikacje mogą zawsze otwierać między dwoma komunikującymi się ze sobą systemami wiele połączeń - jedne służą wtedy do przesyłania danych, a drugie do kontrolowania transmisji. Problem polega na tym, że znajdujące się pośrodku zapory i mechanizmy NAT blokują określone porty i mogą nie zezwalać na otwieranie więcej niż jednego połączenia. Właśnie dlatego niektórych aplikacji, takich jak File Transfer Protocol (FTP) i Real-time Transfer Protocol (RTP) nie można wtedy uruchamiać.

10. Pakiety transmitowane przez połączenia internetowe nie ulegają zmianom

Była to może prawda dawno temu, wtedy gdy Internet raczkował, ale obecnie jest inaczej, głównie za sprawą takich rozwiązań, jak zapory, systemy NAT, system IPS i inne. IPsec rozwiązuje ten problem szyfrując pakiety IP, ale nie jest to rozwiązanie powszechne.

11. Komunikacja obsługiwana przez połączenia internetowe jest prywatna

Nigdy tak nie było. Jedynym sposobem ochrony danych i spowodowania, że będzie to rzeczywiście prywatny zasób, jest skorzystanie z mechanizmu IPsec - zestawu protokołów zapewniających szyfrowanie i autentykację pakietów IP.

12. Adresy towarzyszące stacji nadającej są zawsze prawdziwe

Wiele aplikacji internetowych przyjmuje, że odbierany przez nie pakiet został wysłany przez stację, której adres został do tego pakietu dołączony. Należy jednak pamiętać, że wielu użytkowników sięga po technikę spoofingu umożliwiającą ukrycie rzeczywistych adresów.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200