Transmission Control Protocol (TCP)
Do tej
pory zajmowaliśmy się usługami zawodnego dostarczania pakietów, bez użycia
połączenia, co stanowi podstawę protokołu IP. Jednakże IP nie troszczy się tak
naprawdę o dostarczenie datagramu do adresata, lecz w przypadku odrzucenia datagramu
sygnalizuje ten fakt jako błąd maszynie-nadawcy i uznaje sprawę za załatwioną.
Używanie zawodnego dostarczania bez użycia połączenia do przesyłania dużych porcji
danych jest więc nużące i wymaga od programistów, aby wbudowywali do każdego programu
użytkowego wykrywanie i korekcję błędów.
Obecnie zajmiemy się przesyłaniem niezawodnymi strumieniami oraz przedstawimy protokół
kontroli transmisji (ang. Transmission Control Protocol, TCP), który
tę usługę definiuje. Pokażemy, że TCP zwiększa istotnie funkcjonalność zestawu
omawianych dotąd protokołów, biorąc odpowiedzialność za wiarygodne dostarczenie
datagramu. Jednakże jego implementacja jest znacznie bardziej skomplikowana.
Protokół TCP będąc drugą najważniejszą usługą w sieci, wraz z IP dał nazwę
całej rodzinie protokołów TCP/IP. Pomimo związku z protokołem IP - TCP jest
protokołem w pełni niezależnym i może zostać zaadaptowany do wykorzystania z innymi
systemami dostarczania. Możliwe jest używanie go zarówno w pojedynczej sieci takiej jak
Ethernet jak i w skomplikowanej intersieci.
Własności
usługi niezawodnego dostarczania
TCP organizuje dwukierunkową współpracę między warstwą IP, a
warstwami wyższymi, uwzględniając przy tym wszystkie aspekty priorytetów i
bezpieczeństwa. Musi prawidłowo obsłużyć niespodziewane zakończenie aplikacji, do
której właśnie wędruje datagram, musi również bezpiecznie izolować warstwy wyższe
- w szczególności aplikacje użytkownika - od skutków awarii w warstwie protokołu IP.
Scentralizowanie wszystkich tych aspektów w jednej warstwie umożliwia znaczną
oszczędność nakładów na projektowanie oprogramowania.
TCP rezyduje w modelu warstwowym powyżej warstwy IP. Warstwa ta jest
jednak obecna tylko w tych węzłach sieci, w których odbywa się rzeczywiste
przetwarzanie datagramów przez aplikacje, tak więc nie posiadają warstwy TCP na
przykład routery, gdyż warstwy powyżej IP nie miałyby tam nic do roboty.
Interfejs między programami użytkowymi a usługami niezawodnego
dostarczania TCP/IP można scharakteryzować za pomocą następujących własności:
- Przesyłanie
strumieniami.
Gdy dwa programy użytkowe (procesy użytkownika) przesyłają duże
ilości danych, myślimy o tych danych jako o strumieniu bitów, który jest podzielony na
8-bitowe oktety nieformalnie nazywane bajtami. Usługa dostarczania strumieniami na
maszynie docelowej to przekazanie odbiorcy dokładnie tego samego ciągu oktetów, który
na swojej maszynie przekazał nadawca.
- Łączenie w obwód
wirtualny.
Przed rozpoczęciem przesyłania, programy użytkowe zarówno nadawcy, jak
i odbiorcy muszą się porozumieć z własnymi systemami operacyjnymi, informując je o
potrzebie przesyłania za pomocą strumienia. Moduły oprogramowania protokołów w obu
systemach porozumiewają się, wysyłając przez intersieć odpowiednie komunikaty
sprawdzające czy transfer został autoryzowany oraz czy obydwie strony znajdują się w
stanie gotowości. Po ustaleniu tych szczegółów moduły protokołów informują
programy użytkowe, że połączenie zostało ustanowione i że można rozpocząć
przesyłanie. W trakcie komunikacji oprogramowanie protokołów w dalszym ciągu wymienia
informacje, które potwierdzają poprawność otrzymywanych danych. Jakiekolwiek
zakłócenie komunikacji (np. z powodu awarii osprzętu sieciowego na ścieżce pomiędzy
nadawcą a odbiorcą) zostaje wykryte przez obie maszyny i powoduje poinformowanie
odpowiednich programów użytkowych. Tego typu połączenie określa się mianem obwodu
wirtualnego, bo chociaż programy użytkowe widzą to połączenie tak, jakby istniał
tutaj specjalny obwód elektroniczny, to niezawodność jest złudzeniem wywołanym przez
usługę dostarczania strumieniami.
- Przesyłanie z
użyciem buforów
. Programy użytkowe przesyłają strumienie danych obwodami
wirtualnymi dzięki przekazywaniu kolejnych oktetów danych do oprogramowania
protokołów. Program użytkowy przesyła dane w porcjach, które uważa za wygodne, a
które mogą być nawet wielkości jednego oktetu. U odbiorcy oprogramowanie protokołów
dostarcza oktety ze strumienia danych w takim samym porządku, w jakim zostały wysłane,
udostępniając je odbierającemu programowi użytkowemu, po otrzymaniu i sprawdzeniu.
Oprogramowanie protokołów ma swobodę przy dzieleniu strumienia na pakiety i może to
robić niezależnie od tego, jak strumień jest dzielony przez program użytkowy. W celu
zwiększenia efektywności przesyłania i zminimalizowania ruchu w sieci przyjmuje się
zwykle strategię czekania, aż uzbiera się tyle danych ze strumienia, żeby wypełnić
datagram o rozsądnej wielkości zanim się go wyśle do intersieci. Dzięki temu, nawet
jeśli program użytkowy generuje strumień po jednym bajcie naraz, przesyłanie danych
przez intersieć może być dosyć efektywne. Podobnie jeśli program użytkowy wygeneruje
bardzo duży blok danych, to oprogramowanie protokołów może podzielić go do transmisji
na mniejsze porcje.
Dla
tych programów użytkowych, w których dane powinny zostać dostarczone, nawet jeżeli
bufor nie został wypełniony, udostępnia się mechanizm “wypychania” (ang. push),
którego programy użytkowe używają do wymuszania przesyłania. Po stronie nadawcy
operacja wypchnięcia wymusza na oprogramowaniu protokołów przesłanie wszystkich tych
danych, które zostały dotąd wygenerowane, bez czekania na wypełnienie bufora. Po
stronie odbiorcy zaś powoduje, że TCP udostępnia dane programowi użytkownika beż
opóźnienia.
- Brak
strukturalizacji strumienia.
Usługa przesyłania za pomocą strumieni TCP/IP nie
uwzględnia strukturalizacji strumienia danych. Programy użytkowe wykorzystujące usługi
przesyłania za pomocą strumieni muszą interpretować zawartość strumienia i jeszcze
przed rozpoczęciem połączenia zgadzać się na format strumienia.
- Połączenie w
pełni dwukierunkowe.
Połączenia zapewniane przez usługę przesyłania za pomocą
strumieni TCP/IP są połączeniami w pełni dwukierunkowymi (ang. duplex). Z
punktu widzenia programu użytkowego połączenie w pełni dwukierunkowe składa się z
dwu niezależnych strumieni danych płynących w przeciwnych kierunkach bez żadnej jawnej
interakcji między nimi. Usługa przesyłania za pomocą strumieni pozwala procesowi
użytkownika na zatrzymanie przepływu w jednym z kierunków bez zakłócania przepływu w
drugim, co czyni połączenie połączeniem połowicznie dwukierunkowym (ang. half
duplex). Przy połączeniu w pełni dwukierunkowym oprogramowanie protokołów
obsługujących może wysyłać nadawcy informacje kontrolne związane z jednym
strumieniem w datagramach niosących dane w kierunku przeciwnym, co jest jego zaletą.
Powoduje to zmniejszenie ruchu w sieci.
Rozpatrując TCP z punktu widzenia funkcjonalności można
potraktować jego pracę jako ustanowienie kanału wirtualnego realizującego komunikację
między “końcówkami” - tak wygląda to z punktu widzenia programu użytkownika.
Rzeczywisty
przepływ oczywiście odbywa się poprzez warstwę IP i warstwy niższe.

