Współczesny globalny internet oraz zdecydowana większość prywatnych sieci korporacyjnych, przemysłowych i domowych opiera swoje działanie na jednym dominującym fundamencie technologicznym – stosie protokołów internetowych TCP/IP (Internet Protocol Suite). O ile 7-warstwowy model ISO/OSI pozostaje niedoścignionym wzorcem pojęciowym i dydaktycznym, o tyle stos TCP/IP jest rzeczywistym, działającym silnikiem oprogramowania i sprzętu sieciowego, który od ponad czterech dekad napędza rewolucję cyfrową.

Architektura TCP/IP została zaprojektowana w oparciu o fundamentalną zasadę inżynierską, zwaną zasadą klepsydry (Hourglass Architecture): na samym dole znajduje się ogromna różnorodność mediów fizycznych (Ethernet, światłowody, Wi-Fi, łączność komórkowa 5G, łącza satelitarne), a na samej górze tysiące różnorodnych aplikacji i protokołów (WWW, poczta, strumieniowanie wideo, gry online). Cała ta gigantyczna konstrukcja łączy się w jednym, wąskim przewężeniu w środku – w Warstwie Internetowej reprezentowanej przez Protokół Internetowy (IP). Wszystko na górze musi działać na protokole IP, a protokół IP potrafi działać na dowolnym medium transmisyjnym na dole.

Zrozumienie działania stosu TCP/IP wymaga poznania kluczowych standardów internetowych definiowanych przez organizację IETF (Internet Engineering Task Force) w dokumentach z serii RFC (Request for Comments). W ramach niniejszego modułu przeprowadzimy szczegółową sekcję techniczną: od historii i genezy powstania protokołów, przez anatomię nagłówków IP, mechanizmy routingu i protokołu ICMP, niezawodny transport TCP z algorytmami kontroli zatorów i przesuwnego okna, po lekki protokół UDP oraz kluczowe protokoły warstwy aplikacji, takie jak DNS i DHCP.

Piąta część kursu stanowi przejście od ogólnych ram teoretycznych modelu odniesienia do szczegółowej, praktycznej inżynierii protokołów internetowych. Zrozumienie mikro-mechanizmów rządzących przepływem danych w stosie TCP/IP jest warunkiem koniecznym do skutecznego projektowania sieci, konfiguracji routerów i zapór oraz zaawansowanej analizy ruchu pakietowego.

Plan nauczania został podzielony na następujące powiązane logicznie obszary: 1) Geneza i fundamenty – historia sieci ARPANET, rola Vinta Cerfa i Boba Kahna, przełomowy „Flag Day” z 1983 roku oraz dekompozycja 4 warstw modelu internetowego według RFC 1122; 2) Warstwa Internetowa – protokół IP jako rdzeń routingu Best-Effort, rodzina protokołów pomocniczych (ICMP, ARP) oraz szczegółowa analiza komunikatów diagnostycznych i mechanizmu TTL;

3) Warstwa Transportowa – dogłębna dekompozycja nagłówka TCP (RFC 9293), 3-drożny uścisk dłoni (Three-Way Handshake), maszyna stanów połączenia (od LISTEN po TIME_WAIT), kontrola przepływu za pomocą przesuwnego okna oraz zaawansowane algorytmy unikania przeciążeń sieciowych (Congestion Control). Konfrontacja TCP z minimalistycznym protokołem UDP (RFC 768);

4) Warstwa Aplikacji i usługi infrastrukturalne – zasada działania hierarchicznego systemu nazw domenowych DNS oraz protokołu dynamicznej konfiguracji hosta DHCP (proces DORA); 5) Zaawansowane mechanizmy i diagnostyka – translacja adresów NAT/PAT, konieczność migracji do IPv6, wektory zagrożeń (SYN Flood, IP Spoofing, zatruwanie ARP) oraz praktyczne scenariusze pomiarowe w analizatorze Wireshark.

Początki internetu sięgają końca lat 60. XX wieku i są nierozerwalnie związane z amerykańską agencją zaawansowanych projektów badawczych DARPA (Defense Advanced Research Projects Agency). W 1969 roku uruchomiono sieć ARPANET – pierwszą na świecie rozległą sieć z komutacją pakietów, łączącą węzły uniwersyteckie UCLA, Stanford, UC Santa Barbara oraz University of Utah. Komunikacja opierała się wówczas na dedykowanych minikomputerach pośredniczących zwanych IMP (Interface Message Processors) oraz bazowym protokole NCP (Network Control Program).

Protokół NCP posiadał jednak zasadnicze ograniczenie architektoniczne: zakładał, że sieć fizyczna jest wysoce niezawodna i jednorodna. Nie posiadał mechanizmów adresowania między różnymi sieciami (Internetwork Routing) ani kontroli przeciążeń. Gdy pod koniec lat 70. obok ARPANET zaczęły powstawać inne sieci eksperymentalne (radiowa sieć pakietowa PRNET oraz sieć satelitarna SATNET), okazało się, że protokół NCP nie jest w stanie ich ze sobą połączyć.

Odpowiedzią było stworzenie przez Vintona Cerfa i Roberta Kahna zupełnie nowej architektury TCP/IP. Kluczową datą w historii teleinformatyki stał się 1 stycznia 1983 roku, znany jako „Flag Day” (Dzień Flagi), zorganizowany według wytycznych dokumentu RFC 801. Tego dnia obsługa protokołu NCP została bezpowrotnie wyłączona na wszystkich węzłach ARPANET, a cała sieć została synchronicznie przełączona na stos TCP/IP. Od tego momentu sieć połączonych sieci (Internetwork) stała się rzeczywistością, dając początek współczesnemu internetowi.

Architektura współczesnego internetu jest dziełem dwóch wybitnych amerykańskich naukowców i inżynierów, powszechnie uznawanych za „ojców internetu”: Roberta (Boba) Kahna oraz Vintona (Vinta) Cerfa. W 1973 roku podjęli oni współpracę w agencji DARPA nad fundamentalnym problemem: jak połączyć ze sobą heterogeniczne sieci komputerowe, z których każda korzysta z innego medium fizycznego, innego formatu pakietów i innych prędkości transmisji?

Wyniki swoich prac opublikowali w maju 1974 roku w przełomowej publikacji naukowej „A Protocol for Packet Network Intercommunication” oraz w dokumencie RFC 675 (Specification of Internet Transmission Control Program). Zaproponowali w nich rewolucyjny paradygmat: sieć bezstanowa o architekturze otwartej (Open-Architecture Networking). W ich wizji routery pośredniczące (nazwane pierwotnie bramami – Gateways) nie śledzą stanu połączeń ani nie gwarantują dostarczenia danych – ich wyłącznym zadaniem jest szybkie przekazywanie pakietów dalej. Cała odpowiedzialność za kontrolę błędów, potwierdzenia i retransmisje została przeniesiona na hosty końcowe (tzw. End-to-End Principle).

Początkowo Cerf i Kahn zaprojektowali jednolity, monolityczny protokół nazwany po prostu TCP (Transmission Control Program), który łączył w sobie zarówno funkcje routingu i adresacji, jak i niezawodnego transportu strumieniowego. W 1978 roku inżynierowie (w tym m.in. Jon Postel i Danny Cohen) doszli do wniosku, że architektura ta jest zbyt sztywna dla aplikacji czasu rzeczywistego (takich jak cyfrowy przesył mowy), które nie potrzebują retransmisji ani gwarancji kolejności.

W efekcie w wersji 4 protokołu (1981 r.) dokonano epokowego rozdzielenia protokołu na dwa niezależne poziomy: warstwę sieciową powierzono bezpołączeniowemu protokołowi IP (Internet Protocol, RFC 791), a niezawodny transport strumieniowy wydzielono do protokołu TCP (RFC 793), tworząc równolegle miejsce dla bezpołączeniowego protokołu UDP (RFC 768). Za ten genialny wkład inżynierski obaj naukowcy zostali uhonorowani Nagrodą Turinga w 2004 roku.

W przeciwieństwie do 7-warstwowego modelu odniesienia ISO/OSI, oficjalna specyfikacja stosu protokołów internetowych – opublikowana przez organizację IETF w dokumencie RFC 1122 (Requirements for Internet Hosts – Communication Layers) – definiuje architekturę złożoną z czterech warstw funkcjonalnych:

1) Warstwa 1: Dostęp do sieci (Network Access Layer / Link Layer) – najniższy poziom stosu. Odpowiada za bezpośrednią współpracę z lokalnym medium fizycznym. Łączy w sobie funkcje warstwy fizycznej (L1) i łącza danych (L2) modelu OSI. Obejmuje sterowniki kart sieciowych, formatowanie ramek (Ethernet II, 802.11 Wi-Fi) oraz protokoły mapowania adresów logicznych na fizyczne (ARP w IPv4, NDP w IPv6);

2) Warstwa 2: Internetowa (Internet Layer) – serce całej architektury. Odpowiada za logiczne adresowanie hostów w skali globalnej, trasowanie pakietów przez niezależne systemy autonomiczne oraz kontrolę żywotności pakietu (TTL). Dominuje tu protokół IP (IPv4 oraz IPv6), wspierany przez protokół kontrolno-diagnostyczny ICMP oraz protokoły routingu (OSPF, BGP);

3) Warstwa 3: Transportowa (Transport Layer / Host-to-Host) – odpowiada za komunikację koniec-do-końca pomiędzy konkretnymi aplikacjami na hostach. Zarządza 16-bitowymi numerami portów logicznych. Dostarcza dwa diametralnie różne modele transmisji: niezawodny, połączeniowy protokół TCP oraz szybki, bezpołączeniowy protokół UDP (a także nowoczesny protokół QUIC);

4) Warstwa 4: Aplikacji (Application Layer) – najwyższy poziom stosu. Łączy w sobie zadania warstw sesji, prezentacji i aplikacji modelu OSI. Zawiera wszystkie protokoły i usługi, z których bezpośrednio korzystają programy użytkownika (m.in. HTTP/HTTPS, DNS, DHCP, SSH, SMTP). Każda aplikacja sieciowa we współczesnym systemie operacyjnym komunikuje się ze stosem TCP/IP poprzez znormalizowany interfejs gniazd logicznych (Sockets API).

Warstwa Network Access (Dostępu do sieci / Łącza) jest fundamentem wykonawczym stosu TCP/IP. To właśnie na tym poziomie abstrakcyjne pakiety logiczne warstwy internetowej są przekształcane w fizyczne ramki zdolne do przemieszczania się po konkretnym medium transmisyjnym: kablu miedzianym, światłowodzie czy fali radiowej.

Podstawową cechą warstwy dostępu do sieci w modelu internetowym jest jej całkowita agnostyczność wobec mediów (Media Independence). Twórcy TCP/IP świadomie nie narzucili żadnego własnego formatu ramki fizycznej, lecz zaprojektowali stos tak, aby mógł on współpracować z dowolnym standardem opracowanym przez inne organizacje normalizacyjne (w szczególności przez komitety IEEE 802.3 Ethernet, IEEE 802.11 Wi-Fi, ITU-T czy 3GPP). Implementacja tej warstwy spoczywa na sterownikach kart sieciowych (NIC Drivers) wbudowanych w jądro systemu operacyjnego oraz układach scalonych kontrolera MAC/PHY.

Kluczowym protokołem operującym na styku warstwy dostępu do sieci i warstwy internetowej w sieciach IPv4 jest ARP (Address Resolution Protocol) zdefiniowany w normie RFC 826. Ponieważ przełącznik warstwy 2 nie rozumie adresów IP, stacja nadawcza przed wysłaniem ramki musi poznać fizyczny 48-bitowy adres MAC urządzenia docelowego (lub bramy domyślnej).

W tym celu stacja wysyła zapytanie ARP Request na rozgłoszeniowy adres MAC (FF:FF:FF:FF:FF:FF) z pytaniem: „Kto ma adres IP 192.168.1.1? Odpowiedz do mnie”. Właściciel adresu odpowiada bezpośrednim pakietem ARP Reply, podając swój sprzętowy MAC. Wynik jest buforowany w pamięci jądra w tzw. tablicy ARP (ARP Cache) przez określony czas (typowo kilka minut), co eliminuje konieczność ciągłego generowania ruchu rozgłoszeniowego. W sieciach IPv6 archaiczny protokół ARP został zastąpiony znacznie bardziej eleganckim protokołem NDP (Neighbor Discovery Protocol, RFC 4861), wykorzystującym komunikację grupową ICMPv6 Multicast.

Warstwa Internetowa (Internet Layer) jest absolutnym sercem i spoiwem całej globalnej sieci teleinformatycznej. To właśnie na tym poziomie zbiegają się wszystkie strumienie danych z milionów różnych aplikacji, aby zostać przetworzone w jednolitą, uniwersalną formę pakietów IP (Datagramów internetowych).

Działanie protokołu IP opiera się na dwóch żelaznych paradygmatach inżynierskich: 1) Transmisja bezpołączeniowa (Connectionless) – protokół IP nie wymaga nawiązywania jakiejkolwiek wstępnej sesji ani synchronizacji przed wysłaniem danych. Każdy pakiet IP jest całkowicie autonomiczną jednostką (datagramem), zawierającą kompletny adres źródłowy i docelowy. Oznacza to, że kolejne pakiety w ramach tej samej konwersacji mogą podróżować przez internet całkowicie odmiennymi trasami fizycznymi, omijając awarie węzłów pośredniczących;

2) Dostarczanie z maksymalną starannością (Best-Effort Delivery / Unreliable) – protokół IP sam z siebie nie stawia żadnych gwarancji dostarczenia danych! Jeśli po drodze bufor routera ulegnie przepełnieniu (zator sieciowy), kabel zostanie uszkodzony, a suma kontrolna wykaże błąd, pakiet IP zostaje bezgłośnie odrzucony (porzucony). Protokół IP nie wykonuje żadnych retransmisji, nie śledzi utraconych pakietów ani nie naprawia błędów kolejności. Cała odpowiedzialność za niezawodność została celowo oddelegowana do wyższej warstwy transportowej (TCP) na hostach końcowych.

