plik

Rozdział 1

Architektura TCP/IP w Windows

Protokół TCP/IP zaimplementowano w niemal wszystkich liczących się
systemach operacyjnych, począwszy od mikrokomputerów a skończyw-
szy na komputerach typu mainframe i superkomputerach. W niniejszym
rozdziale opiszemy implementację protokołu TCP/IP w systemie Win-
dows - zarówno w Windows 9x (Windows 95 i 98) jak i Windows NT
firmy Microsoft. Przedstawimy różnice w implementacji pomiędzy wer-
sjami dla Windows 95 i Windows 98.

Warstwy protokołów w Windows NT i Windows 9x

Chociaż Windows NT i Windows 9x mają podobne interfejsy użytkowni-
ka, ich wewnętrzna architektura znacznie się różni. Różna jest też
w związku z tym implementacja TCP/IP.

Pojęcie warstw protokołów w systemach komputerowych tradycyjnie
rozważa się na bazie modelu OSI (Open System Interconnection). Model
ten, wprowadzony w roku 1978 przez ISO (International Organization of
Standards), ułatwia tworzenie i opisywanie środków łączności pomiędzy
różnymi systemami komunikacyjnymi. W niniejszym rozdziale używamy
modelu OSI do opisania różnych komponentów protokołu TCP/IP.

Rozumienie warstw protokołów w kategoriach warstw modelu OSI

Rysunek 1.1 pokazuje model OSI i miejsce, które w nim zajmuje protokół
TCP/IP. Model OSI jest modelem abstrakcyjnym, służącym głównie jako
pomoc w opisie różnych funkcji komunikacyjnych. Zrozumienie zależno-
ści pomiędzy funkcjami komunikacyjnymi modelu i rzeczywistą imple-
mentacją protokołu umożliwia natychmiastowy wgląd w jego działanie.

Na rysunku 1.1 protokół IP (Internet Protocol,) odpowiada trzeciej war-
stwie modelu OSI. Jest to warstwa sieci, która odpowiada za funkcję
nazewnictwa adresów sieciowych oraz funkcję trasowania (routingu)
Nazewnictwo adresów sieciowych umożliwia stosowanie jednolitego

Rozdział 1

formatu adresowania dla węzłów w dwóch fizycznie różnych sieciach.
Jednolity format adresowania umożliwia traktowanie systemu wzajemnie
połączonych elementów jako jednego systemu logicznego bądź sieci
przez wyższe warstwy protokołu. Funkcja trasowania umożliwia dostar-
czenie porcji danych - nazywanych pakietami - do miejsca przeznaczenia.
Jest ona zazwyczaj realizowana przez systemy pośredniczące nazywane
routerami (patrz rysunek 1.2) które operują w warstwie sieci modelu OSI.
Routery badają adres przeznaczenia pakietu i przekazują pakiet do na-
stępnego pośrednika, zbliżając go do miejsca przeznaczenia.

Rysunek 1.1

Model OSI a TCP/IP

Rysunek 1.2

Systemy pośredniczące (routery)

Ponieważ protokół IP odpowiada trzeciej warstwie modelu OSI - na pod-
stawie tego, co zostało do tej pory powiedziane, możemy określić nastę-
pujące właściwości IP w sieciach Windows:

Protokół IP w komputerze pracującym pod kontrolą Windows za-
pewnia jednolite nazewnictwo adresów. Jednolity adres jest 32-bitową
liczbą nazywaną adresem IP. Adres IP powinien zasadniczo być inny
dla każdego węzła IP - co oznacza, że każdy komputer powinien po-
siadać unikalny adres IP. Jeśli komputery mają być połączone
z Internetem, adresy te muszą zostać przydzielone przez INTERNIC

Architektura TCP/IP w Windows

(Internet Network Information Center) lub przez dostarczyciela usług in-
ternetowych.

Protokół IP w komputerze pracującym pod kontrolą Windows za-
pewnia funkcje trasowania. Umożliwia to komputerowi przekazywa-
nie pakietów IP, nazywanych datagramami IP, do kolejnego miejsca
przeznaczenia. Komputer z Windows NT może wykonywać funkcje
trasowania. W dużych sieciach funkcje trasowania wykorzystywane
są do przyspieszenia przekazywania datagramów IP oraz uniknięcia
opóźnień w routerze spowodowanych dużym ruchem w sieci. Do wy-
znaczenia optymalnej ścieżki do konkretnego miejsca przeznaczenia
używa się specjalnych protokołów trasujących - takich jak Protokół In-
formacji Trasującej (Routing Information Protocol, RIP) i protokół
„Otwórz Najpierw Najkrótszą Ścieżkę” - OSPF (Open Shortest Path
First), które współpracują z protokołem IP. Protokoły te opiszemy
w rozdziale 7.

Na rysunku 1.1 widać, że protokół IP pracuje ponad warstwą łącza da-
nych, która z kolei spoczywa na warstwie fizycznej modelu OSI. Każda
warstwa OSI wykorzystuje usługi zapewniane przez niższą warstwę
i dodaje do nich swoje. Warstwa łącza danych w modelu OSI odpowiada
urządzeniom sieciowym, takim jak karty sieciowe Ethernet albo Token
Ring. Zatem trzecia warstwa modelu OSI, odpowiadająca protokołowi IP,
używa urządzeń sieciowych - jak karty sieciowe Ethernet lub Token Ring
- do wysyłania i odbierania datagramów IP. Protokół IP może pracować
ponad szerokim spektrum urządzeń sieciowych, jak na przykład Ether-
net, Token Ring, Frame Relay, X.25, ATM, ISDN itd. Jest to ważne spo-
strzeżenie, ponieważ protokół IP zapewnia niezależność od urządzeń
użytych do budowy sieci. Protokoły umiejscowione ponad protokołem IP
w modelu OSI - jak np. Protokół Kontroli Transmisji (Transmission Control
Protocol, TCP) - nie muszą zajmować się szczegółami i różnicami
w urządzeniach sieciowych tworzących fizyczną sieć.

