Rozdział 2

Infrastruktura protokołów TCP/IP
w sieciach Windows

Sieci Microsoft Windows oferują szeroki wybór protokołów sieciowych:
TCP/IP, SPX/IPX, NBF oraz AppleTalk. Standardowe usługi Windows
korzystają z interfejsu NetBIOS i protokołu SMB – jest to niezależne od
używanego protokołu sieciowego. Standardowe aplikacje i

usługi

internetowe - takie jak FTP, Telnet, DNS, SNMP, HTTP itd. - nie używają
NetBIOS ani SMB, lecz pracują bezpośrednio z protokołem TCP/IP.

W sieci Windows opartej na TCP/IP podstawowymi protokołami są:
TCP/IP w warstwie transportu i sieci modelu OSI, NetBIOS w warstwie
sesji i SMB w warstwie aplikacji. Niniejszy rozdział szczegółowo omawia
podstawowe protokoły w sieci Windows.

Protokoły Windows

Interfejs NetBIOS może funkcjonować ponad różnymi protokołami, jak
np. IPX, NBF i TCP/IP. Kiedy NetBIOS pracuje ponad TCP/IP,
nazywany jest NetBT lub NBT. Mechanizm pracy NetBIOS ponad
TCP/IP jest opisany w dokumentach RFC 1001 i RFC 1002. Protokół SMB,
jak stwierdzono w rozdziale 1 "Architektura TCP/IP w Windows", służy
do dzielenia zasobów w sieci. Używa on interfejsu NetBIOS, który może
pracować ponad TCP/IP. Hierarchię protokołów w sieci Windows
opartej na TCP/IP przedstawia rysunek 2.1. Przy usuwaniu usterek
w takich sieciach znajomość TCP/IP umożliwia znalezienie błędów tylko
w warstwie transportu. Aby znaleźć błędy w warstwach sesji i aplikacji,
trzeba rozumieć działanie NetBIOS i SMB.

Rozdział 2

28

Rysunek 2.1

Protokoły TCP/IP
w Windows

Kolejne podrozdziały omawiają szczegóły SMB, NetBIOS i TCP/IP,
poczynając od najwyższych warstw, a kończąc na najniższych.

Protokół SMB

SMB (Server Message Block) jest protokołem dzielenia zasobów, który po-
wstał dzięki wysiłkom firm Xerox, 3Com oraz (od niedawna) Microsoft.
Dzielenie zasobów przy użyciu SMB obejmuje dzielenie plików, druka-
rek, portów szeregowych oraz abstrakcje komunikacyjne, takie jak na-
zwane potoki i szczeliny pocztowe (mail slots) pomiędzy komputerami.

Protokół SMB jest protokołem warstwy aplikacji związanym z takimi
produktami jak LAN Manager i Microsoft Networking. Część specyfikacji
udostępniono publicznie w dokumencie X/Open. Pomiędzy latami 1992
i 1996 nie ukazała się żadna specyfikacja SMB; w tym czasie Microsoft
stał się implementatorem SMB o największym udziale w rynku. Wraz
z ukazaniem się Windows NT Microsoft rozwinął specyfikację SMB
o kolejne możliwości.

Z powodu siły rynkowej SMB z pewnymi modyfikacjami został przed-
stawiony jako propozycja internetowego standardu CIFS (Common
Internet Filesystem). CIFS nie został jeszcze uznany za internetowy stan-
dard, ale z powodu tej inicjatywy specyfikacja SMB stała się własnością
publiczną, a prowadzone na jej temat dyskusje odbywają się zgodnie
z zasadami Internet Engineering Task Force. W rozwijaniu protokołu
CIFS biorą udział Microsoft, Digital Equipment Corporation (obecnie
część firmy Compaq), Data General, SCO, Network Alliance Corp oraz
inne firmy. Przypuszczalnie CIFS będzie bardzo podobny do protokołu
nazywanego NT LM (LAN Manager) 0.12, z kilkoma modyfikacjami uła-
twiającymi używanie go w Internecie.

Infrastruktura protokołów TCP/IP w sieciach Windows

29

Według firmy Microsoft, CIFS definiuje standardowy protokół dostępu
do zdalnego systemu plików i przeznaczony jest do użycia w Internecie.
Pozwala on grupom użytkowników wspólnie pracować i

dzielić

dokumenty, zarówno w Internecie, jak w firmowych intranetach. CIFS
jest oparty na standardowych protokołach wbudowanych w Windows
i inne popularne systemy operacyjne dla komputerów osobistych, łącznie
z UNIX (program SAMBA). Użytkownicy CIFS mogą otwierać i dzielić
zdalne pliki na serwerach CIFS i SMB w Internecie bez potrzeby instalacji
nowego oprogramowania lub zmiany sposobu pracy.

Natura SMB

SMB jest protokołem typu klient/serwer (patrz rysunek 2.2). Serwery
udostępniają klientom w sieci systemy plików oraz inne zasoby, takie jak
drukarki, szczeliny pocztowe, nazwane potoki czy interfejsy programowe
aplikacji (API). Klienci zazwyczaj posiadają własne systemy składowania
danych, jak np. twarde dyski, mogą jednakże potrzebować również do-
stępu do dzielonych systemów plików oraz drukarek na serwerze.

Typowe działanie SMB polega na tym, że klient wysyła żądania, a serwer
na nie odpowiada. Rysunek 2.2 ilustruje ten sposób pracy. Jedynym
wyjątkiem od zasady żądanie-odpowiedź jest sytuacja, w której klient
poprosił o okazyjną blokadę pliku, a serwer musi następnie przerwać
przyznaną już blokadę, ponieważ inny klient zażądał otwarcia pliku
w niekompatybilnym z nią trybie. W

takim przypadku serwer

samodzielnie wysyła do klienta komunikat o przerwaniu blokady.

Klienci SMB łączą się z serwerami przy użyciu TCP/IP, NetBEUI lub
IPX/SPX (patrz rysunek 2.3). Jeśli używany jest TCP/IP, w rzeczywi-
stości jest to NetBIOS ponad TCP/IP, jak to opisują dokumenty RFC 1001
i RFC 1002. NetBIOS ponad TCP/IP, jak wspomniano wcześniej, czasem
nazywany jest NBT, a czasem NetBT; bywa też nazywany RFCNB (ze
względu na definiujący go dokument RFC).

W przypadku wykorzystywania SMB z TCP/IP lub NetBEUI konieczne
jest używanie nazw NetBIOS jako nazw komputerów. Nazwy NetBIOS
mogą mieć długość do 15 znaków. Microsoft i

niektórzy inni

implementatorzy SMB wymagają, żeby nazwy składały się wyłącznie
z dużych liter.

Po uzyskaniu połączenia klient może przesyłać do serwera polecenia
umożliwiające mu dostęp do dzielonych zasobów, otwieranie plików,
czytanie i zapisywanie plików itd. Większość klientów SMB została
opracowana przez Microsoft. Wchodzą one w skład Windows for
Workgroups 3.x, Windows 9x i Windows NT.

Rozdział 2

30

Klienci SMB wkraczają do działania, kiedy użytkownik posługuje się
Menedżerem plików albo Eksploratorem z

Windows 95 w

celu

połączenia się z serwerami sieciowymi. Klienci SMB pracują również
podczas otwierania plików przy użyciu konwencji UNC. Klienci SMB dla
systemu UNIX to SMBclient, SMBfs dla Linux oraz biblioteka klienta
SMBlib. Istnieje wiele implementacji serwera SMB - poniżej wymieniono
niektóre z nich:

Rysunek 2.2

Klienci i serwery SMB

Rysunek 2.3

Protokoły transportowe SMB

„

Samba

„

Microsoft Windows for Workgroups 3.x

„

Microsoft Windows 95

„

Microsoft Windows NT

„

Rodzina serwerów PATHWORKS firmy Digital

„

LAN Manager for OS/2, SCO itd.

„

VisionFS firmy SCO

„

TotalNET Advanced Server firmy Syntax

„

Advanced Server for UNIX firmy AT&T

„

LAN Server for OS/2 firmy IBM

Infrastruktura protokołów TCP/IP w sieciach Windows

31

Wersje protokołu SMB

Protokół SMB zmieniał się, aby sprostać rosnącej złożoności środowisk,
w których był stosowany. Z tego powodu klient i serwer negocjują wersję
protokołu przy pomocy polecenia negprot, które musi być pierwszym
poleceniem SMB przesłanym przez połączenie.

Pierwszy wariant protokołu nazywany jest protokołem Core. Znany jest
również jako PC NETWORK PROGRAM 1.0. Protokół Core SMB wyko-
nuje dość ograniczony zbiór operacji, między innymi:

„

Łączenie się i odłączanie od udostępnionych plików i drukarek.

„

Otwieranie i zamykanie plików

„

Otwieranie i zamykanie plików wydruku

„

Czytanie i zapisywanie plików

„

Tworzenie i usuwanie plików i katalogów

„

Przeszukiwanie katalogów

„

Sprawdzanie i ustawianie atrybutów plików

„

Blokowanie i odblokowywanie zakresu bajtów w plikach.

Kiedy producenci oprogramowania dostrzegli potrzebę zwiększenia
funkcjonalności protokołu, rozszerzyli jego możliwości. Lista wariantów
protokołu, oparta na wykazie skompilowanym przez Richarda Sharpe,
przedstawiona jest w tabeli 2.1. Niektóre warianty wprowadziły nowe
polecenia SMB, inne zmieniły format istniejących poleceń lub
odpowiedzi, jeszcze inne wprowadziły zarówno nowe polecenia, jak
i formaty.

Tabela 2.1 Wersje SMB

Wersja protokołu SMB

Nazwa protokołu Uwagi

PC Network Program 1.0

Core

Niektóre wersje były nazywane
PCLAN1.0

Microsoft Networks 1.03 CorePlus

Posiadał polecenia Blokuj
i Czytaj oraz Zapisz i Odblokuj
oraz inne wersje poleceń
surowego zapisu i odczytu

Microsoft Networks 3.0

DOS LAN Manager
1.0

Taki sam jak LANMAN 1.0, ale
błędy OS/2 muszą być
tłumaczone na błędy DOS.

LANMAN1.0 LAN

Manager

1.0 Kompletny

protokół LANMAN

1.0

DOS LM1.2X002

LAN Manager 2.0

Taki sam jak LM1.2X002, ale
błędy muszą być tłumaczone na
błędy DOS.

Rozdział 2

32

Wersja protokołu SMB

Nazwa protokołu Uwagi

LM1.2X002

LAN Manager 2.0

Kompletny protokół LANMAN
2.0

DOS LANMAN2.1

LAN Manager 2.1

Taki sam jak LANMAN 2.0, ale
błędy muszą być tłumaczone na
błędy DOS.

LANMAN 2.1

LAN Manager 2.1 Kompletny

protokół LANMAN

2.1

Windows for Workgroups
3.1a

LAN Manager 2.1x Windows

Workgroups

1.0

NT LM 0.12

NT LAN Manager
1.0x

Zawiera specjalne polecenia dla
systemu NT

Samba

NT LAN Manager
1.0x

Wersja Samby protoko³u NT LM
0.12

CIFS 1.0

NT LAN Manager
1.0

NT LM 0.12 z dodatkowymi
funkcjami.

Model bezpieczeństwa SMB

Model SMB definiuje dwa poziomy bezpieczeństwa:
„

poziom udostępionych zasobów

„

poziom użytkownika

W modelu bezpieczeństwa poziomu udostępionych zasobów zasoby
chronione są na serwerze. Każdy zasób może być zabezpieczony hasłem,
a klient znający to hasło ma dostęp do wszystkich plików zasobu. Był to
pierwszy model bezpieczeństwa, w jaki wyposażono SMB i jedyny, jaki
jest dostępny w wersjach protokołu Core i CorePlus. Program vserver.exe
z Windows for Workgroups standardowo stosuje zabezpieczenie na po-
ziomie udostępionych zasobów, Windows 9x również. Klienci Windows
9x logujący się do domeny Windows NT nie są ograniczeni do tego tylko
zabezpieczenia; mogą stosować zabezpieczenia poziomu użytkownika.

W modelu bezpieczeństwa poziomu użytkownika zabezpieczone są po-
szczególne pliki w każdym dzielonym zasobie, a ich używanie uzależ-
nione jest od praw dostępu. Każdy użytkownik (klient) musi zalogować
się na serwer, który sprawdza jego tożsamość. Kiedy to nastąpi, klient
otrzymuje identyfikator użytkownika, który musi okazywać przy na-
stępnych dostępach do serwera. Model ten jest dostępny od wersji LAN
Manager 1.0 i używany również w Windows NT.

Infrastruktura protokołów TCP/IP w sieciach Windows

33

Przykład wymiany SMB

Żądania i odpowiedzi wymieniane pomiędzy klientem i serwerem na-
zywane są poleceniami SMB. Polecenia SMB mają specyficzny format,
podobny dla żądań i odpowiedzi. Polecenie składa się z nagłówka o stałej
długości, po którym następuje część o zmiennej długości, zawierająca
parametry albo dane.

Po połączeniu na poziomie NetBIOS (albo poprzez NBF, albo poprzez
NetBT) klient jest gotowy do korzystania z usług serwera. Klient i serwer
muszą jednak najpierw ustalić, którą wersję protokołu SMB rozumieją.
Klient wysyła w tym celu do serwera polecenie SMB negprot (patrz rysu-
nek 2.4), wymieniając obsługiwane przez siebie dialekty protokołu. Ser-
wer odpowiada indeksem dialektu, który chce używać, lub wartością
0Xffff

, jeśli nie akceptuje żadnego z dialektów. Dialekty nowsze od wersji