Głównym zadaniem urządzeń warstwy internetowej – routerów (Routers) – jest podejmowanie decyzji o trasowaniu (Routing Decision) na podstawie najdłuższego dopasowania prefiksu (Longest Prefix Match) w tablicy routingu. Router bada wyłącznie docelowy adres IP pakietu, dekrementuje licznik TTL, odnajduje najlepszą trasę wyjściową i przekazuje pakiet do kolejnego przeskoku (Next Hop). Dzięki takiej architekturze routery szkieletowe mogą przetwarzać miliardy pakietów na sekundę z prędkościami rzędu terabitów, nie będąc obciążonymi pamięcią o stanach pojedynczych połączeń.

Choć protokół IP jest bez wątpienia centralnym punktem warstwy internetowej, nie działa on w próżni. Do prawidłowego funkcjonowania globalnego routingu, diagnostyki błędów oraz obsługi transmisji grupowych niezbędny jest wyspecjalizowany ekosystem protokołów pomocniczych, tworzących wspólnie rodzinę protokołów warstwy internetowej:

1) Protokoły nośne (Routed Protocols): stanowią właściwy nośnik danych dla warstw wyższych: IPv4 (RFC 791) z 32-bitową przestrzenią adresową (ok. 4,3 miliarda adresów) oraz IPv6 (RFC 8200) z gigantyczną 128-bitową przestrzenią (3,4 × 10³⁸ adresów), uproszczonym nagłówkiem stałym o długości 40 bajtów oraz wbudowaną obsługą autokonfiguracji SLAAC;

2) Protokół kontrolno-diagnostyczny ICMP (Internet Control Message Protocol, RFC 792): integralny element stosu IP służący do raportowania błędów przetwarzania pakietów oraz dostarczania mechanizmów diagnostycznych (m.in. komunikaty Echo w poleceniu ping oraz raportowanie wygasania TTL w poleceniu traceroute). W środowisku IPv6 jego odpowiednikiem jest wysoce rozbudowany ICMPv6 (RFC 4443), który obok diagnostyki przejął funkcje protokołu ARP poprzez procedury Neighbor Discovery;

3) Protokół zarządzania grupami IGMP (Internet Group Management Protocol, RFC 3376): protokół wykorzystywany przez stacje robocze do informowania lokalnych routerów multicastowych o chęci dołączenia do określonej grupy transmisji grupowej Multicast (np. strumieniowanie telewizji IPTV, transmisje giełdowe). W IPv6 funkcję tę realizuje protokół MLD (Multicast Listener Discovery);

4) Protokoły trasowania (Routing Protocols): dynamiczne protokoły wymiany informacji o topologii sieci pomiędzy routerami: protokoły wnętrza systemu autonomicznego (IGP: OSPFv2/OSPFv3 bazujący na algorytmie stanu łącza Dijkstry, IS-IS) oraz protokół zewnątrzsystemowy BGP-4 (RFC 4271) będący spoiwem trasującym cały globalny internet.

Protokół IP został zaprojektowany jako protokół bezpołączeniowy i pozbawiony mechanizmów powiadamiania o problemach. Gdyby router nie był w stanie przekazać pakietu dalej z powodu awarii łącza, nadawca nigdy nie dowiedziałby się o problemie, bezowocnie czekając na odpowiedź. Z tego względu protokołowi IP towarzyszy nierozerwalnie protokół ICMP (Internet Control Message Protocol) zdefiniowany w normie RFC 792.

Komunikaty ICMP są enkapsulowane bezpośrednio wewnątrz pakietów IP (wartość pola Protocol = 1 w nagłówku IPv4). Każdy komunikat ICMP rozpoczyna się od 8-bitowego pola Type (Typ komunikatu), 8-bitowego pola Code (Kod szczegółowy) oraz 16-bitowej sumy kontrolnej Checksum. W inżynierii sieciowej kluczowe znaczenie ma znajomość następujących typów komunikatów ICMP:

1) Typ 8 i Typ 0 (Echo Request / Echo Reply): para komunikatów stanowiąca fundament najpopularniejszego narzędzia diagnostycznego na świecie – polecenia ping. Nadawca wysyła zapytanie Echo Request (Typ 8, Kod 0) zawierające unikalny identyfikator i numer sekwencyjny; odbiorca ma obowiązek natychmiast odesłać identyczny ładunek w odpowiedzi Echo Reply (Typ 0, Kod 0). Pozwala to na zmierzenie czasu podróży pakietu w obie strony (RTT – Round-Trip Time) oraz wykrycie strat pakietów;

2) Typ 3 (Destination Unreachable – Cel nieosiągalny): komunikat generowany przez router lub host docelowy, gdy pakiet nie może zostać dostarczony. Kod precyzuje przyczynę problemu: Kod 0 – sieć nieosiągalna (Network Unreachable), Kod 1 – host nieosiągalny (Host Unreachable), Kod 3 – port zamknięty (Port Unreachable, np. brak usługi UDP), Kod 4 – wymagana fragmentacja, ale flaga DF jest ustawiona (Fragmentation Needed and DF set – kluczowy komunikat w algorytmie PMTUD!);

3) Typ 11 (Time Exceeded – Przekroczono limit czasu): komunikat generowany przez router w sytuacji, gdy licznik TTL osiągnie wartość 0 (Kod 0: Time to Live exceeded in transit), co pozwala na działanie narzędzia traceroute; 4) Typ 5 (Redirect): komunikat informujący hosta o istnieniu lepszego (krótszego) routera pierwszego przeskoku w tej samej podsieci lokalnej.

Warstwa Transportowa (Transport Layer / Host-to-Host) w architekturze TCP/IP stanowi logiczny pomost pomiędzy surowym środowiskiem sieciowym a wymaganiami oprogramowania aplikacyjnego. Podczas gdy warstwa internetowa (IP) doprowadza pakiety pod właściwy adres komputera (Host-to-Host), warstwa transportowa odpowiada za dostarczenie danych do właściwego procesu systemowego (Process-to-Process).

Podstawowym mechanizmem adresacji procesów są 16-bitowe porty logiczne. Zarówno protokół TCP, jak i UDP posiadają w swoich nagłówkach pole portu źródłowego (Source Port) oraz docelowego (Destination Port), tworząc przestrzeń 65 536 portów. Połączenie sieciowe jest unikalnie identyfikowane w systemie operacyjnym za pomocą gniazda logicznego (Socket), łączącego adres IP z numerem portu. Dzięki temu na jednym serwerze o pojedynczym adresie IP może jednocześnie działać serwer WWW (port 80 i 443), serwer pocztowy (port 25), serwer bazodanowy (port 5432) oraz demon zdalnej administracji SSH (port 22).

Co najważniejsze, warstwa transportowa w stosie TCP/IP oferuje programistom dwa fundamentalne, przeciwstawne modele usług transportowych, pozwalając na idealne dopasowanie protokołu do potrzeb tworzonego systemu:

1) Model niezawodny, połączeniowy i strumieniowy (protokół TCP): gwarantujący, że dane dotrą do celu bezbłędnie, w całości, w nienaruszonej kolejności, a tempo ich nadawania zostanie automatycznie dostosowane do przepustowości sieci i buforów odbiorcy (zabezpieczenie przed zatorami);
2) Model lekki, bezpołączeniowy i datagramowy (protokół UDP): przedkładający minimalne narzuty nagłówkowe (zaledwie 8 bajtów) i natychmiastową transmisję bez opóźnień nad gwarancję niezawodności.

W ostatnich latach rodzina transportowa powiększyła się o rewolucyjny protokół QUIC (RFC 9000), który łączy niezawodność i kontrolę zatorów znaną z TCP z natychmiastowym zestawianiem sesji bez blokowania linii (Head-of-Line Blocking) i szyfrowaniem TLS 1.3, bazując na podkładzie datagramów UDP.

Protokół TCP (Transmission Control Protocol), zdefiniowany pierwotnie w dokumencie RFC 793 i gruntownie skonsolidowany w 2022 roku w normie RFC 9293, zawdzięcza swoje zaawansowane możliwości wysoce wyspecjalizowanej strukturze nagłówka o minimalnej wielkości 20 bajtów (zorganizowanej w 32-bitowe słowa maszynowe):

1) Source Port & Destination Port (po 16 bitów) – numery portów logicznych nadawcy i odbiorcy;
2) Sequence Number (Numer sekwencyjny, 32 bity) – określa numer pierwszego bajtu danych w danym segmencie w ramach całego strumienia; podczas uścisku SYN reprezentuje losowy początkowy numer sekwencyjny (ISN – Initial Sequence Number);
3) Acknowledgment Number (Numer potwierdzenia, 32 bity) – pole aktywne, gdy ustawiona jest flaga ACK; wskazuje kolejny numer bajtu, na który oczekuje odbiorca (tzw. potwierdzenie kumulatywne – Cumulative ACK);

4) Data Offset (Długość nagłówka, 4 bity) – liczba 32-bitowych słów tworzących nagłówek (wartość 5 oznacza 5 × 4 B = 20 bajtów); 5) Reserved (3 bity) – bity zarezerwowane do przyszłych zastosowań; 6) Flagi sterujące (Control Flags, 9 bitów) – binarne przełączniki determinujące charakter segmentu: SYN (inicjalizacja sesji), ACK (potwierdzenie), FIN (eleganckie zamknięcie sesji), RST (natychmiastowe zresetowanie/odrzucenie połączenia), PSH (żądanie natychmiastowego wypchnięcia danych do aplikacji bez buforowania), URG (obecność danych pilnych), ECE oraz CWR (jawne powiadamianie o zatorach sieciowych ECN);

7) Window Size (Rozmiar okna, 16 bitów) – liczba bajtów, jaką odbiorca jest gotów przyjąć w buforze bez odsyłania potwierdzenia (mechanizm Flow Control); 8) Checksum (Suma kontrolna, 16 bitów) – weryfikuje integralność nagłówka TCP, danych oraz tzw. pseudonagłówka IP (adresów IP i protokołu); 9) Urgent Pointer (Wskaźnik danych pilnych, 16 bitów); 10) Opcje TCP (Options, do 40 bajtów) – kluczowe rozszerzenia negocjowane w uścisku SYN: MSS (Maximum Segment Size), Window Scale (mnożnik powiększający rozmiar okna do 1 gigabajta), SACK Permitted (selektywne potwierdzenia utraconych bloków) oraz Timestamps (precyzyjny pomiar RTT).

Przed przesłaniem pierwszego bajtu danych protokół TCP musi nawiązać formalne, zsynchronizowane połączenie logiczne pomiędzy klientem a serwerem. Procedura ta nosi nazwę trójkrokowego uścisku dłoni (Three-Way Handshake) i stanowi fundament niezawodności komunikacji w internecie.

Przebieg procedury 3-Way Handshake przebiega według następujących kroków: 1) Krok 1 (SYN od klienta): Klient losuje swój początkowy numer sekwencyjny ISN_c (Initial Sequence Number) i wysyła do serwera segment z ustawioną wyłącznie flagą SYN = 1 (oraz pustym polem danych). W nagłówku przesyła proponowane opcje: swój parametr MSS (np. 1460 bajtów), mnożnik Window Scale oraz obsługę SACK. Klient przechodzi w stan SYN_SENT;

2) Krok 2 (SYN-ACK od serwera): Serwer (który wcześniej nasłuchiwał w stanie LISTEN) odbiera segment SYN, alokuje zasoby buforowe dla nowego połączenia, losuje swój własny niezależny numer sekwencyjny ISN_s i odsyła segment z ustawionymi flagami SYN = 1 oraz ACK = 1. W polu Acknowledgment Number wpisuje wartość ISN_c + 1, potwierdzając odbiór żądania klienta. Serwer przechodzi w stan SYN_RCVD;

3) Krok 3 (ACK od klienta): Klient odbiera segment serwera i odsyła ostateczne potwierdzenie: segment z ustawioną flagą ACK = 1 oraz polem Acknowledgment Number równym ISN_s + 1. Po odebraniu tego segmentu przez serwer obie strony znajdują się w stanie ESTABLISHED – połączenie jest w pełni otwarte i rozpoczyna się dwukierunkowa transmisja danych aplikacji.

Zamykanie sesji TCP realizowane jest w sposób elegancki (Graceful Teardown) za pomocą 4-krokowej wymiany z flagami FIN: strona kończąca wysyła segment FIN, druga strona odpowiada ACK, po czym po zakończeniu nadawania własnych danych odsyła swój FIN, na który otrzymuje ostateczny ACK. W sytuacjach awaryjnych (np. próba połączenia z zamkniętym portem lub załamanie aplikacji) stosuje się natychmiastowe zerwanie połączenia pojedynczym segmentem z flagą RST (Reset).

Analizator protokołów Wireshark jest niezastąpionym instrumentem do weryfikacji poprawności uścisku TCP i badania wydajności połączeń transportowych. Domyślnie Wireshark stosuje zaawansowane mechanizmy ułatwiające inżynierom interpretację surowych danych szesnastkowych.

Najważniejszą funkcją ułatwiającą czytanie zrzutów jest mechanizm względnych numerów sekwencyjnych (Relative Sequence Numbers). Ponieważ rzeczywiste początkowe numery sekwencyjne (ISN) są 32-bitowymi losowymi liczbami (np. 3 412 859 124), śledzenie ich przyrostu w głowie byłoby skrajnie uciążliwe. Wireshark automatycznie mapuje pierwszy pakiet SYN na wartość Seq = 0, pakiet SYN-ACK na Seq = 0, Ack = 1, a kolejne segmenty danych numeruje w odniesieniu do liczby przesłanych bajtów (np. Seq = 1, Ack = 1461 po odebraniu segmentu o rozmiarze 1460 bajtów).

Kluczowe filtry i narzędzia analityczne w diagnostyce TCP obejmują: 1) tcp.flags.syn == 1 and tcp.flags.ack == 0 – izoluje wyłącznie pakiety inicjalizacji nowych połączeń (żądania klientów); 2) tcp.flags.reset == 1 – lokalizuje natychmiastowe odrzucenia i zerwania połączeń (odpowiedzi RST); 3) tcp.analysis.retransmission – automatycznie wykrywa i podświetla na czarno-czerwono retransmisje segmentów utraconych w sieci;

