Bez tytułu slajdu

Wstęp

Omawialismy techniki, które mogą mieć zastosowanie do
połączenia zesobą zbioru komputerów w sieciach LAN,
WAN i w Internecie. Obecnie zajmiemy się dostawą
pakietów na poziomie komunikacji między procesami. To
zadanie spełnia warstwa transportowa modelu OSI.
Obsługuje ona komunikację między końcowymi
programami aplikacji i dlatego protokoły tej warstwy są
nazywane protokołami końcowymi (end-to-end protocol).
Pakiety TCP i UDP są transportowane wewnątrz pakietów
IP, dzięki czemu kolejne routery mogą obsługiwać je tak
samo jak standardowe pakiety IP. Oznacza to również, że
w przypadku przeciążenia routera, zablokowania
podłączonej podsieci lub nieaktywności odbiorcy
wszystkie przesyłki takie czeka podobny los: znikną one z
sieci bez jakiegokolwiek śladu. W ten sposób nadawca
nigdy nie uzyska informacji o tym, czy dany pakiet
rzeczywiście dotarł do adresata.

Większość aplikacji sieciowych musi mieć jednak
pewność, że wysłane dane dotarły do odbiorcy bez
przekłamań i we właściwej kolejności. Protokoły IP oraz
UDP (User Datagram Protocol) nie oferują wprawdzie
takich możliwości, ale TCP (Transmission Control Protocol)
już tak. Z tego też względu przeważająca część aplikacji
internetowych wykorzystuje do transmisji danych właśnie
protokół TCP.
W przeciwieństwie do UDP, TCP jest protokołem dość
skomplikowanym. W celu uzyskania pewności, że
wszystkie wysłane dane zostały prawidłowo
przetransmitowane, korzysta on z pomocy sum
kontrolnych, numerów bloków oraz potwierdzeń od
odbiorcy. Wszystkie przesyłki, które w ciągu określonego
czasu nie dotarły do adresata lub uległy jakimkolwiek
przekłamaniom, są automatycznie nadawane ponownie.
Dopiero wówczas, gdy kilka takich prób nie odniesie
skutku i adresat nie nadeśle żadnego potwierdzenia,
transmisja danych jest przerywana, a nadawca
informowany o jej niepowodzeniu

Można wyróżnić dwa rodzaje czynników kształtujących
protokół końcowy:

•ograniczenia jakości usług świadczonych przez sieć w
której działa protokół transportowy - ograniczenia od
dołu.

–Strata komunikatu
–zmiana kolejności komunikatów
–dostawa duplikatów tego samego komunikatu
–ograniczenie rozmiaru komunikatów
–dostawa komunikatu po dowolnie długim czasie

Sieć o określonych ograniczeniach nazywa się siecią
świadczącą usługę na poziomie dostępnych możliwości
(best-effort level of service). Przykładem sieci tego
rodzaju jest internet.

•Wymagania stawiane przez procesy aplikacji
obsługiwanej przez protokół transportowy:

–gwarancja dostawy komunikatów
–dostawa komunikatów w kolejności nadawania
–dostawa co najwyżej jednej kopii komunikatu
–obsługa dowolnie dużych komunikatów
–obsługa synchronizacji między nadawcą a odbiorcą
–zezwolenie odbiorcy na przejęcie sterowania
przepływem przez nadawcę

–obsługa wielu procesów aplikacji na każdym
komputerze.

–Etc.

Wyzwaniem jest opracowanie algorytmów
zapewniających wysoki poziom usług (QoS) wymagany
przez programy aplikacji.

Omówimy te algorytmy na podstawie trzech
reprezentatywnych usług sieciowych:

•usługa demultipleksacji- protokół UDP (User Datagram
Protocol)

• niezawodny strumienia bajtów - protokół TCP
(Transport Control Protocol)

•usługa żądanie/odpowiedź -RPC (Remote Procedure
Call)

Prosty demultiplekser

Prostym protokołem rozszerzającym usługę dostawy
między komputerami na usługę komunikacji między
procesami jest UDP. Głównym problemem jest w tym
przypadku postać adresu stosowana do identyfikacji
procesu docelowego.

•Bezpośrednia identyfikacja procesów. Procesy mogą
identyfikować się wzajemnie (bezpośrednio) za pomocą
identyfikatora procesu (process identifier -pid),
przydzielonego przez system operacyjny. Rozwiązanie
takie nożna zastosować jedynie w przypadku gdy jeden
system operacyjny jest uruchomiony na wszystkich
komputerach.

