Rozdział 7. Protokół sterowania transmisją

Transkrypt

1 Rozdział 7. Protokół sterowania transmisją Dogłębnie Protokół sterowania transmisją (TCP) jest wymaganym standardem protokołu TCP/IP, określonym w dokumencie RFC 793. Zapewnia on oparte na połączeniach, niezawodne, zorientowane na strumieniowy przesył bajtów połączenia i jest wykorzystywany do logowania, współużytkowania plików oraz wydruku, replikacji informacji, przesyłania list przeglądania, oraz innych zwykłych funkcji w środowisku pracy sieciowej systemu Windows. TCP może być wykorzystywany do komunikacji typu jeden do jednego (lub point-to-point). Niniejszy rozdział najpierw omawia standardowe funkcje i działanie TCP, a następnie przechodzi do opisu udoskonaleń, oraz nowych funkcji zapewnianych przez system Windows Ponieważ większość programów usługowych i usług TCP/IP wykorzystuje TCP, stosowne jest podsumowanie ich w tym rozdziale. Protokoły transportu w sieciach złożonych, takie jak protokół transmisji hipertekstu (HTTP) oraz protokół transmisji plików (FTP) opisane są w rozdziale 9. Standardowe funkcje i działanie TCP TCP jest usytuowany ponad usługą protokołu internetowego (IP) i prawdopodobnie, jest on najbardziej znaczącym protokołem transportu w zestawie TCP/IP. Zapewnia on niezawodną metodę transportu przy użyciu przesyłu strumieniowego programom, które korzystają z sesyjnej transmisji danych, i gwarantuje dostarczanie datagramów IP. TCP implementuje niezawodny, wydajny transport za pomocą kilku mechanizmów. Segmentacja i numery sekwencji TCP segmentuje i ponownie składa duże bloki danych wysyłane przez programy, oraz zapewnia właściwe szeregowanie i uporządkowane dostarczanie segmentowanych danych. Numery sekwencji wykorzystywane są do koordynacji przesyłu i odbioru danych, a TCP zapewnia ponowną transmisję, jeśli ustali, że dane uległy zagubieniu. Protokół ten korzysta z 32-bitowego numeru sekwencji, który liczy oktety w strumieniu danych. Każdy z pakietów TCP zawiera

2 początkowy numer sekwencji danych w tym pakiecie oraz numer sekwencji (lub numer potwierdzający) ostatniego bajta otrzymanego od zdalnego komputera równorzędnego. Przy użyciu tej informacji implementowany jest protokół okna przesuwnego, co zostało opisane w dalszej części tego rozdziału. Numery sekwencji do przodu i wstecz są całkowicie niezależne. TCP zazwyczaj działa w trybie pełnodupleksowym, co oznacza, że działa w obydwu kierunkach w sposób prawie całkowicie niezależny. Nie ma mechanizmu kojarzącego dane strumienia bajtów do przodu i wstecz. TCP wykazuje zachowanie asymetryczne (to jest przesył danych w jednym kierunku) tylko podczas sekwencji rozpoczęcia i zamknięcia połączenia. TCP wykorzystuje znaczniki kontrolne do zarządzania połączeniem. Niektóre z tych znaczników (takie jak znacznik URG) odnoszą się do pojedynczego pakietu. Jednakże dwa znaczniki (SYN oraz FIN) oznaczają początek i koniec strumienia danych i wymagają niezawodnego dostarczenia. Znacznikom tym przypisane są miejsca w przestrzeni numeru sekwencji. TCP wysyła potwierdzenia (ACK), kiedy dane zostaną pomyślnie odebrane. Jeżeli włączone jest potwierdzenie selektywne (SACK), to TCP przesyła również potwierdzenia negatywne, kiedy oczekiwane dane nie zostaną odebrane. SACK jest domyślnie włączony w systemie Windows Sumy kontrolne Numery sekwencji, znaczniki kontrolne oraz potwierdzenia gwarantują, że przetransmitowane dane zostały otrzymane i ponownie złożone we właściwą sekwencję i że nie brakuje segmentów. TCP kontroluje również integralność danych przy użyciu obliczeń sumy kontrolnej. Jeśli suma kontrolna jest niewłaściwa, to datagram zostaje odrzucony i musi być transmitowany. Obliczanie sumy kontrolnej jest skomplikowane. Jeżeli musisz znać szczegóły, to poniższy fragment jest bezpośrednim wypisem z dokumentu RFC 793: Pole sumy kontrolnej to 16-bitowe uzupełnienie jedynkowe sumy uzupełnienia jedynkowego wszystkich słów 16-bitowych w nagłówku i tekście. Jeżeli dany segment zawiera nieparzystą liczbę oktetów nagłówka i tekstu, które mają być poddane sumie kontrolnej, to ostatni oktet zostaje wypełniony z prawej strony zerami, aby utworzyć słowo 16-bitowe dla potrzeb sumy kontrolnej. Wypełnienie nie jest transmitowane jako część segmentu. Podczas obliczania sumy kontrolnej samo pole sumy kontrolnej zostaje zastąpione zerami. Suma kontrolna obejmuje również 96-bitowy pseudo-nagłówek koncepcyjnie przytwierdzony do nagłówka TCP. Ten pseudo-nagłówek zawiera adres źródłowy, adres docelowy, protokół, oraz długość TCP. Zapewnia to TCP zabezpieczenie przed błędnie routowanymi segmentami. Informacja ta jest niesiona w protokole internetowym i przesyłana poprzez interfejs TCP sieć w argumentach lub wynikach wywołań IP przez TCP. Kontrola przepływu danych TCP zapewnia wydajną transmisję danych poprzez sieć dzięki kontroli przepływu danych. Odkrywa ona dynamicznie charakterystykę opóźnień sieci i reguluje jej działanie, aby maksymalizować przepustowość bez przeciążania sieci. Każdy węzeł końcowy połączenia TCP ma bufor, służący do zapamiętywania danych transmitowanych poprzez sieć, dopóki dana aplikacja nie będzie gotowa do odczytu tych danych. Pozwala to, aby mogły mieć miejsce przesyły sieciowe w czasie, kiedy aplikacje są zajęte innymi procesami i poprawia ogólną wydajność. TCP zarządza ruchem tak, aby jego bufory się nie

3 przepełniały szybcy nadawcy są okresowo zatrzymywani, żeby wolniejsi nadawcy mogli nadążyć. Aby uniknąć przepełnienia bufora, TCP ustawia pole rozmiar okna w każdym z pakietów, które transmituje. Pole to wskazuje ilość danych, które mogą być transmitowane do bufora. Gdy wartość ta spadnie do zera, to host transmitujący nie będzie przesyłał żadnych danych, dopóki nie otrzyma pakietu anonsującego wartość niezerową w polu rozmiaru okna. Czasami przestrzeń bufora jest zbyt mała do wydajnej transmisji. Zdarza się to w sieciach, które mają ograniczoną przepustowość albo powolne łącza. Rozwiązaniem jest zwiększenie rozmiaru bufora, lecz istnieje w tej kwestii ograniczenie narzucone przez maksymalny rozmiar okna, jaki dopuszcza protokół. W takiej sytuacji określa się sieć jako sieć LFN (Long Fat Network). TCP systemu Windows 2000 dopuszcza większy rozmiar okna, niż jego poprzednie implementacje. Wskazówka: LFN może być akronimem od Long Fat Network, albo Long File Name (długa nazwa pliku). Akronim ten w przypadku Long File Name wymawia się el-ef-en. W przypadku Long Fat Network wymawia się go elephant. Elephant y omówione są w specyfikacji RFC Jednym z ważnych czynników rządzących przepływem informacji poprzez sieć jest okres czasu, przez jaki host wysyłający czeka na potwierdzenie, zanim założy, że dane uległy zagubieniu i dokona ponownej ich transmisji. Jeżeli okres ten jest zbyt krótki, to pakiety są niepotrzebnie retransmitowane; jeżeli jest on zbyt długi, to dane połączenie będzie stało bezczynnie, podczas gdy host będzie czekał, dopóki okres nie minie. TCP podejmuje próbę ustalenia optymalnego okresu wygaśnięcia poprzez monitorowanie normalnej wymiany pakietów danych. Proces ten zwany jest szacowaniem czasu przewidzianego na transmisję i potwierdzenie przyjęcia (RTT). TCP systemu Windows 2000 zapewnia udoskonalony algorytm RTT, wykorzystujący znaczniki czasu. Zostało to opisane w dalszej części tego rozdziału. Okna przesuwne TCP TCP implementuje kontrolę przepływu danych przez zastosowanie algorytmów okna przesuwnego, umożliwiających jednoczesny transport wielu pakietów danych. Algorytmy te umieszczają bufory pomiędzy programami użytkowymi a sieciowym przepływem danych. Dane otrzymywane z sieci zapamiętywane są w buforze, a aplikacja odczytuje te dane, zwalniając przestrzeń bufora w celu przyjęcia większej ilości danych z sieci. Okno, to ilość danych, która może być odczytywana z wyprzedzeniem i jest ono równe rozmiarowi bufora minus ilość ważnych danych, które są w nim zapamiętane. Jeżeli rozmiar okna jest większy niż rozmiar pakietów, to może być transmitowanych wiele pakietów, ponieważ nadawca wie, że u odbiorcy dostępna jest przestrzeń bufora potrzebna, aby je pomieścić. Najlepiej, kiedy zostanie osiągnięty warunek stanu stabilnego, gdzie aplikacja odczytuje dane z bufora w takim samym tempie, w jakim nadawca dodaje do niego dane. W takim wypadku można sobie wyobrazić bufor jako okno, które przesuwa się spokojnie wzdłuż strumienia danych, utrzymując w ruchu szereg pakietów i zapewniając wydajne wykorzystanie zasobów sieci. Każdy z hostów TCP ma dwa bufory, jeden do odbierania danych i jeden do ich wysyłania. Rozmiar okien odbioru i wysyłania jest ustawiany podczas uzgadniania trzystopniowego. Zostało to omówione w dalszej części tego rozdziału.