4) Funkcja „Follow -> TCP Stream” – po kliknięciu prawym przyciskiem myszy na dowolny segment TCP Wireshark automatycznie filtruje wszystkie pakiety należące do danej 5-krotki połączenia i w czytelnym oknie tekstowym rekonstruuje cały strumień danych z podziałem na kolory (czerwony dla danych wysłanych przez klienta, niebieski dla odpowiedzi serwera), zdejmując wszystkie nagłówki sieciowe; 5) Wykresy TCP (Statistics -> TCP Stream Graphs) – generowanie profesjonalnych wykresów: Time-Sequence Graph (Stevens), Round Trip Time Graph oraz Window Scaling Graph, pozwalających w ułamku sekundy zidentyfikować punkty wystąpienia zatorów buforów.

Jednym z najbardziej genialnych osiągnięć inżynierskich protokołu TCP jest jego zdolność do adaptacyjnego dostosowywania tempa transmisji do dynamicznie zmieniających się warunków sieciowych. Protokół realizuje to poprzez dwa komplementarne mechanizmy regulacyjne:

1) Kontrola przepływu (Flow Control / Sliding Window): chroni bufor stacji odbiorczej przed zalaniem danymi przez zbyt szybkiego nadawcę. Odbiorca w każdym odsyłanym segmencie ACK informuje o bieżącym wolnym miejscu w swoim buforze pamięci RAM za pomocą pola Window Size (rwnd – Receiver Window). Nadawca ma bezwzględny zakaz wysłania większej liczby niepotwierdzonych bajtów niż wartość rwnd. Jeśli bufor odbiorcy zapełni się, odbiorca odsyła Window Size = 0 (Zero Window), co zmusza nadawcę do natychmiastowego wstrzymania nadawania do czasu odzyskania zasobów;

2) Zarządzanie przeciążeniem sieci (Congestion Control): chroni sieć pośredniczącą (routery, bufory przełączników) przed załamaniem zatorowym (Congestion Collapse). Nadawca utrzymuje wewnętrzną zmienną cwnd (Congestion Window – Okno przeciążenia). Rzeczywiste dopuszczalne tempo nadawania określa minimum z obu okien: W = min(cwnd, rwnd). Algorytmy przeciążeniowe opierają się na czterech fazach zdefiniowanych w normie RFC 5681:

• Powolny start (Slow Start): na początku połączenia cwnd = 1 MSS; po odebraniu każdego ACK rozmiar okna rośnie wykładniczo (podwaja się w każdym cyklu RTT), sondując pasmo łącza aż do osiągnięcia progu ssthresh;
• Unikanie przeciążenia (Congestion Avoidance): po przekroczeniu progu ssthresh okno rośnie liniowo (o 1 MSS na cały cykl RTT);
• Szybka retransmisja i powrót (Fast Retransmit & Fast Recovery): po odebraniu trzech duplikatów ACK (Triple Duplicate ACK) nadawca natychmiast retransmituje utracony segment bez czekania na timeout i obniża próg ssthresh o połowę (algorytm AIMD w TCP Reno). We współczesnych systemach dominują algorytmy nowej generacji: TCP Cubic (zoptymalizowany dla łączy o wysokim iloczynie pasma i opóźnienia) oraz opracowany przez Google algorytm BBR (Bottleneck Bandwidth and RTT), który zamiast strat pakietów mierzy rzeczywistą pojemność wąskiego gardła.

Protokół UDP (User Datagram Protocol), zdefiniowany w sierpniu 1980 roku przez Jona Postela w historycznym dokumencie RFC 768, jest ucieleśnieniem inżynierskiego minimalizmu. W przeciwieństwie do potężnego i złożonego protokołu TCP, UDP nie próbuje rozwiązywać problemów niezawodności, kolejkowania ani kontroli zatorów, oferując aplikacjom bezpośredni, niemal nieobciążony dostęp do warstwy internetowej.

Nagłówek protokołu UDP posiada stałą długość dokładnie 8 bajtów (64 bitów) i składa się z zaledwie czterech 16-bitowych pól: 1) Source Port (Port źródłowy, 16 bitów) – numer portu nadawcy (pole opcjonalne, może zawierać wartość 0, jeśli odpowiedź nie jest oczekiwana); 2) Destination Port (Port docelowy, 16 bitów) – numer portu logicznego procesu docelowego; 3) Length (Długość, 16 bitów) – całkowity rozmiar datagramu UDP (nagłówek 8 B + ładunek danych) wyrażony w bajtach; minimalna wartość to 8; 4) Checksum (Suma kontrolna, 16 bitów) – opcjonalna w IPv4, ale obowiązkowa w IPv6; weryfikuje poprawność nagłówka, danych oraz pseudonagłówka IP.

Brak mechanizmów nawiązywania połączenia (brak uścisku Handshake), brak potwierdzeń ACK oraz brak retransmisji przynosi kluczowe zalety operacyjne: 1) Zerowe opóźnienie początkowe (Zero Latency) – aplikacja wysyła dane w pierwszym pakiecie bez konieczności czekania na RTT uścisku TCP; 2) Brak blokowania linii (No Head-of-Line Blocking) – jeśli jeden datagram zostanie utracony na kablu, kolejne pakiety są natychmiast przekazywane do aplikacji bez wstrzymywania bufora;

3) Niski narzut pasma – narzut 8 bajtów w porównaniu z 20–60 bajtami w TCP pozwala zaoszczędzić miliony gigabajtów transferu w skali globalnej. Z tego względu UDP jest bezdyskusyjnym liderem w: telefonii internetowej VoIP, wideokonferencjach, strumieniowaniu na żywo, grach wieloosobowych online, zapytaniach DNS, protokole DHCP, synchronizacji czasu NTP oraz w nowoczesnym protokole QUIC.

Warstwa Aplikacji (Application Layer) w modelu TCP/IP jest poziomem, z którym użytkownicy i programiści mają bezpośredni kontakt. To tutaj realizowane są konkretne funkcje biznesowe, komunikacyjne i rozrywkowe współczesnego świata cyfrowego. W odróżnieniu od modelu OSI, warstwa aplikacji TCP/IP łączy w sobie całą logikę prezentacji danych (formatowanie, kompresję, kryptografię) oraz zarządzanie sesją użytkownika.

W architekturze aplikacji internetowych dominują dwa fundamentalne modele komunikacji: 1) Model Klient-Serwer (Client-Server Architecture) – scentralizowany paradygmat, w którym dedykowany serwer o stałym adresie IP i znanym porcie (Well-Known Port) nieustannie nasłuchuje na przychodzące połączenia, a rozproszone stacje klienckie dynamicznie inicjują sesje żądanie-odpowiedź (Request-Response). Przykłady: przeglądanie stron WWW (HTTP/HTTPS), odpytywanie baz danych, obsługa poczty (SMTP/IMAP);

2) Model Równorzędny (Peer-to-Peer / P2P) – zdecentralizowany paradygmat, w którym każdy węzeł sieci (Peer) pełni jednocześnie rolę klienta i serwera, wymieniając zasoby bezpośrednio z sąsiadami bez pośrednictwa centralnej jednostki (np. protokół BitTorrent, rozproszone rejestry Blockchain, telefonia WebRTC).

Komunikacja pomiędzy procesem aplikacji a stosem sieciowym systemu operacyjnego odbywa się za pomocą standardowych interfejsów programistycznych API gniazd (Berkeley Sockets API). Programista tworzy obiekt gniazda logicznego, wywołuje funkcje systemowe (socket(), bind(), connect(), send(), recv()) i przekazuje strumień danych do jądra, które zajmuje się całą skomplikowaną procedurą enkapsulacji transportowej, sieciowej i fizycznej.

Ludzie operują pojęciami symbolicznymi i łatwymi do zapamiętania słowami (np. agh.edu.pl czy google.com), podczas gdy routery i stosy protokołów sieciowych potrafią trasować pakiety wyłącznie na podstawie numerycznych adresów IP (np. 149.156.96.10 lub 2a00:1450:401b::200e). Usługą infrastrukturalną, która łączy te dwa światy i bez której współczesny internet przestałby funkcjonować, jest System Nazw Domenowych – DNS (Domain Name System) znormalizowany w dokumentach RFC 1034 i RFC 1035.

Baza danych DNS posiada strukturę odwróconego drzewa hierarchicznego: 1) Strefa główna (Root Zone / .) – na szczycie drzewa znajduje się 13 logicznych klastrów serwerów głównych (Root Servers od a.root-servers.net do m.root-servers.net), zarządzanych w architekturze Anycast przez setki lokalizacji na całym świecie; 2) Domeny najwyższego poziomu (TLD – Top-Level Domains) – domeny krajowe (ccTLD: .pl, .de, .uk) oraz funkcjonalne (gTLD: .com, .org, .net, .edu); 3) Domeny drugiego poziomu (Second-Level Domains) – rejestrowane przez organizacje i firmy (np. edu.pl, agh.edu.pl); 4) Subdomeny i nazwy hostów (np. student.agh.edu.pl).

Proces rozwiązywania nazwy przebiega dwufazowo: stacja kliencka wysyła zapytanie rekurencyjne (Recursive Query) do lokalnego serwera DNS (Resolwera, np. 8.8.8.8 lub DNS dostawcy ISP). Resolwer bierze na siebie ciężar rozwiązania nazwy, wykonując serię zapytań iteracyjnych (Iterative Queries): najpierw pyta serwer Root (który odsyła go do serwera TLD dla .pl), potem pyta serwer TLD .pl (który odsyła do serwerów autorytatywnych dla agh.edu.pl), aż wreszcie serwer autorytatywny zwraca właściwy rekord zasobowy (Resource Record).

Kluczowe rekordy DNS w diagnostyce to: Rekord A (adres IPv4), AAAA (adres IPv6), CNAME (alias / nazwa kanoniczna), MX (serwer pocztowy), NS (serwer nazw delegowany dla strefy), TXT (rekordy tekstowe dla polityk SPF, DKIM, DMARC) oraz PTR (odwrotne tłumaczenie IP na domenę – Reverse DNS). Narzędziami diagnostycznymi pierwszego wyboru są polecenia dig, nslookup oraz host.

Ręczna konfiguracja parametrów sieciowych (statyczny adres IP, maska podsieci, brama domyślna, adresy serwerów DNS) na każdym komputerze, smartfonie czy drukarce byłaby w nowoczesnych środowiskach koszmarem administratorskim, niosąc ryzyko konfliktów adresów (IP Conflict). Do automatyzacji tego procesu służy protokół DHCP (Dynamic Host Configuration Protocol), zdefiniowany w normie RFC 2131 (będący następcą protokołu BOOTP).

Proces uzyskania konfiguracji sieciowej przez klienta opiera się na 4-krokowej sekwencji komunikatów znanej jako cykl DORA:

1) D – DHCP Discover (Wykrycie): Nowo podłączony host nie ma adresu IP i nie zna adresu serwera DHCP. Wysyła w sieć lokalną rozgłoszeniowy pakiet UDP z portu 68 na port 67 (Source IP: 0.0.0.0, Destination IP: 255.255.255.255, Broadcast MAC: FF:FF:FF:FF:FF:FF) z zapytaniem o dostępne serwery;
2) O – DHCP Offer (Oferta): Serwer DHCP odbiera zapytanie, rezerwuje wolny adres IP ze swojej puli (Pool/Scope) i odsyła ofertę: proponowany adres IP dla klienta, maskę, czas dzierżawy (Lease Time) oraz swój własny adres serwera;

3) R – DHCP Request (Żądanie): Klient może odebrać oferty od kilku serwerów DHCP w sieci. Wybiera pierwszą z nich i wysyła rozgłoszeniowy komunikat DHCP Request, informując całą sieć, którą ofertę akceptuje (co pozwala pozostałym serwerom zwolnić zarezerwowane adresy);
4) A – DHCP Acknowledge (Zatwierdzenie): Wybrany serwer DHCP odsyła ostateczne potwierdzenie (ACK), przesyłając pełny zestaw opcji konfiguracyjnych (m.in. Opcja 3 – Brama domyślna, Opcja 6 – Serwery DNS, Opcja 15 – Nazwa domeny). Klient konfiguruje swój interfejs i rozpoczyna normalną pracę.

Kluczowym elementem mechanizmu DHCP jest czas dzierżawy (Lease Time). Adres IP nie jest przypisywany stacji na stałe, lecz wypożyczany na określony czas (np. 8 godzin w sieci biurowej lub 24 godziny w domu). W połowie czasu dzierżawy (tzw. czas T1 = 50% Lease Time) klient wysyła bezpośrednie zapytanie unicastowe o odnowienie dzierżawy (DHCP Request Renewal). Jeśli serwer nie odpowiada, przy czasie T2 = 87,5% klient ponawia próbę w trybie rozgłoszeniowym. Jeśli dzierżawa wygaśnie bez odnowienia, host musi natychmiast zaprzestać korzystania z adresu IP i rozpocząć procedurę DORA od nowa.

Podstawowym zadaniem warstwy internetowej jest zapewnienie skutecznego transportu pakietu ze stacji źródłowej do stacji docelowej poprzez sieć połączonych węzłów pośredniczących. Proces ten realizowany jest przez routery i nosi nazwę trasowania (Routingu IP).

Gdy router odbiera pakiet IP na jednym ze swoich interfejsów, wykonuje następującą zautomatyzowaną procedurę decyzyjną: 1) Weryfikuje sumę kontrolną nagłówka IPv4 (Header Checksum); jeśli nagłówek jest uszkodzony, pakiet jest natychmiast niszczony; 2) Sprawdza pole TTL: zmniejsza jego wartość o 1; jeśli TTL = 0, odrzuca pakiet i generuje komunikat ICMP Time Exceeded; 3) Odczytuje docelowy adres IP (Destination IP) i przeszukuje swoją tablicę routingu (Routing Table).

Fundamentalną regułą matematyczną przeszukiwania tablicy routingu jest zasada najdłuższego dopasowania prefiksu (Longest Prefix Match – LPM). Jeśli w tablicy routingu znajduje się kilka tras pasujących do adresu docelowego, router zawsze wybiera trasę o najbardziej specyficznej (najdłuższej) masce podsieci. Przykładowo, jeśli pakiet ma adres docelowy 192.168.1.55, a w tablicy istnieją wpisy:
• Trasa A: 0.0.0.0/0 (trasa domyślna, prefiks /0),
• Trasa B: 192.168.0.0/16 (prefiks /16),
• Trasa C: 192.168.1.0/24 (prefiks /24),
router bezwzględnie wybierze Trasę C, ponieważ prefiks /24 dopasowuje aż 24 bity adresu i jest najbardziej precyzyjny.

