Kontrolę poprawności przesyłania danych w sieciach Ethernet zapewnia protokół
A. HTTP
B. UDP
C. TCP
D. IP
Pytanie z egzaminu CKE, wrzesień 2015 (arkusz E.13-X-15.08).
TCP jest tu najlepszym wyborem, bo odpowiada za kontrolę poprawności transmisji na poziomie transportowym. W praktyce oznacza to, że protokół TCP numeruje segmenty, sprawdza sumę kontrolną, oczekuje potwierdzeń ACK i w razie potrzeby ponawia wysyłanie danych. Dzięki temu aplikacja ma dużo większą pewność, że dane dotarły w odpowiedniej kolejności i bez braków. To jest właśnie ta cecha, której nie daje samo IP ani UDP. Warto tylko doprecyzować, że w samym Ethernecie, zgodnie z IEEE 802.3, ramki mają też pole FCS oparte o CRC, które wykrywa uszkodzenie ramki na łączu. Ale FCS nie zapewnia ponownego przesłania danych end-to-end. TCP, opisany obecnie m.in. w RFC 9293, robi to na wyższym poziomie stosu sieciowego. Moim zdaniem to ważne rozróżnienie, bo w diagnostyce sieci łatwo pomylić wykrywanie błędów w ramce z niezawodnym dostarczeniem danych. Przykładowo pobieranie pliku, logowanie SSH albo otwieranie strony HTTPS korzysta z mechanizmów TCP, aby nie zgubić fragmentów transmisji po drodze.
W tym pytaniu łatwo wpaść w pułapkę, bo wszystkie podane nazwy są związane z sieciami, ale działają na różnych warstwach i mają inne zadania. IP odpowiada głównie za adresowanie i trasowanie pakietów między sieciami. Mówiąc prosto, IP pomaga zdecydować, dokąd pakiet ma iść, ale nie daje gwarancji, że pakiet dojdzie, że dojdzie tylko raz ani że dotrze w poprawnej kolejności. To częsty błąd myślowy: skoro IP jest podstawą komunikacji w Internecie, to musi kontrolować wszystko. No właśnie nie do końca. UDP jest jeszcze prostszy, bo wysyła datagramy bez zestawiania połączenia, bez potwierdzeń i bez retransmisji. Ma sumę kontrolną, więc potrafi wykrywać pewne uszkodzenia danych, ale nie realizuje pełnej kontroli poprawności przesyłania rozumianej jako niezawodna transmisja. Dlatego używa się go tam, gdzie ważne jest małe opóźnienie, np. VoIP, gry online, transmisje strumieniowe. HTTP natomiast jest protokołem warstwy aplikacji. Służy do przesyłania treści stron i komunikacji klient-serwer, ale sam nie kontroluje poprawności transportu danych; tradycyjnie opiera się na TCP, a w nowszym HTTP/3 na QUIC działającym nad UDP. W sieciach Ethernet trzeba też pamiętać o IEEE 802.3 i mechanizmie FCS/CRC w ramce. On wykrywa błąd na łączu lokalnym, ale nie zastępuje TCP. Z mojego doświadczenia najlepiej patrzeć na to warstwowo: Ethernet sprawdza ramkę lokalnie, IP adresuje i routuje, TCP pilnuje niezawodnego transportu, a HTTP obsługuje usługę aplikacyjną.