Część 5: Warstwy Wyższe OSI w sieciach WLAN

Wprowadzenie do Warstw Wyższych

Witam Państwa na naszym finałowym spotkaniu.
Przebyliśmy długą drogę, od fizycznych fal radiowych, przez ramki i adresy MAC, aż po globalny routing oparty na adresach IP.
Dziś wspinamy się na szczyt modelu OSI, aby omówić warstwy wyższe: Transportową, Sesji, Prezentacji i Aplikacji.
To właśnie te warstwy przekształcają surową komunikację sieciową w użyteczne i niezawodne usługi, z których korzystamy na co dzień.
Zobaczymy, jak zapewniana jest niezawodność transmisji, jak zarządzane są dialogi między aplikacjami i wreszcie, jak protokoły takie jak HTTP czy DNS umożliwiają nam przeglądanie stron internetowych przez naszą sieć Wi-Fi.

Strażnik niezawodności i porządku

Warstwa transportowa jest sercem komunikacji "od końca do końca" (end-to-end).
Podczas gdy warstwy niższe zajmowały się przesyłaniem danych między sąsiednimi urządzeniami, warstwa 4 odpowiada za komunikację między konkretnymi aplikacjami na komputerze źródłowym i docelowym.
Jej głównym zadaniem jest zapewnienie niezawodnego dostarczania danych, kontrolowanie przepływu, aby szybszy nadawca nie "zalał" wolniejszego odbiorcy, a także dzielenie dużych porcji danych na mniejsze segmenty i składanie ich z powrotem w odpowiedniej kolejności.
To ona decyduje, czy komunikacja ma być szybka i zawodna, czy wolniejsza, ale w 100% gwarantowana.

Jak dane trafiają do właściwego programu?

Na jednym komputerze może działać jednocześnie wiele aplikacji korzystających z sieci: przeglądarka, klient poczty, komunikator.
Jak system operacyjny wie, które dane są przeznaczone dla której aplikacji?
Służą do tego numery portów.
Port to 16-bitowa liczba (od 0 do 65535) działająca jak numer "drzwi" lub "okienka" dla konkretnej usługi.
Każde połączenie sieciowe jest jednoznacznie identyfikowane przez parę: adres IP i numer portu.
Na przykład, gdy łączymy się ze stroną WWW, nasza przeglądarka wysyła dane na adres IP serwera i standardowy port 80 (dla HTTP) lub 443 (dla HTTPS).

Punkt końcowy komunikacji

Połączenie adresu IP z numerem portu tworzy unikalny punkt końcowy komunikacji, zwany gniazdem (socket).
Pełne połączenie sieciowe jest definiowane przez parę gniazd: gniazdo na komputerze źródłowym i gniazdo na komputerze docelowym.
Na przykład, gdy przeglądarka na Twoim laptopie łączy się z serwerem Google, pełna specyfikacja połączenia może wyglądać tak:
Gniazdo źródłowe: `192.168.1.10:51234` (Twój IP : losowy port)
Gniazdo docelowe: `142.250.203.196:443` (IP Google : port HTTPS)
To właśnie dzięki unikalności tej kombinacji Twój router i komputer potrafią zarządzać wieloma jednoczesnymi połączeniami z różnych aplikacji i kart przeglądarki.

Niezawodność kontra Szybkość

Warstwa transportowa oferuje dwa główne protokoły, które realizują zupełnie różne filozofie komunikacji.
TCP (Transmission Control Protocol): Protokół zorientowany na połączenie, niezawodny i uporządkowany. Gwarantuje, że wszystkie dane dotrą do celu w całości i w odpowiedniej kolejności. Jest jak list polecony z potwierdzeniem odbioru.
UDP (User Datagram Protocol): Protokół bezpołączeniowy, prosty, szybki i zawodny. Wysyła dane i "nie ogląda się za siebie". Nie ma żadnej gwarancji dostarczenia ani zachowania kolejności. Jest jak zwykła kartka pocztowa.
Wybór między TCP a UDP zależy wyłącznie od wymagań aplikacji.

"Czy mnie słyszysz? Tak, słyszę. OK, zaczynamy."

Zanim TCP zacznie przesyłać jakiekolwiek dane, musi najpierw ustanowić formalne połączenie między klientem a serwerem.
Służy do tego proces zwany trójetapowym uzgadnianiem (3-Way Handshake).
1. SYN: Klient wysyła do serwera segment z ustawioną flagą SYN (Synchronize), inicjując połączenie i proponując swój numer sekwencyjny.
2. SYN-ACK: Serwer, jeśli jest gotowy, odpowiada segmentem z flagami SYN i ACK (Acknowledgement). Potwierdza w ten sposób otrzymanie prośby klienta i również proponuje swój numer sekwencyjny.
3. ACK: Klient odsyła ostatni segment, z ustawioną flagą ACK, potwierdzając otrzymanie odpowiedzi serwera.
Po tej wymianie połączenie jest ustanowione i obie strony są gotowe do wymiany danych.

TCP: Nawiązywanie Połączenia (3-Way Handshake)

Gwarancja porządku i dostarczenia

TCP dzieli strumień danych na mniejsze części zwane segmentami.
Każdy bajt w strumieniu danych jest numerowany, a każdy segment w swoim nagłówku przenosi numer sekwencyjny (Sequence Number) pierwszego bajtu danych w tym segmencie.
Dzięki temu odbiorca potrafi złożyć segmenty z powrotem w odpowiedniej kolejności, nawet jeśli pakiety IP dotarły w innym porządku.
Aby zagwarantować dostarczenie, odbiorca po otrzymaniu segmentu odsyła potwierdzenie (Acknowledgement - ACK), w którym podaje numer sekwencyjny następnego bajtu, jakiego się spodziewa.
Jeśli nadawca nie otrzyma ACK w określonym czasie, retransmituje brakujący segment.

