Internet od środka: jak przebiega komunikacja w sieci?

Zapraszam na drugą część cyklu o podstawach komunikacji w sieci. Dziś tematyka może trochę bardziej zaawansowana, ale na pewno nie mniej ciekawa.

Po wcześniejszym wstępie, dziś opiszemy jak wygląda komunikacja między komputerami w Internecie.

Diagram przedstawia warstwy modelu OSI / ISO. Dane przygotowane na jednym komputerze muszą przedostać się przez kilka warstw sieci, aby drugi komputer mógł je z powodzeniem odczytać i wykorzystać. Każda warstwa jest odpowiedzialna za specyficzne działania, w ramach których często wykorzystywane są odpowiednie protokoły sieciowe. Model OSI / ISO został na potrzeby komunikacji w Internecie uproszczony i jest często przedstawiany w postaci modelu TCP/IP, który wygląda tak:

Warstwa aplikacji z pewnością najbardziej zainteresuje przeciętnego użytkownika, bo to tutaj działają wszelkie programy. Jeżeli więc korzystasz z przeglądarki internetowej, poczty elektronicznej, wymiany plików przez FTP, to masz do czynienia z warstwą aplikacji w modelu TCP/IP. Z tą warstwą związane są protokoły takie, jak: HTTP, DNS, SMTP, FTP.

W warstwie transportowej, jak sama nazwa wskazuje, działają mechanizmy odpowiedzialne za dostarczenie danych. Tutaj pole do popisu mają protokoły TCP i UDP.

Warstwa Internetu. Tu przede wszystkim działa protokół IP (Internet Protocol) używany do lokalizacji hostów na podstawie ich adresów.

Warstwa dostępu do sieci. Najniższy poziom komunikacji, czyli poziom fizyczny - wykorzystywany przez karty sieciowe, kabelki, modemy i im podobne urządzenia.

 

Porty

Obok protokołów, które za chwile ogólnie opiszemy używając przykładu, możemy rozróżnić porty. Porty istnieją niezależnie od protokołów i pozwalają zweryfikować usługę sieciową działającą w ramach danego protokołu.

Traktuj porty jako coś abstrakcyjnego - nie jest to kabelek wetknięty w odpowiednie gniazdo z numerem portu, ale logiczny byt, który porządkuje komunikację w ramach danego protokołu. Dlaczego? Zestawienie adresu hosta, protokołu oraz portu pozwala jednoznacznie zaadresować do niego odpowiedni pakiet danych.

Na przykład twoja przeglądarka, po wpisaniu w jej adresie http://jakasstrona.pl "wie", że ma spróbować wysłać żądanie w protokole HTTP do hosta ukrytego pod nazwą domenową jakasstrona.pl, nasłuchującego na porcie 80. Gdybyś wpisał adres http://jakasstrona.pl:12856 wysłałbyś żądanie na port 12856, jednak zapewne trafiłoby ono w próżnię, bo żadna aplikacja nie oczekuje na komunikację przez HTTP na tym serwerze i porcie - czyli, mówiąc bardziej fachowo, nie istnieje tam żaden endpoint.

Przykład wykorzystania portów i protokołów. Serwer udostępnia usługę WWW na porcie 80 i usługę pocztową na porcie 25.

Port może przyjąć wartość od 0 do 65535. Porty z zasady są przypisane do konkretnych usług - i tak mamy porty przypisane domyślnie do protokołów:

• 80 - HTTP
• 443 - HTTPS
• 53 - DNS
• 20, 21 - FTP
• 143 - IMAP
• 110 - POP3
• 25 - SMTP

 

Przykład

Przeanalizujmy uproszczony przykład przesłania informacji z jednego komputera do drugiego. Niech będzie to wspominany już wcześniej request z przeglądarki.

1. Użytkownik zaczyna od warstwy aplikacji.

Uruchamia przeglądarkę i wpisuje adres internetowy www.przykładowyadres.pl. Po wciśnięciu ENTER przeglądarka generuje request HTTP z prośbą o zwrócenie strony WWW przez docelowy serwer.

2. www.przykładowyadres.pl to adres domenowy.

Host użytkownika używa protokołu DNS (Domain Name System), aby przetłumaczyć ten adres z postaci przyjaznej dla użytkownika, do postaci adresu IP pozwalającego zidentyfikować serwer zdalny w sieci. W tym celu komunikuje się z serwerami DNS rozlokowanymi w Internecie i otrzymuje od nich informację zwrotną o adresie IP, np.: 111.112.113.114 (przykład).

3. Host, mając już wiedzę o adresie, protokole z warstwy aplikacyjnej i porcie docelowym, procesuje pakiet danych dalej i przechodzi do warstwy transportowej. Pakiet zawiera już nagłówek HTTP.

Nagłówek protokołu możesz traktować jako zbiór danych, opisujących właściwości pakietu potrzebne do przetworzenia przez dany protokół.

Pakiet to po prostu nazwa (używana na potrzeby protokołów sieciowych) fragmentu danych, które chcemy przesłać z jednego hosta do drugiego używając połączeń sieciowych.

4. Teraz do gry wchodzi protokół TCP.

Za transport danych między dwoma komputerami odpowiedzialne są przede wszystkim dwa protokoły - TCP (Transmission Control Protocol) oraz UDP (User Datagram Protocol). Częściej stosuje się ten pierwszy, gdyż zapewnia dostarczenie danych w całości, bez błędów i duplikatów. Minusem jest większe obciążenie sieci, gdyż w porównaniu do UDP potrzebuje przesłania większej ilości danych potwierdzających poprawność. TCP - niezawodność, UDP - szybkość.