Wszystkie implementacje IP muszą również obsługiwać pomocniczy
protokół, nazywany Internetowym Protokołem Wiadomości Kontrolnych
- ICMP (Internet Control Message Protocol), który używany jest w celach
diagnostycznych oraz do raportowania problemów z przesyłaniem data-
gramów IP w różnych punktach ich drogi przez sieć. Na przykład ko-
menda PING, której używa się powszechnie w sieciach TCP/IP do
sprawdzenia, czy dany węzeł TCP/IP jest osiągalny, stosuje w tym celu
pakiety ICMP - żądanie echa/odpowiedź na echo.

Rysunek 1.1 pokazuje, że TCP odpowiada czwartej warstwie modelu
OSI. Jest to warstwa transportu, której funkcją jest zapewnienie integral-
ności danych przesyłanych pomiędzy końcowymi punktami połączenia.

Rozdział 1

Warstwa transportu w modelu OSI zapewnia wzbogacenie usług ofero-
wanych przez warstwę sieci, dołączając niezawodność przesyłania da-
nych oraz multi- i demultipleksowanie procesów. Aby zapewnić nieza-
wodność przesyłania danych, wykorzystuje mechanizmy korekcji błędów
oferowane przez niższe warstwy i dodaje swoje. Jeśli niższe warstwy są
zawodne, wtedy większość pracy „spada” na warstwę transportu, która
jest ostatnią barierą eliminującą błędy. Warstwa transportu może być
również odpowiedzialna za ustanowienie kilku połączeń logicznych na
pojedynczym połączeniu sieciowym; proces ten nazywamy multiplekso-
waniem.

Multipleksowanie (lub dzielenie czasu) zachodzi wtedy, gdy pewna licz-
ba połączeń transportowych dzieli to samo połączenie sieciowe. War-
stwa transportu jest środkową warstwą modelu OSI. Trzy niższe war-
stwy tworzą podsieć (część modelu sieci), a trzy wyższe warstwy są za-
zwyczaj implementowane przez oprogramowanie sieciowe pracujące na
węźle. Warstwę transportu implementuje się zazwyczaj również na węź-
le; jej zadaniem jest przekształcenie zawodnej podsieci w niezawodną
sieć.

Ze względu na multipleksowanie, kilka programów (w terminologii OSI
nazywanych jednostkami protokołowymi) dzieli ten sam adres
w warstwie sieci. W celu jednoznacznej identyfikacji tych programów
w warstwie transportu konieczny jest bardziej ogólny sposób adresowa-
nia. Rozwiązaniem są adresy transportowe, będące kombinacją adresu
warstwy sieci i numeru SAP (Service Access Point) w warstwie transportu.
Czasem nazywa się je gniazdami lub numerami portu. W przypadku
protokołu TCP adresy SAP nazywane są numerami portu i są 16-
bitowymi liczbami. Na przykład protokół FTP używa portu TCP o nu-
merze 21, protokół Telnet portu TCP o numerze 23, a protokół HTTP -
portu TCP o numerze 80.

Znając zadania warstwy transportu oraz wiedząc, że protokół TCP od-
powiada właśnie tej warstwie modelu OSI, na podstawie tego, co zostało
do tej pory powiedziane, możemy odnotować następujące właściwości
TCP w sieciach Windows:

Protokół TCP w komputerze pracującym pod kontrolą Windows za-
pewnia niezawodne przesyłanie danych. TCP posiada wbudowany
mechanizm kontroli błędów, który kompensuje błędy powstające
w niższych warstwach. Niezawodność przesyłania danych osiąga się
poprzez tworzenie odrębnych połączeń logicznych i zapewnienie, że
wysyłane dane zostaną dostarczone do wyższych warstw we właści-
wej kolejności.

Architektura TCP/IP w Windows

Protokół TCP w komputerze pracującym pod kontrolą Windows za-
pewnia programowe adresowanie każdego z końców połączenia sie-
ciowego. Te programowe (czy też transportowe) adresy nazywane są
numerami portu.

Protokół TCP w komputerze pracującym pod kontrolą Windows
umożliwia multipleksowanie kilku połączeń logicznych na tym sa-
mym interfejsie sieciowym.

Wszystkie implementacje TCP/IP muszą również obsługiwać prostszy
protokół transportowy nazywany Protokołem Datagramów Użytkownika
- UDP (User Datagram Protocol), używany w aplikacjach, w których od-
porność i niezawodność TCP/IP nie są potrzebne i mogą stanowić nad-
mierne obciążenie. Wszystkie implementacje TCP/IP w Windows obsłu-
gują zatem również UDP. UDP jest przydatne w aplikacjach, które pracu-
ją na zasadzie „żądanie-odpowiedź”. Są to programy, które wysyłają
żądanie i oczekują odpowiedzi, przy czym nie ma potrzeby podtrzymy-
wania otwartego połączenia logicznego. Na przykład protokoły DNS
i SNMP używają UDP, ponieważ pracują na zasadzie „żądanie-
odpowiedź”. UDP jest również przydatne w przypadkach, kiedy trans-
misja w sieci jest często kierowana do wszystkich (tzw. broadcast) lub
wielu (tzw. multicast) węzłów sieci. Jest to częsty przypadek w sieciach
Windows, gdyż wiele funkcji przeglądania i ogłaszania usług wykorzy-
stuje tryb broadcast lub multicast.

Aplikacje TCP/IP, takie jak System nazw domen DNS (Domain Name
System), Telnet, Protokół Przesyłania Plików FTP (File Transfer Protocol),
Sieciowy System Plików NFS (Network File System) współpracują bezpo-
średnio z protokołami TCP i UDP. Te aplikacje TCP/IP odpowiadają
warstwie aplikacji w modelu OSI (warstwa siódma) - co interesujące,
bardzo niewiele programów używa protokołów odpowiadających war-
stwom sesji i prezentacji w modelu OSI. Wyjątkiem jest NFS, który używa
protokołów Zdalnego Wywołania Procedury RPC (Remote Procedure Call)
oraz Zewnętrznej Reprezentacji Danych XDR (External Data
Representation), które należą odpowiednio do warstwy sesji i prezentacji
modelu OSI.