"Mów wolniej, nie nadążam!"

TCP implementuje mechanizm kontroli przepływu, aby zapobiec sytuacji, w której szybki nadawca "zalewa" danymi wolniejszego odbiorcę, prowadząc do przepełnienia jego buforów i utraty danych.
Służy do tego mechanizm okna przesuwnego (Sliding Window).
W każdym wysyłanym segmencie ACK, odbiorca informuje nadawcę, ile ma jeszcze wolnego miejsca w swoim buforze.
Wartość ta, zwana rozmiarem okna (Window Size), mówi nadawcy, ile danych może wysłać, zanim będzie musiał czekać na kolejne potwierdzenie.
Jeśli bufor odbiorcy zaczyna się zapełniać, ogłasza on mniejszy rozmiar okna, co zmusza nadawcę do zwolnienia transmisji.

Dostosowanie do warunków w sieci

Oprócz kontroli przepływu (dostosowanie do odbiorcy), TCP musi również radzić sobie z zatłoczeniem (congestion) w samej sieci, czyli na routerach pośredniczących.
Gdy routery są przeciążone, zaczynają gubić pakiety.
TCP interpretuje utratę pakietów (brak ACK) jako sygnał zatłoczenia.
W odpowiedzi, drastycznie zmniejsza swoją szybkość nadawania (zmniejsza tzw. okno zatłoczenia - Congestion Window), a następnie powoli, wykładniczo (algorytm Slow Start), a potem liniowo, próbuje ją znowu zwiększać, badając, na ile "pozwala" sieć.
Ten ciągły proces adaptacji sprawia, że TCP jest "grzecznym" protokołem, który stara się nie przeciążać Internetu.

TCP: Kontrola Zatłoczenia (Congestion Control)

Gdy utrata pakietu nie oznacza zatłoczenia

Mechanizmy kontroli zatłoczenia TCP zostały zaprojektowane z myślą o sieciach przewodowych, gdzie utrata pakietów jest rzadka i prawie zawsze oznacza przeciążenie routera.
W sieciach Wi-Fi jest inaczej – pakiety są często gubione z powodu zakłóceń, kolizji czy słabego sygnału, a nie zatłoczenia w Internecie.
Niestety, standardowy TCP nie potrafi tego rozróżnić.
Dla niego utrata ramki Wi-Fi (i brak ACK) to sygnał, że sieć jest zapchana, co powoduje niepotrzebne i drastyczne spowolnienie transmisji.
Jest to fundamentalny problem wydajnościowy, który próbuje się rozwiązywać za pomocą różnych algorytmów optymalizujących działanie TCP w środowiskach bezprzewodowych.

Szybkość ponad wszystko

UDP (User Datagram Protocol) to drugi, znacznie prostszy protokół warstwy transportowej.
Jest bezpołączeniowy – po prostu bierze dane od aplikacji, pakuje je w jednostkę zwaną datagramem, dodaje bardzo prosty nagłówek (zawierający tylko porty źródłowy i docelowy oraz sumę kontrolną) i przekazuje do warstwy IP.
UDP nie numeruje datagramów, nie potwierdza ich odbioru, nie porządkuje i nie kontroluje przepływu.
Jest szybki, lekki i ma minimalny narzut.
Cała odpowiedzialność za ewentualne sprawdzenie, czy dane dotarły i czy są w dobrej kolejności, jest przerzucona na aplikację.

Kiedy strata nie jest katastrofą?

Kiedy chcielibyśmy używać zawodnego protokołu?
Wszędzie tam, gdzie szybkość i minimalne opóźnienia są ważniejsze niż 100% niezawodność.
UDP jest idealny dla aplikacji czasu rzeczywistego.
W rozmowie VoIP lub wideokonferencji, utrata jednego małego pakietu z próbką dźwięku spowoduje co najwyżej krótkie, prawie niesłyszalne zakłócenie.
Czekanie na retransmisję tego pakietu (jak w TCP) byłoby bezsensowne, bo dźwięk i tak dotarłby z opóźnieniem.
Podobnie w grach online – informacja o pozycji gracza sprzed pół sekundy jest bezużyteczna; liczy się jak najszybciejsze dostarczenie tej aktualnej.
UDP jest również używane w prostych protokołach typu zapytanie-odpowiedź, jak DNS i DHCP.

Wybór odpowiedniego narzędzia

Podsumowując, wybór między TCP a UDP to fundamentalna decyzja architektoniczna dla każdej aplikacji sieciowej.
Jeśli aplikacja wymaga absolutnej pewności, że wszystkie dane dotrą w nienaruszonym stanie i w poprawnej kolejności, wybór jest prosty: TCP.
Jest to przypadek przeglądarek WWW, klientów poczty, transferu plików (FTP) czy terminali (SSH).
Jeśli natomiast aplikacja jest wrażliwa na opóźnienia, a utrata niewielkiej części danych jest akceptowalna, lub jeśli sama aplikacja implementuje własne mechanizmy niezawodności, wtedy znacznie lepszym wyborem będzie szybkie i lekkie UDP.

Najlepsze z obu światów