Wpisy w tablicy routingu mogą pochodzić z trzech źródeł: 1) Trasy bezpośrednio podłączone (Connected) – tworzone automatycznie po skonfigurowaniu adresu IP i włączeniu interfejsu fizycznego; 2) Trasy statyczne (Static Routes) – wpisywane ręcznie przez administratora sieci (w tym trasa domyślna Default Gateway / 0.0.0.0/0); 3) Trasy dynamiczne (Dynamic Routes) – wyliczane automatycznie przez protokoły routingu (OSPF, BGP, IS-IS), które stale monitorują stan łączy i automatycznie przełączają ruch na ścieżki zapasowe w przypadku awarii toru światłowodowego.

Diagnozowanie opóźnień i problemów z routingiem w skali rozległej sieci WAN lub globalnego internetu wymaga możliwości precyzyjnego podejrzenia, przez jakie konkretnie węzły pośredniczące (routery) podróżują nasze pakiety. Do tego celu służy narzędzie traceroute (w systemie Windows występujące jako tracert) oraz jego nowoczesny, interaktywny odpowiednik mtr (My Traceroute).

Geniusz mechanizmu działania polecenia traceroute polega na tym, że nie wymaga ono żadnego specjalnego protokołu – opiera się całkowicie na standardowym zachowaniu pola Time to Live (TTL) protokołu IP oraz protokołu ICMP:

1) Program wysyła pierwszą serię pakietów (tradycyjnie trzy pakiety UDP na wysokie porty w Linuksie lub pakiety ICMP Echo w Windows) ze sztucznie ustawioną wartością TTL = 1. Pierwszy router na ścieżce (nasza brama domyślna) zmniejsza TTL do 0, niszczy pakiet i odsyła komunikat ICMP Type 11 Code 0 (Time Exceeded). Traceroute rejestruje adres IP bramy oraz mierzy czas RTT;
2) Program wysyła kolejną serię z TTL = 2. Pierwszy router zmniejsza TTL do 1 i przekazuje pakiet dalej; drugi router zmniejsza TTL do 0, niszczy pakiet i odsyła ICMP Time Exceeded ze swojego adresu IP. Proces powtarza się z TTL = 3, 4, 5 itd., aż pakiet dotrze do stacji docelowej, która odsyła odpowiedź końcową (ICMP Port Unreachable dla UDP lub ICMP Echo Reply dla Windows).

Znakomitym rozwinięciem tego podejścia jest narzędzie mtr, które łączy funkcje traceroute i ciągłego pinga. W dynamicznie odświeżanej konsoli mtr prezentuje w czasie rzeczywistym dla każdego przeskoku: procentową utratę pakietów (Loss %), liczbę wysłanych prób (Snt), ostatni czas RTT oraz wartości średnie, najlepsze, najgorsze i odchylenie standardowe. Pozwala to błyskawicznie zlokalizować, na styku którego konkretnie operatora telekomunikacyjnego (peering partner) pojawiają się straty pakietów lub zatory buforów.

Gdy na początku lat 80. projektowano protokół IPv4, 32-bitowa przestrzeń adresowa obejmująca 4 294 967 296 unikalnych adresów wydawała się pulą niewyczerpaną – w sieci znajdowało się wówczas zaledwie kilkaset komputerów akademickich i wojskowych. Jednak eksplozja komercyjnego internetu, smartfonów, urządzeń Internetu Rzeczy (IoT) oraz usług chmurowych doprowadziła do wyczerpania wolnych puli adresowych w centralnym rejestrze IANA w lutym 2011 roku. Choć mechanizm translacji NAT tymczasowo przedłużył żywotność IPv4, trwałym rozwiązaniem problemu jest standard IPv6 znormalizowany w dokumencie RFC 8200.

Protokół IPv6 wprowadza fundamentalne innowacje inżynierskie: 1) 128-bitowa przestrzeń adresowa – oferuje astronomiczny zasób 2¹²⁸ ≈ 3,4 × 10³⁸ adresów (co odpowiada bilionom adresów na każdy milimetr kwadratowy powierzchni Ziemi!). Pozwala to na całkowitą rezygnację z mechanizmów NAT i przywrócenie naturalnej zasady łączności koniec-do-końca (End-to-End);

2) Uproszczony, stały nagłówek bazowy – nagłówek IPv6 posiada stałą długość dokładnie 40 bajtów (w odróżnieniu od zmiennego nagłówka IPv4 o długości 20–60 B). Usunięto z niego zbędne pola, takie jak długość nagłówka (IHL), flagi fragmentacji oraz sumę kontrolną (Header Checksum), co drastycznie odciąża procesory routerów szkieletowych i przyspiesza trasowanie pakietów. Opcje protokołu realizowane są za pomocą tzw. nagłówków rozszerzeń (Extension Headers) doklejanych sekwencyjnie pomiędzy nagłówek IPv6 a nagłówek L4;

3) Bezstanowa autokonfiguracja (SLAAC – Stateless Address Autoconfiguration, RFC 4862) – host po wpięciu do sieci generuje własny adres lokalny (Link-Local), nasłuchuje komunikatów Router Advertisement (RA) i samodzielnie konfiguruje globalny adres IP bez konieczności stawiania serwera DHCP; 4) Całkowita eliminacja ruchu rozgłoszeniowego (Broadcast) – w IPv6 nie istnieje pojęcie adresu broadcast; cała komunikacja pomocnicza (odpowiednik ARP) realizowana jest za pomocą wysoce wydajnych grup Multicast z wykorzystaniem protokołu NDP (Neighbor Discovery Protocol).

Zestawienie modelu ISO/OSI ze stosem TCP/IP jest jednym z najważniejszych zagadnień w teorii inżynierii sieciowej. Choć oba modele opisują ten sam proces przesyłania danych w sieci pakietowej, powstały w odmiennych warunkach kulturowych i reprezentują całkowicie różne filozofie projektowe:

1) Filozofia projektowa: Model ISO/OSI powstał jako dzieło komitetów standaryzacyjnych, zanim jeszcze stworzono konkretne protokoły. Jest to model normatywny (Descriptive / Conceptual) – definiuje, co poszczególne warstwy powinny robić, narzucając sztywny podział na siedem poziomów. Z kolei model TCP/IP powstał w drodze empirycznej ewolucji sieci ARPANET. Jest modelem funkcjonalnym (Pragmatic / Implementation-driven) – najpierw stworzono działające protokoły (IP, TCP), przetestowano je w praktyce, a dopiero później opisano ich architekturę w dokumencie RFC 1122;

2) Różnice w strukturze warstw: W modelu TCP/IP zadania warstw sesji (L5) i prezentacji (L6) zostały połączone z warstwą aplikacji (L7) w jeden poziom aplikacyjny. Twórcy internetu uznali, że formatowanie danych (np. szyfrowanie TLS czy kodowanie MIME) powinno być realizowane bezpośrednio w bibliotekach aplikacji, a nie jako osobny poziom sieciowy. Podobnie warstwy fizyczna (L1) i łącza danych (L2) zostały połączone w jedną warstwę dostępu do sieci (Network Access / Link);

3) Rola w nowoczesnej inżynierii: W branży teleinformatycznej obowiązuje niepisana zasada: „Uczymy się i myślimy modelem OSI, ale wdrażamy i konfigurujemy model TCP/IP”. Gdy inżynierowie rozmawiają o przełącznikach warstwy 2 (L2 Switch), routerach warstwy 3 (L3 Router), portach warstwy 4 (L4 Port) czy zaporach warstwy 7 (L7 WAF), posługują się uniwersalnym językiem modelu OSI. Gdy jednak konfigurują adresację IP, maski podsieci, serwery DNS i reguły firewalla, pracują wyłącznie na strukturach stosu TCP/IP. W celach praktycznych powszechnie stosuje się model 5-warstwowy (hybrydowy), który rozdziela dolny poziom TCP/IP na warstwę fizyczną i warstwę łącza danych.

Protokół TCP jest protokołem stanowym (Stateful) – każde aktywne gniazdo sieciowe w pamięci jądra systemu operacyjnego znajduje się w ściśle określonym punkcie cyklu życia opisanego przez maszynę stanów skończonych protokołu TCP (TCP Finite State Machine). Zrozumienie przejść pomiędzy stanami jest kluczowe w diagnozowaniu problemów wydajnościowych serwerów i ataków sieciowych.

Kluczowe stany połączenia TCP obejmują: 1) LISTEN – serwer nasłuchuje na określonym porcie (np. port 443) i oczekuje na nadejście pakietu SYN od klienta; 2) SYN_SENT – klient wysłał segment SYN i oczekuje na odpowiedź serwera (SYN-ACK); 3) SYN_RCVD – serwer odebrał SYN, odesłał SYN-ACK i oczekuje na finalny ACK (kluczowy stan przy atakach SYN Flood); 4) ESTABLISHED – uścisk dłoni 3-Way Handshake został zakończony pomyślnie; trwa dwukierunkowy transfer danych;

5) Stany zamykania sesji (Graceful Teardown): strona inicjująca zamknięcie wysyła FIN i przechodzi w stan FIN_WAIT_1, po odebraniu ACK przechodzi w FIN_WAIT_2, oczekując na segment FIN od drugiej strony. Strona odbierająca przechodzi w stan CLOSE_WAIT (sygnalizując lokalnej aplikacji konieczność zamknięcia gniazda), wysyła swój FIN i przechodzi w LAST_ACK;

6) Stan TIME_WAIT (2MSL): najważniejszy stan z punktu widzenia inżynierii serwerowej. Strona, która jako pierwsza wysłała segment FIN, po odebraniu potwierdzenia nie zamyka gniazda natychmiast, lecz wchodzi w stan TIME_WAIT na czas równy podwójnemu maksymalnemu czasowi życia segmentu – 2MSL (Maximum Segment Lifetime, typowo 60–120 sekund). Ma to dwa cele: po pierwsze, gwarantuje, że jeśli ostateczny ACK zagubił się w sieci, retransmitowany segment FIN zostanie poprawnie odebrany i potwierdzony; po drugie, zapobiega sytuacji, w której opóźnione pakiety ze starej sesji trafiłyby do nowo otwartego połączenia o tych samych portach. Do podglądu stanów gniazd w terminalu Linuksa służy polecenie ss -tulpn lub ss -s.

Gdy w latach 70. i 80. tworzono protokoły TCP/IP, sieć internetowa była zamkniętym środowiskiem zaufanych ośrodków akademickich i wojskowych. W bazowych specyfikacjach RFC nie zaimplementowano żadnych mechanizmów uwierzytelniania ani szyfrowania, co stało się źródłem fundamentalnych wektorów ataków wykorzystywanych przez współczesnych cyberprzestępców:

1) Atak SYN Flood (Odmowa usługi DoS): napastnik wysyła na serwer lawinę pakietów TCP z flagą SYN, fałszując adresy źródłowe IP (IP Spoofing). Serwer dla każdego żądania alokuje pamięć bufora w kolejce połączeń niepełnych (Backlog Queue), odsyła pakiet SYN-ACK w próżnię i przechodzi w stan SYN_RCVD, oczekując na potwierdzenie ACK. Po kilku sekundach kolejka serwera ulega całkowitemu zapełnieniu, a serwer przestaje przyjmować połączenia od legalnych użytkowników. Skuteczną obroną są SYN Cookies (RFC 4987): serwer nie alokuje pamięci, lecz koduje stan połączenia kryptograficznie w numerze sekwencyjnym ISN i alokuje zasoby dopiero po odebraniu poprawnego ACK;

2) Podszywanie się pod adres IP (IP Spoofing): nadawca preparuje nagłówek pakietu, wpisując w polu Source IP fałszywy adres ofiary. Stosowane w atakach wzmacniających DDoS (np. DNS/NTP Amplification) oraz do omijania prostych list kontroli dostępu ACL. Mitigacja opiera się na mechanizmie uRPF (Unicast Reverse Path Forwarding, RFC 3704) na routerach, który odrzuca pakiety przychodzące z interfejsu niezgodnego z tablicą routingu dla adresu źródłowego;

3) Zatruwanie pamięci podręcznej ARP (ARP Cache Poisoning / Spoofing): w warstwie dostępu do sieci protokół ARP nie weryfikuje tożsamości. Atakujący wysyła fałszywe pakiety ARP Reply, wmawiając stacji, że jego karta ma adres IP bramy domyślnej, co pozwala na przeprowadzenie ataku Man-in-the-Middle (MitM) i podsłuch całego ruchu w sieci LAN. Obroną jest wdrożenie na przełącznikach funkcji Dynamic ARP Inspection (DAI) powiązanej z mechanizmem DHCP Snooping.

Ponieważ stos TCP/IP przesyła dane w warstwach 1–4 w postaci jawnego tekstu (Cleartext), ochrona poufności i integralności informacji współczesnego internetu została zrealizowana na styku warstwy transportowej i aplikacyjnej za pomocą protokołu TLS (Transport Layer Security). Standard TLS 1.3, ratyfikowany przez IETF w sierpniu 2018 roku w dokumencie RFC 8446, stanowił rewolucyjne zerwanie z przestarzałymi i podatnymi mechanizmami wcześniejszych wersji TLS 1.0, 1.1 i 1.2.

Kluczowe innowacje architektoniczne standardu TLS 1.3 obejmują: 1) Radykalne skrócenie czasu zestawiania sesji (1-RTT Handshake) – podczas gdy w TLS 1.2 wynegocjowanie kluczy wymagało aż dwóch pełnych cykli RTT (obok uścisku TCP), w TLS 1.3 klient już w pierwszym komunikacie ClientHello przesyła swoje propozycje wymiany kluczy (Key Share). Bezpieczne szyfrowanie jest zestawiane w czasie zaledwie jednego cyklu RTT, a przy wznawianiu sesji w trybie 0-RTT (Early Data) dane aplikacji mogą być transmitowane natychmiast;

2) Bezwzględne utajnianie z wyprzedzeniem (Perfect Forward Secrecy – PFS) – całkowicie usunięto statyczną wymianę kluczy RSA oraz mechanizmy oparte na statycznym Diffie-Hellmanie. Wszystkie sesje TLS 1.3 muszą bezwzględnie korzystać z efemerycznej wymiany kluczy na krzywych eliptycznych ECDHE (np. X25519) lub DHE. Nawet jeśli klucz prywatny serwera zostanie w przyszłości skradziony, przechwycony i zarchiwizowany ruch archiwalny pozostanie niemożliwy do odszyfrowania;