Niewiele aplikacji TCP/IP używa protokołów odpowiadających war-
stwom sesji i prezentacji, ponieważ warstwy te oferują usługi niepotrzeb-
ne większości spośród nich. Warstwa sesji w modelu OSI udostępnia
rozszerzone usługi kontroli sesji - jak sterowanie dialogiem, sterowanie
żetonami, zarządzanie aktywnością. Warstwa prezentacji w modelu OSI
zarządza sposobem reprezentacji danych, biorąc pod uwagę różnice
w sposobie zapisu danych i znaków, oraz to, czy liczby wielobajtowe
zapisywane są w pamięci począwszy od najmniej, czy od najbardziej
znaczącego bajtu. Różnice w formacie zapisu liczb mogą prowadzić do

Rozdział 1

błędów, jeśli liczby te są wysyłane do komputera używającego innego
formatu niż nadawca. Protokół NFS potrzebuje usług zdefiniowanych
przez warstwy szóstą i siódmą modelu OSI, dlatego też używa warstw
sesji i prezentacji.

Architektura Windows NT

Protokół TCP/IP w Windows NT jest zaimplementowany jako sterownik
w komponencie wejścia/wyjścia usług wykonawczych Windows NT.
Pierwszym krokiem do zrozumienia funkcjonowania protokołu TCP/IP
powinno być poznanie podsystemu wejścia/wyjścia Windows NT
i ogólnej architektury systemu. Pomoże to w uświadomieniu sobie poło-
żenia TCP/IP w ramach systemu Windows.

Rysunek 1.3

Architektura Windows NT

Na rysunku 1.3 pokazano komponenty architektury systemu Windows
NT. Ogólne cechy architektury przedstawione na rysunku odnoszą się do
systemu Windows NT - zarówno w wersji Server, jak i Workstation.

Windows NT zaprojektowano w sposób modularny. Poszczególne modu-
ły (nazywane również komponentami) Windows NT pokazuje rysunek

Architektura TCP/IP w Windows

1.3. Windows NT Server jest zoptymalizowany do pełnienia funkcji ser-
wera, zapewniając wsparcie dla domen Windows NT, architektury Ac-
tive Directory, oraz specyficzne dla serwera narzędzia i aplikacje, niedo-
stępne w wersji Windows NT Workstation.

Komponenty systemu operacyjnego Windows NT mogą pracować
w dwóch trybach: użytkownika i jądra (patrz rysunek 1.3). Komponent
pracujący w trybie jądra posiada dostęp do pełnego zakresu instrukcji
maszynowych procesora i zasadniczo może używać wszelkich zasobów
systemu. W Windows NT w trybie jądra pracują usługi wykonawcze,
mikrojądro oraz abstrakcyjna warstwa sprzętowa HAL (Hardware
Abstraction Layer). Podsystem Win32s i inne podsystemy środowiskowe -
jak DOS/Win16, OS/2 i POSIX - pracują w trybie użytkownika. Umie-
ściwszy te komponenty w trybie użytkownika, twórcy systemu Windows
NT mogą je łatwo modyfikować bez zmieniania komponentów zaprojek-
towanych do pracy w trybie jądra. Zaletą trybu jądra jest fakt, że kod
systemu operacyjnego jest chroniony przed programami, które mogłyby
przypadkowo lub celowo spróbować zmienić zachowanie systemu.

Abstrakcyjna warstwa sprzętowa (HAL) wirtualizuje komponenty kom-
putera, dzięki czemu mikrojądro może być dostosowane do wirtualnego
interfejsu sprzętowego, a nie do rzeczywistych urządzeń. W większości
wypadków mikrojądro używa HAL podczas dostępu do zasobów kom-
putera. Oznacza to, że Microsoft może łatwo przenieść mikrojądro
i zależne od niego komponenty na inną platformę sprzętową. Niewielka
część mikrojądra, jak również zarządcy wejścia/wyjścia, odwołuje się do
sprzętowych zasobów komputera z pominięciem HAL.

Warstwa mikrojądra (patrz rysunek 1.3) udostępnia podstawowe funkcje
systemu operacyjnego, używane przez pozostałe komponenty wykonaw-
cze. Mikrojądro jest stosunkowo niewielkie i obsługuje fundamentalne
funkcje systemowe; jest odpowiedzialne głównie za przydzielanie wąt-
ków, obsługę wyjątków sprzętowych i synchronizację w systemach wie-
loprocesorowych.

Komponenty wykonawcze pracują w trybie jądra i udostępniają takie
usługi, jak zarządzanie obiektami (zarządca obiektów), bezpieczeństwem
(monitor bezpieczeństwa), procesami (zarządca procesów), pamięcią
(zarządca pamięci wirtualnej), usługę wywoływania procedur lokalnych,
oraz zarządzanie wejściem/wyjściem (zarządca wejścia/wyjścia).

Podsystemy, nazywane podsystemami środowiskowymi, pracują w try-
bie użytkownika. Tworzą środowiska systemowe dla aplikacji DOS/
Win16, podsystemów OS/2, POSIX i bezpieczeństwa oraz zarządzają
nimi.

Rozdział 1

Abstrakcyjna warstwa sprzętowa (HAL) komunikuje się bezpośrednio ze
sprzętowymi komponentami komputera i zapewnia niezależny od sprzę-
tu interfejs dla warstwy mikrojądra Windows NT (patrz rysunek 1.4).
Taki interfejs pozwala na napisanie mikrojądra w sposób niezależny od
platformy sprzętowej i ułatwia przenoszenie systemu operacyjnego na
inne platformy. Procedury HAL mogą być wywoływane przez podsta-
wową część systemu operacyjnego oraz przez sterowniki urządzeń.

Rysunek 1.4

Interfejs HAL

W przypadku komputera używającego SMP (Symmetric Multi-Processing),
HAL udostępnia procesory wirtualne, które mogą być używane przez
mikrojądro sytemu operacyjnego.

HAL umożliwia także stworzenie pojedynczego interfejsu sterownika
urządzenia dla tego samego urządzenia wykorzystywanego na różnych
platformach sprzętowych. Ponieważ HAL zapewnia wirtualną warstwę
ponad rzeczywistym sprzętem, ten sam sterownik może obsługiwać wie-
le modeli komputerów opartych na danym procesorze.