•Pośrednia identyfikacja procesów. Procesy
identyfikują się wzajemnie za pomocą abstrakcyjnego
wskaźnika - portu (port or mail box). Port stanowi etap
pośredni w komunikacji. Proces nadawczy przekazuje
komunikat do portu a proces odbiorczy odbiera stamtąd
tenże komunikat.

Multipeksacja i demultipleksacja

•Multipleksacja. Połączenie wyróżnionych kanałów
komunikacyjnych w pojedynczy kanał na niższym
poziomie. Na przykład, oddzielne kanały TCP i UDP są
poddane multipleksacji do jednego kanału IP między
węzłami sieci.

•Demultipleksacja. Operacja odwrotna do
multipleksacji. Na podstawie informacji zawartej w
nagłówku pakietu jest on kierowany w górę w stosie
protokołów. Na przykład , IP wykorzystuje zawartość pola
Protokół w nagłówku do skierowania pakietu do jednego
z protokołów warstwy transportowej TCP lub UDP.
Natomiast te protokoły korzystając z numeru portu
kierują segment do właściwego procesu aplikacji.

Nagłówek protokołu końcowego realizujący funkcje
demultipleksacji zawiera porty źródła i odbiorcy. Pola
portów w nagłówku UDP mają długość 16 bitów, co
umożliwia obsługę 6410

portów.

Port Nadawcy

Port Odbiorcy

Suma kontrolna

Długośc

Dane

Proces jest identyfikowany w określonym komputerze
przez parę port, komputer. Para ta jest kluczem

procesy demultipleksacji dla UDP.

Port jest pojeciem abstrakcyjnym. Jego implementacja
jest zależna od systemu operacyjnego.

Porty i procesy

Protokoły IP i ARP wchodzą w skład warstwy sieciowej. Na
wyższym poziomie znajduje się natomiast warstwa
transportowa, którą obsługują protokoły UDP i TCP. Gdy
przez Internet komunikują się ze sobą takie aplikacje, jak
serwery i przeglądarki WWW, muszą one korzystać z
pomocy jednego z tych dwóch ostatnich protokołów. Nie
mają natomiast w ogóle dostępu do pakietów IP, gdyż
pakiety te są wysyłane do hostów internetowych, a nie
aplikacji. Jeśli na danym hoście funkcjonuje kilka takich
aplikacji, nie istnieje tu możliwość jednoznacznej
identyfikacji, czy dany pakiet IP jest kierowany do serwera
WWW czy FTP.

Ponieważ protokół końcowy jest w stanie obsługiwać
wiele sesji pojedynczego hosta, musi on mieć możliwość
adresowania specyficznych programów komunikacyjnych,
które mogą działać na każdym z hostów. TCP(UDP)
wykorzystuje do tego numery portów. IETF przypisało
niektórym najczęściej stosowanym aplikacjom stałe
numery portów. Innym aplikacjom przydziela się po
prostu dostępny numer portu.

Najważniejszą informacją zawartą w nagłówku pakietu
UDP i TCP jest identyfikator portu adresata (16-bitowa
liczba), do którego ma trafić dany pakiet, oraz
identyfikator portu nadawcy. Oprogramowanie sieciowe
może za pomocą numeru portu rozpoznać, do jakiej
aplikacji należy przesyłka, i skierować nadesłane dane do
właściwego programu.

W celu nawiązania komunikacji z serwerem internetowym
potencjalny klient potrzebuje nie tylko jego numer IP, ale
również numeru portu. Numer ten musi być więc z góry
znany. Z tego też względu poszczególne numery portów z
przedziału 0-1024 są na stałe przyporządkowane różnym
usługom internetowym (takim jak FTP czy HTTP). Gdy
zatem w przeglądarce WWW wpiszemy adres URL,
program ten będzie od razu wiedział, że ma odwołać się
do portu numer 80 w komputerze, który kryje się pod tą
nazwą .

Port Protokół Zadanie

20+21

FTP

Transmisja danych

TELNET

Wiersz poleceń zdalnego hosta

SMTP

Nadawanie przesyłek e-mailowych

DNS

Odwzorowywanie nazw domen na

adresy IP
70

GOPHER

Usługa wyszukiwawcza dla Archive

HTTP

World Wide Web

110 POP3

Pobieranie przesyłek e-mailowych

119 NNTP

Usenet

161 SNMP

Zdalne administrowanie

urządzeniami sieciowym
194 IRC

Internet Chat

666 DOOM

Ulubiona gra wraz z odpowiednim

numerem portu
27000

QuakeWorld

Internetowa wersja Quake'a