3) Eliminacja podatnych algorytmów kryptograficznych – z protokołu całkowicie wykreślono funkcje skrótu MD5 i SHA-1, szyfry strumieniowe RC4 oraz podatne tryby blokowe CBC (podatne na ataki padding oracle, takie jak POODLE). Wprowadzono wyłącznie nowoczesne szyfry z uwierzytelnianiem powiązanym AEAD (Authenticated Encryption with Associated Data): AES-128-GCM, AES-256-GCM oraz ChaCha20-Poly1305. Połączenie uścisku TCP z sesją TLS 1.3 tworzy standard HTTPS (port 443), chroniący współczesną bankowość, e-commerce i usługi chmurowe.

Gdy w latach 90. stało się jasne, że 32-bitowa przestrzeń adresowa IPv4 ulegnie wyczerpaniu w ciągu kilkunastu lat, inżynierowie IETF zaproponowali rozwiązanie doraźne – mechanizm translacji adresów sieciowych NAT (Network Address Translation) znormalizowany w dokumencie RFC 3022. Rozwiązanie to, w połączeniu z wydzieleniem prywatnych pul adresowych w RFC 1918 (10.0.0.0/8, 172.16.0.0/12 oraz 192.168.0.0/16), przedłużyło funkcjonowanie protokołu IPv4 o ponad ćwierć wieku.

W inżynierii sieciowej wyróżnia się trzy główne tryby translacji adresowej: 1) Statyczny NAT (Static NAT / 1:1) – sztywne, jednoznaczne mapowanie jednego adresu prywatnego na jeden dedykowany adres publiczny (często stosowane dla serwerów publicznych w strefie DMZ); 2) Dynamiczny NAT (Dynamic NAT / Pula) – mapowanie stacji na wolny adres publiczny pobierany z puli na czas trwania sesji;

3) NAPT / PAT (Port Address Translation / NAT Overload) – najbardziej rozpowszechniony tryb stosowany w każdym routerze domowym i korporacyjnym. Router posiada tylko jeden publiczny adres IP na interfejsie WAN. Gdy komputer z adresem 192.168.1.50 nawiązuje połączenie z serwerem internetowym z portu źródłowego 52140, router podmienia Source IP na swój publiczny adres IP, a Source Port na wolny port logiczny (np. 61001), zapisując mapowanie w tabeli translacji stanów (NAT Translation Table). Gdy serwer odsyła odpowiedź na port 61001, router odnajduje wpis w tabeli, podmienia adres docelowy z powrotem na 192.168.1.50:52140 i przekazuje pakiet do sieci LAN.

Warto pamiętać o istotnych wadach technologii NAT: NAT bezpowrotnie łamie model łączności koniec-do-końca (End-to-End), uniemożliwiając stacjom z zewnątrz bezpośrednie nawiązanie połączenia z urządzeniem w sieci prywatnej (wymaga ręcznego konfigurowania reguł Port Forwarding / DNAT). Ponadto stwarza potężne problemy dla protokołów, które przesyłają adresy IP wewnątrz ładunku aplikacji (np. protokół SIP w VoIP czy aktywny FTP), wymagając stosowania zaawansowanych bramek aplikacyjnych ALG (Application Layer Gateway) lub protokołów traversal (STUN, TURN, ICE). U dostawców ISP powszechny jest mechanizm CGNAT (Carrier-Grade NAT, RFC 6598 – pula 100.64.0.0/10), gdzie klient znajduje się za podwójnym NAT-em operatora.

W ramach dotychczasowych analiz poznaliśmy architekturę stosu protokołów TCP/IP, który stanowi rzeczywisty, technologiczny kręgosłup współczesnego społeczeństwa informacyjnego. Zrozumienie, jak poszczególne klocki tej układanki współdziałają ze sobą, pozwala na precyzyjne projektowanie, optymalizację i diagnozowanie systemów sieciowych w skali lokalnej i globalnej.

Kluczowe wnioski inżynierskie podsumowujące architekturę stosu internetowego obejmują:

1) Architekturę klepsydry (Hourglass Model): całkowitą niezależność aplikacji i fizycznych mediów transmisyjnych skupioną wokół uniwersalnego protokołu warstwy internetowej – IP (RFC 791 / RFC 8200), realizującego bezpołączeniowy routing Best-Effort w oparciu o tablicę tras i regułę Longest Prefix Match;

2) Dwoistość warstwy transportowej: istnienie dwóch komplementarnych modeli transportu danych proces-proces: w pełni niezawodnego, stanowego protokołu TCP (RFC 9293) z mechanizmami uścisku 3-Way Handshake, kontroli przepływu (Sliding Window) i unikania zatorów (Congestion Control) oraz minimalistycznego, szybkiego protokołu UDP (RFC 768) o stałym 8-bajtowym nagłówku;

3) Kluczową rolę usług infrastrukturalnych: bezwzględne znaczenie poprawnego funkcjonowania protokołów pomocniczych – rozproszonego systemu DNS dla mapowania nazw na adresy IP, protokołu DHCP realizującego automatyczną konfigurację w cyklu DORA, protokołu ICMP dla sygnalizacji błędów i diagnostyki osiągalności oraz technologii translacji NAT/PAT oszczędzającej pulę IPv4.

Poniższa tabela stanowi zintegrowane zestawienie inżynierskie, pozwalające na natychmiastowe porównanie cech operacyjnych protokołów warstwy transportowej:

Kryteria inżynierskiego doboru protokołu: Wybór pomiędzy TCP a UDP determinuje charakter wymagań aplikacji. W systemach transakcyjnych, przesyłaniu plików (HTTP, SSH, FTP) czy poczcie elektronicznej (SMTP, IMAP) niezawodność i bezbłędność są krytyczne, co narzuca wybór TCP pomimo narzutu na zestawianie połączenia i retransmisje. W aplikacjach czasu rzeczywistego (VoIP, streaming wideo na żywo, telemetria przemysłowa, gry sieciowe) kluczowe jest minimalne opóźnienie (latency) i brak zjawiska Head-of-Line Blocking, dlatego stosuje się UDP, delegując ewentualną kontrolę kolejności do warstw wyższych (np. protokołu RTP, RFC 3550).

Pytanie sprawdzające znajomość architektury internetowej:

Pytanie: Wymień cztery warstwy modelu TCP/IP zdefiniowane w normie RFC 1122 od warstwy najniższej do najwyższej oraz krótko opisz główną odpowiedzialność każdej z nich.
Odpowiedź akademicka: Zgodnie ze standardem RFC 1122 model TCP/IP składa się z czterech warstw:

1. Warstwa Dostępu do sieci (Network Access / Link Layer): odpowiada za transmisję danych przez fizyczne medium lokalne, obsługę sterowników kart sieciowych, formatowanie ramek (np. Ethernet, Wi-Fi) oraz rozwiązywanie adresów logicznych na sprzętowe (ARP / NDP);
2. Warstwa Internetowa (Internet Layer): odpowiada za globalne logiczne adresowanie hostów (IPv4, IPv6), pakietowanie oraz trasowanie (routing) datagramów pomiędzy różnymi sieciami w trybie Best-Effort;

3. Warstwa Transportowa (Transport / Host-to-Host Layer): odpowiada za komunikację proces-proces za pomocą 16-bitowych portów logicznych, segmentację oraz dostarczanie usług transportowych: niezawodnych (TCP) lub szybkich i bezpołączeniowych (UDP);
4. Warstwa Aplikacji (Application Layer): integruje usługi i protokoły bezpośrednio wykorzystywane przez oprogramowanie użytkownika (HTTP, DNS, DHCP, SSH), łącząc funkcje warstw sesji, prezentacji i aplikacji modelu OSI.

Pytanie sprawdzające zrozumienie mechanizmów warstwy transportowej:

Pytanie: W jaki sposób protokół TCP reaguje na utratę pakietu w sieci, a w jaki sposób reaguje na to protokół UDP?
Odpowiedź akademicka: Reakcja obu protokołów na utratę pakietu odzwierciedla ich przeciwstawne filozofie inżynierskie:

• Protokół TCP (RFC 9293): Wykrywa utratę pakietu za pomocą dwóch mechanizmów: 1) Wygaśnięcia zegara retransmisji RTO (Retransmission Timeout), którego wartość jest dynamicznie wyliczana na podstawie pomiarów RTT; 2) Odebrania trzech zduplikowanych potwierdzeń (Triple Duplicate ACK) od odbiorcy. Po wykryciu straty TCP natychmiast retransmituje utracony segment, zmniejsza okno przeciążenia cwnd o połowę (lub do 1 MSS w przypadku RTO) i wstrzymuje tempo nadawania, zakładając wystąpienie zatoru w buforach routerów. Aplikacja odbiorcy otrzymuje w 100% kompletny strumień danych bez dziur;

• Protokół UDP (RFC 768): Nie reaguje w żaden sposób. Protokół UDP nie śledzi wysłanych datagramów, nie utrzymuje zegarów RTO ani nie oczekuje żadnych potwierdzeń. Jeśli pakiet zginie na uszkodzonym łączu lub przepełnionym buforze, przepada bezpowrotnie. To sama aplikacja (jeśli tego wymaga) musi we własnym kodzie zaimplementować mechanizm wykrywania strat (jak czyni to np. protokół RTP w telefonii VoIP, maskując brakujące milisekundy głosu interpolacją).

Pytanie sprawdzające znajomość mapowania adresów L3 na L2:

Pytanie: Do czego służy protokół ARP w sieciach IPv4, jaki typ komunikacji (Broadcast czy Unicast) wykorzystują zapytania i odpowiedzi ARP oraz co to jest pamięć podręczna ARP Cache?
Odpowiedź akademicka: Protokół ARP (Address Resolution Protocol, RFC 826) służy do dynamicznego mapowania znanego 32-bitowego adresu logicznego warstwy sieciowej (Adres IPv4) na nieznany 48-bitowy adres fizyczny warstwy łącza danych (Adres MAC) w obrębie tego samego segmentu sieci lokalnej.

Przebieg komunikacji ARP obejmuje dwa odmienne tryby transmisji:
1) ARP Request (Zapytanie) jest wysyłane w trybie rozgłoszeniowym (Broadcast) na docelowy adres MAC FF:FF:FF:FF:FF:FF. Ponieważ nadawca nie wie, kto posiada dany adres IP, zapytanie musi odebrać każde urządzenie w domenie rozgłoszeniowej;
2) ARP Reply (Odpowiedź) jest wysyłana w trybie indywidualnym (Unicast) bezpośrednio na adres MAC stacji pytającej, ponieważ stacja docelowa odczytała już adres MAC pytającego z nagłówka zapytania.

Pamięć podręczna ARP Cache to tablica dynamiczna w pamięci RAM systemu operacyjnego, w której jądro zapamiętuje pary (Adres IP, Adres MAC). Wpisy wygasają po zdefiniowanym czasie (Aging Timer, typowo 2–20 minut). Pamięć ta drastycznie redukuje liczbę rozgłoszeń w sieci LAN. Brak mechanizmów uwierzytelniania w protokole ARP sprawia, że jest on podatny na atak ARP Spoofing / Cache Poisoning, w którym intruz fałszuje wpisy w tablicach sąsiadów.

Pytanie sprawdzające znajomość protokołu ICMP:

Pytanie: Wymień trzy główne zastosowania protokołu ICMP w diagnostyce i zarządzaniu siecią oraz podaj typy komunikatów odpowiadające tym funkcjom.
Odpowiedź akademicka: Trzy kluczowe zastosowania protokołu ICMP (RFC 792) w praktyce inżynierskiej to:

1) Testowanie osiągalności i opóźnień (Narzędzie ping): Wykorzystuje komunikaty Echo Request (Typ 8) oraz Echo Reply (Typ 0). Pozwala na zweryfikowanie poprawności działania warstwy sieciowej hosta zdalnego oraz zmierzenie czasu propagacji sygnału w obie strony (RTT);
2) Śledzenie ścieżki pakietu (Narzędzie traceroute / mtr): Wykorzystuje komunikat Time Exceeded (Typ 11, Kod 0: Time to Live exceeded in transit) generowany przez router w momencie, gdy licznik TTL pakietu zostanie zdekrementowany do zera, co pozwala na identyfikację kolejnych węzłów pośredniczących na trasie;

3) Sygnalizacja niemożności dostarczenia oraz wykrywanie MTU ścieżki (PMTUD): Wykorzystuje komunikat Destination Unreachable (Typ 3). W szczególności Kod 4 (Fragmentation Needed and DF set) informuje nadawcę, że pakiet jest zbyt duży dla danego łącza i musi zostać zmniejszony, co stanowi fundament algorytmu Path MTU Discovery (RFC 1191). Dodatkowo komunikat Redirect (Typ 5) informuje stację o optymalniejszej trasie lokalnej.

Pytanie sprawdzające znajomość procedury nawiązywania sesji TCP:

Pytanie: Przedstaw dokładną sekwencję wymiany segmentów w procedurze 3-Way Handshake, podając jakie flagi są ustawione w każdym segmencie oraz jak wyliczane są numery Sequence Number i Acknowledgment Number.
Odpowiedź akademicka: Procedura trójfazowego uścisku dłoni protokołu TCP (RFC 9293) przebiega według następującej ścisłej matematycznej sekwencji:

• Segment 1 (Klient -> Serwer):
Flagi: SYN = 1, ACK = 0. Klient losuje swój początkowy numer sekwencyjny: Sequence Number = ISN_c. Pole Acknowledgment Number jest nieaktywne (zerowe);
• Segment 2 (Serwer -> Klient):
Flagi: SYN = 1, ACK = 1. Serwer losuje swój niezależny numer sekwencyjny: Sequence Number = ISN_s. W polu potwierdzenia wpisuje: Acknowledgment Number = ISN_c + 1 (potwierdzając odebranie wirtualnego bajtu flagi SYN klienta);