4 Gniazda i porty TCP TCP implementuje połączenia pomiędzy hostami przy użyciu gniazd i portów. Gniazdo to węzeł końcowy komunikacji sieciowej i może ono być aktywne, albo pasywne. Gniazdo aktywne łączy się ze zdalnym gniazdem aktywnym poprzez otwarte łącze do transmisji danych. Kiedy połączenie zostanie zerwane, niszczy to gniazdo aktywne w obu węzłach końcowych. Gniazdo pasywne nie zostaje podłączone, lecz zamiast tego czeka na połączenie przychodzące, które da początek nowemu gniazdu aktywnemu. Gniazdo związane jest z portem relacją typu wielu do jednego. Każdy z portów może mieć pojedyncze gniazdo pasywne, oczekujące na połączenia przychodzące oraz kilka gniazd aktywnych, z których każde pokrywa się z połączeniem otwartym w porcie. Gniazdo jest węzłem końcowym w komunikacji sieciowej (podobnym do uchwytu pliku) i tworzy się je poprzez określenie adresu IP jego hosta, typu usługi (TCP lub UDP), oraz wykorzystywanego numeru portu. Wszystkie połączenia TCP są jednoznacznie identyfikowane za pomocą dwóch gniazd to jest dwóch par adresów IP i portów TCP (jedna dla hosta wysyłającego i jedna dla hosta odbierającego). Programy TCP wykorzystują zarezerwowane, albo dobrze znane, numery portów. Każdy program po stronie serwera, który wykorzystuje porty TCP, nasłuchuje komunikatów przychodzących pod dobrze znany numer portu. Wszystkie numery portów serwerów TCP o wartościach mniejszych niż 1024 (oraz niektóre wyższe numery) są zarezerwowane i zarejestrowane przez organizację przydzielania numerów internetowych (IANA). Tabela 7.1 podaje dobrze znane porty serwera TCP, wykorzystywane przez standardowe programy oparte na TCP. Nie jest to lista wyłączna, ale zawiera najczęściej używane porty. Wskazówka: Pełna lista aktualnie zarejestrowanych dobrze znanych portów TCP dostępna jest pod adresem Tabela 7.1. Porty serwerów TCP Numer portu TCP Opis 20 Serwer protokołu transmisji plików (FTP) (kanał danych) 21 Serwer FTP (kanał kontrolny) 23 Serwer Telnet 25 Serwer protokołu prostego transferu poczty elektronicznej (SMTP) 53 Transfery strefy systemu nazw domen (DNS) 80 Serwer WWW protokołu transmisji hipertekstu (HTTP) 110 Serwer protokołu odbierania poczty wersji 3 (POP3) 139 Usługa sesji NetBIOS Trzystopniowe uzgadnianie TCP TCP ustanawia połączenia za pomocą mechanizmu uzgadniania opartego na numerach sekwencji. Każde z połączeń wymaga numeru sekwencji wysyłania i numeru sekwencji odbioru. Początkowy

5 numer sekwencji wysyłania (ISS) jest bieżącym numerem sekwencji inicjującego hosta TCP, a początkowy numer sekwencji odbioru (IRS) jest bieżącym numerem sekwencji docelowego hosta TCP. Aby mogło zostać ustanowione połączenie, TCP musi zsynchronizować numery sekwencji wysyłania i odbioru. Odbywa się to przy użyciu bitu kontrolnego synchronizacji (SYN) oraz początkowych numerów sekwencji (ISN-ów). Komunikat SYN (komunikat, który ma ustawiony bit SYN) jest potwierdzany przez komunikat ACK (komunikat, który ma ustawiony znacznik ACK lub znacznik potwierdzenia). Cała procedura znana jest jako trzystopniowe uzgadnianie TCP i działa w następujący sposób: 1. Host A wysyła komunikat SYN do Hosta B. Komunikat ten zawiera numer sekwencji Hosta A (ISS). 2. Host B wysyła komunikat ACK z ISS powiększonym o jeden. Komunikat ten ma również ustawiony znacznik SYN i zawiera numer sekwencji Hosta B (IRS). 3. Host A potwierdza komunikat SYN Hosta B przy użyciu komunikatu ACK z IRS zwiększonym o jeden i pustym polem danych. Zauważ, że kiedy Host A zaczyna wysyłać dane, to nie zwiększa się numer sekwencji Hosta B na skutek tego komunikatu. Komunikaty ACK, które nie zawierają danych, nie powodują zwiększenia przez odbiorcę numeru sekwencji nadawcy. Rysunek 7.1 przedstawia trzystopniowe uzgadnianie TCP. ISN 1000 (ISS) ISN 2000 (IRS) Host A SEQ=1000 CTL=SYN Host B SEQ=2000 ACK=1001 CTL=SYN, ACK SEQ=1001 ACK=2001 CTL=ACK Rysunek 7.1. Trzystopniowe uzgadnianie TCP Zaletą trzystopniowego uzgadniania TCP jest to, że Host A może sprawdzić, czy potwierdzenie wysłane przez Hosta B zawiera spodziewany numer sekwencji. Jest możliwe, przy powolnej i zawodnej sieci złożonej (takiej jak Internet), że Host B mógł otrzymać część starego komunikatu, który został wysłany przez Hosta A i jest rozsynchronizowany. W takim przypadku ACK Hosta B zawierałoby błędny numer sekwencji, a połączenie nie zostałoby ustanowione. Host A wysłałby komunikat z ustawionym znacznikiem resetowania (RST), który przywróciłby Hosta B do stanu nasłuchiwania.

