TCP, UDP i porty

• Rozróżnisz segment TCP i datagram UDP oraz ich miejsce w enkapsulacji.
• Wyjaśnisz zestawianie, przesyłanie i zamykanie połączenia TCP.
• Zinterpretujesz porty, gniazda i pięcioelementowy identyfikator przepływu.
• Sprawdzisz bezpiecznie lokalne połączenia w Windows i Linux.

Wymagania wstępne

• Modele OSI i TCP/IP
• Adresacja IPv4 lub podstawy IPv6

Aplikacja przekazuje dane do warstwy transportowej. TCP tworzy segmenty, a UDP datagramy; następnie IP przenosi je w pakietach, a technologia łącza opakowuje pakiety w ramki.

TCP jest połączeniowy i zapewnia uporządkowany strumień bajtów, wykrywanie strat, retransmisję i sterowanie przepływem. UDP jest bezpołączeniowy i zachowuje granice datagramów, ale nie gwarantuje dostarczenia, kolejności ani szyfrowania. UDP nie jest z definicji zawsze szybszy.

RFC 768 pozostaje podstawową specyfikacją klasycznego UDP i jego 8-bajtowego nagłówka. RFC 9868 aktualizuje RFC 768, definiując UDP Options umieszczane w surplus area za danymi aplikacji, ale w obrębie datagramu IP, a nie w klasycznym nagłówku UDP. Jest to rozszerzenie, którego obsługi nie należy zakładać bez sprawdzenia systemu i aplikacji.

Typowe zestawienie to SYN, SYN-ACK i ACK. Numery sekwencyjne opisują pozycję bajtów w strumieniu, a ACK potwierdza następny oczekiwany numer. Zamykanie zwykle wymaga osobnych FIN i ACK dla obu kierunków; RST przerywa połączenie.

Okno odbiorcze steruje przepływem, MSS ogranicza ładunek TCP w segmencie, a suma kontrolna wykrywa uszkodzenia. Kontrola przeciążenia, między innymi slow start i congestion avoidance, chroni sieć; nie jest tym samym co sterowanie przepływem odbiorcy.

• Flagi: SYN, ACK, FIN, RST, PSH, URG, ECE i CWR.
• Retransmisja naprawia wykrytą stratę, ale zwiększa opóźnienie.
• Niezawodność TCP nie oznacza poufności, uwierzytelnienia ani szyfrowania; te własności może zapewnić np. TLS.

Gniazdo sieciowe (socket) łączy adres IP, protokół transportowy i port. Przepływ zwykle opisuje pięć wartości: protokół, źródłowy IP i port oraz docelowy IP i port. Klient wybiera zwykle port efemeryczny, a serwer nasłuchuje na znanym lub skonfigurowanym porcie.

Rejestracja IANA opisuje przeznaczenie, a nie gwarantuje zawartości ruchu. NAT z przeciążeniem, często nazywany PAT, może zmienić adres i port źródłowy.

• Wireshark: tcp.flags.syn == 1 && tcp.flags.ack == 0 pokazuje początkowe SYN.
• tcp.analysis.retransmission wskazuje podejrzane retransmisje.
• netcat stosuj wyłącznie do własnych hostów i do prostego testu kontrolowanego portu, np. nc -vz example.com 443.

# Linux
ss -tulpen
curl -I https://example.com

# Windows PowerShell
Get-NetTCPConnection
Test-NetConnection example.com -Port 443

• UDP nie zapewnia automatycznie małego opóźnienia; aplikacja i sieć nadal mogą powodować kolejki lub retransmisje na wyższej warstwie.
• TCP nie szyfruje danych.
• Otwarty port nie dowodzi podatności, ale powiększa powierzchnię wymagającą kontroli.
• Nazwa z rejestru portów nie jest wiarygodną identyfikacją aplikacji bez analizy kontekstu.

1. Uruchom własne połączenie do https://example.com i znajdź lokalny port źródłowy oraz port docelowy 443.
2. W kontrolowanym przechwyceniu wskaż SYN, SYN-ACK i ACK oraz zapisz pięć elementów przepływu.
3. Wyjaśnij, dlaczego DNS może korzystać zarówno z UDP, jak i TCP.

• TCP zapewnia uporządkowany, niezawodny strumień, ale nie szyfrowanie.
• UDP przekazuje datagramy bez gwarancji dostarczenia; niezawodność może realizować aplikacja, np. QUIC.
• Port jest elementem identyfikacji punktu końcowego, a nie dowodem rodzaju aplikacji.

• DNS

• RFC 9293 — Transmission Control Protocol
• RFC 768 — User Datagram Protocol
• RFC 9868 — Transport Options for UDP (updates RFC 768)
• IANA — Service Name and Transport Protocol Port Number Registry
• RFC 9000 — QUIC
• RFC 9114 — HTTP/3