Realizacja niezawodnego połączenia
Powiedzieliśmy wcześniej, że usługa dostarczania niezawodnymi
strumieniami zapewnia, że dane wysyłane w strumieniu z jednej maszyny do drugiej nie są
ani tracone, ani duplikowane. Zachodzi więc pytanie: “W jaki sposób oprogramowanie
protokołów realizuje niezawodne przesyłanie, skoro bazowy system komunikacyjny oferuje
tylko zawodne dostarczanie pakietów?”. Odpowiedź jest skomplikowana, ale większość
protokołów oferujących niezawodność używa jednej podstawowej metody znanej jako pozytywne
potwierdzanie z retransmisją (ang. positive acknowledgment with retransmission).
Metoda ta wymaga, aby odbiorca komunikował się z nadawcą, wysyłając mu w momencie
otrzymania danych komunikat potwierdzenia (ACK). Nadawca zapisuje sobie informację o
każdym wysłanym pakiecie i przed wysłaniem następnego czeka na potwierdzenie. Oprócz
tego nadawca uruchamia zegar w momencie wysyłania pakietu i wysyła ten pakiet ponownie,
gdy minie odpowiedni czas, a potwierdzenie nie nadejdzie.
Poniższy rysunek pokazuje, w jaki sposób odbywa się przesyłanie
danych przy użyciu najprostszego protokołu z pozytywnym potwierdzaniem. Na tym rysunku
wydarzenia u nadawcy i odbiorcy zostały przedstawione odpowiednio po lewej i prawej
stronie. Każda ukośna linia przez środek oznacza przesłanie przez sieć jednego
komunikatu.