6 Trzystopniowe uzgadnianie TCP jest potrzebne, ponieważ protokół nie nakłada żadnego ograniczenia, aby określone połączenie nie miało być wykorzystane więcej niż jeden raz. Nowe egzemplarze połączenia określane są jako wcielenia i czasami mogą być wysyłane powtórzone komunikaty z poprzednich wcieleń, szczególnie jeżeli połączenie zostanie szybko otworzone, zamknięte i ponownie otworzone w krótkich odstępach czasu, albo jeżeli połączenie zostanie zerwane z utratą pamięci, a następnie zostanie ponownie ustanowione. Trzystopniowe uzgadnianie gwarantuje, że ustanawiane są ważne połączenia, nawet jeśli dany host TCP ulegnie awarii i straci całą wiedzę dotyczącą numerów sekwencji, których używał. Pojęcie czasu ciszy TCP W momencie włączenia zasilania, albo podczas powrotu do normalnego stanu po awarii, w wyniku której zostały utracone informacje dotyczące numerowania sekwencji, TCP siedzi cicho (tzn. nie przydziela żadnych numerów sekwencji) przez interwał równy maksymalnemu okresowi istnienia segmentu (MSL). Gwarantuje to, że nie zostanie utworzony segment niosący numer sekwencji podwojony przez stary segment pozostający w sieci. RFC 793 określa MSL wynoszący dwie minuty. Czasami połączenie może być zainicjowane z dwóch hostów naraz. W takim wypadku Host A wysyła pakiet SYN do Hosta B, ale zamiast otrzymać pakiet z ustawionym ACK oraz SYN, otrzymuje inicjujący pakiet SYN Hosta B. Jeżeli tak się dzieje, to Host A ponownie wysyła swój pierwotny pakiet SYN i trzystopniowe uzgadnianie przebiega tak, jak wcześniej. TCP wykorzystuje podobny proces uzgadniania przed zamknięciem połączenia. Sprawdza on, czy oba hosty zakończyły wysyłanie i odbieranie danych. Niezawodny przesył danych Kiedy zostanie ustanowione połączenie, TCP może przesyłać nieprzerwany strumień danych w obu kierunkach. Dane pakowane są w segmenty, a TCP w hostach wysyłających i odbierających decyduje, kiedy blokować, a kiedy przekazywać dane. TCP musi być w stanie powrócić do normalnego stanu po wystąpieniu sytuacji, w toku których dane uległy uszkodzeniu, utracie, podwojeniu lub zostały dostarczone nie po kolei. Uzyskuje się to poprzez przydzielanie numeru sekwencji w momencie ustanowienia połączenia, zwiększanie go o jeden dla każdego oktetu przetransmitowanych danych, oraz przez wymaganie pozytywnego potwierdzenia (ACK), zawierającego informacje dotyczące numeru sekwencji od odbierającego hosta TCP. Jeżeli ACK nie zostanie otrzymane w granicach określonego czasu, dane są ponownie transmitowane. W hoście odbierającym, numery sekwencji wykorzystywane są do ponownego składania segmentów w kolejności, w jakiej zostały wysłane oraz do eliminowania powtórzeń. Uszkadzaniu danych zapobiega się poprzez obliczanie sumy kontrolnej dla każdego z transmitowanych segmentów, sprawdzanie tej sumy kontrolnej u odbiorcy, odrzucanie uszkodzonych segmentów oraz przez wymaganie ponownej transmisji uszkodzonych danych. W ten sposób TCP gwarantuje, że błędy transmisji nie uniemożliwią właściwego dostarczania danych i że komunikacja sieciowa będzie mogła wrócić do normalnego stanu po błędach systemu łączności.

7 Zamykanie połączenia TCP Host TCP zamyka połączenie poprzez wysłanie pakietu TCP z ustawionym znacznikiem FIN. Łączność TCP jest dwukierunkowa (dupleksowa) i host, który zamyka połączenie, informuje swojego hosta równorzędnego, że nie ma już żadnych danych do wysłania. Może on nadal otrzymywać dane poprzez połączenie, dopóki jego host równorzędny również nie wyśle pakietu zamykającego FIN. Zważywszy, że Host A i Host B biorą udział w dwukierunkowym ruchu TCP, mamy trzy możliwe scenariusze. Host A inicjuje zamknięcie W tym przypadku Host A umieszcza segment FIN w kolejce segmentów wychodzących. Nie będą przyjmowane przez TCP żadne dalsze transmisje (SEND-y) od Hosta A, a Host A wchodzi w stan FIN-WAIT-1, w którym dozwolone są przychodzące segmenty danych (RECEIVE). Jeżeli to konieczne, wszystkie segmenty poprzedzające i zawierające segment FIN będą retransmitowane dopóki nie zostaną potwierdzone. Kiedy Host B potwierdzi segment FIN Hosta A i wyśle własny FIN, Host A dokona transmisji segmentu ACK, aby potwierdzić ów FIN. Host B otrzyma ten segment ACK i połączenie zostanie zamknięte. Host A otrzymuje segment FIN W tym przypadku Host A odbiera niezapowiedziany segment FIN od Hosta B. Host A ACK-uje FIN (cudowna terminologia), który mówi Hostowi B, że połączenie jest zamykane. Wtedy Host A wysyła wszystkie pozostałe dane do Hosta B, a następnie wyśle instrukcję FIN. Z kolei Host B ACK-uje FIN Hosta A i połączenie zostaje zamknięte. Obydwa hosty zamykają równocześnie W tym przypadku hosty A i B wymieniają segmenty FIN. Kiedy wszystkie segmenty poprzedzające FIN-y zostaną przetworzone i potwierdzone, każdy z hostów może, za pomocą ACK, potwierdzić FIN, który otrzymał. W momencie otrzymania tych ACK-ów oba hosty usuwają połączenie. Struktura pakietów TCP Pakiet (lub segment) TCP jest kapsułowany za pomocą nagłówka IP, który określa informacje dotyczące routingu IP, takie jak adres docelowy i źródłowy datagramu, co przedstawia rysunek 7.2. Ten rysunek ukazuje pakiet TCP SYN, wykorzystywany do inicjacji trzystopniowego uzgadniania TCP. Ponieważ ta struktura pakietowa nie zawiera żadnych danych, ukazuje ona również strukturę nagłówka TCP. Rysunek 7.2. Pakiet TCP SYN Wskazówka: Rysunek 7.2 przedstawia pakiet z pliku ftp.cap Monitora sieci, dostępnego na CD- ROM. Pakiet TCP zawiera kilka pól, opisanych na stronie???.

8 Port źródłowy To 16-bitowe pole zawiera numer portu źródłowego. Port docelowy To 16-bitowe pole zawiera numer portu docelowego. Gdyby przykładowo, pakiet SYN inicjował połączenie, które miałoby być wykorzystywane przez FTP, to wartość w tym polu byłaby 0x0015 (21 dziesiętne). Numer sekwencji To 32-bitowe pole zawiera albo ISN (w przypadku pakietu SYN), albo numer sekwencji pierwszego oktetu danych w segmencie. Numer potwierdzenia To 32-bitowe pole zawiera wartość następnego numeru sekwencji, który spodziewa się otrzymać nadawca segmentu. W inicjującym pakiecie SYN, w którym nie jest ustawiony znacznik ACK, wartość tego pola wynosi zero. Wyrównanie danych To 4-bitowe pole zawiera wartość równą liczbie słów 32-bitowych w nagłówku TCP i wskazuje, gdzie zaczynają się dane TCP. Nagłówek TCP ma zawsze długość liczby całkowitej słów 32- bitowych. Zarezerwowane To 6-bitowe pole zarezerwowane jest do przyszłego wykorzystania i jest ustawione na zero. Bity kontrolne To pole zawiera sześć jednobitowych znaczników. Począwszy od bitu najbardziej znaczącego, są to: URG wskazuje, czy transmitowane są dane pilne. Jeżeli ten znacznik jest ustawiony to pole Pilny wskaźnik (patrz poniżej) wskazuje na koniec danych pilnych w segmencie. ACK wskazuje, czy jest wysyłane potwierdzenie. Ten znacznik jest zazwyczaj ustawiony, poza początkowymi pakietami SYN. Jeżeli ten znacznik nie jest ustawiony, to wartość w polu Potwierdzenie wynosi zero. PSH wskazuje, że dane w pakiecie powinny zostać przepchnięte do hosta odbierającego. Jeżeli ten znacznik jest ustawiony, to TCP niezwłocznie przekaże i dostarczy dane. RST resetuje połączenie i przywraca hosta odbierającego do stanu nasłuchu. Przeważnie znacznik ten jest ustawiony, kiedy stary, podwojony komunikat przez pomyłkę zainicjuje proces uzgadniania. SYN synchronizuje numery sekwencji. Ten znacznik jest wykorzystywany podczas trzystopniowego uzgadniania TCP. FIN wskazuje, że nie ma już więcej danych od nadawcy.