• Segment 3 (Klient -> Serwer):
Flagi: ACK = 1, SYN = 0. Klient ustawia Sequence Number = ISN_c + 1 oraz potwierdza numer serwera: Acknowledgment Number = ISN_s + 1.
Po odebraniu tego segmentu przez serwer oba gniazda przechodzą w stan ESTABLISHED. Warto pamiętać, że flaga SYN (podobnie jak flaga FIN) konsumuje dokładnie jeden wirtualny numer sekwencyjny w przestrzeni numeracji TCP, mimo że nie niesie ze sobą żadnego fizycznego ładunku danych aplikacji.

Pytanie sprawdzające zrozumienie mechanizmów warstwy sieciowej:

Pytanie: Dlaczego w nagłówku każdego pakietu IPv4 musi znajdować się pole TTL (Time to Live) i co dokładnie dzieje się z pakietem, gdy wartość tego pola spadnie do zera?
Odpowiedź akademicka: W rozległych sieciach o dynamicznej strukturze połączeń (jak internet) w wyniku błędów konfiguracyjnych administratorów lub chwilowych stanów niestabilności protokołów dynamicznego routingu (zbieżność sieci – Convergence) mogą powstawać pętle routingowe (Routing Loops), w których router A przesyła pakiet do routera B, a router B odsyła go z powrotem do routera A.

Gdyby pakiet nie posiadał mechanizmu ograniczania żywotności, krążyłby w takiej pętli w nieskończoność. Przy tysiącach takich pakietów doszłoby do natychmiastowego nasycenia łączy (100% utylizacji pasma) i paraliżu sieci. 8-bitowe pole TTL (Time to Live) w nagłówku IPv4 (oraz pole Hop Limit w IPv6) zapobiega tej katastrofie:

Każdy router pośredniczący, przez który przechodzi pakiet, ma bezwzględny obowiązek zmniejszyć wartość pola TTL dokładnie o 1. Jeśli po dekrementacji wartość pola osiągnie zero (TTL = 0), router nie przekazuje pakietu dalej, lecz natychmiast go niszczy, wysyłając do nadawcy pakietu komunikat błędu ICMP Type 11 Code 0 (Time-to-Live Exceeded in Transit). Dzięki temu pętle routingowe są samogaszące, a pakiety nigdy nie krążą w próżni dłużej niż przez maksymalną zdefiniowaną liczbę skoków (typowo 64, 128 lub 255).

Pytanie sprawdzające zakres zadań warstwy internetowej:

Pytanie: Za co odpowiada, a za co celowo NIE odpowiada warstwa internetowa (IP) w modelu TCP/IP?
Odpowiedź akademicka: Zakres odpowiedzialności warstwy internetowej (IP) jest ściśle zdefiniowany przez filozofię prostego rdzenia sieci:

• Warstwa internetowa ODPOWIADA za:
1. Logiczne adresowanie urządzeń – przypisanie unikalnych adresów IP w skali globalnej;
2. Trasowanie pakietów (Routing) – podejmowanie decyzji o kolejnym przeskoku (Next Hop) na podstawie tablicy routingu i reguły Longest Prefix Match;
3. Kontrolę żywotności pakietu – dekrementację licznika TTL w celu zapobiegania pętlom;
4. Fragmentację i reasemblację – dzielenie zbyt dużych pakietów IP w sytuacji, gdy MTU kolejnego łącza jest mniejsze niż rozmiar pakietu (w IPv4).

• Warstwa internetowa celowo NIE ODPOWIADA za:
1. Gwarancję dostarczenia danych – protokół IP działa w trybie Best-Effort; nie wysyła potwierdzeń i nie ponawia utraconych pakietów;
2. Zachowanie kolejności danych – pakiety mogą docierać do celu w zmienionej kolejności (Packet Reordering);
3. Kontrolę przepływu i unikanie zatorów – IP przesyła pakiety tak szybko, jak otrzymuje je od warstwy wyższej, aż do momentu odrzucenia przez bufory routera;
4. Identyfikację aplikacji – IP nie rozróżnia portów logicznych ani procesów; doprowadza pakiet wyłącznie do interfejsu hosta docelowego. Wszystkie te wyłączone zadania spoczywają na warstwie transportowej (TCP).

Pytanie sprawdzające znajomość protokołów sieci Web:

Pytanie: Jaka jest fundamentalna różnica pomiędzy protokołem HTTP na porcie TCP 80 a protokołem HTTPS na porcie TCP 443 w kontekście bezpieczeństwa i analizy w programie Wireshark?
Odpowiedź akademicka: Różnica pomiędzy protokołem HTTP a HTTPS leży w obecności kryptograficznej warstwy pośredniczącej TLS (Transport Layer Security):

• Protokół HTTP (Port TCP 80): Przesyła dane aplikacji (żądania GET, nagłówki, ciasteczka sesyjne, hasła w formularzach POST) w postaci czystego tekstu jawnego (Cleartext). W programie Wireshark każdy przechwycony pakiet jest w 100% czytelny dla każdego użytkownika w tej samej sieci Wi-Fi lub na trasie tranzytu operatora. Protokół ten jest podatny na podsłuch (Eavesdropping), manipulację treścią (Tampering) oraz ataki podszywania się (Spoofing);

• Protokół HTTPS (Port TCP 443): Nie jest odrębnym protokołem aplikacyjnym, lecz protokołem HTTP enkapsulowanym wewnątrz bezpiecznego tunelu TLS 1.2 / TLS 1.3. Przed przesłaniem jakichkolwiek danych aplikacyjnych klient i serwer wykonują uścisk kryptograficzny, uwierzytelniają tożsamość serwera za pomocą certyfikatu cyfrowego X.509 i uzgadniają symetryczny klucz szyfrowania sesji (np. AES-256-GCM). W programie Wireshark cały ruch widoczny jest wyłącznie jako nieczytelny strumień szyfrogramu (Application Data), uniemożliwiający podejrzenie adresów URL, nagłówków czy treści przesyłanych stron bez posiadania kluczy prywatnych sesji.

Pytanie sprawdzające znajomość abstrakcji programistycznej gniazd:

Pytanie: Czym jest gniazdo sieciowe (Socket) w architekturze TCP/IP i jakie elementy wchodzą w skład tzw. 5-krotki sieciowej (5-tuple) unikalnie identyfikującej połączenie w internecie?
Odpowiedź akademicka: W architekturze teleinformatycznej gniazdo sieciowe (Socket) jest abstrakcyjnym punktem końcowym dwukierunkowego kanału komunikacyjnego pomiędzy procesami w sieci komputerowej. W sensie adresowym gniazdo jest jednoznacznie zdefiniowane jako połączenie adresu warstwy sieciowej oraz portu warstwy transportowej: Gniazdo = (Adres IP, Numer Portu) (np. 192.168.1.100:443).

Każde aktywne połączenie w globalnym internecie jest w danym momencie czasu unikalnie zdefiniowane przez zestaw pięciu parametrów, zwany w inżynierii sieciowej piątką sieciową (5-tuple):
1. Protokół warstwy transportowej (TCP lub UDP);
2. Źródłowy adres IP (Source IP);
3. Źródłowy numer portu (Source Port);
4. Docelowy adres IP (Destination IP);
5. Docelowy numer portu (Destination Port).

Dzięki 5-krotce serwer WWW o pojedynczym adresie IP (np. 203.0.113.10) nasłuchujący na jednym porcie 443 potrafi bezbłędnie rozróżnić tysiące równoległych połączeń pochodzących od tego samego klienta (ponieważ każde połączenie z przeglądarki ma inny wylosowany port źródłowy) lub od różnych klientów w internecie. Tablica stanów połączeń firewalla oraz moduły NAT operują bezpośrednio na 5-krotkach.

Pytanie sprawdzające znajomość metod wyznaczania tras w warstwie sieciowej:

Pytanie: Porównaj routing statyczny z routingiem dynamicznym, wskazując ich zalety, wady oraz typowe scenariusze zastosowań w projektowaniu sieci.
Odpowiedź akademicka: Zestawienie obu paradygmatów wyznaczania tras w sieciach IP przedstawia się następująco:

• Routing statyczny (Static Routing): Trasy są wprowadzane do tablicy routingu ręcznie przez administratora sieci (np. poleceniem ip route add 10.0.0.0/8 via 192.168.1.1).
Zalety: Całkowity brak narzutu na pasmo (routery nie wymieniają żadnych pakietów aktualizacji), brak obciążenia procesora CPU routera, pełna kontrola administratora i wysokie bezpieczeństwo (brak podatności na sfałszowanie tras).
Wady: Brak odporności na awarie (jeśli łącze fizyczne ulegnie uszkodzeniu, router nadal próbuje wysyłać tam pakiety, dopóki administrator ręcznie nie zmieni konfiguracji), skrajnie niska skalowalność (niemożliwe do utrzymania w sieci z setkami routerów).
Zastosowanie: Trasa domyślna (Default Route 0.0.0.0/0) na brzegu sieci, sieci o prostej topologii gwiazdy (Stub Networks);

• Routing dynamiczny (Dynamic Routing): Routery uruchamiają procesy protokołów routingu (np. OSPF, IS-IS, BGP) i automatycznie wymieniają informacje o dostępnych sieciach i metrykach.
Zalety: Automatyczna adaptacja do awarii – w przypadku przerwania światłowodu routery w ułamku sekundy wykrywają brak łączności, przeliczają algorytmy tras (np. Dijkstry) i kierują ruch ścieżką zapasową; doskonała skalowalność.
Wady: Zużycie pasma na pakiety sterujące (Hello, LSA), obciążenie procesora i pamięci routera, ryzyko ataków na protokoły routingu.
Zastosowanie: Sieci kampusowe, korporacyjne, centra danych oraz globalny internet (BGP-4).

Pytanie sprawdzające znajomość mechanizmu translacji adresów:

Pytanie: Dlaczego wprowadzono mechanizm translacji NAT w sieciach IPv4 i w jaki sposób technologia PAT umożliwia setkom komputerów równoczesne korzystanie z internetu przez jeden publiczny adres IP?
Odpowiedź akademicka: Mechanizm NAT (Network Address Translation, RFC 3022) został wprowadzony w połowie lat 90. w celu powstrzymania natychmiastowego wyczerpania ograniczonej puli adresów IPv4. Umożliwił on podział adresacji na adresy publiczne (unikalne globalnie w internecie) oraz adresy prywatne zdefiniowane w normie RFC 1918 (np. 192.168.0.0/16, 10.0.0.0/8), które mogą być wielokrotnie i niezależnie wykorzystywane w milionach prywatnych sieci na świecie.

Odmiana PAT (Port Address Translation / NAT Overload) realizuje jednoczesny dostęp setek urządzeń poprzez dynamiczne mapowanie portów warstwy transportowej (L4):

Gdy stacja robocza z adresem prywatnym wysyła pakiet do internetu, router brzegowy:
1. Podmienia prywatny źródłowy adres IP na swój własny pojedynczy publiczny adres IP;
2. Podmienia źródłowy port TCP/UDP na wolny, unikalny port wylosowany ze swojej puli (np. port 45123);
3. Zapisuje powiązanie w tabeli stanów: (Prywatny IP:Port) <-> (Publiczny IP:Port).
Gdy serwer internetowy odpowiada, kieruje pakiet na publiczny adres IP i port 45123 routera. Router odczytuje tabelę translacji, przywraca oryginalny prywatny adres i port stacji, po czym przekazuje pakiet do sieci wewnętrznej. Ponieważ przestrzeń portów obejmuje ponad 60 000 wartości, pojedynczy publiczny adres IP może obsłużyć dziesiątki tysięcy równoległych sesji.

Pytanie sprawdzające znajomość maszyny stanów TCP:

Pytanie: Co oznaczają stany ESTABLISHED, TIME_WAIT oraz CLOSE_WAIT w maszynie stanów protokołu TCP i jak ich nagromadzenie wpływa na wydajność serwera?
Odpowiedź akademicka: Interpretacja stanów protokołu TCP (RFC 9293) w diagnostyce serwerowej przedstawia się następująco:

• ESTABLISHED: Stan pełnej, aktywnej sesji dwukierunkowej. Uścisk dłoni 3-Way Handshake został zakończony pomyślnie, obie strony wymieniają dane lub utrzymują gotowość za pomocą pakietów Keep-Alive;
• TIME_WAIT: Stan po stronie hosta, który jako pierwszy zainicjował zamknięcie sesji (wysłał FIN). Po odebraniu ACK i FIN host oczekuje przez czas 2MSL (typowo 60 s) na wygaśnięcie ewentualnych opóźnionych pakietów w sieci. Wpływ na serwer: Nagromadzenie dziesiątek tysięcy gniazd w stanie TIME_WAIT na mocno obciążonym serwerze WWW (np. po testach wydajnościowych) prowadzi do wyczerpania wolnych portów efemerycznych (Ephemeral Port Exhaustion), uniemożliwiając nawiązywanie nowych połączeń wychodzących;

• CLOSE_WAIT: Stan po stronie hosta, który odebrał segment FIN od partnera, odesłał ACK i oczekuje, aż lokalna aplikacja wywoła funkcję systemową close() w celu odesłania własnego FIN. Wpływ na serwer: Nagromadzenie gniazd w stanie CLOSE_WAIT jest niemal zawsze objawem błędu programistycznego w kodzie aplikacji serwera (Software Bug / Resource Leak) – oznacza, że program odebrał informację o zamknięciu sesji przez klienta, lecz zawiesił się i „zapomniał” zamknąć uchwyt gniazda, blokując pamięć RAM i deskryptory plików.

Pytanie sprawdzające znajomość architektury i procedury zapytań DNS:

Pytanie: Na czym polega różnica pomiędzy zapytaniem rekurencyjnym (Recursive Query) a zapytaniem iteracyjnym (Iterative Query) w systemie DNS i jak parametr TTL w rekordzie zasobowym wpływa na ruch w sieci?
Odpowiedź akademicka: W rozproszonej architekturze systemu DNS (RFC 1035) występują dwa fundamentalne modele zapytań:

• Zapytanie rekurencyjne (Recursive Query): Wysyłane przez stację kliencką (np. komputer użytkownika) do lokalnego resolwera DNS (np. serwera dostawcy ISP lub publicznego 8.8.8.8). Klient żąda: „Rozwiąż dla mnie tę nazwę i zwróć ostateczny adres IP lub błąd; nie odsyłaj mnie do innych serwerów”. Cały ciężar komunikacji wieloetapowej spoczywa na resolwerze;