W ostatnich latach na popularności zyskuje nowy protokół warstwy transportowej, opracowany przez Google, o nazwie QUIC (Quick UDP Internet Connections).
Działa on "na wierzchu" UDP, ale implementuje wiele zaawansowanych funkcji znanych z TCP, takich jak niezawodność, kontrola zatłoczenia i porządkowanie strumieni – robi to jednak w znacznie bardziej nowoczesny i wydajny sposób.
QUIC domyślnie szyfruje całą transmisję, nawiązuje połączenie znacznie szybciej niż TCP (w jednym obiegu) i lepiej radzi sobie ze zmianami sieci (np. przełączeniem z Wi-Fi na LTE).
Jest on fundamentem protokołu HTTP/3 i coraz szerzej zastępuje klasyczne połączenia TCP w nowoczesnych usługach internetowych.

Zarządca dialogu

Wchodzimy na terytorium warstw, których funkcje w nowoczesnym internecie są często wchłaniane przez warstwę aplikacji.
Teoretycznie, warstwa sesji jest odpowiedzialna za nawiązywanie, zarządzanie i kończenie sesji, czyli dialogów między aplikacjami na dwóch różnych hostach.
Można ją przyrównać do reżysera rozmowy: dba o to, kto mówi teraz (kontrola dialogu), umieszcza "punkty kontrolne" w długiej transmisji, aby w razie awarii nie trzeba było zaczynać od początku (synchronizacja), i formalnie kończy rozmowę.
W praktyce, większość tych zadań realizują same protokoły aplikacyjne, a warstwa sesji jako oddzielny byt rzadko występuje.

Sesja jako rozmowa telefoniczna

Dobrą analogią do działania warstwy sesji jest klasyczna rozmowa telefoniczna.
Nawiązanie sesji: Wykręcenie numeru, oczekiwanie na sygnał, druga osoba odbiera i mówi "halo".
Zarządzanie sesją: Obie strony prowadzą dialog. Wiadomo, kto mówi, a kto słucha. Jeśli rozmowa jest długa i dotyczy ważnych spraw, co jakiś czas podsumowujemy: "OK, czyli do tej pory uzgodniliśmy, że...". To są właśnie punkty kontrolne.
Zakończenie sesji: Jedna ze stron mówi "do usłyszenia" i odkłada słuchawkę. Połączenie jest formalnie zrywane.
Warstwa sesji zapewnia, że ten logiczny dialog między aplikacjami przebiega w sposób uporządkowany.

Gdzie można spotkać Warstwę 5?

Chociaż warstwa sesji nie jest tak wyraźnie widoczna jak inne, jej koncepcje można odnaleźć w wielu protokołach.
Przykładem mogą być zdalne wywołania procedur (RPC - Remote Procedure Call), gdzie program na jednym komputerze wywołuje funkcję na innym, jakby była ona lokalna.
Mechanizmy sesyjne dbają o to, by żądanie i odpowiedź były poprawnie sparowane.
Innym przykładem są protokoły używane w tele- i wideokonferencjach (np. SIP - Session Initiation Protocol), które jawnie nawiązują, modyfikują i kończą sesje multimedialne.
Nawet logowanie do systemu bankowego przez przeglądarkę tworzy "sesję" na poziomie aplikacji, która wygasa po pewnym czasie bezczynności.

Praktyczne przykłady użycia Warstwy Sesji

Uniwersalny tłumacz danych

Zadaniem warstwy prezentacji jest zapewnienie, że dane wysłane przez warstwę aplikacji jednego systemu będą w pełni zrozumiałe dla warstwy aplikacji systemu docelowego.
Działa ona jak uniwersalny tłumacz i formater danych.
Odpowiada za trzy główne zadania.
Po pierwsze, za tłumaczenie formatów, np. konwersję między różnymi systemami kodowania znaków (jak ASCII i EBCDIC).
Po drugie, za szyfrowanie i deszyfrowanie danych w locie, aby zapewnić poufność transmisji.
Po trzecie, za kompresję i dekompresję, w celu zmniejszenia ilości przesyłanych danych i oszczędności pasma.

Jak zapewnić, że "A" to zawsze "A"?

Różne systemy komputerowe mogą historycznie używać różnych sposobów reprezentacji danych.
Na przykład, komputery typu mainframe często używały kodowania znaków EBCDIC, podczas gdy większość współczesnych systemów używa ASCII lub Unicode (UTF-8).
Warstwa prezentacji dba o to, aby dane zostały przekonwertowane na wspólny, pośredni format (np. ASN.1 - Abstract Syntax Notation One) przed wysłaniem, a następnie z powrotem na format natywny po stronie odbiorcy.
W nowoczesnym internecie rolę takiego wspólnego formatu często pełnią standardy takie jak XML (eXtensible Markup Language) czy JSON (JavaScript Object Notation), które pozwalają na strukturalny i czytelny dla maszyn (i ludzi) opis danych.

Zapewnienie poufności

Najważniejszą i najbardziej widoczną funkcją warstwy prezentacji we współczesnym internecie jest szyfrowanie.
Protokoły takie jak TLS (Transport Layer Security) i jego poprzednik SSL (Secure Sockets Layer) działają właśnie na tej warstwie.
Kiedy łączymy się ze stroną banku przez HTTPS, to właśnie warstwa prezentacji w naszej przeglądarce inicjuje "uścisk dłoni" TLS z serwerem, negocjuje klucze szyfrujące, a następnie szyfruje wszystkie dane wysyłane przez aplikację (HTTP) przed przekazaniem ich do warstwy transportowej (TCP).
Po stronie serwera zachodzi proces odwrotny.
Dzięki temu cała komunikacja jest poufna i zabezpieczona przed podsłuchem.

Mniej bitów, szybszy transfer