Na
kolejnym rysunku użyto tej samej formy diagramu co na poprzednim rysunku do pokazania, co
się dzieje gdy pakiet został zgubiony lub gdy przekroczony został limit czasu. Po
wysłaniu pakietu nadawca włącza zegar. Gdy mija określony czas, w czasie którego
powinno nadejść potwierdzenie ACK nadawca przyjmuje, że pakiet został zagubiony i
wysyła go ponownie.
-
-
- Ostatni problem związany z
niezawodnością pojawia się, gdy bazowy system dostarczania duplikuje pakiety.
Duplikowanie może się też pojawić, gdy sieci mają duże opóźnienia powodujące
przedwczesne retransmisje. Rozwiązanie problemu duplikowania wymaga uważnego
przemyślenia, gdyż mogą być zduplikowane zarówno pakiety jak i potwierdzenia. Zwykle
niezawodne protokoły wykrywają zduplikowane pakiety, przyznając każdemu pakietowi
kolejny numer i wymagając, aby odbiorca pamiętał numery odebranych pakietów. W celu
uniknięcia zamieszania spowodowanego opóźnionymi lub zduplikowanymi potwierdzeniami,
protokoły z pozytywnym potwierdzaniem wysyłają w potwierdzeniach wartości kolejnych
numerów, dzięki czemu odbiorca może prawidłowo wiązać potwierdzenia z pakietami.
| Wprowadzenie
| Sieć komputerowa | Protokoły | Model OSI (Open Systems Interconnection) | TCP/IP
a model OSI | Adresowanie fizyczne | Adresy IP |
| Protokół
Odwzorowania Adresów (ARP) | Protokół Odwrotnego Odwzorowania
Adresów (RARP) | Internet Protocol (IP) | Kapsułkowanie
| Fragmentacja |
| Koleje
Życia Datagramu | ICMP | Określanie
Ostatecznego Adresata | UDP | Multipleksowanie
I Demultipleksowanie | Transmission Control Protocol (TCP) |
| Idea
przesuwających się okien | Segment TCP | Porty i połączenia | Konfiguracja TCP/IP
w systemie Unix | Przyszłość TCP/IP | Bibliografia
|