Core i CorePlus w odpowiedzi negprot określają swoje możliwości, jak np.
maksymalny rozmiar bufora, kanoniczne nazwy plików itp.

Rysunek 2.4

Polecenie SMB negprot

Po ustaleniu wariantu protokołu SMB, klient może zalogować się na ser-
wer przy użyciu polecenia SMB SessetupX (patrz rysunek 2.5). Odpo-
wiedź na to polecenie wskazuje, czy klient przesłał właściwą nazwę
użytkownika i hasło. Po uwierzytelnieniu klienta serwer przydziela mu
numer identyfikacyjny użytkownika (User Identification Number, UID).
Klient musi go przedstawiać we wszystkich kolejnych poleceniach SMB
w danym połączeniu z serwerem. Należy zauważyć, że w wersjach Core
i CorePlus nie można się zalogować na serwer, ponieważ protokoły te
oferują zabezpieczenie tylko na poziomie dzielonych zasobów.

Po zalogowaniu się, klient może połączyć się z dzielonym zasobem. Za-
soby te często nazywane są drzewem, ze względu na drzewiastą struktu-
rę systemu plików. Klient wysyła polecenie SMB tcon lub tconX, określa-
jąc sieciową nazwę żądanego zasobu. Jeśli serwer stwierdzi, że dostęp do
zasobu o tej nazwie jest dozwolony, wówczas w odpowiedzi wysyła
identyfikator drzewa TID (tree identifier), którego klient będzie używał we
wszystkich następnych poleceniach SMB dotyczących tego zasobu.

Rozdział 2

34

Przeglądanie SMB

W Eksploratorze Windows możemy zobaczyć Otoczenie sieciowe kompu-
terów pod pojedynczą nazwą grupy roboczej. Nazwa grupy roboczej
Windows jest po prostu nazwą grupy roboczej SMB. Po kliknięciu na
nazwie jednego z należących do niej komputerów możemy zobaczyć listę
dzielonych plików i drukarek, do których można się podłączyć. Ten pro-
ces nazywamy przeglądaniem. Dzięki przeglądaniu możemy stwierdzić,
jakimi zasobami dysponuje sieć. Funkcja przeglądania obsługiwana jest
przez protokół SMB/CIFS, który pozwala na odkrywanie zasobów.

Każdy serwer SMB wysyła do wszystkich węzłów sieci (tzw. tryb
broadcast) komunikaty o swojej obecności. Klienci nasłuchują takich ko-
munikatów i budują listy przeglądania. W środowisku NetBEUI ograni-
czonym do pojedynczej sieci jest to wystarczające, ale w złożonych sie-
ciach TCP/IP powstaje szereg problemów związanych z

trybem

broadcast. Dzieje się tak dlatego, że transmisje w trybie broadcast nie są
zazwyczaj wysyłane poza podsieć, w której powstały, chociaż routery
teoretycznie można skonfigurować tak, aby selektywnie przesyłały je do
innych podsieci. W celu rozwiązania tego problemu Microsoft wprowa-
dził specjalne serwery przeglądania oraz usługę WINS (Windows Inter-
net Name Service). WINS omówimy w szczegółach w rozdziale 9.

Rysunek 2.5

Polecenie SMB SesssetupX

Struktura pakietu SMB

Wszystkie komunikaty SMB posiadają część o stałej długości, nazywaną
czasem nagłówkiem SMB. Po nagłówku SMB następuje zmienna liczba
pól. Rysunek 2.6 pokazuje strukturę pakietu SMB z jego stałą i zmienną
częścią. Rysunki 2.7 i 2.8 pokazują kolejno stałą część nagłówkową
i następujące po nim zmienne pola. Ze względu na istnienie licznych
wersji SMB, komunikujące się komputery mogą wynegocjować inne for-
maty poleceń i odpowiedzi.

Infrastruktura protokołów TCP/IP w sieciach Windows

35

Rysunek 2.6

Stała i zmienna
część SMB

Rysunek 2.7

Nagłówek SMB

Rysunek 2.8

Zmienna część SMB

W polach, których długość wynosi dwa oktety, młodszy bajt poprzedza
starszy. Pola z rysunków 2.7 i 2.8 mają następujące znaczenie:

„idf

. Zawiera kod identyfikujący SMB.

„com

. Jest to tryb poleceń SMB; szczegóły omawia podrozdział "Pole-

cenia SMB w polu

com

".

„rcls

. Jest to klasa błędu.

„reh

. Zarezerwowane dla przyszłych zastosowań.

„err

. Zwracany numer błędu.

„flg

. Jest to pierwsze pole znaczników; szczegóły omawia podrozdział

"Wartości pola

flg

".

„flg2

. Drugie pole znaczników; szczegóły omawia podrozdział "Warto-

ści pola

flg2

".

„res

. Zarezerwowane dla przyszłych zastosowań.

„tid

. Używane przez serwer do identyfikowania zasobów, jak np.

drzewo katalogów. W rozszerzonym protokole LANMAN 1.2 TID re-
prezentuje uwierzytelniony dostęp, będący rezultatem użycia polece-
nia NET USE z właściwą nazwą sieciową i hasłem. Jeśli serwer pracuje
w trybie bezpieczeństwa poziomu udostępionych zasobów, TID jest
jedyną informacją używaną przy zezwalaniu na dostęp do zasobu. Je-
śli więc użytkownik pomyślnie wykona polecenie NET USE
i dostarczy odpowiednią nazwę udostępionego zasobu oraz hasło,

Rozdział 2

36

wówczas zyskuje dostęp do zasobu zgodnie ze zdefiniowanymi dla
tego zasobu prawami dostępu. Jeśli jednak serwer pracuje w trybie
bezpieczeństwa poziomu użytkownika, wówczas dostęp jest oparty
na identyfikatorze użytkownika (UID), przyznawanym mu podczas
otwierania sesji, a TID nie służy do kontrolowania praw dostępu, lecz
po prostu definiuje zasób, jak np. udostępione drzewo katalogów.
W większości wersji SMB pole tid

musi zawierać ważną wartość TID.

Wyjątkiem od tej reguły jest sytuacja, kiedy TID nie został jeszcze
przyznany, a więc przy poleceniach negprot, tcon, sesssetup i tconX. In-
nymi wyjątkami są polecenie QUERY_SRV_INFO, niektóre formy
protokołu transakcji oraz polecenie

echo

. Pusty TID definiuje się jako

0xFFFF

. Serwer jest odpowiedzialny za wymuszenie stosowania TID

tam, gdzie jest to potrzebne.

„pid

. Jest to identyfikator wywołującego procesu. Jest generowany

przez klienta w celu jednoznacznego określenia działającego procesu.
Odpowiedź zawiera zawsze taki sam PID, jaki zawierało żądanie.

„uid

. Jest to identyfikator uwierzytelnionego procesu. UID używany

jest w rozszerzonym protokole LANMAN 1.0, kiedy serwer pracuje
w trybie bezpieczeństwa poziomu użytkownika. Różni użytkownicy,
używający tego samego TID, mogą otrzymać różne prawa dostępu do
zasobu zdefiniowanego przez TID, w zależności od UID. UID jest
przesyłany przez serwer w poleceniu otwarcia sesji (sesssetup). Musi
być używany we wszystkich poleceniach następujących po poleceniu
otwarcia sesji.

„mid

. Pole to służy do multipleksowania komunikatów przesyłanych

pojedynczym połączeniem logicznym. Zazwyczaj wszystkie komuni-
katy pochodzą od tego samego procesu; w innym przypadku klient
używa pól pid i mid do jednoznacznej identyfikacji procesu i do usta-
lenia związku między nadchodzącymi odpowiedziami a uprzednio
wysłanymi żądaniami.

„wct

. Jest to ilość 16-bitowych słów następujących po tym polu. Określa

to długość zmiennej części polecenia SMB.

„vwv

. Zmienna liczba 16-bitowych słów. Rozmiar tego pola jest okre-

ślony przez poprzednie pole wct.

„bcc

. Jest to liczba bajtów, które następują po tym polu.

„buf

. Zmienna liczba bajtów. Rozmiar tego pola jest określony przez

poprzednie pole bcc.

Infrastruktura protokołów TCP/IP w sieciach Windows

37

Wartości pola flg

Pole flg może zawierać następujące wartości:

„bit 0

. Jeśli zostanie ustawiony przez serwer podczas negocjowania

protokołu, oznacza, że serwer obsługuje dialekt posiadający polecenia
"blokuj i czytaj" oraz "zapisz i odblokuj", zdefiniowane w rozszerzeniu
protokołu dzielenia zasobów SMB wersja 2.0, wersja dokumentu 3.2.

„bit 1

. Jeśli zostanie ustawiony przez klienta podczas negocjacji proto-

kołu, wówczas klient gwarantuje, że posiada taki bufor odbiorczy, że
serwer może użyć "send.no.ack" w odpowiedzi na żądanie klienta.
Readresator LANMAN 1.2 dla OS/2 nie ustawia tego bitu.

„bit 2

. Jest zarezerwowany i musi być wyzerowany.

„bit 3

. Jeśli jest ustawiony, wówczas wszystkie ścieżki do plików muszą

być traktowane tak, jakby wielkość liter nie miała znaczenia. Jeśli jest
wyzerowany, wówczas wielkość liter w ścieżkach jest rozróżniana.
Umożliwia to przekazywanie komunikatów protokołu poprzez różne
obwody logiczne, które mogą być wrażliwe na wielkość liter. Readre-
sator LANMAN 1.2 dla OS/2 zawsze ustawia ten bit.

„bit 4

. Jeśli jest ustawiony, wówczas podczas ustanawiania sesji

wszystkie ścieżki dostępu wysyłane do serwera są już w formacie ka-
nonicznym używanym przez OS/2 i NT. Oznacza to, że nazwy pli-
ków/katalogów są pisane dużymi literami i zawierają tylko dozwolo-
ne znaki, a separatorem jest znak backslash (\).

„bit 5

. W poleceniach "otwórz plik", "utwórz plik", oraz "stwórz nowy

plik" w wersji Core protokołu, ustawienie tego bitu oznacza, że klient
prosi o "okazyjne" zablokowanie tego pliku, jeśli jest jedynym klien-
tem, który otwiera plik w momencie żądania dostępu. Jeśli serwer
przyzna blokadę pliku, w odpowiedzi powinien poinformować o tym
klienta ustawiając ten bit.

„bit 6

. W poleceniach "otwórz plik", "utwórz plik", oraz "stwórz nowy

plik" w wersji Core protokołu, ustawienie tego bitu oznacza, że serwer
powinien informować klienta o każdym działaniu, które mogłoby
usunąć plik, przemianować go czy zmienić jego atrybuty. Jeśli jest
wyzerowany, wówczas serwer informuje klienta tylko o innym żąda-
niu otwarcia pliku.

„bit 7

. Jeśli jest ustawiony, wówczas komunikat jest wysyłany z serwera

w odpowiedzi na żądanie klienta. Pole com zazwyczaj zawiera taką
samą wartość w żądaniu klienta jak w skojarzonej z nim odpowiedzi
serwera; ten bit pozwala na jednoznaczne odróżnienie żądania od od-
powiedzi. W multipleksowanym obwodzie logicznym na węźle, gdzie

Rozdział 2

38

aktywny jest zarazem serwer i klient, system rozsyłający polecenia
SMB może użyć tego bitu, aby stwierdzić, czy komunikat należy skie-
rować do serwera, czy do klienta.

Wartości pola flg2

Pole flg2 może zawierać następujące wartości:

„bit 0

. Jeśli zostanie ustawiony przez klienta, wówczas działająca apli-

kacja rozumie nazwy plików w konwencji OS/2 i NT.

„bit 1

. Jeśli zostanie ustawiony przez klienta, wówczas działająca apli-

kacja rozumie rozszerzone atrybuty.

„bity 2

do 15. Są zarezerwowane i muszą być wyzerowane.

Polecenia SMB w polu com

W wersji Core protokołu SMB pole poleceń, com, zawiera wartości, które
można pogrupować w cztery kategorie:

„

Polecenia sterujące sesją. Odpowiedzialne są za rozpoczynanie i koń-
czenie komunikacji pomiędzy klientem a serwerem. Weryfikują rów-
nież wersję protokołu używaną przez komunikujące się jednostki.

„

Polecenia plikowe. Umożliwiają dostęp do katalogów i plików na
serwerze. Wydawane są po ustanowieniu sesji.

„

Polecenia drukowania. Umożliwiają klientowi wysyłanie plików na
drukarkę serwera i otrzymywanie informacji o stanie kolejki wydru-
ku.

„

Komunikaty. Umożliwiają aplikacji wysyłanie indywidualnych lub
grupowych zapytań.

Tabela 2.2 zawiera listę kodów dla niektórych poleceń SMB.

Tabela 2.2 Polecenia SMB w wersji Core

Polecenie Kod

Opis

SMBmkdir 0x00

Utwórz

katalog

SMBrmdir 0x01 Usuń katalog
SMBopen 0x02

Otwórz

plik

SMBcreate 0x03

Utwórz

plik

SMBclose 0x04

Zamknij

plik

SMBflush

0x05

Zapisz plik bezwarunkowo

Infrastruktura protokołów TCP/IP w sieciach Windows

39

Polecenie Kod

Opis

SMBunlink 0x06

Usuń plik

SMBmv 0x07

Przemianuj

plik

SMBgetatr

0x08

Pobierz atrybuty pliku

SMBsetatr

0x09

Ustaw atrybuty pliku

SMBread

0x0A

Czytaj z pliku

SMBwrite

0x0B

Zapisz do pliku