Można powiedzieć, że TCP niejako nadzoruje działania protokołu IP i zapewnia jego niezawodność. IP transmituje dane w formie pakietów mających określoną maksymalną wielkość. Aby przesłać dużą porcję danych, należy podzielić ją na wiele pakietów i wysyłać pojedynczo protokołem IP.

Pakiety takie mogą się w sieci zagubić, zdeformować czy przyjść w nieodpowiedniej kolejności do odbiorcy, co uniemożliwiłoby odczytanie zawartych w nich informacji (byłyby bezużytecznym ciągiem zer i jedynek). Protokół TCP kontroluje pakiety tak, aby żadna z wymienionych okoliczności nie zakłóciła transmisji. TCP jest odpowiedzialny za rozbicie danych, wysłanie za pomocą protokołu IP, a potem poskładanie ich w całość u odbiorcy i dostarczenie aplikacji.

5. Pakiet, opakowany już w nagłówki HTTP i TCP wędruje do kolejnej warstwy - Internetu. Tutaj przejmuje go protokół IP.

IP jest odpowiedzialny za zaadresowanie naszego pakietu (adres IP zdobyliśmy dzięki DNS) i zlokalizowanie hosta docelowego. Host docelowy może być zlokalizowany w zupełnie odrębnej sieci po drugiej stronie globu. Urządzenia sieciowe zwane ruterami przechowują informacje o drogach, którymi może dotrzeć pakiet do adresata (czyli po prostu połączeniach między różnymi komputerami, wiodących w końcu do docelowego hosta). Protokół IP ma za zadanie jednoznacznie zlokalizować docelowego hosta i wyznaczyć optymalną trasę dla pakietów.

6. Po opakowaniu pakietu w nagłówek IP, pakiet dociera do warstwy najniższej - dostępu do sieci.

Tutaj działają mechanizmy odpowiedzialne za fizyczne wysłanie pakietu w postaci impulsów elektrycznych z naszego hosta. Pakiet jest dodatkowo opakowywany w tak zwaną ramkę.

W tej warstwie działa także protokół ARP (Address Resolution Protocol). Wspomniane wcześniej ramki powinny być zaadresowane adresem MAC. Jest to unikalny adres każdego komputera, który posiada interfejs sieciowy, na przykład kartę sieciową Ethernet. Taka karta ma fabrycznie przyporządkowany, unikalny adres fizyczny MAC.

Jeżeli chcesz poznać twój unikalny adres MAC, otwórz linię poleceń i wpisz:

ipconfig /all

Zobaczysz wynik podobny do tego:

Karta bezprzewodowej sieci LAN Połączenie sieci bezprzewodowej:

   Sufiks DNS konkretnego połączenia : xxx.xx.pl
   Opis. . . . . . . . . . . . . . . : Broadcom 802.11n Network Adapter
   Adres fizyczny. . . . . . . . . . : XX-XX-XX-XX-XX-XX
   DHCP włączone . . . . . . . . . . : Tak
   Autokonfiguracja włączona . . . . : Tak


Adres fizyczny to twój MAC adres.

ARP pozwala poznać adres MAC hosta docelowego, co jest konieczne przy adresowaniu wysyłanej ramki.

Reasumując - jak wyglądają dane przesyłane podczas wprowadzania adresu strony internetowej? W bardzo uproszczonym schemacie możemy je przedstawić tak:

7. Request naszej przeglądarki, żądający wyświetlenia strony www.przykładowyadres.pl jest zamieniany na ciąg zer i jedynek w postaci elektrycznej i wysyłany, z wykorzystaniem na przykład przewodowej karty sieciowej Ethernet lub jednego ze standardów połączeń bezprzewodowych Wi-Fi. Nasze żądanie idzie w świat i dzięki protokołowi IP przebywa drogę do hosta docelowego.

8. Ramka dociera do najniższej warstwy hosta docelowego - warstwy dostępu do sieci. 

Weryfikowany jest adres MAC podany w ramce i jeżeli jest on taki sam, jak adres MAC hosta docelowego, zwartość ramki jest przetwarzana w wyższych warstwach. A to oznacza, że zdejmujemy ramkę i idziemy wyżej, bo informacje w niej zawarte spełniły już swoje zadanie.

9. W warstwie Internetu host za pomocą adresu IP rozpoznaje, że dane są kierowane do niego.

10. W warstwie transportowej protokół TCP zapewnia, że wszystkie pakiety IP składające się na pojedynczy transport danych dotarły do celu.

W razie potrzeby wysyła prośbę o ponowne nadesłanie brakującego pakietu. Zapewnia, że pakiety zostały scalone w odpowiedniej kolejności. W ten sposób, po usunięciu nagłówka TCP, mamy na hoście docelowym czysty request HTTP GET. Request jest kierowany na docelowy port 80.

11. Serwer WWW (specjalna aplikacja udostępniająca usługi WWW), nasłuchujący na porcie 80, przyjmuje request HTTP GET, procesuje go i odpowiada nam responsem w postaci strony WWW. Response pokonuje analogiczną drogę, ale w drugą stronę.

W ten sposób bardzo ogólnie opisaliśmy komunikację w sieci Internet od środka. ;)