Takie rozwiązanie sprawia jednak, że hakerzy mogą
stosunkowo łatwo docierać do całych grup adresów IP i
przez nawiązanie kontaktu za pomocą znanych numerów
portów sprawdzać, czy pod danym adresem funkcjonuje
określony serwer. Jeśli tak, to próbują się do niego
włamać, wykorzystując w tym celu słabe punkty danej
usługi. Z drugiej strony istnieje dość prosty sposób,
pozwalający na ukrycie określonych usług internetowych
przed zwykłymi użytkownikami. W tym celu wystarczy po
prostu przypisać dany serwer do nietypowego numeru
portu. I tak zamiast korzystać z portu numer 80, można
uruchomić serwer WWW na porcie 7436. Kontakt z tym
serwerem będą mogły nawiązać tylko osoby, które znają
ten numer i w swojej przeglądarce wpiszą adres URL w
określonej postaci. Podanie oznaczenia protokołu jest w
tym wypadku konieczne, gdyż inaczej przeglądarka nie
będzie wiedziała, jakiej usługi spodziewać się pod
wyspecyfikowanym portem.

W jaki sposób proces odnajduje port innego procesu do
którego adresuje komunikat?

Zazwyczaj to proces klienta nawiązuje wymianę
komunikatu z procesem serwera. Kiedy klient
skontaktował się z serwerem, to serwer poznał port
klienta (nagłówek) i może mu odpowiedzieć. Natomiast
problemem jest poznanie portu serwera przy pierwszym
z nim kontakcie. Rozwiązaniem jest przyjmowanie przez
serwer komunikatów w ogólnie znany, ustalonym porcie
(well-known port).

Na przykład:

• serwer nazw domen (DNS) odbiera komunikaty w
porcie 53

•uniksowy talk w porcie 517
•Etc.

Powszechnie znane porty stanowią początek komunikacji
klient-serwer, a następnie są zwalniane i udostępniane
innym klientom.

Jak działa UDP?

•UDP dołącza komunikat skierowany do określonego
porty do kolejki

•Brak jest sterowania przepływem
•Gdy kolejka jest przepełniona komunikat jest po prostu
odrzucany

•Proces aplikacji odbiera komunikaty z początku kolejki
(1st.in-1st.out), który jest usuwany z kolejki

•Jeżeli kolejka jest pusta proces jest zablokowany do
momentu nadejścia następnego komunikatu.

•Suma kontrolna jest opcja w IPv4, ale będzie
obowiązkowa w IPv6. Algorytm jej obliczania jest taki
sam jak dla IP. Obejmuje on:

—psuedo header + UDP header + data

pseudo header składa się z 3 pól nagłówka IP: długości, adresu IP
nadawcy i adresu IP odbiorcy. Weryfikuje czy komunikt był przesłany
między dwoma poprawnymi punktami końcowymi. Np. kiedy adres
IP odbiorcy był modyfikowany w czasie gdy komunikat był już
przesłany.

TCP - niezawodny strumień danych

TCP protokół sterowania (kontroli) transmisji jest
najszerzej znanym protokołem transportowym
oferującym połączeniowa usługę niezawodnego
strumienia danych. Usługa tak uwalnia aplikacje od
konieczności samodzielnego nadzoru nad transmisja
danych.

Cechy TCP:

•Protokół połaczeniowy (Connection-oriented)
•Strumień bajtów (Byte-stream)

•aplikacja wypisuje bajty
•TCP przesyła segmenty
•aplikacja odczytuje bajty

•komunikacja dupleksowa
•Sterowanie przepływem: protokół nie pozwala nadawcy na
przeciążanie możliwości odbiorcy
•Kontrola zatorów: protokół nie pozwala nadawcy na przeciążanie
sieci

Process aplikacji

Pisanie
bajtów

TCP

Bufor nadawcy

Segment

TRansmisja segmentów

Process aplikacji

Czytanie
bajtów

TCP

Bufor odbiorcy

…

Sposób zarządzania strumieniem bajtów

•TCP wymienia segmenty
•TCP decyduje, że ma dostateczna liczbę bajtów do
wysłanie segmentu zależnie od sytuacji:

–TCP ustala rozmiary segmentu w oparciu o MSS
(maximum segment size) ze dokonywania
fragmentacji. Wartość MSS ustalana jest na MTU
bezpośrednio dołączonej sieci pomniejszona o rozmiar
nagłówków TCP i IP.

–TCP obsługuje operacje umieszczania na stosie (push
operation) na życzenie klienta. Operacja ta jest
stosowana w emulatorach terminali np. Telnet.
Wówczas każdy bajt musi być wysłany natychmiast po
napisaniu znaku na klawiaturze.

–Transmisja wyzwolona jest przez zegar. Wówczas
wysyłane jest tyle bajtów ile znalazło się w buforze do
chwili wystąpienia sygnału.