SMBlock

0x0C

Zablokuj zakres bajtów

SMBunlock

0x0D

Odblokuj zakres bajtów

SMBctemp

0x0E

Utwórz plik tymczasowy

SMBmknew

0x0F

Utwórz nowy plik

SMBchkpth 0x10 Sprawdź ścieżkę do katalogu
SMBexit 0x11 Zakończenie procesu
SMBlseek 0x12 Szukanie

pliku

SMBtcon 0x70

Podłączenie do drzewa

SMBtdis 0x71 Odłączenie od drzewa
SMBnegprot 0x72

Negocjacja

protokołu

SMBdskattr

0x80

Pobierz atrybuty dysku

SMBsearch 0x81 Przeszukaj

katalog

SMBsplopen

0xC0

Otwórz plik bufora wydruku

SMBsplwr 0xC1

Zapisz do pliku bufora wydruku

SMBsplclose

0xC2

Zamknij plik bufora wydruku

SMBsplretq 0xC3

Prześlij kolejkę wydruku

SMBsends 0xD0

Wyślij pojedynczy komunikat

SMBsendb 0xD1 Wyślij komunikat grupowy
SMBfwdname 0xD2

Przekaż nazwę użytkownika

SMBcancelf

0xD3

Zaniechaj przekazywania nazwy
użytkownika

SMBgetmac 0xD4

Pobierz

nazwę komputera

SMBsendstrt 0xD5

Początek wieloblokowego komunikatu

SMBsendend

0xD6

Koniec wieloblokowego komunikatu

SMBsendtxt

0xD7

Tekst wieloblokowego komunikatu

Tabela 2.3 zawiera polecenia dodane przez rozszerzony protokół dziele-
nia plików LANMAN 1.0.

Tabela 2.3 Polecenia rozszerzonego protokołu dzielenia plików LANMAN
1.0

Polecenie Kod

Opis

SMBlockread 0x13

Zablokuj i czytaj dane

Rozdział 2

40

Polecenie Kod

Opis

SMBwriteunlock 0x14

Zapisz i odblokuj dane

SMBreadBraw 0x1A

Odczytaj surowy blok

SMBreadBmpx 0x1B

Odczytaj blok (multipleksowane)

SMBreadBs 0x1C

Odczytaj blok (wtórna odpowiedź)

SMBwriteBraw 0x1D

Zapisz surowy blok

SMBwriteBmpx 0x1E

Zapisz blok (multipleksowane)

SMBwriteBs 0x1F

Zapisz blok (wtórne żądanie)

SMBwriteC

0x20

Zapis dokonany (odpowiedź)

SMBsetattrE

0x22

Ustaw rozszerzone atrybuty pliku

SMBgetattrE

0x23

Pobierz rozszerzone atrybuty pliku

SMBlockingX

0x24

Zablokuj/odblokuj zakres bajtów i X (zapis
iX oznacza, że polecenie może być łączone
z innymi i wysyłane jako pojedynczy
komunikat do serwera)

SMBtrans

0x25

Transakcja (nazwa, kierunek przepływu
danych)

SMBtranss 0x26

Transakcja

(wtórne

żądanie/odpowiedź)

SMBioctl 0x27

Przesyła IOCTL do serwera

SMBioctls 0x28

IOCTL

(wtórne

żądanie/odpowiedź)

SMBcopy 0x29

Kopiuj

SMBmove 0x2A

Przenieś

SMBecho 0x2B

Echo

SMBwriteclose

0x2C

Zapisz i zamknij

SMBopenX

0x2D

Otwórz i X

SMBreadX

0x2E

Czytaj i X

SMBwriteX

0x2F

Zapisz i X

SMBsesssetup

0x73

Ustanowienie sesji i X (łącznie
z logowaniem użytkownika)

SMBtconX 0x75

Podłącz do drzewa i X

SMBffirst 0x82

Znajdź pierwsze

SMBfunique 0x83

Znajdź unikalne

SMBfclose 0x84

Zamknij

szukanie

SMBinvalid 0xFE

Polecenie

nieważne

Polecenia dodane przez rozszerzony protokół dzielenia plików
LANMAN 1.2 opisane są w tabeli 2.4.

Infrastruktura protokołów TCP/IP w sieciach Windows

41

Tabela 2.4 Polecenia rozszerzonego protokołu dzielenia plików LANMAN
1.2

Polecenie Kod

Opis

SMBtrans2

0x32

Transakcja 2 (funkcja, kierunek przepływu
danych)

SMBtranss2

0x33

Transakcja 2 (wtórne żądanie/odpowiedź)

SMBfindclose

0x34

Zamknij przeszukiwanie katalogu

SMBfindnclose

0x35

Zamknij przeszukiwanie i powiadom

SMBulogoffX 0x74 Wylogowanie

użytkownika i X

NetBIOS, NetBEUI i NBF

Podczas projektowania NetBEUI w 1985 roku założono, że sieci lokalne
będą dzielone na grupy robocze zawierające od 20 do 200 komputerów,
a łączność pomiędzy nimi będą zapewniać routery. NetBEUI zoptymali-
zowano więc do obsługi segmentów sieci i nie zawarto w nim możliwości
trasowania (routingu). Microsoft utrzymuje, że ze wszystkich protokołów
dostarczanych z Windows NT NetBEUI jest najszybszy, jeśli w grę wcho-
dzi obsługa pojedynczego segmentu sieci.

Protokół NetBEUI zapewnia kontrolę przepływu, parametry regulacyjne
oraz detekcję błędów. Microsoft wyposaża w ten protokół wszystkie swo-
je produkty począwszy od pierwszego programu obsługi sieci, MS-Net,
wprowadzonego do sprzedaży w połowie lat osiemdziesiątych.

NetBEUI jest prekursorem protokołu NetBIOS Frame (NBF) zawartego
w Windows NT. NBF jest kompatybilny z istniejącymi sieciami opartymi
na LAN Manager, MS-Net oraz Lan Server firmy IBM. W Windows NT
interfejs NetBIOS jest obsługiwany w podsystemach MS-DOS, Win16
oraz Win32.

NetBEUI jest rozszerzoną wersją protokołu NetBIOS używanego przez
takie sieciowe systemy operacyjne jak LAN Manager, LAN Server, Win-
dows for Workgroups, Windows 95 i Windows NT. Wersja NetBEUI
w Windows NT nazywana jest NBF (NetBIOS Frame). NetBEUI formali-
zuje ramkę transportową, która nigdy nie została znormalizowana
w NetBIOS, oraz dodaje pewne nowe funkcje do pierwotnego protokołu
NetBIOS. NetBEUI używa protokołu OSI LLC2 (Logical Link Control Class
2) do ramkowania informacji w warstwie łącza danych.

Protokół NetBEUI jest zdefiniowany w dokumencie "IBM Local Area
Network Technical Reference Manual". Pracuje ponad standardowym
protokołem łącza danych 802.2, używając ramkowania LLC2. Ponieważ
protokół łącza danych 802.2 jest nietrasowalny (not routable), NetBEUI

Rozdział 2

42

również jest nietrasowalny. Było to największą wadą wczesnych sieci
opartych na NetBIOS, takich jak np. Lan Manager, i główną przyczyną,
dla której nigdy nie odniosły one znaczącego sukcesu na rynku.

We wczesnych latach dziewięćdziesiątych Novell dostrzegł konieczność
współpracy Windows for Workgroups i LAN Manager z NetWare
i opracował metodę pracy NetBIOS ponad IPX. Umożliwiło to aplikacjom
NetBIOS pracę w złożonych sieciach, ponieważ IPX jest protokołem tra-
sowalnym. Microsoft zaadaptował tę metodę w Windows for Workgro-
ups i Windows NT. Później opublikowano dokumenty RFC 1001 i RFC
1002, które definiowały metodę pracy NetBIOS ponad TCP/IP. Sieci
Microsoft Windows w przedsiębiorstwach zazwyczaj używają NetBIOS
ponad TCP/IP.

W Windows zawarta jest wersja 3.0 protokołu NetBEUI. Koryguje ona
niektóre ograniczenia poprzednich wersji.

NetBEUI 3.0 wraz z warstwą interfejsu sterownika transportu, eliminuje
poprzednie ograniczenie do 254 sesji na pojedynczej karcie sieciowej
w serwerze. NetBEUI 3.0 zawiera mechanizmy autoregulacji i nie wyma-
ga ręcznego zmieniania parametrów komunikacyjnych. Dzięki więk-
szym przesuwnym oknom i mechanizmom zegarowym kompensującym
opóźnienia w transmisji zapewnia dużo lepszą sprawność w przypadku
wolnych łącz niż poprzednie wersje protokołu.

Mówiąc ściśle, NetBEUI 3.0 nie jest tak naprawdę wersją NetBEUI, ale
protokołem formatu NBF. NetBEUI używa interfejsu NetBIOS jako inter-
fejsu górnego poziomu, ale NBF odpowiada specyfikacji Interfejsu Ste-
rownika Transportu TDI. NBF jest kompatybilne z wersjami NetBEUI
zawartymi w poprzednich produktach Microsoft i może z nimi współ-
pracować.

NetBEUI nie posiada typu adresowania, który umożliwiałby przekazy-
wanie pakietów w trasowanych sieciach, ale interfejs NetBIOS można
zaadaptować do protokołów mających takie mechanizmy - np. IPX lub
TCP/IP. Przystosowanie interfejsu NetBIOS do TCP/IP omawiają doku-
menty RFC 1001 i RFC 1002.

NetBEUI uważa się za efektywny protokół do obsługi małych sieci, skła-
dających się z kilkunastu komputerów osobistych. W sieciach rozległych
jego wydajność jest gorsza. Chociaż NetBEUI jest nietrasowalny, można
używać go w sieciach rozległych przy zastosowaniu zdalnych mostków.
Zalecaną metodą tworzenia sieci jest użycie NetBEUI wraz z innym pro-
tokołem - jak np. TCP/IP - w każdym komputerze, który powinien mieć
możliwość dostępu do innych komputerów sieci rozległej. W przypadku
zainstalowania dwóch protokołów na każdym komputerze i ustawienia
NetBEUI jako protokołu podstawowego, Windows NT używa NetBEUI

Infrastruktura protokołów TCP/IP w sieciach Windows

43

do komunikacji pomiędzy komputerami Windows NT w danym segmen-
cie sieci, a TCP/IP do komunikacji poprzez routery z innymi segmentami
sieci rozległej.

Tabela 2.5 podaje najpopularniejsze sieciowe systemy operacyjne używa-
jące interfejsu NetBIOS.

Tabela 2.5 Sieciowe systemy operacyjne używające NetBIOS

Producent

Sieciowy system operacyjny

Microsoft

MS LAN Manager, Windows for Workgroups, Windows 9x
i Windows NT

Hewlett-Packard

HP LAN Manager and Resource Sharing

IBM LAN

Server

Digital Pathworks

Struktura Pakietu NetBEUI

Polecenia NetBIOS z punktu widzenia protokołów transportu są interfej-
sem warstwy sesji. Standardowym protokołem używanym do przesyła-
nia poleceń NetBIOS jest NetBEUI. NetBEUI jest bezpośrednio przeno-
szony w ramce warstwy łącza danych. Posiada dwa formaty pakietów:
pierwszy format pakietu używa ramki nienumerowanej informacji (UI)
protokołu sterowania łączem danych IEEE 802.2 i zapewnia usługi bez-
połączeniowe (datagramowe). Drugi format pakietu używa ramki infor-
macji (I) protokołu sterowania łączem logicznym IEEE 802.2 i zapewnia
usługi połączeniowe (obwody logiczne). Usługa datagramowa nie jest
gwarantowana - nie można zakładać, że pakiety NetBEUI zostaną do-
starczone do miejsca przeznaczenia. Usługa połączeniowa gwarantuje
natomiast dostarczenie danych.

Rysunek 2.9 pokazuje strukturę ramki NetBEUI. Ramka NetBEUI jest
obudowana ramką LLC IEEE802.2. Ramka LLC (patrz rysunek 2.10) za-
wiera wartość F0 (szesnastkowo) w polu DSAP (Destination Service Access
Point) oraz wartość F0 w polu SSAP (Source Service Access Point). Pole
sterujące (Control) wskazuje na typ ramki - czy jest to ramka informacji
(I), czy nienumerowanej informacji (UI).

Pole polecenia (CMD) w pierwotnej wersji ramki NetBEUI może zawierać
22 różne kody poleceń. Kody poleceń NetBEUI wynoszą od 00 do 13
(szesnastkowo) w przypadku ramek typu UI, oraz od 14 do 1F
w przypadku ramek typu I.

Tabela 2.6 przedstawia polecenia NetBIOS.

Rozdział 2

44

Zagadnienia wydajności NBF

NBF używa dwóch technik zwiększania wydajności połączeń:
„

samoregulujące okna przesuwne

„

zegary sterujące

Techniki te opisano w kolejnych podrozdziałach.

Rysunek 2.9

Struktura
ramki Net-
BEUI

Rysunek
2.10

Obudowanie
ramki Net-
BEUI przez
pakiet LLC

Tabela 2.6 Polecenia NetBIOS

Nazwa ramki

Kod ramki Funkcja

ADD_GROUP_NAME_QUERY

0x00

Sprawdza, czy w sieci nie ma
dwóch takich samych nazw grup.

ADD_NAME_QUERY 0x01

Sprawdza, czy w sieci nie ma
dwóch takich samych nazw.

NAME_IN_CONFLICT

0x02

Wykryto zduplikowane nazwy.

ADD_NAME_RESPONSE 0x0D

Odpowiedź negatywna -
wskazuje, że dodana nazwa jest
duplikatem.