Kolejnym zadaniem warstwy prezentacji jest kompresja danych.
Przed wysłaniem, dane mogą zostać poddane algorytmom kompresji (takim jak gzip, deflate czy brotli), aby zmniejszyć ich objętość.
Mniejsza ilość danych oznacza szybszy transfer i mniejsze obciążenie sieci, co jest szczególnie ważne w sieciach o ograniczonej przepustowości, takich jak sieci komórkowe czy wolne połączenia Wi-Fi.
Po stronie odbiorcy, warstwa prezentacji musi oczywiście dokonać dekompresji, aby przywrócić dane do oryginalnej postaci, zanim przekaże je do aplikacji.
Kompresja jest powszechnie stosowana na przykład przez serwery WWW do zmniejszania rozmiaru plików HTML, CSS i JavaScript.

Interfejs do świata sieci

Wreszcie docieramy na sam szczyt: do warstwy aplikacji.
Jest to warstwa najbliższa użytkownikowi, ale uwaga – to nie jest sama aplikacja (jak Chrome czy Outlook)!
Jest to warstwa, która dostarcza protokoły sieciowe, z których te aplikacje korzystają, aby komunikować się przez sieć.
Innymi słowy, warstwa aplikacji definiuje reguły komunikacji dla konkretnych zadań: jak pobrać stronę WWW, jak wysłać e-mail, jak rozwiązać nazwę domeny.
Udostępnia ona interfejs programistyczny (API), który pozwala programistom na łatwe tworzenie aplikacji sieciowych bez martwienia się o szczegóły niższych warstw.

Język globalnej sieci

HTTP (Hypertext Transfer Protocol) to fundamentalny protokół warstwy aplikacji, na którym opiera się cała sieć World Wide Web.
Działa on w modelu klient-serwer.
Przeglądarka (klient) wysyła do serwera WWW żądanie (HTTP Request), np. `GET /index.html`, prosząc o dany zasób.
Serwer przetwarza żądanie i odsyła odpowiedź (HTTP Response), która zawiera kod statusu (np. `200 OK`) oraz treść zasobu (np. kod HTML strony).
HTTPS (HTTP Secure) to po prostu protokół HTTP działający wewnątrz bezpiecznego, szyfrowanego tunelu TLS.
Cały ten proces, od wysłania żądania do otrzymania odpowiedzi, odbywa się oczywiście przez naszą sieć Wi-Fi.

Rola DNS w Warstwie Aplikacji

Chociaż o DNS mówiliśmy już przy warstwie sieciowej (bo jest niezbędny do uzyskania adresu IP), sam protokół DNS jest protokołem warstwy aplikacji.
Definiuje on format zapytań i odpowiedzi, które aplikacje (a konkretnie, systemowy resolver) wysyłają do serwerów DNS.
Zapytanie DNS to prosta wiadomość, zazwyczaj wysyłana przez UDP na port 53, zawierająca nazwę domeny, o którą pytamy.
Odpowiedź zawiera znaleziony adres IP lub informację o błędzie.
Proces ten, zwany rozwiązywaniem nazwy, musi zajść przed nawiązaniem niemal każdego połączenia w internecie.

Automatyczna konfiguracja jako usługa

Podobnie jak DNS, protokół DHCP, mimo że jego celem jest konfiguracja warstwy 3 (adresu IP), sam w sobie jest protokołem działającym w modelu klient-serwer w warstwie aplikacji.
Definiuje on format i sekwencję wiadomości (Discover, Offer, Request, ACK), które są wymieniane między klientem a serwerem.
Wiadomości te są "opakowywane" w datagramy UDP (klient wysyła na port 67, serwer odpowiada na port 68), a następnie w pakiety IP i ramki.
To pokazuje, jak warstwy współpracują ze sobą – protokół warstwy aplikacji (DHCP) jest używany do skonfigurowania niższej warstwy (IP).

Jak działa e-mail?

Obsługa poczty elektronicznej opiera się na zestawie protokołów warstwy aplikacji.
Do wysyłania e-maili służy SMTP (Simple Mail Transfer Protocol).
Kiedy klikamy "Wyślij", nasz klient poczty łączy się z serwerem SMTP (zwykle na porcie 25 lub 587) i "rozmawia" z nim, przekazując adresata, nadawcę i treść wiadomości.
Do odbierania poczty służą dwa protokoły.
Starszy, POP3 (Post Office Protocol), domyślnie pobiera wiadomości z serwera i usuwa je z niego, przechowując je lokalnie na naszym komputerze.
Nowszy i znacznie popularniejszy, IMAP (Internet Message Access Protocol), synchronizuje zawartość skrzynki z serwerem, przechowując wszystkie wiadomości i foldery na serwerze, co pozwala na dostęp do tej samej poczty z wielu urządzeń.

Transfer plików

Do przesyłania plików między komputerami służy FTP (File Transfer Protocol).
Jest to stary, ale wciąż używany protokół, który wykorzystuje dwa oddzielne połączenia TCP: jedno do przesyłania poleceń (kanał kontrolny, port 21) i drugie do przesyłania samych danych (kanał danych).
Standardowy FTP jest niezabezpieczony – hasła i dane przesyłane są jawnym tekstem.
Jego bezpiecznymi następcami są FTPS (FTP działający w tunelu TLS/SSL) oraz, co jest zupełnie innym protokołem, SFTP (SSH File Transfer Protocol), który jest rozszerzeniem protokołu SSH i całą komunikację realizuje w ramach jednego, bezpiecznego połączenia.

Bezpieczny zdalny dostęp