9 Okno To 16-bitowe pole określa liczbę oktetów danych, począwszy od oktetu wskazanego w polu Potwierdzenie, które nadawca tego segmentu jest gotów przyjąć. Hosty TCP optymalizują wydajność transmisji poprzez negocjowanie rozmiarów okna. Suma kontrolna To 16-bitowe pole zawiera wartość sumy kontrolnej, obliczaną w sposób opisany wcześniej w niniejszym rozdziale. Pilny wskaźnik Jeżeli pakiet zawiera dane pilne i jest ustawiony znacznik URG, to 16-bitowe pole zawiera bieżącą wartość Pilnego wskaźnika. Wskazuje ona numer sekwencji oktetu, który następuje po danych pilnych i jest utrzymywana jako wyrównanie pozytywne numeru sekwencji w segmencie. Opcje Długość tego pola jest zmienna w zależności od tego, które opcje (jeżeli w ogóle) zostaną określone, ale jest zawsze wielokrotnością 8 bitów. Opcja może się zaczynać na dowolnej granicy obszaru. Opcja może wymagać tylko jednego oktetu, określającego rodzaj opcji. Ewentualnie może ona wymagać kilku oktetów, które zawierają wartości dla rodzaju opcji, długości opcji oraz dane zawarte w opcji. W skład standardowych opcji TCP wchodzą: Koniec listy opcji wskazuje koniec listy opcji, a nie koniec każdej z opcji. Ta opcja wymaga pojedynczego oktetu, zawierającego wartość rodzaju opcji wynoszącą 0. Jest ona wykorzystywana tylko, gdyby koniec opcji nie miał w przeciwnym razie zbiec się z końcem nagłówka TCP. Bezczynność wykorzystywana pomiędzy opcjami do wyrównywania początku późniejszej opcji do granicy słowa 32-bitowego. Opcja ta wymaga pojedynczego oktetu, zawierającego wartość rodzaju opcji wynoszącą 1. Nie wszyscy nadawcy wykorzystują tę opcję, a odbiorcy muszą być zdolni do przetwarzania opcji, nawet jeżeli nie zaczynają się one na granicy słowa. Maksymalny rozmiar segmentu określa maksymalny rozmiar segmentu odbioru u hosta TCP, który wysyła ten segment. Ta opcja wymaga czterech oktetów, zawierających wartość rodzaju opcji wynoszącą 2, wartość długości opcji wynoszącą 4 oraz dane dotyczące rozmiaru segmentu (dwa oktety). Maksymalny rozmiar segmentu określany jest tylko w segmentach SYN inicjujących trzystopniowe uzgadnianie (takich jak przedstawione na rysunku 7.1). Jeżeli ta opcja nie jest wykorzystywana, dozwolony jest dowolny rozmiar segmentu. Opcja SACK dozwolone (rodzaj opcji 4, długość opcji 2) jest omówiona w dalszej części niniejszego rozdziału. Wypełnienie Wypełnienie nagłówka TCP jest wykorzystywane, aby zagwarantować, że nagłówek kończy się, a dane zaczynają na 32-bitowej granicy. Pole wypełnienia ma wszystkie oktety ustawione na zero.

10 Wskazówka: Pola Opcje oraz Wypełnienie są czasem połączone w pole Opcje i wypełnienie. Udoskonalony protokół TCP firmy Microsoft Firma Microsoft przepisała stos TCP/IP i wprowadziła znaczące udoskonalenia do zestawu funkcji TCP. Nie wszystkie udoskonalenia opisane poniżej były wprowadzone w systemie Windows 2000, ale stos TCP/IP systemu Windows 2000 implementuje wszystkie (nie zawsze domyślnie). Rozładowanie sumy kontrolnej Wersja 5 specyfikacji interfejsu sterownika sieciowego (NDIS5) obsługuje rozładowywanie zadań (patrz: rozdział 1), a TCP systemu Windows 2000 wykorzystuje to rozładowując obliczenia sumy kontrolnej TCP do karty sieciowej (NIC), przy założeniu, że sterownik karty sieciowej obsługuje tę funkcję. Może to prowadzić do poprawy wydajności w środowiskach o bardzo wysokiej przepustowości. Generowanie początkowego numeru sekwencji Protokół TCP systemu Windows 2000 został zahartowany na okoliczność takich ataków, jak spoofing (wysyłanie fałszywych komunikatów). Jako część tego procesu, algorytm generowania ISN został zmodyfikowany w taki sposób, aby ISN-om przybyło losowych przyrostów, za pomocą opartego na RC4 generatora numerów inicjalizowanego 2048-bitowym kluczem przy uruchamianiu. Wskazówka: RC4 jest algorytmem Rivest-Sharmir-Adelman (RSA). Aby uzyskać więcej informacji na ten oraz na inne tematy związane z zabezpieczeniami, wejdź na stronę główną RSA pod adresem Rozmiar okna odbierania TCP Rozmiar okna odbierania TCP to ilość odbieranych danych (w bajtach), która może być jednorazowo buforowana w danym połączeniu to jest ilość danych, które host transmitujący wysyła przed oczekiwaniem na potwierdzenie (i prawdopodobnie na nowy rozmiar okna) od hosta odbierającego. TCP systemu Windows 2000 używa większych domyślnych rozmiarów okna, niż wcześniejsze wersje systemu Windows i dopasowuje rozmiar okna do parzystych przyrostów maksymalnego rozmiaru segmentu (MSS), który jest negocjowany podczas ustawiania połączenia. Zwiększa to odsetek segmentów TCP naturalnej wielkości, wykorzystywanych podczas transmisji dużej ilości danych. Domyślny rozmiar okna odbierania jest obliczany, a nie zakodowany sprzętowo. Wartość ta obliczana jest w następujący sposób: 1. Pierwsze żądanie połączenia wysłane do hosta zdalnego ogłasza rozmiar okna odbierania równy 16 KB (16 384). 2. Kiedy połączenie zostanie ustanowione, rozmiar okna odbierania zostaje zaokrąglony do parzystego przyrostu maksymalnego rozmiaru segmentu TCP (MSS), który został wynegocjowany podczas ustawiania połączenia.

11 3. Jeżeli nie jest ona co najmniej czterokrotnym rozmiarem MSS, zostaje dostosowana do tej wartości. Maksymalny rozmiar okna odbierania wynosi 64 KB, chyba że włączona jest opcja skalowania okna określona w dokumencie RFC W przypadku Ethernetu okno jest zazwyczaj ustawione na bajtów (16 KB zaokrąglone do dwunastu 1460-bajtowych segmentów.). Rozmiar okna odbierania może być ustawiany na określoną wartość przy użyciu parametru Rejstru TcpWindowSize. Parametr ten może być określany albo dla wszystkich interfejsów albo osobno dla każdego interfejsu. Funkcja setsockopt interfejsu Windows Sockets (Winsock) ustawia rozmiar okna odbierania osobno dla każdego interfejsu. Korzystanie z TcpWindowSize opisane jest w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału. Funkcje Winsock są opisane w rozdziale 16. Wskazówka: Zmiana parametru Rejestru GlobalMaxTcpWindowSize nie zmienia koniecznie rozmiaru okna odbierania na wszystkich interfejsach. Parametr ten jest współczynnikiem przy obliczaniu domyślnego rozmiaru okna (patrz: dodatek A). Skalowanie okna według specyfikacji RFC RFC 1323 określa metodę obsługiwania okien skalowalnych, poprzez umożliwienie TCP negocjowania współczynnika rozmiaru okna, w momencie ustanawiania połączenia. Pozwala to na faktyczny rozmiar okna odbierania do 1 GB, co poprawia wydajność w szerokopasmowych sieciach o dużych opóźnieniach. Opcja Skalowanie okna, o ile jest włączona, pojawia się w części Opcje TCP segmentu TCP SYN jako rodzaj opcji 3, długość opcji 3, współczynnik skalowania. Wskazuje ona, że transmitujący host TCP jest gotowy do skalowania zarówno okna wysyłania, jak i odbierania, oraz określa współczynnik skalowania, który może być zastosowany wobec jego okna odbierania. Współczynnik skalowania wyrażany jest jako potęga liczby dwa zakodowana logarytmicznie, aby mogła być implementowana za pomocą operacji przesunięcia binarnego. Na przykład faktor skali równy cztery zapewnia możliwe skalowanie okna wynoszące 2 4, lub 16, implementowane przez 4- bajtowe przesunięcie wartości w polu Okno. Przypuśćmy, że pole Okno zawiera: (17,520) to faktor skali dawałby możliwy rozmiar okna o wartości: (280,320) Host TCP, który jest gotowy do skalowania okien, powinien wysyłać opcję Skala okna, nawet jeśli jego własny współczynnik skali wynosi 0. Współczynnik skali równy 0 daje skalowanie okna wynoszące 2 0, albo 1. Obydwa hosty muszą wysyłać swoje opcje Skali okna w swoich segmentach SYN, aby umożliwić skalowanie okna w obu kierunkach. Współczynnik skali nie musi być symetryczny i może być różny dla każdego kierunku przepływu danych. Opcja może być wysyłana w początkowym segmencie SYN. Może ona być również wysyłana w segmencie SYN, ACK, ale tylko jeżeli w początkowym segmencie SYN została otrzymana opcja Skala okna. Pole Okno w segmencie SYN nie jest nigdy skalowane. Skalowanie okna implementowane jest w systemie Windows 2000, jeżeli TcpWindowSize jest ustawione na wartość większą niż 64, a parametr Rejestru Tcp1323Opts jest ustawiony albo na 1, albo na 3 (patrz: dodatek A). Domyślnie Tcp1323Opt ustawiony jest na 0, a Skalowanie okna jest wyłączone. Procedura uruchamiania Skalowania okna została opisana w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału.