• Zapytanie iteracyjne (Iterative Query / Non-recursive): Wysyłane przez resolwer do kolejnych serwerów w hierarchii DNS (serwerów Root, następnie serwerów TLD, np. .pl, aż do autorytatywnych serwerów domeny). Odpytywany serwer odpowiada: „Nie znam bezpośredniego adresu IP tego hosta, ale oto adres kolejnego serwera w hierarchii, który wie więcej ode mnie (delegacja NS)”. Resolwer samodzielnie odpytuje kolejne węzły krok po kroku.

Parametr TTL (Time to Live) w rekordzie zasobowym DNS określa czas (w sekundach), przez jaki resolwery pośredniczące oraz stacje klienckie mają prawo przechowywać odpowiedź w swojej lokalnej pamięci podręcznej (DNS Cache). Długi czas TTL (np. 86 400 s = 24 h) drastycznie redukuje ruch w internecie i przyspiesza otwieranie stron, lecz opóźnia propagację zmian przy migracji serwera na nowy adres IP. Krótki TTL (np. 60–300 s) pozwala na natychmiastowe przełączanie ruchu w systemach Disaster Recovery, kosztem częstszego generowania zapytań przez klientów.

Pytanie sprawdzające znajomość protokołu automatycznej konfiguracji hosta:

Pytanie: Opisz cztery fazy cyklu DORA protokołu DHCP, wyjaśniając jakie porty warstwy transportowej są wykorzystywane oraz co oznaczają czasy T1 i T2 w procesie dzierżawy adresu IP.
Odpowiedź akademicka: Protokół DHCP (RFC 2131) operuje w warstwie transportowej na datagramach UDP, wykorzystując port 67 dla serwera oraz port 68 dla klienta. Sekwencja przydziału adresu obejmuje cztery etapy:

1. Discover (D): Klient po podłączeniu do medium nie posiada adresu IP (Source IP: 0.0.0.0) i wysyła zapytanie rozgłoszeniowe (Destination IP: 255.255.255.255) w poszukiwaniu serwera DHCP;
2. Offer (O): Serwer DHCP rezerwuje adres IP z puli i odsyła ofertę z proponowanym adresem, maską i parametrami sieci;
3. Request (R): Klient wysyła rozgłoszeniowy komunikat informujący, którą ofertę akceptuje (formalne żądanie przydziału);
4. Acknowledge (A): Serwer potwierdza przydział, przesyłając pełny zestaw opcji (Default Gateway, DNS) oraz czas dzierżawy (Lease Time).

W procesie nadzorowania dzierżawy kluczową rolę odgrywają dwa zegary:
• Czas T1 (Renewal Time = 50% Lease Time): Klient wysyła bezpośrednie zapytanie Unicast (Request) do serwera, który wydał dzierżawę, żądając jej przedłużenia. Jeśli serwer odpowie ACK, zegar dzierżawy zostaje zresetowany do 100%;
• Czas T2 (Rebinding Time = 87,5% Lease Time): Jeśli serwer pierwotny nie odpowiedział (np. uległ awarii), klient przechodzi w tryb Broadcast, pytając dowolny inny serwer DHCP w podsieci o możliwość przedłużenia dzierżawy. Jeśli czas osiągnie 100%, klient traci prawo do adresu i natychmiast zwalnia interfejs.

Pytanie sprawdzające wiedzę z zakresu nowej generacji protokołu internetowego:

Pytanie: Wskaż cztery kluczowe różnice konstrukcyjne pomiędzy protokołem IPv4 a IPv6 poza samą długością adresu i wyjaśnij, jakie korzyści inżynierskie przyniosły te zmiany.
Odpowiedź akademicka: Cztery fundamentalne różnice architektoniczne pomiędzy IPv4 (RFC 791) a IPv6 (RFC 8200) to:

1) Stały, uproszczony nagłówek bazowy: W IPv4 nagłówek ma zmienną długość (20–60 B z opcjami), co zmusza routery do analizy pola IHL. W IPv6 nagłówek ma zawsze stałą długość 40 bajtów. Wszystkie opcje przeniesiono do opcjonalnych nagłówków rozszerzeń (Extension Headers) doklejanych sekwencyjnie. Pozwala to na przetwarzanie pakietów przez sprzętowe układy ASIC routerów w potokach stałoczasowych;
2) Eliminacja sumy kontrolnej w warstwie sieciowej (Brak Header Checksum): W IPv4 każdy router musiał weryfikować i przeliczać na nowo sumę kontrolną z powodu dekrementacji TTL. W IPv6 całkowicie zrezygnowano z sumy w L3, polegając na silnych sumach kontrolnych L2 (FCS w Ethernet/Wi-Fi) oraz L4 (obowiązkowy Checksum w TCP/UDP), co drastycznie odciąża procesory routerów;

3) Zakaz fragmentacji w routerach pośredniczących: W IPv4 router mógł podzielić zbyt duży pakiet. W IPv6 routery pośredniczące nigdy nie fragmentują pakietów – jeśli pakiet jest za duży, router natychmiast go odrzuca i odsyła ICMPv6 Packet Too Big, zmuszając hosta nadawczego do redukcji rozmiaru pakietu (mechanizm PMTUD);
4) Całkowita likwidacja transmisji rozgłoszeniowej (Brak Broadcastu): W IPv4 zapytania ARP obciążały wszystkie urządzenia w sieci LAN. W IPv6 broadcast zastąpiono precyzyjną komunikacją grupową Multicast za pośrednictwem protokołu NDP (Neighbor Discovery Protocol), co eliminuje zbędne budzenie stacji klienckich z trybów oszczędzania energii.

Pytanie sprawdzające znajomość ograniczeń rozmiaru pakietu w warstwie sieciowej:

Pytanie: Czym jest jednostka MTU, czym różni się od parametru MSS w warstwie transportowej i co to jest zjawisko „czarnej dziury MTU” (MTU Black Hole)?
Odpowiedź akademicka: Precyzyjne rozróżnienie pojęć MTU i MSS oraz analiza ich wpływu na transmisję:

• MTU (Maximum Transmission Unit): Maksymalny rozmiar kompletnego pakietu warstwy sieciowej (wraz z nagłówkiem IP i ładunkiem danych), jaki może zostać przesłany w pojedynczej ramce przez dane medium fizyczne bez fragmentacji. Dla standardowego Ethernetu MTU wynosi dokładnie 1500 bajtów;
• MSS (Maximum Segment Size): Maksymalny rozmiar samego ładunku danych aplikacji, jaki protokół TCP może umieścić w pojedynczym segmencie. Relacja matematyczna wynosi: MSS = MTU - Nagłówek_IP (20 B) - Nagłówek_TCP (20 B) = 1460 bajtów;

• Zjawisko MTU Black Hole (Czarna dziura MTU): Występuje, gdy stacja nadawcza wysyła pakiety o maksymalnym rozmiarze MTU 1500 B z ustawioną flagą DF = 1 (Don't Fragment) w ramach algorytmu PMTUD (RFC 1191). Jeśli na trasie znajduje się łącze o mniejszym MTU (np. tunel VPN IPsec lub łącze PPPoE o MTU 1420 B), router tunelowy musi odrzucić pakiet i odesłać komunikat ICMP Type 3 Code 4 (Fragmentation Needed and DF set).
Jeśli jednak błędnie skonfigurowana zapora ogniowa (firewall) po drodze zablokuje ruch ICMP, komunikat błędu nigdy nie dotrze do nadawcy! Nadawca nie wie, dlaczego nie ma potwierdzenia, i bez końca ponawia duże pakiety, podczas gdy małe pakiety (np. handshake TCP) przechodzą bez przeszkód. Objawia się to zawieszeniem ładowania stron WWW i transferów plików przy pozornie działającym połączeniu.

Pytanie sprawdzające praktyczny warsztat inżynierski:

Pytanie: Jakich narzędzi konsolowych użyjesz, aby: 1) sprawdzić czy zdalny serwer odpowiada w warstwie sieciowej, 2) sprawdzić jakie procesy nasłuchują na portach TCP na serwerze Linux, 3) zweryfikować czy rekord domeny wskazuje na właściwy IP, oraz 4) zbadać dokładny kod odpowiedzi serwera WWW?
Odpowiedź akademicka: Prawidłowy dobór narzędzi diagnostycznych w środowisku produkcyjnym:

1. Badanie osiągalności w warstwie sieciowej (L3): Polecenie ping (np. ping -c 4 192.168.1.1). Wysyła pakiety ICMP Echo Request, weryfikując czy stos IP serwera docelowego oraz routery pośredniczące funkcjonują poprawnie i mierząc czas RTT;
2. Inspekcja portów nasłuchujących w systemie Linux (L4): Polecenie ss (Socket Statistics) z przełącznikami ss -tulpn (lub starsze netstat -tulpn). Opcje oznaczają: -t (TCP), -u (UDP), -l (tylko stany LISTEN), -p (pokaż proces PID i nazwę programu), -n (format numeryczny bez powolnego rozwiązywania nazw portów);

3. Weryfikacja rekordu domenowego (L7): Polecenie dig (Domain Information Grokper) lub nslookup (np. dig +short agh.edu.pl A). Zwraca autorytatywną odpowiedź bezpośrednio z serwerów DNS, prezentując mapowany adres IP oraz czas TTL rekordu;
4. Badanie kodu odpowiedzi aplikacji Web (L7): Narzędzie curl z przełącznikiem pobierania wyłącznie nagłówków: curl -I https://serwer.pl. Zwraca kody statusu HTTP (np. HTTP/2 200 OK, 301 Moved Permanently, 403 Forbidden, 502 Bad Gateway) wraz z nagłówkami serwera bez pobierania całej zawartości strony.

Pytanie sprawdzające zrozumienie filozofii projektowej internetu:

Pytanie: Dlaczego twórcy protokołu IP celowo zrezygnowali z mechanizmów gwarancji dostarczania pakietów w warstwie sieciowej, przyjmując model Best-Effort, i w jaki sposób decyzja ta zadecydowała o globalnym sukcesie internetu?
Odpowiedź akademicka: W tradycyjnych sieciach telekomunikacyjnych (np. w sieciach telefonicznych PSTN czy standardzie X.25) cała odpowiedzialność za niezawodność, rezerwację pasma i kontrolę błędów spoczywała na węzłach centralnych (centralach telefonicznych). Wymagało to budowania skrajnie drogich, skomplikowanych urządzeń pośredniczących utrzymujących pamięć o każdym realizowanym połączeniu.

Twórcy protokołu IP przyjęli diametralnie odmienną koncepcję, zwaną zasadą głupiej sieci i inteligentnych brzegów (Dumb Network, Smart Edges). Zastosowanie modelu Best-Effort (Dostarczanie z maksymalną starannością) w warstwie sieciowej przyniosło kluczowe korzyści:

1) Maksymalna prostota i gigantyczna wydajność routerów: Router szkieletowy nie musi śledzić stanów połączeń, nie pamięta wysłanych pakietów, nie czeka na potwierdzenia ani nie alokuje pamięci na retransmisje. Jego zadaniem jest wyłącznie odczytanie adresu IP i przekazanie pakietu w mikrosekundowym takcie zegara sprzętowego ASIC;
2) Niezależność od mediów transmisyjnych: Protokół IP potrafi działać na medium o dowolnie niskiej jakości (nawet na łączach radiowych o wysokiej stopie błędów bitowych), ponieważ sam nie stawia żadnych wymagań odnośnie bezbłędności łącza;

3) Skalowalność do miliardów węzłów: Gdyby każdy router musiał gwarantować dostarczenie każdego pakietu, globalny internet z milionami równoległych transferów uległby natychmiastowemu załamaniu pod ciężarem pamięci stanu. Złożoność zapewniania niezawodności została przeniesiona tam, gdzie są zasoby obliczeniowe – do procesorów komputerów i serwerów końcowych realizujących protokół TCP.

Pytanie sprawdzające biegłość operowania modelami sieciowymi:

Pytanie: Dlaczego w ogłoszeniach o pracę dla inżynierów sieciowych wymaga się „znajomości modelu OSI”, skoro w rzeczywistości wszystkie urządzenia działają pod kontrolą stosu TCP/IP?
Odpowiedź akademicka: Wymóg ten wynika z faktu, że model ISO/OSI jest uniwersalnym językiem opisu architektury i diagnostyki teleinformatycznej, podczas gdy stos TCP/IP jest konkretnym zestawem protokołów programowych:

1) Precyzja komunikacji technicznej w branży IT: Producenci sprzętu (Cisco, Juniper, Arista, Fortinet) klasyfikują urządzenia i ich funkcje według numerów warstw OSI: „Przełącznik L2” to urządzenie operujące na adresach MAC; „Przełącznik L3” to przełącznik z funkcją routingu IP; „Filtr L4” to zapora filtrująca porty TCP/UDP; „Zapora L7 / WAF” to system analizujący treść HTTP. Gdyby inżynierowie posługiwali się wyłącznie 4-warstwowym modelem TCP/IP, termin „przełącznik warstwy 1” (w TCP/IP Link Layer) byłby mylący, a odróżnienie problemu z kablem od problemu z adresem MAC stałoby się trudniejsze;

2) Struktura procesu usuwania awarii (Troubleshooting): 7-warstwowa dekompozycja modelu OSI dostarcza doskonałej metodyki analitycznej (np. strategie Bottom-Up i Divide-and-Conquer). Inżynier w ułamku sekundy kategoryzuje usterkę: brak linku fizycznego to problem L1, brak adresu w ARP to problem L2, brak bramy to L3, zablokowany port w zaporze to L4, błąd certyfikatu to L6, a błąd bazy danych to L7. Znajomość modelu OSI świadczy o głębokim zrozumieniu praw rządzących systemami rozproszonymi.

W celu praktycznego utrwalenia wiedzy o protokole TCP student powinien samodzielnie wykonać poniższy scenariusz w środowisku laboratoryjnym:

Procedura laboratoryjna krok po kroku:
1. Uruchom program Wireshark na aktywnym interfejsie i ustaw filtr wyświetlania: tcp.flags.syn == 1;
2. Otwórz terminal i nawiąż nowe połączenie za pomocą polecenia curl -I https://www.google.com;
3. Zatrzymaj przechwytywanie i zlokalizuj parę pakietów: SYN (od Twojego komputera) oraz SYN, ACK (odpowiedź serwera Google).