SSH (Secure Shell) to kluczowy protokół warstwy aplikacji, który pozwala na bezpieczny, szyfrowany zdalny dostęp do wiersza poleceń innego komputera (najczęściej serwera).
Zastąpił on stary i niezabezpieczony protokół Telnet.
Połączenie SSH, nawiązywane na porcie 22, szyfruje całą sesję, w tym proces uwierzytelniania (logowanie) oraz wszystkie przesyłane polecenia i ich wyniki.
Uniemożliwia to podsłuchiwanie haseł i przejęcie kontroli nad sesją.
SSH jest podstawowym narzędziem pracy każdego administratora systemów i sieci.

Model dominujący w Internecie

Większość protokołów, które omówiliśmy (HTTP, FTP, SMTP), działa w architekturze klient-serwer.
W tym modelu mamy do czynienia z dwoma typami oprogramowania.
Serwer to program, który działa pasywnie, nasłuchując na znanym porcie na przychodzące żądania.
Jest on dostawcą usługi lub zasobu.
Klient to program, który aktywnie inicjuje komunikację, wysyłając żądanie do serwera, a następnie oczekuje na odpowiedź.
Nasza przeglądarka jest klientem, a serwer, na którym znajduje się strona WWW, jest serwerem.
Ta asymetryczna relacja jest podstawą działania większości usług internetowych.

Wszyscy są równi

Alternatywą dla modelu klient-serwer jest architektura Peer-to-Peer (P2P).
W sieci P2P nie ma centralnego serwera.
Każdy uczestnik sieci (zwany "peerem" lub węzłem) jest równy i może pełnić jednocześnie rolę zarówno klienta, jak i serwera – pobierać dane od innych i jednocześnie udostępniać je innym.
Ten zdecentralizowany model jest bardzo odporny na awarie (nie ma jednego punktu, który może zawieść) i doskonale skalowalny.
Im więcej użytkowników dołącza do sieci, tym większa jest jej łączna przepustowość.
Architektura P2P jest wykorzystywana m.in. w systemach wymiany plików (np. BitTorrent), niektórych komunikatorach i kryptowalutach.

Jak aplikacje ze sobą rozmawiają?

W nowoczesnym internecie aplikacje i usługi nieustannie komunikują się ze sobą, wymieniając dane.
Służą do tego API (Application Programming Interface).
API to formalny zbiór reguł i definicji, który określa, w jaki sposób jedna aplikacja może żądać usług lub danych od drugiej.
Najpopularniejszym stylem architektonicznym dla API webowych jest REST (Representational State Transfer).
API typu REST zazwyczaj komunikuje się za pomocą protokołu HTTP, a dane wymienia w formacie JSON.
Na przykład, aplikacja pogodowa na Twoim telefonie nie ma w sobie danych o pogodzie.
Używa ona API, aby wysłać żądanie HTTP do serwera pogodowego (`GET /pogoda?miasto=Warszawa`), który w odpowiedzi odsyła dane w formacie JSON.

Teoria kontra Praktyka

Przez cały kurs posługiwaliśmy się 7-warstwowym modelem OSI.
Jest on doskonałym modelem teoretycznym, który precyzyjnie rozdziela funkcje sieciowe.
W praktyce jednak, świat Internetu jest zbudowany w oparciu o prostszy, 4-warstwowy model TCP/IP (zwany też modelem DoD).
W tym modelu funkcje warstw Aplikacji, Prezentacji i Sesji z modelu OSI są połączone w jedną, wspólną warstwę Aplikacji.
Podobnie, warstwy Łącza Danych i Fizyczna są połączone w warstwę Dostępu do Sieci.
Model TCP/IP jest modelem praktycznym, który opisuje, jak faktycznie zaimplementowano protokoły internetowe.

Synchronizacja czasu w sieci

Czy zastanawiali się Państwo, skąd komputery i urządzenia sieciowe "wiedzą", która jest godzina?
Za synchronizację zegarów w sieci odpowiada protokół warstwy aplikacji NTP (Network Time Protocol).
Urządzenia (klienci NTP) okresowo wysyłają zapytania do serwerów NTP (działających na porcie UDP 123).
Serwery te to komputery o bardzo wysokiej precyzji, często zsynchronizowane z zegarami atomowymi.
Protokół NTP jest zaprojektowany tak, aby uwzględniać opóźnienia sieciowe i pozwalać na synchronizację zegarów z dokładnością do milisekund.
Precyzyjny czas jest absolutnie kluczowy w sieciach, m.in. do poprawnego działania logów systemowych, mechanizmów uwierzytelniania (np. Kerberos) i szyfrowania.

Zarządzanie i monitorowanie sieci

SNMP to protokół warstwy aplikacji służący do zarządzania i monitorowania urządzeń sieciowych, takich jak routery, przełączniki czy punkty dostępowe.
Działa w modelu menedżer-agent.
Na każdym zarządzanym urządzeniu działa agent SNMP, który zbiera statystyki (np. obciążenie procesora, ruch na interfejsach) i przechowuje je w bazie MIB (Management Information Base).
Menedżer SNMP (stacja zarządzająca) może odpytywać agentów o te informacje (SNMP GET), a także zmieniać ich konfigurację (SNMP SET).
Agenci mogą również samoczynnie wysyłać do menedżera alerty (Traps) w przypadku wystąpienia ważnych zdarzeń, np. awarii interfejsu.

SNMP (Simple Network Management Protocol)

Centralne zbieranie logów

Syslog to standardowy protokół służący do centralnego gromadzenia logów (dzienników zdarzeń) z różnych urządzeń i systemów w sieci.
Każde urządzenie (router, firewall, serwer) może być skonfigurowane tak, aby wysyłało swoje komunikaty logów w czasie rzeczywistym do centralnego serwera Syslog.
Komunikaty są wysyłane jako proste datagramy UDP na port 514.
Zawierają one informację o czasie zdarzenia, jego ważności (od "debug" po "emergency") oraz samą treść komunikatu.
Centralne zbieranie logów jest kluczowe dla monitorowania stanu sieci, diagnozowania problemów i analizy incydentów bezpieczeństwa.