12 Potwierdzenia opóźnione TCP wykorzystuje potwierdzenia opóźnione (ACK) do obniżania liczby wysyłanych pakietów. Kiedy w połączeniu TCP zostaną odebrane dane, to stos firmy Microsoft zwróci ACK tylko jeśli został spełniony jeden z następujących warunków: Nie zostało wysłane żadne ACK dla poprzedniego otrzymanego segmentu. Segment został odebrany, ale przez połączenie nie nadejdą żadne dalsze segmenty przez okres 200 milisekund. W rezultacie ACK wysyłane jest dla co drugiego segmentu TCP odebranego poprzez połączenie, chyba że straci ważność czasomierz potwierdzeń opóźnionych (domyślnie ustawiony na 200 milisekund). Czasomierz ten można ustawiać przy użyciu parametru Rejestru TcpDelAckTick. Potwierdzenia opóźnione określone są w dokumencie RFC Potwierdzenie selektywne System Windows 2000 wprowadza obsługę SACK. Opcja ta jest szczególnie korzystna w przypadku połączeń, które stosują duże rozmiary okien TCP. Przed wprowadzeniem SACK, odbiorca mógł potwierdzić tylko ostatni numer sekwencji przyległych danych odebranych, albo lewą krawędź okna odbierania. Jeżeli jest włączony SACK, to odbiorca może również indywidualnie potwierdzać inne bloki odebranych danych. SACK korzysta z opcji nagłówka TCP, co przedstawione jest poniżej. Opcja SACK dozwolone (rodzaj opcji 4, długość opcji 2) może być wysyłana w pakiecie SYN przez hosta TCP, który może obierać i przetwarzać potwierdzenia selektywne, kiedy połączenie zostanie otwarte. Nie wolno przesyłać opcji SACK dozwolone w segmentach innych niż SYN. Opcja SACK (rodzaj opcji 5, długość opcji zmienna) przekazuje rozszerzone informacje dotyczące potwierdzeń od nadawcy do odbiorcy. Jej pola danych identyfikują lewą krawędź pierwszego bloku danych, prawą krawędź pierwszego bloku danych, lewą krawędź drugiego bloku danych i tak dalej, aż do prawej krawędzi ostatniego bloku danych w segmencie. Gdy SACK jest włączone (ustawienie domyślne systemu Windows 2000), to odbiorca może informować nadawcę, które bloki danych zostały otrzymane oraz gdzie są luki w danych, jeżeli jakiś pakiet (albo szereg pakietów) został zgubiony. Wtedy nadawca retransmituje brakujące dane, ale nie retransmituje bloków danych, które zostały pomyślnie odebrane. SACK kontrolowany jest przez parametr Rejestru SackOpts, który domyślnie ustawiony jest na 1 (prawda). SACK jest określony w specyfikacji RFC Znaczniki czasu System Windows 2000 wprowadza obsługę znaczników czasu TCP, które (podobnie jak SACK) są korzystne przy połączeniach stosujących duże rozmiary okien. Znaczniki czasu wykorzystywane są do pomiaru RTT oraz do ustawiania przeterminowania retransmisji. Opcja znaczników czasu (rodzaj opcji 8, długość opcji 10) zawiera dwa 4-bajtowe pola danych. Pole Wartość znacznika czasu (TSval) zawiera bieżącą wartość zegara znaczników czasu hosta transmitującego. Pole Odpowiedź potwierdzenia znacznika czasu (Tsecr) potwierdza wartość znacznika czasu, która została wysłana przez równorzędnego hosta TCP w polu TSval. Tsecr jest ważna tylko, jeżeli ustawiony jest bit ACK w nagłówku TCP; w przeciwnym razie jego wartość

13 musi być równa zero. Wartość Tsecr będzie (ogólnie rzecz biorąc) pochodziła z ostatniej otrzymanej opcji znaczników czasu. Host TCP może wysyłać opcję znaczników czasu w początkowym segmencie SYN. Może on wysyłać opcję w innych segmentach tylko jeżeli otrzymał znacznik czasu w początkowym segmencie SYN dla połączenia. Opcja znaczników czasu jest domyślnie wyłączona. Ustawienie parametru Rejestru Tcp1323Opts (normalnie zero) na 2 albo na 3 włącza opcję. Procedura ta opisana jest w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału. Dokument RFC 1323 określa korzystanie ze znaczników czasu oraz z opcji Znaczniki czasu. Odkrywanie maksymalnej jednostki transmisyjnej ścieżki (PMTU) Po ustanowieniu połączenia hosty TCP wymieniają swoje wartości MSS i przy połączeniu wykorzystywana jest mniejsza z tych wartości. Tradycyjnie MTU to wynegocjowany MSS plus 40 bajtów na nagłówki IP i TCP. Jednakże obsługa dodatkowych opcji TCP, takich jak znaczniki czasu, zwiększyła typowy rozmiar tych dwóch nagłówków do łącznego rozmiaru 52 i więcej bajtów, co z kolei zwiększa rozmiar MTU. Gdy segmenty TCP wysyłane są do sieci nielokalnej, to w nagłówku IP ustawiony zostaje znacznik Nie fragmentować (DF). Każdy router albo nośnik na ścieżce może mieć MTU, która różni się od MTU tych dwóch hostów. Jeżeli jakiś segment nośnika albo router na ścieżce ma MTU, która jest zbyt mała, aby datagram IP mógł być routowany, to router podejmuje próbę fragmentacji datagramu, ale wykrywa, że ustawiony jest znacznik DF. W tym momencie router powinien wysłać komunikat niedostępnego miejsca docelowego ICMP, aby poinformować hosta transmitującego, że datagram nie może być przekazany dalej bez fragmentacji. Większość routerów określa również MTU dozwoloną dla następnego przeskoku poprzez umieszczenie jej wartości w 16 bitach mniej znaczących nieużywanego pola nagłówka ICMP (aby poznać szczegóły, odwołaj się do specyfikacji RFC 1191). W momencie otrzymania tego komunikatu ICMP o błędzie, transmitujący host TCP ustawia swój MSS (a w związku z tym swoją MTU), aby wszystkie dalsze pakiety wysyłane poprzez połączenie mogły przemierzać ścieżkę bez fragmentacji. Minimalna dozwolona MTU wynosi 68 bajtów. Niektóre niezgodne routery (albo routery czarnej dziury) dyskretnie gubią te datagramy IP, których nie można sfragmentować, albo nie zgłaszają poprawnie ich jednostki MTU następnego przeskoku. W tym wypadku można zrekonfigurować algorytm wykrywania PMTU w systemie Windows 2000, aby obejść problem. Dostępne są dwa parametry Rejestru: EnablePMTUBHDetect ustawienie tego parametru na 1 (prawda) rozkazuje algorytmowi odkrywania PMTU podjąć próbę wykrycia routerów czarnej dziury. Wykrywanie routerów czarnej dziury jest domyślnie wyłączone. EnablePMTUDiscovery ustawienie tego parametru na 0 (fałsz) wyłącza mechanizm wykrywania PMTU. Kiedy wykrywanie PMTU jest wyłączone, to dla wszystkich adresów zdalnego miejsca docelowego wykorzystywany jest MSS o wielkości 536 bajtów. Wykrywanie PMTU jest domyślnie włączone. PMTU pomiędzy dwoma hostami można odkryć ręcznie, przy użyciu polecenia ping z przełącznikiem f (nie fragmentować). Technika ta może również wykrywać routery czarnej