Mikrojądro jest odpowiedzialne za przydzielanie zadań sprzętowym
elementom komputera. Jeśli w komputerze znajduje się wiele proceso-
rów, mikrojądro używa interfejsu do wirtualnych procesorów udostęp-
nianego przez HAL w celu zsynchronizowania ich aktywności.

Jednostką aktywności przydzielaną przez mikrojądro jest wątek. Wątek
jest najmniejszą jednostką, która może zostać przydzielona. Składa się on
z sekwencji instrukcji wykonywanych przez procesor w kontekście pro-
cesu. Proces może posiadać wiele wątków, a musi mieć przynajmniej
jeden.

Mikrojądro przydziela wątki kolejnemu dostępnemu procesorowi. Każdy
wątek ma związany z nim poziom pierwszeństwa. Istnieją 32 poziomy

Architektura TCP/IP w Windows

pierwszeństwa podzielone na klasę czasu rzeczywistego (poziomy
pierwszeństwa od 16 do 31) oraz klasę zmienną, nazywaną też dyna-
miczną (poziomy pierwszeństwa od 0 do 15). Wyższe numery pierw-
szeństwa implikują wyższy poziom pierwszeństwa dla danego wątku.
Wątki o wyższym poziomie pierwszeństwa są wykonywane w pierwszej
kolejności, i mogą wywłaszczać wątki o niższym poziomie pierwszeń-
stwa.

Mikrojądro jest niestronicowalne, co oznacza, że strony (stałe, 4KB jed-
nostki pamięci) zajmowane przez mikrojądro nie są czasowo usuwane
z pamięci do pliku PAGEFILE.SYS. Kod jądra jest niewywłaszczalny (nie
może zostać przerwany), natomiast oprogramowanie na zewnątrz mikro-
jądra, jak na przykład usługi wykonawcze Windows NT, jest wyw-
łaszczalne.

W systemie wieloprocesorowym mikrojądro może pracować jednocześnie
na wszystkich procesorach, synchronizując dostęp do krytycznych regio-
nów pamięci.

Decyzje o wykorzystaniu zasobów nie są podejmowane w mikrojądrze,
ale w komponentach wykonawczych Windows NT. Upraszcza to struk-
turę mikrojądra i zapobiega konieczności zmieniania go w przypadku
zmiany założeń w przyszłych edycjach systemu operacyjnego. Mikroją-
dro podejmuje jednakże decyzje o usunięciu procesów z pamięci.

Mikrojądro zarządza dwoma typami obiektów: dyspozycyjnymi i steru-
jącymi. Obiekty dyspozycyjne są używane do synchronizacji oraz opera-
cji przydzielania zasobów. Należą tu zdarzenia, semafory, mutanty, mu-
teksy, zegary i wątki. Tabela 1.1 zawiera zwięzłe objaśnienie obiektów
dyspozycyjnych. Obiekty sterujące są używane do sterowania pracą mi-
krojądra i nie mają wpływu na funkcje dyspozycyjne. Należą tu prze-
rwania, procesy, profile i asynchroniczne wywołania procedur. Tabela 1.2
zawiera zwięzłe objaśnienie obiektów sterujących.

Tabela 1.1 Obiekty dyspozycyjne

Obiekt Opis

Zdarzenie Używany do stwierdzenia, że zaszło zdarzenie, oraz przypisania mu

działania, jakie należy podjąć.

Semafor

Semafor steruje dostępem do danego zasobu. Liczba związana
z semaforem określa, ile wątków może jednocześnie używać
zasobu. Kiedy wątek uzyskuje dostęp do zasobu, liczba semaforowa
jest zmniejszana o jeden, a kiedy osiągnie zero, żaden inny wątek
nie uzyska dostępu do zasobu. W miarę zwalniania zasobów przez
wątki liczby semaforowe są zwiększane. Jeśli liczba semaforowa
wynosi 1, tylko jeden wątek może korzystać z zasobu.

Rozdział 1

Obiekt Opis

Mutant

Mutant steruje wzajemnie wykluczającymi się dostępami do danego
zasobu. Mutanty używane są w trybie użytkownika i w trybie jądra,
chociaż ich typowym zastosowaniem jest praca w trybie
użytkownika

Muteks

Podobnie jak mutanty, muteksy sterują wzajemnie wykluczającymi
się dostępami do danego zasobu. Muteks może być jednak
używany tylko przez komponenty pracujące w trybie jądra.

Zegar Zegara

używa się do wyzwalania zdarzeń i działań w specyficznym

momencie. Obiekty zegara odmierzają upływ czasu.

Wątek Wątek jest jednostką wykonującą kod programu, przydzielaną przez

mikrojądro do pracy na dostępnym procesorze. Wątki są własnością
procesów; dzięki nim program może wykonywać kilka zadań w tym
samym czasie.

Tabela 1.2 Obiekty sterujące

Obiekt Opis

Przerwanie Przerwanie

wiąże źródło przerwania z procedurą obsługi przerwania

przy pomocy IDT (Interrupt Dispatch Table, Tablica obsługi
przerwań)

Proces

Proces tworzy wirtualną przestrzeń adresową oraz środowisko,
w którym pracują wątki. Proces musi zostać zainicjowany, zanim
którykolwiek z jego wątków będzie mógł podjąć pracę.

Profil Profil

służy do zapamiętywania, ile czasu jest zużywane przez wątki

w bloku kodu programu systemowego.

Asynchroniczne
wywołanie
procedury

Obiekt ten służy do przerwania wykonywania określonego wątku
i wywołania procedury.

Warstwy protokołów w Windows NT

Protokoły sieciowe w Windows NT zaimplementowano jako część za-
rządcy wejścia/wyjścia. Rysunek 1.5 pokazuje, w jaki sposób w zarządcy
wejścia/wyjścia położone są warstwy modelu OSI. Poszczególne elemen-
ty są zorganizowane w warstwową listę współpracujących ze sobą ste-
rowników. Na przykład sterownik obsługujący protokół transportowy
współpracuje ze sterownikami kart sieciowych używając usług udostęp-
nianych przez interfejs NDIS (Network Driver Interface Specification,).
Funkcje wyższych warstw protokołu, jak readresatory i serwery, współ-
pracują z protokołami transportowymi używając usług udostępnianych
przez Interfejs Sterownika Transportu TDI (Transport Driver Interface,).