NAME_QUERY 0x0A

Żądanie zlokalizowania nazwy
w sieci.

NAME_RECOGNIZED 0x0E

Nazwa

rozpoznana

w odpowiedzi na
NAME_QUERY.

SESSION_ALIVE

0x0F

Sprawdza, czy sesja jest wciąż
aktywna.

SESSION_CONFIRM 0x17 Potwierdzenie

polecenia

Infrastruktura protokołów TCP/IP w sieciach Windows

45

Nazwa ramki

Kod ramki Funkcja

SESSION_INITIALIZE.

SESSION_END 0x18 Zakończenie sesji.
SESSION_INITIALIZE 0x19 Ustanowienie

sesji.

DATA_ACK 0x14 Potwierdzenie

DATA_ONLY_LAST.

DATA_FIRST_MIDDLE 0x15 Dane

przesyłane w sesji

(pierwsza lub środkowa ramka).

DATAGRAM

0x08

Datagram wygenerowany przez
aplikację.

DATAGRAM_BROADCAST

0x09

Datagram w trybie broadcast
wygenerowany przez aplikację.

DATA_ONLY_LAST 0x16 Dane

przesyłane w sesji (jedyna

lub ostatnia ramka).

NO_RECEIVE 0x1A

Brak polecenia RECEIVE.

RECEIVE_CONTINUE 0x1C Wskazuje

RECEIVE_OUTSTANDING.

RECEIVE_OUTSTANDING 0x1B

Retransmituje ostatnio wysłane
dane.

STATUS_QUERY

0x03

Pytanie o stan zdalnego węzła.

STATUS_RESPONSE

0x0F

Informacja o stanie zdalnego
węzła.

TERMINATE_TRACE_REMOTE 0x07

Kończy śledzenie w zdalnym
węźle.

TERMINATE_TRACE_LOCAL_REM
OTE

0x13 Kończy śledzenie w zdalnym

i lokalnym węźle.

Adaptacyjny protokół przesuwnych okien

W celu zwiększenia wydajności NBF używa algorytmu przesuwnych
okien, który zmniejsza obciążenie sieci i zapewnia kontrolę przepływu
danych. Algorytm przesuwnych okien umożliwia nadawcy dynamiczne
dostrojenie ilości ramek LLC, które zostaną wysłane przed żądaniem
potwierdzenia. Rysunek 2.11 pokazuje ramki przepływające przez dwu-
kierunkowy kanał. Widać na nim pięć ramek podróżujących od nadawcy
do odbiorcy. Odbiorca może wysłać pojedyncze potwierdzenie (ACK) dla
ramki piątej, co oznacza potwierdzenie wszystkich ramek, od pierwszej
do piątej. Przesuwne okno może wówczas przesunąć się w prawo, ze-
zwalając na transmisję kolejnych pięciu ramek.

Rozdział 2

46

Rysunek 2.11

Samoregulujące
okno przesuwne

Jeśli nadawca wysyła tylko jedną ramkę do kanału komunikacyjnego
i musi czekać na jej potwierdzenie, wówczas możliwości kanału pozostają
niewykorzystane. Jeśli zaś może wysłać wiele ramek przed otrzymaniem
potwierdzenia, wówczas kanał jest w pełni wykorzystywany. Ramki
przepływają w przód kanału, a potwierdzenia otrzymanych ramek po-
dróżują do tyłu. Liczba ramek, które nadawca może wysłać przed otrzy-
maniem potwierdzenia, jest nazywana oknem nadawania.

Zazwyczaj NBF nie ustawia okna odbioru, chyba że wykryje, że na zdal-
nym komputerze pracuje wersja IBM LAN Server, która nigdy nie wysyła
zapytań. W takim przypadku NBF używa okna odbioru opartego na
parametrze MaximumIncomingFrames zapisanym w Rejestrze. Algorytm
przesuwnego okna próbuje określić rozmiar okna nadawania, który był-
by optymalny dla bieżących warunków w sieci; okno powinno być tak
duże, żeby osiągnąć maksymalną przepustowość. Jeśli jednak okno bę-
dzie zbyt duże, odbiorca z powodu nadmiernego obciążenia może zacząć
odrzucać ramki. Powoduje to zwiększenie ruchu w sieci, ponieważ zgu-
bione ramki muszą być retransmitowane.

Zgubione ramki mogą powodować problemy w przypadku wolnych łącz
lub w sytuacji, w której ramki przechodzą przez kilka przekaźników
w drodze do miejsca przeznaczenia. Gubienie ramek w połączeniu
z dużymi oknami nadawania powoduje częste retransmisje, co pogarsza
i tak już niekorzystne warunki ruchu w sieci. Ograniczenie wielkości
okna nadawania pomaga zmniejszyć ruch i uniknąć zablokowania sieci.

Infrastruktura protokołów TCP/IP w sieciach Windows

47

Zegary sterujące

NBF używa trzech zegarów: zegara odpowiedzi (T1), zegara potwier-
dzenia (T2) oraz zegara braku aktywności (Ti). Zegary te ułatwiają kon-
trolowanie ruchu w

sieci. Ich praca określona jest przez wpisy

DefaultT1Timeout

, DefaultT2Timeout i DefaultTiTimeout w Rejestrze Win-

dows, których wartości określa następująca reguła:

T2<=T1<=Ti

Zegar odpowiedzi (T1) określa, jak długo nadawca powinien czekać za-
nim założy, że została zgubiona ramka informacji (I). Po T1 milisekun-
dach NBF wysyła ramkę RR (Receiver Ready), która nie została potwier-
dzona i podwaja wartość T1. Jeśli ramka RR nie zostanie potwierdzona
po liczbie retransmisji określonej przez parametr LLCRetries, łącze jest
zrywane.

Kiedy ruch powrotny nie pozwala odbiorcy wysłać ramki informacji (I)
w określonym limicie czasowym, rozpoczyna odliczanie zegar potwier-
dzenia (T2), a następnie wysyłane jest potwierdzenie. Standardowo war-
tość zegara T2 wynosi 150 milisekund. Jeśli odbiorca musi czekać na start
zegara T2, aby otrzymać odpowiedź, wtedy podczas jego oczekiwania na
potwierdzenie łącze może nie być w pełni wykorzystane. Jest to rzadka
sytuacja, ale może zdarzyć się na wolnych łączach. Jeśli jednak wartość
T2 jest zbyt niska, wówczas startuje on i wysyła potwierdzenia niepo-
trzebnie zwiększając ruch w sieci. NBF jest zoptymalizowany w ten spo-
sób, że ostatnia ramka wysyłana przez nadawcę ma ustawiony bit POLL
(zapytania), wymuszając natychmiastowe wysłanie potwierdzenia przez
odbiorcę.

Zegar braku aktywności (Ti) używany jest do stwierdzenia, czy łącze
jeszcze pracuje. Standardową wartością Ti jest 30 sekund. Po Ti milise-
kundach bez aktywności na łączu NBF wysyła ramkę zapytania; jeśli
zostanie ona potwierdzona, łącze jest nadal podtrzymywane.

Limit sesji NetBIOS

Standardowy NetBIOS posiada limit 254 sesji. Jest to związane
z rozmiarem zmiennej w architekturze NetBIOS, nazywanej Lokalnym
Numerem Sesji (Local Session Number, LSN). LSN zajmuje jeden bajt, co
ogranicza go do zakresu 0...255, przy czym niektóre wartości są zarezer-
wowane do celów systemowych.

Kiedy dwa komputery ustanawiają sesję przy użyciu NBF, wówczas
wymieniają numery LSN. Każdy z komputerów może podać inny numer
LSN; nie muszą one być takie same, ale komputer zawsze używa tego

Rozdział 2

48

samego numeru LSN w danej sesji. Numer ten jest przypisywany, kiedy
komputer wykonuje polecenie CALL NCB (wywołanie połączenia). Kom-
puter wywołujący przekazuje LSN do komputera nasłuchującego
w pierwszej wysyłanej ramce. Na rysunku 2.12 pokazano wymianę ra-
mek podczas ustanawiania sesji.

Jako pierwsza przesyłana jest ramka NameQuery (zapytanie o nazwę).
W poprzednich implementacjach NetBIOS ramka ta była rozsyłana do
wszystkich węzłów sieci. Wszystkie komputery odczytują ramkę, spraw-
dzają, czy posiadają odpowiednią nazwę w swojej przestrzeni nazw, i czy
z tą nazwą związane jest oczekujące polecenie LISTEN NCB (nasłuchiwa-
nie połączenia). Jeśli tak jest, komputer wybiera dla siebie nowy numer
LSN, który umieszcza w ramce odpowiedzi, a następnie wykonuje pole-
cenie LISTEN NCB, przekazując wygenerowany przed chwilą numer.
Chociaż oba komputery znają numer LSN partnera, nie jest on przez nie
wykorzystywany - znacznie ważniejszą informacją są adresy sieciowe
komputerów, zawarte w wymienianych ramkach. Każdy z komputerów
poznaje adres sieciowy partnera odczytując pole adresu źródłowego
ramce; jest to forma określania adresu sieciowego, w której adres nadaw-
cy określa się badając adres źródłowy. Protokół NBF zapamiętuje adres
sieciowy zdalnego partnera, aby następne ramki można było adresować
już bezpośrednio.

Rysunek 2.12

Rozsyłanie
NameQuery
w trybie broadcast

Windows NT również musi używać ramki NameQuery do nawiązania
połączeń ze zdalnymi komputerami poprzez NBF; w przeciwnym przy-
padku nie mógłby odnaleźć istniejących serwerów i stacji roboczych.
Ramka NameQuery musi zawierać jednobajtowy numer LSN. Jednakże
każdy proces pracujący w Windows NT może komunikować się z mak-
symalnie 254 komputerami, podczas gdy w poprzednich implementa-
cjach NetBIOS limit ten dotyczył całego komputera. Stacje robocze
i serwery Windows NT unikają tego problemu przekazując dane bezpo-

Infrastruktura protokołów TCP/IP w sieciach Windows

49

średnio do interfejsu sterownika transportu (TDI) zamiast wywoływania
NetBIOS. Wszystkie wywołania TDI odbywają się przez 32-bitowy,
uchwytowo zorientowany interfejs.

NBF posiada także specjalną metodę zarządzania zasobami, która umoż-
liwia utworzenie nielimitowanej ilości połączeń. Opisujemy ją w następ-
nym podrozdziale.

Metoda obejścia limitu 254 sesji

NBF radzi sobie z limitem 254 sesji przy użyciu kombinacji dwóch tablic,
jednej utrzymywanej przez NBF, a drugiej przez NetBIOS.

NBF tworzy dwuwymiarową tablicę, którą pokazano na rysunku 2.13.
Wzdłuż jej boku umieszczone są numery LSN od 1 do 254. Wzdłuż gór-
nej krawędzi umieszczone są adresy sieciowe komputerów, z którymi
nawiązano sesje. W komórce na przecięciu LSN i adresu sieciowego
umieszczony jest uchwyt TDI, wskazujący na proces, który zapoczątko-
wał połączenie (albo CALL, albo LISTEN).

Rysunek 2.13

Metoda implementa-
cji tablicy NBF

Należy zauważyć, że tablica i jej zawartość są tylko modelem ilustrują-
cym funkcjonowanie NBF. Rzeczywista implementacja używa wydajniej-
szej metody przechowywania danych, takiej jak używana w tabelach
przestawnych.

Rozdział 2

50

Metoda ta używana jest tylko w połączeniach przy użyciu NBF. Połączenia
NetBIOS dokonywane przy użyciu TCP/IP są obsługiwane w inny sposób.

Ramka NameQuery w Windows NT zawiera numer LSN związany
z uchwytem TDI, który jest przekazywany poleceniom CALL lub LISTEN
NCB

. W przypadku CALL numer LSN nie jest rozsyłany do wszystkich

węzłów, ale adresowany bezpośrednio do odbiorcy.

NBF pobiera adres sieciowy (umieszczany następnie w tablicy) odbiorcy
z ramki NameQuery (wysłanej przez polecenie oczekujące LISTEN) pod-
czas wykonywania polecenia CALL.

Jak pokazuje rysunek 2.14, NBF używa dwóch ramek NameQuery. Poniż-
sze punkty odpowiadają numerom na rysunku:

1. W pierwszej ramce NameQuery numer LSN wynosi 0, co oznacza for-

mat FindName (szukanie nazwy). Ramka ta jest wysyłana do wszyst-
kich węzłów sieci. Kiedy zdalny komputer odpowie na ramkę, NBF
otrzymuje jego adres sieciowy, który umieszcza w tablicy.

2. Następna ramka NameQuery jest wysyłana bezpośrednio do zdalnego

komputera, przy czym numer LSN jest związany z poleceniem CALL.
Ramka FindName jest zwracana przez zdalny komputer, nawet jeśli nie
ma polecenia LISTEN oczekującego na daną nazwę.

3. Jeśli nie ma polecenia LISTEN oczekującego na daną nazwę, wtedy

wysyłana jest ramka (3).

NBF musi uporać się z jeszcze jednym problemem - numer LSN zawarty
w tablicy nie może być bezpośrednio zwrócony procesowi, który wydał
polecenie CALL lub LISTEN, ponieważ NBF mogło użyć danej wartości
LSN do ustanowienia połączeń z wieloma zdalnymi komputerami. Win-
dows NT musi zwrócić każdemu procesowi numer LSN, który jedno-
znacznie określi jego sesję.

Infrastruktura protokołów TCP/IP w sieciach Windows

51

Rysunek 2.14

Dwie ramki NameQuery
w NBF używanym
w Windows NT