Zadania do wykonania w oknie Packet Details:
• Rozwiń gałąź Transmission Control Protocol i odczytaj pole Flags: upewnij się, które konkretnie bity są ustawione (SYN, ACK), a które mają wartość 0 (RST, FIN, PSH);
• Rozwiń poddrzewo Options (Opcje TCP) w pakiecie SYN i zidentyfikuj kluczowe rozszerzenia:
1. Maximum Segment Size (MSS): odczytaj zaproponowaną wartość (np. 1460 B);
2. TCP Window Scale: odczytaj współczynnik mnożnika okna (np. shift count 7 = mnożnik 128);
3. SACK Permitted: sprawdź, czy włączona jest obsługa selektywnych potwierdzeń;
4. Timestamps: odczytaj znaczniki czasu RTT;
• Porównaj parametry opcji zaproponowane przez Twój komputer z parametrami zaakceptowanymi przez serwer w pakiecie SYN-ACK.

Wnioski inżynierskie: Zaobserwowana negocjacja opcji dowodzi, że początkowy 3-Way Handshake służy nie tylko synchronizacji numerów sekwencyjnych ISN, ale także uzgodnieniu wspólnego zbioru zaawansowanych algorytmów wydajnościowych zdefiniowanych w RFC 7323 i RFC 2018. Bez poprawnej obsługi Window Scale współczesne łącza szerokopasmowe o wysokim iloczynie BDP (Bandwidth-Delay Product) nie byłyby w stanie osiągnąć pełnej przepustowości.

W celu empirycznego zbadania funkcjonowania mechanizmów routingu i licznika TTL student powinien zrealizować w terminalu poniższe zadanie badawcze:

Część 1: Badanie trasy lokalnej w podsieci LAN
Wydaj polecenie badania trasy do bramy domyślnej lub sąsiedniego komputera w pracowni:
traceroute -n <IP_bramy_domyślnej> (w Windows: tracert -d <IP_bramy>).
Obserwacja: Trasa zamyka się w jednym przeskoku (1 hop) z czasem RTT poniżej 1 ms, ponieważ pakiet nie przechodzi przez żaden router pośredniczący.

Część 2: Badanie trasy międzykontynentalnej
Wydaj polecenie badania trasy do odległego serwera zagranicznego (np. serwera w USA lub Australii):
mtr --report -c 10 1.1.1.1 (lub traceroute -n 8.8.8.8).
Zadania analityczne:
1. Policz całkowitą liczbę routerów pośredniczących (przeskoków) na ścieżce;
2. Zidentyfikuj węzeł, w którym następuje gwałtowny skok opóźnienia RTT (np. z 15 ms do 110 ms) – skok ten wskazuje na przekroczenie światłowodowego kabla podmorskiego (transatlantyckiego);
3. Zwróć uwagę na węzły oznaczone gwiazdkami * * * – wyjaśnij, dlaczego niektóre routery w internecie celowo nie odsyłają pakietów ICMP Time Exceeded (blokada ze względów bezpieczeństwa i odciążenia procesora Control Plane).

Interpretacja zjawiska pętli trasowania: Zrozumienie roli TTL nabiera fundamentalnego znaczenia w sytuacjach awaryjnych, gdy w wyniku błędnej rekonfiguracji protokołów routingu dynamicznego (np. OSPF czy BGP) powstaje pętla trasowania (Routing Loop). Gdyby pole TTL (w IPv6 Hop Limit) nie było dekrementowane przez każdy węzeł L3, zapętlone pakiety krążyłyby w sieci w nieskończoność, doprowadzając do natychmiastowego nasycenia buforów interfejsów i załamania przepustowości całego segmentu transmisyjnego.

W ramach ćwiczenia końcowego student ma za zadanie przypisać poniższe protokoły do czterech warstw modelu TCP/IP (RFC 1122):

Protokoły do przyporządkowania:
1. HTTP | 2. TCP | 3. IPv4 | 4. ARP | 5. UDP
6. ICMP | 7. DNS | 8. DHCP | 9. Ethernet | 10. BGP

Prawidłowe rozwiązanie akademickie wraz z uzasadnieniem:
• Warstwa 1: Dostępu do sieci (Network Access / Link):
- Ethernet (IEEE 802.3) – formatuje ramki i definiuje warstwę fizyczną;
- ARP (RFC 826) – protokół pomocniczy mapujący IP na adresy fizyczne MAC w obrębie łącza;
• Warstwa 2: Internetowa (Internet):
- IPv4 (RFC 791) – główny protokół adresowania i trasowania pakietów;
- ICMP (RFC 792) – protokół kontrolno-diagnostyczny warstwy internetowej;
• Warstwa 3: Transportowa (Transport):
- TCP (RFC 9293) – połączeniowy, niezawodny protokół strumieniowy;
- UDP (RFC 768) – bezpołączeniowy, lekki protokół datagramowy;
• Warstwa 4: Aplikacji (Application):
- HTTP – protokół przesyłania zasobów sieci Web (port TCP 80);
- DNS – hierarchiczny system rozwiązywania nazw domenowych (port UDP/TCP 53);
- DHCP – protokół dynamicznej konfiguracji parametrów hosta (porty UDP 67/68);
- BGP-4 – protokół routingu zewnątrzsystemowego operujący jako aplikacja na porcie TCP 179.

Komentarz akademicki do klasyfikacji protokołów brzegowych: Szczególną uwagę należy zwrócić na protokoły hybrydowe, takie jak ARP, ICMP oraz BGP. ARP operuje na granicy L2/L3 (przenosi adresy L3, lecz jest enkapsulowany bezpośrednio w ramkach Ethernet z własnym kodem EtherType 0x0806). ICMP jest formalnie częścią warstwy internetowej, mimo że jego pakiety są enkapsulowane wewnątrz nagłówka IPv4 (protokół 1). Z kolei BGP-4, choć realizuje kluczowe zadanie routingu internetowego w warstwie sieciowej, z punktu widzenia architektury stosu jest w pełni aplikacją bazującą na niezawodnej sesji TCP port 179.

Moduł poświęcony stosowi protokołów TCP/IP stanowił całościowe studium technologii, która ukształtowała współczesną cywilizację techniczną. Najważniejsze fakty inżynierskie, które należy zapamiętać, to:

1) Struktura czterech warstw: Model internetowy według RFC 1122 łączy warstwy fizyczną i łącza w warstwę dostępu do sieci, a warstwy sesji, prezentacji i aplikacji w jednolitą warstwę aplikacji, zachowując autonomię warstwy internetowej i transportowej;

2) Prostota protokołu IP: Protokół IP realizuje routing bezpołączeniowy Best-Effort w oparciu o tablicę tras i regułę Longest Prefix Match, dekrementując licznik TTL w celu eliminacji pętli;

3) Podwójna natura warstwy transportowej: Wybór pomiędzy protokołem TCP (niezawodność, potwierdzenia, kontrola okna przesuwnego, kontrola zatorów) a protokołem UDP (minimalny nagłówek 8 B, brak opóźnień, idealny dla VoIP i DNS) wynika ściśle z charakterystyki aplikacji;

4) Fundamenty usługowe: Współczesna sieć nie może funkcjonować bez usług warstwy aplikacji: DNS mapuje nazwy na adresy, DHCP automatyzuje konfigurację węzłów, a mechanizm translacji NAT/PAT pozwala na współdzielenie adresów publicznych.

5) Ewolucja ku nowoczesnym protokołom transportowym: Zrozumienie klasycznego stosu TCP/IP jest niezbędnym wstępem do zaawansowanych mechanizmów teleinformatycznych, w tym protokołu QUIC (RFC 9000), który przenosi mechanizmy niezawodnego transportu do przestrzeni użytkownika ponad UDP, eliminując opóźnienia wieloetapowego uzgadniania połączeń i problem blokowania początku kolejki (Head-of-Line Blocking). Wiedza ta umożliwia inżynierowi projektowanie i optymalizację wysoce skalowalnych systemów chmurowych i brzegowych.

Poniższa tabela stanowi zintegrowane kompendium wiedzy dla inżynierów i administratorów sieciowych:

Zastosowanie operacyjne tabeli protokołów: Niniejsza tabela stanowi klucz referencyjny podczas konfiguracji reguł zapór sieciowych (np. iptables, nftables, pf, Cisco ACL) oraz analizy bezpieczeństwa sieci. Skuteczna filtracja pakietów wymaga precyzyjnego zestawienia numeru protokołu w nagłówku IP (np. 6 dla TCP, 17 dla UDP, 1 dla ICMP) oraz portów źródłowych i docelowych. Rozumienie relacji pomiędzy protokołami warstwy aplikacji a mechanizmami warstw niższych pozwala administratorom na szybkie wykrywanie anomalii ruchowych, takich jak nieautoryzowane tunele DNS/ICMP, skanowanie portów czy ataki typu SYN Flood.

W ramach samodzielnej weryfikacji opanowania materiału student powinien przeanalizować i odpowiedzieć na poniższe trzy fundamentalne problemy inżynierskie, łączące wiedzę z zakresu adresacji, mechaniki protokołów transportowych oraz translacji sieciowych:

Pytanie 1: Dlaczego serwer internetowy potrzebuje zarówno adresu IP, jak i numeru portu logicznego, aby odebrać dane od klienta?
Wskazówka analityczna: Rozważ relację pomiędzy warstwą internetową (Host-to-Host) a warstwą transportową (Process-to-Process) oraz koncepcję gniazda logicznego (Socket) w systemie operacyjnym serwera obsługującego wiele równoległych usług.

Pytanie 2: Co oznacza flaga RST w nagłówku TCP i w jakich konkretnych sytuacjach jest wysyłana przez stos sieciowy jądra?
Wskazówka analityczna: Porównaj eleganckie zamykanie sesji (FIN) z awaryjnym resetowaniem (RST); zwróć uwagę na zachowanie systemu w przypadku próby połączenia z nieaktywnym portem oraz po restarcie serwera.

Pytanie 3: Na czym polega fundamentalna różnica pomiędzy translacją Source NAT (SNAT) a Destination NAT (DNAT / Port Forwarding)?
Wskazówka analityczna: Zastanów się nad kierunkiem inicjalizacji połączenia (ruch wychodzący stacji z sieci LAN vs ruch przychodzący z internetu do serwera w strefie prywatnej) oraz nad tym, które pole nagłówka IP/TCP ulega podmianie w tabeli translacji routera.

Prawidłowe, wyczerpujące odpowiedzi akademickie wraz ze szczegółowym uzasadnieniem technicznym znajdują się na kolejnym slajdzie.

Szczegółowe omówienie akademickie poprawnych odpowiedzi:

Odpowiedź na Pytanie 1 (IP vs Port):
Adres IP jest adresem warstwy internetowej identyfikującym konkretne urządzenie (interfejs sieciowy hosta) w globalnej sieci – pozwala routerom doprowadzić pakiet pod właściwy adres fizyczny komputera. Numer portu jest identyfikatorem warstwy transportowej przypisanym do konkretnego procesu systemowego w pamięci RAM. Bez adresu IP pakiet nie dotarłby do komputera; bez numeru portu jądro systemu operacyjnego nie wiedziałoby, do którego z setek działających programów (przeglądarki, serwera bazy danych czy demona SSH) przekazać odebrany strumień danych. Dopiero para (IP, Port) tworzy pełny adres gniazda (Socket);

Odpowiedź na Pytanie 2 (Flaga TCP RST):
Flaga RST (Reset) służy do natychmiastowego, awaryjnego zerwania lub odrzucenia połączenia bez przeprowadzania eleganckiej 4-krokowej procedury FIN. System operacyjny wysyła segment z flagą RST w trzech głównych sytuacjach: 1) Gdy stacja odbierze segment SYN lub dane skierowane na port, na którym żadna aplikacja nie nasłuchuje (odpowiedź „Port zamknięty”); 2) Gdy połączenie zostało nagle zerwane przez awarię procesu (Crash); 3) Gdy odebrano segment niepasujący do żadnej aktywnej sesji w pamięci (np. po restarcie serwera);

Odpowiedź na Pytanie 3 (SNAT vs DNAT):
• SNAT (Source NAT): Podmienia źródłowy adres IP pakietu. Stosowany dla stacji z sieci lokalnej wychodzących do internetu – router zastępuje prywatny IP stacji swoim adresem publicznym, umożliwiając wielu komputerom korzystanie z sieci;
• DNAT (Destination NAT / Port Forwarding): Podmienia docelowy adres IP (i ewentualnie port) pakietu. Stosowany w celu udostępnienia serwera z sieci prywatnej (np. wewnętrznego serwera WWW 192.168.1.50:80) dla użytkowników z internetu – router odbiera ruch skierowany na swój publiczny adres IP i przekierowuje go na prywatny adres serwera.

Niniejsza część kursu wyposażyła Państwa w szczegółową wiedzę na temat architektury i funkcjonowania stosu protokołów internetowych TCP/IP zdefiniowanego w normie RFC 1122. Poznali Państwo mechanizmy działania protokołu IP, zasady routingu Best-Effort, anatomię nagłówków IPv4 i IPv6 oraz kluczową rolę protokołu kontrolno-diagnostycznego ICMP.

Szczególną uwagę poświęciliśmy warstwie transportowej: dogłębnie zbadali Państwo 3-drożny uścisk dłoni TCP, maszynę stanów połączeń, sterowanie przepływem za pomocą przesuwnego okna oraz zaawansowane algorytmy kontroli przeciążeń sieciowych (Congestion Control). Poznali Państwo również minimalistyczny protokół UDP oraz fundamenty usług infrastrukturalnych: hierarchię systemu DNS, cykl DORA w protokole DHCP oraz mechanizmy translacji adresów NAT/PAT.

W kolejnej części kursu – Część 6: Protokoły i usługi sieciowe wyższych warstw – dokonamy głębokiej analizy protokołów aplikacyjnych. Zbadamy szczegółowo ewolucję protokołu HTTP (od HTTP/1.1 przez HTTP/2 z multipleksacją binarną po HTTP/3 z protokołem QUIC), protokoły pocztowe (SMTP, IMAP, POP3), protokoły transferu plików (FTP, SFTP, TFTP) oraz protokoły zarządzania i synchronizacji czasu (NTP, PTP, SNMPv3, SSH i Telnet).