Warstwy modelu OSI od drugiej (warstwa łącza danych) do piątej (war-
stwa sesji) są zawarte w zarządcy wejścia/wyjścia i pracują w trybie ją-

Architektura TCP/IP w Windows

dra systemu Windows NT. Warstwa fizyczna związana jest bezpośrednio
ze sprzętem, dlatego na rysunku umieszczono ją poza zarządcą wej-
ścia/wyjścia. Wszystkie komponenty protokołu, jak sterowniki kart sie-
ciowych, sterowniki protokołu transportu, interfejs sterownika transpor-
tu, readresator i serwery stanowią zorganizowaną listę sterowników,
działających w trybie jądra. Tryb jądra pozwala im na pełny dostęp do
sieci i sprzętu w komputerze oraz sprawia, że implementacja protokołu
jest efektywna: podczas przetwarzania pakietów sieciowych niepotrzeb-
ne jest przełączanie z trybu użytkownika do trybu jądra i odwrotnie.
Zbyt częste przełączanie trybów jest niepożądane, gdyż obniża spraw-
ność komputera.

Sterowniki kart sieciowych (patrz rysunek 1.5) pracują w podwarstwie
MAC (Media Access Control,) modelu IEEE802. Model ten jest szeroko
wykorzystywany przy opisie funkcjonowania wielu sieci lokalnych
i rozległych. Zakłada on, że warstwa łącza danych modelu OSI składa się
z dwóch podwarstw: warstwy MAC oraz warstwy LLC (Logical Link Con-
trol, Sterowanie łączem logicznym) - patrz rysunek 1.6.

Rysunek 1.5

Model sieciowy Windows
NT

Warstwa MAC komunikuje się bezpośrednio z warstwą fizyczną i jest
odpowiedzialna za wykorzystanie mechanizmów sprzętowych sieci
w celu umożliwienia komunikacji pomiędzy dwoma komputerami znaj-
dującymi się w tej samej fizycznej sieci. Na przykład w sieciach Ethernet,
MAC przed przesłaniem pakietu wykorzystuje mechanizm CSMA/CD
(Carrier Sense Multiple Access with Collission Detect, Wykrywanie jednocze-
snego dostępu z detekcją kolizji) - aby upewnić się, że fizyczny kanał jest
wolny. Natomiast w sieciach Token Ring oraz FDDI (Fiber Distributed
Data Interface,) MAC oczekuje na wolny żeton przed przesłaniem pakietu.

Rozdział 1

Warstwa LLC operuje ponad warstwą MAC i zapewnia protokołom
wyższego rzędu niezależność od różnic w warstwie MAC. Sterownik
NDIS spełnia tutaj funkcję warstwy LLC, aczkolwiek oprócz tego robi
o wiele więcej.

Interfejs NDIS umożliwia protokołom transportowym używanie kart
sieciowych bez znajomości szczegółów rzeczywistych sterowników kart
sieciowych. Udostępnia im wyidealizowaną, wirtualną kartę sieciową,
z dokładnie zdefiniowanymi procedurami i usługami. Protokoły trans-
portowe porozumiewają się z kartą sieciową poprzez ów wyidealizowa-
ny interfejs. NDIS natomiast zajmuje się mapowaniem tego interfejsu na
sterownik rzeczywistej karty sieciowej. Utrzymuje w ten sposób łączność
pomiędzy protokołami transportowymi i sterownikami kart sieciowych.

Rysunek 1.6

Podwarstwy MAC i LLC
modelu IEEE 802

Moduł protokołów transportu odpowiada warstwom trzeciej i czwartej
modelu OSI, i nie powinien być mylony z warstwą transportu w tym
modelu. Windows NT posiada wiele protokołów transportowych:

NBF (NetBIOS Frame). Jest to protokół transportowy będący odmianą
NetBEUI (Net Basic Input Output System Extended User Interface). Pro-
tokół ten jest kompatybilny z istniejącymi sieciami opartymi na Net-
BIOS, (Net Basic Input Output System), jak np. LAN Manager, LAN Se-
rver oraz licznymi sieciami pracującymi w DOS.

NWLink. Jest to zgodna ze specyfikacją NDIS wersja IPX/SPX (Inter-
net Packet Exchange/Sequence Packet Exchange, Międzysiecio-
wa/Sekwencyjna Wymiana Pakietów), protokołu używanego
w sieciach Novell. NWLink można używać do ustanowienia połączeń
peer-to-peer z komputerami pracującymi pod Windows oraz węzłami
MS-DOS oraz OS/2, które używają tego protokołu. NWLink jest tra-
sowalnym protokołem i można przy jego użyciu budować połączone
sieci.

DLC (Data Link Protocol, Protokół łącza danych). Przy użyciu tego
protokołu można łączyć się z komputerami typu mainframe.

Architektura TCP/IP w Windows

AppleTalk. AppleTalk jest zestawem protokołów używanym przez
komputery Macintosh do łączenia się z serwerem AppleTalk. Serwe-
rem AppleTalk może być inny komputer Macintosh albo serwer Win-
dows NT emulujący serwer AppleTalk. AppleTalk standardowo insta-
luje się podczas instalacji serwera NT. Producenci oprogramowania
mogą otrzymać od firmy Microsoft wersję AppleTalk do zainstalowa-
nia na komputerach z Windows NT Workstation.

TCP/IP. Jest to otwarty protokół zaimplementowany w licznych sys-
temach oraz używany w Internecie. Jest preferowanym protokołem,
jeśli celem jest jak najszersza kompatybilność. TCP/IP jest trasowal-
nym protokołem i można przy jego użyciu budować połączone sieci,
takie jak istniejący Internet