• Punktem centralnym TCP jest algorytm
przesuwnego okna

Różnice między łączem fizycznym, a usługą

transportu

•Łącze fizyczne łączy dwa komputery.

 TCP może łączyć

wiele różnych hostów

–TCP potrzebuje fazy nawiązania łączności i jej

zakończenia. (Analogia: dedykowana linia

telefoniczna, a linia komutowana)

•Łącze fizyczne łączy zawsze dwa te same komputery
-stały RTT

 TCP różne zmieniające się w czasie RTT

(round-trip time)

– TCP potrzebuje adaptacyjnego mechanizmu

oczekiwania (timeout mechanism) dla przesuwnego

okna.

•Możliwość wystąpienia w sieci patologicznie długiego
opóźnienia

–TCP musi być przygotowany na przyjmowanie bardzo
starych pakietów <60s

•Różna ilość zasobów przeznaczonych (opóźnienie
•szerokość pasma) dla danego połączenia .

–TCP musi dostosowywać się do różnej ilości zasobów
np. pojemności buforów w węzłach

•Różna szybkość łaczy w sieci

–TCP musi być przygotowany na wystąpienie zatorów

(internet składa się z sieci o odminnych szybkościach

transmisji)

Format nagłówka segmentu TCP

Opcje (zmienne)

Dane

Suma kontrolna

Por nadawcy

Port odbiorcy

HdrLen

Flagi

Wskaźnik pilnych danych

Zalecane okno

Numer sekwencyjny

Potwierdzenie

Format nagłówka segmentu TCP cd.

•Każde połaczenie jest identyfikowane przez 4 wartości:

(SrcPort, SrcIPAddr, DsrPort, DstIPAddr)
Połączenia TCP między dana parą respondentów pojawiają się i
znikają.

•Przesuwne okno +sterowanie przepływem

acknowledgment, SequenceNum, AdvertisedWinow
Ponieważ TCP jet protokołem znakowym to każdy bajt danych
posiada numer sekwencyjny, a pole numer sekwencyjny zawiera
numer senwencyjny pierwszego bajtu przenoszonego przez dany
segment.

Nadawca

Dane

(SequenceNum)

Acknowledgment +

AdvertisedWindow

Odbiorca

•Flagi

SYN, FIN stosowane przy nawiązywaniu i zamykaniu połączenia,
ACK jest ustawiana za każdym razem gdy pole potwierdzenie jest
ważne,
URG oznacza, że dany segment zawiera pilne dane,
PUSH oznacza, że nadawca wywołał operacje umieszczania na
stosie i pole to informuje odbiorce o takim sposobie transmisji,
RESET oznacza zakłopotanie odbiorcy, np.. Nie spodziewł się on
takiego segmentu i dlatego chce przerwac połaczenie.

•Suma kontrolna

pseudo header + TCP header + data

Nawiązywanie połączenia

Strona mająca zamiar nawiązać połączenie wykonuje
otwarcie aktywne, a strona mająca zamiar zaakceptować
to połączenie wykonuje otwarcie pasywne.

Gdy faza nawiązania połączenia jest zakończona obie
strony zaczynają wymieniać dane.

Gdy jedna strona zakończy nadawać swoje dane to
zamyka swoja stronę połączenia. Powoduje to, że TCP
inicjuje wymianę komunikatów zamykających połączenie.

Zamykanie połączenia jest symetryczne (aktywne).

Wymiana trójetapowa

- algorytm nawiązywania i

rozłączania połączenia

Obie strony muszą uzgodnić zbiór parametrów, które w przypadku
otwarcia połączenia TCP są początkowymi numerami sekwencyjnymi
x i y, które każda ze stron ma zamiar zastosować do swego
strumienia bajtów. Są one ustalane losowo, aby uchronić się przed
dwoma inkarnacjami tego samego połączenia.

Uczestnik aktywny

(klient)

Uczestnik pasywny

(serwer)

SYN, Num

er sekwen

cyjny = x

SYN +

ACK,

Nume

r sek

ACK, Ackn

owledgme

nt = y + 1

Ackn

owled

gmen

t =

x + 1

Diagram czasowy algorytmu wymiany trójetapowej

Pole potwierdzenia
identyfikuje następny,
oczekiwany numer
sekwencyjny.
Potwierdzając w sposób
nie jawny wszystkie
poprzednie numery
sekwencyjne

Dla każdego
z pierwszych dwu
segmentów zostaje
ustawiony zegar jeśli
odpowiedź nie zostanie
odebrana, segment jest
nadawany ponownie.

Diagram przejść stanów, w których może się
znaleźć połączenie TCP