Rysunek 2.15

NETBIOS.SYS i TDI

Do określenia, pod jaki adres sieciowy i numer LSN należy wysyłać ram-
ki, NBF używa uchwytu TDI. Każdy proces ma własny zbiór numerów
LSN. Musi więc istnieć jeszcze jeden komponent pomiędzy wywołującym
procesem a interfejsem TDI, który przetłumaczy identyfikator procesu
i numer LSN na uchwyt TDI. Tym pośredniczącym komponentem jest
NETBIOS.SYS (patrz rysunek 2.15). Tablica utrzymywana przez
NETBIOS.SYS w istocie zawiera 254 numery LSN na jeden numer LANA
na proces. W Windows NT każda ścieżka powiązania (bindings) jest re-

Rozdział 2

52

prezentowana przez numer LANA. Tak więc każdy proces może mieć
254 numery LSN na numer LANA, czyli nie jest ograniczony do limitu
254 sesji.

NETBIOS.SYS tworzy tablicę, którą pokazano na rysunku 2.16. Wzdłuż
jej boku umieszczone są numery LSN, wzdłuż górnej krawędzi umiesz-
czone są identyfikatory procesów, a w komórkach umieszczone są
uchwyty TDI. Właśnie numer LSN z tej tablicy jest przekazywany wywo-
łującemu procesowi.

Dla przykładu rozważmy sytuację, w której komputer chce ustanowić
sesję ze zdalnym partnerem. Przed wydaniem polecenia CALL NCB pro-
ces musi najpierw wydać polecenie RESET NCB (zerowania), które mię-
dzy innymi sygnalizuje NETBIOS.SYS konieczność zarezerwowania miej-
sca w tablicy TDI. Następnie proces wydaje polecenie CALL NCB w celu
połączenia ze zdalnym komputerem. Polecenie to jest przekazywane
sterownikowi NETBIOS.SYS. Sterownik otwiera wówczas nowy uchwyt
TDI i przesyła polecenie NBF.

NBF wysyła pierwszą ramkę NameQuery z numerem LSN równym zeru,
aby odnaleźć zdalny komputer. Jeśli nadejdzie odpowiedź, uzyskuje się
z niej adres sieciowy zdalnego komputera, po czym tworzona jest nowa
kolumna w tablicy NBF. Następną ramkę NameQuery wysyła się bezpo-
średnio do zdalnego komputera. Jeśli nadejdzie odpowiedź, NBF zwraca
pozytywną odpowiedź na wywołanie TDI z poziomu NETBIOS.SYS;
NETBIOS.SYS z kolei zwraca wartość LSN ze swojej tabeli do wywołują-
cego procesu.

Ruch bezpołączeniowy w NetBIOS

Trzy rodzaje poleceń NetBIOS generują ruch bezpołączeniowy: określa-
nie nazw, przesyłanie datagramów i pozostałe polecenia, przesyłane jako
ramki nienumerowanej informacji (UI) w podwarstwie LLC.

Infrastruktura protokołów TCP/IP w sieciach Windows

53

Rysunek 2.16

Tablica
NETBIOS.SYS

Transmisje bezpołączeniowe, wymagające potwierdzenia ze zdalnego
komputera, przesyłane są przez NBF w pewnej liczbie ramek, zależnej od
polecenia. Liczba ta określona jest w Rejestrze przez wpisy definiujące
liczbę retransmisji, jak np. NameQueryRetries. Okresy pomiędzy wysyła-
niem kolejnych ramek określane są przez limity czasu, jak np.
NameQueryTimeout

.

Jako przykład użycia wartości definiujących liczbę retransmisji i limity
czasu rozważmy sytuację, w której Windows NT rejestruje nazwy kom-
puterów poprzez NBF używając polecenia NetBIOS ADD_NAME. Kiedy
NBF otrzyma polecenie ADD_NAME, wysyła do wszystkich węzłów sieci
ramki ADD_NAME_QUERY tyle razy, ile wynosi wartość AddNameQuery
Retries

, przy czym okres pomiędzy kolejnymi transmisjami jest określony

przez wartość AddNameQueryTimeout. Daje to komputerom w sieci wy-
starczającą ilość czasu, aby powiadomić nadawcę, czy nazwa jest już
zarejestrowana jako unikalna nazwa innego komputera lub grupy robo-
czej.

Kolejny podrozdział omawia wpisy Rejestru Windows NT, związane
z NBF. Można je znaleźć w Rejestrze pod następującą ścieżką:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf

Wpisy w Rejestrze dotyczące NBF

Parametry startowe transportu NBF znajdują się pod następującym pod
kluczem:

HKEY_LOCAL_MACHINE\SYSTEM\Services\NBF\Parameters

Rozdział 2

54

Wpisy o postaci InitXXXX definiują początkową alokację i rozmiar pa-
mięci przydzielanej usługom NBF, a wpisy o postaci MaxXXXX definiują
górne granice. W tym zakresie system samodzielnie reguluje wydajność.
Standardowo usługi NBF używają wszystkich zasobów koniecznych do
spełnienia żądań użytkowników, a kiedy nie są aktywne, wtedy ich zapo-
trzebowanie na zasoby jest niewielkie. Zmieniając wartości InitXXXX
zmieniamy początkowy przydział zasobów, co może nieznacznie przy-
spieszyć system, jeśli wiadomo, że będzie mocno obciążony. Zmieniając
wartości MaxXXXX możemy ograniczyć obciążenie serwera albo zmniej-
szyć ilość pamięci przeznaczoną na pracę w sieci.

Podane niżej wartości wpisów związanych z NBF można zmieniać przy
użyciu Edytora rejestru.

AddNameQueryRetries

Parametr ten określa, ile razy NBF będzie retransmitował ramki
ADD_NAME_QUERY

i ADD_GROUP_NAME_QUERY. Należy go zmienić

tylko wtedy, jeśli NBF rejestruje adresy w sieci gubiącej wiele pakietów.
Standardowa wartość parametru wynosi 3, przy czym jest to wartość
typu REG_DWORD. W Windows NT każdy wpis do rejestru posiada
związany z nim typ, np. REG_DWORD jest 32-bitową liczbą bez znaku.

AddNameQueryTimeout

Parametr ten określa odstęp czasu pomiędzy retransmisjami kolejnych
ramek ADD_NAME_QUERY i ADD_GROUP_NAME_QUERY. Należy go
zmienić tylko wtedy, jeśli NBF rejestruje adresy w powolnej sieci (lub
w

sieci z

powolnymi komputerami). Standardowa wartość wynosi

5000000 (500 milisekund). Parametr jest typu REG_DWORD i jest mierzo-
ny w 100-nanosekundowych jednostkach.

DefaultT1Timeout

Parametr określa początkową wartość zegara T1. Zegar T1 odmierza czas
oczekiwania przez NBF na odpowiedź po wysłaniu pakietu zapytania
LLC, zanim wyśle go ponownie. Parametr należy zmienić tylko wtedy,
jeśli NBF łączy się poprzez powolną sieć lub z powolnymi komputerami,
chociaż NBF powinien dostosować się do zmian w wartości parametru.
Standardowa wartość wynosi 6000000 (600 milisekund). Parametr jest
typu REG_DWORD i jest mierzony w 100-nanosekundowych jednost-
kach.

Infrastruktura protokołów TCP/IP w sieciach Windows

55

DefaultT2Timeout

Parametr określa początkową wartość zegara T2. Zegar T2 odmierza
czas, który NBF może odczekać po otrzymaniu pakietu zapytania LLC
zanim wyśle odpowiedź. Wartość powinna być niższa niż T1; ogólną
zasadą jest przyjęcie połowy wartości T1 lub mniej. Parametr należy
zmienić tylko wtedy, jeśli NBF łączy się poprzez powolną sieć lub
z powolnymi komputerami, chociaż NBF powinien dostosować się do
zmian wartości zegara. Standardowa wartość wynosi 1500000 (150 mili-
sekund). Parametr jest typu REG_DWORD i jest mierzony w 100-
nanosekundowych jednostkach.

DefaultTiTimeout

Parametr określa początkową wartość zegara Ti. Zegar Ti odmierza czas
braku aktywności. Kiedy jego wartość spadnie do zera, wówczas NBF
wysyła pakiet zapytania LLC, aby sprawdzić, czy łącze jest nadal aktyw-
ne. Parametr należy zmienić tylko wtedy, jeśli NBF pracuje w sieci, której
niezawodność ulega nagłym wahaniom, albo jeśli NBF łączy się poprzez
powolną sieć lub z powolnymi komputerami. Standardowa wartość wy-
nosi 300000000 (30 sekund). Parametr jest typu REG_DWORD i jest
mierzony w 100-nanosekundowych jednostkach.

GeneralRetries

Parametr ten określa, ile razy NBF będzie retransmitował ramki
STATUS_QUERY

i FIND_NAME. Należy go zmienić tylko wtedy, jeśli

NBF pracuje w sieci gubiącej wiele pakietów. Standardowa wartość wy-
nosi 3. Parametr jest typu REG_DWORD.

GeneralTimeout

Parametr ten określa odstęp czasu pomiędzy retransmisjami kolejnych
żądań STATUS_QUERY i FIND_NAME. Należy go zmienić tylko wtedy,
jeśli NBF pracuje w powolnej sieci (lub w sieci z powolnymi komputera-
mi). Standardowa wartość wynosi 5000000 (500 milisekund). Parametr
jest typu REG_DWORD i jest mierzony w 100-nanosekundowych jednost-
kach.

InitAddresses

Parametr ten określa początkową liczbę adresów, dla których należy
przydzielić miejsce w pamięci dostępnej dla NBF. Adresy odpowiadają
nazwom NetBIOS. Terminem adres określamy rzeczywistą nazwę,
a terminem plik adresu określamy klienta TDI używającego tej nazwy.
Zazwyczaj liczba adresów i plików adresów jest taka sama, ale jeśli

Rozdział 2

56

dwóch klientów otworzy ten sam adres, wtedy istnieją dwa pliki adresów
lecz tylko jeden adres. Parametr należy zmieniać tylko wtedy, jeśli będzie
potrzebna duża liczba adresów - w innych przypadkach system automa-
tycznie przydziela pamięć na adresy w miarę potrzeb. Standardowa war-
tość parametru wynosi 0, co oznacza brak limitu. Można go ustawić na 1
lub więcej. Parametr jest typu REG_DWORD.

InitFileAddresses

Parametr ten określa początkową liczbę plików adresów, dla których
należy przydzielić miejsce w pamięci dostępnej dla NBF. Parametr należy
zmieniać tylko wtedy, jeśli będzie potrzebna duża liczba plików adresów
- w innych przypadkach system automatycznie przydziela pamięć na
pliki adresów w miarę potrzeb. Standardowa wartość parametru wynosi
0, co oznacza brak limitu. Można go ustawić na 1 lub więcej. Parametr
jest typu REG_DWORD.

InitConnections

Parametr ten określa początkową liczbę połączeń, dla których należy
przydzielić miejsce w pamięci dostępnej dla NBF. Parametr należy zmie-
niać tylko wtedy, jeśli będzie potrzebna duża liczba połączeń - w innych
przypadkach system automatycznie przydziela pamięć na połączenia
w miarę potrzeb. Standardowa wartość parametru wynosi 1. Można go
ustawić na 0, co oznacza brak limitu, lub więcej. Parametr jest typu
REG_DWORD

.

InitLinks

Parametr ten określa początkową liczbę łącz LLC, dla których należy
przydzielić miejsce w pamięci dostępnej dla NBF. Zazwyczaj istnieje jed-
no połączenie na jedno łącze LLC z inną kartą sieciową, ponieważ re-
adresator umieszcza wszystkie łącza LLC do komputera w jednym połą-
czeniu. Może ich jednak być więcej, jeśli komunikują się ze sobą dwa
komputery albo pracuje aplikacja NetBIOS. Parametr należy zmieniać
tylko wtedy, jeśli będzie potrzebna duża liczba łącz LLC - w innych
przypadkach system automatycznie przydziela pamięć na łącza w miarę
potrzeb. Standardowa wartość parametru wynosi 2. Można go ustawić na
0, co oznacza brak limitu, lub więcej. Parametr jest typu REG_DWORD.

InitReceiveBuffers

Parametr ten określa początkową liczbę buforów odbioru, dla których
należy przydzielić miejsce w pamięci. Bufory odbioru są używane przez
NBF, kiedy wywołuje funkcję NDIS TransferData żeby pobrać nadesłane

Infrastruktura protokołów TCP/IP w sieciach Windows

57

datagramy. Zazwyczaj pamięć jest przydzielana w miarę potrzeb, ale
można zarezerwować ją wstępnie jeśli wiadomo, że nadsyłana będzie
duża liczba ramek zawierających datagramy. Standardowa wartość pa-
rametru wynosi 5. Można go ustawić na 0, co oznacza brak limitu, lub
więcej. Parametr jest typu REG_DWORD.

InitReceivePackets

Parametr ten określa początkową liczbę pakietów odbioru, dla których
należy przydzielić miejsce w pamięci. Pakiety odbioru są używane przez
NBF, kiedy wywołuje funkcję NDIS TransferData żeby pobrać nadesłane
dane. Zazwyczaj pamięć jest przydzielana w miarę potrzeb, ale można
zarezerwować ją wstępnie, jeśli wiadomo, że nadsyłana będzie duża licz-
ba ramek nienumerowanej informacji (UI). Standardowa wartość para-
metru wynosi 10. Można go ustawić na 0, co oznacza brak limitu, lub
więcej. Parametr jest typu REG_DWORD.

InitRequests

