Internetowe mity

Minęło trzydzieści lat od momentu opublikowania pierwszych dokumentów opisujących pracę protokołu IP (Internet Protocol). Od tego czasu programiści i inżynierowie opracowali tysiące aplikacji i urządzeń, które transmitują dane między użytkownikami i komputerami w oparciu o ten mechanizm. Jednak protokół IP cały czas ewoluował i zmieniał się. Proces jego dostosowywania do aktualnych potrzeb trwa do dzisiaj, ponieważ całe otoczenie sieciowe bezustannie zmienia się.

Prawdę tę można przypomnieć prezentując np. wiele mitów dotyczących tego, jak pracuje największa, ogólnoświatowa sieć komputerowa (Internet).

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". Dlatego szereg aplikacji internetowych zakłada, iż jeśli Stacja A może się skontaktować ze Stacją B, to oznacza to, iż zasada ta obowiązuje również w drugim kierunku.

Zobacz również:

  • Darmowy hosting bije rekordy popularności
  • Wirusy na Androida - popularne i niebezpieczne zagrożenia
  • Starlink dla pojazdów mobilnych

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 czy 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 sprawdza się obecnie, z tych samych powodów, które zostały podane w punkcie 1.

3. Transmitowanie danych w trybie multicast zawsze pracuje poprawnie.

Transmitowanie danych w trybie multicast polega na tym, że stacja źródłowa może rozsyłać jednocześnie pakiety do wielu stacji docelowych, jeśli tylko stacje docelowe akceptują 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 do stacji docelowej pierwszego pakietu, będzie obowiązywać dalej 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. Przykład - aplikacje wysyłają do serwera pakiety Ping i każda z nich uważa, że pierwsze opóźnienie jest tym właściwym. Jednak opóźnienie odnotowane dla pierwszego pakietu może być dłuższe niż dla następnych, ponieważ serwer musi wtedy wykonać dodatkowo taką np. czynność, jak przeglądanie tabel routingu.

Aplikacje przyjmują wtedy błędne założenia dotyczące opóźnień, które w rzeczywistości nie będą tak duże. Trzeba tu też wziąć pod uwagę to, że niektóre aplikacje (takie jak 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.

Panuje opinia, że adresy IP zmieniają się bardzo rzadko i pozostają takie same przez dłuższy czas. Aplikacje zamieniają najpierw nazwy stacji docelowych na adresy i przechowują je w swoich buforach, nie dołączając do nich żadnych uwag dotyczących czasu życia takiej informacji (przyporządkowującej adres IP do nazwy).

Pogląd, że adresy IP zmieniają się bardzo rzadko nie jest prawdziwy, 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ą.

Trzeba od razu powiedzieć, że jest to przypuszczenie, które nie było nigdy prawdziwe. Odkąd istnieje protokół IP, komputery mogły zawsze zawierać wiele interfejsów sieciowych i do każdego z nich można było przypisywać kilka adresów internetowych. Pracujące obecnie komputery obsługują łączność kablową i bezprzewodową, protokoły IPv4 i IPv6, i mogą posiadać wiele interfejsów, które mogą nosić wiele 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, jaki 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 tu 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 (czwarta, licząc od dołu), 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, nowe aplikacje webowe wykorzystują tylko protokół warstwy aplikacji Hypertext Transfer Protocol (HTTP).

9. Aplikacje mogą - obsługując komunikację między dwiema stacjami - zawsze 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 mogą nieraz blokować określone porty i nie zezwalać na otwieranie więcej niż jednego połączenia. Dlatego niektóre aplikacje (np. File Transfer Protocol czy Real-time Transfer Protocol) mogą mieć wtedy kłopoty.

10. Zawartość pakietów transmitowanych przez połączenia internetowe nie ulega żadnym zmianom.

Istnieje przekonanie, że pakiety transmitowane przez połączenia internetowe nie są modyfikowane. 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, systemu IPS i inne. IPsec rozwiązuje ten problem szyfrując pakiety IP, ale nie jest to rozwiązanie stosowane powszechnie.

11. Cała komunikacja obsługiwana przez połączenia internetowe jest prywatna.

Internauci sądzą, że przesyłane przez nich pakiety to zasób prywatny, do którego nikt inny nie ma dostępu. 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 pakietom IP bezpieczeństwo poprzez ich szyfrowanie.

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. Jest to błędne założenie. Należy pamiętać, że wielu użytkowników sięga po technikę spoofingu, używaną np. powszechnie przez stacje biorące udział w atakach typu Denial of Service do ukrycia swoich 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