Infrastruktura Sieciowa

Protokół TCP

Protokół TCP/IP to zestaw standardowych protokołów używanych do ustanawiania połączeń między komputerami w sieciach. TCP jest protokołem działającym w trybie klient-serwer. Serwer oczekuje na nawiązanie połączenia na określonym porcie. Klient inicjuje połączenie do serwera. TCP ma zapewnić pewny kanał transmisji, w którym dotarcie danych do celu jest potwierdzane przez odbiorcę. W razie potrzeby dane są retransmitowane. Innymi słowy aplikacja, która używa TCP do przesłania danych do odbiorcy może się już nie martwic, czy poszczególne pakiety IP dotarły do odbiorcy. O kontrole tego zadba TCP i tylko zbiorczo, na koniec, poinformuje aplikacje, czy transmisja zakończyła się sukcesem.

Reasumując protokół TCP charakteryzuje się następującymi cechami:

* jest zorientowany na połączenie: oznacza to, że program użytkowy, który chce skorzystać z protokółu TCP musi najpierw zwrócić się do odbiorcy z prośbą o uzyskanie połączenia i uzyskać jego zgodę;

* jest protokółem typu punkt-punkt: oznacza to, że każde połączenie TCP ma dokładnie dwa końce;

* zapewnia niezawodność: oznacza to, że protokół TCP zapewnia pełna niezawodność w dostarczaniu pakietów;

* zapewnia dwukierunkową komunikację: oznacza to, że komunikacja w połączeniu TCP odbywa się w dwu kierunkach, czyli zarówno od nadawcy do odbiorcy jak i od odbiorcy do nadawcy;

* zapewnia strumieniowy interfejs: oznacza to, że program może wysyłać połączeniem całą sekwencję bajtów, w konsekwencji prowadzi to do tego, że dane nie musza być dostarczane do odbiorcy w kawałkach tych samych wielkości, w których zostały wysłane;

* zapewnia łagodne kończenie połączenia: oznacza to, ze protokół gwarantuje niezawodne dostarczenie pakietów przed zamknięciem połączenia.

Retransmisja

Jednym z mechanizmów zapewniających niezawodność transportu danych jest retransmisja. Polega on na tym, ze odbiorca po odebraniu danych zobowiązany jest do przesłania do nadawcy potwierdzenia odebrania danych. Jeżeli potwierdzenie nie nadejdzie w określonym czasie, to nadawca wysyła dane ponownie.

Komunikacja

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ą.

Schemat:

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.

Zakończenie i zamknięcie połączenia wygląda następująco:

Flagi TCP

A, ACK- (Potwierdzenie) Odbiorca wysyła flagę ACK, która jest równa numerowi sekwencji nadawcy plus parametr Len lub liczba danych w warstwie TCP.

Flagi SYN i FIN są liczone jako 1 bajt. Flaga ACK może również oznaczać numer sekwencji następnego oktetu oczekiwanego przez odbiorcę.

S, SYN- Synchronizowanie jest używane w czasie konfigurowania sesji do uzgodnienia początkowych numerów sekwencji. Numery sekwencji są losowe.

F, FIN- Zakończenie jest używane podczas bezpiecznego zamknięcia sesji i oznacza, że nadawca nie ma już danych do wysłania.

R, RST- Zresetowanie to natychmiastowe przerwanie w dwóch kierunkach (nieprawidłowe rozłączenie sesji).

P, PSH- Pchnięcie wymusza dostarczenie bez oczekiwania na wypełnienie się buforów. Dane zostaną dostarczone również do aplikacji w miejscu docelowym bez buforowania.

U, URG- Pilne - Dane są wysyłane poza pasmem.

Protokół UDP

Protokół UDP jest pozbawiony wszystkich funkcji TCP. Oferuje usługę w której mogą wystąpić straty pakietów.