Parametr ten określa początkową liczbę żądań, dla których należy przy-
dzielić miejsce w pamięci dostępnej dla NBF. Pamięci żądań używa się
do obsługi żądań nawiązania połączeń, zapytań o stan zdalnego kompu-
tera, żądań odszukania nazwy itp. Parametr należy zmieniać wtedy, jeśli
będzie potrzebna obsługa dużej liczby żądań - w innych przypadkach
system automatycznie przydziela pamięć na żądania w miarę potrzeb.
Standardowa wartość parametru wynosi 5. Można go ustawić na 0, co
oznacza brak limitu, lub więcej. Parametr jest typu REG_DWORD.

InitSendPackets

Parametr ten określa początkową liczbę pakietów nadawania, dla których
należy przydzielić miejsce w pamięci. Pakiety nadawania są używane
przez NBF, kiedy w imieniu klienta wysyła dane w trybie połączenio-
wym. Zazwyczaj pamięć jest przydzielana w miarę potrzeb, ale można
zarezerwować ją wstępnie, jeśli wiadomo, że będzie wysyłana duża licz-
ba ramek danych, albo jeśli w programie Performance Monitor pojawia
się wiele komunikatów "send packets exhausted". Standardowa wartość
parametru wynosi 30. Można go ustawić na 0, co oznacza brak limitu, lub
więcej. Parametr jest typu REG_DWORD.

InitUIFrames

Parametr ten określa początkową liczbę ramek UI, dla których należy
przydzielić miejsce w pamięci. Ramki UI są używane przez NBF podczas
nawiązywania połączeń i świadczenia usług datagramowych. Zazwyczaj

Rozdział 2

58

pamięć jest przydzielana w miarę potrzeb, ale można zarezerwować ją
wstępnie jeśli wiadomo, że będzie potrzebna duża liczba ramek UI. Stan-
dardowa wartość parametru wynosi 30. Można go ustawić na 5, co ozna-
cza brak limitu, lub więcej. Parametr jest typu REG_DWORD.

LLCMaxWindowSize

Parametr ten określa liczbę ramek I, które NBF może wysłać przed prze-
słaniem zapytania i oczekiwaniem na odpowiedź ze zdalnego kompute-
ra. Parametr należy zmieniać tylko wtedy, jeśli NBF pracuje w sieci, któ-
rej niezawodność ulega nagłym wahaniom. Standardowa wartość para-
metru wynosi 10. Można go ustawić na 0, co oznacza brak limitu, lub
więcej. Parametr jest typu REG_DWORD.

LLCRetries

Parametr ten określa, ile razy NBF prześle zapytanie do zdalnego kom-
putera po przekroczeniu limitu czasu przez zegar T1. Po tej ilości nie-
udanych prób łącze jest zamykane. Parametr należy zmieniać tylko wte-
dy, jeśli NBF pracuje w sieci, której niezawodność ulega nagłym waha-
niom. Standardowa wartość parametru wynosi 8. Można go ustawić na 0,
co oznacza brak limitu, lub więcej. Parametr jest typu REG_DWORD.

MaxAddresses

Parametr ten określa maksymalną liczbę adresów, dla których należy
przydzielić miejsce w pamięci dostępnej dla NBF. Adresy są nazwami
NetBIOS rejestrowanymi w sieci przez NBF. Terminem adres określamy
rzeczywistą nazwę, a terminem plik adresu określamy klienta TDI uży-
wającego tej nazwy. Parametr można zmieniać w celu precyzyjnej regula-
cji ilości pamięci używanej przez NBF. Zazwyczaj używa się go do kon-
troli zasobów używanych przez adresy w przypadku nielimitowanego
dostępu do zasobów dla NBF. Standardowa wartość parametru wynosi 0,
co oznacza brak limitu. Można go ustawić na 1 lub więcej. Parametr jest
typu REG_DWORD.

MaxAddressFiles

Parametr ten określa maksymalną liczbę plików adresu, dla których na-
leży przydzielić miejsce w pamięci dostępnej dla NBF. Każdy plik adresu
odpowiada klientowi otwierającemu adres. Parametr można zmieniać
w celu precyzyjnej regulacji ilości pamięci używanej przez NBF. Zazwy-
czaj używa się go do kontroli zasobów używanych przez pliki adresów
w przypadku nielimitowanego dostępu do zasobów dla NBF. Standar-

Infrastruktura protokołów TCP/IP w sieciach Windows

59

dowa wartość parametru wynosi 0, co oznacza brak limitu. Można go
ustawić na 1 lub więcej. Parametr jest typu REG_DWORD.

MaxConnections

Parametr ten określa maksymalną liczbę połączeń, dla których należy
przydzielić miejsce w pamięci dostępnej dla NBF. Połączenia są ustana-
wiane pomiędzy klientami NBF i podobnymi programami pracującymi
na zdalnych komputerach. Parametr można zmieniać w celu precyzyjnej
regulacji ilości pamięci używanej przez NBF. Zazwyczaj używa się go do
kontroli zasobów używanych przez połączenia w przypadku nielimito-
wanego dostępu do zasobów dla NBF. Standardowa wartość parametru
wynosi 0, co oznacza brak limitu. Można go ustawić na 1 lub więcej. Pa-
rametr jest typu REG_DWORD.

MaximumIncomingFrames

Parametr ten używany jest w niektórych przypadkach, aby kontrolować
liczbę ramek, które NBF odbierze przed wysłaniem potwierdzenia do
zdalnego komputera. Zazwyczaj NBF automatycznie wykrywa, kiedy
należy wysłać potwierdzenie; czasem jednak podczas komunikacji
z komputerami używającymi Microsoft LAN Manager lub IBM LAN
Server, które mają ustawioną bardzo niską wartość parametru maxout,
parametr ten można ustawić na wartość równą lub niższą w celu popra-
wienia wydajności sieci. Parametr ten odpowiada z grubsza parametrowi
maxin w Microsoft LAN Manager. Wartość parametru równa 0 wyłącza
kontrolę liczby odbieranych ramek, co jest zwykłym zachowaniem proto-
kołu NBF. Podczas komunikacji z większością zdalnych komputerów
parametr ten nie jest używany. Standardowa wartość parametru wynosi
2. Można go ustawić na 1 lub więcej. Parametr jest typu REG_DWORD.

MaxLinks

Parametr ten określa maksymalną liczbę łącz, dla których należy przy-
dzielić miejsce w pamięci dostępnej dla NBF. Łącza są ustanawiane
z każdym zdalnym komputerem, z którym NBF się komunikuje. Para-
metr można zmieniać w celu precyzyjnej regulacji ilości pamięci używa-
nej przez NBF. Zazwyczaj używa się go do kontroli zasobów używanych
przez łącza w przypadku nielimitowanego dostępu do zasobów dla NBF.
Standardowa wartość parametru wynosi 0, co oznacza brak limitu. Moż-
na go ustawić na 1 lub więcej. Parametr jest typu REG_DWORD.

Rozdział 2

60

MaxRequests

Parametr ten określa maksymalną liczbę żądań, dla których należy przy-
dzielić miejsce w pamięci dostępnej dla NBF. NBF używa żądań do ob-
sługi operacji wysyłania, odbierania, łączenia i nasłuchiwania. Parametr
można zmieniać w celu precyzyjnej regulacji ilości pamięci używanej
przez NBF. Zazwyczaj używa się go do kontroli zasobów używanych
przez żądania w przypadku nielimitowanego dostępu do zasobów dla
NBF. Standardowa wartość parametru wynosi 0, co oznacza brak limitu.
Można go ustawić na 1 lub więcej. Parametr jest typu REG_DWORD.

NameQueryRetries

Parametr ten określa, ile razy NBF będzie retransmitował ramki
NAME_QUERY

. Należy go zmienić tylko wtedy, jeśli NBF łączy się

z komputerami przez sieć gubiącą wiele pakietów. Standardowa wartość
parametru wynosi 3. Parametr jest typu REG_DWORD.

AddNameQueryTimeout

Parametr ten określa odstęp czasu pomiędzy retransmisjami kolejnych
ramek NAME_QUERY. Należy go zmienić tylko wtedy, jeśli NBF łączy
się z powolnymi komputerami lub poprzez powolną sieć. Standardowa
wartość wynosi 5000000 (500 milisekund). Parametr jest typu
REG_DWORD

i jest mierzony w 100-nanosekundowych jednostkach.

QueryWithoutSourceRouting

Parametr ten instruuje NBF, żeby podczas pracy ze sterownikiem Token
Ring wysyłał zapytania bez zapisywania w ramkach adresu źródłowego.
Umożliwia to funkcjonowanie sprzętowym mostkom, które nie mogą
przekazywać ramek zawierających adres źródłowy. Standardową warto-
ścią jest 0 (fałsz). Parametr można uaktywnić przypisując mu wartość 1
(prawda). Parametr jest typu REG_DWORD.

WanNameQueryRetries

Parametr ten określa, ile razy NBF będzie retransmitował ramki
NAME_QUERY

podczas łączenia się z RAS (Remote Access Services). Nale-

ży go zmienić tylko wtedy, jeśli NBF łączy się z komputerami przez sieć
gubiącą wiele pakietów. Standardowa wartość parametru wynosi 5. Pa-
rametr jest typu REG_DWORD. Usługi RAS omawia rozdział 12, "Dostęp
do Internetu przy użyciu RAS i PPTP".

Infrastruktura protokołów TCP/IP w sieciach Windows

61

Protokół TCP/IP

Protokół TCP/IP zawiera następujące komponenty: IP, TCP oraz UDP.

Wersja beta 1 Windows NT 5 zawiera kilka ulepszeń w obsłudze proto-
kołu w stosunku do poprzednich wersji systemu. Są to między innymi
większe rozmiary okien transmisji, użycie selektywnych potwierdzeń
oraz lepsze szacowanie czasu drogi powrotnej.

Duże rozmiary okna umożliwiają Windows NT wysyłanie dużych ilości
danych bez oczekiwania na potwierdzenie. Kontrola przepływu pozosta-
je w gestii odbiorcy, który zaleca dynamiczne zmiany rozmiaru okna.

Selektywne potwierdzenia umożliwiają odbiorcy poinformowanie
nadawcy o brakujących fragmentach danych.

Czas drogi powrotnej jest obliczany, aby nadawca mógł przewidzieć, że
odbiorca nie otrzymał danego segmentu i wysłać go ponownie.

Poniższe rozdziały zwięźle omawiają protokoły TCP, IP i UDP.

Protokół IP

IP jest protokołem warstwy sieci, który zapewnia bezpołączeniowe usługi
datagramowe ponad różnymi protokołami łącza danych (patrz rysunek
2.17).

IP nie gwarantuje dostarczenia datagramów; podejmuje tylko próbę do-
starczenia danych do miejsca przeznaczenia. Do zapewnienia niezawod-
nych usług używa się ponad IP protokołów wyższych warstw, takich jak
TCP. IP zapewnia kilka przydatnych usług, które stały się wzorem pod-
czas projektowania innych podobnych protokołów.

IP wprowadził koncepcję logicznego adresu sieciowego, niezależnego od
użytego rodzaju sieci. Używa protokołu ARP (Address Resolution Protocol),
aby umożliwić powiązanie pomiędzy logicznym i fizycznym adresem
węzła sieci.

Datagramy IP mogą być dzielone na fragmenty, aby dostosować je do
Maksymalnej Jednostki Transmisji (MTU, Maximum Transmission Unit)
używanej sieci. Jeśli ma miejsce fragmentacja datagramów, każdy z nich
zawiera informację o sposobie ich ponownego złożenia. Składanie frag-
mentów w pierwotny datagram odbywa się w węźle odbiorczym. Pro-
blemy w działaniu IP, jak np. nieosiągalne miejsca przeznaczenia lub
przekroczenie czasu składania fragmentów datagramu, zgłaszane są
nadawcy przy użyciu protokołu ICMP (Internet Control Message Protocol).

Rozdział 2

62

Adresy IP reprezentowane są przez 32-bitową liczbę. Każdy interfejs
sieciowy w węźle obsługującym IP musi posiadać przypisany mu unikal-
ny adres. Adres IP składa się z dwóch części: identyfikatora sieci
i identyfikatora komputera sieciowego (tzw. hosta), jak pokazano na ry-
sunku 2.18. Najbardziej znaczące bity określają, ile z pozostałych bitów
używanych jest do identyfikacji sieci, a ile - komputera. Obecnie zdefi-
niowanych jest pięć klas adresów: A, B, C, D i E. Komputerowi można
przypisać adresy klasy A, B i C; klasa D jest zarezerwowana dla trybu
multicast i używana przez specjalne protokoły do transmitowania komu-
nikatów do wybranej grupy węzłów, natomiast klasa E jest zarezerwo-
wana dla przyszłych zastosowań.

Rysunek 2.17

Przykład użycia
TCP/IP ponad róż-
nymi protokołami
warstwy łącza da-
nych.

Identyfikator sieci (netid) w adresie IP przypomina numer sieci używany
w protokołach IPX. Definiuje on sieć w sposób jednoznaczny - wszystkie
karty sieciowe w podsieci powinny mieć ten sam identyfikator sieci.
Połączone ze sobą sieci muszą mieć unikalne identyfikatory.

Różne klasy adresów IP zdefiniowano po to, aby zaspokoić potrzeby sieci
o różnych wielkościach. Tabela 2.7 pokazuje, ile sieci może istnieć
w każdej z klas i ile każda z nich może mieć węzłów.

Tabela 2.7 Powody używania różnych klas adresów

Klasa adresu

Liczba sieci

Liczba węzłów

A

127

16 777 214

Infrastruktura protokołów TCP/IP w sieciach Windows

63

B

16 383