Diagram ten przedstawia stany biorące udział w
nawiązaniu (to co znajduje się powyżej stanu
NAWIĄZANE) i zamykaniu połączenia (Stany znajdujące
się poniżej stanu NAWIĄZANE).

Wszystko, co ma miejsce kiedy połączenie jest aktywne
zawarte jest w stanie NAWIĄZANE.

Nawiązywanie połączenia

Połączenie zaczyna się od stanu ZAMKNIĘTE, a
następnie ewoluuje wzdłuż strzałek opatrzonych
etykietami w postaci zdarzenie/akcja.

Gdy połączenie jest w stanie NASŁUCIWANIE nadchodzi
segment z flagą SYN. Połączenie przechodzi do stanu

SYN ODEBRANY i podejmuje akcje odpowiedzi
segmentem ACK+SYN Strona aktywna potwierdzając

odebranie segmenty SYN+ACK przechodzi do stanu
NAWIĄZANE Po odebraniu tego segmentu strona

pasywna przechodzi do stanu NAWIĄZANE.

Diagram przejść stanów

Zamknięte

Nasłuchiwanie

SYN Odebrany

SYN Nadany

Nawiazane

Czekanie na
zamknięcie

Ostatnie ACK

Zamykanie

Oczekiwanie
na spóźnionych

FIN
Oczekiwanie1

Otwarcie
pasywne

Zamknij

Nadaj/SYN

SYN/SYN + ACK

SYN + ACK/ACK

SYN/SYN + ACK

ACK

Zamknij/FIN

FIN/ACK

Za;knij/FIN

FIN/ACK

K +

FIN

Koniec czsu
oczekiwania
po 2 segment
lifetimes

FIN/ACK

ACK

Zamknij/FIN

Zamknij

Zamknięte

Otwarcie aktywne/SYN

/SYN

FIN
Oczekiwanie2

Rozłączanie połączenia

Procesy aplikacji po obu stronach połączenia muszą
niezależnie zamykać swoją stronę połączenia. Komplikuje
to diagram przejść, gdyż możliwe są trzy scenariusze
zamykania połączenia:

•Jedna strona zamyka wpierw:
NAWIĄZANIEFIN OCZEKIWANIE_1  FIN

OCZEKIWANIE_2 CZEKANIE NA SPÓŹNIALSKICH

ZAMKNIĘTE

•Druga strona zamyka wpierw:
NAWIĄZANIECZEKANIE NA ZAMKNIĘCIE 

OSTATNIE ACK ZAMKNIĘTE

•Obie strony zamykają razem:
NAWIĄZANIEFIN OCZEKIWANIE_1 ZAMYKANIE

CZEKANIE NA SPÓŹNIALSKICH ZAMKNIĘTE

Przejścia pomiędzy stanami wyzwalane są przez dwa

rodzaje zdarzeń:

1. Nadejście segmentu od partnera

2. Wywołanie operacji przez lokalny proces aplikacji

(otwarcie aktywne).

Diagram przejść między stanami TCP definiuje
semantykę interfejsu między partnerami.

Składnia (syntax) tych dwu interfejsów określona jest
przez format segmentu.

Niezawodna transmisja

Niezawodna transmisja opiera się na dwu podstawowych
mechanizmach:

•Potwierdzeń (aknowlegements ACK)
•Czasów oczekiwania (timeouts)

ACK jest segmentem (ramką) wskazująca nadawcy, że
jego segment (ramka) został pomyślnie odebrany. Jeżeli
nadawca nie odbierze potwierdzenia po ustalonym czasie
oczekiwania, dokonuje on retransmisji segmentu (ramki).

Ogólna strategia stosowania potwierdzeń i czasów
oczekiwania, w celu implementacji niezawodnej dostawy
segmentów (ramek), jest nazywana automatycznym
żądaniem powtórzenia (automatic repeat request) ARQ.

Jednym z algorytmów ARQ jest algorytm przesuwnego
okna.

Sender

Receiver

Frame

ACK

Tim

Sender

Receiver

Frame

ACK

Tim

Frame

ACK

Tim

Sender

Receiver

Frame

ACK

Tim

Frame

ACK

Tim

Sender

Receiver

Frame

Tim

Frame

ACK

Tim

(a)

(c)

(b)

(d)

Potwierdzenia i czasy oczekiwania

Diagram czasowy dla czterech scenariuszy algorytmu
Stój i czekaj:

Problem: keeping the pipe full

Iloczyn Opóźnienie Szerokość Pasma określa ilość

danych, którą chcielibyśmy być zdolni nadać bez
czekania na pierwsze potwierdzenie. Jest to zasada
utrzymywana wypełnionego łącza.