14 dziury i jest opisana w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału. Odkrywanie PMTU jest opisane w specyfikacji RFC Wykrywanie martwych bram Wykrywanie martwych bram pozwala hostowi TCP na wykrywanie awarii bramy domyślnej oraz dostosowywanie tablicy tras IP w taki sposób, aby zastosowana została inna brama domyślna. Stos Microsoft 2000 wykorzystuje metodę reselekcji wyzwalanej (określoną w specyfikacji RFC 816) z nieznacznymi modyfikacjami opartymi na reakcjach klientów. Kiedy połączenie TCP kilkakrotnie podejmie próbę wysłania pakietu TCP do miejsca docelowego poprzez bramę domyślną i nie otrzyma odpowiedzi, algorytm zmienia pozycję pamięci podręcznej tras (RCE) dla tego zdalnego adresu IP, aby używać następnej bramy domyślnej na liście. Liczba prób transmisji podejmowanych zanim będzie to miało miejsce, jest równa połowie wartości określonej w parametrze Rejestru TcpMaxData-Retransmissionss. Kiedy 25 procent połączeń TCP przeniesie się do następnej bramy domyślnej, algorytm zmienia bramę domyślną komputera na tę, której aktualnie używają połączenia. Jeżeli druga brama domyślna również doświadcza problemów, algorytm wypróbowuje następną na liście. Kiedy poszukiwania osiągną ostatnią bramę domyślną, algorytm powraca do początku listy. Jeżeli brama pomyślnie transmituje pakiety, to pozostanie bramą domyślną aż do ponownej inicjalizacji komputera. Retransmisja TCP włącza czasomierz retransmisji, kiedy każdy segment wychodzący jest przekazywany do IP. Jeżeli przed przeterminowaniem czasomierza nie zostanie otrzymane potwierdzenie, segment jest ponownie transmitowany. W przypadku żądań nowego połączenia, czasomierz zostaje ustawiony na 3 sekundy. Ta wartość domyślna może być zmieniana osobno dla każdej karty poprzez zmianę parametru Rejestru TcpInitialRTT. Jeżeli segment żądania (SYN) nie zostanie potwierdzony, zostaje ponownie wysłany maksymalnie do dwóch razy w trybie domyślnym. Aby to zmienić, można zastosować parametr Rejestru TcpMaxConnectRetransmissions. W przypadku istniejących połączeń, liczba retransmisji kontrolowana jest przez parametr TcpMaxDataRetransmissions, który jest domyślnie ustawiony na pięć. Przeterminowanie retransmisji dostosowywane jest do charakterystyki połączenia przy użyciu obliczeń wygładzonego czasu przewidzianego na transmisję i potwierdzenie przyjęcia (SRTT) (w kwestii szczegółów odwołaj się do dokumentu RFC 793). Czasomierz dla każdego segmentu zostaje podwojony po każdej z retransmisji. Ten algorytm umożliwia TCP dostrojenie się do normalnego opóźnienia połączenia. Czasami TCP dokonuje ponownej transmisji danych, zanim przeterminuje się czasomierz retransmisji. Najczęściej występuje to z powodu funkcji szybkiej retransmisji. Kiedy odbiorca obsługujący szybką retransmisję otrzyma dane, które mają numer sekwencji wykraczający poza oczekiwany, to zakłada, że dane te uległy zagubieniu. W tym przypadku odbiorca wysyła ACK z numerem ACK ustawionym na numer sekwencji, którego się spodziewał. Robi to później w przypadku każdego dodatkowego segmentu TCP zawierającego dane następujące po brakujących danych w strumieniu przychodzącym. Kiedy nadawca otrzyma strumień ACK-ów potwierdzających ten sam numer sekwencji i numer ten jest wcześniejszy niż aktualnie wysyłany numer sekwencji, to wyciąga wniosek, że jeden lub

15 więcej segmentów uległ zagubieniu. Jeżeli obsługiwany jest algorytm szybkiej retransmisji, to transmitujący host TCP natychmiast ponownie wysyła segment, którego oczekuje odbiorca, nie czekając na przeterminowanie czasomierza retransmisji. Poprawia to wydajność w niepewnym środowisku sieciowym. System Windows 2000 w sposób domyślny ponownie wysyła dany segment, jeżeli otrzyma trzy potwierdzenia (ACK) dla tego samego numeru sekwencji i jeżeli numer ten pozostaje w tyle za bieżącym numerem. Liczba ACK-ów ustawiona jest w parametrze Rejestru TcpMaxDupAcks. Pakiety keep-alive Pakiet TCP keep-alive to ACK, które ma numer sekwencji ustawiony na o jeden mniejszy niż bieżący numer sekwencji połączenia. Host TCP, który otrzyma takie ACK, odpowiada za pomocą ACK dla bieżącego numeru sekwencji. Pakiety keep-alive wykorzystywane są do sprawdzania, czy komputer na zdalnym końcu połączenia jest wciąż w trybie online. Okres pomiędzy pakietami keep-alive określany jest przez parametr Rejestru KeepAliveTime, który domyślnie ma wartość milisekund lub dwóch godzin. Jeżeli nie ma odpowiedzi, to pakiet keep-alive powtarzany jest co drugą sekundę (domyślnie). Ten okres czasu kontrolowany jest przez parametr Rejestru KeepAliveInterval. Połączenia NetBIOS przez TCP/IP (NetBT) wysyłają pakiety keep-alive usługi NetBIOS częściej, a w połączeniu NetBIOS nie są zwykle wysyłane żadne pakiety TCP keep-alive. Pakiety TCP keepalive są domyślnie wyłączone, ale aplikacje Winsock mogą wykorzystywać funkcję setsockopt do ich uaktywniania. Algorytm powolnego startu i unikanie przeciążeń Kiedy zostaje ustanowione połączenie, TCP oszacowuje przepustowość połączenia. Aby uniknąć przepełnienia hosta odbierającego lub wszelkich innych urządzeń lub łączy na ścieżce, okno wysyłania jest początkowo ustawione na dwa segmenty TCP. Jeżeli zostanie ono potwierdzone, okno zostaje powiększone do trzech segmentów. Jeżeli zostaną one potwierdzone, okno zostaje powiększone do czterech segmentów i tak dalej, dopóki ilość danych wysyłanych na jedną wiązkę nie osiągnie rozmiaru okna odbierania hosta zdalnego. Od tego momentu algorytm powolnego startu nie jest już używany, a kontrola przepływu danych jest regulowana przez okno odbierania. Jednak przeciążenie może się zdarzyć w połączeniu w dowolnym momencie podczas transmisji. Jeżeli zaczynają mieć miejsce regularne transmisje, to algorytm unikania przeciążeń tymczasowo obniża rozmiar okna wysyłania, a następnie znowu pozwala mu rosnąć do rozmiaru okna odbierania. Powolny start i unikanie przeciążeń zostały określone w specyfikacji RFC Unikanie syndromu głupiego okna Syndrom głupiego okna (SWS) występuje, gdy odbiorca przesuwa prawą krawędź okna protokołu sterowania transmisją (TCP), kiedy tylko ma ono w buforze jakąkolwiek świeżą przestrzeń do otrzymywania danych i kiedy nadawca wykorzystuje każde dodatkowe okno (obojętne jak małe) do wysłania większej ilości danych. Może to doprowadzać do sytuacji, w której ciągle przesyłane są malutkie segmenty danych, pomimo że zarówno nadawca, jak i odbiorca mają dużą przestrzeń całkowitą bufora na potrzeby połączenia.

