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

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

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

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

1072.

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.

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

www.isi.edu/in-notes/iana/assignments/port-numbers

.

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

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)

SEQ=1000

CTL=SYN

Host

A

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.

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.

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

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.

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.

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

www.rsasecurity.com

.

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.

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

W przypadku Ethernetu okno jest zazwyczaj ustawione na 17 520 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 1323.

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:

0100 0100 0111 0000 (17,520)

to faktor skali dawałby możliwy rozmiar okna o wartości:

0100 0100 0111 0000 0000 (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.

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

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

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ść

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

dziury

i jest opisana w podrozdziale rozwiązań natychmiastowych niniejszego rozdziału.

Odkrywanie PMTU jest opisane w specyfikacji RFC 1191.

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

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ść

7 200 000 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

keep-

alive

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

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.

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

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

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 2 000 (Server) lub 1 000 (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 1 000 zostaje zaokrąglone do 1 024.

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

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 65 535 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.

• 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 Opis

Ftp Przesyła dowolny rozmiar plików pomiędzy systemem Windows 2000 a

komputerem z zainstalowanym oprogramowaniem serwera FTP.

Lpr Przesyła zadania wydruku do zdalnych drukarek systemu UNIX

zarządzanych przez oprogramowanie serwera wydruków demona drukarki
wierszowej (LPD).

Rcp

Kopiuje pliki pomiędzy systemem Windows 2000 a komputerami z
zainstalowanym oprogramowaniem serwera protokołu kopii zdalnej (RCP).

Rexec

Wykonuje zadania na komputerach zdalnych.

Rsh

Wykonuje polecenia na komputerze z zainstalowanym oprogramowaniem
serwera Remote Shell (RSH).

Telnet

Korzysta z logowania za pomocą terminalu w celu uzyskania zdalnego
dostępu do urządzeń sieciowych z zainstalowanym oprogramowaniem
serwera Telnet.

Tftp Przesyła małe pliki pomiędzy systemem Windows 2000 a komputerami z

zainstalowanym oprogramowaniem serwera protokołu transferu plików
podstawowych (TFTP).

Tabela 7.3. Programy usługowe diagnostyczne

Program usługowy Opis

Arp

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.

Hostname

Zwraca nazwę hosta komputera lokalnego.

Ipconfig

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.

Lpq

Otrzymuje informacje o stanie kolejki wydruku z komputerów z
zainstalowanym oprogramowaniem serwera wydruków demona drukarki
wierszowej (LPD).

Nbtstat

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.

Netstat

Wyświetla informacje o sesji protokołu TCP/IP.

Nslookup

Sprawdza rekordy, nazwy hostów domen, usługi hostów domen i informacje
o systemie operacyjnym za pomocą zapytań serwerów DNS.

Ping

Sprawdza konfiguracje i testuje połączenia IP.

Route

Wyświetla lub modyfikuje lokalną tablicę tras.

Tracert

Śledzi trasę pakietu w drodze do miejsca docelowego.

PathPing

Ś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 Opis

Usługa drukowania protokołu
TCP/IP

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

Równoprawne usługi w sieci
WWW

Dostarczane z wersją profesjonalną systemu Windows 2000 aby
implementować sieciowe usługi udostępniania, podobne do
usług IIS, ale do obsługi nie więcej niż 10 połączeń
jednocześnie.

Tabela 7.5. Usługi protokołu

Simple

TCP/IP

Protokół Opis

Specyfikacja
RFC

Character Generator
(CHARGEN)

Wysyła zestaw 95 drukowanych znaków ASCII.
CHARGEN jest używany jako narzędzie do testowania i
rozwiązywania problemów z drukarkami wierszowymi.

864

Daytime Zwraca

komunikaty

z dopisanym dniem tygodnia,

miesiącem, rokiem, bieżącym czasem (w formacie

gg:mm:ss

) i informacji o strefie czasowej.

Daytime

jest

wykorzystywany do usuwania wirusów, monitorowania
zmian w zegarze systemowym różnych hostów, a także do
resetowania czasu systemowego.

867

Discard

Odrzuca komunikaty otrzymanych za pośrednictwem
danego portu bez odpowiedzi lub potwierdzenia otrzymania.

Discard

jest wykorzystywany do implementowania portu

zerowego do odbierania i routingu komunikatów testowych
TCP/IP podczas instalowania i konfigurowania sieci. Może
być używany przez niektóre programy jako narzędzie do
odrzucania komunikatów.

863

Echo

Zwraca dane pochodzące z dowolnego komunikatu
odebranego za pomocą danego portu serwera. Może być
przydatny jako narzędzie do usuwania wirusów i narzędzie
monitorowania sieci.

862

Cytat dnia (QUOTE) Zwraca cytat w formie jednego lub kilku wierszy tekstu

komunikatu. Cytaty są wybierane losowo z

%systemroot%\System32\Drivers\Etc\Quotes

.

865

Rozwiązania natychmiastowe

Przechwytywanie ruchu TCP

Większość komunikacji sieciowej systemu Windows 2000 generuje ruch TCP. W tym przypadku
ruch dostępu do witryn FTP i HTTP pomiędzy klientem systemu Windows 2000 a usługą IIS
przechwytuje się przy użyciu

Monitora sieci

w IIS. Aby ograniczyć rozmiar przechwytywania,

ustawia się filtr przechwytywania tak, aby przechwytywany był tylko ruch do i od wybranego
komputera klineckiego. Procedura ta zakłada, że w IIS uruchomione są zarówno witryny HTTP,

jak i FTP. Przechwycenia otrzymane w ten sposób powinny przypominać pliki przechwytywania

ftp.cap

oraz

http.cap

na CD-ROM-ie.

Aby przechwytywać ruch TCP, podejmij następujące działania:

1. Zaloguj

się na serwerze IIS jako administrator.

2. Zaloguj

się na drugim komputerze w domenie przy użyciu dowolnego konta domeny,

które ma zezwolenie na dostęp do witryn FTP oraz HTTP na serwerze IIS.

3. Na serwerze IIS wejdź do

Start|Programy|Narzędzia administracyjne

i wybierz

Monitor

sieci

.

4. W menu rozwijanym

Monitora sieci Przechwytywanie

wybierz

Filtr

.

5. W oknie dialogowym

Filtr przechwytywania

kliknij

Edytuj adresy

.

6. W oknie dialogowym

Baza danych adresów

kliknij

Dodaj

.

7. Pojawi

się okno dialogowe

Informacje adresowe

. Z listy rozwijanej

Typ

wybierz IP i

wpisz nazwę i adres IP drugiego komputera w twojej domenie, na którym się
zalogowałeś. Kliknij

OK

.

8. Zamknij

okno

Baza danych adresów

.

9. W oknie dialogowym

Wyrażenie adresowe

wybierz serwer IIS jako

Stacja 1

, a drugi

komputer jako

Stacja 2

. W polu

Kierunek

wybierz dwukierunkowy

(<-->)

. Kliknij

OK

.

10. Kliknij

OK

, aby zamknąć okno dialogowe

Filtr przechwytywania

.

11. W menu rozwijanym

Monitora sieci Przechwytywanie

wybierz

Rozpocznij

.

12. Na drugim komputerze (nie-IIS) otwórz przeglądarkę i wpisz

ftp://nazwa serwera

,

gdzie

nazwa serwera

jest nazwą serwera IIS.

13. W menu rozwijanym

Monitora sieci Przechwytywanie

(na serwerze IIS) wybierz

Zatrzymaj i wyświetl

. Przeglądnij przechwycone ramki i zapisz przechwycenie (na

przykład jako

ftp.cap

).

14. W menu rozwijanym

Monitora sieci Przechwytywanie

wybierz

Rozpocznij

.

15. Na drugim komputerze (nie-IIS) wpisz w przeglądarce

http://nazwa serwera

, gdzie

nazwa serwera

jest nazwą serwera IIS.

16. Zamknij przeglądarkę.

17. W menu rozwijanym

Monitora sieci Przechwytywanie

(na serwerze IIS) wybierz

Zatrzymaj i wyświetl

. Przeglądnij przechwycone ramki i zapisz przechwycenie (na

przykład jako

htttp.cap

).

18. Wyjdź z

Monitora sieci

.

Odnośne rozwiązanie:

Strona:

Implementowanie Filtra przechwytywania

Konfigurowanie protokołu TCP systemu Windows
2000

Procedury zawarte w tej części opisują, jak należy konfigurować protokół TCP systemu Windows
2000. Zakładają one, że wiesz, które wartości domyślne chcesz zmienić i że rozpracowałeś
prawdopodobne konsekwencje takich zmian. TCP systemu Windows zapewnia optymalną
konfigurację w większości środowisk, więc zmiany należy przeprowadzać ostrożnie. Poza tym
procedury te wymagają zmieniania (

przerabiania

)

Rejestru

. Powinno się to robić bardzo ostrożnie.

Nieostrożne przeróbki

Rejestru

mogą poważnie uszkodzić twój system operacyjny. Zawsze

zapisuj klucz podrzędny (przy użyciu polecenia

Zapisz klucz

w menu rozwijanym

Rejestr

) zanim

go zmienisz.

Program

Edytor Rejestru

,

regedt32.exe

, można znaleźć w folderze

%systemroot%\System32

. Dla

wygody możesz zechcieć utworzyć skrót na swoim pulpicie, albo w menu

Narzędzia

administracyjne

. Jeżeli to zrobisz, uważaj szczególnie aby nie umożliwiać innym użytkownikom

dostępu do swojego komputera kiedy zalogowane jest twoje konto.

Edytor Rejestru

nie jest

narzędziem, które można pozostawić w rękach niedoświadczonego użytkownika.

Ustawianie rozmiaru okna odbierania protokołu TCP

Procedura ta ustawia rozmiar okna odbierania protokołu TCP dla określonego interfejsu.
Procedura ustawiania rozmiaru okna dla wszystkich interfejsów jest podobna, z tym że jest
implementowana w kluczu podrzędnym

/Tcpip/Parameters/

, a nie w kluczu podrzędnym

/Tcpip/Parameters/Interfaces/interface

.

Aby ustawić rozmiar okna odbierania, wykonaj następujące czynności:

1. Uruchom

Edytor Rejestru

.

2. Rozwiń:

HKEY_LOCAL_MACHINE

\SYSTEM

\CurrentControlSet

\Services

\Tcpip

\Parameters

\Interfaces

3. Kliknij interfejs, dla którego chcesz określić rozmiar okna odbierania.

4. Wybierz

Dodaj wartość

w menu rozwijanym

Edycja

.

5. Określ

TcpWindowSize

jako typ danych REG_DWORD, jak na rysunku 8.3.

6. Kliknij

OK

. Wpisz wartość albo szesnastkową, albo dziesiętną w oknie dialogowym

Edytor DWORD

. Maksymalna dopuszczalna wartość to 3FFFFFFF (szesnastkowa), lub

1 073 741 823 (dziesiątkowa).

7. Kliknij

OK

. Zamknij

Edytor Rejestru

.

Rysunek 7.3. Określanie typu danych

TcpWindowSize

Włączanie opcji skali okna i znaczników czasu

Opcję skali okna oraz zastosowanie znaczników czasu włącza się dla wszystkich interfejsów, a nie
dla pojedynczego interfejsu. Jednakże skalowanie okna nie zacznie działać na żadnym interfejsie,
na którym rozmiar okna odbierania ma wartość FFFF (szesnastkową), lub mniejszą. W celu
ustawienia rozmiaru okna odbierania odwołaj się do poprzedniej procedury.

Aby włączyć opcję skalowania okna oraz zastosowanie znaczników czasu, wykonaj następujące
kroki:

1. Uruchom

Edytor Rejestru

.

2. Rozwiń:

HKEY_LOCAL_MACHINE

\SYSTEM

\CurrentControlSet

\Services

\Tcpip

3. Kliknij

Parametry

.

4. Wybierz

Dodaj wartość

w menu rozwijanym

Edycja

.

5. Określ

Tcp1323Opts

jako typ danych REG_WORD.

6. Kliknij

OK

. Wpisz wartość od

1

do

3

, w zależności od tego co chcesz włączyć:

• wartość równa

1

włącza tylko skalowanie okna;

• wartość równa

2

włącza tylko znaczniki czasu;

• wartość równa

3

włącza zarówno skalowanie okna, jak i znaczniki czasu.

7. Kliknij

OK

. Zamknij

Edytor Rejestru

.

Wskazówka: W toku tej i poprzedniej procedury zostały określone pełne ścieżki do kluczy
podrzędnych

Rejestru

interfejsu

Tcpip/Parameters

oraz

Tcpip/Parameters/Interfaces/

.

Pozostałe procedury w tej części korzystają z jednego lub drugiego z tych kluczy i wydaje się
bezcelowym określanie pełnej ścieżki dla każdego z nich. Dlatego też w toku kolejnych
procedur pełne ścieżki będą skracane do

Tcpip/Parameters

oraz

Tcpip/Parameters/Interfaces

.

Ustawianie czasomierza potwierdzenia opóźnionego

Czasomierz ACK opóźnionego ustawiony jest domyślnie na wartość 2 (200 milisekund). Aby
zmienić tę wartość przeterminowania dla danego interfejsu, wykonaj następujące czynności:

1. Uruchom

Edytor Rejestru

i rozwiń klucz podrzędny

Tcpip/Parameters/Interfaces

.

2. Kliknij interfejs, na którym chcesz zmienić czasomierz ACK opóźnionego.

3. Wybierz

Dodaj wartość

w menu rozwijanym

Edycja

.

4. Określ

TcpDelAckTicks

jako typ danych REG_DWORD.

5. Kliknij

OK

. Wpisz wartość od

0

do

6

. Określa to liczbę 100-milisekundowych

interwałów przed przeterminowaniem czasomierza. Wartość równa

0

wyłącza

potwierdzenia opóźnione, co sprawia, że komputer natychmiastowo potwierdza każdy
pakiet, który otrzyma.

6. Kliknij

OK

i zamknij

Edytor Rejestru

.

Wyłączanie potwierdzenia selektywnego

Jeżeli twoja sieć nigdy nie wykorzystuje dużych rozmiarów okien, to możesz zechcieć wyłączyć
SACK. Jest to nietypowe i zazwyczaj niewskazane. Jednak procedura wyłączania SACK wygląda
następująco:

1. Uruchom

Edytor Rejestru

i kliknij klucz podrzędny

Tcpip/Parameters

.

2. Wybierz

Dodaj wartość

z menu rozwijanego

Edycja

.

3. Określ

SackOpts

jako typ danych REG_DWORD.

4. Kliknij

OK

. Wpisz wartość równą

0

, aby wyłączyć SACK.

5. Kliknij

OK

i zamknij

Edytor Rejestru

.

Włączanie odkrywania routera czarnej dziury

Router czarnej dziury odrzuca pakiet, który ma zbyt duży rozmiar okna i który ma ustawiony
znacznik DF, ale nie wysyła komunikatu protokołu ICMP „Miejsce docelowe niedostępne”.
Mechanizm odkrywania PMTU można ustawić na wykrywanie takich routerów w następujący
sposób:

1. Uruchom

Edytor Rejestru

i kliknij klucz podrzędny

Tcpip/Parameters

.

2. Wybierz

Dodaj wartość

z menu rozwijanego

Edycja

.

3. Określ

EnablePMTUBHDetect

jako typ danych REG_DWORD.

4. Kliknij

OK

. Wpisz wartość

1

, aby włączyć wykrywanie routerów czarnej dziury.

5. Kliknij

OK

i zamknij

Edytor Rejestru

.

Wyłączanie odkrywania maksymalnej jednostki transmisyjnej ścieżki
(PMTU)

Możliwe jest całkowite wyłączenie odkrywania PMTU. Jest to nietypowe i normalnie
niewskazane, ale możesz zechcieć to zrobić, jeżeli nigdy nie wysyłasz dużych segmentów lub
kiedy wysyłasz segmenty poprzez znajome sieci, gdzie znane są rozmiary MTU. Kiedy
odkrywanie PMTU jest wyłączone, to dla wszystkich adresów miejsc docelowych zdalnych
wykorzystywane jest MSS równe 536 bajtom. Aby wyłączyć odkrywanie PMTU, wykonaj
następujące czynności:

1. Uruchom

Edytor Rejestru

i kliknij klucz podrzędny

Tcpip/Parameters

.

2. Wybierz

Dodaj wartość

z menu rozwijanego

Edycja

.

3. Określ

EnablePMTUBHDiscovery

jako typ danych REG_DWORD.

4. Kliknij

OK

. Wpisz wartość

0

(zero), aby wyłączyć odkrywanie PMTU.

5. Kliknij

OK

i zamknij

Edytor Rejestru

.

Konfigurowanie zachowań retransmisji protokołu TCP

Jak opisano w części

Dogłębnie

niniejszego rozdziału, zachowania retransmisji protokołu TCP

można konfigurować i dostrajać przy użyciu czterech parametrów

Rejestru

:

•

TcpInitialRTT

,

•

TcpMaxConnectRetransmissions

,

•

TcpMaxDataRetransmissions

,

•

TcpMaxDupAcs

.

Parametr

TcpMaxDataRetransmissions

konfiguruje także wykrywanie martwej bramy.

Wszystkie te parametry mają typ danych REG_WORD i trzeba je dodawać do

Rejestru

przy

użyciu polecenia

Dodaj wartość

w menu rozwijanym

Edycja

.

TCPInitialRTT

określane jest

osobno dla każdego z interfejsów, a trzy pozostałe parametry określane są w kluczu podrzędnym
Tcpip/Parameters. Mając informacje z tabeli 7.6, możesz dodawać i konfigurować parametry przy
użyciu technik opisanych w poprzednich procedurach.

Uwaga! Parametr

TcpInitialRTT

stosuje się wykładniczo i bardzo mała zmiana może mieć

niekorzystny wpływ na wydajność (patrz: dodatek A). Nie zaleca się ustawienia większego niż
3.

Konfigurowanie pakietów keep-alive protokołu TCP oraz opóźnienia
TIME-WAIT

Jak opisano w części

Dogłębnie

niniejszego rozdziału, pakiety

keep-alive

można konfigurować i

dostrajać przy użyciu dwóch parametrów

Rejestru

:

•

KeepAliveTime

,

•

KeepAliveInterval

.

Oba te parametry mają typ danych REG_WORD i określają wartości w milisekundach.

Opóźnienie TIME-WAIT można konfigurować przy użyciu czterech parametrów

Rejestru

:

•

TcpTimedWaitDelay

,

•

MaxUserPort

,

•

MaxFreeTcbs

,

•

MaxHashTableSize

.

Wszystkie te parametry mają typ danych REG_DWORD.

TcpTimedWaitDelay

określa wartość

w sekundach, a pozostałe trzy parametry określają numery.

Tabela 7.6. Parametry retransmisji protokołu TCP

Parametr Zakres

Wartość domyślna

TcpInitialRTT

0 do FFFF

3

TcpMaxConnectRetransmissions

0 do 255 (dziesiętne) 3

TcpMaxDataRetransmissions

0 do FFFFFFFF

5

TcpMaxDupAcks

1 do 3

2

Wszystkie parametry

keep-alive

i TIME-WAIT dodaje się do klucza podrzędnego

Rejestru

Tcpip/Parameters

przy użyciu polecenia

Dodaj

wartość z menu rozwijanego

Edycja

. Mając

informacje z tabeli 7.7, możesz dodawać oraz konfigurować parametry korzystając z technik
opisanych w poprzednich procedurach.

Wskazówka:

MaxHashTableSize

powinien być potęgą liczby dwa. Odwołaj się do dodatku A.

Tabela 7.7. Parametry TCP

keep-alive

i TIME-WAIT

Parametr Zakres

Wartość domyślna

KeepAliveTime

0 do FFFFFFFF

7 200 000 (dziesiętne)

KeepAliveInterval

0 do FFFFFFFF

1 000 (dziesiętne)

TcpTimedWaitDelay

30 do 300 (dziesiętne) 240

(dziesiętne)

MaxUserPort

5 000 do 65 534 (dziesiętne)

5 000 (dziesiętne)

MaxFreeTcbs

0 do FFFFFFFF

Server — 2 000 (dziesiętne)
Professional — 1 000 (dziesiętne)

MaxHashTableSize

64 do 65 536 (dziesiętne) 512

(dziesiętne)

Ręczne odkrywanie PMTU

PMTU można odkryć przy użyciu polecenia

ping

. Procedura ta jest prosta, lecz nieco nużąca.

Zakłada ona, że możesz przeprowadzić

ping

hosta w sieci i chcesz odkryć PMTU do tej sieci.

Składnia polecenia

ping

, której możesz użyć, to:

ping –f –n <liczba ping’ów[PO15]> -1 <rozmiar> <docelowy adres IP>

Przełącznik

–f

ustawia znacznik DF. Parametr

rozmiar

określa rozmiar bufora danych, który

wysyła

ping

, z wyłączeniem nagłówków. Nagłówek ICMP ma rozmiar 8 bajtów, a nagłówek IP

zazwyczaj 20 bajtów. Technika ta to przeprowadzić ping, określając maksymalny rozmiar danych,
o jakim wiesz, że może być transmitowany do hosta zdalnego, ustalony według przechwyceń

Monitora sieci

i zwiększać tę wartość w kolejnych

ping’ach[PO16]

do momentu, kiedy

polecenie nie powiedzie się, zwracając stosowny komunikat.

Wskazówka: MSS, negocjowany podczas ustanawiania połączenia, stanowi dobry wskaźnik
wartości początkowej, która ma być używana w parametrze rozmiaru.

Przypuśćmy na przykład, że wiesz, iż możesz przeprowadzić

ping

hosta zdalnego 142.24.234.66

przy użyciu 1600 bajtów danych.

E:\>ping –f –n 1 –l 1600 142.24.234.66

Badanie 142.24.234.66 z użyciem 1600 bajtów danych:

Odpowiedź od 142.24.234.66: bajtów=1600 czas<10ms TTL=128

Statystyka badania dla 142.24.234.66:

Pakiety: Wysłane = 1, Odebrane = 1, Utracone = 0 (0% utraconych),

Szacunkowy czas błądzenia pakietów w milisekundach:

Minimum = 0ms, Maksimum = 0ms, Średnia = 0ms

Kontynuujesz

ping

tego samego hosta, zwiększając wartość parametru

rozmiar

do momentu

kiedy

ping

się nie powiedzie.

E:\>ping –f –n 1 –l 1640 142.24.234.66

Badanie 142.24.234.66 z użyciem 1600 bajtów danych:

Pakiet musi zostać sfragmentowany, ale DF ustawione.

Statystyka badania dla 142.24.234.66:

Pakiety: Wysłane = 1, Odebrane = 0, Utracone = 1 (100% utraconych),

Szacunkowy czas błądzenia pakietów w milisekundach:

Minimum = 0ms, Maksimum = 0ms, Średnia = 0ms

W tym przykładzie MTU do określonego hosta (albo PMTU dla ścieżki do tego hosta) wynosi
1640 plus 28, lub 1 668 bajtów. Gdyby na ścieżce znajdował się router czarnej dziury, to

ping

uległby przeterminowaniu, ale nie zostałby zwrócony żaden komunikat o błędzie.

Instalowanie usług protokołu Simple TCP/IP

Jeżeli musisz komunikować się z komputerami mającymi zainstalowane usługi protokołu

Simple

TCP/IP, lub jeśli masz inne powody, aby je instalować, to procedura służąca temu jest
następująca:

1. Zaloguj

się jako administrator.

2. W

Start|Ustawienia|Panel sterowania

otwórz

Dodaj/Usuń programy

.

3. W oknie dialogowym

Dodaj/Usuń programy

wybierz

Dodaj/Usuń składniki systemu

Windows

.

4. W Kreatorze składników systemu Windows wybierz

Usługi sieciowe

, a następnie kliknij

Szczegóły

.

5. Wybierz

Usługi Simple TCP/IP

, a następnie kliknij

OK

.

6. Kliknij

Dalej

.

7. Jeżeli zostaniesz o to poproszony, włóż swój CD-ROM instalacyjny, lub wpisz ścieżkę do

miejsca, w którym znajdują się pliki dystrybucyjne systemu Windows 2000, a następnie
kliknij

OK

.

8. Kliknij

Zakończ

.