Aby router wiedział do kogo ma przekazać pakiet danych, używa informacji dostarczonych przez protokół IP (Internet Protocol), któe sa zawarte w nagłówku datagramu. Protokół IP nie zapewnia dostarczenia pakietu do adresata, dlatego określa się go mianem zawodnego, bezpołączeniowego protokołu dostarczającego dane z dołożeniem wszelkich starań. Jeżeli pakiety zostana odrzucowne w trakcie przesyłania, lub zostana przesłane szybciej niż odbiorca może je odebrać, to protokół IP sam nie poradzi sobie z tym problemem. Aby poradzić sobie z takimi sytuacjami, protokół IP korzysta z protokołu TCP (Transmission Control Protocol).
Każda warstwa modelu odniesienia OSI ma różne funkcje do wykonania. Te funkcje są niezależne od innych warstw. Każda warstwa zapewnia również określone usługi warstwie znajdującej się powyżej niej. Warstwa aplikacji, prezentacji i sesji, które uznaje się za część warstwy aplikacji w modelu TCP/IP, korzystają z usług warstwy transportowej poprzez jednostki logiczne zwane portami.
Adresy IP pozwalają na przekazywanie pakietów między hostami i sieciami. Jednak sam protokół IP nie gwarantuje ich dostarczenia. Warstwa transpotru jest odpowiedzialna za dostarczenie i prawidłowy przepływ datagramów między hostem wysyłającym i odbierającym. Służą do tego okna przesuwne i liczby sekwencyjne oraz proces synchronizacji. Dzięki niemu każdy host jest gotowy do komunikacji. Warstwa transportowa, będąca czwartą warstwą modelu OSI, korzysta z protokołu TCP w celu dostarczenia tych usług warstwie piątej.
TCP jest protokołem zorientowanym połączeniowo. Zanim rozpocznie się transmisja danych, dwa komunikujące się hosty przechodzą przez proces synchronizacji wirtualnego połączenia. Synchronizacja zapewnia, że obydwie strony są gotowe do transmisji danych i pozwala urządzeniom ustalić początkowe numery sekwencyjne. Proces ten jest znany jako "trzykrotny uścisk dłoni" (ang. three way handshake). Jest to trzy etapowy proces ustanawiania wirtualnego połączenia między nadawcą i odbiorcą.
W pierwszym kroku host inicjujący (klient) wysyła segment synchronizacji (z ustawioną flagą SYN). Segment ten zawiera początkowy numer sekwencyjny dla tej sesji (ozn. x). Ustawienie bitu SYN w polu "kod" nagłówka TCP oznacza żądanie nawiązania połączenia. Numer sekwencyjny jest wartością 32-bitową.
W pierwszym kroku host inicjujący (klient) wysyła segment synchronizacji (z ustawioną flagą SYN). Segment ten zawiera początkowy numer sekwencyjny dla tej sesji (ozn. x). Ustawienie bitu SYN w polu "kod" nagłówka TCP oznacza żądanie nawiązania połączenia. Numer sekwencyjny jest wartością 32-bitową.
|
|
W trzecim kroku host inicjujący nawiązanie połączenia odpowiada prostym potwierdzeniem z wartością y+1, która jest równa numerowi sekwencyjnemu hosta B powiększonemu o 1. Oznacza to, że klient otrzymał potwierdzenie wysłane przez serwer i kończy proces nawiązywania połączenia.
Ważne! Początkowe numery sekwencyjne są używane do inicjalizacji komunikacji pomiędzy dwoma urządzeniami. Pełnią one rolę punktów odniesienia. Numery sekwencyjne pozwalają na precyzyjne informowanie nadawcy o odebraniu konkretnego segmentu danych lub żądania nawiązania połączenia.
Ataki DoS mają na celu zablokowanie usług świadczonych uprawnionym do korzystania z nich hostom, które próbują nawiązać połączenie. Ataki DoS służą zazwyczaj hackerom do zablokowania systemu tak, aby przestał reagować na żądania. Jednym z rodzajów ataków DoS jest zalewanie żądaniami synchronizacji (ang. SYN flooding). Zalewanie żądaniami synchronizacji (SYN flooding) wykorzystuje normalny mechanizm nawiązywania połączenia i powoduje, że cel ataku odpowiada do adresów źródłowych, które nie dokończą procesu nawiązywania połączenia.
Uzgadnianie trójetapowe zaczyna się w momencie, gdy inicjujący host wysyła pakiet SYN, który zawiera źródłowy i docelowy adres IP. Informacja o adresie źródłowym i docelowym jest wykorzystywana przez odbiorcę w celu wysłania segmentu potwierdzającego do urządzenia inicjującego.
|
W ataku DoS hacker inicjuje synchronizację, wysyłając pakiet z fałszywym adresem źródłowym. Spoofing to termin określający fałszowanie, na przykład adresu IP, by ukryć swoją lokalizację i tożsamość. W tym przypadku, ponieważ adres źródłowy pakietu został podmieniony, na przykład na nieistniejący lub nieosiągalny, żądanie oczekiwania jest umieszczane w kolejce połączeń lub w obszarze przechowywania w pamięci. Taki stan oczekiwania powoduje, że zaatakowane urządzenie zużywa zasoby systemowe, na przykład pamięć, do momentu przekroczenia określonego limitu czasu. Hackerzy zalewają zaatakowany host fałszywymi żądaniami synchronizacji, aż host zużyje wszystkie zasoby połączeniowe i przestanie reagować na uprawnione żądania połączenia.
Aby bronić się przed takimi atakami, administratorzy mogą skrócić limit czasu oczekiwania na połączenie i zwiększyć długość kolejki połączeń. Istnieje również oprogramowanie, które wykrywa tego typu ataki i przeciwdziała im.
Ilość danych, jakie mają zostać przesłane, często przekracza rozmiar pojedynczego segmentu. W takiej sytuacji konieczne jest podzielenie ich na mniejsze kawałki, aby umożliwić prawidłową transmisję. Protokół TCP jest odpowiedzialny za dzielenie danych na segmenty. Ponadto urządzenie może nie być w stanie odebrać danych tak szybko, jak nadawca je wysyła. Może ono być zajęte innymi czynnościami lub też urządzenie nadawcy może mieć większą wydajność.
Po przeprowadzeniu segmentacji danych konieczne jest ich przesłanie do urządzenia docelowego. Jedną z możliwości protokołu TCP jest kontrola przepływu, która służy do regulowania ilości informacji wysyłanych w danym okresie transmisji. Kontrola przepływu jest także znana jako okienkowanie.
Rozmiar okna określa ilość danych, jaka może być wysłana przed otrzymaniem potwierdzenia ze strony odbiorcy. Po wysłaniu ilości bajtów określonej przez rozmiar okna, host musi otrzymać potwierdzenie, że dane zostały otrzymane, zanim wyśle następne dane. Na przykład, jeśli rozmiar okna wynosi 1, każdy bajt musi być potwierdzony zanim następny bajt zostanie wysłany.
TCP stosuje technikę okna o zmiennym rozmiarze. Urządzenia negocjują rozmiar okna określając ilość bajtów, które można wysłać przed otrzymaniem potwierdzenia. Proces dynamicznej zmiany rozmiaru okna zwiększa niezawodność. Rozmiar okna może być zmieniany na podstawie otrzymywanych potwierdzeń.
Protokół TCP dzieli dane na segmenty. Po zakończeniu procedury synchronizacji i określeniu rozmiaru okna segmenty z danymi są przesyłane od nadawcy do odbiorcy. Po odebraniu wszystkich danych konieczne jest ponowne złożenie segmentów. Nie ma gwarancji, że dane dotrą do odbiorcy w kolejności, w jakiej zostały wysłane. W protokole TCP segmentom danych nadawane są numery sekwencyjne, przez co odbiorca może ponownie poskładać bajty w pierwotnej kolejności. Dzięki temu, nawet jeśli segmenty TCP dotrą w nieprawidłowej kolejności, zostaną prawidłowo złożone.
Numery sekwencyjne stanowią także odniesienie, dzięki któremu odbiorca wie, że odebrał wszystkie dane. Umożliwiają także określenie, których fragmentów brakuje, aby nadawca mógł je ponownie wysłać. Zwiększa to wydajność, ponieważ nadawca musi wysłać tylko brakujące segmenty, a nie całość danych.
Przed wysłaniem każdy segment TCP jest numerowany. W formacie segmentu numer sekwencyjny znajduje się po porcie docelowym. Po stronie stacji odbierającej protokół TCP za pomocą numerów sekwencyjnych ponownie składa kompletną wiadomość. Jeśli numer sekwencyjny w szeregu został opuszczony, segment ten jest transmitowany ponownie.
Potwierdzanie jest typowym etapem procesu synchronizacji, który szereguje dane i korzysta z techniki okien przesuwnych. W segmencie TCP po polu z numerem sekwencyjnym znajduje się pole numeru potwierdzenia, które nosi również nazwę pola kodu. To pole zawiera m.in. informację, czy pakiet niesie ze sobą informację o nadawanych i odbieranych bajtach.
Jednym z problemów związanych z protokołem IP jest brak metody weryfikacji, czy segmenty danych dotarły do celu. Dlatego segmenty mogą być przesyłane cały czas bez otrzymania informacji, czy zostały odebrane. W protokole TCP do sterowania przepływem danych i potwierdzania ich dostarczenia stosuje się potwierdzenie pozytywne i retransmisję (PAR, ang. positive acknowledgement and retransmission).
Technika PAR jest używana w wielu protokołach w celu zapewnienia niezawodności. Gdy nadawca korzystający z tej techniki wysyła pakiet, jednocześnie uruchamia licznik czasu i przed wysłaniem następnego pakietu czeka na potwierdzenie. Jeśli limit czasu upłynie przed odebraniem potwierdzenia przez nadawcę, wysyła on pakiet ponownie i zeruje licznik. Potwierdzenie opiera się na wartości numeru potwierdzenia i ustawieniu flagi ACK w nagłówku TCP. W protokole TCP stosowane jest potwierdzenie wyprzedzające, w którym numer potwierdzenia wskazuje następny oktet spodziewany w ramach sesji TCP.
Okienkowanie jest mechanizmem kontroli przepływu, który wymaga, aby urządzenie źródłowe otrzymywało od adresata potwierdzenie po wysłaniu określonej ilości danych. Przy rozmiarze okna równym 3 urządzenie źródłowe może wysłać do adresata trzy oktety. Następnie musi oczekiwać na potwierdzenie odebrania tych bajtów. Gdy adresat otrzyma trzy oktety, wysyła potwierdzenie do urządzenia źródłowego, które może wtedy wysłać kolejne trzy oktety. Jeśli adresat nie otrzyma tych trzech oktetów, nie wyśle potwierdzenia. Może to być spowodowane przepełnieniem buforów lub utratą pakietów podczas transmisji. Gdy nadawca nie otrzyma potwierdzenia, oznacza to, że oktety powinny być wysłane ponownie, a rozmiar okna zmniejszony. Dzięki zmniejszeniu rozmiaru okna adresat musi przetworzyć mniej bajtów zapisanych w buforach przed nadejściem kolejnych danych. Zatem zapewnienie większej niezawodności komunikacji między hostami powoduje jej spowolnienie.
Stos TCP/IP zawiera wiele różnych protokołów, z których każdy jest przeznaczony do realizacji określonych zadań. Protokół IP zapewnia bezpołączeniowy transport przez intersieć na poziomie warstwy 3. TCP zapewnia zorientowaną połączeniowo, niezawodną transmisję pakietów w warstwie 4 modelu OSI. UDP zapewnia bezpołączeniową, niegwarantowaną transmisję pakietów w warstwie 4 modelu OSI.
Zarówno TCP, jak i UDP korzystają z protokołu IP jako protokołu warstwy 3. Ponadto protokoły TCP i UDP są używane przez różne protokoły warstwy aplikacji. TCP dostarcza usługi dla m.in. FTP, HTTP, SMTP i DNS. UDP jest protokołem warstwy transportowej używanym przez m.in. DNS, TFTP, SNMP i DHCP.
Jeśli aplikacja musi zagwarantować, że pakiet dotrze nienaruszony, we właściwej kolejności i niepowielony, będzie korzystać z protokołu TCP. Czasami problemem związanym z protokołem TCP jest narzut konieczny do zapewnienia, że pakiet będzie dostarczony. Ponieważ nie wszystkie aplikacje muszą gwarantować dostawę pakietu danych, mogą używać szybszego, bezpołączeniowego mechanizmu dostarczania, jaki zapewnia protokół UDP. Standard protokołu UDP jest opisany w dokumencie RFC 768.
Protokół UDP nie korzysta z okien ani potwierdzeń, dlatego błędy muszą być wykrywane przez protokoły warstwy aplikacji. Pole Port źródłowy jest opcjonalne i używane tylko wtedy, gdy informacja musi wrócić do hosta nadawcy. Na przykład, gdy router docelowy odbierze aktualizację routingu, router źródłowy nie żąda żadnych danych, zatem nic nie trzeba wysyłać z powrotem do nadawcy. Pole Port docelowy określa aplikację, której protokół UDP musi przekazać dane. Żądanie DNS z hosta do serwera DNS ma w polu Port docelowy wartość 53, która jest numerem portu UDP dla usługi DNS. Pole Długość określa liczbę oktetów w segmencie UDP. Suma kontrolna UDP jest opcjonalna, ale należy jej użyć dla upewnienia się, że podczas transmisji dane nie uległy uszkodzeniu. W celu przesłania przez sieć pakiety UDP są poddawane enkapsulacji w pakietach IP.
Po dotarciu segmentu UDP do docelowego adresu IP musi istnieć mechanizm, który umożliwia odbierającemu informacje hostowi określenie konkretnej aplikacji docelowej. Służą do tego porty docelowe. Jeśli na hoście działają jednocześnie np. usługi TFTP i DNS, musi on być w stanie określić, której usługi żądają nadchodzące segmenty UDP. Pole Port docelowy w nagłówku UDP określa aplikację, do której segment zostanie dostarczony.
We współczesnych sieciach w każdym momencie przesyłane są tysiące pakietów dostarczających setki różnych usług. Wiele serwerów udostępnia ogromną liczbę usług, co powoduje powstanie problemów z adresowaniem pakietów. Jeśli na serwerze działają usługi SMTP i HTTP, to za pomocą pola Port docelowy określa on, której usługi żąda nadawca. Nadawca nie może utworzyć pakietu przeznaczonego po prostu dla serwera o danym adresie IP, ponieważ odbiorca nie wiedziałby, jakiej usługi zażądano. Numer portu musi być powiązany z konwersacją pomiędzy hostami, aby zapewnić dotarcie pakietu do odpowiedniej usługi na serwerze. Jeśli serwer nie miałby możliwości rozróżnienia konwersacji, klient nie mógłby jednocześnie wysyłać wiadomości e-mail i przeglądać strony WWW. Konieczne jest użycie metody separowania konwersacji w warstwie transportowej.
Hosty udostępniające usługi TCP/IP przypisują porty warstwy transportowej do określonych aplikacji. Numery portów służą do rozróżniania rozmaitych konwersacji odbywających się w tym samym czasie w sieci. Host potrzebuje numerów portów, aby komunikować się z serwerem udostępniającym różne usługi. W protokołach TCP i UDP numery portów (gniazd) są wykorzystywane do przekazywania informacji do wyższych warstw.
Projektanci aplikacji uzgodnili korzystanie z dobrze znanych numerów portów zdefiniowanych w dokumencie RFC1700. Na przykład, każda konwersacja związana z aplikacją FTP korzysta ze standardowego portu o numerze 21. Konwersacje, które nie dotyczą aplikacji wykorzystujących dobrze znane numery portów, mają przypisane numery wybrane losowo z określonego zakresu. Numery portów służą jako adresy nadawcy i odbiorcy w segmencie TCP.
Numery portów mają przydzielone następujące zakresy:
Dobrą analogią opisującą numery portów jest porównanie do skrytek pocztowych. Przesyłkę można wysłać, podając kod pocztowy, miasto i numer skrytki pocztowej. Kod pocztowy i miasto kierują przesyłkę do właściwego urzędu pocztowego, natomiast numer skrytki zapewnia dostarczenie jej do adresata. Podobnie adres IP powoduje dostarczenie pakietu do właściwego serwera, natomiast porty TCP lub UDP gwarantują przekazanie do odpowiedniej aplikacji.
Aby możliwa była komunikacja z usługami działającymi na hostach, każda z nich musi mieć przypisany numer portu. Zdalny host, próbując połączyć się z usługą, oczekuje, że będzie ona korzystała z określonych protokołów i portów warstwy transportowej. Niektóre porty, zdefiniowane w dokumencie RFC 1700, są określane mianem dobrze znanych portów. Są one zarezerwowane zarówno w protokole TCP, jak i UDP.
Dobrze znane porty określają aplikacje działające ponad protokołami warstwy transportowej. Na przykład serwer z usługą FTP korzysta z portów 20 i 21 w celu nawiązywania połączeń TCP od klientów do aplikacji FTP. Dzięki nim może on określić, jakiej usługi żąda klient. Protokoły TCP i UDP określają za pomocą numerów portów usługę, do której są przesyłane żądania.
Za każdym razem, gdy klient łączy się z usługą na serwerze, musi podać port źródłowy lub docelowy. Segmenty TCP i UDP zawierają pola, w których określa się te parametry. Porty docelowe, czyli porty przeznaczone dla usług, definiuje się w oparciu o dobrze znane porty. Porty źródłowe ustawiane przez klientów są określane dynamicznie.
Ogólnie rzecz biorąc, klient określa port źródłowy, wybierając losowo liczbę większą od 1023. Na przykład klient, który próbuje skomunikować się z serwerem WWW, użyje protokołu TCP i przypisze port docelowy 80 i port źródłowy 1045. Kiedy pakiet dotrze do serwera, przechodzi przez warstwę transportową aż do usługi HTTP, która działa na porcie 80. Serwer odpowie na żądanie klienta segmentem, w którym jako port źródłowy podana będzie wartość 80, a jako port docelowy 1045. Klienci i serwery używają portów do rozróżnienia, do których procesów jest przypisany dany segment.
Numer portu jest określany przez 2 bajty w nagłówku segmentu TCP lub UDP. Ta 16-bitowa wartość umożliwia podanie numerów portów z zakresu od 0 do 65535. Trzy kategorie numerów portów to: dobrze znane porty, porty zarejestrowane i porty dynamiczne lub prywatne. Pierwsze 1023 porty to dobrze znane porty. Są one wykorzystywane przez popularne usługi sieciowe, na przykład FTP, Telnet lub DNS. Porty zarejestrowane zawierają się w zakresie od 1024 do 49151. Porty o numerach od 49152 do 65535 są zdefiniowane jako dynamiczne lub prywatne.
Numery portów służą do śledzenia wielu sesji nawiązywanych pomiędzy hostami. Port źródłowy lub docelowy wraz z adresem sieciowym tworzą gniazdo. Para gniazd, po jednym dla każdego hosta, tworzy unikatowe połączenie. Na przykład host może utrzymywać połączenie Telnet przez port 23 i połączenie internetowe przez port 80. Adresy IP i MAC będą takie same, ponieważ pakiety pochodzą z tego samego hosta. Dlatego każda konwersacja po stronie źródła wymaga odrębnego numeru portu, podobnie jak każda żądana usługa.
Numery portów znajdują się w warstwie transportowej i są obsługiwane przez warstwę sieci. Warstwa sieci przypisuje adresy logiczne, czyli adresy IP, a następnie jest obsługiwana przez warstwę łącza danych, która przypisuje adres fizyczny, czyli adres MAC.
Dobrą analogią jest porównanie do zwykłego listu. W przypadku listu adres składa się z nazwiska, ulicy i numeru oraz miasta i kraju. Można je porównać do numeru portu, adresu MAC i adresu IP używanych przy przesyłaniu danych sieciowych. Nazwisko na kopercie jest analogiczne do numeru portu, ulica i numer - do adresu MAC, a miasto i kraj - do adresu IP. Można wysłać wiele listów pod ten sam adres (numer domu, ulicę, miasto i kraj), podając inne nazwiska. Na przykład można wysłać dwa listy pod ten sam adres; adresatem jednego z nich może być "Jan Kowalski", a drugiego - "Anna Kowalska". Jest to analogiczne do wielu sesji z różnymi numerami portów.