Niezabezpieczony zdalny dostęp

Przed erą SSH, standardowym protokołem do zdalnego zarządzania urządzeniami był Telnet.
Działa on na porcie TCP 23 i pozwala na uzyskanie dostępu do wiersza poleceń zdalnego systemu.
Jego fundamentalną i dyskwalifikującą dziś wadą jest całkowity brak szyfrowania.
Wszystkie dane, w tym login, hasło oraz cała sesja, są przesyłane przez sieć jako jawny tekst.
Oznacza to, że każdy, kto jest w stanie podsłuchać ruch w sieci (co w Wi-Fi jest trywialne), może przechwycić poświadczenia i uzyskać pełny dostęp do zarządzanego urządzenia.
Z tego powodu Telnet nie powinien być nigdy używany w niezaufanych sieciach.

Transport dla danych czasu rzeczywistego

Aplikacje takie jak VoIP czy streaming wideo używają UDP do transportu danych, ale sam UDP nie dostarcza żadnych informacji o synchronizacji czasowej.
Tę rolę pełni RTP (Real-time Transport Protocol), protokół warstwy aplikacji, który działa "na wierzchu" UDP.
Każdy pakiet RTP, oprócz danych (np. próbki dźwięku), zawiera w nagłówku znacznik czasu (timestamp) oraz numer sekwencyjny.
Pozwala to odbiorcy na odtworzenie multimediów w poprawnej kolejności i z odpowiednią synchronizacją, a także na kompensację zjawiska "jitter" (zmienności opóźnień).
RTP często towarzyszy protokół RTCP (RTP Control Protocol), który służy do przesyłania statystyk o jakości transmisji.

Nawiązywanie rozmów VoIP

Jak telefon VoIP wie, jak "zadzwonić" na inny numer?
Do sygnalizacji, czyli nawiązywania, modyfikowania i kończenia sesji multimedialnych (np. rozmów głosowych), służy protokół warstwy aplikacji SIP (Session Initiation Protocol).
Działa on w modelu tekstowym, podobnym do HTTP.
Kiedy dzwonimy, nasz telefon wysyła do serwera SIP (tzw. centrali PBX) wiadomość `INVITE`, zapraszając drugiego użytkownika do rozmowy.
Serwer lokalizuje drugiego użytkownika i przekazuje mu zaproszenie.
Po wymianie kilku wiadomości i zaakceptowaniu połączenia, SIP "schodzi z drogi", a właściwa transmisja głosu odbywa się już bezpośrednio między telefonami za pomocą RTP/UDP.

Dostęp do folderów sieciowych

Protokół SMB (Server Message Block), znany też pod starszą nazwą CIFS (Common Internet File System), to protokół warstwy aplikacji dominujący w sieciach opartych na systemie Windows.
Służy on do udostępniania plików, drukarek i innych zasobów w sieci lokalnej.
Kiedy w Eksploratorze Windows otwieramy folder sieciowy, nasz komputer używa protokołu SMB (zazwyczaj przez TCP na porcie 445), aby komunikować się z serwerem plików, listować zawartość katalogów, odczytywać i zapisywać pliki.
SMB implementuje również własne mechanizmy uwierzytelniania i autoryzacji, kontrolując, kto i jaki ma dostęp do udostępnionych zasobów.

SMB/CIFS: Udostępnianie plików w Windows

Udostępnianie plików w świecie Linux/Unix

Odpowiednikiem SMB w świecie systemów uniksowych i linuksowych jest NFS (Network File System).
Jest to również protokół warstwy aplikacji, który pozwala na "zamontowanie" zdalnego systemu plików na lokalnym komputerze, tak że staje się on widoczny jako zwykły katalog.
Z perspektywy użytkownika i aplikacji, operacje na plikach w zamontowanym katalogu NFS są przezroczyste i wyglądają tak samo jak operacje na plikach lokalnych.
System operacyjny w tle tłumaczy te operacje na zdalne wywołania procedur (RPC) i wysyła je przez sieć do serwera NFS.

Jak urządzenia znajdują się w sieci lokalnej?

W nowoczesnych sieciach domowych urządzenia potrafią automatycznie wykrywać siebie nawzajem bez żadnej konfiguracji (konfiguracja "zero-touch").
Drukarka pojawia się na liście dostępnych drukarek, a telewizor na liście urządzeń do strumieniowania.
Odpowiadają za to protokoły wykrywania usług warstwy aplikacji, takie jak mDNS (multicast DNS), używany przez Apple (Bonjour) i wiele innych systemów.
Urządzenie rozgłasza w sieci lokalnej (przez multicast na adres 224.0.0.251) swoje nazwy i usługi.
Innym popularnym protokołem jest SSDP (Simple Service Discovery Protocol), będący częścią standardu UPnP, używany do wykrywania np. serwerów mediów.

Automatyzacja konfiguracji sieciowej

UPnP to zbiór protokołów warstwy aplikacji, którego celem jest ułatwienie komunikacji między urządzeniami w sieci lokalnej.
Jedną z jego najbardziej znanych (i kontrowersyjnych) funkcji jest IGD (Internet Gateway Device).
Pozwala on aplikacjom na naszym komputerze (np. grom P2P) na automatyczne konfigurowanie routera i otwieranie portów (tworzenie reguł NAT).
Zamiast ręcznie logować się do routera i przekierowywać port, aplikacja sama wysyła do routera (który musi wspierać UPnP) polecenie: "Proszę, przekieruj ruch z publicznego portu 12345 na mój wewnętrzny port 12345".
Ułatwia to życie, ale bywa też krytykowane jako potencjalna dziura w bezpieczeństwie.