65 534

C 2

097

151 254

Rysunek 2.18

Klasy adresów IP

Klasa A jest odpowiednia dla bardzo dużych sieci, ale ponieważ identy-
fikator sieci zajmuje w tym przypadku tylko 7 bitów, może istnieć tylko
127 takich sieci. Przykładem może być tu pierwotna sieć ARPANET. Sieci
klasy B są średniej wielkości i zaspokajają potrzeby średnich i dużych
organizacji. Sieci klasy C są odpowiednie dla małych organizacji; każda
z nich może mieć najwyżej 254 węzły.

32-bitowy adres zapisuje się dla wygody jako cztery liczby dziesiętne,
odpowiadające czterem tworzącym go bajtom. Liczby oddziela się od
siebie znakiem kropki (.). Taki sposób zapisu nazywamy kropkowaną
notacją dziesiętną. Rysunek 2.19 pokazuje format pakietu IP.

Poniższy przykład przedstawia adres IP w

notacji dwójkowej

i w kropkowanej notacji dziesiętnej:

Adres IP = 10010000 00010011 01001010 11001010
Adres IP = 144.19.74.202

Pole numeru wersji (Version) zajmuje cztery bity i określa format nagłów-
ka IP (patrz rysunek 2.19). Pozwala to na przedefiniowanie w przyszłości
struktury nagłówka. Numerem bieżącej wersji jest 4. Wersja 6, będąca
nowym formatem pakietu IP, nazywana jest IPv6.

Tabela 2.8 Wartości pola wersji IP

Wersja IP

Znaczenie

0 Zarezerwowane

Rozdział 2

64

1-3 Nieprzypisane
4 IP
5

IP strumieniowe (protokół eksperymentalny)

6 IPv6
7-14 Nieprzypisane
15 Zarezerwowane

Rysunek 2.19

Format pakietu TCP

Pole długości nagłówka internetowego IHL (Internet Header Length) poda-
je długość nagłówka jako liczbę 32-bitowych słów. Jest ono potrzebne,
ponieważ nagłówek zawiera pole opcji o zmiennej długości.

Pole typu usługi TOS (Type of Service) informuje sieć o żądanej jakości
usługi, to znaczy o

pierwszeństwie, opóźnieniu, przepustowości

i niezawodności. Na rysunku 2.20 opisano znaczenie tego 8-bitowego
pola.

Pole pierwszeństwa odzwierciedla militarne pochodzenie sieci opartych
na IP. Poniżej opisujemy niektóre ze znaczeń zawartych w nim wartości:

„

Flash (błyskawicznie); maksymalne pierwszeństwo na wszystkich
obwodach.

Infrastruktura protokołów TCP/IP w sieciach Windows

65

„

Immediate (natychmiastowo). W ciągu czterech godzin.

„

Priority (priorytet). Tego samego dnia.

„

Routine (zwykłe). W ciągu jednego dnia.

Większość implementacji IP i protokołów trasujących (RIP, HELLO itp.)
ignoruje pole TOS.

Pole pierwszeństwa ma służyć aplikacjom IP używanym przez Departa-
ment Obrony USA. Użycie w tym polu wartości innych niż zera jest poza
zakresem specyfikacji standardu IP; producenci oprogramowania po-
winni kontaktować się z agencją DISA (Defense Information Systems Agen-
cy) w celu otrzymania wskazówek dotyczących pola pierwszeństwa i jego
wpływu na inne warstwy protokołu.

Rysunek 2.20

Pole typu usługi
(TOS) w pakiecie IP

Producenci oprogramowania powinni zauważyć, że obsługa pierwszeń-
stwa wymaga przekazywania jego wartości pomiędzy warstwami proto-
kołu w podobny sposób, jak przekazuje się pole TOS. Warstwa IP musi
umożliwić warstwie transportu ustawianie pola TOS w każdym wysyła-
nym datagramie; standardową wartością są same zera. IP powinien także
przekazywać wyższej warstwie otrzymane wartości TOS.

Pole TOS, w przeszłości rzadko używane, w przyszłości może spełniać
coraz ważniejszą rolę dzięki mogącym wykorzystać je protokołom trasu-
jącym, jak np. OSPF. Prawdopodobnie będzie sterować dwoma aspekta-
mi pracy routerów: algorytmami trasowania i algorytmami kolejkowania.
Pole TOS można także odwzorować na warstwę łącza danych, co umoż-
liwi efektywne dzielenie linii szeregowych przez różne klasy ruchu
w sieciach TCP.

Pole całkowitej długości (Total Length) zawiera łączną długość nagłówka
IP i danych wyrażoną w bajtach. Maksymalnym rozmiarem datagramu

Rozdział 2

66

jest 65535 bajtów. Wszystkie węzły IP muszą być zdolne do odbierania
datagramów o minimalnej długości 576 bajtów (512 bajtów danych
i nagłówka protokołu).

Pole identyfikacji (Identification) jest wypełniane oddzielnie dla każdego
datagramu i pełni funkcję numeru datagramu. Razem ze znacznikami
"nie fragmentować" DF (Don't Fragment), "więcej fragmentów" MF (More
Fragments) oraz polem przesunięcia fragmentu (Fragment Offset) służy do
składania fragmentów datagramu. Jeśli ustawiony jest znacznik DF, da-
tagramu nie wolno fragmentować. Znacznik MF ustawiony na 1 informu-
je odbiorcę, że nadejdą kolejne fragmenty; znacznik MF ustawiony na 0
oznacza, że jest to ostatni fragment.

Pole przesunięcia fragmentu (Fragment Offset) określa pozycję zawar-
tych we fragmencie danych w stosunku do początku pierwotnego data-
gramu. Jest to pole 13-bitowe, wyrażające przesunięcie w ośmiobajto-
wych jednostkach. Aby otrzymać przesunięcie w bajtach, należy wartość
tego pola pomnożyć przez 8.

Pole czasu życia TTL (Time to Live) określa w sekundach czas, w jakim
datagram może podróżować przez sieć. Powinno być zmniejszane przez
każdy router o ilość czasu, jaki zabrało przetworzenie pakietu. Przekro-
czenie czasu życia powinno spowodować odrzucenie datagramu przez
router, ale nie przez komputer przeznaczenia. Komputery pracujące
również jako routery (a więc przekazujące datagramy) muszą traktować
pole TTL tak, jak zwykłe routery. Pole to spełnia dwie funkcje: ogranicza
czas życia segmentów TCP i przerywa ślepe pętle trasowania. Chociaż
czas życia jest wyrażony w sekundach, ma również własności licznika
skoków, ponieważ każdy router zobowiązany jest do zmniejszenia go co
najmniej o 1. Dlatego niektórzy implementatorzy ustawiają go na 16, po-
nieważ 16 uważa się w protokole trasującym RIP za czas nieskończony;
czas życia jest jednak niezależny od własności protokołu RIP.

Poniżej wymieniamy dalsze uwagi dotyczące pola TTL:

„

Komputer nie może wysyłać datagramu z wartością TTL równą zero;
nie może także odrzucić datagramu tylko dlatego, że otrzymał go
z wartością TTL mniejszą niż dwa.

„

Protokół wyższej warstwy powinien mieć możliwość ustawiania TTL,
np. podczas przeszukiwania o wzrastającym zasięgu. Metody tej
używają niektóre narzędzia diagnostyczne; może przydać się na
przykład do znalezienia "najbliższego" serwera danej klasy przy uży-
ciu trybu multicast IP. Poszczególne protokoły transportowe mogą
również zechcieć ustanowić własną granicę życia datagramu w sieci.

Infrastruktura protokołów TCP/IP w sieciach Windows

67

„

Jeśli wartość TTL jest stała, musi być przynajmniej tak duża, jak "śred-
nica" Internetu - najdłuższa możliwa ścieżka. Ponieważ Internet stale
się rozrasta, rozsądną wartością jest podwójna średnica.

„

Warstwa IP musi umożliwić warstwie transportu ustawianie pola TTL
w każdym wysyłanym datagramie. Jeśli używa się stałej wartości
TTL, należy zapewnić możliwość jej konfiguracji. Niestety, większość
implementacji nie pozwala na ustawienie wartości TTL; często stosuje
się stałą wartość 32 lub 64.

Pole protokołu (Protocol) określa protokół wyższej warstwy, który będzie
odbierał dane od IP. Przypomina swoją funkcją pole "typ pakietu" (Packet
Type) w pakietach IPX. Dokument RFC 1060 opisuje wartości zdefinio-
wane dla tego pola; np. w przypadku TCP jest to 6, a w przypadku ICMP
1.

Pole sumy kontrolnej (Header Checksum) używane jest do sprawdzenia
poprawności nagłówka IP. Dodaje się uzupełnienia jedynkowe wszyst-
kich 16-bitowych słów nagłówka (z wyłączeniem pola sumy kontrolnej),
po czym umieszcza się w tym polu uzupełnienie jedynkowe otrzymanej
sumy. Pole jest przeliczane przez każdy router, ponieważ zmieniają one
wartość pola TTL, co modyfikuje nagłówek.

Adres źródłowy (Source Address) i adres przeznaczenia (Destination Ad-
dress) są 32-bitowymi adresami węzłów źródła i przeznaczenia.

Opcje IP obejmują bezpieczeństwo, swobodne trasowanie źródłowe, ści-
słe trasowanie źródłowe, zapisywanie trasy i znacznik czasowy.

Protokół TCP

TCP jest podstawowym protokołem używanym do zapewnienie nieza-
wodnych, dupleksowych połączeń (albo obwodów logicznych). Połącze-
nie tworzy się pomiędzy numerowanymi portami nadawcy i odbiorcy.
TCP zorientowany jest na przesyłanie strumienia oktetów, czyli 8-
bitowych grup - strumień oktetów jest więc strumieniem 8-bitowym.
W protokole TCP nie istnieje pojęcie bloku danych. TCP umożliwia utwo-
rzenie wielu logicznych połączeń pomiędzy dwoma komputerami.

Rysunek 2.21 przedstawia strukturę pakietu TCP. Numery portu źródło-
wego i portu przeznaczenia identyfikują końcowe procesy w obwodzie
logicznym TCP. Niektóre numery portów są powszechnie znane, podczas
gdy inne są przypisywane dynamicznie. RFC 1066 zawiera opis po-
wszechnie znanych numerów; niektóre z nich omówiono w tabeli 2.9.

32-bitowy numer kolejny (Sequence Number) jest numerem pierwszego
bajtu danych w bieżącym pakiecie. Jeśli ustawiony jest znacznik synchro-

Rozdział 2

68

nizacji SYN, pole określa początkowy numer kolejny dla danej sesji. Pole
jest 32-bitowe, aby uniknąć używania starych numerów kolejnych, które
mogły zostać przypisane danym transmitowanym jeszcze przez sieć.

Numer potwierdzenia (Acknowledgment Number) jest numerem kolejnym
następnego bajtu oczekiwanego przez odbiorcę. Potwierdzenia w TCP są
kumulatywne - oznacza to, że pojedyncze potwierdzenie może informo-
wać o odebraniu kilku kolejnych segmentów TCP.

Pole przesunięcia danych (Data Offset) oznacza liczbę 32-bitowych słów
w nagłówku TCP. Jest potrzebne, ponieważ pole opcji TCP może mieć
zmienną długość.

Tabela 2.9 Niektóre powszechnie znane numery portów TCP

Numer portu

Opis

0 Zarezerwowany
5

Remote Job Entry (praca zdalna)

7 Echo
9 Discard

(Odrzucenie)

11 Systat
13

Daytime (pora dnia)

15 Netstat
17

Quotd (Quote of the day, Cytat dnia)

20

ftp_data (dane ftp)

21

ftp control (sterowanie ftp)

23 Telnet
25 SMTP
37 time

(czas)

53

name server (serwer nazw)

102 ISO_TSAP
103 X.400
104

X.400 sending service (us³ugi nadawcze)

111 Sun

RPC

139

NetBIOS session source (Ÿród³o sesji NetBIOS)

160-223 Zarezerwowany

Infrastruktura protokołów TCP/IP w sieciach Windows

69

Numer portu

Opis

Rysunek 2.21

Format pakietu TCP

Znaczniki pełnią następujące funkcje:

„

URG (Pilne). Znacznika używa się, aby przesłać pilne dane bez czeka-
nia, aż proces odbiorczy przetworzy oktety znajdujące się już
w strumieniu. Kiedy znacznik jest ustawiony, znaczenia nabiera pole
wskaźnika do pilnych danych (Urgent Pointer). W RFC 1122 podano,
że wskaźnik zawiera numer kolejny ostatniego bajtu w sekwencji pil-
nych danych (a nie ostatniego + 1, jak błędnie stwierdzono w RFC
793). Każda implementacja TCP musi umieć przetworzyć sekwencję
pilnych danych o dowolnej długości. Warstwa TCP musi zawsze
asynchronicznie powiadomić warstwę aplikacji, kiedy otrzyma
wskaźnik, a nie posiada nie przetworzonych pilnych danych, lub kie-
dy wskaźnik do pilnych danych wyprzedza dane w strumieniu.

„

Aplikacja musi mieć możliwość stwierdzenia, ile pilnych danych trze-
ba jeszcze odczytać z połączenia, albo przynajmniej ustalenia, czy po-
zostały jeszcze jakieś pilne dane do odczytania. Chociaż z mecha-
nizmu pilnych danych może korzystać dowolna aplikacja, zazwyczaj
używa się go podczas wysyłania poleceń do programu Telnet. Asyn-
chroniczne powiadomienie pozwala aplikacji przejść w tryb pilnej
pracy podczas odczytywania danych z połączenia TCP. Dzięki temu
możliwe jest wysyłanie poleceń sterujących do aplikacji, której bufory
odbiorcze są pełne nieprzetworzonych jeszcze danych.