16 System Windows 2000 implementuje unikanie SWS poprzez nie wysyłanie dodatkowych danych, dopóki odbierający host TCP nie ogłosi rozmiaru okna wystarczającego do wysłania pełnego segmentu TCP. Implementuje on również unikanie SWS na odbierającym końcu połączenia poprzez otwieranie okna odbierania w przyrostach wielkości co najmniej jednego segmentu TCP. SWS jest opisany w specyfikacji RFC Algorytm Nagle Podobnie jak w przypadku unikania SWS, zadaniem algorytmu Nagle jest obniżenie liczby wysyłanych bardzo małych segmentów, szczególnie przez powolne łącza stałe. Algorytm ten umożliwia wysyłanie naraz tylko jednego małego segmentu bez potwierdzenia. Jeżeli zostanie wygenerowanych więcej małych segmentów przed otrzymaniem potwierdzenia dla pierwszego z nich, to segmenty te zostają połączone w jeden większy segment. Segmenty naturalnej wielkości są zawsze transmitowane natychmiastowo, przy założeniu, że dostępne jest wystarczające okno odbierania. Algorytm Nagle jest szczególnie skuteczny w obniżaniu liczby pakietów wysyłanych przez aplikacje interaktywne, takie jak Telnet, poprzez powolne łącza. Aplikacje interfejsu Winsock mogą wyłączać algorytm Nagle dla swoich połączeń poprzez ustawienie opcji gniazda TCP_NODELAY (patrz: rozdział 16). Jednak praktyka ta zwiększa wykorzystanie sieci i powinno się jej unikać, chyba że jest absolutnie konieczna. Algorytmu Nagle nie stosuje się przy połączeniach pseudosieci TCP z powodu wydajności; wyłącza się go również przy połączeniach NetBIOS przez TCP oraz połączeniach typu zwrotnica z hostem bezpośrednim serwer. Może to poprawiać wydajność w przypadku aplikacji wydających dużą liczbę poleceń operowania małymi plikami (na przykład aplikacji, które często używają blokowania/odblokowywania plików). Algorytm Nagle opisany jest w specyfikacji RFC 896. Opóźnienie TIME-WAIT Po zamknięciu połączenia TCP para gniazd zostaje umieszczona w stanie TIME-WAIT. Implementuje to opóźnienie czasowe, zanim nowe połączenie będzie mogło korzystać z tego samego protokołu, źródłowego adresu IP, docelowego adresu IP, portu źródłowego oraz portu docelowego. Opóźnienie to ma na celu zagwarantowanie, że przez nowe połączenie nie zostaną nieoczekiwanie dostarczone żadne błędnie routowane ani opóźnione segmenty. Specyfikacja RFC 793 określa opóźnienie jako dwa MSL-e, lub cztery minuty, co jest ustawieniem domyślnym dla systemu Windows Czasami jednak aplikacje sieciowe wykonujące wiele połączeń wychodzących w krótkim czasie, zużywają wszystkie dostępne porty. W takim przypadku może być wskazane obniżenie opóźnienia TIME-WAIT, aby porty mogły szybciej powracać do obiegu. System Windows 2000 pozwala na dokonywanie ustawień opóźnienia TIME-WAIT przy użyciu parametru Rejestru TcpTimedWaitDelay. Jeżeli jest to konieczne, to opóźnienie może być ustawione na wartość zaledwie 30 sekund. Ponadto liczba portów dostępnych dla użytkowników, które mogą pełnić rolę źródła dla połączeń wychodzących, może być konfigurowana przy użyciu parametru MaxUserPort. Domyślnie numer portu, który ma wartość między 1024 a 5000, określany jest, kiedy dana aplikacja zażąda gniazda, którego mogłaby użyć do wywołania wychodzącego. Parametr MaxUserPort może ustawiać wartość najwyższego portu. Ustawienie tej wartości na (powiedzmy) 9000 z nawiązką podwoiłoby liczbę dostępnych portów. Szczegóły można znaleźć w specyfikacji RFC 793.

17 W skład dodatkowych parametrów Rejestru rządzących zachowaniem połączenia wchodzi MaxFreeTcbs, który kontroluje dostępną liczbę zapamiętanych w pamięci podręcznej (albo wstępnie alokowanych) bloków kontrolnych transportu (TCB). TCB to struktura danych, która jest utrzymywana dla każdego połączenia TCP. Parametr MaxHashTableSize kontroluje szybkość znajdywania bloku kontrolnego TCP przez system. Wartość MaxHashTableSize (domyślnie 512) powinna być zwiększona, jeżeli wartość MaxFreeTcbs zostanie zwiększona z wartości domyślnej (Server) lub (Professional/Workstation). Wskazówka: Jeżeli wartość MaxHashTableSize nie jest potęgą liczby dwa, to system konfiguruje tablicę mieszania na najbliższą wartość będącą potęgą liczby dwa. Na przykład ustawienie o wartości zostaje zaokrąglone do Komputery o wielu podłączeniach Połączenia TCP do i od hosta o wielu podłączeniach wykonywane są na kilka sposobów w zależności od tego czy host jest lokalny, czy zdalny i od zastosowanej usługi rozpoznawania nazw. Połączenia do hosta o wielu podłączeniach Kiedy połączenia TCP wykonywane są do hosta o wielu podłączeniach, to zarówno analizator nazw domen (DNR), jak i klient usługi nazw internetowych systemu Windows (WINS), próbują ustalić, czy któreś spośród docelowych adresów IP są w tej samej podsieci, co któryś z interfejsów w komputerze lokalnym. Adresy lokalne umieszczane są na górze listy, aby aplikacja mogła je wypróbować w pierwszej kolejności. Parametr Rejestru TCP/IP PrioritizeRecordData może być wykorzystywany, aby uniemożliwić składnikowi DNR umieszczenie adresów podsieci lokalnej na górze listy. To, w jaki sposób traktowane są odległe adresy IP, zależy od typu wykorzystywanej przestrzeni nazw. W przestrzeni nazw WINS, klient WINS odpowiedzialny jest za wyrównywanie obciążenia pomiędzy dostarczonymi adresami. Serwer WINS zawsze zwraca listę adresów w tej samej kolejności, a klient WINS wybiera jeden z nich losowo dla każdego połączenia. W przestrzeni nazw systemu nazw domen (DNS) serwer DNS jest zazwyczaj skonfigurowany tak, aby dostarczać adresy w sposób okrężny. DNR nie podejmuje prób dalszych randomizacji adresów. W niektórych sytuacjach wskazane jest połączyć się z określonym interfejsem w komputerze o wielu połączeniach, a najlepszym sposobem osiągnięcia tego jest zapewnienie interfejsowi jego własnej pozycji DNS. Połączenia od hosta o wielu podłączeniach Jeżeli połączenie od hosta o wielu połączeniach jest połączeniem Winsock korzystającym z przestrzeni nazw DNS, to TCP podejmuje próbę połączenia z najlepszego źródłowego adresu IP dostępnego, kiedy znany jest docelowy adres IP dla połączenia. Do ustalenia tego adresu wykorzystywana jest tablica tras. Jeżeli na komputerze lokalnym znajdującym się w tej samej podsieci, co docelowy adres IP, jest interfejs, to jego adres IP jest wykorzystywany w żądaniu połączenia jako źródłowy. Jeżeli nie ma żadnego najlepszego źródłowego adresu IP, to system wybiera go losowo. Na poziomie aplikacji dostępnych jest mało informacji dotyczących routingu dla połączeń opartych na usłudze NetBIOS, które korzystają ze Zwrotnicy. W tym wypadku Zwrotnica umieszcza wywołania we wszystkich transportach, które są z nią powiązane. Jeżeli na przykład na