Najczęstszy cel ataków

Warstwa aplikacji jest najczęstszym celem ataków, ponieważ jest najbliżej danych użytkownika i często zawiera luki w implementacji.
Zagrożenia są bardzo różnorodne.
Mogą to być ataki na aplikacje webowe, takie jak SQL Injection (wstrzykiwanie złośliwego kodu SQL do zapytań do bazy danych) czy Cross-Site Scripting (XSS) (wstrzykiwanie złośliwego kodu JavaScript do strony WWW).
Inne zagrożenia to malware (wirusy, trojany), które wykorzystują protokoły aplikacyjne do rozprzestrzeniania się, oraz phishing, czyli ataki socjotechniczne, w których atakujący podszywa się pod zaufaną usługę (np. bank), aby wyłudzić poświadczenia.

Inteligentna ochrona usług

Tradycyjny firewall warstwy 3/4 filtruje ruch na podstawie adresów IP i portów.
Nie jest on jednak w stanie zrozumieć, co dzieje się wewnątrz samej komunikacji aplikacyjnej.
Do tego służy WAF (Web Application Firewall).
Jest to specjalizowany firewall, który działa na warstwie 7 i potrafi analizować treść żądań i odpowiedzi HTTP.
Rozumie on logikę protokołu i potrafi wykryć próby ataków, takich jak SQL Injection czy XSS, nawet jeśli przechodzą one przez standardowy, dozwolony port 443.
WAF działa jak inteligentny strażnik stojący przed serwerem WWW, który dokładnie sprawdza "zawartość każdej przesyłki", a nie tylko jej "adres".

Logowanie do publicznych sieci Wi-Fi

Kiedy łączymy się z publiczną siecią Wi-Fi w hotelu lub na lotnisku, często pierwszą rzeczą, jaką widzimy, jest strona logowania lub strona z regulaminem, którą musimy zaakceptować.
Mechanizm ten, zwany Captive Portal, to inteligentne wykorzystanie protokołów warstw wyższych.
Po połączeniu się z siecią, punkt dostępowy lub router przechwytuje wszystkie nasze żądania DNS i HTTP.
Niezależnie od tego, jaką stronę próbujemy otworzyć, system przekierowuje nas na lokalną stronę portalu.
Dopiero po pomyślnym uwierzytelnieniu (np. podaniu numeru pokoju lub akceptacji regulaminu), firewall "otwiera" nam dostęp do Internetu.

Jak budowane są nowoczesne aplikacje?

Współczesne, duże aplikacje internetowe (np. Netflix, Uber) rzadko są już jednym, monolitycznym programem.
Zamiast tego, budowane są w architekturze mikrousług (microservices).
Cała aplikacja jest podzielona na dziesiątki lub setki małych, niezależnych usług, z których każda odpowiada za jedną, konkretną funkcję (np. autoryzacja użytkownika, obsługa koszyka, rekomendacje).
Te mikrousługi komunikują się ze sobą nawzajem przez sieć, najczęściej za pomocą lekkich protokołów i API (np. REST przez HTTP).
Taka architektura, hostowana w chmurze, jest niezwykle elastyczna, skalowalna i odporna na awarie.

Rozkładanie obciążenia

Popularne usługi internetowe muszą obsługiwać miliony jednoczesnych żądań.
Jeden serwer by sobie z tym nie poradził.
Dlatego stosuje się load balancing (równoważenie obciążenia).
Zamiast jednego serwera, mamy całą farmę identycznych serwerów.
Przed nimi stoi specjalne urządzenie lub oprogramowanie – load balancer.
Wszystkie żądania od użytkowników trafiają najpierw do load balancera.
Jego zadaniem jest inteligentne rozdzielanie tych żądań między dostępne serwery, tak aby żaden z nich nie był przeciążony.
Load balancery mogą działać na warstwie 4 (rozdzielając połączenia TCP) lub na warstwie 7 (rozdzielając żądania HTTP, co daje większe możliwości).

Przybliżanie treści do użytkownika

Pobieranie dużych plików (zdjęć, wideo) z serwera znajdującego się na drugim końcu świata jest wolne.
Aby to zoptymalizować, używa się sieci CDN (Content Delivery Network).
CDN to globalnie rozproszona sieć serwerów (zwanych "edge servers"), które przechowują kopie statycznych treści (obrazków, plików wideo, CSS) popularnych stron WWW.
Kiedy użytkownik w Polsce próbuje pobrać obrazek ze strony hostowanej w USA, system DNS (często wykorzystując anycast) kieruje jego żądanie nie do oryginalnego serwera w USA, ale do najbliższego mu geograficznie serwera CDN, np. w Warszawie.
Dzięki temu dane przebywają znacznie krótszą drogę, a strona ładuje się błyskawicznie.

Dwukierunkowa komunikacja w czasie rzeczywistym

Standardowy protokół HTTP działa w modelu żądanie-odpowiedź, co nie jest idealne dla aplikacji wymagających natychmiastowej, dwukierunkowej komunikacji (np. czaty, aplikacje giełdowe).
Rozwiązaniem tego problemu jest protokół WebSocket.
Jest on inicjowany przez "upgrade" standardowego połączenia HTTP.
Po nawiązaniu, tworzy on trwałe, dwukierunkowe połączenie TCP między przeglądarką a serwerem.
Od tego momentu serwer może wysyłać dane do przeglądarki w dowolnym momencie, bez potrzeby oczekiwania na jej żądanie.
Pozwala to na tworzenie prawdziwie interaktywnych aplikacji webowych, które aktualizują się w czasie rzeczywistym.