Przykład:
Jeżeli oczekujemy na potwierdzenie (algorytm: Stój i
Czekaj ) to zakładając, że iloczyn opóźnienie szerokość
pasma

45ms RTT

1.5Mbps link = 67.5Kb (8KB)

Ponieważ nadajnik może nadać jedynie 1 ramkę na 1 RTT

to dla ramek o rozmiarze 1kB maksymalna szybkość

nadawania wynosi
(1024 ·8):0.045=182kb/s
czyli łącze wykorzystane jest w 1/8

Nadajnik

Odbiornik

…

Algorytm Przesuwnego okna (sliding window)

Rozważmy ponownie scenariusz, w którym opóźnienie
szerokość pasma wynosi 8kB i ramki maja rozmiar 1kB
chcielibyśmy, aby nadajnik był gotowy do transmisji 9
ramki tuz po nadejściu ACK dla pierwszej ramki.

1
2
3

8
9

SW: Nadajnik

• Przypisuje każdej ramce numer sekwencyjny

(SeqNum)

• Zarządza trzema zmiennymi stanu:

– Rozmiar okna nadawczego (SWS)

– Numer sekwencyjny ostatniego odebranego

potwierdzenia(LAR)

– Numer sekwencyjny ostatniej nadanej

ramki(LFS)

• Utrzymuje niezmiennik: LFS - LAR <= SWS

• Zwiększa LAR po odebraniu ACK

• Buforuje liczbę SWS ramek



SWS

LAR

LFS

…

SW: Odbiornik

• Zarządza trzema zmiennymi stanu:

– Rozmiar okna odbiorczego (RWS)

– Górna granica liczby ramek przyjmowanych poza

kolejnością - ostatnia akceptowana ramka (LFA)

– Następna oczekiwana ramka (NFE)

• Utrzymuje niezmiennik: LFA - NFE +1<= RWS

• Gdy przychodzi ramka o numerze SeqNum:

– Jest akceptowana jeżeli NFE <= SeqNum < = LFA

– Jest odrzucana jeżeli SeqNum < NFE lub SeqNum > LFA



RWS

NFE

LFA

…

Wysłanie kumulacyjnego ACK

Niech SeqNumToAck oznacza największy numer
sekwencyjny, który nie został jeszcze potwierdzony ale
taki, że wszystkie ramki o numerach SeqNum<
SeqNumToAck zostały odebrane. Odbiornik potwierdza
odbiór ramki SeqNumToAck i wszystkich poprzednich -
potwierdzenie kumulacyjne.

Następnie odbiornik ustawia NFE= SeqNumToAck+1

i modyfikuje LFA= SeqNumToAck+RWS.

Przykład:

Niech RWS=4, NFE=5, czyli ostatni nadany AKC odnosił
się do numeru sekwencyjnego ramki 4. Wynika stąd, że
LFA=9. Ramki 6 i 7 znajdują się w oknie odbiornika i
gdyby nadeszły będą buforowane, jednakże nie zostanie
nadane żadne AKC przed przybyciem ramki 5. W takim
przypadku ramki 6 i 7 nadeszły poza kolejnością.

Inną odmianą tego schematu jest tzw. potwierdzenie
selektywne. Odbiornik potwierdza wówczas te ramki
które odebrał.

Wariant algorytmu przesuwnego okna stosowany

w TCP

Algorytm przesuwnego okna pozwala na osiągnięcie kilku

celów:

1. Gwarantuje niezawodna dostawę danych

2. Zapewnia dostarczenie danych w odpowiedniej

kolejności

3. Wymusza sterowanie przepływem między nadawca i

odbiorcą.

W przypadku dwóch pierwszych funkcji TCP

wykorzystuje ten sam algorytm przesuwnego okna.
TCP różni się od wcześniej opisanego algorytmu
funkcją sterowania przepływem. Zamiast
stosowania stałego rozmiaru okna, odbiorca zaleca
nadawcy rozmiar okna (pole zalecane okno). Odbiorca
wybiera odpowiednia wartość tego pola na podstawie
ilości pamięci przydzielonej w celu buforowania
danych.

Przesuwne okno TCP

Aplikacja wysyłająca

Ostatni bajt zapisany

TCP

Ostani nadany bajt

Ostatni bajt potwierdzony

Aplikacja odbierająca

Ostatni bajt przeczytany

TCP

Ostatni bajt odebrany

Następny bajt oczekiwany

•Bufor nadawczy :

OstBajtPotw < =OstBajtNad

LastBytNad < = OstBajtZap

buforowane są bajty pomiędzy

OstBajtPotw

OstBajtZap

•Bufor odbiorczy:

OstBajtOdcz <

NastBajtOczek

NastBajtOczek < =