Protokół NBF zapewnia dwa typy usług: niezawodne usługi połączeniowe
i zawodne usługi bezpołączeniowe. Zawodne usługi bezpołączeniowe, na-
zywane także usługami datagramowymi, używane są przez aplikacje
pracujące na zasadzie żądanie-odpowiedź oraz przez protokoły zorien-
towane na transmisję do wszystkich węzłów sieci (broadcast). NBF używa
na przykład trybu broadcast do ogłaszania w sieci nazw, dzięki czemu
można uniknąć otwierania oddzielnych połączeń do każdego z węzłów.
Zazwyczaj transmisje typu broadcast nie są przekazywane przez routery
do innych sieci, gdyż znacząco zwiększyłoby to ich obciążenie. Usługi
połączeniowe, nazywane czasem obwodami logicznymi, używane są
wtedy, kiedy wymagana jest niezawodna transmisja danych poprzez
sieć.

Protokół NBF jest wykorzystywany przez liczne elementy systemu Win-
dows. Niestety, nie jest on trasowalny, ponieważ stworzono go jako mo-
nolityczny protokół, mający z założenia działać w pojedynczej sieci. Pro-
tokół NBF nie posiada oddzielnej warstwy sieciowej i nie ma żadnej moż-
liwości odróżnienia jednej sieci od drugiej, co czyni go nietrasowalnym.
Istnieje jednakże możliwość pracy protokołu NBF ponad TCP/IP. Wów-
czas NBF staje się trasowalny, ponieważ trasowalny jest TCP/IP.
W sieciach TCP/IP, w których aplikacje wymagają użycia NBF, jest to
powszechnie stosowana metoda.

Interfejs sterownika transportu położony jest ponad modułami protoko-
łów transportowych i udostępnia protokołom wyższej warstwy (np. war-
stwie sesji) standardowy zestaw usług. Na rysunku 1.5 readresator
i serwery pokazane są jako należące do warstwy sesji. Readresator prze-
kierunkowuje lokalne żądania usług sieciowych do innych komputerów
w sieci, a serwery są modułami programowymi, które obsługują zarówno
żądania lokalne, jak i przychodzące z sieci. Ponieważ interfejs sterownika
transportu jest wspólną warstwą dla komponentów warstwy sesji, wyko-

Rozdział 1

rzystują go one do przekazywania ich żądań odpowiedniemu modułowi
protokołu transportu.

Chociaż warstwa prezentacji modelu OSI widnieje na rysunku 1.5 tuż
ponad usługami wykonawczymi, w praktycznych zastosowaniach nie
używa się jej. Warstwa aplikacji pracuje w trybie użytkownika.

Moduł dostawcy jest biblioteką DLL dostarczoną przez producenta sieci.
Dostawca łączy się z odpowiednim readresatorem. Windows NT umoż-
liwia jednoczesną pracę wielu modułów dostawcy, co umożliwia produ-
centom oprogramowania sieciowego pisanie własnych programów
klienckich. Do łączenia modułu dostawcy z odpowiednim readresatorem
używa się komponentu MPR (Multiple Provider Router).

Rysunek 1.5 pokazuje model sieciowy Windows NT dla dowolnego pro-
tokołu, natomiast rysunek 1.7 pokazuje model sieciowy specyficzny dla
protokołu TCP/IP.

Na rysunku 1.7 widać ,że protokoły IP, TCP i UDP zostały zaimplemen-
towane jako sterowniki w zarządcy wejścia/wyjścia. Warstwa IP odpo-
wiada warstwie sieci modelu OSI, natomiast warstwa TCP i UDP odpo-
wiada warstwie transportu OSI.

Rysunek 1.7

Model sieciowy Windows
NT dla protokołów TCP/IP

Warstwy protokołów w Windows 9x

Systemy operacyjne Windows 9x nie posiadają tak wyrafinowanej
i bezpiecznej architektury jak Windows NT. Sterowniki i stosy protoko-

Architektura TCP/IP w Windows

łów w Windows 95 zapewniają podobne funkcje jak ich odpowiedniki
z Windows NT, ale komponenty te nie są wzajemnie wymienialne.

Rysunek 1.8 pokazuje model sieciowy Windows 9x. Sterowniki kart sie-
ciowych umożliwiają dostęp do sprzętu sieciowego opisanego jako war-
stwa fizyczna. Interfejs NDIS pod względem architektury jest taki sam,
jak w Windows NT. Różni się od niego w tym sensie, że został napisany
specjalnie dla platformy Windows 9x.

Moduł TCP/IP jest zaimplementowany jako sterownik. Zazwyczaj do
łączenia się ze sterownikiem TCP/IP używa się interfejsu Winsock. Inter-
fejs Winsock, napisany w postaci biblioteki DLL, jest oparty na interfejsie
Berkeley Sockets, którego używa się w wielu systemach UNIX do pisania
programów korzystających z protokołu TCP/IP. Udostępnia on aplika-
cjom standardowy interfejs programowy. Interfejs Winsock jest także
dostępny w Windows NT; pracuje tam ponad interfejsem sterownika
transportu.

Readresator przekierunkowuje lokalne żądania usług sieciowych do in-
nych komputerów w sieci, a serwery są modułami programowymi, które
obsługują zarówno żądania lokalne, jak i przychodzące z sieci.

Rysunek 1.9 pokazuje komponenty sieciowe Windows 9x które tworzą
architekturę z rysunku 1.8. Windows 9x wspiera jednocześnie kilka pro-
tokołów sieciowych. Protokoły te zaimplementowano jako 16- lub 32-
bitowe wirtualne sterowniki urządzeń (VxD).

Rysunek 1.8

Model sieciowy Windows 9x
dla protokołów TCP/IP.

Warstwa interfejsu programowego aplikacji (API) na rysunku 1.9 może
używać Win32 lub 16-bitowego interfejsu Windows. API umożliwia do-
stęp do dzielonych zasobów w innych komputerach, jak np. systemy
plików, drukarki itp.

Rozdział 1

Sterownik dostawców (MPR) zajmuje się rozdzielaniem wszystkich ope-
racji sieciowych, udostępniając podstawowe usługi wspólne dla wszyst-
kich sieci.

Komponent dostawcy sieciowego udostępnia interfejs dostawcy usług
sieciowych. MPR komunikuje się bezpośrednio z dostawcą sieciowym.

