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ądzeniaPorty

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. ;)