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