Zarządca instalowalnego systemu plików (Installable File System, IFS)
przekierunkowuje żądania dostępu do plików do odpowiedniego ste-
rownika systemu plików. Zarządca IFS może jednocześnie obsługiwać
wiele systemów plików. Obsługuje także ładowalne sterowniki systemów
plików.

Sieciowy sterownik systemu plików FSD (File System Driver) odwzorowu-
je charakterystykę zdalnego systemu plików na lokalnym komputerze
z Windows 9x. FSD jest pisany dla konkretnego typu sieci i związany
z oprogramowaniem klienta sieciowego dostarczanym przez sprzedawcę
sieci.

Architektura TCP/IP w Windows

Rysunek 1.9

Komponenty sieciowe Windows 9x dla protokołów TCP/P.

Moduł transportu sieciowego obsługuje używany protokół. W Windows
9x możliwe jest jednoczesne używanie wielu protokołów, jak np.
NetBEUI, IPX/SPX oraz TCP/IP. Sieciowy sterownik FSD łączy się
z modułem transportu sieciowego.

NDIS jest specyfikacją interfejsu, który określa współpracę pomiędzy
protokołem transportu sieciowego a sterownikiem karty sieciowej. Za-
równo sterownik, jak i protokoły transportu sieciowego muszą odpowia-
dać specyfikacji NDIS. Wersja NDIS używana w Windows 9x składa się
z zarządcy protokołów, sterownika dostępu do nośnika (MAC), mini-
portu oraz sterowników osłony mini-portu. Zarządca protokołów za-
pewnia wsparcie dla urządzeń typu plug-and-play. Sterowniki mini-
portu zawierają funkcje wspólne dla wszystkich kart sieciowych
i zmniejszają ilość kodu, który trzeba napisać do obsługi karty sieciowej.
Architekturę NDIS omówimy szczegółowo w późniejszym podrozdziale
„NDIS w Windows”.

Sterownik karty sieciowej łączy się bezpośrednio z kartą sieciową i ste-
ruje jej funkcjami. Interfejs NDIS umożliwia współpracę protokołów
transportowych z kartą sieciową.

Elementy protokołu TCP/IP w Windows NT

We wcześniejszym podrozdziale „Warstwy protokołów w Windows NT”
opisaliśmy ogólną architekturę systemu Windows NT. W dalszych pod-
rozdziałach opiszemy szczegółowo elementy protokołu.

NDIS w Windows

W okresie przed późnymi latami osiemdziesiątymi większość implemen-
tacji protokołów transportowych była pisana dla specyficznych wersji
interfejsów dostępu do nośnika (MAC). Interfejsy te definiowały sposób,
w jaki protokół miał komunikować się z kartą sieciową. Z powodu specy-
ficznego charakteru tego interfejsu producenci kart sieciowych mieli kło-
poty z przystosowaniem go do różnych sieciowych systemów operacyj-
nych obecnych na rynku. Każdy producent kart musiał pisać sterowniki
obsługujące poszczególne implementacje protokołów w różnych środo-
wiskach sieciowych. W 1989 firmy Microsoft i 3COM wspólnie zdefinio-
wały standard interfejsu pośredniczącego pomiędzy warstwą MAC

Rozdział 1

a sterownikami protokołów położonych wyżej w hierarchii OSI. Standard
ten znany jest jako NDIS (Network Device Interface Specification, Specyfika-
cja interfejsu sterownika sieciowego).

NDIS umożliwia zestandaryzowaną wymianę danych pomiędzy proto-
kołami transportowymi a sterownikiem karty sieciowej. Definiuje inter-
fejs programowy używany przez protokoły do komunikacji z sterow-
nikiem karty sieciowej. Dowolne protokoły i dowolne sterowniki karty
sieciowej, zgodne ze specyfikacją NDIS, mogą wymieniać między sobą
dane. W celu zainicjowania kanału komunikacyjnego pomiędzy sterow-
nikiem protokołu a sterownikiem karty używa się procesu nazywanego
wiązaniem.

Windows NT i Windows 9x obecnie obsługują sterowniki kart i protokoły
napisane w wersji NDIS 3.0. NDIS pozwala na instalację wielu kart sie-
ciowych w jednym komputerze, przy czym każda karta sieciowa może
obsługiwać wiele protokołów (patrz rysunek 1.10). Zaletą takiego roz-
wiązania jest to, że komputery z Windows NT mogą mieć jednoczesny
dostęp do różnych typów serwerów sieciowych, z których każdy używa
innego protokołu transportowego, poprzez ten sam interfejs sieciowy.
Można np. uzyskać jednoczesny dostęp do serwera NetWare przy użyciu
IPX i do serwera UNIX przy użyciu TCP/IP. Protokół TCP/IP może tak-
że służyć do łączenia się z serwerem Windows NT.

Wersja NDIS 3.0 w Windows NT nie potrzebuje modułu zarządcy proto-
kołów do łączenia ze sobą różnych komponentów sieciowych. Używa
w tym celu informacji zawartych w rejestrze (wewnętrznej, hierarchicznej
bazie danych informacji o systemie) oraz niewielkiego programu nazy-
wanego opakowaniem NDIS, który „otacza” sterownik karty sieciowej.

Rysunek 1.10

Interfejs NDIS
z opakowaniami

Architektura TCP/IP w Windows

Rysunek 1.11

Komponenty NDIS
w Windows NT

NDIS w Windows NT obsługiwane jest przez NDIS.SYS, który działa
jako interfejs otaczający sterownik NDIS (patrz rysunek 1.11). Interfejs ten
komunikuje się ze sterownikami protokołów i z komponentami usług
wykonawczych Windows NT.

Interfejs Sterownika Transportu

Model sieciowy Windows NT definiuje standardowy interfejs pomiędzy
warstwami sesji i transportu, nazywany interfejsem sterownika transpor-
tu (Transport Driver Interface, TDI). Służy on do komunikacji
z protokołami transportowymi. Jego działanie jest zbliżone do sterownika
NDIS operującego pomiędzy warstwą sieci i łącza danych modelu OSI.