Protokół UDP jest bezpołączeniowy. Nie wymaga istnienia żadnego połączenia. Klient UDP może utworzyć gniazdo i wysłać datagram do jakiegoś serwera, po czym może natychmiast przez to samo gniazdo wysłać kolejne datagramy do różnych innych serwerów. Podobnie serwer przez jedno gniazdo może przyjmować datagramy od różnych klientów.

Należy podkreślić, że wiadomość zostanie odebrana tylko wtedy, gdy adresat oczekuje na odbiór datagramu, w przeciwnym wypadku wiadomość jest ignorowana.

Protokół jest zorientowany transakcyjnie, a dostarczenie wiadomości nie jest gwarantowane. Nie mamy żadnej informacji na temat tego, czy wysłane pakiety dotarły do celu. Nie ma też mechanizmy retransmisji (jak to było w przypadku TCP).

Komunikaty UDP mogą być gubione, duplikowane lub przychodzić w innej kolejności niż były wysłane, ponadto pakiety mogą przychodzić szybciej niż odbiorca może je przetworzyć.

Jest to protokół bezpołączeniowy, więc nie ma narzutu na nawiązywanie połączenia i śledzenie sesji (w przeciwieństwie do TCP). Nie ma też mechanizmów kontroli przepływu i retransmisji. Korzyścią płynącą z takiego uproszczenia budowy jest większa szybkośćtransmisji danych i brak dodatkowych zadań, którymi musi zajmować się host posługujący siętym protokołem. Z tych względów UDP jest często używany w takich zastosowaniach jak wideokonferencje, strumienie dźwięku w Internecie i gry sieciowe, gdzie dane muszą byćprzesyłane możliwie szybko, a poprawianiem błędów zajmują się inne warstwy modelu OSI.

Oprócz wysyłanych danych, każdy komunikat UDP zawiera numer portu odbiorcy i numer portu nadawcy, dzięki czemu oprogramowanie UDP odbiorcy może dostarczyć komunikat do właściwego adresata oraz umożliwia wysłanie odpowiedzi.

Zadanie (1pkt)

Podaj przykłady zastosowań kiedy wykorzystany powinien być protokół TCP i kiedy powinien być zastosowany protokół UDP (inny niż streaming Video).

Zadanie (1pkt)

Wytłumacz o co chodzi w dowcipie:

Zadanie (3pkt)

Stwórz za pomocą netcat-a serwer tcp i serwer udp. Wpisz w oknie cmd:

nc -L -p 2389

i w nowym okienku (dla serwera UDP)

nc -L -u -p 2389

Spróbój się z nimi połączyć, w nowym oknie wpisz (dla klienta TCP)

nc localhost 2389

I w nowym oknie (dla klienta UDP)

nc -u localhost 2389

Sprawdź, czy oba serwery działają. Znajdź w sieci informacje dlaczego tak jest? Co stanie się jeżeli chcielibyśmy stworzyć dwa serwery TCP na tym samym porcie?

Zadanie (5pkt)

Ściągnij prostą implementację serwera w pliku:

server.py

Uruchom ją wpisując w okienku cmd:

python server.py

W nowym oknie połącz się z serwerem poprzez wpisanie:

nc localhost 8080

Zamień implementację serwera tak, by dla otrzymanej liczby naturalnej zwracał do klienta liczbę o jeden większą. Podaj jako rozwiązanie kod swojego serwera.

Rozwiązania Zadań proszę przesłać przez stronę:

https://mw.vm.wmi.amu.edu.pl/login

*

Wykorzystano materiały z:

http://www.isep.pw.edu.pl/~slawekn/info1/lekcja9/segment2.htm

http://rogaski.republika.pl/cisco/sem2/intermediatetcpip.html#2

http://www.cs.put.poznan.pl/ddwornikowski/sieci/sieci2/bsdsockets.html

http://www.tenouk.com/Module41.html

http://www.binarytides.com/programming-udp-sockets-c-linux/

http://www.diffen.com/difference/TCP_vs_UDP

https://www.bleepingcomputer.com/tutorials/tcp-and-udp-ports-explained/