18 komputerze są dwa interfejsy i jest zainstalowany jeden protokół, to dla Zwrotnicy dostępne są dwa transporty i wywołania są umieszczane w obu z nich. NetBT wysyła żądania połączenia stosu przy użyciu adresu IP z każdego z interfejsów. Jeżeli powiodą się oba wywołania, to Zwrotnica anuluje jedno z nich. Wybór tego, które ma zostać anulowane, zależy od parametru Rejestru Zwrotnicy ObeyBindingOrder. Jeżeli jest on ustawiony na 0 (wartość domyślna), to preferowany jest transport główny, ustalany przez kolejność powiązań. W takim wypadku Zwrotnica czeka, aż transport podstawowy ulegnie przeterminowaniu, zanim przyjmie połączenie na transporcie pomocniczym. Jeżeli ObeyBindingOrder jest ustawiony na 1, to kolejność powiązań jest ignorowana. W takim wypadku Zwrotnica przyjmuje pierwsze udane połączenie i anuluje pozostałe. Wskazówka: Więcej informacji dotyczących parametrów Rejestru Zwrotnicy dostępnych jest w zestawie Windows 2000 Resource Kit. Optymalizowanie przepustowości łącza System Windows 2000 jest zaprojektowany tak, aby zapewniać optymalną wydajność w większości warunków łącza. Faktyczna przepustowość łącza zależy od kilku zmiennych. Najważniejsze czynniki to: szybkość łącza, opóźnienie propagacji, rozmiar okna, niezawodność łącza, przeciążenie sieci i urządzeń pośrednich. Jeżeli uważasz, że przepustowość jest niezadowalająca, to można dokonać paru regulacji. Dostrajanie wydajności łącza jest złożoną operacją i jego próby powinni podejmować tylko doświadczeni fachowcy od tworzenia sieci. Oto niektóre kluczowe czynniki: Potok to połączenie pomiędzy dwoma gniazdami TCP. Pojemność (lub produkt opóźnienia szerokości pasma) potoku równa jest szerokości pasma pomnożonej przez RTT. Jeżeli łącze jest niezawodne, to rozmiar okna powinien być większy lub równy pojemności potoku, aby stos wysyłający mógł je wypełnić. Pole Okno w segmencie TCP ma długość 16 bitów, a bitów to, w związku z tym, największy rozmiar okna, jaki może być określony przez to pole. Skalowanie okna, opisane wcześniej w tym rozdziale, może negocjować większe okna. Przepustowość nie może nigdy przekraczać rozmiaru okna podzielonego przez RTT. Jeżeli łącze jest niepewne albo poważnie przeciążone i pakiety ulegają zagubieniu, to zastosowanie większego okna może, samo w sobie, nie poprawić przepustowości. W rzeczywistości zwiększenie rozmiaru okna może czasem obniżać wydajność w sieci stratnej, ponieważ prowadzi do ponownego wysyłania większych pakietów. SACK może poprawić wydajność w środowiskach, które doświadczają utraty danych, a znaczniki czasu mogą być wykorzystywane do poprawy szacowania RTT.

19 Opóźnienie propagacji uzależnione jest od zwłoki sprzętu transmisyjnego i ostatecznie, od prędkości światła. Opóźnienie transmisji zależy od prędkości nośnika. W przypadku określonej ścieżki opóźnienie propagacji jest stałe, ale opóźnienie transmisji zależy od rozmiaru pakietu. Przy małych prędkościach czynnikiem ograniczającym jest opóźnienie transmisji. Przy dużych prędkościach czynnikiem ograniczającym może być opóźnienie propagacji. Podsumowując, TCP systemu Windows 2000 przystosowuje się do większości warunków sieciowych i przeważnie zapewnia optymalną przepustowość i niezawodność przy każdym połączeniu. Próby ręcznego dostrajania przynoszą często skutki odwrotne do zamierzonych, chyba że doświadczony fachowiec do spraw sieci dokona najpierw starannej analizy przepływu danych. Programy usługowe i usługi TCP/IP System Windows 2000 zapewnia dwa typy programów usługowych opartych na TCP/IP: programy usługowe komunikacyjne wchodzą w interakcje i wykorzystują zasoby rozmaitych hostów Microsoft i nie-microsoft (takich jak systemy Unix), programy usługowe diagnostyczne wykrywają i rozwiązują problemy pracy w sieci. Usługi systemu Windows 2000 zapewniają klientom zgodnym z TCP/IP usługi wydruku i udostępniania WWW. Ponadto system Windows 2000 zapewnia zestaw usług protokołu Simple TCP/IP, takich jak Echo i Cytat dnia. Tabele od 7.2 do 7.5 podsumowują programy usługowe i usługi TCP/IP. Uwaga: Microsoft zaleca, aby nie instalować usług protokołu Simple TCP/IP, chyba że musisz specjalnie zapewnić obsługę komunikacji z innymi systemami korzystającymi z tych usług. Tabela 7.2. Programy usługowe komunikacyjne Program usługowy Ftp Lpr Rcp Rexec Rsh Telnet Tftp Opis Przesyła dowolny rozmiar plików pomiędzy systemem Windows 2000 a komputerem z zainstalowanym oprogramowaniem serwera FTP. Przesyła zadania wydruku do zdalnych drukarek systemu UNIX zarządzanych przez oprogramowanie serwera wydruków demona drukarki wierszowej (LPD). Kopiuje pliki pomiędzy systemem Windows 2000 a komputerami z zainstalowanym oprogramowaniem serwera protokołu kopii zdalnej (RCP). Wykonuje zadania na komputerach zdalnych. Wykonuje polecenia na komputerze z zainstalowanym oprogramowaniem serwera Remote Shell (RSH). Korzysta z logowania za pomocą terminalu w celu uzyskania zdalnego dostępu do urządzeń sieciowych z zainstalowanym oprogramowaniem serwera Telnet. Przesyła małe pliki pomiędzy systemem Windows 2000 a komputerami z

20 zainstalowanym oprogramowaniem serwera protokołu transferu plików podstawowych (TFTP). Tabela 7.3. Programy usługowe diagnostyczne Program usługowy Arp Hostname Ipconfig Lpq Nbtstat Netstat Nslookup Ping Route Tracert PathPing Opis Wyświetla i modyfikuje pamięć podręczną protokołu Address Resolution Protocol (ARP). Pamięć ta jest tabelą lokalną, wykorzystywaną przez system Windows 2000 do zamiany adresów IP na adresy kontroli dostępu do nośnika, używane w sieci lokalnej. Zwraca nazwę hosta komputera lokalnego. Wyświetla bieżącą konfigurację TCP/IP i może również służyć do wypuszczania i odnawiania konfiguracji TCP/IP przypisanych przez serwer DHCP. Otrzymuje informacje o stanie kolejki wydruku z komputerów z zainstalowanym oprogramowaniem serwera wydruków demona drukarki wierszowej (LPD). Wyświetla tabelę lokalnych nazw NetBIOS, tabelę nazw NetBIOS zarejestrowanych za pomocą aplikacji lokalnych oraz pamięć podręczną nazw NetBIOS, która jest lokalnym wykazem nazw NetBIOS zamienionych na adresy IP i zapisanych w pamięci podręcznej komputera. Wyświetla informacje o sesji protokołu TCP/IP. Sprawdza rekordy, nazwy hostów domen, usługi hostów domen i informacje o systemie operacyjnym za pomocą zapytań serwerów DNS. Sprawdza konfiguracje i testuje połączenia IP. Wyświetla lub modyfikuje lokalną tablicę tras. Śledzi trasę pakietu w drodze do miejsca docelowego. Śledzi trasę pakietu w drodze do miejsca docelowego i wyświetla informacje o ubytkach pakietów dla każdego routera na trasie. Polecenia Pathping można także używać do rozwiązywania problemów z jakością usług (QoS) połączeń. Tabela 7.4. Usługi systemu Windows 2000 Usługa Usługa drukowania protokołu TCP/IP Opis Umożliwia wysyłanie zadań wydruku z komputerów UNIX do komputerów wyposażonych w system Windows 2000 za pomocą polecenia drukowania Line Printer Remote (Lpr). Internetowe usługi informacyjne Uaktywnia usługi udostępniania WWW oparte na TCP/IP. Usługi te, zainstalowane na serwerze IIS implementują gotowy serwer sieci WWW dla przedsiębiorstw z możliwością jednoczesnego ustanawiania nieograniczonej liczby połączeń.