Interfejs sterownika transportu nie jest pojedynczym programem, ale
specyfikacją, zgodnie z którą pisane są górne warstwy protokołów trans-
portowych. Programy wyższych warstw, jak readresator i serwery, rów-
nież pisane są zgodnie ze specyfikacją TDI. Umożliwia to komunikację
między protokołami transportowymi a protokołami wyższych warstw.

Dostawcy w Windows

Dostawcami nazywamy komponenty sieciowe, które umożliwiają kom-
puterowi klienta dostęp do zasobów sieci. Dostawcy są zazwyczaj pro-
gramami klienckimi, jak np. oprogramowanie klienta sieciowego firmy
Microsoft, które umożliwia komputerom z Windows 9x i NT komunika-
cję z serwerem Windows NT. Każdy sprzedawca oprogramowania sie-
ciowego może dostarczyć swój własny program klienta-dostawcy, który
umożliwi korzystanie z zasobów tej sieci.

W Windows NT warstwa dostawcy rozciąga się po obu stronach granicy
pomiędzy trybem jądra i trybem użytkownika i zarządza poleceniami
dostępu do zasobów sieciowych. Aplikacje uzyskują dostęp do zasobów
przy użyciu poleceń Jednolitej Konwencji Nazewnictwa UNC (Uniform

Rozdział 1

Naming Convention), bądź też przy użyciu sieciowego interfejsu progra-
mowego aplikacji WNet API (Windows Network Application Programming
Interface).

Polecenia UNC identyfikują dzielone zasoby sieciowe, jak np. katalogi,
nazwy plików lub drukarki sieciowe. Nazwa UNC posiada następującą
składnię:

\\NazwaSerwera\

NazwaZasobu

\ŚcieżkaPodkatalogu\NazwaPliku

Rysunek 1.12

Interfejs sterownika transpor-
tu

NazwaSerwera

jest to nazwa serwera, na którym znajduje się żądany za-

sób. NazwaZasobu jest nazwą, pod którą zasób jest znany i dzielony
w sieci. ŚcieżkaPodkatalogu jest opcjonalną nazwą ścieżki. NazwaPliku
określa nazwę pliku, jeśli dzielony zasób jest plikiem. UNC umożliwia
pisanie poleceń, które przypisują zasobom sieciowym lokalne litery dys-
ków. Jeśli na przykład zechcemy przypisać lokalną literę dysku do zaso-
bu sieciowego \\NTS\Docs, możemy to zrobić przy użyciu następującego
polecenia:

NET USE E: \\NTS\Docs

Po wydaniu tego polecenia można używać litery dysku E: do dostępu do
\\NTS\Docs.

Interfejs WNet API jest częścią Win32 API. Umożliwia komputerom
Windows łączenie się z wieloma sieciami, przeglądanie zasobów siecio-
wych oraz przesyłanie danych pomiędzy połączonymi komputerami.

Warstwa dostawcy zawiera dwa komponenty, które przekierunkowują
żądania UNC i WNet do odpowiedniego dostawcy: MUP (Multiple UNC
Provider, Złożony dostawca UNC) oraz MPR (Multiple Provider Router,
Złożony sterownik dostawców). MUP używany jest do przekierunko-
wywania żądań UNC, a MPR do przekierunkowywania żądań WNet.

Architektura TCP/IP w Windows

Kiedy MUP otrzymuje polecenie UNC, lokalizuje wówczas właściwego
readresatora, który wykona polecenie. Kiedy MPR otrzymuje polecenie
WNet, przekazuje je kolejno do każdego readresatora, aż znajdzie takie-
go, który będzie mógł je wykonać.

Złożony dostawca UNC (Multiple UNC Provider, MUP)

Dostawcę UNC nazywamy złożonym, ponieważ w komputerze Win-
dows NT może znajdować się kilku dostawców UNC, z których każdy
pracuje z innym programem klienckim od innego producenta. Jego funk-
cją jest lokalizowanie zasobów sieciowych na podstawie ich nazw UNC.
Po otrzymaniu nazwy UNC, MUP przekazuje ją do jednego z zarejestro-
wanych dostawców UNC. Kiedy dostawca stwierdzi, że potrafi odszukać
żądany zasób, wówczas MUP przesyła mu pozostałą część polecenia.
Jeśli aplikacja używa funkcji, które operują na nazwach UNC, wówczas
MUP przekazuje ich żądania do odpowiedniego sterownika systemu
plików.

Złożony sterownik dostawców (Multiple Provider Router, MPR)

MPR (patrz rysunek 1.14) udostępnia interfejs, który pozwala aplikacjom
na używanie wywołań systemowych do WNet API, niezależnie od typu
zasobu sieciowego. MPR jest odpowiedzialny za przekierunkowanie
żądań WNet do odpowiedniego sterownika systemu plików. Żądania
lokalnych zasobów kierowane są do lokalnego systemu plików, a żądania
zasobów sieciowych są przesyłane do odpowiedniego klienta sieciowego.

Architektura TCP/IP w Windows

Interfejsy programowe: Winsock i NetBIOS

Winsock i NetBIOS są alternatywnymi interfejsami programowymi dla
aplikacji Windows. Każdy z nich zaimplementowano jako oddzielną
bibliotekę DLL (patrz rysunki 1.15 i 1.16)

Rysunek 1.15

Interfejs Winsock

Rysunek 1.16

Interfejs NetBIOS

Rozdział 1

Winsock udostępnia protokołom TCP/IP model systemu plików oparty
na interfejsie Berkeley Software Distribution (BSD) UNIX Sockets. Użycie
Winsock ułatwia przenoszenie programów sieciowych pisanych pod
UNIX do środowiska Windows.

NetBIOS może pracować bezpośrednio na stosie protokołów NBF albo
też ponad TCP/IP. Szczegóły pracy NetBIOS ponad TCP/IP omawiają
dokumenty RFC 1001 i RFC 1002. Dokumenty RFC można otrzymać
z serwera INTERNIC pod adresem ds.internic.net albo z serwera ftp
ftp.internic.net

. NetBIOS jest interfejsem warstwy sesji, który określa

w sieci nazwy logiczne i pozwala na tworzenie sesji sieciowych, umożli-
wiających niezawodną wymianę danych.