Poprawna odpowiedź w tym pytaniu to UDP, a nie SPX. W modelu TCP/IP tylko dwa główne protokoły działają w warstwie transportowej: TCP (Transmission Control Protocol) oraz UDP (User Datagram Protocol). Z tej dwójki właśnie UDP jest protokołem, który nie gwarantuje dostarczenia danych, nie zapewnia też kontroli kolejności ani ponownych transmisji. Mówi się, że UDP jest protokołem bezpołączeniowym i „best effort” – wysyła datagramy i nie sprawdza, czy dotarły. To jest świadomy wybór projektowy, opisany w dokumentach RFC (np. RFC 768). Dzięki temu UDP ma bardzo mały narzut, jest szybki i idealny tam, gdzie ważniejsza jest szybkość niż pełna niezawodność. W praktyce UDP stosuje się np. w transmisji strumieni audio/wideo (VoIP, streaming), w grach sieciowych czasu rzeczywistego, w DNS (zapytania zwykle lecą po UDP), w protokołach jak DHCP czy TFTP. Jeżeli jeden pakiet z pozycją gracza w grze online zginie, to zaraz przyjdzie następny – nie ma sensu go retransmitować. Z mojego doświadczenia w sieciach warto zapamiętać prostą zasadę: kiedy aplikacja sama ogarnia logikę błędów i może tolerować utratę części danych, często wybiera UDP. Gdy natomiast liczy się stuprocentowa poprawność i kolejność (np. HTTP, SMTP, FTP – choć same nie są „transportowe”), pod spodem zawsze pracuje TCP. Dlatego, patrząc na warstwę transportową w ujęciu TCP/IP, jedyną prawidłową odpowiedzią na to pytanie jest UDP jako protokół niegwarantujący dostarczenia danych.
W tym zadaniu kluczowe jest poprawne skojarzenie warstwy transportowej modelu TCP/IP z konkretnymi protokołami oraz zrozumienie, które z nich gwarantują dostarczenie danych, a które działają w trybie „bez gwarancji”. W modelu TCP/IP warstwa transportowa to przede wszystkim dwa podstawowe protokoły: TCP oraz UDP. TCP jest połączeniowy, zapewnia niezawodność, kontrolę kolejności segmentów, retransmisję i kontrolę przeciążenia. UDP natomiast jest bezpołączeniowy, nie potwierdza odbioru, nie retransmituje utraconych datagramów i właśnie dlatego mówi się, że nie gwarantuje dostarczenia danych. To jest fundament, który przewija się w praktycznie każdym kursie z sieci komputerowych. Częsty błąd polega na mieszaniu protokołów transportowych z aplikacyjnymi. FTP służy do przesyłania plików, ale działa w warstwie aplikacji i korzysta z TCP jako warstwy transportowej. Sam FTP nie jest protokołem transportowym, tylko usługą, która używa niezawodnego kanału TCP. Podobnie DNS to protokół aplikacyjny odpowiedzialny za tłumaczenie nazw domenowych na adresy IP. Co ciekawe, DNS bardzo często korzysta właśnie z UDP jako warstwy transportowej (port 53/UDP), ale sam w sobie nadal nie jest protokołem transportowym. To rozróżnienie: warstwa aplikacji vs warstwa transportowa, bywa w technikach trochę mylone, zwłaszcza gdy patrzy się tylko na numery portów. SPX z kolei historycznie był protokołem transportowym, ale w stosie IPX/SPX firmy Novell, a nie w modelu TCP/IP. W dodatku SPX zapewniał połączeniową, niezawodną komunikację, bardziej podobną w zachowaniu do TCP niż do UDP. Dlatego wybór SPX jako odpowiedzi jest podwójnie mylący: ani nie należy do stosu TCP/IP, ani nie jest protokołem „bez gwarancji dostarczenia”. Moim zdaniem warto sobie poukładać w głowie, że w klasycznym TCP/IP, gdy pada pytanie o brak gwarancji dostarczenia w warstwie transportowej, właściwie zawsze chodzi o UDP. Reszta wymienionych nazw to albo protokoły aplikacyjne, albo elementy zupełnie innego stosu sieciowego.