OstBajtOde +1

buforowane są bajty pomiędzy

NastBajtOdcz

OstBajtOde

Sterowanie przepływem

Zasadnicza różnicą między algorytmem TCP a SW
opisanym wcześniej polega na uwzględnieniu zapełniania
i opróżniania buforów przez procesy aplikacji po stronie
nadawczej i odbiorczej.

Definiujemy:

MaksBufNad i MaksBufOdb

Szerokość okna określa liczbę bajtów, które mogą być
nadane bez czekania na potwierdzenie od odbiorcy. W ten
sposób odbiorca ogranicza nadawcę polecając mu okno
nie większe niż ilość danych, którą może buforować. TCP
po stronie odbiorczej spełnia relację:

OstBajtOde-NastBajtOdcz<= MaksBufOdb

Aby uniknąć przepełnienia bufora zaleca on szerokość
okna:

ZalecOkno= MaksBufOdb-(OstBajtOde- NastBajtOdcz)

Rozmiar okna po stronie odbiorcy może się zmniejszać,
jeżeli oplikacja nie nadąża z odczytywaniem
nadchodzących danych.

Nadawca musi dopasować się do rozmiaru zalecanego
okna, obliczając wielkość okna efektywnego

EfektOkno= ZalecOkno -(OstBajtNad-OstBajtPotw)

EfektOkno >0, aby nadawca mógł nadać dane. Kiedy
dane przychodzą odbiorca potwierdza je jeśli wszystkie
poprzedzające je segmenty również nadeszły. Gdy
odbiorca potwierdzi x danych, nadawca może zwiększyć
OstBajtPotw o x. Zwalniając przestrzeń bufora
nadawczego, ale nie mogąc nadać więcej danych bo
rozmiar zalecanego okna zmniejszył się wraz ze
wzrostem OstBajtOde, a aplikacja czyta dane we
właściwym porządku więc NastBajtOdcz nie zdążył się
jeszcze zmienić. W takiej sytuacji TCP blokuje proces
zapisujący dane do bufora nadawczego.

Powolny proces odbierający może zablokować szybki
proces nadający!

W jaki sposób strona nadawcza dowiaduje się, że
ZalecOkno przestało być zerowe?

Po zaleceniu zerowego okna, strona nadająca nadaje
stale jeden segment z jednym bajtem danych co pewien
czas wiedząc, że prawdopodobnie nie zostaną one
zaakceptowane. W końcu któraś z takich sond wyzwala
odpowiedź, zawierającą niezerową wartość zmiennej
ZalecOkno.

Taki schemat działania TCP sprawia, że strona odbiorcza
jest możliwie najprostsza i nie inicjuje działania na
własna rękę (przykład zasady smart sender/dumb
receiver).

Zabezpieczenie przed zawijaniem numeru
sekwencyjnego

32-bitowe pole

SequenceNum

pozwala utworzenie 2

różnych numerów sekwencyjnych. Taki sam numer
sekwencyjny nie może pojawić się ponownie przed
upływem 60s . Czy to się zdąży, czy nie, zależy od tego
jak szybko wyczerpie się przestrzeń numerów
sekwencyjnych. Zależy to oczywiście od szerokości
pasma.

Pasmo

Czas do wyczerpania

przestrzeni

numerów sekwencyjnych

Ethernet (10 Mbps)

57 minutes

T3 (45 Mbps)

13 minutes

FDDI (100 Mbps) 6 minutes
STS-3 (155 Mbps)

4 minutes

STS-12 (622 Mbps)

55 seconds

STS-24 (1.2 Gbps)

28 seconds

Wypełnienie pojemności łącza

16b pole

AdvertisedWindow

pozwala polecić otwarcie okna

o szerokości 64kB co nie zawsze umożliwia nadawcy
wypełnienie całej pojemności łącza. Największe możliwe
zalecane okno określone jest przez iloczyn
Opóźnienie•Pasmo, które definiuje ilość danych “w
rurze”.

Pasmo

Pasmo •

(RTT=100ms)

Ethernet (10 Mbps)

122KB

T3 (45 Mbps)

549KB

FDDI (100 Mbps)

1.2MB

STS-3 (155 Mbps)

1.8MB

STS-12 (622 Mbps)

7.4MB

STS-24 (1.2 Gbps)

14.8MB

Pasmo

Opóźnienie

Retransmisja adaptacyjna

TPC gwarantuje niezawodna dostawę danych, wiec
retransmituje każdy segment, jeżeli w określonym czasie
nie zostanie odebrany ACK. TCP ustawia czas
oczekiwania jako funkcję spodziewanej wartości RTT
między dwoma końcami połączenia. W przypadku
internetu wybór odpowiedniej wartości timeoutu nie jest
prosty.