Rozdział 2

70

„

ACK (Potwierdzenie). Znacznik ACK informuje, że pole numeru po-
twierdzenia (Acknowledgment Number) jest znaczące.

„

PSH (Natychmiastowe dostarczenie). Znacznik ten informuje TCP, że
należy natychmiast dostarczyć zawarte w tym komunikacie dane do
procesu wyższej warstwy. Kiedy proces wydaje serię poleceń przesła-
nia danych nie ustawiając znacznika PSH, wówczas TCP może we-
wnętrznie zagregować dane przed ich wysłaniem. TCP może także
buforować otrzymywane bez znacznika PSH dane przed ich przesła-
niem do odbiorcy.

„

Znacznik PSH nie jest wskaźnikiem końca rekordu i jest niezależny od
granic segmentów, chociaż niektóre implementacje tak go (błędnie)
traktują. Nadawca powinien połączyć następujące po sobie znaczniki
PSH w trakcie układania danych w pakietach tak, aby przesłać moż-
liwie największy segment.

„

TCP może obsługiwać ustawianie znacznika PSH podczas żądania
przesłania danych. Jeśli tego nie robi, dane nie mogą być buforowane
przez nieokreślony czas, a w ostatnim segmencie musi być ustawiony
znacznik PSH (np. w sytuacji, gdy nie ma już buforowanych danych
do przesłania).

„

RFC 793 błędnie stwierdza, że odebrany znacznik PSH musi być
przekazany do warstwy aplikacji. Przekazywanie znacznika PSH jest
obecnie opcjonalne.

„

Od aplikacji wymaga się (co zresztą jest logiczne), aby ustawiała
znacznik PSH w żądaniu przesłania, jeśli wymuszenie przesłania da-
nych ma zapobiec zablokowaniu komunikacji między procesami.
Ustawienie znacznika PSH po stronie nadawcy nie musi więc ozna-
czać natychmiastowego wysłania segmentu.

„

Kiedy TCP nie obsługuje znacznika PSH podczas wysyłania danych
(lub kiedy aplikacja bądź protokół TCP używa czysto strumieniowego
modelu komunikacji), wówczas odpowiedzialność za połączenie
drobnych fragmentów danych w bloki o rozsądnej wielkości spoczy-
wa częściowo na warstwie aplikacji. Ogólnie rzecz biorąc, interaktyw-
ny protokół aplikacji po otrzymaniu sekwencji poleceń powinien
ustawiać znacznik PSH, przynajmniej w ostatnim poleceniu przesła-
nia. Protokół transmitujący duże ilości danych, jak np. FTP, powinien
ustawiać znacznik PSH w ostatnim segmencie przesyłanego pliku lub
gdy grozi przepełnienie bufora.

„

U odbiorcy otrzymanie znacznika PSH wymusza przesłanie buforo-
wanych danych do aplikacji, nawet jeśli bufor nie jest jeszcze całkowi-
cie wypełniony. Odwrotnie, brak znacznika PSH powinien powodo-

Infrastruktura protokołów TCP/IP w sieciach Windows

71

wać, że dane nie będą przedwcześnie wysyłane do aplikacji; jest to
ważny czynnik przy optymalizacji pracy dużych, wielozadaniowych
systemów.

„

RST (Zerowanie). Znacznik RST zeruje połączenie, kiedy wystąpi
niemożliwy do naprawienia błąd, spowodowany np. zawieszeniem
się komputera lub odebraniem opóźnionych, zduplikowanych seg-
mentów z ustawionym znacznikiem SYN.

„

SYN (Synchronizacja). Znacznika tego używa się podczas otwierania
połączenia. Połączenia TCP otwierane są przy użyciu trójstopniowego
potwierdzenia; znaczniki SYN i ACK sygnalizują następujące rodzaje
pakietów:

SYN=1 i ACK=0 Pakiet otwierający połączenie
SYN=1 i ACK=1 Pakiet potwierdzający otwarcie połączenia
SYN=0 i ACK=1 Pakiet danych lub pakiet potwierdzenia.

„

FIN (Koniec). Znacznik FIN zamyka połączenie. TCP dokonuje tego
przy użyciu mediacyjnego mechanizmu: obie strony muszą zgodzić
się, żeby zakończyć połączenie, zanim będzie mogło nastąpić jego za-
mknięcie. Mechanizm ten gwarantuje, że nie zostaną utracone żadne
dane, co mogłoby się zdarzyć w wyniku nagłego, jednostronnego ze-
rwania połączenia.

Pole okna (Window) służy do sterowania przepływem. Odbiorca używa
go, aby określić liczbę bajtów danych, którą obecnie może odebrać od
nadawcy.

Pole sumy kontrolnej (Checksum) jest uzupełnieniem jedynkowym sumy
uzupełnień jedynkowych wszystkich 16-bitowych słów w pakiecie TCP.
Podczas obliczania sumy kontrolnej brany pod uwagę jest także 96-
bitowy pseudonagłówek (patrz rysunek 2.22), konceptualnie dołączany
do właściwego nagłówka TCP. Pseudonagłówek umożliwia sprawdzenie,
czy pakiet dotarł do miejsca przeznaczenia. Zawiera on pole identyfika-
tora protokołu (6 w przypadku TCP) oraz adres źródłowy i adres prze-
znaczenia IP. Wraz z numerami portów z nagłówka TCP adresy te jedno-
znacznie definiują połączenie między końcowymi punktami komunikacji.

Pole opcji (Options) może obecnie zawierać tylko opcję maksymalnego
rozmiaru segmentu MSS (Maximum Segment Size), która jest negocjowana
podczas otwierania połączenia.

Protokół UDP

Niektóre aplikacje nie wymagają odporności i solidności TCP. Potrzebują
tylko protokołu transportowego, który potrafi zidentyfikować procesy

Rozdział 2

72

pracujące w łączących się komputerach i przeprowadzić podstawową
kontrolę błędów. Wymagania te spełnia protokół UDP (User Datagram
Protocol).

Protokół TCP pracuje w trybie połączeniowym, natomiast UDP (jak suge-
ruje jego nazwa) pracuje w trybie datagramowym (bezpołączeniowym).
UDP nie ustanawia połączeń. Przesyła dane obudowując je nagłówkami
UDP i

przekazując warstwie IP, która wysyła pakiety UDP

w pojedynczym datagramie (o ile nie jest konieczna jego fragmentacja).
UDP nie umożliwia sekwencjonowania przesyłanych danych, dlatego
istnieje możliwość, że zostaną odebrane w innej kolejności, niż zostały
wysłane. Aplikacje wymagające sekwencjonowania danych muszą albo
same zapewnić taki mechanizm, albo skorzystać z usług TCP. W wielu
sieciach lokalnych prawdopodobieństwo otrzymania danych w niewłaś-
ciwej kolejności jest niewielkie, ze względu na małe opóźnienia i prostą
topologię sieci.

Rysunek 2.22

Pseudonagłówek
używany przy obli-
czaniu sumy kontro-
lnej TCP

UDP jest przydatne dla aplikacji pracujących w trybie "żądanie-
odpowiedź", w których polecenia i odpowiedzi mogą zostać przesłane
w pojedynczym datagramie. Unika się dzięki temu obciążenia związane-
go z otwieraniem połączenia i zamykaniem go po przesłaniu niewielkiej
ilości danych. Innym obszarem zastosowania UDP są aplikacje wymaga-
jące użycia trybu broadcast lub multicast. Aby przesłać dane do 1000
komputerów przy użyciu TCP, trzeba otworzyć 1000 połączeń, przesłać
dane każdym z nich, po czym wszystkie zamknąć. Koszt otwarcia tylu
połączeń, utrzymywania ich oraz zamknięcia jest stosunkowo wysoki.
Jeśli stosuje się UDP, wówczas nadawca może przekazać dane do modu-
łu IP żądając transmisji w trybie broadcast lub multicast, przy czym do

Infrastruktura protokołów TCP/IP w sieciach Windows

73

przeprowadzenia tej operacji można wykorzystać fizyczne możliwości
używanej sieci.

UDP zapewnia opcjonalną, podstawową kontrolę integralności przesyła-
nych danych. Jeśli używana sieć jest wystarczająco niezawodna, wówczas
sprawdzanie błędów można wyłączyć, co przyspiesza przetwarzanie
danych UDP.

Cechy UDP można podsumować następująco:
„

Identyfikacja aplikacji poprzez użycie numerów portów UDP.

„

Praca datagramowa. Nie ma tu obciążenia związanego z otwieraniem,
utrzymywaniem i zamykaniem połączenia

„

Wydajna praca z aplikacjami wymagającymi trybu broadcast lub mul-
ticast.

„

Brak sekwencjonowania danych. Nie można zagwarantować właści-
wej kolejności otrzymywanych danych.

„

Opcjonalna suma kontrolna danych.

„

Szybszy, prostszy i wydajniejszy niż TCP, ale mniej niezawodny.

UDP zapewnia zawodne, bezpołączeniowe usługi transportowe ponad
protokołem IP. Uważany jest za protokół warstwy transportu, co jest
odrobinę paradoksalne, ponieważ funkcją warstwy transportu jest za-
pewnienie integralności danych pomiędzy końcowymi punktami połą-
czenia - czego UDP nie robi. Pomimo tego wiele działających aplikacji
używa UDP. Są to między innymi:
„

TFTP (Trivial File Transfer Protocol)

„

DNS (Domain Name System)

„

NFS wersja 2 (Network File System)

„

SNMP (Simple Network Management Protocol)

„

RIP (Routing Information Protocol)

„

Datagramy NetBIOS

„

Wiele usług pracujących w trybie broadcast, jak np. WHOD (demon
Who w serwerach UNIX)

Format nagłówka UDP

Nagłówek UDP posiada stałą długość ośmiu oktetów. Format nagłówka
UDP przedstawia rysunek 2.23.

Pole portu źródłowego (Source Port) posiada długość 16 bitów i jest
opcjonalne. Kiedy ma znaczenie, wówczas:

„

Określa numer portu nadającego procesu.

Rozdział 2

74

„

Numer portu źródłowego jest portem, do którego należy adresować
odpowiedź pod nieobecność innych informacji.

„

Jeśli jest ustawione na 0, port źródłowy nie jest używany.

Pole portu przeznaczenia (Destination Port) identyfikuje proces pracujący
pod adresem przeznaczenia IP, który ma otrzymać wysyłane dane. Po-
dobnie jak TCP, dzięki numerom portu UDP może demultipleksować
dane wysyłane do procesów odbiorczych. Jeśli UDP otrzyma datagram
z numerem portu, który nie jest używany (żadna aplikacja UDP nie ko-
rzysta z tego portu), wówczas generuje komunikat błędu ICMP "nieosią-
galny port" i odrzuca datagram.

Pole długości (Length) określa długość danego pakietu UDP w oktetach.
W długość włączany jest nagłówek UDP i dane. Minimalną wartością
tego pola jest 8, co oznacza, że pole danych ma zerową długość.

Pole sumy kontrolnej (Checksum) jest 16-bitowym uzupełnieniem jedyn-
kowym sumy uzupełnień jedynkowych pseudonagłówka (zawierającego
informacje z nagłówka IP), nagłówka UDP oraz danych. W razie potrze-
by na końcu umieszcza się oktet o wartości 0 tak, aby liczba oktetów była
parzysta. Procedura obliczania sumy kontrolnej jest taka sama, jak
w przypadku TCP.

Pseudonagłówek konceptualnie poprzedza nagłówek UDP i zawiera
adres źródłowy, adres przeznaczenia, typ protokołu (17 w przypadku
UDP) oraz długość pakietu UDP (patrz rysunek 2.24). Informacje te za-
bezpieczają przed błędnie trasowanymi datagramami. Pseudonagłówek
posiada stałą długość 12 oktetów. Informacje w pseudonagłówku całko-
wicie określają związek datagramu z miejscem przeznaczenia, chociaż
nie jest ustanawiane żadne połączenie.

Rysunek 2.23

Format nagłówka UDP

Rysunek 2.24

Pseudonagłówek używany przy obliczaniu
sumy kontrolnej UDP

Jeśli obliczoną sumą kontrolną jest zero, wówczas jej bity zamieniane są
na same jedynki (jest to odpowiednik zera w uzupełnieniu jedynkowym),
dlatego suma kontrolna generowana przez opisane wyżej obliczenia nig-

Infrastruktura protokołów TCP/IP w sieciach Windows

75

dy nie wynosi zero. Zerowa suma kontrolna służy do poinformowania,
że sumy kontrolne nie są używane. Można na to spojrzeć w inny sposób:
w arytmetyce uzupełnień jedynkowych zero ma dwie bitowe reprezenta-
cje - same zera albo same jedynki. Wersja z samymi jedynkami jest uży-
wana jako obliczona suma kontrolna, wersja z samymi zerami wskazuje,
że wyłączona jest kontrola błędów. Jeśli aplikacja pracuje w niezawodnej
sieci IP, takiej jak sieć lokalna, wówczas można wyłączyć obsługę sum
kontrolnych, ponieważ ich generowanie podczas wysyłania datagramów
UDP i sprawdzanie podczas odbioru jest niepotrzebnym obciążeniem.

Protokół UDP pracuje ponad protokołem IP. Suma kontrolna IP jest obli-
czana tylko dla nagłówka, podczas gdy suma kontrolna UDP jest obli-
czana dla nagłówka i danych. Suma kontrolna UDP jest potrzebna do
zagwarantowania integralności pola danych.