Pełna podróż danych

Prześledźmy całą drogę, jaką pokonują dane, gdy otwieramy stronę WWW w sieci Wi-Fi.
1. L7 (Aplikacji): Przeglądarka tworzy żądanie HTTP GET. Pyta DNS o adres IP serwera.
2. L6 (Prezentacji): Nawiązywana jest sesja TLS, żądanie HTTP jest szyfrowane.
3. L5 (Sesji): Zarządzany jest logiczny dialog z serwerem.
4. L4 (Transportowa): Zaszyfrowane dane są dzielone na segmenty TCP.
5. L3 (Sieciowa): Do segmentów dodawany jest nagłówek IP, tworząc pakiety adresowane do serwera.
6. L2 (Łącza Danych): Pakiety IP są pakowane w ramki 802.11, adresowane do adresu MAC punktu dostępowego.
7. L1 (Fizyczna): Ramki są zamieniane na sygnał radiowy i wysyłane w eter.
Na każdym etapie, od AP, przez routery, aż do serwera, zachodzą odpowiednie procesy dekapsułkacji i ponownej kapsułkacji.

Kapsułkowanie w praktyce: Przeglądanie strony

Spójna priorytetyzacja na całej trasie

Aby usługa Quality of Service działała skutecznie, priorytety muszą być respektowane na całej trasie komunikacji.
Nie wystarczy, że nasza sieć Wi-Fi, dzięki WMM (L2), nada wysoki priorytet pakietom VoIP.
Te oznaczenia muszą być "przetłumaczone" na odpowiednie znaczniki DSCP w nagłówku IP (L3).
Dzięki temu routery w internecie również będą wiedziały, że te pakiety są ważne.
Podobnie, sieć szkieletowa musi być skonfigurowana tak, aby honorować te znaczniki.
Tylko spójne i konsekwentne oznaczanie i traktowanie ruchu na warstwach 2, 3 i wyższych może zapewnić prawdziwą jakość usług "od końca do końca".

Gdy protokół nie lubi translacji

Niektóre starsze protokoły warstwy aplikacji źle znoszą mechanizm NAT.
Przykładem jest FTP w trybie aktywnym.
W tym trybie, klient, po nawiązaniu połączenia kontrolnego, informuje serwer: "Otwórz połączenie danych na mój adres IP 192.168.1.10 i port X".
Oczywiście, serwer w internecie nie ma pojęcia, jak połączyć się z adresem prywatnym.
Podobne problemy występują w protokole SIP, który w swoich wiadomościach również przesyła adresy IP.
Aby rozwiązać te problemy, nowoczesne routery posiadają funkcję ALG (Application-Layer Gateway).
Router "zagląda" do środka pakietów tych problematycznych protokołów i inteligentnie podmienia adresy prywatne na publiczne, pozwalając im działać przez NAT.

Dlaczego "szybkie Wi-Fi" nie zawsze wystarcza?

Na koniec warto podkreślić, że odczuwalna przez użytkownika wydajność aplikacji zależy od całej ścieżki sieciowej, a nie tylko od ostatniego, bezprzewodowego odcinka.
Możemy mieć najnowszy router Wi-Fi 6E, ale jeśli nasze połączenie z internetem jest wolne, serwer DNS odpowiada z opóźnieniem, a serwer docelowy jest przeciążony, to strony i tak będą ładować się wolno.
Każda warstwa i każdy element na trasie – od klienta, przez AP, router, sieć ISP, aż po serwer docelowy – dokłada swoje opóźnienie (latency) i stanowi potencjalne "wąskie gardło" (bottleneck).
Diagnozowanie problemów z wydajnością wymaga holistycznego spojrzenia na cały stos komunikacyjny.

Architektura sieci a wydajność aplikacji

Od niezawodności po aplikacje

Warstwy wyższe modelu OSI (4-7) odpowiadają za przekształcenie surowych możliwości przesyłania pakietów w użyteczne, niezawodne i bezpieczne usługi.
Warstwa transportowa, z jej kluczowymi protokołami TCP i UDP, decyduje o charakterze komunikacji.
Warstwy sesji i prezentacji, choć często ukryte, dbają o uporządkowanie dialogu, formatowanie danych i szyfrowanie.
Na samym szczycie, warstwa aplikacji dostarcza nam konkretne protokoły, które napędzają nasz cyfrowy świat – od przeglądania stron, przez wysyłanie e-maili, po rozmowy wideo.
Każda z tych warstw dokłada swoją "cegiełkę", tworząc razem skomplikowaną, ale spójną architekturę, która umożliwia działanie globalnego Internetu.

Podsumowanie całego kursu

Szanowni Państwo, dotarliśmy do końca naszej podróży przez świat sieci komputerowych, od fizycznej transmisji fal radiowych aż po protokoły aplikacji.
Mam nadzieję, że ten kurs dał Państwu solidne podstawy i pozwolił zrozumieć, jak skomplikowane i fascynujące mechanizmy kryją się za prostą czynnością połączenia się z siecią Wi-Fi.
Zrozumienie, jak działają poszczególne warstwy i jak współpracują ze sobą, jest kluczem do świadomego projektowania, konfigurowania i diagnozowania problemów w każdej sieci.
Dziękuję Państwu za uwagę, zaangażowanie i wszystkie pytania.
Życzę powodzenia na egzaminie i w dalszej karierze zawodowej.