Oryginalny algorytm wyliczania czasu oczekiwania
dla TCP

Czas oczekiwania jest obliczany na podstawie aktualnej
wartości średniej z RTT.

•TCP rejestruje

SampleRTT

dla każdej pary nadany

segment/ ACK

•Oblicza średnia ważoną RTT

EstRTT =



x EstRTT +



x SampleRTT

gdzie





= 1

0.8 <=



<= 0.9

0.1<=



<= 0.2

•Na podstawie

EstRTT

ustala wartość czasu oczekiwania

TimeOut = 2 x EstRTT

Przedstawiony algorytm posiada wadę. ACK nie jest
potwierdzeniem transmisji, a odbioru danych. Gdy
segment jest retransmitowany, a następnie nadchodzi do
nadawcy ACK to nie jest możliwe stwierdzenie czy ACK
powinno być powiązane z pierwszą czy z drugą
transmisją segmentu. Wiedza ta jest konieczna dla
poprawnego obliczenia wartości SampleRTT.

Nadawca

Odbiorca

Transm

isja Ory

ginalna

ACK

Retrans

misja

Nadawca

Odbiorca

Transm

isja Ory

ginalna

ACK

Retrans

misja

Algorytm Karna/Partridge’a

Rozwiązanie problemu:
• Nie pobierać próbek RTT przy retransmisji
• Podwajać wartość czasu oczekiwania po

każdej retransmisji.

Oznacza to, że Karn i Partridge zaproponowali

aby TCP wykorzystał wykładniczy algorytm
wykrywania kolizji, uzywany w internecie.

Algorytm Jacobsona/ Karelsa

Mechanizm czasu oczekiwania ma zwiazek z

przeciążeniem. Jeśli wystąpi zbyt wcześnie,

niepotrzebnie będziemy retransmitowali

segment co zwiększa obciąenie sieci. Wartość

tego czasu wyzwala także mechanizm kontroli

przeciążenia..

• Propozycja Jacobsona i Karelsa to nowuy

sposób obliczanie średniej wartości RTT

• Diff = SampleRTT - EstRTT
• EstRTT = EstRTT + ( x Diff)
• Dev = Dev + ( |Diff| - Dev)

– gdzie czynnik 0 <=  <= 1

Następnie TPC oblicza wartość czasu oczekiwania jako

funkcję

TimeOut =



x EstRTT +



x Dev

gdzie zazwyczaj



= 1, a



= 4.

Stąd gdy odchylenie Dev jest małe czas oczekiwania

jestzblizony do szacunkowej wartości EstRTT. Natomiast,

gdy odchylenie jest duże w obliczeniu dominuje Dev.

Algorytm Jacobsona i Karelsa

jest jedynie tak dobry, jak

zegar użyty do odczytu bieżącego czasu. 500ms w

typowej implementacji Unix. Jest to wartość większa od

typowego RTT dla komunikacji krajowej (100-200ms).

Problem pogarsza fakt, że w implementacji Unixowej TCP

sprawdza czy upłynął timeout również co 500ms.

Granice rekordów

TCP jest protokołem strumienia bajtów oznacza to, że
liczba bajtów zapisanych przez nadawcę nie musi być
koniecznie taka sama jak liczba bajtów odczytanych
przez odbiorcę.

Przykład:

Aplikacja może zapisać do połączenia TCP: 8B, 2B i 20B.
Podczas gdy aplikacja po stronie odbierającej odczytuje
5B naraz wewnątrz pętli powtarzanej 6 razy. W
odróżnieniu od protokołów operujących na komunikatach
jak UDP, TCP nie wtrąca granic rekordów pomiędzy 8 i 9
bajtem, a także pomiędzy 10 i 11 bajtem.

TCP posiada dwie istotne cechy, za pomocą których
można wprowadzić granice rekordów do strumienia
bajtów informując w ten sposób odbiorcę w jaki sposób
podzielić strumień na rekordy. Są to:

•Operacja zapisu na stosie (operacja push - Telnet).
Ponieważ w nagłówku TCP można wstawić flagę push
TCP może poinformować aplikacje odbierającą o
wykonaniu zapisu na stosie.

•Drugi mechanizm do wprowadzenia znaczników granic
rekordów to cecha pilnych danych, implementowana
przez flagę URG oraz pole pilnych danych (UrgPtr).

Opcje (zmienne)

Dane

Suma kontrolna

Por nadawcy

Port odbiorcy

HdrLen

Flagi

Wskaźnik pilnych danych

Zalecane okno

Numer sekwencyjny

Potwierdzenie

Document Outline