Biblia TCP IP Tom 3 - Uzupelnienie PDF

-/ja \ \
V V : / \ \
tTi fW *' * J V -
eh -
Sn
ar,
U z u p e n ie n ie
W. Richard Stevens
tom3
BIBLIA TCP/IP
Uzupenienie
W. Richard Stevens
tom 3
BIBLIA TCP/IP
Uzupenienie
W. Richard Stevens
TT Addison
W esley
Biblia TCP/IP, tom III. Uzupenienie

W. Richard Stevens
Tytu oryginau amerykaskiego: TCP/IP lllustrated, Vol. III Copyright 1996 by Addison-Wesley Publishing Company Published by arrangement with Addison Wesley Longman, Inc. The BSD Daemon used on the cover of this book is reproduced with the permission of Marshall Kirk McKusick
Opracowanie wersji polskiej: Marcin Palacz

Copyright for the Polish edition by Wydawnictwo RM Sp. z o.o., Warszawa 1998
W ydawnictwo RM , 00-987 W a rszaw a 4, sk r. poczt. 144 e-m ail: readm e@ rm .com .pl W W W : http://w w w .rm .com .pl Ali rights reserved. No part of this book m ay be reproduced ortransmitted in any form or by any m eans, electronic or m echanical, including photocopying, recording or by any information storage retrieval system , without prior perm ission in writing from the Publisher. ad na c z tej pracy nie moe by powielana i rozpow szechniana w jakiejkolwiek formie i w jakikolw iek sposb (elektroniczny, m echaniczny) w cznie z fotokopiowaniem, nagrywaniem na tam y lub przy uyciu innych System w, bez w cze n ie jsze j pisem nej zgody wydaw cy. W szystkie n azw y handlowe i towarw, w ystpujce w niniejszej publikacji, s znakam i towarowymi zastrzeo nymi lub nazw am i zastrzeonym i odpowiednich firm odnonych w acicieli. Printed in Poland. W ydawnictwo RM dooyo w szelkich stara, aby zapew ni n ajw y sz ja ko tej k si ce . Je d n a k e nikomu nie udziela adnej rkojmi ani gw arancji. W ydawnictwo RM nie jest w adnym wypadku odpowiedzialne za jakiekolw iek szkody cznie ze szkodam i z tytuu utraty zysk w zw izanych z prowadzeniem przedsibiorstwa, przerw w dziaalnoci przedsibiorstw a lub utraty informacji gospodarczej, bdcych nastpstwem korzystania z informacji zaw artych w niniejszej publikacji RM , nawet jeeli RM zostao zawiadom ione o moliwoci w ystpienia szkd.
ISBN 83-87216-26-7
Redaktor prowadzcy: Beata Brzeg-Wieluska Redakcja: Anna Marczak Opracowanie graficzne okadki: Grayna Jdrzejec Skad: Marcin Fabijaski Druk i oprawa: Oficyna Wydawnicza READ ME - Drukarnia w odzi
Wydanie I 10 9 8 7 6 5 4 3 2 1
Moim nauczycielom, od ktrych w cigu minionych lat nauczyem si tak wiele, a szczeglnie Jimowi Braultowi, Dave'owi Hansonowi, Bobowi Huntowi i Banowi Kenghanowi
Spis treci
Przedmowa Rozdzia 1 Wprowadzenie do T/TCP
Wstp Klient-serwer UDP Klient-serwer TCP Klient-serwer T /T C P Sie testowa Przykad pomiaru czasu Aplikacje Historia Implementacje Podsumowanie
XV 1
1 1 7 16 19 20 22 24 26 28
1.1
1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10
Rozdzia 2
2.1 2.2 2.3 2.4 2.5 2.6
Protok T/TCP
Wstp Nowe opcje TCP zwizane z T /T C P Zmienne implementacyjne T /TC P Diagram zmiany stanw Stany rozszerzone T/T C P Podsumowanie
31
31 32 35 36 38 40
Rozdzia 3
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8
T/TCP - przykady
Wstp Przeadowanie klienta Normalna transakcja T /T C P Serwer otrzymuje duplikat starego segmentu SYN Przeadowanie serwera danie lub odpowied z dugoci wiksz ni MSS Kompatybilno wstecz Podsumowanie
43
43 44 46 47 48 49 54 56
Rozdzia 4
4.1 4.2 4.3 4.4 4.5
Protok T/TCP - kontynuacja

Wstp Numery portw i stan TIME_WAIT Rola stanu TIME_WAIT Skrcenie stanu TTME_WAIT Unikanie potrjnego uzgodnienia przy pomocy TAO
59
59 59 62 65 69
VIII
Biblia TC P /IP -tom III
Spis treci
4.6 4.7
Wartoci CC z zawinitym" bitem znaku Podsumowanie
72 75
Rozdzia 5
5.1 5.2 5.3 5.4
Implementacja T/TCP: warstwa gniazd

Wstp Stae Funkcja sosend Podsumowanie
77
77 77 78 79
Rozdzia 6
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12
implementacja T/TCP: tablica rutowania

Wstp Kod rdowy - wprowadzenie Struktura radix_node_head Struktura rtentry Struktura rt_metrics Funkcja in jnithead Funkcja in_addroute Funkcja in_matroute Funkcja in_clsroute Funkcja in_rtqtimo Funkcja in_rtqkill Podsumowanie
81
81 82 83 83 83 84 85 86 87 88 90 93
Rozdzia 7
7.1 7.2 7.3 7.4
Implementacja T/TCP: bloki kontrolne protokou

Wstp Funkcja in_pcbladdr Funkcja in_pcbconnect Podsumowanie
95
95 96 97 98
Rozdzia 8
8.1 8.2 8.3 8.4 8.5 8.6 8.7
implementacja T/TCP: przegld TCP

Wstp Kod rdowy - wprowadzenie Struktura TCP protosw Blok kontrolny TCP Funkcja tcp_init Funkcja tcp_slowtimo Podsumowanie
99
99 99 100 101 102 102 103
Rozdzia 9
9.1 9.2 9.3
Implementacja T/TCP: wyjcie TCP

Wstp Funkcja tcp_output Podsumowanie
105
105 105 112
10
10.1 10.2 10.3 10.4 10.5
Implementacja T/TCP: funkcje TCP
113
113 113 114 115 116
Wstp Funkcja tcp_newtcpcb Funkcja tcp_rtlookup Funkcja tcp_gettaocache Obliczenie czasu oczekiwania na powtrzenie transmisji 10.6 Funkcja tcp_close 10.7 Funkcja tcp_msssend 10.8 Funkcja tcp_mssrcvd 10.9 Funkcja tcp_dooptions 10.10 Funkcja tcp_reass 10.11 Podsumowanie
120 121
123 129 131 133
11
11.1 11.2 11.3 11.4 11.5 11.6
Implementacja T/TCP: wejcie TCP
135
135 137 138 140 144 151 151 152 153 155 157
Wstp Przetwarzanie wstpne Przewidywanie nagwka Inicjacja pasywnego otwarcia Inicjacja aktywnego otwarcia Zabezpieczenie przed zawinitymi" numerami sekwencyjnymi (PAWS) 11.7 Przetwarzanie ACK 11.8 Zakoczenie pasywnych i jednoczesnych otwar 11.9 Przetwarzanie ACK (kontynuacja) 11.10 Przetwarzanie flagi FIN 11.11 Podsumowanie
12
12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8
Implementacja T/TCP: dania uytkownika TCP

Wstp danie PRU_CONNECT Funkcja tcp_connect dania PRU_SEND i PRU_SEND_EOF Funkcja tcp_usrclosed Funkcja tcp_sysctl Przyszo T/T C P Podsumowanie
159
159 159 160 163 165 166 166 167
13
13.1 13.2 13.3 13.4
HTTP - protok przesyania hipertekstu

Wstp Wprowadzenie do HTTP i HTML Protok HTT Przykad
169
169 171 173 178
Biblia TCP/IP -to m III
Spis treci
13.5 13.6 13.7
Dane statystyczne HTTP Problemy zwizane z szybkoci i sprawnoci dziaania Podsumowanie
181 183 185
Rozdzia 14
14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9 14.10 14.11 14.12 14.13
Pakiety znalezione w serwerze HTTP

Wstp Jednoczesne serwery HTTP Czas pomidzy otrzymaniem kolejnych segmentw SYN Pomiary RTT Drugi argument funkcji listen Opcje w segmencie SYN klienta Powtrne wysania SYN klienta Nazwy domen Ograniczenie czasu sondowania trwaoci poczenia Symulacja rozmiaru tablicy rutowania T /T C P Wspdziaanie z buforami mbuf Blok protokou TCP i przewidywanie nagwka Podsumowanie
187
187 190 191 196 198 203 206 208 208 212 214 215 218
Rozdzia 15
15.1 15.2 15.3 15.4 15.5 15.6
NNTP - sieciowy protok przesyania informacji

Wstp Protok NNTP Prosty klient informacji Bardziej skomplikowany klient informacji Statystyka NNTP Podsumowanie
221
221 223 227 229 230 231
Rozdzia 16
16.1 16.2 16.3 16.4 16.5
Protokoy domeny unixowej: wprowadzenie

Wstp Zastosowania Szybko dziaania Przykady programw Podsumowanie
233
233 234 235 237 239
Rozdzia 17
17.1 17.2 17.3 17.4 17.5 17.6 17.7
Protokoy domeny unixowej: implementacja

Wstp Wprowadzenie do kodu rdowego Unbcowe struktury domain i protosw Struktura adresowa gniazda domeny unixowej Bloki kontrolne protokou domeny unixowej Funkcja uipc_usrreq danie PRU_ATTACH i funkcja unp_attach
241
241 241 242 244 245 248 249
Spis treci
XI
17.8 17.9 17.10 17.11 17.12 17.13 17.14 17.15 17.16 17.17 17.18 17.19
danie PRU_DETACH i funkcja unp_detach danie P R U _ B I N D i funkcja unp_bind danie PRU_CONNECT i funkcja unp_connect danie PRU_CONNECT2 i funkcja unp_connect2 Odwoanie systemowe socketpair Odwoanie systemowe pip danie PRU_ACCEPT danie PRU_DISCONNECT i funkcja unp_disconnect danie PRU_SHUTDOWN i funkcja unp_shutdown danie PRU_ABORT i funkcja unp_drop Rne dania Podsumowanie
250 252 255 260 264 268 269 269 272 273 274 276
Rozdzia 18
18.1 18.2 18.3 18.4 18.5 18.6 18.7 18.8 18.9 18.10 18.11 18.12
Protokoy domeny unixowej: l/O i przekazywanie deskryptorw

Wstp dania PRU_SEND i PRU_RCVD Przekazywanie deskryptorw Funkcja unp_intemalize Funkcja unp_extemalize Funkcja unp_discard Funkcja unp_dispose Funkcja unp_scan Funkcja unp_gc Funkcja unp_mark Szybko dziaania (raz jeszcze) Podsumowanie
277
277 277 282 288 290 291 292 293 294 302 303 304
Dodatek A
A .l A.2 A.3
Pomiary czasu w sieci

Pomiary RTT z uyciem programu Ping Pomiary w stosie protokou Czas propagacji a szeroko pasma
305
306 308 314
Dodatek B Bibliografia Indeks
Programowanie aplikacji T/TCP
319 323 329
Przedmowa
Wstp i ukad ksiki
Ksika, ktr wanie oddajemy do rk Pastwa, naley do serii Biblia T C P /IP " (tom 1 Protokoy [Stevens 1994] i tom 2 Implementacje [Wright i Stevens 1995]). W ksice tej czsto odwoujemy si do informacji zawartych w poprzednich tomach - uywamy wtedy okrele tom 1" i tom 2", oraz do innych opracowa wymienionych w zaczonej na kocu bibliografii - stosujemy wwczas odnoniki w nawiasach kwadratowych. Ksika zostaa podzielona na trzy czci, z ktrych kada omawia oddzielne zagadnienie: Cz I rozdziay 1-4 Protok TCP dla transakcji, powszechnie nazywany T /TC P. Jest to rozszerze nie TCP zaprojektowane tak, by transakcje klient-serwer byy szybsze, bardziej efektywne i niezawodne. Osiga si to przez pominicie potrjnego uzgodnie nia przy inicjacji poczenia i przez skrcenie czasu TIME_WAIT po jego za koczeniu. Zobaczymy, e T /T C P moe zaoferowa szybko dziaania zblio n do UDP, a jednoczenie zapewnia znacznie wiksz ni UDP niezawodno i zdolno adaptacyjn. Transakcja jest zdefiniowana jako danie klienta skie rowane do serwera, z nastpujc po daniu odpowiedzi serwera. (Uwaga: pojcia transakcja nie uywamy w znaczeniu transakcji pojawiajcej si w kon tekcie baz danych: blokowanie, potwierdzenie dwufazowe i odtworzenie.) Cz II rozdziay 5-12 Aplikacje T C P/IP, szczeglnie HTTP (Hypertext Transfer Protocol, podstawa wiatowej Pajczyny - W WW) oraz NNTP (Network News Transfer Protocol, podstawa systemu Usenet News). Cz III rozdziay 13-18 Protokoy domeny unixowej. Protokoy takie istniej we wszystkich unixowych implementacjach T C P/IP i wielu implementacjach nalecych do innych systemw ni Unix. Okrelaj sposb komunikacji midzy procesami (IPC) i uywaj tego samego interfejsu gniazd co TCP/IP. Jeli klient i serwer dziaaj w tym samym komputerze, protokoy domeny urtbcowej s czsto dwukrotnie szybsze ni TC P/IP. Prezentacja T /T C P zawarta w czci I podzielona jest na dwa dziay. W rozdzia ach 1-4 przedstawiony zosta protok i zademonstrowane jego dziaanie na wielu przykadach. Ten materia jest duym rozszerzeniem krtkiej prezentacji T /T C P w rozdziale 24.7 tomu 1. Rozdziay 5-12 ukazuj implementacj T /T C P zawart w kodzie sieciowym systemu 4.4BSD-Lite (jest to kod zaprezentowany w tomie 2). Poniewa pierwsza implementacja T /T C P zostaa udostpniona dopiero we wrzeniu 1994 r., mniej wicej rok po opublikowaniu tomu 1 i dokadnie w okresie, gdy tom 2 by bliski ukoczenia, szczegowy opis T /TC P, z przykadami
X IV
Przedmowa
i szczegami implementacji, musia zaczeka do ukazania si nastpnego tomu serii. Cz II, aplikacje HTTP i NNTP, jest kontynuacj prezentacji aplikacji T C P/IP z rozdziaw 25-30 tomu 1. W cigu dwch lat od opublikowania tomu 1 popular no HTTP wraz z eksplozj" Internetu wzrosa niewyobraalnie. Liczba kompu terw uywajcych NNTP w cigu ostatnich 10 lat rosa o okoo 75% rocznie. Typowy sposb uycia TCP przez HTTP to krtkie poczenia z niewielk iloci przesyanych danych, gdzie czas poczenia jest czsto okrelony przez czas na wizania i zamknicia poczenia. W zwizku z tym HTTP to doskonay przykad aplikaq'i, ktra powinna uywa T/TC P. Fakt, e HTTP jest uywany tak inten sywnie przez tysice rozmaitych klientw, stwarza te wyjtkow sposobno przeanalizowania pakietw docierajcych do serwera i wysyanych przez niego (rozdzia 14) oraz do przyjrzenia si wielu waciwociom T C P /IP omawianym w tomach 1 i 2. Pocztkowo przewidywano, e protokoy domeny unixowej omawiane w czci III zostan przedstawione w tomie 2. Zamierzenie to zostao jednak zweryfikowa ne, gdy objto tomu 2 przekroczya 1200 stron. Cho moe wydawa si dziwne, e w serii zatytuowanej Biblia T C P /IP " omawiane s protokoy inne ni T C P/IP, trzeba pamita, e protokoy domeny unixowej zostay zaimplementowane w 4.2BSD niemal 15 lat temu, jednoczenie z pierwsz implementacj T C P/IP w systemie BSD. S;one dzi intensywnie uywane przez jdra systemw w ywo dzcych si z systemu Berkeley, ale ich uycie nie jest jawne i wikszo uytkow nikw nie zdaje sobie sprawy z ich istnienia. Stanowi one podstaw strumieni unixowych i s wykorzystywane przez X Windows System, jeli klient i serwer pracuj w tym samym komputerze (tzn. w typowej stacji roboczej). Gniazd dome ny unixowej uywa si rwnie do przekazywania deskryptorw pomidzy pro cesami, co jest wan technik komunikacji miedzyprocesowej. Poniewa interfej sy API (application program interface - interfejs programw aplikacyjnych) gniazd uywane w protokoach domeny unixowej s niemal identyczne z interfejsami API gniazd uywanych w TC P/IP, protokoy domeny unixowej pozwalaj zwi kszy szybko lokalnych aplikacji przy bardzo niewielkich zmianach kodu. Zwracam y uwag, e kada z trzech czci moe by czytana niezalenie.
Czytelnicy
Podobnie jak poprzednie dwa tomy serii, ksika jest przeznaczona dla kadego, kto pragnie zrozumie dziaanie protokow TC P/IP: programistw piszcych aplikacje sieciowe, administratorw systemw i sieci komputerowych uywaj cych T C P /IP oraz uytkownikw, ktrzy regularnie korzystaj z aplikacji TC P/IP. W czci I i II zakadamy, e czytelnik rozumie podstawy funkcjonowania proto kow TCP/IP.'Czytelnicy nie znajcy T C P/IP powinni zajrze do tomu pierwsze go [Stevens 1994] w poszukiwaniu szczegowego opisu podstaw TC P/IP. Pierw szy dzia czci I (rozdziay 1-4 - idee lece u podstaw T /T C P oraz przykady),
Przedmowa
Biblia T C P /IP -to m III
XV
moe by czytany niezalenie od tomu 2, ale w nastpnych rozdziaach tej czci (rozdziay 5-12 - implementacja T/T C P) zakadamy znajomo kodu sieciowego systemu 4 .4BSD-Lite przedstawionego w tomie 2. Dla bardziej wnikliwych czytelnikw w tekcie ksiki podajemy wiele odnoni kw, zarwno do zagadnie omawianych w innych miejscach ksiki, jak i do odpowiednich rozdziaw tomw 1 i 2. Zaczamy szczegowy spis alfabetyczny terminw uywanych w ksice, a lista skrtw wraz z odpowiednimi terminami podanymi w penym brzmieniu znajduje si na wewntrznej stronie okadki na pocztku ksiki. Natomiast na wewntrznej stronie okadki na kocu ksiki znajduje si spis alfabetyczny wszystkich struktur, funkcji i makroinstrukcji przedstawionych w ksice, wraz z numerem strony, na ktrej zaczyna si odpo wiedni opis. Spis ten zawiera rwnie odnoniki do definicji w tomie 2, w przy padku gdy odnonik dotyczy obiektu tam wprowadzonego.
Prawa autorskie kodu rdowego

K o d rdowy zawarty w ksice, p o c h o d z c y z s y s t e m u 4 . 4 B S D - L i t e , z a w i e r a n a s t p u j c e zastrzeenie d o t y c z c e p r a w autorskich:
/*
* C o p y r i g h t (c) 1982, 1986, 1988, 1990, 1993, 1994 * The Rege n t s of the U n i v e r s i t y of Calif o r n i a .
*
* * * * * * * * * * * * * * * * * * * * * * * * * *
Ali
rights reserved.
R e d i s t r i b u t i o n and use in source and binary forms, w i t h or w i t h o u t m o d i f i c a t i o n , are p e r m i t t e d p r o v i d e d that the f o l l o w i n g co n d i t i o n s are met: 1. R e d i s t r i b u t i o n s of s o u r c e code must retain the a b ove c o p y r i g h t notice, this list of c o n d i t i o n s and the f o l l o w i n g discl a i m e r . 2. R e d i s t r i b u t i o n s in binary form must r e p r o d u c e the a b ove c o p y r i g h t notice, this list of c o n d i t i o n s and the fol l o w i n g d i s c l a i m e r in the documentati.on an d / o r o t h e r m a t e r i a l s p r o v i d e d w i t h the di stri buti o n . 3. Ali a d v e r t i s i n g m a t e r i a l s m e n t i o n i n g features or use of this s o f t w a r e m u s t d i s p l a y the f o l l o w i n g a c k n o w l e d g e m e n t : T h i s p r o d u ct includes s o f t w a r e d e v e l o p e d by the U n i v e r s i t y of C a l i f o r n i a , B e r k e l e y and its c o n t r i b u t o r s . 4. N e i t h e r the name of the U n i v e r s i t y nor the names of its c o n t r i b u t o r s m a y be used to e n d o r s e or p r o m o t e prod u c t s d e r i v e d from this s o f t w a r e w i t h o u t s p e c i f i c pri o r w r i t t e n p e rmission. THIS S O F T W A R E 1S P R 0 V I D E D BY THE R E G ENTS AND C O N T R I B U T O R S " A S I S " AN D A NY E X P R E S S OR IMPLIED W A R R A N T I E S , INCLUDING, BUT NOT L I M I T E D TO, THE I M P L I E D W A R R A N T I E S OF M E R C H A N T A B I L I T Y A N D F I T NESS FOR A P A R T I C U L A R P U R P O S E ARE D I S C L A I M E D . IN NO EVENT SHA L L THE R E G E N T S O R C O N T R I B U T O R S BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, E X E M P L A R Y , OR C 0 N S E 0 U E N T I A L D A M A G E S ( I N C LUDING, BUT NOT LIMITED TO, P R O C U R E M E N T OF S U B S T I T U T E G 0 0DS OR SERV I C E S ; LOSS OF USE, DATA. OR PROFITS; OR B U S I N E S S I N T E R R U P T I O N ) H 0 W E V E R C A U S E D AN D ON ANY THEORY OF LIABILITY. W H E T H E R IN CON T R A C T , ST R I C T LIABIL I T Y , O R TORT ( I N C L U D I N G N E G L I G E N C E O R O T H E R W I S E ) A R I S I N G IN ANY WAY O UT OF T HE USE OF THIS SOFTWARE, EVEN IF A D V I S E D OF THE P O S S I B I L I T Y OF SUCH DAMAGE.
XVI
Biblia TCP/IP -tom III
Przedmowa
K o d r d o w y tablicy r u t o w a n i a w
r ozdziale 6 z a w i e r a n a s t p u j c e zastrzeenie: I n s titute of T e c h n o l o g y
/*
* C o p y r i g h t 1994,
k
* * * * * * * * * * *
1995 M a s s a c h u s e t t s
P e r m i s s i o n to use, copy, modify, and d i s t r i b u t e this s o f t w a r e and its d o c u m e n t a t i o n for any p u r p o s e and w i t h o u t fee is hereby g r a nted, p r o v i d e d that both the a b ove c o p y r i g h t n o t i c e and this p e r m i s s i o n n o t i c e a p p e a r in all copies, that both the above c o p y r i g h t n o t i c e and this p e r m i s s i o n n o t i c e ap p e a r in all s u p p o r t i n g d o c u m e n t a t i o n , and that the name of M.I.T. not be used in a d v e r t i s i n g or p u b l i c i t y p e r t a i n i n g to d i s t r i b u t i o n of the s o f t w a r e w i t h o u t specific, w r i t t e n prior p e r mission. M.I.T. makes no r e p r e s e n t a t i o n s a b out the s u i t a b i l i t y of this s o f t w a r e for any p u r pose. It is p r o v i d e d "as is" w i t h o u t e x p ress or i m p lied warranty. T H I S S O F T W A R E IS P R 0 V I D E D BY M.I.T. " A S I S " . M.I.T. D I S C L A I M S A L L E X P R E S S OR IMPLIED W A R R A N T I E S WITH RE G A R D TO THIS SOFTWARE, INCLUDING. BUT NOT L I M I T E D TO, THE IMPLIED W A R R A N T I E S OF M E R C H A N T A B I L I T Y AN D F I T N E S S FOR A P A R T I C U L A R PURPOSE. IN NO EVENT S H A L L M.I.T. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECI A L , E X E M P L ARY, OR C O N S E Q U E N T I A L D A M A G E S (INCLUDING, BUT NOT L I M I T E D TO, P R O C U R E M E N T OF S U B S T I T U T E G O O D S OR SERVICES; LOSS OF USE, DATA, O R PROFITS; OR B U S I N E S S INTERR U P T I O N ) H 0 W E V E R C A U S E D AND ON ANY T H E O R Y OF L I A B I L I T Y , W H E T H E R IN CONTRACT, S T R I C T L I A B I L I T Y . OR T O R T ( I N C L U D I N G N E G L I G E N C E OR O T H E R W I S E ) A R I S I N G IN ANY WAY OUT OF THE USE O F THIS SOFTWARE, EVEN IF A D V I S E D OF THE P O S S I B I L I T Y OF SUCH DAMAGE.
* * * * * * * * * * * *
*/
Konwencje typograficzne
We fragmentach, w ktrych przedstawiamy tekst interakcyjnie wprowadzany z klawiatury i wywietlany na ekranie, tekst z klawiatury jest przedstawiony pogru bionym drukiem, a tekst wywietlany przez komputer tak czci onk. Komentarze pisane s kursyw.
sun X t e l n e t w w w . a w . c o m 80 sunTrying 192.207.117.2... C o n n e c t e d to aw.com.
pocz si z serwerem HTTP wydruk z Telnetu
Znak zgoszenia powoki systemu zawiera zawsze nazw komputera (na przykad sun). eby unikn zbyt czstych zmian czcionki, przyjlimy zasad, e nazwy programw pojawiajce si w tekcie rozpoczynaj si du liter (np. Telnet i Tcpdump).
Dodatkowe informacje, dotyczce kontekstu historycznego czy szczegw implementa cji, przedstawiamy mniejszym drukiem, w sposb taki jak tutaj.
Podzikowania
Przede wszystkim dzikuj mojej rodzinie, Sally, Bilemu, Elen i Davidowi, ktrzy znieli jeszcze jedn ksik, przy tak czstych moich podrach w cigu ostatnie go roku. Tym razem jednak jest to naprawd maa" ksika. Dzikuj recenzentom, ktrzy czytali maszynopis dostosowujc si do napitego harmonogramu i dostarczyli wielu istotnych uwag, a s to: Sami Boulos, Alan Cox, Tony DeSimone, Pete Haverlock, Chris Heigham, Mukesh Kacker, Brian Kemig-
Przedmowa
XVII
han, Art Mellor, Jeff Mogul, Mariann Mueller, Andras Olah, Craig Partridge, Vem Paxson, Keith Sklower, an Lance Taylor i Gary Wright. Szczeglnie dzikuj redaktorowi Brianowi Kernighanowi za jego szybkie, dokadne i pomocne uwagi w czasie pisania ksiki, za cige wsparcie oraz wyrazy zachty. Specjalne podzikowania nale si Vemowi Paxsonowi i Andrasowi Olahowi za nieprawdopodobnie dokadne przeczytanie kompletnego manuskryptu, za znale zienie licznych bdw i wiele cennych technicznych sugestii. Vernowi Paxsonowi dzikuj rwnie za udostpnienie jego programw do analizy wydrukw z pro gramu Tcpdump, a Andrasowi Olahowi za pomoc z T /T C P w cigu ostatniego roku. Dzikuj te Bobowi Bardenowi, ktry zaprojektowa T /T C P i dostarczy kod rdowy implementacji, na ktrej oparta jest I cz ksiki. Pomoc innych osb bya rwnie istotna - na wiele sposobw. Gary Wright i Jim Hogue udostpnili system, ktry pozwoli zebra dane do rozdziau 14. Doug Schmidt dostarczy kopie powszechnie rozpowszechnianego programu TTCP, ktry uywa gniazd domeny unixowej i ktry posuy do zmierzenia zalenoci czasowych w rozdziale 16. Craig Partridge dostarczy kopie kodu rdowego RDP. Mike Karels odpowiedzia na liczne pytania. Dzikuj jeszcze raz National Optical Astronomy Observatories ( NOAO), Sidney'owi Wolffowi, Richardowi Wolffowi i Steve'owi Grandiemu za udostpnienie sieci i komputerw. Dzikuj take wszystkim pracownikom Addison-Wesley, ktrzy byli pomocni w cigu ostatnich kilku lat, szczeglnie dzikuj Johnowi Waitowi, redaktorowi moich ksiek. Kompletny, gotowy do powielenia egzemplarz ksiki zosta jak zwykle przygo towany przez autora - zagorzaego zwolennika systemu Troff - przy uyciu pakietu Groff napisanego przez Jamesa Clarka. Zachcam Czytelnikw do podzie lenia si ze mn, za porednictwem poczty elektronicznej, wszelkimi uwagami, sugestiami i informacjami o znalezionych bdach. Tucsoti, Arizona Listopad 1995 W. Richard Stevens rstevens@noao.edu http://www.noao.edu/-rstevens
Wprowadzenie do T/TCP
1.1 Wstp
W niniejszym rozdziale wprowadzamy pojcie transakcji klient-serwer. Rozpo czynamy od omwienia najprostszej z moliwych aplikacji - UDP. Nastpnie stworzymy programy penice rol serwera i klienta uywajce protokou TCP i przeanalizujemy pakiety T C P/IP wymieniane midzy dwoma hostami. W kolej nym kroku przedstawimy analogiczne programy uywajce protokou T /T C P . Zwrcimy uwag na zmniejszenie liczby pakietw i pokaemy, e zmiany w ko dzie rdowym po obu stronach poczenia umoliwiajce wykorzystanie zalet T /T C P s niewielkie. Nastpnie opiszemy przykadow sie, ktrej bdziemy uywa do wykonania omawianych przykadw. Sporzdzimy proste porwnanie czasw potrzebnych do wykonania aplikacji typu klient-serwer uywajcych UDP, TCP i T/T C P . Prze analizujemy kilka typowych internetowych aplikacji wykorzystujcych TCP i za stanowimy si, co ulegoby zmianie, jeli aplikaqe po obu stronach poczenia potrafiyby wykorzysta T /T C P. Na koniec, krtko przedstawimy histori proto kow transakcyjnych w ramach zestawu protokow Internetu i opiszemy istnie jce implementacje T/T C P. W niniejszym tekcie i oglnie w literaturze powiconej T /T C P okrelenie tran sakcja oznacza danie wysane przez klienta do serwera, wraz z nastpujc po daniu odpowiedzi serwera. Typowym internetowym przykadem transakcji jest danie klienta skierowane do systemu nazw domen (DNS - Domain Name System), w ktrym klient pyta o adres IP odpowiadajcy nazwie domeny, oraz nastpujca po pytaniu odpowied serwera. Podkrelamy, e terminu transakcja nie uywamy w znaczeniu transakcji pojawiajcej si w kontekcie baz danych: blokowanie, potwierdzenie dwufazowe, odtworzenie, itd.
1.2
Klient-serwer UDP
Rozpoczynamy od pokazania prostego przykadu systemu klient-serwer. Kod rdowy klienta prezentujemy na rysunku 1.1. Klient przesya danie do serwe ra, serwer przetwarza to danie i przesya odpowied.
Rozdzia 1
------------------------------------------------------------------------------------------------1 tfinclude " c l iserv.h" 2 i nt 3 m a i n t i n t argc, char *argv[]) 4 { /* prosty klient UDP */ 5 s t r u c t s o c k a d d r _ i n serv: 6 char request[REQUEST], reply[REPLY]; 7 i nt sockfd, n; 8 9 10 11 12 13 14 15 16 if (argc != 2) e r r _ q u i t ( " u s a g e : udpcli <IP a d d ress of server>"); S0CK_ D G R A M , 0)) < 0)
udpcli.c
if ( ( s o c k f d = s o c k e t ( P F _ I N E T , e r r _ s y s ("socket error");
m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v .s i n _ f a m i l y = A F _ I N E T : s e r v . s i n _ a d d r . s _ a d d r = i n e t _ a d d r ( a r g v [ l ] ); s e r v . s i n _ p o r t = h t o n s ( U D P _ S E R V _ P O R T ); /* t w o r z y m y d a n i e request[] ... */ 0,
17 if ( s e n d t o t s o c k f d , request, REOUEST. 18 (SA) & s e r v . s i z e o f ( s e r v ) ) != REOUEST) 19 e r r _ s y s ("sendto error"); 20 21 22 23 24 25 1
if ((n = r e c v f r o m ( s o c k f d , reply. REPLY, (SA) NULL, (int *) N U L L )) < 0) e r r _ s y s ("r e c v f r o m error"); /* p r z e t w a r z a m y exi t (0); "n" baj t w odpowiedzi reply[]
0,
... */
------------------------------------- ------------ ----------- ----------------------------- udpcli.c Rysunek 1.1 Prosty klient UDP
Sposb przedstawienia kodu rdowego na rysunku 1.1 jest typowy dla caej ksiki. Kada niepusta linia jest oznaczona numerem. Odpowiedni fragment tekstu opisujcy ukazany na rysunku kod rdowy rozpoczyna si od liczb oznaczajcych pierwsz i ostatni lini omawianego kodu rdowego, tak jak to wida poniej. Czasami taki akapit poprzedzony jest krtkim nagwkiem zawierajcym okrelenie opisywanego fragmentu kodu. Poziome linie na kocu i na pocztku fragmentu program u zakoczone s nazw pliku zawierajcego przedstawiany kod rdowy. N azwy plikw odnosz si do plikw dystrybucji 4.4BSD-Lite, ktr om wimy w podrozdziale 1.9.
Omawiamy tu odpowiednie waciwoci programu, ale nie opisujemy szczego wo funkcji gniazd, zakadajc, e s one zasadniczo znane czytelnikowi. Wicej informacji na temat tych funkcji mona znale w rozdziale 6 ksiki [Stevens 1990]. Nagwek cl i serv .h pokazujemy na rysunku 1.2.
Utworzenie gniazda UDP

10-11 Funkcja socket tworzy gniazdo UDP, zwracajc nieujemny deskryptordo procesu, z ktrego zostaa wywoana. Funkcja obsugi bdu e r r _ s y s przedsta wiona jest w dodatku B.2 ksiki [Stevens 1992]. Funkcja ta akceptuje dowoln liczb argumentw, formatuje argumenty uywajc vspri ntf, drukuje systemo
Sekcja 1.2
Klient-serwer UDP
w informacj o bdzie odpowiadajc wartoci e r rn o z odwoania systemowego i koczy proces.

Wpisanie adresu serwera
12-15 Struktura adresowa gniazda internetowego jest najpierw zerowana przy pomocy memset, a nastpnie wpisane zostaj do niej adres IP i numer portu serwera. Dla uproszczenia wymagamy, by uytkownik poda adres IP w linii komendy uruchamiajcej program (a rgv [ 1 ]). Numer portu serwera jest zdefinio wany (#def i ne ) w nagwku cl i serv .h i doczany na pocztku wszystkich programw w tym rozdziale. W ten sposb unikamy komplikowania kodu odwo aniami do g e t h o s t b y n a m e i getservbyname.
Utworzenie i wysanie dania do serwera
16-19 Klient formuuje danie (ktre przedstawiamy jedynie jako komentarz) i wysyaje do serwera uywajc sendto. W ten sposb pojedynczy datagram UDP zostaje wysany do serwera. Ponownie dla uproszczenia zakadamy, e danie i odpowied ( R E O U E S T i RE PLY) maj ustalon dugo. Rzeczywista aplikacja zare zerwowaaby miejsce na danie i odpowied o maksymalnym rozmiarze, ale faktyczna dugo dania i odpowiedzi byaby zmienna, najczciej mniejsza.
Odczytanie i przetworzenie odpowiedzi serwera
20-23 Odwoanie do r e c v f r o m blokuje proces (tzn. usypia go) do czasu, gdy datagram dociera do klienta. Gdy to nastpi, klient przetwarza odpowied (co pokazujemy jako komentarz) i koczy proces.
Przedstawiony program zawiesi si trwale, jeli danie lub odpowied zaginie, ponie wa brak jest limitu czasu dla odwoania do r e c v f r o m . Taki brak odpornoci na bdy wystpujce w rzeczywistych warunkach jest jednym z zasadniczych mankamentw systemw klient-serwer opartych na UDP. Omawiam y to bardziej szczegowo pod koniec tego podrozdziau. W nagwku cl i serv . h definiujemy symbole (#define) SA jako s t r u c t s o c k a d d r * , czyli jako wskanik do uniwersalnej struktury adresowej gniazda. Za kadym razem, gdy jedna z funkcji gniazda da wskanika do struktury adresowej gniazda, wskanik ten musi by zrzutow any na wskanik do uniwersalnej struktury adresowej gniazda. Dzieje si tak dlatego, gdy funkcje gniazd powstay wczeniej ni standard ANSI C i typ wskanika v o i d * nie by dostpny we wczesnych latach osiemdziesitych, kiedy to funkq'e te zostay stworzone. Rzecz w tym, e wyraenie s t r u c t s o c k a d d r * " ma 17 znakw i linia kodu zawierajca to wyraenie czsto wychodzi poza praw krawd ekranu (lub strony - w przypadku ksiki), tak wic skrcilimy to wyraenie do S A . Ten skrt jest zapoyczony z kodu rodowego jdra BSD.
N a rysunku 1.2 przedstawiamy nagwek cl i serv .h doczany do wszystkich programw w niniejszym rozdziale.
Rozdzia 1
clisero.h
1 /* I n s t r u k c j e i n c l u d e i d e f i n e w s p l n e dla s e r w e r w i k l i e n t w 2 * UDP, T C P i T / T C P */ 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 //include # i n c 1 ude /incl ude /incl ude //include //include //include //include < s y s / t y p e s .h> <sys/socket,h> <netinet/in.h> <arpa/inet.h> <stdio.h> <stdli b .h > <string.h> <unistd.h> /* maks. r o z miar dania, b a jty */ /* maks. r o z miar o d p o w i e d z i , b a jty */ 7777 8688 9999 /* /* /* d o b r z e - z n a n y port s e r wera UDP */ d o b r z e - z n a n y port s e r wera TCP */ d o b r z e - z n a n y port s e r wera T / T C P */
//define R E O U E S T 400 y/de fi ne REPLY 400 //define U D P _ S E R V _ P O R T //define T C P _ S E R V _ P O R T //define T T C P _ S E R V _ P O R T
/* S k r t u y w a n y przy r z u t o w a n i u w s k a n i k w */ //define S A s t r u c t s o c k a d d r * void void int e r r _ q u i t ( c o n s t char *,...); e r r _ s y s ( c o n s t char r e a d _ s t r e a m ( i n t , char *, int);
------------------------------------------------------------------------------------------------lisew.h Rysunek 1.2 Nagwek cl i s e r v . h doczany do zoszystkichprogramw w tym rozdziale Na rysunku 1.3 przedstawiamy kod rdowy serwera UDP odpowiadajcy wczeniej przedstawionemu klientowi. ------------------------------------------------------------------------------ ------------------1 //include " c l iserv.h" 2 1 nt 3 mai n ( ) 4 ( /* prosty s e r w e r UDP */ 5 s t r u c t s o c k a d d r _ i n serv, cli; 6 char r e q u e s t [ R E Q U E S T ] , rep 1y [REP L Y ]; 7 int sockfd. n, cl i 1 e n ; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ] if ( Csockfd = s o c k e t ( P F _ I N E T , S0CK_ D G R A M , 0)) < 0) e r r _ s y s ( " s o c k e t error"); m e m s e t ( & s e r v . 0, s i z e o f ( s e r v ) ): s e r v . s i n _ f a m i l y = AF_INET; s e r v . s i n _ a d d r . s _ a d d r = h t o n l ( 1 N A D D R _ A N Y ); s e r v . s i n _ p o r t = h t o n s (U D P _ S E R V _ P O R T ); if ( b i n d t s o c k f d , (SA) &serv, e r r _ s y s ("bind error"); s i z e o f ( s e r v ) ) < 0)
udpserv.c
for ( ; ;) { cl i 1 en = si zeof(cl i ); if ((n = r e c v f r o m ( s o c k f d , request, REOUEST, (SA) i c l i , &cli l e n ) ) < 0) err_sys( r e c v f r o m error"); /* p r z e t w a r z a m y " n b a j t w dania i t w o r z y m y o d p o w i e d . . . if ( s e n d t o t s o c k f d , reply, REPLY, 0, (SA) & c l i , si z e o f (cl i )) != REPLY) e r r _ s y s ( " s e n d t b error"); ]
0,
*/
udpsero.c Rysunek 1 3 Serwer UDP odpowiadajcy klientowi UDP z rysunku 1.1
Sekcja 1.2
Klient-serwer UDP
Utworzenie gniazda UDP i powizanie z lokalnym adresem
8-15 Odwoanie do funkcji sock et tworzy gniazdo UDP i lokalny adres serwera jest wpisywany do internetowej struktury adresowej. Lokalny adres otrzymuje warto wieloznaczn (I N ADDR_ANY ), co oznacza, e serwer zaakceptuje datagram otrzymany z dowolnego lokalnego interfejsu (w przypadku, gdy host serwera posiada wicej ni jeden interfejs sieciowy). Numer portu jest rwny dobrze-znanemu (well-known) numerowi portu serwera (UDP_SERV_PORT ), k t ry -ja k wspo mnielimy wczeniej - zosta zdefiniowany w nagwku cl i serv . h. Lokalny adres IP i dobrze-znany port zostaj zwizane z gniazdem przez odwoanie do funkcji bind .
Przetwarzanie dania klienta
16-25
Serwer wchodzi w nieskoczon ptl, w ktrej czeka na danie klienta
(r ecvfro m ), przetwarza to danie (co pokazujemy jako komentarz) i wysya odpowied ( s e n d t o ).
Pokazalimy najprostsz form aplikacji typu klient-serwer uywajcej UDP. Po wszechnie spotykanym w rzeczywistoci przykadem jest system nazw domen Domain Name System (D N S). Klient DNS (resolver) jest zwykle czci klienta-aplikacji, ktra korzysta z DNS (na przykad Telnet, F T P , czy przegldarka WWW). Resolver wysya pojedynczy datagram do serwera DNS z daniem podania adresu IP odpowiadajcego nazwie domeny. W odpowiedzi serwer wysya zw y kle pojedynczy datagram. Jeli przeledzimy pakiety wymieniane pomidzy serwerem a klientem, otrzyma m y diagram czasowy przedstawiony na rysunku 1.4. Czas biegnie w kierunku od gry do dou strony. Najpierw uruchamiany jest serwer, przedstawiony w prawej czci rysunku, nieco pniej zaczyna dziaa klient. W prowadzam y rozrnienie pomidzy odwoaniem do funkcji wykonanym przez serwera lub przez klienta, a dziaaniem wykonanym przez odpowiednie jdro. Uywam y dwch strzaek narysowanych bezporednio jedna nad drug, tak jak to wida w dwch odwoaniach do funkcji s o c k e t , aby pokaza, e jdro wykonuje dan czynno i zwraca kontrol do wywoujcego procesu praktycz nie natychmiast. W przypadku wywoania sendto, mimo e powrt do wywou jcego procesu nastpuje natychmiast, kernel wysya datagram UDP. Dla uprosz czenia zakadamy, e rozmiar datagramw utworzonych przez danie klienta i odpowied serwera jest mniejszy ni MTU (maximum tmnsmission unit - najwi ksza jednostka transmisji) danej sieci, unikajc w ten sposb dzielenia datagramu IP na czci. Na tym samym rysunku pokazujemy rwnie, e dwa odwoania do r e c v f r o m wprowadzaj proces w stan upienia - a do czasu, gdy nadejdzie oczekiwany datagram. Odpowiednie procedury jdra oznaczamy jako sl eep i w a k e u p (upie nie i pobudka).
Rozdzia 1
Wreszcie pokazujemy rwnie zalenoci czasowe zwizane z transakcj. W lewej czci rysunku 1.4 pokazujemy czas transakcji mierzony przez klienta: czas upy wajcy od sformuowania dania do otrzymania odpowiedzi. Po prawej stronie rysunku zaznaczylimy wartoci odpowiadajce temu czasowi transakcji: RTT + SPT, gdzie RTT jest charakterystycznym dla danej sieci czasem przesania datagramu w obie strony (round trip time), a SPT jest czasem obsugi dania przez serwer (seruer processing time). Czas transakcji pomidzy klientem i serwerem w protokole UDP, RTT + SPT jest najmniejszym moliwym czasem transakcji.
Zaoylimy, e czas konieczny na przesanie datagram u od klienta do serwera wynosi RTT i e czas potrzebny na przesanie datagram u w przeciwnym kierunku jest rwnie Vi RTT. Przeprowadzona analiza ponad 600 m arszrut internetowych [Paxson 1995b] wykazaa, e 30% z tych tras charakteryzowao si znaczc asymetri, to znaczy pakiety podrujce w przeciwnych kierunkach przemieszczay si rnymi drogami.
Nasz system skadajcy si z klienta i serwera uywajcych UDP wydaje si mao skomplikowany (kady z programw skada si tylko z okoo 30 linii kodu), ale program y te nie s wystarczajco odporne na bdy, z ktrymi aplikacje mog zetkn si w rzeczywistych warunkach. Poniewa UDP jest zawodnym protoko em - datagramy mog by zgubione lub powielone, moe by zmieniona ich kolejno - aplikacja dziaajca w rzeczywistoci musi by w stanie obsuy
Sekcja 1.3
Klient-serwer TCP
wszystkie takie problematyczne sytuacje. Zwykle wprowadza si ograniczenie na czas oczekiwania przy odwoaniu klienta do recvfrom, tak by w przypadku zaginicia datagramu danie mogo by wysane ponownie. Jeli ograniczenie czasu m a by wprowadzone, klient musi zmierzy RTT i dynamicznie uaktual nia zmierzon warto, poniewa RTT w intemecie moe mie bardzo rne wartoci i moe ulega duym zmianom. Gdy zaginie odpowied, a nie danie, serwer obsuy danie po raz drugi, co w przypadku niektrych usug moe by powodem problemw. Serwer, by zapobiec takiej sytuacji, moe zachowa odpowied, zamiast przetwarza danie po raz drugi. Dodajmy, e klient zwykle docza identyfikator do kadego dania, a serwer powiela ten identyfikator, umoliwiajc klientowi skojarzenie odpowiedzi z daniem. W rozdziale 8.4 ksiki [Stevens 1990] szczegowo przedstawiono kod rdowy konieczny do obsuenia niektrych z wymienionych problemw dla ukadu klient-serwer z protokoem UDP - wymaga to jednak dodania okoo 500 linii kodu do kadego z programw. O ile niezawodno wielu aplikacji UDP jest zwikszona przez dodanie tych dodatkowych elementw (ograniczenie czasu oczekiwania, pomiary RTT, iden tyfikatory da, itd.), wszystkie te zabezpieczenia s od nowa wymylane, za kadym razem, gdy powstaje nowa aplikacja. W pracy [Partridge 1990b] autor zauwaa: by stworzy niezawodn aplikacj UDP, konieczna jest informacja o stanie poczenia (numer porzdkowy, liczniki retransmisji, oszacowanie czasu przesania w obie strony). W zasadzie potrzebna jest niemal caa informacja za warta w bloku poczenia TCP. Pisanie 'niezawodnych aplikacji UDP' jest wic w istocie rwnie trudne jak pisanie aplikacji TCP." Niektre aplikacje nie posiadaj wszystkich wymaganych zabezpiecze: na przy kad uwzgldniaj ograniczenie czasu oczekiwania na datagram, ale nie mierz lub nie uaktualniaj dynamicznie RTT. Moe to by przyczyn problemw, gdy aplikacja zostaje przeniesiona z jednego rodowiska (na przykad LAN) do innego (na przykad WAN). Lepszym rozwizaniem jest uycie TCP zamiast UDP i wyko rzystanie caej niezawodnoci charakterystycznej dla TCP. To rozwizanie zwi ksza jednak czas transakcji z wartoci odpowiadajcej RTT + SPT do 2 x RTT + SPT, co bdzie pokazane w nastpnym podrozdziale, oraz znacznie zwiksza liczb pakietw wymienianych midzy obydwoma systemami. rodkiem zarad czym dla tych nowych problemw jest uycie T /T C P zamiast TCP. Zajmiemy si tym zagadnieniem w rozdziale 1.4.
1.3
Klient-serwer TCP
W naszym nastpnym przykadzie aplikacji transakcyjnej typu klient-serwer w y korzystany jest protok TCP. Kod rdowy programu-klienta przedstawiony zosta na rysunku 1.5.
Wprowadzenie do TfTCP
Rozdzia 1
------------------------------------------------------------------------------------------------1 #include "cliserv.h" 2 i nt 3 m a i n ( i n t argc, char *argv[]) 4 I /* pr o s t y kl i e n t TCP */ 5 s t r u c t s o c k a d d r _ i n serv; 6 char r e q u e s t [ R E Q U E S T ] , rep 1y [R E P L Y ]; 7 int sockfd, n; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 1 if (argc != 2) err_quit("usage: tcpcli <IP a d d ress of server>"); S0CK _ S T R E A M , 0)) < 0)
tcpcli.c
if ((soc k f d = s o c k e t ( P F _ I N E T , e r r _ s y s (" s ocket error");
m e m s e t ( & s e r v , 0. s i z e o f ( s e r v ) ): serv.sin_family = AF_I NET: serv.sin_addr.s_addr = inet_addr(argv[l]); s e r v .s i n _ p o r t = h t o n s ( T C P _ S E R V _ P 0 R T ) ; if ( c o n n e c t ( s o c k f d . (SA) &serv, e r r _ s y s ( " c o n n e c t error"); /* t w o r z y m y d a n i e request[] s i z e o f (s e r v )) < 0)
...
*1
!= RE0UEST)
if ( w r i t e ( sockfd, request, RE0UEST) err_ s y s ( write error ); if ( s h u t d o w n ( s o c k f d . 1) < 0) e r r _ s y s ( " s h utdown error"); if ( Cn = r e a d _ s t r e a m ( s o c k f d , reply, e r r _ s y s ( " r e a d error");
R E P L Y )) r e p l y []
< 0)
/* p r z e t w a r z a m y "n" b a j t w odpowiedzi e x i t(0);
...
*1
------------------------------------------------------------------------------------------------Rysunek 1.5 Klient transakcji TCP

Utworzenie gniazda TCP i poczenie z serwerem 10-17
tcpcli.c
Gniazdo TCP jest tworzone przez wywoanie funkcji s oc ke t, a nastpnie do internetowej struktury adresowej zostaje wpisany adres IP i numer portu serwera. Wywoanie funkcji connect powoduje potrjne uzgodnienie TCP, ustanawiajc poczenie midzy klientem i serwerem. W podrozdziale 18.5 tomu 1 przedstawia my dodatkowe szczegy procedury wymiany pakietw, gdy poczenia TCP s nawizywane i zakaczane.
Wysanie dania i poowiczne zamknicie poczenia
19-22
danie jest wysyane przez klienta do serwera przy pomocy funkcji w r i te. Klient wywouje wtedy funkcj shu t d o w n z drugim argumentem rwnym 1, za mykajc tym samym poow poczenia - przesyanie danych w kierunku od klienta do serwera. W ten sposb serwer otrzymuje informaq, e klient zakoczy ju przesyanie danych: przesany zostaje od klienta do serwera znak koca pliku. Segment TCP zawierajcy flag FIN jest wysany do serwera. Klient moe w dal szym cigu otrzymywa dane - zakoczone jest przesyanie danych w jednym
Sekcja 1.3
Klient-serwer TCP
kierunku. Taki stan nazywamy poowicznym zamkniciem TCP. (Dodatkowe szczegy zostay przedstawione w rozdziale 18.5 tomu 1.)
Odczytanie odpowiedzi
23-24 Odpowied jest czytana przy pomocy naszej funkcji read_stream, przed stawionej na rysunku 1.6. Poniewa TCP jest protokoem przesyajcym strumie bajtw, bez jakiejkolwiek struktury rekordw, odpowied serwera moe by prze sana w jednym lub kilku segmentach TCP. Segmenty te s odczytywane przez klienta przy pomocy jednego lub kilku odwoa do funkcji read. Wiemy, e serwer po wysaniu kompletnej odpowiedzi zamyka poczenie przez wysanie segmentu FIN do klienta. Segment ten, przy wczytaniu funkcj read przez proces klienta, powoduje otrzymanie informacji o kocu pliku (warto zwracana przez read jest rwna 0). Funkcja read_stream jest wic wywoywana tyle razy, ile jest to konieczne, a do momentu gdy bufor wejciowy jest peny, lub znak koca pliku zostanie zwrcony przez read. Warto zwracana przez t funkcj rwna jest liczbie wczytanych bajtw. ------------------------------------------------------------------------------------------------1 tfinclude " c l iserv.h" int m a x bytes) 2 i nt 3 r e a d _ s t r e a m ( i n t fd. char *ptr, 4 ( 5 int nleft, nread; 6 7 8 9 10 11
readstream.c
nle f t = m a x b y t e s ; w h i l e ( nleft > 0) ( if ((nread = read(fd, ptr, nleft)) < 0) r e turn (nread); /* bd, w a r t o z w r a c a n a < 0 */ e l s e if (nread == 0) break; /* EOF, z w r a c a m y liczb p r z e c z y t a n y c h b a j t w n l e f t -= nread; ptr + = nread; ) return (maxbytes - nleft); /* return >= 0 */
*/
12 13 14 15 16 )
------------------------------------------------------------------------------------------------- readstream.c Rysunek 1.6 Funkcja read_stream

Istniej rwnie inne sposoby zaznaczenia rekordw, gdy uywany jest protok strumie niowy, taki jak na przykad TCP. Wiele aplikacji internetowych (FTP, SMTP, HTTP, NNTP) zakacza kady rekord znakami karetki i nowej linii. Inne (DNS, RFC) poprze dzaj kady rekord informacj o dugoci rekordu, zapisan w polu o ustalonej dugoci. W naszym przykadzie uywam y flagi koca pliku protokou TCP (FIN), poniewa wysyam y tylko jedno danie od klienta do serwera i jedn odpowied na to danie. Protok FTP - by poinformowa m aszyn po drugiej stronie poczenia o kocu pliku rwnie uyw a tej techniki w swoich poczeniach transferu danych.
10
Rozdzia 1
Na rysunku 1.7 przedstawiony jest serwer uywajcy protokou TCP. ------------------------------------------------------------------------------------------------1 #include " c liserv.h" 2 i nt 3 main() 4 ( /* pr o s t y se r w e r TCP */ 5 s t r u c t s o c k a d d r _ i n serv, cli; 6 char r e q u e s t [ R E Q U E S T ] , r e p l y [ R E P L Y ]; 7 int listenfd, sockfd, n. clilen; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 I ) if ( ( l i s t e n f d = s o c k e t ( P F _ I N E T , e r r _ s y s ( "socket error"); S O C K _ S T R E A M , 0)) < 0)
tcpseru.c
m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v .si n_fami ly = A F _ I N E T ; s e r v .s i n _ a d d r .s_ a d d r = h t o n 1 ( I N A D D R _ A N Y ); serv.sin_port = htons(TCP_SERV_PORT): if ( b i n d d i s t e n f d , (SA) &serv, e r r _ s y s ( " b i n d error"); si zeof ( s e r v ) ) < 0)
if (1 i stent 1 i stenfd , S0MAXC 0 N N ) < 0) e r r _ s y s ( " l i s t e n error"); for (;;) ( cl 1 len = si zeof(cl i ); if ((sockfd = a c c e p t t 1 i s t e n f d , (SA) &cli, e r r _ s y s ("accept error"); if ((n = r e a d _ s t r e a m ( s o c k f d , request, e r r _ s y s ("read error");
&cli 1 e n ))
<
0)
R E O UEST)) < 0) */
/* p r z e t w a r z a m y "n" b a j t w dania i t w o r z y m y o d p o w i e d . . . if (wri te(sockfd, reply, REPLY) e r r _ s y s ("write error"); close(sockfd); != REPLY)
tcpserv.c Rysunek 1.7 Serwer transakcji TCP

Utworzenie gniazda odbiorczego TCP
8 -1 7
Gniazdo TCP jest utworzone i dobrze-znany port serwera zostaje przypisa ny do tego gniazda. Tak jak w przypadku TCP serwer interpretuje warto wielo znaczn jako wasny lokalny adres. Wywoanie funkcji 1 i sten wprowadza gniaz do w tryb odbioru, tworzc gniazdo odbiorcze, w ktrym akceptowane bd przychodzce poczenia. Drugi argument funkcji 1 i sten, S0MAXC0NN, przekazuje do jdra maksymaln dopuszczaln liczb pocze oczekujcych w kolejce do danego gniazda.
Param etr S0MAXC0NN jest zdefiniowany w nagwku < s y s / s o c k e t . h>. Tradycyjna w ar to tego param etru wynosi 5, cho niektre nowe systemy uywaj wartoci 10. Naley jednak pamita, e silnie aktywne serwery (np. systemy udostpniajce strony W W W World Wide Web, wiatowa Pajczyna) musz czsto stosowa wysze wartoci, na przy kad 256 lub 1024. (Omawiamy to zagadnienie w podrozdziale 14.5.)
Sekcja 1.3
Klient-serwer TCP
11
Akceptacja poczenia i przetworzenie dania

1 8 -2 8
Serwer zatrzymuje si w funkcji accept a do czasu, gdy poczenie zosta nie ustanowione w wyniku wywoania co n n e c t przez klienta, so ck fd - nowy deskryptor gniazda zwrcony przez a c cep t dotyczy poczenia z klientem. da nie klienta zostaje odczytane przez r e a d _ s t r e a m (rysunek 1.6) i nastpnie przy pomocy funkcji wr i te wysana jest odpowied.
Przedstawiony serwer jest serwerem iteracyjnym: przetw arza on cakowicie kade d a nie klienta, zanim kolejny raz wywoa a c c e p t , by przyj od niego nastpne poczenie. Serwer wspbieny obsuguje wielu klientw jednoczenie. W celu stworzenia serwera wspbienego na maszynie unixowej stosuje si technik polegajc na tym, e serwer tworzy proces potomny po wywoaniu a c c e p t i pozostawia temu procesowi obsuenie dania klienta, a proces macierzysty moe natychmiast przyj od klienta nastpne poczenie. Innym sposobem jest utworzenie przez serwera w celu obsuenia kadego dania nowego procesu wtkowego ( hread) zwanego czasem procesem bahym lub lekkim (lightweight proces). By unikn komplikowania przykadu odwoaniami do funk cji kontrolujcych rwnolege procesy, nieistotnymi dla sieciowych aspektw zagadnie nia, pokazujemy ha serwer iteracyjny. (W rozdziale 8 ksiki [Stevens 1992] omwiona jest funkcja fork. W rozdziale 4 ksiki [Stevens 1990] porwnano serwery itericyjne i wspbiene.) Istnieje rwnie trzecia moliwo: tzw. serwer wstpnie rozgaziony (pre-forked seroer). W tym przypadku serwer na wstpie (przy uruchomieniu) ustalon liczb razy wywouje funkcj f o r k i kady proces potom ny wywouje ac ce pt dla tego samego deskryptora odbiorczego. W ten sposb unika si wywoania funkcji f ork przy kadym daniu klienta, co m oe w istotny sposb przyspieszy dziaanie program u w przypadku bardzo zajtego serwera. Tej techniki uywaj niektre serwery HTTP.
Na rysunku 1.8 przedstawione zostay zalenoci czasowe dla przeprowadzonej z uyciem TCP transakcji klient-serwer. Zauwaamy tu przede wszystkim zwi kszon w porwnaniu z UDP (rysunek 1.4) liczb pakietw sieciowych: dziewi dla transakcji TCP, dwa - dla UDP. W przypadku uycia TCP czas transakcji mierzony po stronie klienta wynosi przynajmniej 2 x RTT + SPT. Zwykle trzy rodkowe segmenty przesyane od klienta do serwera - ACK wysany w odpowie dzi na SYN serwera, danie i FIN klienta - s wysyane w niewielkich odstpach czasowych, podobnie jak ostatnie dwa segmenty wysyane przez serwera do klienta - odpowied i FIN serwera. Dlatego te czas transakcji bywa bardziej zbliony do 2 x RTT + SPT, ni wynikaoby to z rysunku 1.8. Dodatkowy czas RTT w omawianym tu przykadzie zwizany jest z nawizaniem poczenia TCP - odpowiada to przesaniu dwch pierwszych segmentw z ry sunku 1.8. Jeli TCP potrafioby poczy nawizanie poczenia z wysaniem przez klienta danych i segmentu FIN, a nastpnie odpowied serwera zostaaby poczona z segmentem FIN wysanym przez serwera, czas transakcji wynisby znowu RTT + SPT, czyli tyle samo ile mielimy w przypadku UDP. Tak mniej wicej technik wykorzystuje w rzeczywistoci protok T/TC P.
12
Rozdzia 1
Rysunek 1.8
Diagram czasowy dla transakcji klient-serwer TCP
Sekcja 1.3
Klient-serwer TCP
13
Stan oczekiwania TCP

TCP wymaga, by uczestnik transakcji wysyajcy pierwszy segment FIN, ktrym w naszym przypadku jest klient, pozostawa w stanie oczekiwania (TIME_WAIT) przez czas rwny podwojonemu maksymalnemu czasowi ycia segmentu (maximum segment lifetime - MSL), po tym jak poczenie zostaje cakowicie zakoczone przez obie strony. Zalecan wartoci MSL jest 120 sekund, z czego wynika warto opnienia TIME_WAIT rwna 4 minuty. W czasie gdy poczenie jest w stanie TIME_WAIT, to samo poczenie (tzn. ten sam adres IP i numer portu klienta oraz adres IP i numer portu serwera) nie moe by otwarte ponownie. (Powiemy wicej o stanie TIME_WAIT w rozdziale 4.)
Wiele implementacji opartych na kodzie typu Berkeley pozostaje w stanie TIME_WAIT tylko przez 60 sekund, a nie przez 240 sekund, co byoby zgodne z RFC 1122 [Braden 1989], W e wszystkich prezentowanych tu oszacowaniach zakadamy, e czs oczekiwa nia jest poprawny i wynosi 240 sekund.
W naszym przykadzie pierwszy segment FIN wysany jest przez klienta, co okrela si jako aktywne zamknicie (active close) i opnienie TIME_WAIT poja wia si po stronie klienta. W czasie trwania stanu TIME_WAIT pewne informacje o stanie poczenia s przechowywane przez TCP, tak by poczenie byo w stanie obsuy segmenty, ktre mogy zosta opnione w sieci i ewentualnie dotr po zamkniciu poczenia. Rwnie w przypadku gdy segment z ostatecznym ACK zostanie zagubiony, serwer przele ponownie segment FIN, co spowoduje ponow ne przesanie ostatecznego ACK przez klienta. W innych aplikacjach - w szczeglnoci w protokole HTTP uywanym przez W W W - klient wysya specjaln komend oznaczajc, e zakoczy ju wysya nie dania (zamiast poowicznie zamyka poczenie, tak jak to robimy w przy padku naszego klienta), po czym serwer wysya odpowied, a nastpnie segment FIN. W odpowiedzi klient wysya segment FIN. Rnica polega na tym, e stan TIME_WAIT pojawia si teraz po stronie serwera, a nie klienta. W przypadku silnie aktywnego serwera, z ktrym kontaktuj si liczni klienci, wymagana informac ja o stanie poczenia moe zajmowa duy obszar w pamici serwera. Dlatego te zagadnienie, po ktrej stronie poczenia ma pojawia si stan TIME_WAIT, musi by rozwaone przy projektowaniu systemw transakcyjnych typu klient-serwer. W dalszej czci ksiki pokaemy te, e T /T C P skraca czas trwania stanu TIME_WAIT z 240 sekund do okoo 12 sekund.
Zmniejszenie liczby segmentw wysyanych przez TCP

TCP moe zmniejszy liczb segmentw w transakcji pokazanej na rysunku 1.8, czc dane z segmentami kontrolnymi, tak jak to prezentujemy na rysunku 1.9. Zauwamy, e pierwszy segment zawiera teraz SYN, dane i FIN, a nie tylko SYN, tak jak to byo pokazane na rysunku 1.8. Podobnie odpowied serwera jest poczona z segmentem FIN. Mimo e taka sekwencja pakietw jest dopuszczalna w sensie regu TCP, autor nie zna metody, ktra umoliwiaby aplikacji spowodowanie, by protok TCP wytworzy tak sekwencj segmentw uywajc interfejsu API gniazd
14
Rozdzia 1
(std na rysunku znak zapytania w miejscu funkcji jdra generujcej pierwszy segment wysyany przez klienta i drugi znak zapytania w miejscu funkcji generu jcej ostatni segment wysyany przez serwera). Autor nie zna rwnie implemen tacji, ktra w rzeczywistoci generowaaby przedstawion sekwencj segmentw.
Rysunek 1.9
Diagram czasowy dla minimalnej transakcji TCP
Sekcja 1.3
Klient-serwer TCP
15
W arto zauway, e cho zmniejszylimy liczb segmentw z dziewiciu do pi ciu, czas transakcji z punktu widzenia klienta wynosi nadal 2 x RTT + SPT, poniewa reguy TCP zabraniaj protokoowi TCP serwera dostarczenia danych do serwera zanim potrjne uzgodnienie jest zakoczone. (Rozdzia 27.9 tomu 2 pokazuje, jak TCP umieszcza takie dane w kolejce - a do czasu, gdy poczenie zostanie nawizane.) Takie ograniczenie istnieje, poniewa serwer musi mie pew no, e SYN otrzymany od klienta jest nowy", to znaczy e nie jest to opniony segment SYN pochodzcy z poprzedniego poczenia. Stosuje si nastpujc procedur: serwer potwierdza (ACK) otrzymanie segmentu SYN od serwera, w y sya wasny segment SYN i czeka a klient potwierdzi (ACK) otrzymanie segmen tu SYN. W momencie gdy potrjne uzgodnienie zostaje zakoczone, obie strony transakcji wiedz, e SYN wysany przez drug stron jest nowy. Zmniejszenie liczby pakietw nie zmniejsza czasu transakcji mierzonego po stronie klienta, poniewa serwer nie moe rozpocz przetwarzania dania klienta, dopki po trjne uzgodnienie nie jest zakoczone.
Nastpujcy fragment pochodzi z dodatku zamieszczonego w specyfikacji RFC 1185 [Jacobsen, Braden i Zhang 1990]: Uwaga: umoliwienie szybkiego ponownego uycia poczenia byo jednym z wanych zagadnie we wczesnym okresie rozwoju TCP. Ten wym g by zwizany z nadziej, e TCP bdzie suy zarwno jako podstaw a protoko w poziomu uytkownika, jak i protokow zorientowanych na poczenia. Omawiano przykad segmentu Choinki Boo-Narodzeniowej lub segmentu Kamikaze, ktre zawieray bity SYN i FIN oraz dane. Entuzjazm dla takiego rozwizania zmala, gdy zdano sobie spraw, e potrjne uzgodnienie zwizane z flag SYN i uzgodnienie zw i zane z flag FIN oznaczay, e pomidzy serwerem i klientem musi by wymienionych przynajmniej 5 pakietw. Co wicej, opnienie zwizane ze stanem TIME_WAIT pow o duje, e to samo poczenie nie moe by w istocie natychmiast otwarte ponownie. Pracy nad tym zagadnieniem nie kontynuowano, cho istniejce aplikacje (szczeglnie SMTP) czsto tw orz bardzo krtkie sesje TCP. Problem ponownego uycia jest omijany przez uycie innej pary portw dla kadego poczenia." W specyfikacji RFC 1379 [Braden 1992b] zaznacza si, e Wspomniane segmenty Kamikaze nie byy tworzone jako usuga; byy one gwnie uywane do pow odow ania zaamania innych eksperymentalnych elementw TCP!"
W charakterze eksperymentu autor napisa prbny program, ktry wysya seg ment SYN z danymi i flag FIN. Jest to pierwszy segment na rysunku 1.9. Taki segment by wysyany do standardowych serwerw echa (echo server - bliej omwiony w rozdziale 1.12 tomu 1) dziaajcych na bazie omiu rnych odmian Unixa. Wynike wymiany pakietw byy obserwowane przy pomocy Tcpdump. Siedem z omiu serwerw przetworzyo segmenty poprawnie (4.4 BSD, AIX, 3.2.2, BSD/OS 2.0, HP-UX 9.01, IRIX System V.3, SunOS 4.1.3 i System V Release 4.0), podczas gdy smy (Solaris 2.4) zignorowa dane towarzyszce fladze SYN, co zmusio klienta do ponownego wysania danych. Rzeczywista sekwencja segmentw zaobserwowana dla siedmiu systemw bya inna od scenariusza pokazanego na rysunku 1.9. Po zakoczeniu potrjnego uz godnienia serwer natychmiast potwierdzi (ACK) otrzymanie danych i flagi FIN. Rwnie - poniewa serwer echa nie mia adnej moliwoci cznego wysania odpowiedzi i flagi FIN (czwarty segment na rysunku 1.9) - wysa on dwa segmen-
16
Rozdzia 1
ty: odpowied i segment FIN nastpujcy natychmiast po odpowiedzi. Cakowita liczba przesanych segmentw wyniosa wic 7, a nie 5, jak pokazano na rysunku 1.9. W rozdziale 3.7 powicamy wicej miejsca kompatybilnoci z implementa cjami nie uywajcymi T /T C P oraz prezentujemy wydruk z programu Tcpdump.
Wiele systemw opartych na systemie Berkeley nie potrafi przetw orzy otrzym anego segmentu, jeli segment ten zawiera SYN, FIN, a nie zawiera danych oraz ACK. Ten bd powoduje utworzenie nowego gniazda, pozostajcego w stanie CLOSE_WAIT a do czasu, gdy host zostanie przeadowany. W spomniany segment jest dopuszczalny z pun ktu widzenia protokou T/T C P: klient ustanawia poczenie, przesya 0 bajtw danych i zamyka poczenie.
1.4
Klient-serwer T/TCP
Nasz kod rdowy dla systemu klient-serwer wykorzystujcego T /T C P rni si nieznacznie od kodu TCP z poprzedniego rozdziau, tak by moliwe byo wyko rzystanie zalet T/TC P. Na rysunku 1.10 przedstawiamy kod rdowy klienta T /T C P. ------------------------------------------------------------------------------------------------1 #include "cliserv.h" 2 int 3 m a i n ( i n t argc, char * a r g v C ]) 4 [ /* klient T/TCP 5 s t r u c t s o c k a d d r _ i n serv; 6 char r e q u e s t [ R E Q U E S T ] , r e p l y [R E P L Y ]; 7 int sockfd, n; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 } if (argc != 2) e r r _ q u i t ( "u s a g e : ttcpcli if ( ( s o c k f d = s o c k e t ( P F _ I N E T , e r r _ s y s (" s ocket error");
ttcpcli.c
*/
<1P address of server>"); S 0 C K _ S T R E A M , 0)) < 0)
m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v .s i n _ f a m i l y = A F_IN E T ; s e r v . s i n _ a d d r . s _ a d d r = i n e t _ a d d r ( a r g v [ l ]); serv.sin_port = htons(TCP_SERV_PORT); /* t w o r z y m y d a n i e request[] if ( s e n d t o t s o c k f d , request, REOUEST, MSG_E0F, (SA) &serv, s i z e o f ( s e r v ) ) != REOUEST) err_sys( se n d t o error"); if ((n = r e a d _ s t r e a m ( s o c k f d , reply, e r r _ s y s ( " r e a d error"); REPLY)) < 0) reply[] ... */
/* p r z e t w a r z a m y "n" b a j t w odpowiedzi exi t (0);
------------------------------------------------------------------------------------------------Rysunek 1.10 Klient transakcji T/TCP
ttcpcli.c
Sekcja 1.4
Klient-serwer T/TCP
17
Utworzenie gniazda TCP

1 0- 15
Odwoanie do funkcji socket jest identyczne jak w przypadku klienta TCP i internetowa struktura adresowa zostaje wypeniona adresem IP i numerem portu serwera.
Wysanie dania do serwera

17-19
Klient uywajcy T /T C P nie wywouje funkcji connect. W zamian woana jest standardowa funkqa sendto, ktra wysya danie do serwera oraz ustana wia poczenie z serwerem. D odatkow o-jako czwarty argument funkcji s e n d t o podajemy flag MSG_E0F, ktra informuje jdro systemu, e wanie zakoczyli my wysyanie danych. Postpowanie to jest podobne do wywoania funkcji s h u t d o w n na rysunku 1.5. W rezultacie segment FIN zostaje wysany przez klienta do serwera. Flaga M S G _ E 0 F to nowy element wprowadzony w implementacjach uywajcych T /TC P. Nie naley myli tej flagi z istniejc flag M S G _ E 0 R , ktra jest uywana w protokoach zorientowanych na przesyanie rekordw (jak na przykad warstwa transportowa protokou OSI), by zaznaczy koniec rekordu. W wyniku wywoania funkcji sendto wysany zostaje przez klienta pojedynczy segment zawierajcy flag SYN, danie i flag FIN. Jedno odwoanie do sen dto jest funkcjonalnie rwnowane kolejnym odwoaniom do connect, w r i t e i s h u t down. Odczytanie odpowiedzi serwera
20-21
Odpowied serwera jest odczytana przy pomocy odwoania do funkcji
r e a d _ s t r e a m , takiego samego jak w przypadku klienta TCP.
Na rysunku 1.11 pokazany zosta serwer T/TCP. Ten program jest niemal identyczny z programem serwera TCP z rysunku 1.7: odwoania do socket, bi nd, 1 i sten, accept i r e a d _ s t r e a m s takie same. Jedyna rnica polega na tym, e serwer T /T C P wysya odpowied przy pomocy send, a nie wri te. W ten sposb moe by podana flaga M S G _ E 0 F, co pozwala poczy odpowied serwera z flag FIN wysan przez serwera. Diagram czasowy dla transakcji klient-serwer przeprowadzonej z uyciem T /T C P pokazany zosta na rysunku 1.12. Czas transakcji z punktu widzenia klienta T /T C P jest niemal taki sam jak czas transakcji widziany przez klienta UDP (rysunek 1.4): RTT + SPT. Moemy si spodziewa, e czas transakcji T/T C P bdzie nieznacznie wikszy ni czas tran sakcji UDP, poniewa protok T /T C P wykonuje wicej czynnoci ni protok UDP, a take dlatego, e po obu stronach poczenia konieczne s dwa wywoania read , by odczyta zarwno dane i znak koca pliku (w porwnaniu do pojedyn czego wywoania r e c v f r o m p o obu stronach w przypadku UDP). Dodatkowy czas przetwarzania w obu zaangaowanych hostach jest zwykle jednak znacznie mniejszy ni czas RTT. (Pewne porwnanie czasw transakcji mierzonych dla naszych systemw klient-serwer wykorzystujcych UDP, TCP i T /T C P prezentu jemy w rozdziale 1.6). Wycigamy wic wniosek, e transkacja T /T C P jest szybsza
18
Rozdzia 1
ni transakcja TCP o czas niemal rwny RTT. W protokole T /T C P mona za oszczdzi czas odpowiadajcy wartoci RTT dziki wykorzystaniu procedury TAO (TCP accelerated open - przyspieszone otwarcie TCP), ktra omija potrjne uzgodnienie. W nastpnych dwch rozdziaach opisujemy, jak jest to zrealizowa ne, a w podrozdziale 4.5 wyjaniamy, dlaczego taka procedura moe dziaa po prawnie. ------------------------------------------------------------------------------------------------1 //include "cliserv.h" 2 int 3 main() 4 ( /* serwer T / T C P */ 5 s t r u c t s o c k a d d r _ i n serv. cli; 6 char r e q u e s t [ R E Q U E S T ] , r e p l y [R E P L Y J : 7 int l i stenfd. sockfd. n. clilen; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ) ) if ((listenfd = socket(PF_INET. e r r _ s y s (" s o cket error"); SOC K _ S T R E A M , 0)) < 0)
ttcpsew.c
m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ): s e r v . s i n _ f a m i l y = A F_IN E T ; serv.sin_addr.s_addr = htonl(INADDR_ANY); serv.sin_port = htons(TCP_SERV_PORT); if if ( b i n d d i s t e n f d , (SA) &serv, e r r _ s y s ( " b i n d error"): s i z e o f ( s e r v ) ) < 0)
( l i s t e n d i s t e n f d . S0 M A X C 0 N N ) < 0) e r r _ s y s ( " l i s t e n error");
for (;;) ( c l i l e n - s i z e o f t c l i ): if ( ( s ockfd = a c c e p t ( l i s t e n f d , err_sys( accept error");
(SA) &cli, S c l i l e n ) ) < REO U E S T ) ) < 0)
0)
if ((n = r e a d _ s t r e a m ( s o c k f d . request, err_sys("read error");
/* p r z e t w a r z a m y "n" b a j t w dania i t w o r z y m y o d p o w i e d . . . if (se ndtsockfd, reply. REPLY. MSG_E0F) err_sys("send error"); close(sockfd); != REPLY)
*/
------------------------------------------------------------------------------------------------Rysunek 1.11 Serwer transakcji T /T C P
ttcpseru.c
Przeprowadzenie transakcji w przypadku UDP wymaga przesania przez sie dwch pakietw, T /T C P - trzech pakietw, a TCP - dziewiciu pakietw. (Zaka damy, e adne pakiety nie zostaj zgubione.) T /T C P nie tylko skraca wic czas transakcji, ale rwnie zmniejsza liczb pakietw sieciowych. Zmniejszenie liczby pakietw sieciowych jest podane, poniewa rutery ograniczaj czsto liczb przesyanych pakietw - bez wzgldu na rozmiar pojedynczego pakietu.
Sekcja 1.5
Sie testowa
19
Podsumowujc, T /T C P zapewnia niezawodno i molwo dostosowania do konkret nych potrzeb - waciwoci zasadnicze dla aplikacji sieciowych. Dzieje si to ko sztem zwikszenia liczby wysyanych pakietw o jeden, przy niewielkim zwi kszeniu czasu transakcji.
1.5
Sie testowa
Na rysunku 1.13 przedstawiona jest sie uywana do testowania wszystkich przy kadowych programw prezentowanych w tekcie.
20
Rozdzia 1
Ethernet, 140.252.13.0
Rysunek 1.13 Sie, w ktrej wykonywane s wszystkie przykady omawiane w tekcie (wszystkie adresy IP zaczynaj si. od 140.252.) Wikszo przykadowych programw jest uruchamiana w dwch komputerach uywajcych protokou T /T C P: lap t o p i b s d i . Wszystkie adresy IP na rysunku s czci sieci typu B: 140.252.0.0. Wszystkie nazwy hostw nale do domeny tuc .noao.edu. Akronim noao oznacza National Optical Astronomy Observatories (Narodowe Astronomiczne Obserwatoria Optyczne), a tuc pochodzi od na zwy Tucson. N a rysunku 1.13 nad prostoktami odpowiadajcym poszczeglnym komputerom zaznaczylimy uywany system operacyjny.
1.6
Przykad pomiaru czasu
Moemy zmierzy czas transakcji dla kadego z naszych trzech systemw klient-ser wer i porwna wyniki. Zmodyfikujemy programy klienta w ten sposb: W kodzie klienta UDP z rysunku 1.1 dodamy wywoania funkcji odczytujcej czas zegara bezporednio przed wywoaniem sen d t o oraz zaraz po odwoaniu do recvfrom. Rnica pomidzy wartociami czasu otrzymanymi w tych dwch punktach jest czasem transakcji mierzonym dla klienta.
Sekcja 1.6
Przykad pomiaru czasu
21
W przypadku klienta TCP z rysunku 1.5 odczytamy czas zegara bezporednio przed wywoaniem c o n n e c t i bezporednio po funkcji read_stream. W kodzie klienta T /T C P z rysunku 1.10 czas zegara zostanie odczytany bez porednio przed wywoaniem s e n d t o oraz zaraz po wywoaniu funkcji
read_stream.
Na rysunku 1.14 przedstawiamy wyniki porwnania dla 14 rnych wielkoci dania i odpowiedzi. Klientem jest host bsdi z rysunku 1.13, serwerem za host 1 ap top . W dodatku A dokadniej omawiamy tego typu pomiary i czynniki wpy wajce na ich rezultaty.
Rysunek 1.14
Czas wykonania transakcji UDP, T/TCP i TCP
Czasy otrzymywane z uyciem protokou T/TCP s zawsze o kilka milisekund wiksze ni czasy dla protokou UDP. (Poniewa rnice czasu s zwizane z opro gramowaniem, rnice te bd z upywem lat male, jako e komputery staj si coraz szybsze.) Stos protokou T /T C P wykonuje wicej czynnoci ni UDP (rysu nek A.8 str. 315). Zauwaylimy rwnie, e klient i serwer T /T C P wykonuj po dwa odwoania do funkcji read , zamiast pojedynczego odwoania do recvfrom. Czasy otrzymane dla protokou TCP s zawsze o okoo 20 ms wiksze ni odpo wiednie czasy dla T/T C P. Czciowo jest to zwizane z potrjnym uzgodnieniem w trakcie nawizywania poczenia. Dugo dwch segementw SYN wynosi 44 bajty (20-bajtowy nagwek IP, standardowy 20-bajtowy nagwek TCP i 4-bajto-
22
Rozdzia 1
wa opcja TCP - MSS). Odpowiada to 16 bajtom danych uytkownika wysanym przy pomocy Ping; na rysunku A.3 (str. 309) widzimy, e RTT wynosi okoo 10 ms. Dodatkowe 10 ms rnicy jest prawdopodobnie zuytkowane na dodatkowe przetwarzanie szeciu dodatkowych segmentw TCP. Moemy wic stwierdzi, e czas transakcji T /T C P bdzie nieco wikszy (cho bliski) ni czas otrzymany dla UDP. Czas transakcji T /T C P bdzie mniejszy od czasu TCP przynajmniej o warto rwn RTT dla 44-bajtowego segmentu. Wzgldny zysk wynikajcy z uycia T /T C P zamiast TCP zaley od relacji pomi dzy czasem RTT a SPT. Na przykad w sieci lokalnej (LAN) z RTT rwnym 3 ms (rysunek A.2 str. 308), dla serwera ze rednim czasem przetwarzania 500 ms, czas transakcji TCP wyniesie okoo 506 ms (2 x RTT + SPT), a czas transakcji T /T C P okoo 503 ms. W przypadku sieci typu WAN, z czasem RTT okoo 200 ms (rozdzia 14.4) i rednim czasem SPT okoo 100 ms, odpowiednie wartoci wynosz okoo 500 ms dla TCP i 300 ms dla T/T C P. Pokazalimy rwnie, e T /T C P wykorzystu je mniejsz liczb pakietw sieciowych (3 w porwnaniu do 9, rysunki 1.8 i 1.12). Tak wic niezalenie od zmierzonego zmniejszenia czasu, zawsze zmniejszeniu ulega liczba przesyanych pakietw. Zmniejszenie liczby pakietw moe zmniej szy prawdopodobiestwo zagubienia pakietu i - w kontekcie Internetu widzia nego jako cao - przyczynia si do zwikszenia oglnej stabilnoci sieci. W rozdziale A.3 (str. 316-319) omawiamy rnic midzy czasem propagacji (latency), a pasmem przenoszenia. RTT zaley co prawda zarwno od czasu propagacji, jak i od pasma przenoszenia, ale wraz ze zwikszeniem si szybkoci przesyania danych w sieciach bardziej istotny staje si czas propagacji. Co wicej, czas propagacji to wielko, na ktr nie mamy wpywu, poniewa jest on wyzna czony przez prdko wiata i odlego pomidzy klientem i serwerem. Dlatego te - wraz ze zwikszeniem szybkoci sieci - zmniejszenie liczby pakietw przesy anych w obie strony staje si coraz bardziej podane i korzyci wynikajce ze stosowania T /T C P rosn.
Oglnie dostpne testy szybkoci sieci od niedawna uwzgldniaj rwnie T /T C P:
http://www.cup.hp.com/netperf/NetperfPage.html.
1.7
Aplikacje
Pierwsz zalet korzystania z T/T C P, istotn dla kadej aplikacji TCP, jest poten cjalna moliwo skrcenia stanu TIME_WAIT. Pozwala to na zmniejszenie liczby blokw kontrolnych, ktre implementacja musi przetwarza regularnie. W roz dziale 4.4 omawiamy t waciwo protokou bardziej szczegowo. W tym miej scu wspomnijmy tylko, e waciwo ta jest cenna dla wszystkich aplikacji, ktre wykorzystuj krtkie (typowo: krtsze ni 2 minuty) poczenia TCP, jeli tylko oba hosty potrafi uywa T/TC P. Najwikszym, by moe, poytkiem wynikajcym ze stosowania T /T C P jest omi nicie potrjnego uzgodnienia. Ponadto wszystkie aplikacje, ktre wymieniaj niewielkie iloci danych, skorzystaj na zmniejszeniu czasu oczekiwania. Przed-
Sekcja 1.7
Aplikacje
23
stawimy kilka przykadw takich aplikacji. (W dodatku B omawiamy zmiany w programowaniu, konieczne do uniknicia potrjnego uzgodnienia w T/TC P.)
wiatowa pajczyna: protok HTTP

W W W (World Wide Web), czyli wiatowa Pajczyna i stosowany przez ni protok HTTP (Hyperex Transfer Protocol), ktry omawiamy w rozdziale 13, w duym stopniu mog wykorzysta zalety T/TC P. W pracy [Mogul 1995b] zauwaono, e: Gwnym powodem opnie widocznych przy uyciu W W W jest komunikacja sieciowa... Skoro nie moemy zwikszy prdkoci wiata, powinnimy przynaj mniej zmniejszy liczb pakietw przesyanych w obie strony przy kadej czynno ci. Protok HTTP, w formie obecnie uywanej w WWW, wykonuje o wiele wicej przesa pakietw w obie strony, ni to jest niezbdnie konieczne." Na przykad dla przypadkowo wybranej prbki 200 000 transferw z uyciem HTTP stwierdzono [Mogul 1995b], e najczciej spotykan dugoci odpowiedzi byo 1770 bajtw. (Uywa si czsto wartoci najczciej spotykanej - mediany, zamiast wartoci redniej, poniewa niewielka liczba duych plikw moe spowo dowa znaczce przesunicie wartoci redniej.) Mogul podaje te inny przykad prawie ptora miliona transferw, dla ktrych najczciej spotykana dugo odpowiedzi wynosia 958 bajtw. danie klienta jest czsto mniejsze: 100-300 bajtw. Typowa transakcja HTTP typu klient-serwer jest podobna to transakcji przedsta wionej na rysunku 1.8. Klient wykonuje aktywne otwarcie, wysya niewielkie danie do serwera, serwer wysya odpowied i zamyka poczenie. Tego rodzaju wymiana pakietw to idealny przykad poczenia, ktre mogoby wykorzysty wa T /T C P . Zastosowanie TCP pozwolioby unikn przesyania pakietw w obie strony przy okazji potrjnego uzgodnienia - segment SYN wysany przez klienta zostaby poczony z daniem klienta. Zmniejszeniu ulegaby rwnie liczba pakietw sieciowych, co - zwaszcza w czasach gdy natenie ruchu w sieci generowane przez Pajczyn jest tak wielkie - byoby bardzo istotne.
Poczenie typu transfer danych protokou FTP

Kolejnym kandydatem jest poczenie transferu danych protokou FTP. W opraco waniu natenia ruchu w Internecie przedstawionym w pracy [Paxson 1994b] pokazano, e rednio w jednym poczeniu FTP przesya si 3000 bajtw. Na stronie 494 tomu 1 pokazujemy przykad poczenia transferu danych FTP, ktre jest podobne do poczenia z rysunku 1.12, cho dane przesyane s tylko w jed nym kierunku. Osiem segmentw ze wspomnianego rysunku zostaoby zastpio nych trzema segmentami w przypadku poczenia T/TC P.
System nazw domen (DNS)

Klient w systemie DNS wys.ya zapytania do serwera uywajc UDP. Serwer odpowiada z uyciem UDP, ale jeli odpowied jest dusza ni 512 bajtw, tylko pierwszych 512 bajtw zostaje przesanych wraz z flag informujc, e dalszy
24
Rozdzia 1
cig odpowiedzi oczekuje na przesanie. W takim przypadku klient powtarza pytanie uywajc TCP, a serwer przesya kompletn odpowied, rwnie stosujc protok TCP. Technika taka jest stosowana, poniewa nie m a gwarancji, e host potrafi przyj datagram IP o dugoci przekraczajcej 576 bajtw. (Rzeczywicie, wiele aplikacji UDP ogranicza dugo danych uytkownika do 512 bajtw, po to by zmieci si poniej limitu 576 bajtw.) Poniewa TCP jest protokoem przesyajcym strumie bajtw, rozmiar odpowiedzi nie stanowi problemu. Wysyajcy host TCP dzieli odpowied na czci o odpowiedniej dugoci - ograniczeniem jest maksymalny rozmiar segmentu (MSS) przekazany przez partnera w czasie nawizywania po czenia. Odbierajcy host TCP przyjmuje segmenty i przekazuje do aplikacji dane, podzielone na dowolne fragmenty, zgodnie z wymaganiami funkcji czytajcej uywanej przez aplikacj. Klient i serwer DNS mogyby uywa T /T C P , zacho wujc szybko UDP i korzystajc jednoczenie ze wszystkich zalet TCP.
Zdalne wywoanie procedur (RPC)

Protok RPC (Remote Procedure Calls - zdalne wywoanie procedur) jest wymie niany niemal zawsze, gdy trzeba poda przykad protokou transportowego zaprojektowanego z myl o przeprowadzaniu transakcji. Dziaanie RPC opiera si na wysaniu przez klienta do serwera dania zawierajcego nazw procedury, ktra m a by wykonana przez komputer serwera, wraz z argumentami podanymi przez klienta. Odpowied serwera zawiera wartoci zwrcone przez wywoan procedur. (W rozdziale 29.2 pracy [Stevens 1994] przedyskutowana jest imple mentacja RPC dziaajca na komputerach Sun.) Implementacje RPC charakteryzuj si zwykle duymi rozmiarami, w sensie du goci kodu, poniewa staraj si one zapewni niezawodno dziaania RPC opierajc si na zawodnym protokole, jakim jest UDP - unikajc potrjnego uzgodnienia protokou TCP. Zastosowanie T /T C P pozwolioby na zapewnienie RPC niezawodnoci waciwej dla TCP, bez koniecznoci potrjnego uzgodnienia. Innymi kandydatami do stosowania T /T C P s wszystkie aplikacje oparte na RPC, jak na przykad Sieciowy System Plikw ( NFS - Network File System).
1.8
Historia
Jednym z wczesnych dokumentw zajmujcych si przetwarzaniem transakcji jest RFC 938 [Miller 1985]. Dokument ten definiuje IRTP (Internet Reliable Transaction Protocol - niezawodny internetowy protok transakcyjny), ktry oferuje nieza wodne, sekwencyjne dostarczanie pakietw z danymi. Wymieniony dokument RFC okrela transakcj jako may, kompletny komunikat. W zaoeniu IRTP defi niuje si trwae poczenie pomidzy dwoma dowolnymi hostami (tzn. adresami IP), ktre zostaje zresynchronizowane, gdy ktrykolwiek z hostw zostaje przea dowany. IRTP jest nakadk na IP i definiuje swj wasny 8-bajtowy nagwek.
Sekcja 1.8
Historia
25
Kolejny dokument - RFC 955 [Braden 1985], nie specyfikuje protokou w sensie dosownym, za to podaje pewne kryteria projektowania protokow transakcyj nych. W dokumencie tym zauwaa si, e dwa dominujce protokoy transporto we, UDP i TCP, oferuj diametralnie rne usugi, a protokoy transakcyjne trafiaj ze swoimi wymaganiami w obszar lecy pomidzy UDP i TCP, nie obejmowany w istocie przez aden z tych protokow. RFC 955 definiuje transakcj jako prost wymian komunikatw: danie klienta skierowane do serwera, z nastpujc po nim odpowiedzi serwera. W tym RFC zauwaa si te, e cechami wsplnymi wszystkich transakcji s: asymetria (na jednym kocu poczenia jest klient, na drugim serwer), jednokierunkowy przepyw danych (dane nigdy nie s przesya ne jednoczenie w obu kierunkach), krtki czas trwania (by moe dziesitki sekund, ale nigdy godziny), niewielkie opnienie, niewiele pakietw danych, operowanie komunikatami (nie strumieniem bajtw). We wspomnianym RFC jako przykad analizowany jest DNS. Zauwaa si, e konieczno wyboru pomidzy TCP a UDP stwarza nieprzyjemny dylemat dla serwera. Optymalny protok transakcyjny powinien umoliwi niezawodne do starczenie danych, nie powinno by konieczne jawne nawizanie poczenia, jaw ne jego zerwanie, ani podzia komunikatu na czci, czy odtworzenie komunikatu z fragmentw (aplikacja nie powinna by zmuszona do zajmowania si magiczny mi liczbami, jak na przykad 576), a stan bezczynnoci powinien trwa moliwie najkrcej na obu kocach poczenia. TCP posiada te wszystkie cechy - wyjtkiem jest konieczno nawizania poczenia i jego zerwania. Innym pokrewnym protokoem jest RDP (Reliable Data Protocol - niezawodny protok danych), zdefiniowany w RFC 908 [Velten, Hinden i Skx 1984], uaktual niony w RFC 1151 [Partridge i Hinden 1990]. Dowiadczenia zebrane w trakcie implementowania tego protokou mona znale w pracy [Partridge 1987], W pra cy [Partridge 1990a] zawarty jest natomiast nastpujcy komentarz o RDP: Kiedy ludzie pytaj o niezawodny protok datagramowy (i zanim Jon Postel napadnie na mnie, tak Jon, wiem, e jest to oksymoron), to maj wtedy zwykle na myli protok transakcyjny - protok, ktry umoliwia niezawodn wymian danych z wieloma oddalonymi systemami. Rodzaj niezawodnej wersji UDP. RDP powi nien by traktowany jako protok TCP operujcy rekordami. RDP uywa po cze i niezawodnie przesya strumie nieliniowych danych. Nie jest to protok transakcyjny." (RDP nie jest protokoem transakcyjnym, poniewa stosuje potrj ne uzgodnienie, tak samo jak TCP.) RDP uywa zwykego interfejsu API gniazd i oferuje strumieniowy interfejs gniazd (SOCK_STREAM ), podobnie jak TCP. Dodatkowo RDP oferuje typy gniazd S0CK_RDM (reliably delivered message - niezawodnie dostarczony komunikat) i SOCK_SEQPACKET (sequenced packet - pakiet uszeregowany). Protok VMTP ( Versatile Message Transaction Protocol - uniwersalny protok transakcji komunikatw) zosta okrelony w RFC 1045 [Cheriton 1988]. Protok ten by specjalnie zaprojektowany pod ktem obsugi transakcji reprezentowa nych przez zdalne wywoania procedur. Podobnie jak IRTP i RDP, protok
26
Rozdzia 1
VMTP tworzy warstw transportow ulokowan jako nakadka na IP. VMTP obsuguje jednak bezporednio przesyanie grupowe (multicasting) - waciwoci tej nie posiadaj T/TCP ani inne protokoy wymienione w tym podrozdziale. (Podejcie takie byo krytykowane w pracy [Floyd i in. 1995], w ktrej twierdzi si, e niezawodne przesyanie grupowe powinno by obsugiwane w warstwie apli kacyjnej, a nie w warstwie transportowej.) Protok VMTP oferuje aplikacjom inny interfejs API. Interfejs ten zosta opisany w dokumencie RFC 1045. Typ gniazda jest zdefiniowany jako S0CK_TRANSACT. Cho wiele elementw T /T C P opisano w RFC 955, pierwsza specyfikacja tego protokou pojawia si dopiero w RFC 1379 [Braden 1992b]. Ten ostatni dokument definiuje protok T /TC P. Uzupenieniem RFC 955 by dokument RFC 1644 [Braden 1994], w ktrym sprecyzowano dodatkowe szczegy definicji protokou i przedyskutowano niektre zagadnienia implementacyjne. Interesujce jest pokazane niej porwnanie liczby linii kodu rdowego w C koniecznych, by zaimplementowa rne protokoy warstwy transportu.
Protok UDP (tom 2) RDP TC P (tom 2) TCP z modyfikacjami T/TCP VMTP Liczba linii kodu 800 2 700 4 500 5 700 21 000
Rysunek 1.15
Liczba linii kodu potrzebna do implementacji rnych warstw transportu
Dodatkowy kod, konieczny by moliwa bya obsuga T /T C P (okoo 1200 linii), jest ptora raza wikszy ni implementacja UDP. Obsuga przesa grupowych doda na do 4.4BSD wymagaa okoo 2000 linii kodu (pomijajc zmiany w programach obsugi urzdze i obsug grupowego nitowania).
Protok VMTP jest dostpny pod adresem: f t p : / / g r e g o r i o .Stanford . e d u / v m t p - i p. RDP nie jest oglnie dostpny.
1.9
Implementacje
Pierwsza implementacja T /T C P zostaa napisana przez Boba Bradena i Liminga Wei w Information Sciences Institute Uniwersytetu Poudniowej Karoliny. Praca ta bya czciowo finansowana przez National Science Foundation w ramach grantu numer NCR-8922231. Implementacja ta zostaa wykonana dla systemu SunOS 4.1.3 (z jdrem wywodzcym si z systemu Berkeley) i zostaa udostpnio na za porednictwem FTP ( f t p : / / f t p . i s i . e d u / p u b / b r a d e n / T T C P . t a r . Z ). Kod rdowy jdra SunOS jest jednak potrzebny, by mc uruchomi udostpnione uzupenienia.
Sekcja 1.9
Implementacje
27
Wymieniona wyej implementacja zostaa zmodyfikowana przez Andrasa Olaha z Uniwersytetu Twente (Holandia) i zostaa wczona do systemu FreeBSD 2.0 udostpnionego w marcu 1995 r. Kod obsugi sieci we FreeBSD 2.0 jest oparty na systemie 4.4BSD-Lite (opisany w tomie 2). Chronologi pojawiania si rnych wersji systemu BSD pokazujemy na rysunku 1.16. Caa praca zwizana z tablic nitowania (patrz rozdzia 6) zostaa wykonana przez Garretta Wollmana z Massa chusetts Institute of Technology. Informacje na temat dostpnoci implementacji zawartej we FreeBSD mona uzyska pod adresem h t t p : / / w w w . f r e e b s d . o r g .
4.2BSD (1983) pierwsza szeroko dostpna wersja TCP/IP 1 4.3BSD (1986) poprawa sprawnoci dziaania TC P I T 4.3BSD Tahoe (1988) powolny start, unikanie przecienia, szybka retransmisja I 4.3BSD Reno (1990) szybkie odtwarzanie poczenia, _________ przewidywanie nagwka, kompresja nagwka SLIP, zmiany w tablicy rutowania BSD Networking Software Release 2.0 (1991): Net/2 I T 4.4BSD (1993) przesyanie grupowe, modyfikacje dugich, szerokich potokw
___ '
BSD Networking Software Releasel.O (1989): Net/1
4.4BSD-Lite (1994) ' oznaczane w tekcie ksiki jako Net/3 BSD/OS > FreeBSD NetBSD
' 4.4BSD-Llte2 (1995)
Rysunek 1.16
Rne wersje BSD i loaniejsze waciwoci IP
28
Rozdzia 1
Autor niniejszej ksiki przenis implementacj zawart we FreeBSD do jdra systemu BSD/OS 2.0 (ktry jest rwnie oparty na kodzie obsugi sieci z 4.4BSDLite). Ten kod uywany jest w komputerach bsdi i l a p t o p (rysunek 1.13), ktre s uywane do uruchamiania programw przedstawionych w tekcie. Rozszerzenia systemu BSD/OS, umoliwiajce obsug T /T C P, s dostpne za porednictwem strony domowej autora: h t t p : / / w w w .noao .ed u/~rstevens. Rysunek 1.16 pokazuje kolejno pojawiania si rnych wersji BSD, z zaznaczo nymi istotnymi waciwociami TC P/IP. Wersje pokazane w lewej czci rysunku s wersjami z publicznie dostpnym kompletnym kodem rdowym: protokoy, procedury interfejsu sieciowego zawarte w jdrze i wiele aplikacji oraz progra mw uytkowych (jak na przykad Telnet i FTP). Oficjalna nazwa oprogramowania uywanego jako podstawa implementacji T /T C P zawartych w tekcie ksiki brzmi 4.4BSD-Lite, bdziemy jednak uywa prostszej nazwy: Net/3. Naley te zauway, e oglnie dostpna wersja Ne t /3 nie obejmuje modyfikacji zwizanych z T /TC P, ktre s przedstawione w ksice. Gdy uywamy terminu N e t/3, odnosimy si do oglnie dostpnej wersji, ktra nie obejmuje T/TC P. System 4.4BSD-Lite2 jest modyfikacj 4.4BSD-Lite udostpnion w roku 1995. Z punktu widzenia obsugi sieci zmiany wprowadzone w Lite2, w porwnaniu do Lite, ograniczaj si do usunicia bdw i niewielkich usprawnie (jak na przy kad ograniczenie czasu oczekiwania na tzw. prbki trwaoci - persist probes). Wymieniamy trzy systemy oparte na kodzie Lite: BSD/OS, FreeBSD i NetBSD. W czasie gdy powstaje ta ksika, wszystkie trzy systemy oparte s na oryginalnym kodzie Lite. Nastpne wersje tych systemw powinny by ju oparte na Lite2. CD-ROM zawierajcy kod Lite2 jest rozprowadzany przez firm Walnut Creek CD-ROM, h t t p : / / w w w .c d r o m .com. W tekcie ksiki bdziemy uywa okrelenia implementacja oparta na systemie Berkeley w odniesieniu do takich implementacji jak SunOS, SVR4 (System V Release 4) i AIX, ktrych oryginalny kod by stworzony na podstawie kodu rdowego systemu Berkeley. Wszystkie te implementacje maj wiele cech wsplnych - cznie z powieleniem tych samych bdw!
1.10
Podsumowanie
W niniejszym rozdziale staralimy si przekona Czytelnika, e protok T /T C P oferuje rozwizanie wielu rzeczywistych problemw zwizanych z aplikacjami sieciowymi. Porwnalimy najpierw kody prostych systemw klient-serwer, napi sanych z uyciem UDP, TCP i T/TC P. Dwa pakiety byy wymieniane przez system oparty na UDP, dziewi pakietw w przypadku TCP i trzy pakiety w przypadku T/TC P. Nastpnie pokazalimy, e czas transakcji z punktu widze nia klienta jest niemal taki sam dla T /T C P jak dla UDP. Pomiary czasu zaprezen towane na rysunku 1.14 potwierdzaj nasze stwierdzenia. Poza zblion do UDP
Sekcja 1.10
Podsumowanie
29
szybkoci dziaania, T /T C P oferuje niezawodno i moliwo przystosowania, co w obu przypadkach jest znaczcym ulepszeniem w porwnaniu do UDP. Wymienione zalety protokou T /T C P s wynikiem rezygnacji z typowego dla TCP potrjnego uzgodnienia. Zmiany w kodzie klienta i serwera - konieczne by mc skorzysta z tych zalet T /T C P - s niewielkie; w zasadzie sprowadzaj si do wywoania funkcji sendto zamiast c o n n e c t , wri te i shu t d o w n po stronie klienta. W kolejnych trzech rozdziaach przeanalizujemy bliej sposb dziaania protokou na podstawie wikszej liczby przykadw.
Protok T/TCP
2.1 Wstp
Nasz dyskusj o protokole T /T C P podzielimy na dwie czci (przedstawione w rozdziaach 2 i 4), tak by dogbn prezentacj protokou (rozdzia 4), mc poprzedzi kilkoma przykadami jego uycia (rozdzia 3). Niniejszy rozdzia jest wstpem do przedstawienia technik protokou T /T C P i wymaganych zmiennych implementacyjnych. W nastpnym rozdziale zawarlimy kilka przykadw T /T C P , a w rozdziale 4 pogbimy prezentacj protokou. Dwa problemy pojawiaj si, gdy protok TCP jest uywany do transakqi typu klient-server, tak jak to byo pokazane w rozdziale 1: 1. Potrjne uzgodnienie zwiksza czas transakcji mierzony po stronie klienta o dodatkowy czas RTT. Widzielimy to na rysunku 1.8. 2. Poniewa to klient wykonuje aktywne zamknicie (tzn. wysya pierwsz flag FIN), klient - po odebraniu segmentu FIN wysanego przez serwera - pozostaje w stanie TIME_WAIT przez 240 sekund. Poczenie stanu TIME_WAIT i 16-bitowego numeru portu wprowadza ograniczenie na czstotliwo transakq'i pomidzy dowolnymi dwoma hostami. N a przykad, jeli pewien host-klient dokonuje transakcji w sposb cigy z jednym hostem-serwerem, musi on albo czeka przez 240 sekund pomidzy kadymi dwoma kolejnymi transakqami, albo musi uywa innego portu do kadej kolejnej transakcji. Klient ma jednak do dyspozycji tylko 64 512 portw (65 535 minus 1023 dobrze-znane porty), dostpnych co 240 sekund kady, co ogranicza liczb transakcji do 268 na sekund. W sieci LAN, w ktrej RTT wynosi 1-3 ms, moliwe jest osignicie tego limitu. Nawet jeli aplikacja mieci si poniej wymienionego wyej limitu, wykonujc - powiedzmy - 50 000 transakcji na kade 240 sekund, gdy poczenie jest w stanie TIME_WAIT po stronie klienta, klient musi utworzy blok kontrolny, po to by utrzyma poczenie w niezmienionym stanie. W implementacji BSD, omwionej w tomie 2, wymagane s: blok kontrolny protokou Internetu (zaj mujcy 84 bajty), blok kontrolny TCP (140 bajtw) oraz wzorcowy nagwek IP/TC P. Oznacza to zajcie 13 200 000 bajtw pamici jdra, co jest wielkoci du, nawet biorc pod uwag fakt, e pamici komputerw staj si coraz wiksze. Protok T /T C P rozwizuje te dwa problemy omijajc potrjne uzgodnienie i skracajc czas TIME_WAIT z 240 sekund do okoo 12 sekund. Obie te modyfika cje omwimy szczegowo w rozdziale 4.
32
Protok T/TCP
Rozdzia 2
Podstawowy element T /T C P , ktry pozwala omin potrjne uzgodnienie, okre lany jest jako TAO ( TCP a c c e l e r a t e d oper) - przyspieszone otwarcie TCP). Protok T /T C P przypisuje jednoznaczny identyfikator, zwany licznikiem po czenia ( conn ec ti on c o u n t - CC), kademu poczeniu nawizanemu przez host. Kady host uywajcy T /T C P pamita przez pewien czas ostatni warto liczni ka poczenia dla kadego partnera. Kiedy serwer otrzymuje flag SYN od klienta T /T C P i segment SYN zawiera licznik poczenia, ktry jest wikszy od wartoci ostatnio otrzymanej, oznacza to, e SYN jest nowy i mona zezwoli, by odbieraj cy modu TCP zaakceptowa SYN bez potrjnego uzgodnienia. Taka procedura nazywana jest testem TAO. Jeli wynik testu TAO jest negatywny, TCP powraca do potrjnego uzgodnienia, by sprawdzi, czy otrzymany SYN jest nowy.
2.2
Nowe opcje TCP zwizane z T7TCP
Trzy nowe opcje TCP s uywane w poczeniu T/TC P. N a rysunku 2.1 przedsta wione zostay wszystkie obecnie uywane opqe TCP. Pierwsze trzy pochodz z oryginalnej specyfikacji TCP zawartej w RFC 793 [Postel 1981b]. Czynnik skalu jcy okna (windw s c a l e f ac tor ) i znacznik czasu ( timestamp ) zostay zdefinio wane w RFC 1323 [Jacobson, Braden i Borman 1992]. Ostatnie trzy - CC, CCnew i CCecho - s nowe, zwizane z T /T C P i zdefiniowano je w RFC 1644 [Braden 1994]. Zasady stosowania trzech nowych opcji s nastpujce: 1. Opcja CC moe by wysana w inicjujcym segmencie SYN, czyli w przypadku aktywnego otwarcia wykonanego przez klienta. Moe by rwnie wysana w innych segmentach, ale tylko wtedy, gdy urzdzenie na drugim kocu po czenia wysao CC lub CCnew w swoim segmencie SYN. 2. Opcja CCnew moe pojawi si tylko w inicjujcym segmencie SYN. Protok TCP klienta wysya t opcj zamiast opcji CC, jeli klient chce wykona zwyke potrjne uzgodnienie. 3. Opcja CCecho moe pojawi si tylko w drugim segmencie potrjnego uzgod nienia (zwykle wysyanym przez serwera) zawierajcym flagi SYN i ACK. Potwierdzane jest w ten sposb otrzymanie opcji CC lub CCnew wysanych przez klienta i klient jest informowany, e serwer rozumie protok T /TC P. W dalszej czci tego rozdziau, i w nastpnych rozdziaach, podamy wicej infor macji o trzech nowych opcjach, w miar dyskutowania przykadw T /TC P. Naley zauway, e kada z trzech nowych opcji zajmuje 6 bajtw. W niektrych systemach podane jest, by kada opcja zajmowaa wielokrotno czterech baj tw. Szeciobajtowe opcje s wic zwykle poprzedzone dwoma jednobajtowymi rozkazami pustymi (NOP).
Sekcja 2.2
Nowe opcje TCP zwizane z T/TCP
33
Koniec [sty opcji (EOl)
kind-0 1 bajt
Rozkaz pusty (NOP):
kind-1 1 baji maksymalny rozmiar segmentu (MSS) 2 bajty
Maksymalny rozmiar segmentu:
kind2 1 bajt
len*4 1 bajt
Czynnik skali okna:
kind-3 1 bajt
len=3 1 bajt
warto przesunicia 1 bajt
Znacznik czasu:
kind*8 1 bajt
len-10 1 bajt
warto znacznika czasu 4 bajty
odpowied .echo' znacznika czasu 4 bajty
CC:
ldnd-11 1 bajt
len=6 1 bajt
Beznfk poczenia 4 bajty
a:
CCnew:
kind=12 1 bajt
len>6 1 bajt
nowa warto licznika poczenia 4 bajty
CCecho:
kind-13 1 bajt
len-6 1 bajt
licznik poczenia - echo 4 bajty
Rysunek 2.1
Opcje TCP
Na rysunku 2.2 przedstawione zostay opcje TCP w iniq'ujcym segmencie SYN wysanym przez klienta do serwera, w przypadku gdy klient uywa protokou zgodnego z RFC 1323 i T/TC P. Na rysunku zaznaczono wartoci kind i len dla kadej opcji, a pola NOP przedstawipno jako zacieniowane prostokty z wartoci kind rwn jeden. Druga opcja (symbol WS") to opcja skali okna (window sca 1e ). W przedstawionym przykadzie opcje TCP zajmuj 28 bajtw, przy maksymalnej dugoci pola przeznaczonego na opcje rwnej 40 bajtw. W arto zauway, e rozkazy puste (NOP) tak uzupeniaj pola zajmowane przez opcje, by dugo kadej opcji bya wielokrotnoci 4 bajtw.
34
Protok T/TCP
Rozdzia 2
4 2 4 MSS 1 3
12
16
20 1
24
W znacznik czasu 3 1 i ; ; 8 10 znacznik czasu -echo S
1 CC
26
11 6
Rysunek 2.2
Opcje TCP w inicjujcym segmencie SYN wystanym przez klienta zgodnego z RFC 1323 i znajcego T/TCP
Jeli serwer nie uywa protokou zgodnego z RFC 1323 lub T /TC P, odpowied skadajca si z SYN i ACK bdzie zawieraa tylko opcj MSS. Jeeli natomiast protok uywany przez serwera jest zgodny zarwno z RFC 1323 jak i z T /T C P , odpowied bdzie zawieraa opcje przedstawione na rysunku 2.3.
4 2 4 MSS 1 3 W 3 S 8 1 12 16 20 24 CC 28 13 6 32 CC echo 36
znacznik czasu .1 Ili; 11 6 1 8 10 znacznik czasu -echo
Rysunek 2.3
Opcje TCP w odpoiuiedzi serwera na segment zawierajcy opcje z rysunku 2.2
Poniewa opcja CCecho jest zawsze wysyana cznie z opcj CC, protok T /T C P powinien w zasadzie poczy obie te opcje w jedn, oszczdzajc w ten sposb 4 bajty cennej przestrzeni przeznaczonej na opcje TCP. Ewentualnie, jako e najgor sza kombinacja opcji zdarza si tylko w przypadku SYN /A C K wysanych przez serwera, co tak czy inaczej oznacza powolne przetwarzanie na wejciu TCP, m o na by byo pomin rozkazy puste, oszczdzajc w ten sposb 7 bajtw. Poniewa opcje MSS i opcja skali okna pojawiaj si tylko w segmentach SYN, a opcja CCecho pojawia si tylko w segmencie SYN /ACK , wszystkie nastpne opcje tego poczenia zawieraj tylko znacznik czasu i opcje CC. Przedstawiamy to na rysunku 2.4. Zakadamy tutaj, e po obu stronach poczenia uywane s protokoy zgodne z RFC 1323 i T /TC P.
4 1: i 8 10 znacznik czasu B znacznik czasu -echo 12 1 i 11 6 16 o " o
Rysunek 2.4
Opcje TCP w segmentach innych ni SYN, gdy oba hosty dziaaj zgodnie z RFC 1323 i znaj T/TCP
Zauwamy, e opcje znacznika czasu i CC zwikszaj o 20 bajtw dugo wszyst kich segmentw TCP wysyanych po nawizaniu poczenia. Mwic o T /T C P czsto uywamy oglnego okrelenia opcje CC (CC options), odnoszc si do wszystkich trzech opcji omwionych w obecnym podrozdziale.
Sekcja 2.3
Zmienne implementacyjne T/TCP
35
0 ile zwiksza si objto przesyanych danych, gdy uywane s opcje CC 1 zriacznika czasu? Zakadajc typowo, e MSS dla dwch hostw w rnych sieciach wynosi 512 bajtw, plik o dugoci 1 miliona bajtw przesyany jest w 1954 segmentach bez opcji, lub w 2033 segmentach, gdy opcje CC i znacznik czasu s uywane. Oznacza to zwikszenie liczby segmentw o 4%. Jeeli warto MSS jest rwna 1460 bajtw, liczba segmentw ronie tylko o 1,5%.
2.3
Protok T /T C P wymaga, by jdro systemu przechowywao pewne nowe infor macje. W tym podrozdziale opisujemy, jakie s to informacje, a w nastpnym pokaemy, jak s one uywane. 1. t c p _ c c g e n to 32-bitowa globalna zmienna cakowita zawierajca warto CC, ktra m a by uyta przy nastpnym poczeniu. Zmienna ta jest zwikszana o 1 przy kadym poczeniu TCP nawizanym przez hosta, aktywnie lub pa sywnie - b e z wzgldu na to, czy poczenie uywa T /T C P , czy nie. Warto tej zmiennej nigdy nie jest rwna 0. Jeli w wyniku inkrementacji zmienna miaa by osign warto 0, ustawiana zostaje warto 1. 2. Zesp zmiennych zwizanych z konkretnym hostem (tzw. p e r - h o s t cache), zawierajcy trzy nowe zmienne: tao_cc , t ao_ccsent i tao_mssopt. Ta grupa zmiennych nazywana jest rwnie pamici TAO ( TAO cache). Zobaczymy, e dla kadego hosta nasza implementacja T/TC P tworzy wpis w tablicy rutowania. (Tablica rutowania jest jedynie wygodnym umiejscowieniem pamici TAO. W za sadzie do tego celu mogaby by stworzona oddzielna tablica. T/TC P nie wymaga wprowadzenia adnych modyfikacji funkcji rutowania IP.) W momencie gdy nowy wpis jest tworzony w pamici TAO, t a o_c c i t a o_c c s en t musz otrzyma pocztkow warto rwn 0, co oznacza, e zmienne te s niezdefiniowane.
t a o_c c zawiera ostatni warto CC otrzyman od danego hosta w segmencie SYN, bez opcji ACK (aktywne otwarcie). Jeli host T /T C P otrzymuje segment SYN z opcj CC i jeeli warto tej opcji jest wiksza ni t a o_c c, serwer wie, e jest to nowy SYN, a nie duplikat starego, i moliwe jest pominicie potrjnego uzgodnienia (test TAO). t a o _ c c s e n t zawiera ostatni warto CC wysan do danego hosta w segmen cie SYN bez opcji ACK (aktywne otwarcie). Jeeli zmienna ta jest niezdefinio wana (0), to otrzymuje ona niezerow warto, kiedy host-partner poinformuje, e potrafi uywa T /T C P, przesyajc opcj CCecho. t a o _m s s o p t zawiera ostatni warto MSS otrzyman od danego hosta.
3. Trzy nowe zmienne zostay dodane do istniejcego bloku kontrolnego TCP: cc_send, cc _ r e c v i t_durati on. Pierwsza z tych zmiennych zawiera warto CC, ktra ma by wysana w kadym segmencie danego poczenia. Druga zmienna zawiera warto CC, ktra powinna by otrzymana od partnera w kadym segmencie. Ostatnia z tych zmiennych, t_duration, podaje czas
36
Protok TfTCP
Rozdzia 2
trwania poczenia (mierzone w impulsach zegara). W momencie gdy pocze nie zostaje aktywnie zamknite, jeli ten licznik impulsw zegara ma warto mniejsz ni MSL, czas trwania stanu TIME_WAIT ulega zmniejszeniu. Do kadniej omawiamy to zagadnienie w rozdziale 4.4. Wymienione zmienne moemy przedstawi tak, jak to zostao pokazane na rysunku 2.5. Zakadamy, e uywana jest implementacja opisana w nastpnych rozdziaach.
tcp ccgen:
routo{}
r o u t e {}
tao_cc tao_ccsent tao_mssopt
tao_cc tao_ccsent tao_mssopt
> dla kadego hosta
tcpcbf)
tcpcb(}
tcpcb{)
cc_send cc_recv t_duration
cc_send cc_recv t duration
cc_send cc_recv t_duration
>
dla kadego poczenia
Rysunek 2.5
Na rysunku para nawiasw klamrowych {} oznacza struktur. Pokazujemy blok kontrolny jako struktur tcpcb. Dowolna implementacja TCP musi dla kadego poczenia posiada blok kontrolny zawierajcy wszystkie przedstawione zmienne.
2.4
Diagram zmiany stanw
Dziaanie TCP moe by przedstawione w formie diagramu zmiany stanw, tak jak to pokazano na rysunku 2.6. Na wikszoci diagramw zmiany stanw (na przykad diagramy w tomie 1 i 2) na linii symbolizujcej zmian stanu zaznacza si nazwy przesyanych segmentw. Na przykad zmiana stanu z CLOSED do SYN_SENT oznaczaaby wysanie segmentu SYN. Na rysunku 2.6 rezygnujemy z tej notacji, w zamian w kadym prostokcie reprezentujcym stan zaznaczamy typ segmentw wysyanych w tym stanie. Na przykad w stanie SYN_RCVD wysyany jest segment SYN wraz z potwierdzeniem otrzymanego SYN. W stanie CLOSE_WAIT wysyane jest potwierdzenie otrzymanego segmentu FIN.
Sekcja 2.4 ________________________ Diagram zmiany stanw _______________________________ 37
pocztek
f
[
SYN RCVD
SYN, AK(SYN)
"1
otrzym. SYN
otwarcie jednoczesne
N
SYN SENT
SYN
zamknicie
lub przekr.
aplikacja: zamknicie
jednoczesne zamknicie FIN WAIT_1

FIN, ACK otrzym.: FIN r ^
CLOSING
FIN, ACK(FIN)
'l
J
pasywne zamknicie
otrzym.: ACK(FIN)
otrzym.: ACK (FIN)
otrzym.: ACK (FIN)
FIN WAIT_2
ACK
otrzym.: FIN
TIME WAIT
ACK (FIN)
upyn czas 2MSL aktywne zamknicie

-------- -------- aplikacja: otrzym.: zwykle zmiany stanu dla klienta zwykle zmiany stanu dla serwera zmiany stanu, gdy aplikacja inicjuje operacj zmiany stanu po odebraniu segmentu
Rysunek 2.6
Diagram zmiany stanio TCP
38
Protok T/TCP
Rozdzia 2
Wprowadzilimy t modyfikacj diagramu, poniewa T /T C P czsto przetwarza segment, ktry powoduje wicej ni jedn zmian stanu. Istotny jest wic ostatecz ny stan poczenia po przetworzeniu danego segmentu - to ostateczny stan po czenia okrela, jaka jest wysyana odpowied. Bez T /T C P kady otrzymany seg ment powoduje co najwyej jedn zmian stanu. Wyjtek stanowi segment FIN /A C K , ktry opiszemy pokrtce niej. Jest kilka rnic pomidzy rysunkiem 2.6, a diagramami TCP pokazanymi w RFC 793 [Postel 1981b]. RFC 793 pokazuje zmian stanu z LISTEN do SYN_SENT w momencie, gdy aplikacja wysya dane. To uatwienie jest rzadko udostpniane przez typowe interfejsy API. RFC 1122 [ Braden 1989] opisuje przejcie bezporednio ze stanu FIN_WAIT_1 do TIME_WAIT, po otrzymaniu segmentu FIN i potwierdzeniu wysanego segmentu FIN. Jednake w przypadku otrzymania segmentu z takimi flagami (co jest typowe), flaga ACK jest przetwarzana najpierw, powodujc przejcie do stanu FIN_WAIT_2, a dopiero potem przetwarzana jest flaga FIN, powodu jca przejcie do stanu TIME_WAIT. Wida wic, e taki segment na rysunku 2.6 zosta opisany poprawnie. Jest to przykad pojedynczego segmentu powo dujcego dwie zmiany stanu. We wszystkich stanach, z wyjtkiem stanu SYN_SENT, wysyana jest flaga ACK. Dzieje si tak dlatego, e przesanie ACK nic nie kosztuje: w stan dardow ym nagwku TCP jest zawsze miejsce na potwierdzenie. Dlatego TCP zawsze potwierdza najwyszy otrzymany numer sekwencyjny (plus jeden), z wyjtkiem potwierdzenia segmentu SYN odpowiadajcego aktywnemu otwarciu (SYN_SENT) i z wyjtkiem potwierdzenia niektrych segmentw RST.
Kolejno przetwarzania danych wejciowych w TCP

Kolejno, w jakiej TCP musi przetwarza poszczeglne elementy informacji otrzymanej w danym segmencie (flagi SYN, FIN, ACK, URG i RST, ewentualnie dane i opcje), nie jest przypadkowa, lecz z gry ustalona i nie zaley od implemen tacji. Kolejno ta okrelona zostaa szczegowo w RFC 793. Jest to rwnie zwile zademonstrowane na rysunku 11.1, gdzie uwypuklono zmiany wprowa dzone w T/T C P. Na przykad, jeli klient T /T C P otrzymuje segment z flag SYN, danymi oraz flagami FIN i ACK, flaga SYN zostaje przetworzona najpierw (poniewa gniazdo jest w stanie SYN_SENT), a nastpnie przetwarzane s: flaga ACK, dane i na kocu flaga FIN. Kada z tych trzech flag moe spowodowa zmian stanu gniazda.
2.5
Stany rozszerzone T/TCP
Protok T /T C P definiuje siedem stanw okrelanych jako stany rozszerzone ( e x t e n de d s ta t e s) , zwane rwnie stanami z gwiazdk (s t a r r e d s t a t e s ). S to:
Sekcja 2.5
Stany rozszerzone T/TCP
39
SYN_SENT*, SYN_RCVD*, ESTABLISHED*, CLOSE_WAIT*, LAST_ACK*, FIN_WAIT_1* i CLOSING*. Na przykad na rysunku 1.12 klient wysya inicjujcy segment zawierajcy SYN, dane i FIN. Wysanie tego segmentu jako czci aktyw nego otwarcia wprowadza klienta w stan SYN_SENT*, a nie w zwyky stan SYN_SENT, poniewa flaga FIN musi by wysana. Wielokrotne zmiany stanw zachodz w momencie, gdy nadejdzie odpowied serwera zawierajca SYN, dane, FIN oraz flag ACK potwierdzajc SYN, dane i FIN wysane wczeniej przez klienta. Flaga ACK, potwierdzajc SYN wysany przez klienta, wprowadza poczenie w stan FIN_WAIT_1. Stan jest cakowicie pominity, poniewa klient wysa ju FIN. Flaga ACK potwierdzajca flag FIN wysan przez klienta wprowadza po czenie w stan FIN_WAIT_2. Otrzymanie wysanej przez serwera flagi FIN wprowadza poczenie w stan TIME_WAIT. W RFC 1379 szczegowo omwiony zosta diagram zmiany stanw, na ktrym uwzgldniono wszystkie stany oznaczone gwiazdk. Diagram taki zawiera jednak wiele pokrywajcych si linii i jest duo bardziej skomplikowany ni diagram przedstawiony na rysunku 2.6. Na szczcie zwizek midzy stanami z gwiazdk a stanami bez gwiazdki jest prosty. Dwa stany: SYN_SENT* i SYN_RCVD* s identyczne z odpowiednimi stanami bez gwiazdki, z dokadnoci do tego, e flaga FIN musi by wysana. To znaczy poczenie znajduje si w jednym z tych dwch stanw, gdy zostaje utworzony aktywny punkt kocowy i aplikacja generuje komunikat MSG_EOF (wysya FIN) zanim poczenie zostanie ustanowione. Normalnym stanem klienta w tym scenariuszu jest SYN_SENT*. Rzadko wystpujcy stan SYN_RCVD* pojawia si, gdy nastpuje jednoczesne otwarcie, co omawiamy w szczegach w rozdziale 18.8 tomu 1. Stany ESTABLISHED*, CLOSE_WAIT*, LAST_ACK*, FIN_WAIT_1* i CLO SING* s identyczne z odpowiednimi stanami bez gwiazdki, z dokadnoci do tego, e flaga SYN musi by wysana. Poczenie w jednym z tych piciu stanw okrela si mianem poczenia poowicznie zsynchronizowanego {hal f - s y n ch ron ized). Poczenie znajduje si w jednym z tych stanw, jeli host wyko nuje pasywne zamknicie i otrzymuje segment SYN, ktry pomylnie przecho dzi test TAO. Wraz z tym segmentem opcjonalnie przesane s dane i flaga FIN. (Test TAO opisany jest szczegowo w rozdziale 4.5.) Uywa si okrelenia poowicznie zsynchronizowane, poniewa host otrzymujcy SYN uwaa, e po czenie jest ustanowione (skoro test TAO daje pozytywny wynik), mimo e zwyke potrjne uzgodnienie zostao zrealizowane tylko w poowie. Rysunek 2.7 przedstawia stany z gwiazdk oraz wszystkie pozostae zwyke sta ny. Dla kadego stanu w tabeli podany zosta rodzaj wysyanego segmentu.
40
Protok T/TCP
Rozdzia 2
Zwyky stan
Okrelenie
Wysyane
Stan z gwiazdk
Wysyane
CLOSED LISTEN SYN _SEN T SYN_RCVD ESTA BU SH ED CLO SE_W AIT FIN_WAIT_1 CLOSING LAST_ACK FIN_WAIT_2 TIME_WAIT
poczenie zamknite oczekiwanie na poczenie (pasywne otwarcie) wysano SYN (aktywne otwarcie) wysano i otrzymano SYN; oczekiwanie na ACK poczenie nawizane (przesyanie danych) otrzymano FIN, oczekiwanie na zamknicie aplikacji poczenie zostao zamknite, wysano FIN; oczekiwanie na ACK i FIN jednoczesne zamknicie; oczekiwanie na ACK otrzymany FIN zamkn poczenie; oczekiwanie na ACK zamknite poczenie; oczekiwanie na FIN oczekiwanie przez czas 2MSL po aktywnym zamkniciu
RST, ACK
SYN SYN, ACK ACK ACK FIN, ACK FIN, ACK FIN, ACK ACK ACK
SYN _SEN T SYN_RCVD* ESTABUSHED* CLOSE_W AIT* FIN_WAIT_1* CLOSING LAST_ACK*
SYN, FIN SYN, FIN, ACK SYN, ACK SYN, ACK SYN, FIN, ACK SYN, FIN, ACK SYN, FIN, ACK
Rysunek 2.7
Flagi wysyane przez TCP w zalenoci od aktualnego stanu (stany zwyke i rozszerzone)
Zobaczymy, e stany z gwiazdk nie stwarzaj trudnoci implementacyjnych. W zwizanym z kadym poczeniem bloku kontrolnym TCP, w uzupenieniu informacji dotyczcych stanw bez gwiazdek, umieszczane s dwie dodatkowe flagi:
T F_S E N D F I N pokazuje, e FIN ma by wysany (odpowiada SYN_SENT* i SYN_RCVD) TF_S EN D SYN pokazuje, e SYN m a by wysany (odpowiada piciu poowicz nie zsynchronizowanym stanom z gwiazdk, rysunek 2.7)
Na rysunku 2.7 uylimy pogrubionej czcionki do zaznaczenia flag SYN i FIN ustawianych w stanach z gwiazdk przez dwie nowe flagi.
2.6
Podsumowanie
Najwaniejszy element T /T C P to TAO, czyli aktywne otwarcie TCP. Ten mecha nizm pozwala serwerowi T /T C P stwierdzi, bez stosowania potrjnego uzgodnie nia, e otrzymany segment SYN jest nowy. Jednoznaczny identyfikator - licznik poczenia - jest przypisany kademu poczeniu, w ktrym uczestniczy dany host. Kady host T /T C P przechowuje przez pewien czas liczniki ostatnio nawi zanych pocze z kadym partnerem. Test TAO daje pozytywny rezultat, gdy otrzymany segment SYN m a warto licznika poczenia wiksz ni ostatnio uyta warto tego licznika dla danego partnera. T /T C P definiuje trzy nowe opcje: CC, CCnew i CCecho. Kada z tych opcji zawiera pole okrelajce dugo (podobnie jak wszystkie opcje zdefinowane przez RFC 1323), tak e implementacja, ktra danej opcji nie rozumie, moe tak opcj pomin. Jeli dane poczenie uywa T /TC P, to opcja CC obecna jest niemal
Sekcja 2.6
Podsumowanie
41
w kadym przesyanym segmencie. Jedynie czasami opcja CC zastpiona zostaje opcj CCnew w segmencie SYN wysanym przez klienta. W zwizku z T /T C P dodane s: jedna globalna zmienna jdra systemu, trzy nowe zmienne w tzw. pamici TAO tworzonej dla kadego hosta i trzy nowe zmienne w istniejcym dla kadego poczenia bloku TCP. Implementacja T /T C P , ktr opisujemy w tym tekcie, uywa jako pamici TAO istniejcej tablicy rutowania. T /T C P dodaje 7 dodatkowych stanw do 10 istniejcych w diagramie stanw TCP. Implementacja tych nowych stanw jest jednak prosta: dwie nowe flagi dla kadego poczenia okrelaj, czy flagi SYN i FIN powinny by wysane - i to wystarcza do zdefiniowania siedmiu nowych stanw, jako e s one tylko rozsze rzeniami stanw istniejcych.
T/TCP - przykady
3.1 Wstp
Przeledzimy teraz kilka przykadw zastosowania T /T C P , po to by dokadniej przeanalizowa uycie trzech nowych opcji. Przykady poka, jak protok T /T C P dziaa w nastpujcych sytuacjach: przeadowanie klienta normalna transakcja T /T C P serwer otrzymuje duplikat starego segmentu SYN przeadowanie serwera przetwarzanie dania lub odpowiedzi o dugoci wikszej ni MSS kompatybilno wstecz z systemami, ktre nie znaj T /T C P W nastpnym rozdziale rozwaamy dwa dodatkowe przykady: przypadek seg mentw SYN nie bdcych duplikatami, ale przybywajcych do serwera w niepra widowej kolejnoci oraz przetwarzanie przez klienta zduplikowanych odpowie dzi SYN /A C K wysanych przez serwer. W przedstawionych przykadach klientem T /T C P jest host bsdi (rysunek 1.13), a serwerem - host laptop. Uywane s programy: klient z rysunku 1.10 i serwer z rysunku 1.11. Klient wysya 300-bajtowe dania, a odpowied serwera ma 400 bajtw. Klient w omawianych przykadach dziaa z pominiciem rozszerze protokou opisanych w RFC 1323. Zapobiega to wysyaniu przez klienta opcji skali okna i znacznika czasu w inicjujcym segmencie SYN. (Poniewa klient nie wysya tych opcji, odpowied serwera rwnie nie bdzie ich zawieraa, nie m a wic znacze nia, czy serwer stosuje si do RFC 1323, czy nie.) W ten sposb unikamy kompliko wania przykadw czynnikami, ktre nie maj wpywu na nasz dyskusj o T /T C P . W normalnych warunkach rozszerzenia opisane w RFC 1323 byyby uywane wraz z T /T C P , poniewa opcja znacznika czasu daje dodatkow ochro n przed zinterpretowaniem starych zduplikowanych segmentw jako czci ist niejcego poczenia. Oznacza to, e nawet z uyciem T /T C P zabezpieczenie PAWS (protection against zorapped seuence numbers - zabezpieczenie przed zawi nitymi" numerami sekwencyjnymi, patrz te rozdzia 24.6 w tomie 1) jest nie zbdne w przypadku szerokopasmowych pocze, przez ktre przesyane s due iloci danych.
44
T/TCP - przykady
Rozdzia 3
3.2
Przeadowanie klienta
Rozpoczynamy nasz sekwencj transakcji klient-serwer bezporednio po przea dowaniu klienta. W momencie gdy aplikacja klienta wysya sendto, pojawia si zapis w tablicy rutowania dotyczcy serwera, z wartoci ta o _ c c s e n t ustawion na 0 (niezdefiniowana). TCP wysya wic opcj CCnew zamiast opcji CC. Serwer otrzymuje opcj CCnew i to powoduje, e protok TCP serwera przeprowadza zwyke potrjne uzgodnienie, tak jak to wida na wydruku z programu Tcpdump na rysunku 3.1. (Czytelnicy nie znajcy programu Tcpdump i wydruku z tego programu powinni zapozna si z dodatkiem A tomu 1.) Analizujc wydruk z programu Tcpdump, nie naley zapomina, e flagi SYN i FIN zuywaj po jednym bajcie w polu numeru sekwencyjnego.
1
2 0.0 0.020542 b s d i . 1 0 2 4 > l a p t o p . 8888: SFP 3 6 8 5 8 8 2 5 : 3 6 8 5 9 1 2 5 ( 3 0 0 ) win 8568 <mss 1460,nop.nop.ccnew 1> (0.0205) l a p t o p . 8 8 88 > bs d i. 10 24 : S 76355292:76355292(0) ac k 3 6 8 5 8 8 2 6 w in 8712 <mss 1 4 6 0 . n o p . n o p , c c 18, n o p . n o p , c c e c h o 1>
3 0.029471 5 0.042086
0 . 0 2 1 4 7 9 (0.0009) b s d i . 1 0 2 4 > l a p t o p . 8888: F 3 01 : 30 1 ( 0 ) a ck 1 w in 8712 < n o p , n o p , c c 1> (0.0080) l a p t o p . 8 88 8 > bsdi.1 02 4: ack 302 win 8412 <nop,nop,cc 18> (0.0126) l a p t o p . 88 88 > b sd i .1 02 4: FP 1 : 40 1( 4 0 0 ) ack 302 win 8712 <nop,nop,cc 18> . ack 402 win 8312 < no p.nop,cc 1>
0 . 0 4 2 9 6 9 (0.0 009) b s d i . 1 0 2 4 > l a p t o p . 8888:
Rysunek 3.1 Po przeadowaniu klient przeprowadza transakcj z senoerem Opcja CCnew w linii 1 pokazuje, e tcp_ccgen wynosi 1. W linii 2 serwer powtarza otrzyman warto CCnew i warto zmiennej tcp_ccgen serwera jest rwna 18. Serwer potwierdza (ACK) otrzymanie od klienta flagi SYN, ale nie potwierdza otrzy mania danych. Poniewa serwer otrzyma flag CCnew od klienta, musi on wykona zwyke potrjne uzgodnienie, nawet jeli w pamici TAO serwera znajduje si wpis dla danego klienta. Protok TCP serwera nie moe przesa 300 bajtw danych do dalszego przetwarzania, dopki potrjne uzgodnienie nie zostanie zakoczone. W linii 3 znajdujemy ostatni segment potrjnego uzgodnienia: potwierdzenie flagi SYN wysanej przez serwera. Klient ponownie wysya FIN, ale nie wysya powtr nie 300 bajtw danych. W momencie, gdy serwer otrzyma ten segment, natych miast potwierdza otrzymanie danych i flagi FIN, co wida w linii 4. Flaga ACK wysyana jest natychmiast, po to by unikn wyczerpania si czasu oczekiwania klienta na potwierdzenie wysania danych w linii 1. Linia 5 jest potwierdzeniem odpowiedzi serwera i jednoczenie otrzymanej przez klienta flagi FIN. W linii 6 klient potwierdza otrzymanie obu tych potwierdze. Zauwamy, e linie 3 ,4 ,5 i 6 zawieraj opcj CC. Opcje CCnew i CCecho pojawiaj si odpowiednio tylko w pierwszym i drugim segmencie.
Sekcja 3.2
Przeadowanie klienta
45
Poczwszy od tego miejsca nie bdziemy jawnie wymienia rozkazw pustych (NOP) w segmentach T /T C P , poniewa flagi te nie s niezbdne i tylko komplikuj nasz prezentacj. Opcje, ktrych dugo nie jest wielokrotnoci 4 bajtw, s uzupenia ne rozkazami NOP, tak by kada opcja zawieraa si w naturalnych czterobajtowych granicach. Wnikliwy Czytelnik zauway, e pocztkowy num er sekwencyjny (ISN) uyty przez klienta TCP bezporednio po przeadowaniu nie jest zgodny ze zwykym w zorcem omawianym w wiczeniu 18.1 w tomie 1. W idzimy te, e pocztkowy num er sekwencyj ny uyty przez serwera jest liczb parzyst, co w normalnej sytuacji nigdy si nie zdarza w implementacjach opartych na systemie Berkeley. M amy tu do czynienia z sytuacj, w ktrej pocztkowy numer sekwencyjny jest liczb wygenerowan losowo. Podobnie losowo generowana jest warto dodawana do ISN jdra po kadych 500 ms. Zwiksza to moliwo zabezpieczenia si przed prbami przechwycenia pakietw, tak jak to zostao opisane w pracy [Bellovin 1989]. Ta modyfikacja zostaa wprowadzona do systemu BSD/OS 2.0 a nastpnie do systemu 4.4BSD-Lite2, po szeroko znanym internetowym wamaniu w grudniu 1994 r. [Shimomura 1995].
Diagramy zalenoci czasowych

Na rysunku 3.2 przedstawiono diagram zalenoci czasowych odpowiadajcy wymianie segmentw z rysunku 3.1.
bsdi.1024 laptop1.8888
SYN_SENT* 1
<mss 14bo, ccnew 1> SYN 75355292:76355292(0)
SYN_RCVD
2 ESTABLISHED, CLOSE_WAIT
FIN_WAIT_1 3
ack 36856826, <mss 1460, ec 18 ccecho1>
---------- ? o t a o i( o )
a< * T < c e 7 r ack302,<cc18>
FIN_WAIT_2
-------------
FIN. PSH TIME_WAIT 6
-------------------------
5 LAST_ACK
-------- -
ack 302, <1B> ack402, <ec1> CLOSED
Rysunek 3.2
Zalenoci czasowe dla wymiany pakietw z rysunku 3.1
Dwa segmenty zawierajce dane oznaczamy pogrubionymi liniami (segmenty 1 i 5). Zaznaczamy rwnie zmian stanu zwizan z otrzymaniem kadego seg mentu. Klient znajduje si pocztkowo w stanie SYN_SENT*. Wynika to z faktu,
46
T/TCP - przykady
Rozdzia 3
e klient wywouje sen d t o z flag MSG_E0F. Gdy serwer przetwarza segment 3, nastpuj dwie zmiany stanu. Najpierw flaga ACK potwierdzajca otrzymanie flagi SYN wysanej przez serwera wprowadza poczenie w stan ESTABLISHED. Nastpnie flaga FIN zmienia stan poczenia na CLOSE_WAIT. Kiedy serwer wysya odpowied uywajc flagi MSG_EOF, poczenie po stronie serwera wchodzi w stan LAST_ACK. Zauwamy rwnie, e klient po raz drugi wysya flag FIN w segmencie 3 (przypominamy rysunek 2.7).
3.3
Normalna transakcja T/TCP
W nastpnym kroku inicjujemy kolejn transakcj pomidzy klientem i serwerem. Tym razem klient znajduje niezerow warto zmiennej t a o _ c c s e n t w pamici TAO dla danego serwera. Wysya wic opcj CC z nastpn wartoci zmiennej t c p_c c ge n rwn 2. (Jest to drugie od przeadowania poczenie T /T C P nawiza ne przez klienta.) Wymiana segmentw pokazana zostaa na rysunku 3.3.
1 2 0.0 0.026469 (0.0265) b s d i .1025 > l a p t o p . 8888: SFP 4 0 2 0 3 4 9 0 : 4 0 2 0 3 7 9 0 ( 3 0 0 ) w in 8712 <mss 1 4 6 0 , cc 2>
laptop.8888 > b s d i . 1025: SFP 7 95 78 8 38:79579238(400) ack 4 0 2 0 3 7 9 2 w i n 87 12 <mss 1 4 6 0 , cc 1 9 . c c e c h o 2> ack 402 w in 83 12 <cc 2>
0 . 0 2 7 5 7 3 (0.0011) b s d i . 1025 > l a p t o p . 8888: .
Rysunek 3.3 Normalna transakcja klient-serwer T/TCP Jest to normalna, minimalna wymiana T /T C P, w ramach ktrej przesane s trzy segmenty. Na rysunku 3.4 przedstawiony zosta diagram czasowy tej wymiany, z zaznaczonymi zmianami stanw.
bsdi.1025
wm MU, <mss 1460, c c 2 >
laptop,888B
ESTABUSHED*, CLOSE_WAIT*
SYN_SENT* 1
------------- --
2 LAST_ACK* FIN WAIT 1, FIN WAIT 2, TIME WAIT
* 3
i S
3 ----------- --------ggj[4Q 2. win 6312 <cc2> LAST ACK, CLOSED
Rysunek 3 A
Zalenoci czasowe dla wymiany segmentw z rysunku 3.3
Sekcja 3.4
Serwer otrzymuje duplikat starego segmentu SYN
47
Klient wchodzi w stan SYN_SENT* w momencie, gdy wysya SYN, dane i FIN. Gdy serwer otrzymuje ten segment i test TAO daje pozytywny wynik, serwer wchodzi w stan ESTABLISHED*. Dane s przetworzone i przesane do procesu serwera. W dalszej kolejnoci, w czasie przetwarzania tego segmentu, napotkana zostaje flaga FIN, co powoduje zmian stanu poczenia na CLOSE_WAIT*. Ser wer znajduje si w stanie z gwiazdk, poniewa flaga SYN cigle jeszcze musi by wysana. Kiedy serwer wysya swoj odpowied i proces specyfikuje flag M S G _ E 0 F poczenie po stronie serwera wchodzi w stan LAST_ACK*. Tak jak pokazano na rysunku 2.7, segment wysany w tym stanie zawiera flagi SYN, FIN i ACK. Kiedy klient otrzymuje segment 2, potwierdzenie (ACK) wysanej przez klienta flagi SYN wprowadza poczenie w stan FIN_WAIT_1. W dalszej kolejnoci w trakcie przetwarzania tego segmentu znalezione jest potwierdzenie flagi FIN wysanej przez klienta, co zmienia stan poczenia na FIN_WAIT_2. Odpowied serwera zostaje przekazana do procesu klienta. Ostatnim etapem przetwarzania cigle tego samego segmentu jest znalezienie flagi FIN i zwizana z tym zmiana stanu poczenia na TIME_WAIT. Klient wysya odpowied zawierajc ACK. Kiedy serwer otrzymuje segment 3, flaga ACK potwierdzajca SYN wysany przez serwera wprowadza poczenie w stan CLOSED. Przedstawiony przykad jasno pokazuje, e w trakcie przetwarzania jednego otrzymanego segmentu nastpuj liczne kolejne zmiany stanu. Pokazalimy te, e proces moe otrzyma dane w stanie innym ni ESTABLISHED. Zdarza si to, gdy klient otrzymuje dane w stanie FIN_WAIT_1 (segment 2), po poowicznym zamkniciu poczenia (segment 1).
3.4
Serwer otrzymuje duplikat starego segmentu SYN
Co si dzieje, gdy serwer otrzymuje segment z wartoci CC odpowiadajc wczeniejszemu poczeniu z klientem? Zmuszamy klienta do wysania segmentu SYN z wartocia CC rwn 1, ktra jest mniejsza od najnowszej wartoci CC otrzymanej przez serwera od tego klienta (warto 2, rysunek 3.3). Taka sytuacja moe nastpi, gdy segment z CC rwnym 1 pochodzi z wczeniejszego wcielenia tego samego poczenia i uleg pewnemu opnieniu w sieci, nie wikszemu jednak ni warto MSL obowizujca w momencie wysyania segmentu. Poczenie jest zdefiniowane przez par gniazd czyli zesp czterech elementw: numer IP i numer portu klienta oraz numer IP i numer portu serwera. Nowe realizacje tego samego poczenia (te same cztery elementy) nazywane s wciele niami (incamations) poczenia. Na rysunku 3.5 widzimy, e gdy serwer otrzymuje SYN z wartoci CC rwn 1, wymusza on przeprowadzenie potrjnego uzgodnienia, poniewa nie moe stwierdzi, czy otrzymany segment jest duplikatem starego segmentu, czy te nie.
48
T/TCP - przykady
Rozdzia 3
1 0.0
2 0.018391 (0.0184)
b s d i . 1027 > l a p t o p . 8888:
SFP 8 0 0 0 0 0 0 0 : 8 0 0 0 0 3 0 0 ( 3 0 0 ) w in 40 96 <mss 1 4 6 0 , cc 1>
l a p t o p . 8 8 8 8 > b s d i . 1027: S 1 3 2 4 9 2 3 5 0 : 1 3 2 4 9 2 3 5 0 ( 0 ) ack 8 0 0 0 0 0 0 1 win 8712 <mss 1 4 6 0 , cc 2 1 , c c e c h o 1> b s d i . 1027 > l a p t o p . 8888: R 80000001:80000001(0) win 0
3 0 . 0 1 9 2 6 6 (0.0009)
Rysunek 3.5 Serwer T/TCP otrzymuje od klienta duplikat starego segmentu SYN Poniewa m a miejsce potrjne uzgodnienie (co poznajemy po tym, e tylko flaga SYN jest potwierdzona, dane za nie), TCP serwera nie moe przekaza 300 bajtw danych do procesu serwera a do czasu potrjnego zakoczenia. W naszym przykadzie segment 1 jest duplikatem starego segmentu (TCP klienta nie oczekuje w tym momencie odpowiedzi na ten segment SYN) - tak wic gdy klient otrzymuje od serwera flagi SYN i ACK w segmencie 2, klient odpowiada wysaniem flagi RST (segment 3). To wanie powinno si zdarzy. Serwer po otrzymaniu RST kasuje 300 bajtw danych i nie zakacza odwoania do funkcji a c c e p t , na co czeka proces serwera.
Segment 1 zosta wygenerowany przez specjalny program sucy do testw. Nie jeste m y w stanie spowodowa, by klient T /T C P wygenerowa taki segment, chcemy nato miast, by segment ten wyglda jak duplikat starego segmentu. Autor prbowa sztucznie ustawi warto t c p _ c c g e n na 1, ale - jak widzimy to na rysunku 12.3 - jeli warto t c p _ c c g e n zawarta w jdrze jest mniejsza ni ostatnia warto CC wysana do danego hosta, TCP automatycznie wysya opcj CCnew, zamiast opcji CC.
Na rysunku 3.6 przedstawiona zostaa nastpna, normalna transakcja T /TC P. Zgodnie z oczekiwaniami transakcja ta obejmuje wymian trzech segmentw.
1 0.0 2 0 . 0 2 8 2 1 4 (0.0282)
b s d i . 102 6 > l a p t o p . 8888: SFP 1 0 1 6 1 9 8 4 4 : 1 0 1 6 2 0 1 4 4 ( 3 0 0 ) win 8 71 2 <mss 1 4 6 0 , cc 3> l a p t o p . 8 8 8 8 > b s d i . 1026: SFP 1 4 0 2 1 1 1 2 8 : 1 4 0 2 1 1 5 2 8 ( 4 0 0 ) ac k 1 0 1 6 2 0 1 4 6 w in 87 12 <m ss 1 4 6 0 , cc 2 2 , cc e c h o 3> bsdi .1026 > l a p t o p . 8888: . ac k 402 w in 83 1 2 <cc 3>
i 0 . 0 2 9 3 3 0 (0.0011)
Rysunek 3.6 Normalna transakcja klient-serwer T/TCP Serwer spodziewa si otrzyma opcj CC z wartoci wiksz ni 2, tak wic otrzymany segment SYN przechodzi test TAO z wynikiem pozytywnym.
3.5
Przeadowanie serwera
Przeadowujemy teraz serwer i klient rozpoczyna transakcj zaraz po przeadowa niu, bezporednio po ponownym uruchomieniu procesu odbierajcego serwera. Wymian segmentw pokazujemy na rysunku 3.7.
Sekcja 3.6
danie lub odpowied z dugoci wiksz ni M S S
49
1 0.0
2 0 . 0 2 5 4 2 0 (0.0254) 3 0.025872 (0.00 05)
bsdi .1027 > l a p t o p . 8888: SFP 1 4 6 5 1 3 0 8 9 : 1 4 6 5 1 3 3 8 9 ( 3 0 0 ) w in 8 71 2 <mss 1 4 6 0 , cc 4> arp w h o - h a s bsdi tell arp reply bsdi laptop
is- at 0 : 2 0 : a f : 9 c : e e : 9 5
4 0 . 0 3 3 7 3 1 (0.0079)
l a p t o p . 8 8 8 8 > b s d i . 1027: S 2 7 3 3 8 8 8 2 : 2 7 3 3 8 8 8 2 ( 0 ) ack 1 4 6 5 1 3 0 9 0 win 87 12 <mss 1 4 6 0 , cc l . c c e c h o 4> bsdi .1027 > l a p t o p . 8888: l a p t o p . 8 88 8 > b s d i . 1027: l a p t o p . 8 8 8 8 > b s d i . 1027: b s d i . 1027 > l a p t o p . 8888: F 301:301(0) ack 1 win 8 71 2 <cc 4> . ack 3 02 w i n 8 4 1 2 < cc 1> FP 1: 4 01 (4 00 ) ack 302 w i n 87 12 <cc 1> . ack 402 w i n 8 3 1 2 <cc 4>
5 0.034697
(0.00 10)
6 0 . 0 4 4 2 8 4 (0.0096)
7 0.066749 8 0.067613 (0.0225) (0.0009)
Rysunek 3.7 Wymiana pakietw T/TCP po przeadowaniu serwera Poniewa klient nie wie, e serwer zosta przeadowany, wysya on normalne danie T/TC P z wartoci CC rwn 4 (linia 1). Ze wzgldu na to, e serwer straci sprztowy adres klienta w czasie przeadowywania, serwer wysya danie A R P , na co klient reaguje wysaniem odpowiedzi ARP. Serwer wymusza zwyke potrjne uzgodnie nie (linia 4), nie zna bowiem wartoci CC ostatnio otrzymanej od tego klienta. Podobnie do sytuacji z rysunku 3.1, klient koczy potrjne uzgodnienie potwier dzeniem, ktre zawiera rwnie flag FEST - 300 bajtw danych nie zostaje wysa nych ponownie. Dane klienta s retransmitowane dopiero po upywie czasu oczeki wania klienta na retransmisj, co pokaemy na rysunku 3.11. Po otrzymaniu trzeciego segmentu serwer natychmiast potwierdza otrzymanie danych i segmentu FIN. Odpowied serwera (linia 7) zostaje potwierdzona przez klienta w linii 8. Po wymianie segmentw przedstawionej na rysunku 3.7 spodziewamy si, e nastpna transakcja pomidzy klientem i serwerem bedzie znowu wymian tylko trzech segmentw, tak jak to pokazujemy na rysunku 3.8.
1 0 .0 2 0 .0 3 4 8 5 1 (0.0349) b s d i . 10 28 > l a p t o p . 8888: SFP 1 5 2 2 1 3 0 6 1 : 1 5 2 2 1 3 3 6 1 ( 3 0 0 ) w i n 87 12 <mss 1 4 6 0 , cc 5> l a p t o p . 8 8 8 8 > b s d i . 1028: SFP 3 2 8 6 9 4 7 0 : 3 2 8 6 9 8 7 0 ( 4 0 0 ) ac k 1 5 2 2 1 3 3 6 3 w i n 87 12 <mss 1 4 6 0 , cc 2 , c c e c h o 5> bsdi .1028 > l a p t o p . 8888: . ac k 402 win 83 1 2 <cc 5>
3 0 . 0 3 5 9 5 5 (0.0011)
Rysunek 3.8 Normalna transakcja klient-serwer TCP
3.6
danie lub odpowied z dugoci wiksz ni MSS
We wszystkich naszych dotychczasowych przykadach klient wysya dane o du goci nie przekraczajcej MSS, i odpowied serwera te bya nie dusza ni MSS. Jeeli aplikacja klienta wysya wicej bajtw danych ni MSS i jeeli TCP klienta
50
T/TCP - przykady
Rozdzia 3
wie, e partner (serwer) potrafi obsuy T /T C P, dane s wysyane w kilku seg mentach. Poniewa warto MSS partnera jest przechowywana w zmiennej tao_m ssopt (rysunek 2.5), klient zna MSS serwera, ale nie zna wielkoci okna odbiorczego (receive ivindow) procesu partnera. (W rozdziaach 18.4 i 20.4 tomu 1 omawiane s odpowiednio MSS i rozmiar okna.) W przeciwiestwie do MSS, ktre jest zwykle stae dla danego hosta-partnera, rozmiar okna moe by zmie niony przez aplikacj, jeli aplikacja zmienia rozmiar bufora wejciowego zwiza nego z konkretnym gniazdem. Co wicej, nawet jeli partner powiadomi, e uy wa duego okna (powiedzmy 32 768 bajtw) i jeli MSS wynosi 512 bajtw, mog istnie porednie rutery, kre nie potrafi obsuy pocztkowej lawiny 64 seg mentw wysanych od klienta do serwera (tzn. powolny start nie powinien by pominity). T /T C P potrafi poradzi sobie z opisanymi problemami, z uwzgld nieniem nastpujcych dwch ogranicze: 1. T /T C P zakada, e pocztkowy rozmiar okna wynosi 4096 bajtw. W imple mentacji N e t/3 zmienn okrelajc, jak duo danych TCP moe wysa za jednym razem, jest snd_wnd. Pocztkowy rozmiar okna rwny 4096 bajtw ulegnie zmianie, gdy pierwszy segment z informacj o rozmiarze okna zostanie otrzymany od partnera. 2. T /T C P rozpoczyna poczenie w trybie powolnym - (slow start) powolny start tylko wtedy, gdy partner nie znajduje si w sieci lokalnej. Tryb powolny rozpo czcia poczenia jest stosowany, gdy zmienna s n d _ c w n d ma warto jeden, co oznacza jeden segment. Sposb sprawdzenia, czy partner znajduje si w sieci lokalnej przedstawiony zosta na rysunku 10.14 i opiera si na wykorzystaniu funkcji in_l ocal addr z jdra systemu. Partner jest uwaany za partnera lokalnego, gdy: (a) znajduje si w tej samej sieci i podsieci co dany host, (b) znajduje si w innej podsieci tej samej sieci, ale zmienna jdra s u b n e t s a r e l o cal m aniezerow w arto. Zwykle N e t/3 rozpoczyna kade poczenie w trybie powolnym (powolny start strona 940 tomu 2), ale to uniemoliwia klientowi biorcemu udzia w transakcji wysanie wicej ni jednego segmentu jako pocztku transakcji. W prowadza si wic kompromis polegajcy na dopuszczeniu wysania wielu segmentw w przy padku lokalnego partnera. Cakowity rozmiar danych w tym przypadku nie moe przekroczy 4096 bajtw. Kiedykolwiek TCP otrzymuje polecenie wysania danych, rozmiar wysyanych danych (liczbabajtw) jest okrelony przez mniejsz z dwch zmiennych sn d _ w n d i snd_cwnd. Pocztkowa warto pierwszej z tych zmiennych jest rwna maksy malnej wartoci informacji TCP o rozmiarze okna - zakadamy, e wynosi ona 65 535. (W rzeczywistoci warto ta moe wynosi 65 535x214, czyli niemal 1 GB, w przypadku gdy uywana jest opcja skali okna.) Dla lokalnego partnera poczt kowa warto s n d _ w n d wynosi 4096, a pocztkowa warto s n d _ c w n d 65 535. TCP bdzie wysya pocztkowo dane w porcjach po maksymalnie 4096 bajtw, a do momentu, gdy informacja o wielkoci okna zostanie otrzymana. Jeeli partner poinformowa, e wielko okna wynosi 32 768, TCP bdzie kontynuowa wysya
Sekcja 3.6
danie lub odpowied z dugoci wiksz ni M SS
51
nie danych a do wyczerpania tego nowego limitu (32 768 jest mniejsz z dwch wartoci: 65 535 i 32 768). Uniknito w ten sposb startu w trybie powolnym i dugo przesyanych danych jest ograniczona przez wielko okna zadeklaro wan przez partnera. Natomiast gdy partner nie jest hostem lokalnym, pocztkowa warto s n d _ w n d bdzie nadal wynosi 4096, ale pocztkowa warto s n d _ c w n d wyniesie 1, co oznacza jeden segment (zakadamy, e warto MSS zapamitana dla tego partne ra wynosi 512). TCP pocztkowo wyle tylko jeden segment, a kiedy partner poinformuje o wielkoci okna, warto s n d _ c w n d zwikszona zostanie o jeden segment dla kadej otrzymanej flagi ACK. Mamy tu do czynienia z kontrolowa nym powolnym startem i ilo przesyanych danych jest ograniczona przez ewen tualne przecienie sieci, chyba e zostanie przekroczony rozmiar okna partnera. Jako przykad zmodyfikowalimy kod klienta i serwera T /T C P z rozdziau 1, tak by wysane zostao danie o dugoci 3300 bajtw i odpowied o dugoci 3400 bajtw. Nastpia wymiana pakietw, ktr prezentujemy na rysunku 3.9.
I 0.0
2 0 . 0 0 1 5 5 6 (0.0016) b s d i . 1057 > l a p t o p . 8888 b s d i . 1057 > laptop. b s d i . 1057 > laptop. laptop S 3846892142:3846893590(1448) w i n 87 12 <m ss 1 4 6 0 , cc 7> . 3846893591:3846895043(1452) w in 8712 <cc 7> FP 3 8 4 6 8 9 5 0 4 3 : 3 8 4 6 8 9 5 4 4 3 ( 4 0 0 ) w in 8 71 2 <cc 7>
3 0 . 0 0 2 6 7 2 (0 .0011)
4 0.138283 5 0.139273 (0.1356) (0.0010)
> b s d i . 1057: S 3 7 8 6 1 7 0 0 3 1 : 3 7 8 6 1 7 0 0 3 1 ( 0 ) ack 3 8 4 6 8 9 5 4 4 4 win 8 71 2 <mss 1 4 6 0 , cc 6 , c c e c h o 7> b s d i . 1057 > l a p t o p . 8888: ack 1 wi n 8 71 2 <cc 7> l a p t o p . 88 88 > b s d i . 1057: b s d i . 1057 > laptop. ac k 1453 win 72 6 0 <cc 7> l a p t o p . 88 8 8 > b s d i . 1057: b s d i . 1057 > laptop. ac k 2905 w i n 7 2 60 <cc 7> l a p t o p . 8 88 8 > b s d i . 1057: b s d i . 1057 > l a p t o p . 8888: FP 2 9 0 5 : 3 4 0 1 ( 4 9 6 ) ack 1 wi n 8712 <cc 6> . ack 3402 win 82 16 <cc 7> . 1453:2905(1452) ac k 1 wi n 8 7 12 <cc 6> . 1: 1 4 5 3 ( 1 4 5 2 ) ac k 1 w i n 87 12 <cc 6>
6 0 . 1 7 9 6 1 5 (0.0403)
7 0 . 1 8 0 5 5 8 (0. 0009)
8 0 . 2 0 9 6 2 1 (0.0291) 9 0 . 2 1 0 5 6 5 (0.0009)
10 0 . 2 2 3 8 2 2 (0.0 133)
11 0 . 2 2 4 7 1 9 (0.0009)
Rysunek 3.9 danie klienta o dugoci 3300 bajtw i 3400-bajtowa odpowied serwera
Przykad pokazuje bd w program ie Tcpdump, polegajcy na zym drukowaniu wzgld nych numerw sekwencyjnych w przypadku wym iany kilku segmentw T /T C P . Po twierdzenie w liniach 6, 8 i 10 powinno dotyczy numeru 3302, a nie 1.
Poniewa klient wie, e serwer potrafi obsuy T /T C P , klient moe natychmiast wysa maksymalnie do 4096 bajtw. Segmenty 1, 2 i 3 zostaj wysane w cigu pierwszych 2.6 ms. Pierwszy segment zawiera flag SYN, 1448 bajtw danych i 12 bajtw opcji TCP (opcje MSS i CC). Drugi segment nie zawiera adnych flag, zawiera natomiast 1452 bajty danych i 8 bajtw opcji TCP. Trzeci segment zawiera
52
T/TCP - przykady
Rozdzia 3
flagi FIN i PSH, pozostae 400 bajtw danych i 8 bajtw opcji TCP. Segment drugi jest szczeglny w tym sensie, e nie zawiera adnej z szeciu flag TCP, w tym flagi ACK. Zwykle flaga ACK jest obecna, z wyjtkiem aktywnego otwarcia wykony wanego przez klienta, zawierajcego flag SYN. (Klient nigdy nie wysya ACK zanim nie otrzyma segmentu od serwera.) Segment 4 zawiera SYN serwera i rwnie potwierdza wszystko, co klient dotych czas wysa: SYN, dane i FIN. Klient natychmiast potwierdza otrzymanie od serwera flagi SYN - segment 5. Segment 6 dociera do klienta 40 ms pniej i zawiera pierwsz cz odpowiedzi serwera. Segment ten jest natychmiast potwierdzony przez klienta. Ten sam scena riusz zostaje powtrzony dla segmentw 8-11. Ostatni segment wysany przez serwera (10) zawiera flag FIN. Na kocu (segment 11) klient potwierdza ostatni fragment danych i flag FIN. Moemy zapyta, dlaczego klient natychmiast potwierdza dwa pierwsze z trzech segmentw odpowiedzi serwera, skoro s one odebrane w krtkim odstpie czasu (44 ms)? Odpowied jest zawarta w makroinstrukcji T C P _ R E A S S (strona 947, tom 2), wywoywanej dla kadego segmentu danych otrzymanych przez klienta. Po niewa poczenie po stronie klienta po przetworzeniu segmentu 4 wchodzi w stan FIN_WAIT_2 , sprawdzenie w T C P _ R E A S S czy poczenie jest w stanie ESTABLISHED daje wynik negatywny, powodujc wysanie natychmiastowego potwierdzenia, zamiast potwierdzenia opnionego. Ta waciwo nie jest szcze gln cech T /T C P - tak zachowuje si kod N e t/3 zawsze, gdy poczenie TCP zostaje poowicznie zamknite z jednej strony i wchodzi w stan FIN_WAIT_1 lub FIN_WAIT_2. Od tego momentu kady segment z danymi otrzymany od partnera jest natychmiast potwierdzany. Sprawdzenie, czy poczenie jest w stanie ESTAB LISHED w makroinstrukcji T C P _ R E A S S zapobiega przekazaniu danych do aplika cji zanim potrjne uzgodnienie jest zakoczone. Nie ma potrzeby natychmiasto wego potwierdzania danych otrzymywanych sekwencyjnie, jeli poczenie jest w stanie nastpujcym po stanie ESTABLISHED (tzn. odpowiedni fragment T C P _ R E A S S powinien zosta zmieniony).
Opcja gniazda TCP_NOPUSH

Jeszcze jedna zmiana w kodzie rdowym klienta bya niezbdna, by przeprowa dzi opisany wyej przykad. Opcja gniazda T C P _ N O P U S H (nowa opcja wprowa dzona z T /T C P) zostaa wczona w nastpujcy sposb:
i nt n ; n = 1: if ( s e t s o c k o p t ( s o c k f d , IPPR0T 0 _T CP , TC P _N O P U S H , e r r _ s y s ( " T C P _ N 0 P U S H error"); (char *) & n , s i z e o f ( n ) ) < 0)
Przedstawione linie kodu zostay dodane po odwoaniu do funkcji socket na rysunku 1.10. Opcja ta ma za zadanie poinformowa TCP, e segment nie powi nien by wysany, jeeli jedynym powodem wysania segmentu jest oprnienie buforu wysyania.
Sekcja 3.6
danie lub odpowied z dugoci wiksz ni M SS
53
eby zrozumie potrzeb uruchomienia tej opcji gniazd, musimy przeledzi kro ki wykonywane przez jdro, po tym jak proces woa sendto z flag M S G _ E 0 F w celu wysania 3300-bajtowego dania. 1. Funkcja jdra s o sen d (rozdzia 16.7, tom 2) jest wywoana, by obsuy da nie wysyki. Funkcja ta umieszcza pierwsze 2048 bajtw w klastrze mbuf i wysya danie P RU_S E ND do protokou (TCP). 2. Funkcja t c p _ o u t p u t jest wywoana i - poniewa moe zosta wysany seg ment o penej wielkoci - pierwszych 1448 bajtw znajdujcych si w klastrze zostaje wysanych wraz z flag SYN. (W segmencie tym 12 bajtw zajtych jest przez opcje TCP.)
3. Poniewa 600 bajtw wci pozostaje w klastrze mbuf, tcp_o utp ut jest woa
na jeszcze raz. Mogoby si wydawa, e algorytm Nagle uniemoliwi wysa nie nastpnego segmentu, ale zauwamy (strona 886 tomu 2), e przy pierw szym wywoaniu t c p _ o u t p u t zmienna i dl e bya rwna 1. Zmienna ta nie zostaje obliczona ponownie po tym, jak wykonany jest skok do aga i n po wysaniu 1448-bajtowego segmentu. Dlatego program ostatecznie przechodzi do fragmentu pokazanego na rysunku 9.3 (unikanie wysyania gupich seg mentw - sender silly window avoidance). Warto i d 1 e jest 1 (czyli prawda"), a wysanie segmentu oprnioby wysykowy bufor gniazda, wic tym co de cyduje o wysaniu segmentu lub nie, jest aktualna warto flagi TF_N0PUSH. Przed wprowadzeniem tej flagi wraz z T/TCP, niepeny segment zostaby zawsze wysany, jeli tylko wysanie nie byoby zablokowane przez algorytm Nagle i jeli segment ten oprniby bufor wysykowy gniazda. Jeeli jednak aplikacja ustawi flag T F _ N 0 P U S H (przy pomocy nowej opcji gniazda TCP_NOPUSH), to TCP nie wyle danych z bufora wysykowego tylko po to, by oprni bufor. TCP pozwoli, by dane istniejce w buforze zostay poczone z danymi wprowadzony mi przy pomocy pniejszych operacji, tak by mc wysa wikszy segment. 4. Jeli flaga T F_N 0 P U S H jest ustawiona przez aplikacj, segment nie zostaje wysa ny, a t c p _ o u t p u t zwraca kontrol do sosend.
5. Jeli flaga T F _ N 0 P U S H nie jest ustawiona przez aplikaq', 600-bajtowy segment
zostaje wysany i ustawiona jest flaga PSH. 6. Funkcja sosend wprowadza pozostae 1252 bajty do klastra mbuf i generuje danie P RU_S E N D_E0 F (rysunek 5.2), ktre znowu doprowadza do wywoania tcp_output. Jednak przed tym wywoaniem t c p _ o u t p u t zostaje wywoana funkcja t c p_u s r c 1 o s e d (rysunek 12.4), co powoduje zmian stanu poczenia z SYN _SENTnaSYN_SENP (rysunek 12.5). Przy ustawionej fladze T F _ N 0 P U S H 1852 bajty danych znajduj si w buforze wysykowym gniazda i - jak widzimy na rysunku 3.9 - kolejny segment o normalnej (penej) wielkoci, zawierajcy 1452 bajty danych i 8 bajtw opcji TCP, zostaje wysany. Segment ten zostaje wysany, poniewa jest to segment o normalnej dugoci (tzn. algorytm Nagle nie daje adnego efektu). Mimo e wrd flag wysyanych w stanie SYN_SENT* znajduje si flaga FIN (rysunek 2.7), flaga FIN jest wyczona
54
T/TCP - przykady
Rozdzia 3
(strona 889, tom 2), poniewa w dalszym cigu dane znajduj si w buforze wysykowym. 7. Funkq'a t c p _ o u t p u t jest wykonywana kolejny raz w celu wysania 400 bajtw pozostajcych w buforze wysykowym. Tym razem flaga FIN zostaje ustawio na, poniewa bufor wysykowy jest oprniany. Mimo e algorytm Nagle zapobiega wysaniu segmentu o niepenej dugoci, 400-bajtowy segment zo staje wysany, bowiem ustawiona jest flaga FIN (strona 895, tom 2). W przedstawionym przykadzie 3300-bajtowe danie w sieci Ethernet - z w arto ci MSS rwn 1460, przy ustawionej opcji gniazda - powoduje wysanie trzech segmentw zawierajcych 1448,1452 i 400 bajtw. W przypadku gdy opcja nie jest ustawiona, wysane s rwnie trzy segmenty liczce 1448, 600 i 1252 bajty. Dla 3600-bajtowego dania, w przypadku z opcj, zostan wysane trzy segmenty (1448,1452 i 700 bajtw). Bez opcji wysane bd cztery segmenty (1448, 600,1452 i 100 bajtw). Podsumowujc, jeeli klient wysya danie przy pomocy pojedynczego sendto. powinien zwykle ustawi opcj gniazda T C P _ N O P U S H by spowodowa wysyanie segmentw o normalnej, penej dugoci, jeeli dugo dania przekracza limit okrelony przez MSS. W ten sposb moe by zredukowana liczba wysyanych segmentw, w zalenoci od rozmiaru wysyanych danych.
3.7
Kompatybilno wstecz
Musimy si rwnie zastanowi, co si zdarzy, gdy klient T /T C P wyle dane do hosta, ktry nie zna T/TC P. Na rysunku 3.10 przedstawiamy wymian pakietw - transakcj - pomidzy klientem T/TC P (bsdi), a serwerem svr4. Host svr4 dziaa pod systemem System V Release 4, ktry nie obsuguje T/TC P.
2 0.0 2 0.006265 (0.0063) (0.0008) b s d i . 1031 > svr4.88 88 : SFP 2 6 7 2 1 1 4 3 2 1 : 2 6 7 2 1 1 4 6 2 1 (300) win 8 5 6 8 <mss 1 4 6 0 , c c n e w 10>
s v r 4 . 8 8 8 8 > b s d i . 1031: S 8 7 9 9 3 0 8 8 1 : 8 7 9 9 3 0 8 8 1 ( 0 ) ac k 2 6 7 2 1 1 4 3 2 2 win 4096 <mss 1024> bsdi .1031 > svr4.8888: F 301:301(0) ack 1 w in 9216 . ack 302 w in 3796 P 1 :4 01 ( 40 0) ack 302 w i n 40 96 . ack 401 w i n 88 16 F 40 1: 4 0 1 ( 0 ) ack 302 w i n 40 96 . ack 402 w in 9216
3 0.007108
4 0.012279 5 0.071683
(0.0052) s v r 4 . 8 8 8 8 > b s d i . 1031: (0.0 594) s v r 4 . 8 8 8 8 > b s d i . 1031: (0 .0008) b s d i . 1031 > svr4.8 88 8 : (0.0059) s v r 4 . 8 8 8 8 > b s d i . 1031: (0.0013) b s d i . 1031 > svr4.8 88 8 :
6 0.072451
7 0.078373
8 0.079642
Rysunek 3.10 Transakcja klienta T/TCP z serwerem TCP
Sekcja 3.7
Kompatybilno wstecz
55
Klient jak zwykle wysya pierwszy segment zawierajcy SYN, FIN i flagi PSH, wraz z 300 bajtami danych. Wysyana jest opcja CCnew, poniewa klient nie ma zachowanej wartoci numeru poczenia dla tego serwera. Serwer odpowiada wysyajc normalny, drugi segment potrjnego uzgodnienia (linia 2), ktry to segment klient potwierdza w linii 3. Zauwamy, e dane s retransmitowane w linii 3. Kiedy serwer otrzymuje segment z linii 3, natychmiast wysya potwierdzenie 300 bajtw danych i flagi FIN. (Potwierdzenie flagi FIN nigdy nie jest opnione, jak to pokazano na stronie 1033 tomu 2.) TCP serwera umiecio dane w kolejce a do czasu, gdy potrjne uzgodnienie zostanie zakoczone. Linia 5 jest odpowiedzi serwera (400 bajtw danych), ktr klient natychmiast potwierdza w linii 6. Linia 7 zawiera flag FIN serwera, ktr klient znw natych miast potwierdza. Zauwamy, e proces serwera nie ma adnej moliwoci po czenia danych z linii 5 z flag FIN z linii 7. Jeli zainicjujemy kolejn transakcj pomidzy tym samym klientem i serwerem, sekwencja przesyanych segmentw bdzie taka sama. Pierwszy segment wysany przez klienta zawiera opcj CCnew z wartoci 11, poniewa klient nie moe wysa opcji CC do tego hosta, jako e serwer nie przesa opcji CCecho (rysunek 3.10). Klient T /T C P zawsze wysya opcj CCnew, wpis w pamici TAO dla serwera nie znajcego T /T C P nigdy bowiem nie jest uaktualniany - warto t a o _ c c s e n t pozostaje zawsze 0 (niezdefiniowana). W nastpnym przykadzie (rysunek 3.11) klient rozpoczyna transakcj z serwerem dziaajcym pod systemem Solaris 2.4, ktry to system - cho oparty na SVR4 (tak jak serwer na rysunku 3.10) - ma zupenie inn implementacje TC P/IP.
1 0 .0
2 0 . 0 0 2 8 0 8 (0.0028) b s d i . 10 33 > s un.8880: SFP 2 6 9 3 8 1 4 1 0 7 : 2 6 9 3 8 1 4 4 0 7 ( 3 0 0 ) win 87 12 <mss 1 4 6 0 , c c n e w 12>
s u n . 8 8 8 8 > b s d i . 1033: S 3 1 7 9 0 4 0 7 6 8 : 3 1 7 9 0 4 0 7 6 8 ( 0 ) ack 2 6 9 3 8 1 4 1 0 8 wi n 8 7 60 <mss 1460> (DF) b s d i . 10 33 > s u n .8 88 8: b s d i . 10 33 > s un.8888: s u n . 8 8 8 8 > b s d i . 1033: s u n . 8 8 8 8 > b s d i . 1033: b s d i . 1033 > s un.8888: s u n . 8 8 8 8 > b s d i . 1033: b s d i . 1033 > sun.8 88 8 : F 3 01 : 30 1 ( 0 ) ack 1 w i n 8760 FP 1: 30 1( 3 00 ) ack 1 win 87 60 . ack 302 w in 8 76 0 (DF) P 1 :4 01 ( 40 0) ack 302 w in 87 60 (DF) . ack 401 w in 8 36 0 F 4 0 1: 40 1 ( 0 ) ack 302 w i n 8 7 6 0 (DF) . ack 402 w i n 8360
3 0 . 0 0 3 6 7 9 (0 .0009) 4 1.287379 (1.2837)
5 1 . 2 8 9 0 4 8 (0.0017) 6 1.291323 7 1 . 29 21 01 (0.0023) (0.0008)
8 1 . 2 9 2 3 6 7 (0 .0003) 9 1 . 2 9 3 1 5 1 (0.0008)
Rysunek 3.11 Transakcja klienta T/TCP z serwerem TCP dziaajcym w systemie Solaris 2.4
56
T/TCP - przykady
Rozdzia 3
Linie 1, 2 i 3 s takie same jak na rysunku 3.10: flagi SYN, FIN, PSH i 300-bajtowe danie klienta, nastpnie flagi SYN /A CK serwera, po ktrych nastpuje flaga ACK wysana przez klienta. Jest to zwyke potrjne uzgodnienie. Tak jak wcze niej, klient wysya opcj CCnew, poniewa nie ma zachowanej wartoci CC dla tego serwera.
Obecno flagi nie dzieli na fragm enty" (DF - don't fragment) w kadym segmencie pochodzcym od hosta Solaris jest zwizana z wyznaczeniem MTU cieki (path disccruery, RFC 1191 [Mogul i Deering 1990]).
Niestety, w tym momencie natykamy si na bd w implementacji systemu Solaris. Okazuje si, e TCP serwera ignoruje dane, ktre byy wysane w linii 1 (dane nie s potwierdzone w segmencie 2), co powoduje, e upywa czas oczekiwania klien ta na potwierdzenie i klient ponownie wysya dane w linii 4. Flaga FIN rwnie wysana jest ponownie. Serwer nastpnie potwierdza dane oraz FIN (linia 5) i serwer wysya odpowied (linia 6). Klient potwierdza odpowied (linia 7), ser wer wysya flag FIN (linia 8), ktr klient ostatecznie potwierdza (linia 9).
Na stronie 30 opracowania RFC 793 [Postel 1981b] znajduje si stwierdzenie: Cho w przedstawionych przykadach synchronizacja poczenia nie jest dokonywana za po rednictwem segmentw przenoszcych rwnie dane, taki przypadek byby cakowicie dopuszczalny, jeli tylko odbierajcy protok TCP nie dostarcza danych do procesu uytkownika zanim nie zostanie ustalone, e dane s poprawne (tzn. dane musz by buforowane przez odbierajcy TCP a do chwili, gdy poczenie znajdzie si w stanie ESTABLISHED)." Na stronie 66 tego samego dokumentu mwi si, e w czasie przetw a rzania otrzymanej flagi SYN w stanie LISTEN dowolne elementy kontrolne lub tekstowe powinny by umieszczane w kolejce w oczekiwaniu na pniejsze przetworzenie." Pewien recenzent utrzymuje, e nazwanie tego bdem jest niewaciwe, poniewa doku menty RFC nie imjmagaj, by serwer akceptowa dane, ktre przychodz w raz z flag SYN. Niektrzy utrzymuj rwnie, e implementacja systemu Solaris zachowuje si popraw nie, poniewa serwer nie poinformowa jeszcze klienta o rozmiarze okna i serwer moe odrzuci dane, wykraczaj one bowiem poza okno. Bez wzgldu na to, jak zdecydujemy si nazyw a opisan waciwo (autor okrela j jako bd Solaris, a Sun przypisa jej identyfikator bdu 1222490, tak wic powinna ona by usunita w przyszych wersjach), przetwarzanie w sytuacjach jak ta opisana powyej wie si z Zasad Odpornoci (Robustness Principle), pierwszy raz wymienion w RFC 791 [Postel 1981a]: Bdi liberalny w stosunku do tego, co akceptujesz, i zachowawczy w stosunku do tego, co w ysyasz."
3.8
Podsumowanie
Przykady z obecnego rozdziau moemy podsumowa nastpujcymi stwierdze niami: 1. Jeli klient straci informacje o stanie serwera (np. klient zostaje przeadowany), wymusza potrjne uzgodnienie wysyajc opcj CCnew w ramach swojego aktywnego otwarcia. 2. Jeli serwer straci informacje o stanie klienta, lub jeli otrzyma segment SYN z wartoci CC mniejsz od oczekiwanej wartoci, wymusza potrjne uzgod nienie wysyajc jedynie SYN /A C K w odpowiedzi na SYN klienta. W tym
Sekcja 3.8
Podsumowanie
57
przypadku TCP serwera musi zaczeka z przekazaniem otrzymanych danych do procesu serwera, a zakoczone zostanie potrjne uzgodnienie. 3. Serwer - jeli chce uywa T /T C P w danym poczeniu - zawsze w odpowie dzi na opcje CC lub CCnew wysya opcje CCecho. 4. Jeli klient i serwer posiadaj informacje o stanie partnera, przeprowadzana jest minimalna transakcja T/T C P skadajca si z trzech segmentw (zakadajc, e zarwno danie, jak i odpowied s mniejsze ni MSS). Jest to najmniejsza moliwa liczba pakietw i transakcja taka charakteryzuje si najmniejszym moliwym czasem oczekiwania (RTT + SPT). W przykadach pokazalimy rwnie wielokrotne zmiany stanu zachodzce w transakcjach z T /T C P i pokazalimy zastosowanie nowych, rozszerzonych (z gwiazdk) stanw poczenia. Jeli klient wysya segment zawierajcy SYN, dane i FIN do hosta, ktry nie rozumie T /T C P , systemy oparte na kodzie sieciowym systemu Berkeley (wrd nich SVR4, lecz nie Solaris) poprawnie umieszczaj dane w kolejce, czekajc na zakoczenie potrjnego uzgodnienia. Moliwe jest jednak, e inne implementacje niepoprawnie zignoruj dane otrzymane wraz z SYN, powodujc - po upywie czasu oczekiwania na potwierdzenie - ponowne wysanie danych przez klienta.

4.1 Wstp
W tym rozdziale kontynuujemy nasze rozwaania na temat protokou T /TC P. Rozpoczynamy od omwienia, w jaki sposb aplikacje typu klient powinny usta la numer portu dla swojego koca poczenia, w zalenoci od przewidywanego czasu poczenia (poczenie dusze lub krtsze od MSL), i pokazujemy jak to wpywa na stan TIME_WAIT protokou TCP. Nastpnie zastanowimy si, dlacze go TCP definiuje stan TIME_WAIT, poniewa ta waciwo protokou czsto nie jest poprawnie rozumiana. Jedn z zalet T /T C P jest moliwo skrcenia stanu TIME_WAIT z 240 sekund do mniej wicej 12 sekund, jeli poczenie trwa krcej ni warto MSL. Przedstawiamy, w jaki sposb to skrcenie jest realizowane i dlaczego mechanizm ten moe dziaa poprawnie. Nasz dyskusj o protokole T /T C P uzupenimy przedstawieniem mechanizmu TAO (TCP accelerated open - przyspieszone otwarcie TCP), ktry umoliwia syste mom klient-serwer uniknicie potrjnego uzgodnienia i w ten sposb przy nawi zywaniu poczenia zaoszczdza czas odpowiadajcy przesaniu pakietu w obie strony, co jest najwiksz zalet T/TCP.
4.2
Numery portw i stan TIME.WAIT
Przy pisaniu programw typu klient TCP nie ma zwykle potrzeby powicania uwagi numerom portw. Wikszo klientw TCP (Telnet, FTP, W W W , itd.) uy wa efemerycznego numeru portu, pozwalajc moduowi TCP hosta wybra aktu alnie nieuywany port. Systemy wywodzce si z systemu Berkeley zwykle w y bieraj efemeryczny numer portu z zakresu od 1024 do 5000 (rysunek 14.4), Solaris wybiera natomiast port o numerze od 32 768 do 65 535. W przypadku klienta T /T C P wybr numeru portu jest bardziej skomplikowany i zaley od czstotliwo ci wymieniania pakietw i czasu trwania poczenia.
Zwyke hosty TCP, zwyky klient TCP

Rysunek 4.1 przedstawia klienta TCP (takiego jak na przykad z rysunku 1.5) wykonujcego w odstpach jednosekundowych trzy jednosekundowe transakcje z tym samym serwerem. Trzy poczenia rozpoczynaj si odpowiednio w czasie 0, 2 i 4 oraz kocz si w czasie 1, 3 i 5. Na osi x odoony jest czas w sekundach, a trzy poczenia oznaczono pogrubionymi liniami.
60
Rozdzia 4
Do kadej transakcji uyte jest inne poczenie TCP. Zakadamy, e klient nie wie jawnie lokalnego portu z gniazdem, pozwalajc moduowi TCP wybra port efemeryczny, oraz e warto MSL protokou TCP klienta wynosi 120 sekund. Pierwsze poczenie pozostaje w stanie TIME_WAIT a do 241 sekundy, drugie poczenie od 3 do 243 sekundy, trzecie od 5 do 245 sekundy. Uywamy symbolu CB (control bock) na oznaczenie kombinacji blokw kon trolnych protokou TCP uywanych, gdy poczenie jest aktywne lub w stanie TIME_WAIT. S to: internetowy blok PCB, blok kontrolny TCP i wzorzec nagw ka. Zaznaczylimy na pocztku rozdziau 2, e cakowity rozmiar tych trzech blokw wynosi 264 bajty w implementacji N et/3. TCP musi periodycznie prze twarza wszystkie bloki kontrolne (w przykadach przedstawionych w rozdzia ach 25.4 i 25.5 tomu 2 wszystkie bloki kontrolne TCP byy przetwarzane odpowiednio co 200 i 500 ms), co moe by istotnym obcieniem CPU.
Implementacja N e t/3 przechowuje kopie nagwkw TCP i IP dla kadego poczenia jako tzw. wzorzec nagwka (header template, rozdzia 26.8 w tomie 2). W zorzec zawiera wszystkie pola, ktre pozostaj niezmienione dla danego poczenia. Przyspiesza to tworzenie wysyanego pakietu, poniewa program po prostu kopiuje w zorzec nagwka, zamiast wypenia kolejno poszczeglne pola.
W przypadku uycia normalnego TCP nie ma sposobu uniknicia sytuacji, w kt rej poczenie pozostaje przez dugi czas w stanie TTME_WAIT. Klient nie moe wic uy tego samego portu dla wszystkich trzech pocze, nawet w przypadku wykorzystania opcji gniazda S O _ R E U S E A D D R . (Na stronie 76 6 w tomie 2 pokazuje my przykad, w ktrym klient usiuje uy tego samego portu.)
Hosty T/TCP, rne porty klienta dla kadej transakcji

Na rysunku 4.2 prezentujemy tak sam sekwencj trzech transakcji, ale teraz oba hosty uywaj T/TC P. Klient TCP jest ten sam co na rysunku 4.1. Zwracamy uwag na istotne rozrnienie: aplikaq'e klienta i serwera nie m usz wykorzysty wa T /T C P , wymagamy jedynie, by hosty znay TCP (tzn. znay opcje CC).
Sekcja 4.2
Numery portw i stan TIM E_ WAIT
61
Rysunek 4.2
Klient TCP, gdy klinet i serwer znaj T/TCP
Rnica pomidzy rysunkami 4.2 i 4.1 polega na tym, e czas trwania stanu nM E_W A IT zmniejszy si, poniewa oba hosty potrafi wykorzysta opcje CC. Zakadamy, e czas oczekiwania, po ktrym nastpuje retransmisja pakietu wyno si 1,5 sekundy (warto typowa dla N e t/3 w sieci lokalnej [Brakmo i Peterson 1994]), i e warto mnonika T /TC P dla stanu TIME_WAIT wynosi 8, co daje skrcenie czasu TIME_WAIT z 240 do 12 sekund. Protok T /T C P umoliwia skrcenie stanu TIME_WAIT, jeli oba hosty potrafi wykorzysta opcje CC i jeli czas trwania poczenia jest krtszy ni MSL (120 sekund). Moe tak by, poniewa opcja CC daje dodatkowe zabezpieczenie przed dostarczeniem duplikatw starych segmentw do innego wcielenia danego po czenia, co pokaemy w rozdziale 4.4.
Hosty T/TCP, ten sam port klienta dla kadej transakcji

Rysunek 4.3 pokazuje t sam co na rysunku 4.2 sekwencj trzech transakcji, ale tym razem zakadamy, e klient za kadym razem uywa tego samego portu. Aby to osign, klient musi uy opcji gniazda S O _ R E U S E A D D R i nastpnie zwiza si z konkretnym portem lokalnym, wywoujc bind przed wywoaniem connect (w przypadku zwykego klienta TCP) lub sendto (w przypadku klienta T/TCP). Podobnie jak dla rysunku 4.2 zakadamy, e oba hosty potrafi uywa T /TC P.
Rysunek 4.3
Klient TCP ponownie wykorzystuje ten sam port; klient i serwer znaj T/TCP
W momencie gdy poczenie ma by utworzone w sekundach 2 i 4, TCP znajduje blok kontrolny z t sam par gniazd w stanie TIME_WAIT. Poniewa poprzednie wcielenie tego poczenia uywao opcji CC i czas trwania poczenia by krtszy
62
Rozdzia 4
ni MSL, stan TIME_WAIT zostaje skrcony, blok kontrolny istniejcego pocze nia skasowany i utworzony jest blok kontrolny nowego poczenia. (Ten sam blok kontrolny moe by uyty dla nowego poczenia - czy tak si zdarzy, zaley jednak od implementacji. Istotne jest, e cakowita liczba uywanych blokw kontrolnych nie zwiksza si.) Zauwamy te, e po zamkniciu trzeciego po czenia stan TIME_WAIT bdzie trwa tylko przez 12 sekund, tak jak to pokazali my na rysunku 4.2. Podsumowujc, pokazalimy w tym podrozdziale, e moliwe s dwa sposoby optymalizacji dziaania klientw uczestniczcych w transakcjach: 1. Bez jakichkolwiek zmian w kodzie rdowym, uwzgldniajc jedynie, e oba uczestniczce hosty znaj protok T/TC P, otrzymuje si skrcenie czasu trwa nia stanu TIME_WAIT z 240 sekund do wartoci rwnej czasowi retransmisji pomnoonemu przez 8. 2. W prowadzajc zmian w kodzie klienta, tak e uywa on tego samego portu dla kolejnych pocze, otrzymujemy nie tylko skrcenie stanu TIME_WAIT do wartoci odpowiadajcej czasowi retransmisji pomnoonemu przez 8, ale stan TIME_WAIT przerywany jest jeszcze szybciej - w momencie, gdy utwo rzone jest nowe wcielenie tego samego poczenia.
4.3
Rola stanu TIME_WAIT
Stan TTME_WAIT protokou TCP to element, ktrego rola bywa bardzo czsto le rozumiana. By moe przyczyn takiego stanu rzeczy jest oryginalna specyfikacja zawarta w RFC 793, w ktrej stan ten zosta opisany bardzo lapidarnie. Pniejsze rda, jak na przykad RFC 1185, omawiaj to zagadnienie bardziej szczegowo. Stan TTME_WAIT spenia dwie funkcje: pozwala przeprowadzi pene dwustronne zamknicie poczenia umoliwia odczekanie do czasu, po ktrym stare zduplikowane segmenty przestaj istnie. Przyjrzyjmy si bardziej szczegowo kadej z tych dwch funkcji.
Dwustronne zamknicie poczenia TCP

N a rysunku 4.4 pokazana jest typowa wymiana segmentw przeprowadzana w momencie, gdy poczenie jest zamykane. Pokazujemy rwnie zmiany stanw poczenia i warto RTT zmierzon dla serwera. Lewa strona diagramu odnosi si do klienta, prawa do serwera, ale naley zauw a y, e aktywne zamknicie moe wykonywa zarwno klient, jak i serwer. Naj czciej jednak robi to klient. Rozwamy te co si stanie, jeeli ostatni segment zostanie zgubiony. Pokazujemy to na rysunku 4.5.
Sekcja 4.3
Rola stanu TIM E_W AIT
63
k li<;nt
(aktywne zamknicie) FIN_WAIT_1
ser wer
ack ____________
FIN_WAIT_2 TIME_WAIT ----------- _________ _________ __
CLOSE_W AIT (pasywne zamknicie) LA ST_A C K ^
> RTT CLO SED
'
Rysunek 4.4
Zwyka wymiana segmentw przy zamkniciu poczenia
kil ant
(aktywne zamknicie) FIN_WAIT_1 ' - ___ acK M+1___ ____ FIN_WAIT_2 TIME_WAIT
ser wer
CLOSE_W AIT (pasywne zamknicie) LA ST_A C K -x
> RTO
J
-----------TIME_WAIT (rozpoczty powtrnie) CLOSED
Rysunek 4.5
Zamknicie TCP, gdy ostatni segment zostaje zagubiony
Poniewa potwierdzenie nigdy nie dociera do serwera, po upywie czasu oczeki wania serwer przele ponownie ostatni segment FIN. Z premedytacj zaznaczyli my tu, e RTO ( retransmission timeout - czas oczekiwania przed powtrzeniem transmisji) jest wikszy ni RTT z rysunku 4.4, poniewa warto RTO rwna si oszacowanej wartoci RTT plus pewna wielokrotno wariancji RTT. (W rozdziale 25 tomu 2 omwilimy szczegowo pomiar RTT i sposb obliczania RTO.) Scena riusz jest taki sam, jeli ostatni segment FIN zaginie - serwer po upywie czasu oczekiwania przesya ponownie segment FIN. Zaprezentowany przykad wyjania, dlaczego stan TIME_WAIT pojawia si po tej stronie poczenia, po ktrej wykonywane jest aktywne zamknicie: host wykonu jcy aktywne zamknicie wysya ostatnie potwierdzenie i - jeli to potwierdzenie
64
Rozdzia 4
zostao zagubione, lub jeli zagin ostatni segment FIN - host znajdujcy si po przeciwnej stronie poczenia, po upywie czasu oczekiwania, retransmituje ostat ni segment FIN. Poniewa informacja o stanie poczenia jest wci zachowana po stronie wykonujcej aktywne zamknicie, moliwe jest ponowne przesanie osta tecznego ACK. Jeli modu TCP nie przechowywaby informaqi o stanie pocze nia, nie byoby moliwe wysanie ostatecznego segmentu ACK, konieczne byoby natomiast wysanie segmentu RST w odpowiedzi na retransmitowany FIN, w wy niku czego pojawiyby si niepotrzebne komunikaty o bdzie. Na rysunku 4.5 zaznaczamy rwnie, e jeeli retransmitowany segment FIN dociera do hosta w stanie TIME_WAIT, to nie tylko wysany jest ostatni segment, ale rwnie rozpoczty jest ponownie stan TIME_WAIT. Oznacza to, e czas oczekiwania w stanie TIME_WAIT zostaje od nowa ustawiony na 2MSL. Moemy postawi pytanie, jak dugo host wykonujcy aktywne zamknicie powi nien pozostawa w stanie TIME_WAIT, by scenariusz przedstawiony na rysunku 4.5 by moliwy? Zaley to od wartoci RTO po przeciwnej stronie poczenia, a ta z kolei zaley od RTT. W RFC 1185 zaznacza si, e RTT wiksze ni 1 minuta jest bardzo mao prawdopodobne. Natomiast moliwa jest warto RTO bliska jednej minuty. Moe si to zdarzy w sytuacjach przecienia w sieciach typu WAN, gdy wielokrotnie retransmitowane segmenty s gubione i algorytm postpowania w sytuacjach awaryjnych protokou TCP wykadniczo ustawia (exponential bcickoff) coraz wiksze i wiksze wartoci RTO.
Utrata wanoci przez stare, zduplikowane segmenty

Drugim powodem istnienia stanu TIME_WAIT jest stworzenie sytuacji, w ktrej stare zduplikowane segmenty mog utraci wano. Podstawowym zaoeniem w dziaaniu TCP jest, e kady datagram IP m a ograniczony czas istnienia w Inter necie. Ten czas jest podany w polu TTL (time-to-live - czas ycia) nagwka IP. Kady ruter przekazujcy datagram IP musi zmniejszy warto TTL o jeden, lub o liczb sekund odpowiadajc czasowi, przez ktry ruter przetrzymuje data gram. W praktyce rzadko si zdarza, by ruter przetrzymywa pakiet duej ni przez sekund, warto TTL jest wic zwykle zmniejszana o jeden przez kady ruter (rozdzia5.3.1 opracowania RFC 1812 [Baker 1995]). Poniewa TTL zajmuje 8 bitw w nagwku, maksymalna liczba hopw dla dowolnego datagramu wynosi 255. W RFC 793 definiuje si maksymalny czas ycia segmentu (MSL - maximum segment lifeime) i okrela si jego warto na 2 minuty. Stwierdza si rwnie, e wybr wartoci MSL podyktowany jest wzgldami praktycznymi i warto ta moe by zmieniona pod wpywem dowiadczenia oraz e czas trwania stanu TIME_WAIT jest rwny podwojonej wartoci MSL. Na rysunku 4.6 pokazalimy poczenie, ktre zostaje zamknite, czeka w stanie TIME_WAIT przez okres 2MSL, a nastpnie inicjowane jest nowe wcielenie po czenia.
Sekcja 4.4
Skrcenie stanu TIM E_W AIT
65
Rysunek 4.6
Nowe wcielenie poczenia jest inicjowane po czasie 2MSL od poprzedniego wcielenia
Poniewa nowe wcielenie poczenia nie moe by zainicjowane wczeniej ni po czasie 2 MSL od zamknicia poprzedniego wcielenia i poniewa ewentualne du plikaty starych segmentw z pierwszego wcielenia znikn w cigu pierwszego MSL trwania stanu TIME_WAIT, mamy pewno, e stare duplikaty nie zostan bdnie uznane za nalece do drugiego wcielenia.
Zabicie stanu TIME_WAIT

W RFC 793 stwierdza si, e segment RST otrzymany w stanie TIME_WAIT zmienia stan poczenia na CLOSED. Uywa si tu okrelenia zabicie (assassination) stanu TIME_WAIT. W RFC 1337 [Braden 1992a] zaleca si, by nie dopuszcza do sytuacji, w ktrej RST przedwczenie koczy stan TIME_WAIT.
4.4
Skrcenie stanu TIME_WAIT
Widzielimy na rysunkach 4.2 i 4.3, e T /T C P moe skrci stan TIME_WAIT. Jeli uywany jest protok T /T C P , czas trwania stanu TIME_WAIT moe ulec skrce niu do wartoci rwnej wartoci RTO ( retransmission timeout) pomnoonej przez 8, zamiast 2MSL. W rozdziale 4.3 wymienilimy rwnie dwie funkcje penione przez stan TIME_WAIT, usprawiedliwiajce jego istnienie. Jak wpywa skrcenie TIME_WAIT na te funkcje?
66
Rozdzia 4
Dwustronne zamknicie poczenia TCP

Pierwsz przyczyn istnienia stanu TIME_WAIT jest przechowanie informacji o stanie poczenia, po to by moliwe byo przetworzenie retransmitowanego segmentu FIN. Jak wida na rysunku 4.5, czas trwania stanu TIME_WAIT powi nien rzeczywicie zalee od RTO, a nie od MSL. Czynnik 8 uywany przez T /T C P pozwala hostowi na drugim kocu poczenia odczeka odpowiednio dugo na potwierdzenie wysania FIN i - przy braku takiego potwierdzenia wysa segment FIN ponownie. W ten sposb powstaje scenariusz przedstawiony na rysunku 4.2, w ktrym kade koczone poczenie pozostaje w stanie TIME_WAIT krcej ni to miaoby miejsce w TCP (12 sekund na rysunku 4.2). Zastanwmy si, co si dzieje w przypadku przedstawionym na rysunku 4.3, gdy klient uywa ponownie tej samej pary gniazd i skrcenie stanu TIME_WAIT nastpuje wczeniej ni po czasie rwnym 8 razy RTO. Odpowiedni przykad zosta przedstawiony na rysunku 4.7.
klient
serwer
C C , cvu
dane i EOF dla klienta, pocztek TIME_WAIT HTO
cd's....... c\N ,
nawa aktywne otwarcie, skrcenie TIME_WAIT (ignorowany)
F IH:cc=a
- niejawne ACK wczeniejszego wcielenia, zamknicie starego wcielenia, otwarcie nowego wcielenia, przekazanie danych do procesu serwera
R ysun ek 4 .7
Skrcenie TIM E_W AIT, gdy ostatni segment A C K zosta zagubiony
Ostatnie potwierdzenie jest zgubione, ale klient inicjuje nowe wcielenie tego same go poczenia zanim druga (retransmitowana) kopia ostatniego segmentu wysa nego przez serwera zostanie odebrana. Kiedy serwer otrzymuje nowy segment SYN, poniewa test TAO daje wynik pozytywny (8 jest wiksze ni 6), potwier dzony zostaje rwnie niejawnie zalegy segment wysany wczeniej przez serwe ra (drugi segment na rysunku). Stare poczenie zostaje zamknite, a nowe zaini cjowane. Poniewa test TAO daje wynik pozytywny, dane zawarte w nowym segmencie SYN zostaj przekazane do procesu serwera.
Sekcja 4.4
Skrcenie stanu TIM E_W AIT
67
W arto zauway, e skoro T /T C P definiuje czas trwania stanu TIME_WAIT w zalenoci od RTO po stronie wykonujcej aktywne zamknicie, istnieje niejawne zaoenie, e wartoci RTO po obu stronach poczenia s podobne" i zawieraj si w pewnych granicach [ Olah 1995]. Jeli host wykonujcy aktywne zamknicie koczy stan TIME_WAIT zanim partner z drugiego koca poczenia wyle ponownie ostatni segment FIN, odpo wiedzi na ostatni FIN bdzie RST, a nie spodziewane retransmitowane potwierdzenie. Moe si to zdarzy, jeli warto RTT jest maa, trzeci segment (ACK) minimalnej trzysegmentowej wym iany T /T C P zosta zgubiony, a klient i serwer maj rne czstot liwoci zegarw program owych i rne minimalne wartoci RTO. (W rozdziale 14.7 pokazane s rozmaite, dziwaczne wartoci RTO uywane niekiedy przez systemy peni ce rol klienta.) Klient moe zmierzy RTT o maej wartoci, podczas gdy serwer nie moe zmierzy RTT w ogle (poniewa trzeci segment zosta zgubiony). Dla przykadu za my, e klient mierzy RTT i otrzymuje warto 10 ms, przy minimalnej wartoci RTT dla tego hosta rwnej 100 ms. Klient zakoczy stan TIME_WAIT 800 ms po otrzymaniu odpowiedzi serwera. Jeeli natomiast kod serwera wywodzi si z systemu Berkeley, domylna warto RTO bdzie rwna 6 sekund (tak jak pokazano na rysunku 14.13). Serwer ponownie wyle segment zawierajcy S Y N /A C K /d an e/F IN po okoo 6 sekun dach, klient odpowie wysyajc RST, co prawdopodobnie spowoduje wystpienie niepo trzebnego bdu aplikacji serwera.
Utrata wanoci przez stare, zduplikowane segmenty

Skrcenie stanu TIME_WAIT staje si moliwe dziki temu, e opcja CC stwarza zabezpieczenie przed dostarczeniem duplikatw starych segmentw do innego wcielenia tego samego poczenia, ale tylko wtedy, gdy czas trwania poczenia jest mniejszy ni MSL. Na rysunku 4.8 prezentujemy sytuacj, w ktrej licznik CC jest zwikszany (tcp_ccgen) z najwiksz moliw czstotliwoci: 2 - 1 jedno stek na 2MSL. Daje to maksymaln czstotliwo transakcji rwn 4 294 967 295, czyli 18 milionw transakcji na sekund!
Zakadajc, e warto t c p _ c c g e n wynosi 1 w czasie 0 i jest zwikszana z maksymaln czstotliwoci, warto ta bdzie ponownie rwna 1 po czasie 2MSL, 4MSL, itd. Rw nie, poniewa w arto 0 nigdy nie wystpuje, pokazana warto 2 1 4 7 483 648 pojawi si w rzeczywistoci chwil przed czasem MSL, a nie - tak jak pokazujemy - dokadnie w czasie MSL.
Zakadamy, e poczenie zaczyna si w czasie 0 z wartoci CC rwn 1, i czas trwania poczenia wynosi 100 sekund. Stan TIME_WAIT zaczyna si w czasie 100 i trwa albo do czasu 112, albo do momentu, gdy nowe wcielenie poczenia jest zainicjowane - w zalenoci od tego, co zdarzy si najpierw. (Zakadamy warto RTO rwn 1,5 sekundy, dajc czas trwania stanu TIME_WAIT rwny 12 se kund.) Poniewa czas trwania poczenia (100 sekund) jest mniejszy ni MSL (120 sekund), mamy pewno, e wszelkie duplikaty starych segmentw znikn po czasie 220. Zaoymy rwnie, e licznik t c p _ c c g e n jest inkrementowany z naj wiksz moliw czstotliwoci, to znaczy pomidzy czasem 0 i czasem 240 host nawizuje ponad 4 miliardy innych pocze TCP. Tak wic - jeli tylko czas trwania poczenia jest krtszy ni MSL - mona bezpiecznie skrci czas trwania stanu TIME_WAIT, poniewa wartoci CC nie powtrz si przed czasem, po ktrym wszystkie ewentualne duplikaty starych segmentw przestan istnie.
68
Rozdzia 4
1 - t cp_ccgen
czas
0 --
*
< 100 --
poczenie z C C -1
23'=2147 483 648 = t cp_ccgen
112(MSL) 120 MSL; wszystkie stare duplikaty z poczenia * z CC-1 przestaj istnie
220- _ 2M -1 = 4 294 967 295 * tcp ccgen 1 - tcp ccgen 2=tcp_ccgen

(2MSL) 240 -
Rysunek 4.8
Poczenie trwajce mniej ni MSL: skrcenie TIME_WAIT jest moliwe
Aby zobaczy, dlaczego skrcenie stanu TTME_WArT moe mie miejsce tylko wtedy, jeli czas trwania poczenia jest krtszy ni MSL, przeanalizujmy rysunek 4.9.
1 = tcp_ccgen
czas
1 - ^
>
231 -2 147 483 648 tcp_ccgen (MSL) 120 140- - '
poczenie z CC=2
220 2k -1 m 4 294 967 295 = tcp_ccgen 1 = tcp ccgen 2= tcp_ccgen

i
MSL; wszystkie stare duplikaty z poczenia z CC2 przestaj istnie
(2MSL) 240 260 -
> =q ro 3E
J
360 -
r 380 --
Rysunek 4.9
Poczenie trwajce duej ni MSL: stan TIM EJN A IT nie moe by skrcony
Sekcja 4.5 ____________ Unikanie potrjnego uzgodnienia przy pomocy TAO
69
Zakadamy ponownie, e licznik tcp_ccgen jest zwikszany z najwiksz moli w czstotliwoci. Poczenie rozpoczyna si w czasie 0, z wartoci CC rwn 2, a czas trwania poczenia wynosi 140 sekund. Poniewa czas trwania jest wikszy ni MSL, stan TTME_WAIT nie moe by skrcony i para gniazd nie moe by ponownie uyta - a do czasu 380. (Dokadniej, poniewa przyjmujemy, e tcp_ccgen rwna si 1 w czasie 0, poczenie z wartoci CC rwn 2 pojawi si chwil po czasie 0 i skoczy si chwil po czasie 140. Nie wpywa to na nasze rozwaania.) W czasie pomidzy 240 a 260 warto CC rwna 2 moe zosta ponownie uyta. Gdyby stan T1ME_WAIT zosta skrcony (powiedzmy, zakoczony pomidzy 140 a 152) i jeli nowe wcielenie tego samego poczenia zostaoby utworzone w czasie pomidzy 240 i 260, moliwe byoby (bdne) dostarczenie do drugiego wcielenia starych duplikatw z pierwszego wcielenia. Zauwamy, e nie jest problemem uycie wartoci CC rwnej 2 w czasie 240-260 dla innego poczenia (to znaczy dla innej pary gniazd), nie mona jedynie uy tej samej wartoci CC dla tej samej pary gniazd, dla ktrej cigle jeszcze mog istnie w sieci duplikaty starych segmentw. Z punktu widzenia aplikacji, skrcenie TIME_WAIT oznacza, e klient musi zde cydowa, czy uywa tego samego lokalnego portu dla serii transakcji z tym samym serwerem, czy uywa innego portu dla kadej transakcji. Jeli czas trwa nia poczenia jest krtszy ni MSL (co jest typowe dla pocze zwanych trans akcjami), to uywanie tego samego portu oszczdza zasoby TCP (tzn. zmniejsza pami zajt przez bloki kontrolne, tak jak to pokazano na rysunkach 4.2 i 4.3). Jeli jednak klient usiuje uy tego samego portu, a poprzednie poczenie trwao duej ni MSL, wygenerowany zostaje komunikat o bdzie EADDRINUSE. Tak jak pokazano na rysunku 4.2, bez wzgldu na to, ktra strategia wyboru portu zostanie uyta - przy zaoeniu, e oba hosty znaj T /T C P i czas trwania pocze nia jest krtszy ni MSL - stan TIME_WAIT jest zawsze skracany od wartoci 2MSL do 8RTO. Pozwala to zaoszczdzi zasoby (tzn. pami i czas CPU). Doty czy to dowolnego poczenia TCP - FTP, SMTP, HTTP i podobnych - krtszego ni MSL, nawizanego pomidzy dwoma hostami uywajcymi T/TC P.
4.5
Unikanie potrjnego uzgodnienia przy pomocy TAO
Podstawow zalet T /T C P jest moliwo uniknicia potrjnego uzgodnienia. Aby zrozumie, dlaczego pominicie potrjnego uzgodnienia jest moliwe, musi my najpierw zastanowi si, jak rol spenia potrjne uzgodnienie. W RFC 793 zwile stwierdza si: Pierwszorzdn przyczyn przeprowadzania potrjnego uzgodnienia jest uniknicie sytuacji, w ktrej stare duplikaty inicjacji poczenia s powodem trudnoci. W celu rozwizania tego problemu zosta wymylony spe cjalny komunikat kontrolny - reset." W ramach potrjnego uzgodnienia kady z partnerw wysya segment SYN ze swoim pocztkowym numerem sekwencyjnym i segment taki musi zosta po twierdzony. W ten sposb wykluczona jest potencjalna moliwo otrzymania przez ktrykolwiek z dwu hostw duplikatu starego segmentu SYN. Co wicej,
70
Rozdzia 4
zwyke TCP nie przekae adnych danych (dane mog by zawarte w segmencie SYN) a do czasu, gdy poczenie znajdzie si w stanie ESTABLISHED. T /T C P musi da gwarancje, e otrzymany SYN nie jest duplikatem starego seg mentu, bez przechodzenia przez potrjne uzgodnienie, stwarzajc jednoczenie moliwo natychmiastowego przekazania danych do procesu uytkownika. Za bezpieczenie przed duplikatami starych segmentw SYN zostaje zrealizowane przez podanie wartoci CC w segmencie SYN wysanym przez klienta, ktra to warto jest porwnana z wartoci CC dla ostatniego poczenia z tym samym klientem, zapamitan przez serwera. Rozwamy diagram czasowy przedstawiony na rysunku 4.10. Tak jak w przypad ku rysunku 4.8, zakadamy, e licznik t c p _ c c g e n jest zwikszany z maksymaln czstotliwoci rwn 232 - 1 jednostek na 2MSL.
1 tcp_ccgen 100 tcp_ c c g e n
czas
Ot
231 = 2 147 403 648 - t c p _ c c g e n
(MSL)
120
wszystkie SYN z CC=1 przestaj istnie wszystkie SYN z CC-100 przestaj istnie
2m -1 - 4 294 967 295 - tcp_ c c g e n 1 b tcp_ c c g e n 100 = t c p _ c c g e n
(2MSL) 240
- -
poczenie, CC=1, serwer zapamituje CC=1 poczenie, CC=100, serwer zapamituje CC-100
Rysunek 4.10 Wiksza warto CC w segmencie SYN gwarantuje, e SYN nie jest duplikatem starego segmentu
W czasie 0 t c p _ c c g e n jest rwne 1, w chwil pniej wynosi 100. Z uwagi na ograniczony czas wanoci dowolnego datagramu IP mamy gwarancj, e po czasie 120 (czas rwny wartoci MSL) wszystkie segmenty SYN z wartoci CC rwn 1 przestan istnie, a chwil pniej przestan rwnie istnie wszystkie segmenty SYN z wartoci CC rwn 100. Nastpnie, w czasie 240, nawizane zostaje poczenie z wartoci CC rwn 1. Zamy, e serwer przeprowadza test TAO dla segmentu inicjujcego to pocze nie i test ten daje wynik pozytywny - wwczas dla tego klienta serwer zachowuje warto CC rwn 1. Chwil pniej zostaje zainicjowane nowe poczenie z tym samym hostem. Poniewa warto CC otrzymana wraz z SYN (100) jest wiksza ni zachowana wczeniej warto CC dla tego klienta (1) i skoro wiemy na pewno,
Sekcja 4.5
Unikanie potrjnego uzgodnienia przy pomocy TAO
71
e stare segmenty SYN z wartoci CC rwn 100 przestay istnie przynajmniej MSL sekund wczeniej, mamy gwarancj, i otrzymany segment SYN nie jest duplikatem starego segmentu. Rzeczywicie, test TAO zosta opisany w RFC 1644 w sposb nastpujcy: Jeli inicjujcy segment SYN (tzn. segment zawierajcy bit SYN, ale nie zawierajcy bitu ACK) wysany przez pewnego hosta posiada warto CC wiksz ni odpo wiednia zapamitana warto, monotoniczna wasno opcji CC gwarantuje, e segment SYN jest nowy i w zwizku z tym moe by natychmiast zaakceptowa ny." Monotoniczna wasno CC oraz dwa zaoenia: wszystkie segmenty maj skoczony czas istnienia rwny MSL, warto tcp_ccgen jest inkrementowana nie szybciej ni 223 - 1 jednostek na 2MSL sekund, gwarantuj, e segment SYN jest nowy i T /T C P moe pomin potrjne uzgodnienie.
Segmenty SYN w nieprawidowej kolejnoci

N a rysunku 4.11 przedstawiono dwa hosty T /T C P i segment SYN, ktry dociera do serwera w nieprawidowej kolejnoci w stosunku do innych segmentw. Seg ment SYN nie jest duplikatem starego segmentu, jedynie kolejno otrzymywania pakietw zostaa zmieniona.
Rysunek 4.11 Dwa hosty T/TCP i segment SYN docierajcy zv niepraimdowej kolejnoci
12
Rozdzia 4
Warto CC przechowywana przez serwera dla tego klienta rwna jest 1. Segment 1 na rysunku, wysany z portu klienta numer 1600, z wartoci CC rwn 15, zostaje jednak opniony w sieci. Segment 2 jest wysany z portu klienta 1601, z wartoci CC rwn 5000, i kiedy serwer odbierze ten segment, test TAO da wynik pozytywny (5000 jest wiksze ni 1) - warto CC przechowywana przez serwera zostaje zwikszona do 5000, a dane przekazane do procesu. Segmenty 3 i 4 zakaczaj t transakcj. Test TAO dla segmentu 1, gdy segment ten dociera wreszcie do serwera, daje wynik negatywny (15 jest mniejsze ni 5000), tak wic serwer odpowiada wysya jc SYN oraz potwierdzenie segmentu SYN wysanego przez klienta, wymuszajc w ten sposb potrjne uzgodnienie (3WHS - three-way handshake), ktre musi by przeprowadzone zanim dane bd mogy by przesane do procesu serwera. Segment 6 zakacza potrjne uzgodnienie i dane s przekazane do procesu. (Nie pokazujemy dalszego cigu tej transakcji.) Warto CC przechowywana przez serwera nie jest jednak uaktualniona, mimo e potrjne uzgodnienie zostao za koczone pomylnie, poniewa segment SYN z wartoci CC rwn 15 nie jest duplikatem starego segmentu (jedynie zosta on odebrany w nieprawidowej ko lejnoci). Gdyby warto CC zostaa uaktualniona, zmieniaby si ona z powrotem z 5000 na 15, stwarzajc moliwo bdnego zaakceptowania przez serwera du plikatu starego segmentu SYN pochodzcego od tego samego klienta, z wartoci CC w przedziale od 15 do 5000.
4.6
Wartoci CC z zawinitym bitem znaku
Na rysunku 4.11 pokazalimy, e gdy test TAO daje wynik negatywny, serwer wymusza potrjne uzgodnienie. Nawet jeli to uzgodnienie koczy si pomylnie, warto CC przechowywana przez serwera nie jest uaktualniona. Jest to prawido we postpowanie z punktu widzenia protokou, ale wprowadza pewn trudno. Moliwe, e test TAO przeprowadzony przez serwera da wynik negatywny, po niewa wartoci CC wygenerowane przez klienta zawijaj bit znaku" (zump) w stosunku do danego serwera. Przypominamy, e generowana jest jedna se kwencja wartoci CC dla wszystkich pocze realizowanych przez danego klien ta. (CC s 32-bitowymi liczbami cakowitymi bez znaku, podobnie jak numery sekwencyjne TCP. Przy wszystkich porwnaniach CC uywana jest modularna arytmetyka, tak jak to opisano na stronach 839-842 tomu 2. Kiedy mwimy, e warto a licznika CC zawija si" w stosunku do b, to mamy na myli sytuacj, w ktrej zwikszona warto nie jest ju wiksza, lecz jest mniejsza ni b). Rozwamy rysunek 4.12. Klient ustanawia poczenie z serwerem w czasie 0, z wartoci CC rwn 1. Test TAO przeprowadzony przez serwera daje wynik pozytywny i serwer zachowuje dla danego klienta t warto CC. Nastpnie klient nawizuje 2 147 483 646 po cze z innymi serwerami. W czasie 120 zostaje nawizane poczenie z tym samym serwerem co w czasie 0. Warto CC wynosi teraz 2 1 4 7 483 648. Test TAO
Sekcja 4.6 __________________ Wartoci CC z zawinitym" bitem znaku________________________ 73
przeprowadzony przez serwera dla segmentu SYN z tak wartoci CC daje wynik negatywny (2147 483 648 jest mniejsze ni jeden, jeli uywana jest modular na arytmetyka - patrz rysunek 24.26 na stronie 842 w tomie 2), potrjne uzgodnie nie przeprowadzone zostaje pomylnie, segment SYN zaakceptowany, ale warto CC przechowywana przez serwera dla tego klienta pozostaje 1.
1=tcp_ccgen
czas
0 - - -4 ----- poczenie, CC=1, serwer zapamituje CC=1
231- 2 147483 648 = tcp_ c c g e n
(MSL) 120 - -
-----
poczenie, CC=2 147 483 648, test TAO daje wynik negatywny, serwer wymusza potrjne uzgodnienie
2321 =2 294967295 = tcp ccgen 1 = tcp ccgen
(2MSL) 240 -
'F Rysunek 4.12 Test TAO moe zakoczy si. niepomylnie, poniewa bit znaku CC zostaje zawinity" Oznacza to, e wszystkie nastpne segmenty SYN wysane przed czasem 240 przez tego samego klienta do serwera spowoduj potrjne uzgodnienie. Zakada my tu, e licznik tcp_ccgen jest cigle zwikszany z maksymaln czstotliwoci. Bardziej prawdopodobne natomiast, e czstotliwo inkrementacji licznika b dzie znacznie mniejsza, co oznacza, e czas, po ktrym warto licznika zwikszy si od 2 147 483 648 do 4 294 967 295 bdzie nie 120 sekund, a potrwa godziny, czy nawet dni. Dopki jednak bit znaku licznika nie zostanie zawinity" po raz drugi, wszystkie poczenia pomidzy tym klientem i tym serwerem bd wymagay potrjnego uzgodnienia. Rozwizanie przedstawionego powyej problemu jest dwustopniowe. Po pierw sze, nie tylko serwer przechowuje najnowsz warto CC otrzyman od klienta, ale rwnie klient przechowuje ostatni warto CC wysan do kadego serwera. Odpowiednie dwie zmienne pokazane s na rysunku 2.5 jako t a o_c c i t a o_c c s e nt . Po drugie, jeli klient stwierdza, e warto CC, ktr ma wanie wysa, jest mniejsza ni ostatnio uyta warto CC dla tego serwera, klient wysya opcj CCnew zamiast CC. Opcja CCnew zmusza oba hosty do ponownego zsynchro nizowania przechowywanych wartoci CC.
74
Rozdzia 4
Jeli serwer otrzymuje segment SYN z opcj CCnew, zmienna tcp_ccgen dla tego klienta otrzymuje warto 0 (niezdefiniowana). Po pomylnym przeprowadzeniu potrjnego uzgodnienia, jeli przechowywana warto CC jest niezdefiniowana, zostaje ona uaktualniona wartoci wanie otrzyman. Klient wysya opcj CCnew zamiast CC w inicjujcym segmencie SYN w dwch sytuacjach: gdy klient nie ma zachowanej wartoci CC dla danego serwera (na przykad po przeadowaniu komputera lub gdy wpis dla danego serwera zosta oprniony) oraz gdy klient wykrywa, e warto CC dla tego serwera zostaa zawinita.
Zduplikowane segmenty SYN/ACK

Do tego momentu nasza dyskusja koncentrowaa si na przypadku, gdy serwer mia pewno, e otrzymany segment SYN jest nowy, tzn. nie jest duplikatem starego segmentu. W takiej sytuacji serwer nie musi przeprowadza potrjnego uzgodnienia. Zastanwmy si teraz, w jaki sposb klient moe uzyska pewno, e odpowied serwera (segment SYN/ACK) nie jest duplikatem starego segmentu. Gdy uywany jest zwyky protok TCP, klient nie wysya adnych danych w seg mencie SYN, tak wic serwer musi potwierdzi dokadnie jeden bajt: flag SYN. Co wicej, implementacje oparte na systemie Berkeley zwikszaj pocztkowy wysykowy numer sekwencyjny (ISS - initial send sequen.ce number) o 64 000 (T CP_I SSINC R podzielone przez 2) za kadym razem, gdy rozpoczynane jest nowe poczenie (strona 1055 tomu 2). Tak wic kady kolejny segment SYN klienta ma wyszy numer sekwencyjny ni w przypadku poprzedniego poczenia. Bardzo mao prawdopodobne, by duplikat starego segmentu SYN /A C K zawiera pole potwierdzenia akceptowalne dla klienta. W przypadku T /T C P segment SYN zawiera zwykle rwnie dane, co zwiksza zakres akceptowalnych dla klienta flag ACK wysanych przez serwera. Rysunek 7 w RFC 1379 [Braden 1992b] pokazuje przykad duplikatu starego segmentu SYN /A C K bdnie zaakceptowanego przez klienta. W ad tego przykadu jest jednak to, e rnica pocztkowych numerw sekwencyjnych pomidzy dwoma poczeniami wynosi tylko 100 i jest to warto mniejsza ni ilo danych wysya nych w pierwszym segmencie SYN (300 bajtw). Jak powiedzielimy, implemen tacje oparte na systemie Berkeley zwikszaj ISS przynajmniej o 64 000 dla kade go poczenia, a liczba 64 000 jest wiksza ni domylna wielko wysykowego okna w protokole T /T C P (zwykle 4096). Wyklucza to moliwo zaakceptowania przez klienta duplikatu starego segmentu SYN/ACK.
System 4.4BSD-Lite2 generuje losowo warto ISS - tak jak to przedstawilimy w rozdzia le 3.2. W tym przypadku warto, o ktr ISS jest zwikszana, zostaa jednolicie losowo rozoona w przedziale od 31 232 do 96 767, co daje redni warto rwn 63 999. Liczba 31 232 jest wci wiksza ni domylna wielko okna wysykowego, a opcja CCecho, ktr wanie zamierzamy przedyskutowa, powoduje, e problem staje si pozorny.
Tak czy inaczej, T /T C P zawiera niezawodne zabezpieczenie przed duplikatami starych segmentw SYN /A CK: opcj CCecho. Klient zna warto CC, ktr wysy-
Sekcja 4.7
Podsumowanie
75
a, i dokadnie ta warto musi by zwrcona przez serwera w opcji CCecho. Odpowied serwera nie zawierajca spodziewanej wartoci CCecho jest ignoro wana przez klienta (rysunek 11.8). Waciwo monotonicznego zwikszania w ar toci CC gwarantuje, e duplikat starego segmentu SYN /A CK nie zostanie za akceptowany przez klienta. Przypominamy, e cykliczne powtrzenie wartoci CC moe nastpi najwczeniej po czasie rwnym 2MSL sekund. Zauwamy, e klient nie moe wykona testu TAO dla segmentu SYN /A C K otrzymanego od serwera: jest na to zbyt pno. Segment SYN klienta zosta ju zaakceptowany przez serwera, dane przekazane do procesu serwera, a otrzymany segment SY N /A C K zawiera odpowied serwera. Jest wic zbyt pno, by klient mg wymusi potrjne uzgodnienie.
Retransmitowane segmenty SYN

W RFC 1644 oraz w naszej dyskusji w tym podrozdziale zignorowana zostaa moliwo, e SYN klienta lub SYN serwera bdzie wysany powtrnie. Na rysun ku 4.10 zakadamy na przykad, e warto tcp_ccgen jest 1 w czasie 0 i wszystkie segmenty SYN z wartoci CC rwn 1 przestaj istnie po czasie' 120 (MSL). W rzeczywistoci moe si zdarzy, e segment SYN z CC rwnym 1 jest retrans mitowany w przedziale czasu od 0 do 75, tak wic wszystkie segmenty SYN z CC rwnym 1 gin po czasie 195, a nie 120. (Implementacje wywodzce si z systemu Berkeley ograniczaj czas, w ktrym segment SYN klienta lub serwera moe by retransmitowany, do 75 sekund. Zostao to omwione na stronie 859 w tomie 2.) Nie zmienia to faktu, e test TAO jest poprawny, zmniejszona zostaje natomiast maksymalna czstotliwo inkrementacji licznika tcp_ccgen. Wczeniej podali my, e maksymalna czstotliwo zmian tego licznika wynosi 232 -1 jednostek na 2MSL sekund, co daje maksymaln czstotliwo transakcji niemal 18 milionw na sekund. Jeli wemie si pod uwag powtrnie wysane segmenty SYN, maksy malna czstotliwo jest rwna 232 - 1 zmian na 2MSL+ 2MRX sekund, gdzie MRX jest limitem czasu na retransmisje segmentw SYN (75 sekund dla N et/3). Otrzy mujemy w ten sposb zmniejszon maksymaln czsto transakcji: okoo 11 milionw na sekund.
4.7
Podsumowanie
Stan TTMELWAIT protokou TCP peni dwie funkcje: pozwala przeprowadzi pene dwustronne zamknicie poczenia, umoliwia odczekanie do czasu, po ktrym stare zduplikowane segmenty przestaj istnie. Jeli czas trwania poczenia T /T C P jest mniejszy ni 120 sekund (1MSL), stan TIME_WAIT trwa przez czas rwny 8 razy czas oczekiwania na retransmsj (8RTO), zamiast 240 sekund. Klient moe rwnie stworzy nowe wcielenie po czenia, ktre znajduje si w stanie TIME_WAIT, jeszcze bardziej skracajc ten stan.
76
Rozdzia 4
Wyjanilimy, dlaczego jest to moliwe, i pokazalimy, e ograniczeniem jest jedynie maksymalna czstotliwo transakcji w protokule T /T C P (niemal 18 mi lionw transakcji na sekund). Jeli klient T /T C P zamierza przeprowadza wiele transakcji z tym samym serwerem, moe on uywa tego samego portu dla kade go kolejnego poczenia, ograniczajc w ten sposb liczb blokw kontrolnych w stanie TIME_WAIT. Test TAO (TCP accelemted open) pozwala omin potrjne uzgodnienie przy na wizywaniu poczenia T/TC P. Test ten daje wynik pozytywny, jeli serwer otrzymuje od klienta warto CC wiksz ni warto przechowywana przez serwera dla tego klienta. Wanie waciwo monotonicznego wzrostu wartoci CC oraz dwa zaoenia, e: wszystkie segmenty maj skoczony czas istnienia rwny MSL sekund, warto tcp_ccgen ronie nie szybciej ni 232 - 1 jednostek na 2MSL sekund, gwarantuj, e segment SYN wysany przez klienta jest nowy i umoliwiaj pominicie potrjnego uzgodnienia w protokole T/TC P.

5.1 Wstp
Jest to pierwszy z kilku rozdziaw opisujcych implementacj T /T C P zawart w kodzie sieciowym N et/3. Zachowujemy ten sam porzdek i styl prezentacji co w tomie 2: Rozdzia 5: warstwa gniazd Rozdzia 6: tablica rutowania Rozdzia 7: bloki kontrolne protokou (PCB) Rozdzia 8: przegld TCP Rozdzia 9: wyjcie TCP Rozdzia 10: funkcje TCP Rozdzia 11: wejcie TCP Rozdzia 12: dania uytkownika w TCP.
We wszystkich tych rozdziaach zakadamy, e Czytelnik dysponuje egzempla rzem tomu 2 lub kodem rdowym opisanych tam programw. W ten sposb moemy ograniczy prezentacj do 1200 linii nowego kodu potrzebnego do imple mentacji T /T C P i unikamy powtrzenia opisu 15 000 linii zawartego w tomie 2. Zm iany w warstwie gniazd wymagane przez T / T C P s niewielkie: funkcja sosend musi uwzgldnia flag M SG_EOF i musi umoliwia wywoanie sendto lub s e ndm s g, jeeli protok dopuszcza niejawne zamknicie-otwarcie.
5.2
Stae
T /T C P wymaga zdefiniowania trzech nowych staych: 1. Flaga MSG_E0F, zdefiniowana w < s y s / s o c k e t . h > . Jeli flaga ta jest podana w odwoaniu do funkcji send, sendto lub sendmsg, oznacza to, e przesyanie danych w danym poczeniu zostao zakoczone. Poczone s w ten sposb funkcje odwoa dowriteishutdown. Flaga ta powinna by uwzgldniona na rysunku 16.12 (strona 498) tomu 2. 2. Nowe danie protokou, PRU_SEND_E0 F, zdefiniowane w <s ys / pr ot os w. h>. danie powinno by uwzgldnione na rysunku 15.17 w tomie 2. Jest ono generowane przez s o s e nd, jak pokaemy to pniej na rysunku 5.2. 3. Nowa flaga protokou, PR_IMPLOPCL (implied open-close, czyli niejawne otwarcie-zamknicie), rwnie zdefiniowana w < s y s / p r o t o s w . h > . Flaga ta oznacza dwie rzeczy: (a) protok dopuszcza wywoanie sendto i sendmsg z podaniem
78
Rozdzia 5
adresu partnera, bez wczeniejszego wywoania connect (niejawne otwarcie); (b) protok rozumie znaczenie flagi MSG_E0F (niejawne zamknicie). Zauwa my, e flaga PR_IMPL0 PCLjest istotna tylko dla protokow zorientowanych na poczenia (na przykad TCP), poniewa protokoy bezpoczeniowe zawsze dopuszczaj sendto i sendmsg bez poprzedzajcego connect. Flaga ta powin na by dodana do rysunku 7.9 (strona 197) w tomie 2. Wpis odpowiadajcy TCP w i net sw[ 2] (linie 51-55 na rysunku 7.13, strona 200, tom 2) powinien zawiera PR_IMPLOPCL wrd wartoci pr_fl ags.
5.3
Funkcja sosend
W prowadzamy dwie zmiany w kodzie funkcji sosend. Rysunek 5.1 przedstawia kod zastpujcy linie 314-321 na stronie 511 w tomie 2. uipc_socket.c
32 0 321 32 2 323 32 4 32 5 326 327 328 32 9 33 0 331 33 2 333 33 4 335 336 if ((so - > s o _s t at e & S S _ I S C O N N E C T E D ) = = 0) [ /* * s en dt o i s e n dm sg s d o p u s z c z a l n e dla g n ia zd a z o r i e n t o w a n e g o * na poczenie, jedynie jezleli gniazdo obsuguje niejawne otwar cie (np. T/TC P). Zw racamy ENOTCONN, jeeli brak pocz e ni a lub nie zosta podany * adres. */ if ((s o - > s o _ p r o t o - > p r _ f 1 ags & P R _ C 0 N N R E Q U I R E D ) && ( s o - > s o _ p r o t o - > p r _ f l a g s & PR _ I M P L O P C L ) = = 0) ( if ( ( s o - > s o _ s t a t e & S S _ I SC 0N FI RM ING) = = 0 && !(resid = = 0 && cl en != 0)) snderrt E N O T C O N N ); ] el se if (addr = = 0) s n d e r r ( s o - > s o p r o t o - > p r flags & PR C O N N R E Q U I R E D ? ENOTCO NN : E D E S T A DD RR EO ) ; )
-----------------------------------------------------------------------------------------------Rysunek 5.1 Funkcja sosend-sprawdzenie poprawnoci
uipc_socket.c
Zauwam y, e nasz modyfikowany kod zaczyna si od linii 320, a nie od linii 314. Spowodowane jest to przez inne zmiany, niezwizane z T /T C P , dokonane w e wczeniej szych fragmentach tego pliku. Ponadto - poniewa zastpujemy siedemnastoma nowymi liniami osiem linii z tomu 2 - dalsze fragmenty kodu w tym samym pliku, ktre bdziemy pokazywa pniej, bd rwnie miay inne numery linii ni odpowiednie fragmenty z tomu 2. Przyjmujemy ogln zasad, e kiedy odnosimy si do fragmentw program w z tomu 2, wyszczeglniamy num ery linii dokadnie takie, jakie widoczne s w w tomie 2. Poniewa program y ulegy zmianie w stosunku do przedstawionych w tomie 2, num ery linii w prezentowanych tu fragmentach zawierajcych modyfikacje bd zblione, ale nie identyczne. 3 2 0 -3 3 6
Jeeli flaga protokou PR_ IMPLOPCL jest ustawiona (tak jak m a to miejsce dla TCP ze zmianami opisanymi w tym tekcie) i adres przeznaczenia jest podany przez woajc procedur, ten fragment kodu dla gniazda zorientowanego na poczenia, umoliwia uycie sendto lub sendmsg. Jeli adres przeznaczenia nie jest podany - w przypadku gniazda TCP zwracany jest komunikat EN O TCO N N , a w przypadku gniazda UDP komunikat EDESTADDRREO.
Sekcja 5.4
Podsumowanie
79
330-331
Ta instrukcja i f umoliwia wysanie informacji kontrolnej bez danych, jeli poczenie jest w stanie SS_I SC ON FI R MING. Wymagane jest to przez protok OSI TP4, nie przez TC P/IP. Nastpna modyfikacja sendto, zastpujca linie 399-403 na stronie 516 w tomie 2, zostaa pokazana na rysunku 5.2. -----------------------------------------------------------------------------------------------41 5 4 16 41 7 4 18 419 420 421 4 22 423 424 425 426 427
uipc_socket.c
s = spl ne tt ) : /* XXX */ /* * Jeeli u y t k o w n i k p o da je fla g MS G_ E0 F , a p r o t o k rozumie * t f lag (np. T/ TCP), i adne d a ne nie o c z e k u j na wysanie, * wwczas wygenerowane zostaje danie PRU_SEND_EOF zamiast * PRILSEND. M S G _ 0 0 B ma je d n a k w y s z y priorytet. */ req = (fla gs & M SG _0 0 B) ? P R I L S E N D O O B : ((flags & M SG _ E 0 F ) && ( s o - > s o _ p r o t o - > p r _ f l a g s & P R _ I M PL 0 PC L) && (resid <= 0)) ? P R U _ S E N D _ E 0 F : PRU_SEND; error = (*so- >s o_ pr o to -> pr _ us rr eq ) (so, req, top. addr. c ontrol); s p l x ( s );
-----------------------------------------------------------------------------------------------Rysunek5.2 Funkcja s os e n d - przekazanie do odpowiedniego protokou
uipc_socket.c
Po raz pierwszy spotykamy si tutaj z komentarzem XXX. Jest to ostrzeenie dla czytelni ka, e ten fragment program u jest niejasny, powoduje nieoczywiste efekty uboczne, lub jest szybkim rozwizaniem bardziej zoonego problemu. W przedstawionym tu frag mencie kodu priorytet procesora zostaje zwikszony przez s p1 ne t po to by uniemoliwi przetwarzanie protokou. Pocztkowy priorytet procesora jest przywrcony na kocu przedstawionego fragmentu przez wywoanie spl x. Rozdzia 1.12 tomu 2 przedstawia rne poziomy priorytetu przerwa w kodzie N e t/3 . 4 1 6 -4 2 7
Jeli podana jest flaga MSG_00B, to wygenerowane zostaje take danie PRILSENDOOB. W przeciwnym razie, jeli podana jest flaga MSG_E0F oraz protok uznaje flag PR_IMPL0 PC L i nie ma wicej danych, ktre powinny by wysane do protokou (resid jest mniejsze lub rwne 0), utworzone zostaje danie PRU_SEND_E0F, zamiast normalnego dania PRU_SEND.
Przypomnijmy nasz przykad z rozdziau 3.6. Aplikacja wywouje sendto z flag MSG_EOF, eby przekaza 3300 bajtw. Przy pierwszym wykonaniu ptli (rysu nek 5.2) program generuje danie PRU_SEND dla pierwszych 2048 bajtw danych (klaster mbuf). Przy drugim wykonaniu ptli w funkcji sos end danie PRU_SEND_E0F utworzone zostaje dla pozostaych 1252 bajtw danych (w kolej nym klastrze mbuf).
5.4
Podsumowanie
T /T C P uzupenia TCP o moliwo wykonania niejawnego otwarcia i zamknicia poczenia. Niejawne otwarcie oznacza, e zamiast wywoywa connect, aplika cja moe wywoa sendto lub sendmsg podajc adres partnera. Niejawne zamk nicie pozwala aplikacji poda flag MSG_E0F w odwoaniu do send, sendto lub sendmsg, czc wysanie danych z zamkniciem, sendto na rysunku 1.10 czy
80
Rozdzia 5
otwarcie, wysanie i zamknicie w jednym odwoaniu do funkcji systemowej. Zmiany zaprezentowane w tym rozdziale rozszerzaj warstw gniazd kodu N e t/3 o moliwo korzystania z niejawnego otwarcia i zamknicia.
Implementacja T/TCP: tablica rutowania

6.1 Wstp
Protok T /T C P musi utworzy w pamici wpis dla kadego hosta, z ktrym si komunikuje, zawierajcy trzy zmienne: t ao_cc, t a o _ c c s e n t i tao_mssopt, tak jak to pokazalimy na rysunku 2.5. Wygodne miejsce na umieszczenie takiego wpisu to istniejca tablica rutowania. W kodzie N e t / 3 umieszczenie dodatkowych da nych w tablicy rutowania jest atwe - mona to zrobi przy pomocy flagi klono wania", ktr opisalimy w rozdziale 19 tomu 2. W tomie 2 zobaczylimy, e protokoy Internetu (bez T /T C P ) uywaj oglnych funkcji obsugi tablicy rutowania udostpnianych przez N et/3. Rysunek 18.17 (strona 593) w tomie 2 pokazuje, e marszruty s dodawane przy pomocy funkcji rn_addroute, a kasowane przy pomocy rn_delete. Poszukiwanie marszruty odbywa si przy pomocy funkcji rn_match, a funkcja rn_wa 1 kt ree umoliwia przeledzenie caego drzewa rutowania. (N et/3 przechowuje tablice rutowania w formie binarnego drzewa, zwanego drzewem podstawowym - mdix tree). Wymie nione funkcje pozwalaj na pen obsug tablic rutowania wymagan przez TCP/IP. W przypadku T /T C P sytuacja jest jednak inna. Poniewa host w krtkim czasie moe nawizywa poczenia z tysicami innych hostw (na przykad w cigu kilku godzin, a w przypadku silnie aktywnego serwera W W W by moe nawet w czasie krtszym ni godzina), potrzebny jest mechanizm dajcy moliwo automatycznego usuwania wpisw z tablicy ruto wania po okrelonym czasie, by unikn niepotrzebnego zajmowania pamici jdra systemu. W tym rozdziale przedstawiamy uywane przez T /T C P funkcje, pozwalajce dynamicznie tworzy i kasowa wpisy w tablicy rutowania protoko u IP.
W wiczeniu 19.2 w tomie 2 przedstawilimy prosty sposb tworzenia wpisu w tablicy nitow ania dla kadego partnera, z ktrym komunikuje si nasz host. Mechanizm, ktry przedstawiamy tutaj, opiera si na podobnej zasadzie, ale dziaa automatycznie dla wikszoci m arszrut T C P /IP. Wpisy dla poszczeglnych hostw utworzone w wiczeniu nigdy nie traciy wanoci - istniay a do przeadowania hosta lub do chwili, gdy zostay rcznie skasowane przez administratora. Potrzebny jest lepszy, autom atyczny sposb zarzdzania wpisami w tablicy rutowania. Istniej rne opinie na temat zaoenia, e istniejca tablica rutowania jest odpowiednim miejscem do przechowywania wpisw protokou T /T C P dla poszczeglnych hostw. A lternatyw byoby przechowywanie danych T /T C P dla poszczeglnych hostw w po staci oddzielnego, specjalnie w tym celu utworzonego drzewa podstawowego w jdrze. Technika oddzielnego drzewa jest prosta, jeli korzysta si z istniejcych oglnych funkcji sucych do obsugi takiego drzewa, i w rzeczywistoci jest uywana do montowania dyskw NFS w kodzie N et/3.
82
Rozdzia 6
6.2
Kod rdowy - wprowadzenie
Funkcje dodane wraz z T /T C P w celu obsugi rutowania T /T C P zebrane s w jednym pliku: neti n e t / i n_rmx. c. Plik ten zawiera jedynie funkcje specyficzne dla Internetu, ktre opisujemy w tym rozdziale. Nie opisujemy tutaj wszystkich funkcji rutowania przedstawionych w rozdziaach 18,19 i 20 tomu 2. Na rysunku 6.1 przedstawilimy zaleno pomidzy nowymi funkq'ami specy ficznymi dla Internetu, opisywanymi w tym rodziale (zacieniowane elipsy z na zwami funkcji zaczynajcymi si od i n_), a oglnymi funkcjami rutowania (o na zwach najczciej zaczynajcych si od rn_ lub r t ).
co 10
minut
________^
(^route_init^)
7
tqtimo^)
RTM ADD
1
(^rtable_init]) (^r^walktreeî (^rtreguest^) (^Jtallocl^) (^^rtfree~^) rt refcnt = 0
RTM DELETE <^rn_lnithead^) <^rtrequest^) (^rrTâddroute^) ( ^ r n _ m at c h ^ )
Rysunek 6.1
Zalenoci pomidzyfunkcjami rutowania specyficznymi dla Internetu
Zmienne globalne
Nowe zmienne globalne specyficzne dla Internetu przedstawione s na rysunku 6.2.
Zmienna r t q _ t i meout rtq_toomany rtq _reallyo ld rtq _m in reallyo ld Typ i nt in t i nt i nt Okrelenie czstotliwo wykonywania i n _ r t q t i mo (domylnie co 10 minut) liczba marszrut, powyej ktrej rozpoczyna si dynamiczne kasowanie czas, po ktrym marszruta zostaje uznana za naprawd star minimalna warto r t q _ r e a l l y o l d
Rysunek 6.2
Zmienne globalne specyficzne dla Internetu
System FreeBSD pozwala administratorowi zmodyfikowa wartoci trzech ostatnich zmiennych na rysunku 6.2 przy pom ocy program u s y s c t l z przedrostkiem
Sekcja 6.3
Struktura radix_node_head
83
n e t . i n e t . i p. Nie pokazujemy tu odpowiedniego fragmentu kodu, poniewa jest to proste uzupenienie funkcji i p_sysct l (rysunek 8.35 strona 253 tom u 2).
6.3
Struktura radix_node_head
Nowy wskanik dodany do struktury radix_node_head (rysunek 18.16, strona 592, tom 2) jest pusty, z wyjtkiem sytuaq'i, gdy wskazuje on na funkcj i n_cl s route, ktr pokazujemy na rysunku 6.7. Wskanik ten uywany jest przez funkcj r t f ree. Pomidzy liniami 108 i 109 na rysunku 19.5 w tomie 2 dodajemy nastpujc lini, deklarujc i inicjalizujc lokaln zmienn dynamiczn rnh :
s t r u c t r a d i x _ n o d e _ h e a d *rnh = r t _ t a b l e s [ r t _ k e y ( r t )- > s a _ f a m i l y ] ;
Pomidzy liniami 112 i 113 zostaj dodane nastpujce trzy linie:

i f (r n h - > r n h _ c l o s e && r t - > r t _ r e f c n t = = 0) ( r n h - > r n h _ c l o s e ( ( s t r u c t r a d i x _ n o d e *)rt, rnh):
} Jeli wskanik funkcji jest niepusty i licznik odwoa ( r t _ r e f c n t ) osiga warto 0, wywoana zostaje funkcja zamykajca rnh_cl ose.
6.4
Struktura rtentry
T /T C P wymaga wprowadzenia dwch nowych flag rutowania w strukturze r t e n t ry (strona 597, tom 2). Do tej struktury zostaje wic dodany nowy czon flag, r t _ p r f 1ags.
Innym moliwym rozwizaniem jest zmiana typu rt_f 1 ags z krtkich na dugie liczby cakowite. Rozwizanie to by m oe bdzie zastosowane w nastpnych wersjach N e t/3 .
T /T C P wykorzystuje w rt _pr f1 ags dwa bity flag: Flaga R T P R F _ W A S C L O N E D -u staw ian ap rzez r t r e q u e s t (pomidzy liniam i335336 na stronie 629 tomu 2), gdy nowy wpis jest tworzony z wpisu z ustawion flag R T F _ C LONING. Flaga R T P R F _ O U R S - ustawiana przez i n_cl sr out e (rysunek 6.7), gdy ostatnie odwoanie do sklonowanej marszruty IP zostaje usunite; w tym momencie uru chamiany jest zegar, ktry po pewnym czasie spowoduje skasowanie marszruty.
6.5
Struktura rtjnetrics
Wszystkie zmiany w tablicy rutowania zwizane z T /T C P wykonowywane s w celu umieszczenia w tej tablicy dodatkowych informacji zwizanych z poszcze glnymi hostami. Informacje te zawarte s w zmiennych t a o_ c c , t a o _ c c s e n t i tao_mssopt. Przechowanie nowych informaqi umoliwia nowy czon w stru kturze rt_met ri cs (strona 599, tom 2):
u_long rmx_fi 1 1 e r [ 4 ] ; /* metryki s p e c y f i c z n e dla r o d zi ny p r o t o k o w */
84
Rozdzia 6
Umoliwia to przeznaczenie 16 bajtw na metryki specyficzne dla konkretnego protokou, ktre wykorzystywane s przez T /T C P tak, jak to pokazujemy na rysunku 6.3. ------------------------------------------------------------------------------------------------153 st r u c t rmxp _ t a o ( 154 t c p _ c c tao_cc; 155 156 157 ) ; tc p _ c c tao_ccsent; u _ s h o r t tao_m s s o p t ; /* * /* /* osta t n i a partnera ostatnia ostatnia
tcpjuar.h
w a r t o CC ot r z y m a n a od w p o p r a w n y m s e g m e n c i e SYN */ w a r t o CC w y s a n a do p a r t n e r a */ w a r t o MSS o t r z y m a n a od part n e r a */
158 # d e f i n e r m x_taop(r)
((struct rmxp_tao * ) ( r ) .rmx_fi 11 er)
-----------------------------------------------------------------------------------------------Rysunek 6.3 Struktura rmxp_tao uywana przez T/TCP jako pami TAO
tcpjuar.h
153-157 Liczniki pocze zadeklarowane s przy uyciu typu tcp_cc. Typ ten zosta zdefiniowany (typedef) jako liczba cakowita bez znaku (podobnie jak numery sekwencyjne TCP). Warto 0 zmiennej typu tc p_ c c oznacza, e zmienna jest niezdefiniowana. 158 Makroinstrukcja rmx_taop, z podanym wskanikiem do struktury rtentry, zwraca wskanik do odpowiedniej struktury rmxp_tao.
6.6
Funkcja injnithead
Na stronie 602 w tomie 2 opisalimy szczegowo kolejne kroki wykonywane przy inicjacji wszystkich tablic rutowania w kodzie N et/3. Pierwsza modyfikacja zwi zana z T /T C P polega na tym, e wskanik dom_rtattach nalecy do struktury inetdomain (linie 78-81 na stronie 200 tomu 2) wskazuje teraz na funkcj i n_i ni thead, zamiast na funkcj rn_i ni thead. Funkcj in_i ni thead pokazuje my na rysunku 6.4. -----------------------------------------------------------------------------------------------218 int 219 i n _ i n i t h e a d ( v o i d **head, int off) 220 [ 221 struct r a d i x _ n o d e _ h e a d *rnh; 222 223 224 225 226 227 228 229 230 231 232 ] if ( ! r n _ i n i t h e a d t h e a d , off)) return (0); if (head != (void **) & r t _ t a b i e s [A F _ 1 N E T ] ) return (1); /* w y k o n u j e m y to tylko dla prawdziwej * tabli cy rutowani a */ rnh = *head; r n h - > r n h _ a d d a d d r = in_addroute; rnh->rnh_matchaddr = in_matroute; r n h - > r n h _ c l o s e = in_clsroute; in_rtqtimo(rnh); /* ki ck off t i m eout first t i m e */ return (1);
in_rmx.c
-----------------------------------------------------------------------------------------------Rysunek 6.4 Funkcja in _ in i thead
in_rmx.c
Sekcja 6.7
Funkcja in_addroute
85
Inicjacja tablicy rutowania

222-225
W kodzie N e t / 3 rn_i ni thead alokuje i inicjuje jedn struktur typu radi x_node_head. Pozostaa cz funkcji jest nowa, wprowadzona dla potrzeb T /T C P i wykonywana tylko wtedy, gdy inicjuje si prawdziw" tablic rutowa nia. Funkcja ta jest rwnie wywoywana przy inicjacji tablicy rutowania innego rodzaju - uywanej w zwizku z punktami montowania NFS.
Zmiana wskanikw funkcji
22 6 229
Dwa wskaniki funkcji w strukturze radi x_n o d e_h e a d s zmienione w sto sunku do ich wartoci domylnych ustawionych przez rn_ini thead: rnh_addaddr oraz rnh_matchaddr. Zmienione zostaj wic dwa z czterech wskanikw z rysunku 18.17, strona 593, tom 2. W ten sposb czynnoci specyficzne dla Internetu mog by wykonane zanim zostan wywoane uniwersalne funkcje wierzchoka podstawy (mdix node). Wskanik funkcji r n h_c 1 o s e jest nowy, wpro wadzony w raz z T/TC P.
Inicjacja ograniczenia czasu
230
Funkcja ograniczenia czasu, i n_rtqti mo, wywoana zostaje po raz pierw szy. Kade wywoanie tej funkcji powoduje, e bdzie ona ponownie wywoana w przyszoci.
6.7
Funkcja in_addroute
Gdy funkcja rtrequest umieszcza nowy wpis w tablicy rutowania w wyniku wykonania polecenia RT M _ A D D lub polecenia R T M _ R E S O L V E (ktre tworzy nowy wpis z istniejcego wpisu posiadajcego ustawion flag klonowania - strony 629-630 w tomie 2), woana jest funkqa rnh_addaddr. Odpowiednikiem tej funkcji dla protokow internetowych jest - jak widzielimy - i n_addroute. Ta nowa funkcja pokazana zostaa na rysunku 6.5. ------------------------------------------------------------------------------------------------47 s t a t i c s tr uc t r a d i x _ n o d e * 48 i n _ a d d r o u t e ( v o i d *v_arg, void *n_arg, st r u c t r a d i x _ n o d e _ h e a d *head, st r u c t r a d i x _ n o d e * t re e n o d e s ) 49 50 l s t r u c t r t e nt ry *rt = (struct r t e nt ry *) treenod e s; 51 52 53 54 55 56 57 58 59 60 61 62 } /* * Dla IP w s z y s t k i e m a r s z r u t y j ed n o s t k o w e , nie b d c e m a r s z r u t a m i * do hosta, maj u s t a w i o n e flagi k l o n o w a n i a */ if ( ! ( r t - > r t _ f 1ags & (R T F _ H 0 S T | R T F _ C L O N I N G ) )) ( s t r u c t s o c k a d d r in *sin = (struct s o c k a d d r in *) rt key(r t) : if ( ! IN M U L T I C A S T ( n t o h l ( s i n - > s i n addr.s a d d r ) )) ( rt - >r t flags |= RTF CL ONING: ) } re t ur n ( r n _ a d d r o u t e ( v _ a r g , n_arg, head, t r e e n od e s) );
in_rmx.c
------------------------------------------------------------------------------------------------Rysunek 6.5 Funkcja in_addroute
in_rmx.c
86
Implementacja TfTCP: tablica rutowania
Rozdzia 6
52-61 Jeeli dodawana marszruta nie jest marszrut do konkretnego hosta i nie ma ustawionej flagi klonowania, analizowane jest sowo kluczowe tablicy rutowania (adres IP). Jeli adres IP nie jest adresem grupowym (multicast), nowy wpis w tab licy rutowania otrzymuje flag klonowania. Funkcja r n _ a d d r o u t e dodaje wpis do tablicy rutowania. Efekt wykonania tej funkcji to ustawienie flagi klonowania dla wszystkich m arsz rut do sieci, cznie z marszrut domyln, z wyjtkiem marszrut przesyania grupowego. Flaga klonowania powoduje, e powstaje nowa marszruta do hosta dla kadego adresu przeznaczenia poszukiwanego w tablicy rutowania, jeli tylko pasujcy wpis w tablicy nie jest adresem sieci przesyania grupowego. Dzieje si tak rwnie, jeli pasujcy wpis to adres domylny. Nowa, sklonowana marszruta do hosta tworzona jest przy pierwszym przeszukiwaniu tablicy dla danego adresu przeznaczenia.
6.8
Funkcja in_matroute
Podczas poszukiwania m arszruty funkcja r t a l l o c l (strona 622-623, tom 2) wywouje funkcj wskazywan przez wskanik r n h _ m a t c h a d d r (tzn. funkcj i n _ m a t r o u t e pokazan na rysunku 6.6). -----------------------------------------------------------------------------------------------68 s t a t i c struct r a d i x _ n o d e * 69 i n _ m a t r o u t e ( v o i d *v_arg, struct r a d i x _ n o d e _ h e a d *head) 70 ( 71 str u c t r a d i x _ n o d e *rn = r n _ m a t c h ( v _ a r g , head); 72 struct r t entry *rt = (struct rtentry *) rn; 73 74 75 76 77 78 79 80 ) if (rt && r t - > r t _ r e f c n t = = 0) ( /* jest to p i e r w s z e o d w o a n i e */ if (r t - > r t _ p r f l a g s & RTPR F _ 0 U R S ) l r t - > r t _ p r f l a g s &= ~ R T P R F _ O U R S ; r t - > r t _ r m x . r m x _ e x p i r e = 0: ) 1 return (rn);
in_rmx.c
-------------------------------------------------------------------------------------------------in_rmx.c Rysunek 6.6 Funkcja injm troute

Wywoanie mjnatch w poszukiwaniu marszruty
71 -78 rn_match poszukuje marszruty w tablicy rutowania. Jeeli marszruta zosta je znaleziona i licznik rt_ref cnt ma warto 0, jest to pierwsze odwoanie do tego wpisu w tablicy rutowania. Jeeli odliczany jest czas pozostajcy do skasowania wpisu, tzn. gdy ustawiona jest flaga RTPRFJDURS, flaga ta zostaje wyczona i ze gar (licznik czasu) rmx_expi re otrzymuje warto 0. Taka sytuacja ma miejsce, gdy marszruta zostaa zamknita, ale nastpio ponowne jej uycie, zanim ulega skasowaniu.
Sekcja 6.9
Funkcja in_clsroute
87
6.9
Funkcja in_clsroute
Wspomnielimy wczeniej, e nowy wskanik funkcji, rn h_c 1 o s e, zostaje dodany do struktury radi x_node_head wraz z T/TC P. Funkcja ta jest wywoywana przez r t f ree, gdy licznik odwoa osiga warto 0. To powoduje wywoanie funkq'i i n_cl s route, pokazanej na rysunku 6.7.
89 stati c void 90 i n _ c l s r o u t e ( s t r u c t ra d i x _ n o d e *rn, s tr uc t ra dix n od e head *head) 91 { 92 st r u c t r t e nt r y *rt = (struct r t e n t r y *) rn; 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 ) if ( ! ( r t - > r t _ f l a g s & RTF_UP)) return; if ( ( r t - > r t _ f l a g s & (R T F _ L L I N F 0 | R T F _ H 0 S T ) ) != RTF_H 0S T) return; if (C r t -> rt prf la g s & (RTPR F W A S C L 0 N E D 1 RTP RF 0URS)) != R T P R F _ W A S C L 0 N E D ) return; /* Jeeli r t q _ r e a l l y o l d je st 0, po p r os tu k a s u j e m y t m a r s z r u t * nie c z e k a j c a z o s t a n i e s ka s o w a n a po w y c z e r p a n i u si c zasu o cz ek iw a ni a. */ if (rtq r e a l l y o l d != 0) ( r t - > r t _ p r f 1ags |= RT PR F_0URS; r t - > r t _ r m x . r m x _ e x p i r e = t i m e . t v _ s e c + r t q _ r e a l 1y o l d ; ) else { rtrequest(RTM_DELETE, (str uc t s o c k a d d r *) rt_ k ey (r t) . r t - > r t _ g a t e w a y , r t_ ma sk ( rt ), r t - > r t _ f l a g s , 0); )
------------------------------------------------------------------------------------------------Rysunek 6.7 Funkcja in_clsroute

Sprawdzenie flag
in_rmx.c
93-99 Sprawdzone zostaje, czy: marszruta jest aktywna (up), flaga RTF_H0ST w czona (tzn. czy nie jest to marszruta do sieci), flaga RTF_LLIN FO wyczona (flaga ta jest wczona dla wpisw ARP), flaga RTPRF_W ASCLONED wczona (wpis zosta sklonowany) i czy flaga RTPRF_0URS wyczona (czas do skasowania wpisu nie jest aktualnie odliczany). Jeli ktrykolwiek z powyszych warunkw nie zosta speniony, funkcja zwraca kontrol do procedury woajcej.
Ustalenie czasu skasowania wpisu
100-112 Najczciej warto rt q_ re al 1yol d jest niezerowa, co powoduje ustawie nie flagi RTPRF_0URS i wpisanie do rmx_expi re wartoci aktualnego czasu w se kundach ( t i me. t v_ s ec ) powikszonego o r t q_ re a l lyol d (zwykle 3600 sekund, czyli 1 godzina). Jeli administrator ustawi przy pomocy programu s y s c t l ze row warto r t q _r ea l lyold, to marszruta jest natychmiast kasowana przez rtrequest.
88
Rozdziale
6.10
Funkcja in_rtqtimo
Po raz pierwszy funkcja i n _ r t q t i m o zostaa wywoana przez i n_i ni th e a d na rysunku 6.4. Kade wywoanie funkcji i n_rtqti mo powoduje, e ustalony zostaje czas nastpnego wywoania tej funkcji - nastpi to po czasie rtq_t i m e o u t sekund (warto domylna wynosi 600 sekund, czyli 10 minut). Funkcja i n_rtqtimo kolejno przeglda (uywajc uniwersalnej funkcji rn_wal k-tree) wszystkie wpisy w tablicy rutowania IP, wywoujc i n_ r t q ki 11 dla kadego wpisu. Funkcja in_rtqkill decyduje, czy skasowa wpis, czy nie. Funkcje i n_rtqti mo i i n_rtqki 11 musz przekazywa midzy sob informaqe i robi to za porednictwem trzeciego argumentu funkcji rn_wal ktree. Argument ten jest wskanikiem przekazywanym przez rn_wal ktree do i n_rtqki 1 1 . Poniewa ar gument jest wskanikiem, informacja moe by przekazywana w obie strony, od i n _ r t q t i m o do i n_rtqki 11 i vice versa. Wspomniany wskanik przekazywany przez i n _ r t q t i m o do rn_wal ktree jest wskanikiem do struktury rtq k_a rg pokazanej na rysunku 6.8. in_rmx.c t-H -_1U L A , 114 s t r u c t rtqk _a rg ( s tr uc t radi x _ n o d e _ h e a d *rnh; /* p o c z t e k t a b l i c y r ut o w a n i a */ 115 found; 116 i nt /* l iczba wpisw, dla k t r yc h o d l i c z a n y je st k czas do s k a s o w a n i a */ ki 1 1 e d ; 117 i nt /* liczba w p i s w s k a s o w a n y c h p rz e z in_rtqki 11 */ updating; 118 i nt /* ustawi an y, jeeli k a s u j e m y n i e p o t r z e b n e * wpi sy */ d raining; /* zw y k l e 0 */ 119 i nt */ 120 t im e t n e x t s t o p ; /* czas p o n o w n e g o w y k o n a n i a 121 ) ; in_rmx.c Rysunek 6.8 Struktura rtqk_arg-przekazyivanie informacji z i n _ r t q t i m o do i n _ r t q k i 11 izpoiorotem Przy okazji omawiania funkcji i n_rtqti mo pokazanej na rysunku 6.9 pokaemy, jak poszczeglne czony tej struktury s uywane. ------------------------------------------------------------------------------------------------159 s t a t i c void 160 i n _ r t q t i m o ( v o i d *roc k) 161 { 162 s t r u c t r a d i x _ n o d e _ h e a d *rnh = rock: 163 s t r u c t r t qk _ a r g a r g ; 164 st r u c t timeval atv; 165 s t a t i c t ime_t 1 a s t _ a d j u s t e d _ t i m e o u t = 0; 166 int s; 167 168 169 170 171 172 a rg .rnh = r n h ; a r g . f o u n d = a r g . k i l l e d = a r g . u p d a t i n g = a r g . d r a i n i n g = 0; a r g . n e x t s t o p = t i m e . t v _ s e c + rtq_ti me ou t ; s = s pi n e t (); r n h - > r n h _ w a l k t r e e ( r n h , i n _r tqkill, &arg): s p l x ( s );
in_rmx.c
173 /* 174 * U s i u j e m y p o s t p o w a " d y n a m ic zn ie " :
Sekcja 6.10
Funkcja in_rtqtimo
89
175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 )
* Jeeli je st "zbyt wiele" m a r s z r u t z a j m u j c y c h n i e p o t r z e b n i e m ie j sc e, * s kr a c a m y czas o c z e k i w a n i a i spra w dz am y, czy m o e m y si p o z b y j a k i c h * d o d a t k o w y c h m a r sz r ut . N i gdy je dn ak nie d o k o n u j e m y takiej m o d y f i k a c j i * cz ciej ni raz na r t q _ t i m e o u t se k u n d - nie chcemy, by s p r a w d z a n i e * o d b y w a o si zbyt czsto. */ if ( C a r g . f o u n d - a r g . k i l l e d > r t q _ t o o m a n y ) && ( t i m e . t v _ s e c - l a s t _ a d j u s t e d _ t i m e o u t >= r t q _ t i m e o u t ) && r t q _ r e a H y o l d > r tq _minreal lyold) { r t q _ r e a l l y o l d = 2 * r t q _ r e a l l y o l d / 3; if ( r t q _ r e a l l y o l d < r t q _ m i n r e a l l y o l d ) rtq_reallyold = rtq_minreallyold; 1 a s t _ a d j u s t e d _ t i m e o u t = t i me .t v_ s ec ; 1 o g ( L 0 G _ D E B U G , "in_rtq ti m o: a d j u s t e d r t q _ r e a l l y o l d to *d\n", r t q _ r e a l l y o l d ); a r g . f o u n d = a r g . k i l l e d = 0; a r g . u p d a t i n g = 1: s = s p l n e t ( ); r n h - > r n h _ w a l k t r e e ( r n h , in_rt qk il l , &arg): s p l x ( s ); ) a t v . t v _ u s e c = 0; a t v . t v _ s e c = ar g. ne x t s t o p ; timeout(in_rtqtimo, rock, h z t o ( 4a tv ) );
---------------------------------------------------------------------------------Rysunek 6.9 Funkcja in_rtqtimo

Inicjacja struktury rtqk_arg i wywoanie rn_walktree
in_rmx.c
167-172 Struktura rtqk _ ar g jest zainicjowana przez przypisanie rnh wartoci odpo wiadajcej pocztkowi tablicy rutowania IP, liczniki found i killed otrzymuj warto O , flagi d r a i n i n g i u p d a t e ustawione s na O , a warto n e x t s t o p ustalona zostaje na aktualny czas (w sekundach) plus r t q _ t i m e o u t (600 sekund, czyli 10 minut). Funkcja r n _ w a l k t r e e przeglda ca tablic rutowania IP, woajc i n_rtqki 11 (rysunek 6.10) dla kadego wpisu w tej tablicy.
Sprawdzenie liczby wpisw w tablicy rutowania
173-189 Tablica rutowania zawiera zbyt wiele wpisw, jeeli jednoczenie spenione s nastpujce trzy warunki: liczba wpisw cigle pozostajcych we wanie przegldanej tablicy rutowania (found minus ki 1 i ed ) jest wiksza ni r t q _ t o o m a n y (z wartoci domyln rwn 128), liczba sekund od ostatniego wykonania tego sprawdzenia jest wiksza ni rtq_ti m e o u t (600 sekund, czyli 10 minut), warto r t q_re a 11 y o 1 d jest wiksza ni r t q_mi n re a 11 y o 1 d (warto domyl na wynosi 10). Jeeli wszystkie trzy warunki s spenione, to r t q _ r e a l l y o l d otrzymuje warto rwn dwm-trzecim swojej aktualnej wartoci (obliczone z dzielenia liczb cako witych). Poniewa pocztkowa warto rtq_real lyol d jest rwna 3600 sekund (60 minut), to kolejne moliwe wartoci wynosz: 3600,2400,1600,1066,710, itd. Nigdy jednak warto tej zmiennej nie moe sta si mniejsza ni rtq_minreal lyol d
90
Rozdzia 6
(warto domylna rwna 10). Aktualny czas zostaje zachowany w statycznej zmiennej 1 ast_ a d ju sted_ti meo u t i wysyany jest komunikat (dla kontroli) do demona sysl ogd. (Rozdzia 13.4.2 pracy [Stevens 1992] pokazuje, jak funkcja 1 og wysya komunikaty do demona s y s 1 o g d .) Idea zwizana z tym fragmentem kodu i ze zmniejszajc si wartoci r t q _ r e a 11 yol d jest taka, by przegldanie tablicy rutowania i kasowanie zdezaktualizowanych wpisw stawao si czstsze, w mia r jak tablica rutowania si wypenia. 190-195 Liczniki found i killed w strukturze r t q k _ a r g s ponownie inicjowane wartociami 0, flaga updati ng otrzymuje tym razem warto 1 i znw woana jest funkcja rn_wal ktree. 196 -1 9 8 Funkcja i n_rtqki 11 wpisuje do czonu n e x t s t o p struktury r t q k _ a r g czas, w ktrym i n_rtqti mo m a by wywoana ponownie. Funkcja jdra ti m e o u t po woduje, e takie wywoanie w przyszoci nastpi.
Jak due dodatkowe obcienie procesora spowodowane jest przegldaniem caej tablicy rutowania co 10 minut? Zaley to oczywicie od liczby wpisw w tej tablicy. W rozdziale 14.10 stworzylimy tablic rutowania odpowiadajc aktywnemu serwerowi W W W i stwierdzilimy, e cho serwer kontaktuje si z ponad 5000 rnych klientw w cigu 24 godzin, z czasem deaktualizacji wpisw w tablicy rutowania rwnym 1 godzinie, w tab licy rutowania nigdy nie wystpuje wicej ni 550 pozycji. Niektre podstawowe (backbone) rutery w Internecie posiadaj dzi dziesitki tysicy wpisw w tablicy rutowania, lecz s to rutery, a nie hosty. Nie naley si spodziewa, e taki podstaw ow y ruter bdzie wykorzystywa T /T C P i bdzie zmuszony regularnie przeglda tak wielk tablic ruto wania, kasujc stare wpisy.
6.11
Funkcja in_rtqkill
Jak ju wiemy, funkcja i n_rtqki 11 jest woana przez rn_wal ktree, ktra to funkcja z kolei jest woana przez i n_rtqti mo. Funkcja i n_rt q k i 11, ktr pokazu jemy na rysunku 6.10, m a za zadanie kasowa wpisy w tablicy rutowania IP, gdy to jest konieczne. -----------------------------------------------------------------------------------------------127 s t a t i c int 128 in_rtqki 11 129 ( st r u c t 130 st r u c t 131 st r u c t 132 int 133 134 135 136 137 138 139 140 141 142 143 144 (struct r a a i x _ n o d e *rri, void *rock) rtqk _ a r g *ap = rock; r a d i x _ n o d e _ h e a d * rnh = a p ->rnh ; rtentry *rt = (struct r t e ntry *) rn; err; 1 (
in_rmx.c
if ( r t - > r t _ p r f l a g s & R T PRF_0URS) ap->found++:
if ( a p - > d r a i n i n g || r t - > r t _ r m x . r m x _ e x p i r e <= t i m e . t v _ s e c ) if ( r t - > r t _ r e f c n t > 0) pani c ("r t q k i 11 route re a 11y not free"); err = r t r e q u e s t (R T M _ D E L E T E , (struct s o c k a d d r *) rt_key(rt), r t - > r t _ g a t e w a y , rt_mask(rt), r t - > r t _ f 1a g s . 0); if (err) l o g ( L 0 G _ W A R N I N G , " i n _ r t q k i 11: e r r o r % d \ n , err);
Sekcja 6.11
Funkcja in_rqkill
else a p - > k i 1 led++: if ( a p - > u p d a t i n g && (r t - > r t _ r m x .r m x _ e x p i r e - t i m e . t v _ s e c > r t q _ r e a l l y o l d ) ) r t - > r t _ r m x . r m x _ e x p i r e = t i m e . t v _ s e c + rtq really ol d ; ) a p - > n e x t s t o p =l m in(ap->nextstop, r t - > r t _ r m x . r m x _ e x p i r e ) ; {
91
145 146 147 1 e ls e ( 148 149 150 151 152 153 ] 154 ] 155 r e tu rn (0): 156 )
-----------------------------------------------------------------------------------------------Rysunek 6.10 Funkcja in _ rtq k i 1 7

Przetwarzanie tylko nieaktualnych wpisw
in_rmx.c
134-135 Funkcja ta przetwarza tylko wpisy z ustawion flag RTPRF_0URS, to znaczy wpisy, ktre zostay zamknite przez i n_cl s route (ich liczniki odwoa osign y warto 0) i nastpnie, po pewnym czasie (zwykle 1 godzina), straciy wano. Funkcja nie ma wpywu na aktualnie uywane marszruty (poniewa flaga RTPRF_0URS dla takich marszrut nie jest ustawiona). 136-146 Jeeli flaga dra i ni ng jest ustawiona (co nigdy nie zdarza si w opisywanej tu implementaqi), lub skoczy si okres wanoci wpisu (warto rmx_expi re jest mniejsza ni aktualny czas),marszruta zostaje skasowana przy pomocy r t r e q u e s t . Czon found struktury rtqk_arg zlicza wpisy w tablicy rutowania z ustawion flag RTPRF_0URS, a czon ki 11 ed zlicza skasowane wpisy. 147-151 Klauzula el se zostaje wykonana, gdy przegldany wpis jest wany (tzn. nie skoczy si okres wanoci wpisu ). Jeeli ustawiona zostaa flaga updating (co si zdarza, gdy - jak widzimy na rysunku 6.9 - mamy wiele marszrut, dla ktrych odliczany jest czas do skasowania i caa tablica jest przegldana jeszcze raz) i jeeli czas utraty wanoci (ktry musi odpowiada przyszoci, jeli odejmo wanie m a da dodatni warto) jest zbyt odlegy, to czas ten zostaje ustawiony na aktualny czas powikszony o warto rt q_ r ea 1 lyold. Wyjaniamy to dokadniej na rysunku 6.11.
1
okres wanoci ustalony pocztkowo na 3600 sekund rnica = 3100 okres wanoci odliczany od nowa - ustalony na 2400 sekund i 100 in _ c ls r o u t e 600 in _ r t q t im o in r t q k i .l l i I 3000 i I 3700
Rysunek 6.11 Funkcja in _ rtq k i 11 zmienia czas utraty wanoci Na osi x odoylimy czas w sekundach. Marszruta zostaje zamknita w czasie 100 (gdy liczba odwoa staa si rwna 0), a pocztkowa warto r t q _r ea l lyol d wynosi 3600 (1 godzina). Czas utraty wanoci dla tej marszruty wynosi wic
92
Rozdzia 6
3700. W czasie 600 wykonana jest funkcja i n_rtqti mo i marszruta nie jest skaso wana (poniewa traci ona wano dopiero 3100 sekund pniej). W tablicy ruto wania jest jednak zbyt wiele pozycji, funkcja i n_rtqti mo ustawia wic warto rtq_real lyol d na 2400, zmienia warto flagi updati ng na 1, a funkcja rn_wal k-tree ponownie przeglda tablic rutowania. Tym razem i n_r t q ki 11 znajduje ustawio n flag updati ng i czas utraty wanoci marszruty jest okrelony na 3100. Ponie wa 3100 jest wiksze ni 2400, czas utraty wanoci jest zmieniony na 2400 sekund liczone od aktualnej chwili, czyli czas 3000 na rysunku 6.11. Czas utraty wanoci maleje wraz ze zwikszeniem si liczby wpisw w tablicy rutowania.
Obliczenie nastpnego czasu timeout
152-153 Ten fragment kodu jest wykonywany za kadym razem, gdy znaleziona zostaje marszruta, dla ktrej czas do utraty wanoci jest odliczany, ale jeszcze nie upyn. n e x t s t o p otrzymuje warto rwn mniejszej z dwch wartoci: aktual na warto n e x t s t o p i czas utraty wanoci danego wpisu w tablicy rutowania. Przypominamy, e pocztkowa warto next stop bya ustalona przez i n_rtqti mo ibya rwna aktualnemu czasowi plus rtq_ti m e o u t (tzn. 10 minut pniej). Rozwamy przykad pokazany na rysunku 6.12. Na osi x odoony jest czas w sekundach i due kropki w czasie 0, 600, itd. oznaczaj kolejne wywoania
i n_rtqti mo.
in
c ls r o u t e "1 1 100 300 I Il Ii t 0
marszruty trac wano 1 1 3700 3900 11 1 t t t 3600
1 f 600
i t 1200
i t 1800
i t 2400
i t 3000
i t 4500
Rysunek 6.12 Wykonanie in _ rtq tim o ; utrata wanoci marszrut Marszruta IP jest tworzona przez i n _ a d d r o u t e i nastpnie zamykana w czasie 100 przez in_clsroute. Czas utraty wanoci tej marszruty ustalono na 3700 (godzin pniej). Inna marszruta zostaje utworzona i nastpnie zamknita w czasie 300, czas utraty wanoci tej marszruty wynosi wic 3900. Funkcja i n _ r t q t i m o jest wykonywana co 10 minut, w czasie 0, 600,1200,1800, 2400, 3000 i 3600. Podczas kadego z tych wykona w czasach od 0 do 3000 n e x t s t o p otrzymuje warto rwn aktualnemu czasowi powikszonemu o 600. Kiedy i n_ r t q ki 11 jest w yw o ana dla kadej z dwch marszrut w czasie 3000, n e x t s t o p otrzymuje warto 3600, poniewa 3600 jest mniejsze ni 3700 i mniejsze ni 3900. Kiedy natomiast i n_rtqki 11 jest wywoana w czasie 3600, n e x t s t o p otrzymuje warto 3700, poniewa 3700 jest mniejsze ni 3900 i mniejsze ni 4200. Oznacza to, e nastp nym razem i n_rtqki 11 bdzie wywoana w czasie 3700, a nie 4200. Podobnie, kiedy in_rtqkill jest wywoana w czasie 3700, druga marszuta, ktra utraci wano w czasie 3900, powoduje, e n e x t s t o p otrzymuje warto 3900. Zakada
Sekcja 6.12
Podsumowanie
93
jc, e adne inne marszruty IP nie trac wanoci, funkcja i n_rtqti mo po wyko naniu w czasie 3900 zostanie ponownie wywoana w czasie 4500,5100, itd.
Zalenoci zwizane z czasem utraty wanoci

Istnieje kilka subtelnych zalenoci dotyczcych czasu utraty wanoci wpisw do tablicy rutowania i czonu rmx_expi re struktury rt_metri cs. Po pierwsze, ten sam czon jest rwnie uywany przez ARP, by okreli utrat wanoci wpisw ARP (rozdzia 21, tom 2). Oznacza to, e wpis w tablicy rutowania odnoszcy si do hosta w lokalnej podsieci (cznie ze zwizan z tym hostem informacj TAO) jest kasowany, kiedy kasowany jest wpis ARP dla tego hosta, co zwykle ma miejsce co 20 minut. Czas ten jest krtszy ni domylny czas utraty wanoci uywany przez i n_rtqki 11 (1 godzina). Przypominamy, e funkcja i n_c1 s route jawnie ignorowaa te wpisy ARP (rysunek 6.7), ktre miay ustawion flag RTM_LLINF0, oddajc ARP kontrol nad wanoci tych wpisw. Po drugie, wykonanie programu route w celu odczytania i wydrukowania m e tryk i czasu utraty wanoci dla sklonowanego wpisu T /T C P w tablicy rutowania m a efekt uboczny polegajcy na przywrceniu pocztkowej wartoci czasu utraty wanoci. Dzieje si to w sposb nastpujcy. Zamy, e marszruta jest uyw a na, a nastpnie zostaje zamknita (liczba odwoa staje si rwna 0). Czas utraty wanoci zostaje ustalony na jedn godzin od czasu zamknicia marszruty. 59 minut pniej, jedn minut przed upywem terminu wanoci, program route jest uyty do wydrukowania metryk tej marszruty. W wyniku uruchomienia programu route wykonane zostaj nastpujce funkcje jdra: r o u t e _ o u t p u t wy wouje rtal 1 ocl, ktra z kolei woa i n _ m a t r o u t e (wersja funkcji r n h _ m a t c h a d d r specyficzna dla Internetu), co powoduje zwikszenie liczby odwoa od - powie dzmy - 0 do 1. Na koniec, zakadajc, e liczba odwoa zmienia si od 1 do 0, funcja r t f r e e wywouje i n_c 1 s r o u t e, co powoduje ustawienie czasu utraty wa noci ponownie na 1 godzin.
6.12
Podsumowanie
W zwizku z T /T C P do struktury rt_ m e t r i c s dodajemy 16 bajtw. Dziesi z tych bajtw jest uywanych przez T/TC P jako pami TAO : t ao _c c , ostatnia warto CC otrzymana od partnera w poprawnym segmencie SYN t a o _ c c s e n t , ostatnia warto CC wysana do partnera tao_ms sopt, ostatnia warto MSS otrzymana od partnera. Do struktury r a d i x _ n o d e _ h e a d zostaje dodany jeden nowy wskanik funkcji czon rnh_close, ktry (o ile zosta zdefiniowany) jest wykorzystywany, gdy liczba odwoa dla danej marszruty osignie 0.
94
Rozdzia 6
Zostaj zdefiniowane cztery nowe funkcje specyficzne dla protokow interneto wych:
1. i n_i ni thead inicjuje internetow struktur rad i x _ node_head, ustawiajc
omawiane tu cztery wskaniki funkcji, 2. i n _ a d d r o u t e jest woana, gdy do tablicy rutowania IP dodana zostaje nowa marszruta. Funkcja ta wcza flag klonowania dla kadej marszruty IP, z wyjtkiem marszrut do hostw i wpisw odpowiadajcych adresom grupo wym,
3. i n_m a t r o u t e jest woana za kadym razem, gdy poszukiwana jest marszruta IP. Jeli marszruta oczekuje na skasowanie po wykonaniu i n_c1 s route, tzn.
biegnie czas do utraty jej wanoci, czas utraty wanoci otrzymuje warto 0, poniewa marszruta ta jest znowu uywana. 4. i n _ c l s r o u t e jest woana, gdy ostatnie odwoanie do marszruty IP zostaje zamknite. Funkcja ta ustala czas utraty wanoci marszruty na 1 godzin od aktualnej chwili. Zobaczylimy te, e czas ten moe zosta skrcony, jeeli tablica rutowania staje si zbyt dua.
Implementacja T/TCP: bloki kontrolne protokou

7.1 Wstp
T/TCP wymaga wprowadzenia jednej niewielkej zmiany w funkcjach PCB (roz

dzia 22, tom 2). Funkcja i n _ p c b c o n n e c t (rozdzia 22.8, tom 2) zostaje teraz po dzielona na dwie czci: wewntrzn procedur zwan i n_pcbl addr, ktra przy pisuje adres lokalnego interfejsu, oraz funkcj i n_p c b c o n n e c t , ktra peni t sam rol co wczeniej (i woa in_pcbl addr). Dokonujemy takiego podziau funkcji na dwie czci, poniewa przy uyciu T/TCP moliwe jest wywoanie connect, gdy poprzednie wcielenie tego samego poczenia (ta sama para gniazd) pozostaje w stanie TIME_WAIT. Jeli poprzednie wcielenie trwao krcej ni warto MSL, i jeli obie strony uywaj opcji CC, wtedy poczenie w stanie TIME_WArr zostaje zamknite i moe zosta utworzo ne nowe poczenie (nowe wcielenie poczenia). Gdybymy nie wprowadzili zmiany i T/TCP uyoby niezmodyfikowanej funkcji i n_pcbco n n e c t , aplikaqa po znalezieniu bloku PCB poczenia w stanie TIME_WAIT - otrzymaaby infor macje o bdzie address already in use" (zajty adres). Funkcja i n _ p c b c o n n e c t jest wywoywana nie tylko z polecenia c o n n e c t moduu
TCP, ale rwnie: gdy otrzymane zostaje nowe danie poczenia TCP, gdy wywoywane jest c o n n e c t protokou UDP i przy wykonaniu funkcji s e n d t o UDP.
Rysunek 7.1 podsumowuje te odwoania N e t/3 przed wprowadzeniem naszej modyfikacji.
UDP wejcie TCP
R ysunek7.1
Podsumowanie odwoa Net/3 dofunkcji i n_pcbcorw ect
Procedury wejciowe TCP oraz modu protokou UDP wywouj - tak jak poprzednio - i n_pcbconnect, ale funkcja co n n e c t TCP (danie PR U _ C O N N E C T ) wywouje teraz now funkcj t c p _ c o n n e c t (rysunki 12.2 i 12.3), ktra z kolei wywouje now funkq' i n_pcbl addr. Dodatkowo t c p _ c o n n e c t wywouje rw nie dania P R U _ S E N D oraz P R U _ S E N D _ E O F wygenerowane w rezultacie niejawne go otwarcia poczenia przez klienta z uyciem s e n d t o lub w wyniku uycia sendmsg. Demonstrujemy to na rysunku 7.2.
96
Implementacja T/TCP: bloki kontrolne protokou______________ Rozdzia 7
UDP
wejcie TCP
Rysunek.7.2
Nowy ukad, odwoa do i n_pcbconnect
in _p cb l addr
7.2
Funkcja in_pcbladdr
Pierwsza cz funkcjii n_pcbl addr pokazana zostaa na rysunku 7.3.Ten frag ment zawiera jedynie argumenty funkcji i pierwsze dwie liniekodu, ktre s identyczne z liniami 138-139 na stronie 762 tomu 2. -----------------------------------------------------------------------------------------------136 137 138 139 140 141 142 143 144 145 146 int i n _ p c b l a d d r (i n p , nam, p 1o c a 1_s i n ) s t r u c t inpcb *inp; s t r u c t m b u f *nam; struct sockaddr_in * * p l o c a l _ s i n ; ( st r u c t in _ i f a d d r *ia; s t r u c t s o c k a d d r _ i n *ifaddr; s t r u c t s o c k a d d r _ i n *sin = mtod (n am , if ( n a m - > m _ l e n != s i z e o f ( * s i n )) re t ur n (EINVAL);
in_pcb.c
s t ru ct s o c k a d d r _ i n *);
-----------------------------------------------------------------------------------------------Rysunek 7.3 Funkcja i n_pcb 1addr, cz pierwsza

136-140
in_pcb.c
Pierwsze dwa argumenty s takie same jak argumenty in_pcbconnect, trzeci argument jest wskanikiem do wskanika, za porednictwem ktrego zw r cony zostaje lokalny adres. Pozostaa cz tej funkcji jest taka sama jak na rysunkach 22.25, 22.26 i 22.27 w tomie 2, z wyjtkiem ostatnich dwch linii na rysunku 22.27 (linie 225-226, strona 765), ktre zostaj zastpione kodem przedstawionym na rysunku 7.4.
232-236
Jeli procedura woajca poda adres wieloznaczny (w i d c a r d ), w trzecim argumencie zostanie zwrcony wskanik do struktury sockaddr_in.
Dziaanie i n _ p c b l a d d r sprowadza si w zasadzie do przeprowadzenia najpierw pewnej kontroli bdw, nastpnie obsuone zostaj szczeglne adresy 0.0.0.0 i 255.255.255.255, po czym nastpuje przypisanie lokalnego adresu IP (o ile proce dura woajca nie podaa adresu). Pozostaa cz przetwarzania wymaganego przez co n n e c t wykonywana jest w i n_pcbconnect.
Sekcja 7.3
Funkcja in_pcbconnect
97
-----------------------------------------------------------------------------------------------232 233 234 235 236 237 238 239 } /* * Nie w y w o u j e m y tu i n _ p c b l o o k u p . Interfejs zwracamy w * plocal_sin i przekazujemy kontrol do w y w o u j c e j procedury, * ktra wy k o n a poszuki w a n i e . */ * p l o c a l _ s i n = &i a -> i a _ a d d r : ) return (0);
injpcb.c
-----------------------------------------------------------------------------------------------Rysunek 7.4 Funkcja in_pcb 1addr, cz kocowa
in_pcb.c
7.3
Funkcja in_pcbconnect
Funkcja i n _ p c b c o n n e c t pokazana zostaa na rysunku 7.5. Funkcja ta wywouje funkcj i n_ p c b 1 addr przedstawion w poprzednim rozdziale, a dalsza cz ko du rdowego tej funkcji jest taka sama jak kod z rysunku 22.28, strona 765 w tomie 2. ------------------------------------------------------------------------------------------------247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 int i n _ p c b c o n n e c t ( i n p , nam) str u c t inpcb *inp; st r u c t m b u f *nam: ( s t r u c t s o c k a d d r _ i n *i f a d d r ; s t r u c t s o c k a d d r _ i n *sin = mto d ( n a m , int error;
injpcb.c
struct s o c k a d d r _ i n *);
/*
* W y w o u j e m y w e w n t r z n funkcj,
by p r z y p i s a l o kalny adres i n t e r f e j s u
if (error = i n _ p c b l a d d r ( i n p , return (error);
*/
nam, &i f a d d r ))
if ( i n _ p c b l o o k u p ( i n p - > i n p _ h e a d , si n->sin_addr, sin-> s i n _ p o r t , i n p - > i n p _ l a d d r . s _ a d d r ? i n p -> i n p _ l a d d r i n p - > i n p_lport, return ( E A D D R I N U S E ) ; if ( i n p - > i n p _ l a d d r . s _ a d d r = = I N ADDR_ANY) { if (i n p -> in p _ l p o r t == 0) (v o i d ) i n_pcbbi n d (i n p , (struct m b u f *) 0); inp->inp_laddr = ifaddr--sin_addr; i n p - > i n p _ f a d d r = s i n - > sin_addr; i n p - > i n p _ f p o r t = sin-> s i n _ p o r t ; r et u r n (0); )
: ifaddr->sin_addr,
0))
-----------------------------------------------------------------------------------
injpco.c
Rysunek 7.5 Funkcja in_pcbco nnect
98
Implementacja TfTCP: bloki kontrolne protokou
Rozdzia 7
Przypisanie lokalnego adresu

2 5 5 -2 5 9
Lokalny adres IP jest wyznaczany przez i n_pcbl addr i zostaje zwrcony we wskaniku i faddr, chyba e procedura woajca zwizaa si wczeniej z gniazdem.
Sprawdzenie, czy para gniazd jest jednoznaczna
2 6 0 -2 6 6
Funkcja i n _ p c b l o o k u p sprawdza, czy para gniazd okrelona jest jedno znacznie. W zwykym przypadku, gdy klinet TCP wykonuje c o n n e c t (jeli klient nie zwiza si z gniazdem lokalnego portu lub lokalnego adresu), numer lokalne go portu rwny jest 0. Tak wic funkcja i n_pcbl oo k u p zawsze zwraca warto 0, poniewa numer lokalnego portu rwny 0 nie koliduje z adnym istniejcym blokiem PCB.
Zwizanie lokalnego adresu portu i lokalnego portu
Funkcja i n_pcbbi nd przypisuje lokalny adres i lokalny port, o ile lokalny adres i lokalny port nie zostay jeszcze zwizane z gniazdem. Jeli lokalny adres nie zosta jeszcze zwizany, ale numer lokalnego portu jest inny ni 0, do PCB zostaje wpisany adres lokalny zwrcony przez in_pcbl addr. Nie jest moliwe zwizanie lokalnego adresu, gdy numer lokalnego portu jest cigle 0, poniewa wywoanie in_p c b b i n d w celu zwizania lokalnego adresu powoduje rwnie przypisanie do gniazda efemerycznego portu. 2 7 2 -2 7 3 Do PCB zostaj wpisane adres i port odlegego systemu (argumenty
267-271
i n_pcbconnect).
7.4
Podsumowanie
Funkcja i n _ p c b c o n n e c t zostaa zmodyfikowana w zwizku z T /T C P w ten spo sb, e fragment kodu, w ktrym wyznaczany jest lokalny adres, zosta usunity i umieszczony w nowej oddzielnej funkcji i n_pcbl addr. Funkcja i n _ p c b c o n n e c t najpierw wywouje now funkcj, a nastpnie kontynuuje dziaanie tak jak po przednio. Taki funkcjonalny podzia procedury i n _ p c b c o n n e c t umoliwia w y woanie i n_pcbl addr w celu wyznaczenia lokalnego adresu w trakcie przetwa rzania dania klienta T /T C P (jawnego - z uyciem connect, lub niejawnego z uyciem sendto). Przetwarzanie po stronie klienta T /T C P powiela nastpnie kroki pokazane na rysunku 7.5, a modu T /T C P umoliwia akceptacj dania poczenia, nawet jeli istnieje wczeniejsze wcielenie tego samego poczenia pozostajce w stanie TIME_WAIT. Zwyke TCP nie dopucioby do takiej sytuacji, funkcja i n _ p c b c o n n e c t zwrciaby komunikat o bdzie E A D D R I N U S E (rysu nek 7.5).
Implementacja T/TCP: przegld TCP

8.1 Wstp
W tym rozdziale omawiamy globalne zmiany w strukturach danych i funkcjach TCP wprowadzone na potrzeby T/T C P. Dodane zostaj dwie zmienne globalne: t c p _ c c g e n - globalny licznik CC oraz t c p _ d o _ r f c l 6 4 4 - flaga okrelajca, czy powinny by uywane opcje CC. Wpis przecznika protokow (protocol switch entry) odpowiadajcy TCP jest zmodyfikowany, tak by moliwe byo wykonanie niejawnego otwarcia-zamknicia. Ponadto do bloku kontrolnego TCP zostaj do dane cztery nowe zmienne. Funkqa t cp _s 1 owti mo, mierzca czas trwania poczenia, zostaje nieznacznie zmodyfikowana. W zalenoci od czasu trwania poczenia - jeeli poczenie jest krtsze ni MSL - T /TC P skraca stan TIME_WAIT, tak jak to przedstawilimy na rysunku 4.4.
8.2
Kod rdowy - wprowadzenie
adne nowe pliki z kodem rdowym nie zostaj dodane w zwizku z T /T C P, wymagane jest natomiast wprowadzenie kilku nowych zmiennych.
Zmienne globalne
Na rysunku 8.1 zebralimy nowe zmienne globalne zwizane z T /TC P.
Zmienna tcp_ccgen tcp_do_rfcl644 Typ tcp_cc i nt Okrelenie nastpna warto C C do wysania jeli prawda (warto domylna), wylij opcje C C lub C C ne w
Rysunek 8.1
Zmienne globalne dodane wraz z T/TCP
W rozdziale 3 przedstawilimy kilka przykadw uycia zmiennej tcp_ccgen. W rozdziale 6.5 wspomnielimy, e typ zmiennych t c p _ c c jest zdefiniowany (typedef) jako unsigned long. Warto 0 zmiennej typu t c p _ c c oznacza, e zmienna ta jest niezdefiniowana. Sposb odwoywania si do zmiennej tcp_ccgen jest zawsze nastpujcy:
t p - > c c _ s e n d = C C _ I N C (t c p _ c c g e n ):
gdzie cc_send to nowy czon bloku kontrolnego TCP (patrz rysunek 8.3). Makro instrukcja CC_INC zostaa zdefiniowana w <net i net / tcp_seq . h> jako
100
Implementacja T/TCP: przegld TCP
Rozdzia 8
# d e f i n e CC _ l N C ( c )
(++(c) == O ? + + (c)
: (c))
Poniewa warto zmiennej jest zwikszana przed uyciem, t c p _ c c g e n zostaje zainicjowana wartoci 0, a jej pierwsza warto wynosi 1. Zostaj zdefiniowane cztery makroinstrukq'e, ktre - przy zastosowaniu modular nej arytmetyki - su do porwnywania wartoci CC: CC_LT, CC_LEQ, CC_G, i CC_GEQ. Makroinstrukcje te s identyczne z czterema makroinstrukcjami S E Q _ x x przedstawionymi na stronie 839 tomu 2. Zmienna t c p _ d o _ r f c l 6 4 4 jest podobna do zmiennej t c p _ d o _ r f c 1323 wprowa dzonej w tomie 2. Jeli t c p _ do_r f c 1644 jest rwna 0, TCP nie bdzie wysya opcji CC lub CCnew do partnera po drugiej stronie poczenia.
Zmienne statystyczne
T /T C P wprowadza pi nowych licznikw, ktre pokazujemy na rysunku 8.2. Liczniki te zostaj dodane do struktury t c p s t a t , ktr przedstawiamy na stro nach 826-827 w tomie 2. Program n e t s t a t musi zosta zmodyfikowany, tak by drukowa rwnie te nowe czony struktury.
Czton tcpstat tcp_taook tcps_taofai 1 tcps_badccecho tcps_i mpli e d a c k tcps_ccdrop Opis liczba otrzymanych segmentw SYN, dla ktrych testTAO da wynik pozytywny liczba otrzymanych segmentw S Y N z opcj CC, ale z negatywnym wynikiem T A O liczba segmentw SYN/ACK z bdn opcj CCecho liczba nowych SYN, ktre niejawnie potwierdzaj poprzednie wcielenie liczba segmentw odrzuconych ze wzgldu na nieprawidow opcj C C
Rysunek 8.2
Dodatkowe liczniki T/TCP w strukturze statystycznej t c p s t a t
8.3
Struktura TCP protosw
W rozdziale 5 wspomnielimy, e wraz z wprowadzeniem T /T C P zmianie ulega czon pr_f 1 ags odpowiadajcej TCP struktury protosw (ktra jest elementem tablicy inetsw[2]; strona 829 w tomie 2). Do istniejcych ju flag P R _ C O N N R E Q U I R E D i P R _ W A N T R C V D musi by dodana nowa flaga warstwy gniazd - PR_IMPL0PCL. W funkcji sosend, jeli procedura woajca podaje adres przeznaczenia, flaga ta umoliwia wykonanie sendto dla nie poczonego gniazda. Umoliwia ona rw nie wystawienie dania P RU_S E N D_E 0 F zamiast P RU_S E N D, jeli podana jest flaga
MSG_E0F.
Zmian pokrewn do modyfikacji struktury protosw, nie wymagan przez T /T C P , jest dodanie definicji funkcji zwanej tcp_sysct l w charakterze czonu struktury pr_sysctl. Umoliwia to administratorowi systemu modyfikowanie wartoci niektrych zmiennych kontrolujcych dziaanie TCP przy pomocy programu sysctl z przedrostkiem n e t . i n e t .tcp. (Kod N e t/3 przedstawiony w tomie 2 umoliwia jedynie kontrol niektrych zmiennych IP, ICMP i UDP przy pomocy
Sekcja 8.4
Blok kontrolny TCP
101
programu sysctl. Kontrola ta jest realizowana poprzez funkcje ip_sysctl, i cmp_ sysctl i u d p _ s y s c t l .) Funkcj tcp _sysctl pokazujemy na rysunku 12.6.
8.4
Blok kontrolny TCP
Do bloku kontrolnego TCP, czyli do struktury tc pcb pokazanej na rysunku 8.3, dodane zostaj cztery nowe zmienne.
Zmienna t _ d u r a t i on t_ m a x o p d cc_sen d c c _re c v Typ u _ lo n g u _sh o rt tc p _c c tc p _c c Opis czas trwania poczenia w jednostkach 500 milisekundowych MSS plus dugo zwykych opcji warto CC, ktra bdzie wysana do partnera warlo CC otrzymana od partnera
Rysunek 8.3
Nowe czony struktury tcpcb dodane z T/TCP
Zmienna t_durati on jest konieczna, by stwierdzi, czy T /T C P moe skrci stan TIME_WAIT, tak jak to omawialimy w rozdziale 4.4. Gdy powstaje blok kontrol ny, zmienna ta otrzymuje warto pocztkow rwn 0 i nastpnie jest zwiksza na co 500 ms przez funkcj tcp_sl owti mo (rozdzia 8 .6). Zmienna t_ m a x o p d zostaa stworzona dla wygody. Jest rwna sumie wartoci czonu t _ m a x s e g oraz liczby bajtw zajmowanych przez opcje TCP. t _ m a x s e g to liczba bajtw danych w segmencie. N a przykad w sieci Ethernet z wartoci MTU rwn 1500 bajtw - jeli znaczniki czasu oraz opcje T /T C P s uywane t _ m a x o p d jest rwna 1460, a warto t_ m a x s e g 1440. Rnica 20 bajtw pomidzy tymi dwiema wartociami odpowiada 12 bajtom opcji znacznika czasu plus 8 bajtw opcji CC (rysunek 2.4). Zmienne t _ m a x o p d i t _ m a x s e g s wyznaczane i zapisywane przez funkcj tcp_mssrcvd. Ostatnie dwie zmienne z rysunku 8.3 pochodz z RFC 1644 i przykady uycia tych zmiennych byy pokazane w rozdziale 2. Jeli poczenie zostao nawizane z uyciem opcji CC przez oba hosty, warto cc _ r e c v bdzie niezerowa. Sze nowych flag zostaje zdefiniowanych i umieszczonych w czonie t_fl ags bloku kontrolnego TCP. Flagi te zostay pokazane na rysunku 8.4 i s uzupenie niem flag przedstawionych na rysunku 24.14 na stronie 834 w tomie 2.
t _ f 1ags Opis wysa SYN (ukryta flaga stanu dla poczenia poowicznie zsynchronizowanego) wysa FIN (ukryta flaga stanu) wysa opcj CCnew zamiast CC dla aklywego otwarcia nie wysya segmentu tylko w celu oprnienia bufora wysykowego ustawiona, gdy partner przysya opcj CC w segmencie SYN opcja CC jest lub bdzie dana w segmencie SYN
TF_SENDSYN TF_SENDF1 N TF_SENDCCNEW TF_N0PUSH TF_RC/ D_CC TF_RE0_CC
Rysunek 8.4
Nowe flagi w czonie
t_fl
a g s - wprowadzone wraz z T/TCP
102
Implementacja TTCP: przegld TCP
Rozdzia 8
Nie naley myli flagi T /T C P TF_SENDFIN, ktra oznacza, e TCP m a wysa segment FIN, z istniejc flag T F_S ENTFIN, ktra oznacza, e segment FIN zosta ju wysany.
N azwy T F _ S E N D S Y N i T F _ S E N D F IN pochodz z implementacji T /T C P Boba Bradena. W implementacji FreeBSD nazwy te zostay zmienione na T F _ N E E D S Y N i T F _ N E E D F 1 N.. Wybralimy wczeniej wymienione wersje nazw, poniewa nowe flagi oznaczaj, e odpowiednie flagi kontrolne (SYN i FIN) m usz by wysane, podczas gdy nazw y w w er sji FreeBSD niepoprawnie implikuj, e flaga SYN lub FIN powinna by otrzymana. Naley jednak pamita, e przy takim wyborze nazw, nazw y flagi T /T C P T F _ S E N D F IN i istniejcej flagi T F _ S E N T F I N (ktra oznacza, e modu TCP wysa ju FIN) rni si tylko jednym znakiem.
Flagi T F _ N 0 P U S H i T F _ S E N D C C N E W omawiamy w nastpnym rozdziale i przedstawiamy je odpowiednio na rysunkach 9.3 i 9.7.
8.5
Funkcja tcpjnit
Nie jest wymagana jawna inicjacja adnej ze zmiennych T /T C P i funkcja tcp_i n i t pozostaje nie zmieniona. Zmienna globalna t c p _ c c g e n jest niezainicjowana zmienn zewntrzn i otrzymuje warto domyln 0, zgodnie z reguami jzyka C. Jest to poprawne, poniewa makroinstrukcja CC_INC, zdefiniowana w rozdziale 8.2, inkrementuje t zmienn zanim zostanie ona uyta, tak e pierw sza warto t c p _ c c g e n po przeadowaniu komputera wynosi 1. Protok T /T C P wymaga rwnie, by pami TAO zostaa oprniona w trakcie przeadowania. Warunek ten jest speniony niejawnie - tablica rutowania IP zosta je zainicjowana po przeadowaniu. Za kadym razem, gdy nowa struktura rtent ry dodawana jest do tablicy rutowania, funkcja rt r e q u e s t inicjuje struktur warto ci domyln rwn 0. Oznacza to, e trzy zmienne TAO w strukturze r m xp_ ta o (rysunek 6.3) otrzymuj wartoci domylne 0. Warto pocztkowa rwna 0 jest wymagana przez T /T C P dla zmiennej ta o _ c c , gdy dla nowego hosta powstaje nowy wpis TAO.
8.6
Funkcja tcp_slowtimo
Do kadej z dwch funkcji obsugi czasu w TCP dodana zostaje jedna linia kodu. Przy kadym odwoaniu do funkcji t c p_s 1 owt i mo (pokazanej na stronach 852-853 tomu 2) warto czonu t_durati on w kadym bloku kontrolnym TCP zostaje zwikszona o 1. Odwoania takie nastpuj co 500 ms. Pomidzy liniami 94 i 95 na stronie 853 tomu 2. dodana zostaje nastpujca linia:
tp->t_duration++;
Zadaniem zmiennej t_durati on jest pomiar czasu trwania poczenia w jedno stkach rwnych 500 ms. Jeli poczenie jest krtsze ni MSL, stan TIME_WAIT moe zosta skrcony, tak jak to pokazalimy w rozdziale 4.4.
Sekcja 8.7
Podsumowanie
103
Rwnie w zwizku z tym usprawnieniem do nagwka < n e t i n e t / t i m e r . h > zostaje dodana nastpujca staa:
#define TCPTV_TWTRUNC 8 /* C z y n n i k RTO u y w a n y do sk r c e n i a T I M E _ W A I T */
Na rysunkach 11.17 i 11.19 zobaczymy, e gdy poczenie T /T C P zostaje aktyw nie zamknite i warto t _ d u r a t i o n jest mniejsza ni T C P T V _ M S L (60 jednostek 500-milisekundowych, czyli 30 sekund), to czas trwania stanu TIME_WAIT jest rwny czasowi oczekiwania przed powtrzeniem transmisji (RTO) pomnoone mu przez TCP TV_TW TRUNC. W sieci LAN, gdzie RTO wynosi zwykle 3 zliczenia zegara, czyli 1,5 sekundy - stan TIME_WAIT zostaje skrcony do 12 sekund.
8.7
Podsumowanie
Protok T /T C P wprowadza dwie nowe zmienne globalne (tc p_ccgen i t c p _ d o _ r f c l 6 4 4 ), dwa nowe czony w bloku kontrolnym TCP i pi nowych licznikw w strukturze statystycznej TCP. Funkcja tcp_sl o w tim o jest rwnie zmodyfikowana, tak by wyznaczaa czas trwania kadego poczenia TCP w jednostkach rwnych 500 ms. Warto ta uywana jest dla okrelenia, czy T /T C P moe skrci stan TIME_WAIT, gdy nastpuje aktywne zamknicie.

9.1 Wstp
W tym rozdziale omawiamy zmiany w funkcji t c p _ o u t p u t wprowadzone w zwizku z T/TC P. Funkcja t c p _ o u t p u t jest woana z wielu miejsc w TCP. Sprawdza ona, czy segment powinien by wysany i wysya ten segment - jeeli jest to konieczne. W raz z T /T C P zostaj wprowadzone nastpujce zmiany: dwie ukryte flagi stanu mog wczy flagi TH_SY N i TH_ F IN T /T C P umoliwia wysanie wicej ni jednego segmentu w stanie SYN_SENT, ale tylko jeli wiemy, e partner rozumie T /T C P mechanizm unikania wysyania gupich segmentw musi wzi pod uwag now flag TF_N0 PUSH (omawiamy t flag w rozdziale 3.6) m og by wysyane nowe opcje T /T C P - CC, CCnew i CCecho.
9.2
Funkcja tcp_output
Nowe dynamiczne zmienne lokalne

W t c p _ o u t p u t zostaj zadeklarowane dwie nowe dynamiczne zmienne lokalne:
st r u c t r mx p _ t a o *taop; st r u c t r mx p _ t a o tao_noncached;
Pierwsza jest wskanikiem do wpisu partnera w pamici T A O . Jeli nie istnieje odpo wiedni wpis T A O (co nie powinno si zdarzy), t a o p wskazuje na t a o_n oncached, a ta struktura jest zainiqowana wartoci 0 (jej warto t a o_c c pozostaje wic niezdefiniowana).
Dodanie ukrytych flag stanu
Na pocztku t c p _ o u t p u t flagi TCP odpowiadajce aktualnemu stanowi pocze nia zostaj wczytane z tablicy tc p_o ut f 1 a g s . Rysunek 2.7 pokazuje flagi obowi zujce dla poszczeglnych stanw poczenia. Kod przedstawiony na rysunku 9.1 dodaje do flag poczenia (w sensie logicznego OR) flagi TH_FIN i TH_SYN, jeeli odpowiednia ukryta flaga stanu jest wczona. Ten fragment kodu znajduje si na stronach 886 i 888 w tomie 2.
106
Rozdzia 9
------------------------------------------------------------------------------------------------71 72 73 74 75 76 77 78 79 80 81 82 83 s e n d a l o t = 0;
tcp_output.c
again: off = t p - > s n d _ n x t - t p - > s nd _ un a: w in = m i n ( t p - > s n d _ w n d , t p - > s n d _ c w n d ): flags = t c p _ o u t f l a g s [ t p - > t _ s t a t e ] ; /* * M o d y f i k u j e m y s t a n d a r d o w e flagi d o d a j c SYN lub FIN - jeeli * tego w y m a g a j u k r y t e flagi stanu. */ if (t p- > t _ f l a g s & T F _ S E N D F I N ) flags 1= T H _ F I N : if (t p - > t _ l a g s & T F _ S E N D S Y N ) flags |= T H _ S Y N :
--------------------------------------------------------------Rysunek 9.1 tcp_output - dodanie ukrytych flag stanu
tCp_OUtput.C
tcp_output.c
116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 1 en = m i n ( s o - > s o _ s n d .sb_cc, win) - off; if ( ( taop = t c p _ g e t t a o c a c h e ( t p - > t _ i n p c b ) ) = = NULL) ( taop = & t a o _ n o n c a c h e d ; bzer oC t ao p, s i z e o f ( * t a o p ) ): ) /* * Z e r u j e m y bit SYN, jeeli SYN z os ta ju wysa ny . * S e g m e n t u SYN n ie w y s y a m y te, je eli s e g m e n t z a w i e r a dane * z n a j d u j e m y si w s t a n i e SYN_ SE N T, a nie wiemy, czy p a r t n e r * zna TAO. */ if ((flags & TH SYN) && SEQ G T ( t p - > s n d nxt. t p - > s n d una)) ( flags & = ~ T H _ S Y N : off--. len++; if (len > 0 && t p - > t _ s t a t e == T C P S _ S Y N _ S E N T && t a o p - > t a o _ c c s e n t = = 0) re t ur n (0); 1 if (len < 0) l
------------------------------------------------------------------------------------------------tcp_output.c Rysunek 9.2 tcp_ou tpu t-fla ga SYN nie powinna by powtrnie wysana w stanie SYN_SENT
Flaga SYN nie powinna by powtrnie wysiana w stanie SYN_SENT
Kod przedstawiony na rysunku 9.2 odczytuje pami TAO dla partnera i spraw dza, czy segment SYN zosta wysany. Ten fragment kodu ulokowany jest na pocztku rysunku 26.3 na stronie 889 w tomie 2.
Odczytanie pamici TAO
117-119 Zawarto pamici TAO dla danego partnera zostaje odczytana. Jeli odpo wiedni wpis TAO nie istnieje, uyta zostaje lokalna zmienna dynamiczna tao_noncached. Jest ona zainicjowana wartoci 0.
Naw et jeli ten w peni zerow y wpis jest uywany, nie ulega on nigdy modyfikacji. Dlatego te - zamiast inicjacji za pomoc b z e r o - struktura t a o _ n o n c a c h e d mogaby by alokowana statycznie i zainicjowana w artoci 0.
Sekcja 9.2
Funkcja tcp_ouput
107
Sprawdzenie, czy danie klienta jest wiksze ni MSS
121 -133
Jeeli dla danego stanu segment SYN powinien by wysany i jeli zosta ju wysany, to flaga TH_SYN jest wyczana. Taka sytuacja moe si zdarzy, gdy aplikacja T /T C P wysya do partnera wicej bajtw danych ni warto MSS (roz dzia 3.6). Jeli partner zna T /T C P , moliwe jest wysanie wicej ni jednego segmentu, ale tylko pierwszy z tych segmentw powinien zawiera flag SYN. Jeli nie wiemy, czy partner rozumie T /T C P (ta o _ c c s e n t jest 0), to nie wysyamy wicej ni jednego segmentu danych dopty, dopki potrjne uzgodnienie nie zostanie zakoczone.
Unikanie wysyania gupich segmentw

Rysunek 9.3 pokazuje dwie zmiany wprowadzone w kodzie implementujcym mechanizmu unikania wysyania gupich segmentw (strona 893, tom 2). -----------------------------------------------------------------------------------------------168 169 170 171 172 173 174 175 176 177 178 179 180 181 i f (1 en ) l if (len = = tp - > t _ m a x s e g ) goto send; if ( ( i d 1e || tp->t f 1ags & TF NODE L A Y ) && (t p -> t _ f 1 ags & TF _ N 0 P U S H ) = = 0 && len + off >= s o - > s o _ s n d . s b _ c c ) goto send: if (tp->t_ f o r c e ) goto send; if (len >= t p - > m a x _ s n d w n d / 2 && t p - > m a x _ s n d w n d > 0) goto send; if ( S E Q _ L T ( t p - > s n d _ n x t . t p - > s n d _ m a x ) ) goto send; )
tcp_output.c
------------------------------------------------------------------------------------------------tcp_output.c Rysunek 9.3 tcp_output-okrelenie, przy uyciu mechanizmu unikania wysyania gupich segmentw, czy naley wysa segment
Wysanie segmentu o normalnej wielkoci
169-170
Jeli segment o normalnej (penej) wielkoci moe by wysany, to zostaje on wysany.

Aplikacja moe wyczy niejawne wypchnicie
171-174
Implementacje BSD zawsze wysyay segment, jeeli flaga ACK nie bya akurat spodziewana od partnera (zmienna i d1 e miaa warto prawda") lub jeli algorytm Nagle by wyczony (TF_NODELAY miaa warto prawda") oraz modu TCP oprnia bufor wysykowy. Takie postpowanie bywa czasami nazywane niejawnym wypchniciem (implied push), poniewa kada prba wpisania danych do gniazda wykonana przez aplikacj koczy si wysaniem segmentu, chyba e jest to uniemoliwione przez algorytm Nagle. T/TC P udostpnia now opcj gniazd, TCP_NOPUSH, ktra umoliwia wyczenie niejawnego wypchnicia. Opcji tej od powiada flaga TF_N0 PUSH . Przykad zastosowania tej flagi omwilimy w rozdzia le 3.6. Widzimy, e w omawianym tu fragmencie kodu segment zostaje wysany tylko wtedy, jeli spenione s jednoczenie trzy nastpujce warunki:
108
Implementacja TfTCP: wyjcie TCP
Rozdzia 9
flaga ACK nie jest spodziewana ( i d 1e m a warto true") lub algorytm Nagle jest wyczony, opcja gniazda TCP_NOPUSH nie jest wczona (sytuacja domylna), TCP oprnia bufor wysykowy (tzn. cae oczekujce dane mog by wysane w pojedynczym segmencie).
Sprawdzenie, czy okno odbiorcy jest przynajmniej poowicznie otwarte
177-178
W zwykym TCP cay ten fragment kodu nie jest wykonywany dla inicjuj cego segmentu SYN, poniewa 1 en wynosi 0. Przy uyciu T /T C P moliwe jest jednak wysanie danych przed otrzymaniem flagi SYN od partnera. Oznacza to, e sprawdzenie, czy okno odbierajcego hosta jest teraz poowicznie otwarte, musi by oparte na warunku, czy warto max_sndwnd jest wiksza ni 0. Zmienna ta podaje maksymalny rozmiar okna partnera, ale wynosi ona 0, dopki informacja o rozmiarze okna nie zostanie otrzymana od partnera (tzn. dopki nie zostanie otrzymany segment SYN).
Wylij, jeli upyn czas oczekiwania na powtrzenie transmisji
179-180
Warto snd_nxt jest mniejsza ni snd_max, jeli upyn czas oczekiwania na powtrzenie transmisji.
Wymuszenie wysania segmentu z flag RST lub SYN

Kod w liniach 179-180 na stronie 895 w tomie 2 zawsze wysya segment, jeeli ustawiona bya flaga SYN lub RST. Te dwie linie zostaj zastpione kodem przed stawionym na rysunku 9.4. -----------------------------------------------------------------------------------------------207 208 209 if ((flags & T H _ R S T ) II ((flags & T H _ SYN) ( t p - > t_flags & TF S E N D S Y N ) = = 0)) goto send;
tcp_output.c
-----------------------------------------------------------------------------------------------Rysunek 9.4 tcp_output - sprawdzenie, czy segment ma by wysany w zalenoci od wartoci flag RST i SYN.
207-209
tcp_output.c
Segment zawsze zostaje wysany, jeeli ustawiona jest flaga RST. Jeli jed nak zostaa ustawiona flaga SYN, segment moe by wysany tylko wtedy, gdy odpowiednia ukryta flaga jest wyczona. Przyczyn tego ostatniego ograniczenia widzimy na rysunku 2.7. Flaga TF_SENDSYN jest wczona dla ostatnich piciu, spord siedmiu, stanw z gwiazdk (stany poowicznie zsynchronizowane), co powoduje wczenie flagi SYN przez kod przedstawiony na rysunku 9.1. Rol tego testu w tcp_output jest wysanie segmentu tylko w stanach SYN_SENT, SYN_RCVD, SYN_SENT* i SYN_RCVD*.
Wysanie opcji MSS

Wprowadzamy drobn zmian w kodzie przedstawionym na stronie 908 w tomie 2. Funkcja N e t/3 tcp_mss (z dwoma argumentami) zostaje zastpiona funkcj
Sekcja 9.2
Funkcja tcp_output
109
t c p_m s s s e n d (z jednym tylko argumentem - 1 p). Dzieje si tak, poniewa musimy rozrni pomidzy obliczeniem wartoci MSS, ktra ma by wysana, a przetwa rzaniem otrzymanej opcji MSS. Funkcja tcp_mss w kodzie N e t/3 penia obie te role. Protok T/TC P uywa dwch rnych funkcji - tcp_msssend i tcp_ms s rcvd. Funkcje te przedstawiamy w nastpnym rozdziale.
Wysa opcj znacznika czasu?

Na stronie 909 w tomie 2 wida, e opcja znacznika czasu zostaje wysana, jeli spenione s nastpujce trzy warunki: konfiguracja TCP przewiduje danie opcji znacznika czasu, tworzony segment nie zawiera flagi RST, wykonujemy aktywne otwarcie lub modu TCP otrzyma opcj znacznika cza su od hosta na drugim kocu poczenia (TF_RCVD_TSTMP). Z aktywnym otwarciem mamy do czynienia, jeeli flaga SYN jest wczona, a flaga ACK wyczona. Kod T /T C P sprawdzajcy trzy wspomniane warunki przedsta wiony zosta na rysunku 9.5. -----------------------------------------------------------------------------------------------283 284 285 286 287 288 289 290 291 /* * * * *
tcp_output.c
W y s y a m y z n a c z n i k czasu i o d p o w i e d "echo", jeeli j e s t to SYN i chcemy u y w a z n a c z n i k w czasu ( T F _ R E Q _ T S T M P j e s t ustawi o n a ) lub z a r w n o my jak i nasz p a r t n e r w y s a l i m y znaczniki c z asu w s e g m e n t a c h SYN.
if ((t p ->t _ f 1 ags 4 (T F _ R E Q _ T S T M P | TF_N00 P T ) ) = = T F _ R E Q _ T S T M P 44 (flags 4 T H _ R S T ) = 0 44 ((flags & TH_ACK) = = 0 |I (t p - > t _ f 1ags & T F _ R C V D _ T S T M P ) )) {
*/
-----------------------------------------------------------------------------------------------Rysunek 9.5 tcp_output - czy wysta opcj znacznika czasu?

283-291
tcp_output.c
Pierwsza poowa trzeciego testu ulega zmianie dla T/T C P, poniewa chce my wysya znaczniki czasu we wszystkich pocztkowych segmentach przesya nych od klienta do serwera (w przypadku wielosegmentowego dania - patrz rysunek 3.9), a nie tylko w pierwszym segmencie zawierajcym SYN. Nowym testem dla wszystkich tych pocztkowych segmentw jest sprawdzenie braku flagi ACK.
Wysanie opcji CC
Pierwszym warunkiem wysania jednej z trzech opcji CC jest to, by flaga T F _ R E Q _ C C bya wczona (flag t wcza tcp_newtcpcb, jeli zmienna globalna tcp_do_rfcl644 jest rna od zera), flaga T F _ N 0 0 P T wyczona i by segment nie zawiera flagi RST. Ktra konkretnie opcja CC bdzie wysana, zaley to od usta wienia w tworzonym segmencie flag SYN i ACK. S cztery moliwe kombinacje, dwie z nich pokazujemy na rysunku 9.6. (Przedstawiony kod powinien by umie szczony pomidzy liniami 268-269 na stronie 909 tomu 2.)
110
Rozdzia 9
Flaga T F _ N 0 0 P T jest kontrolowana przez opcj gniazda TCP_N00PT. Opcja ta pojawia si w kodzie przedstawionym przez Thomasa Skibo w RFC 1323 (rozdzia 12.7). Jak w spo mniano w tomie 2, flaga T F _ N 0 0 P T (ale nie opq'a gniazda) obecna bya w kodzie Berkeley od czasw 4.2BSD, ale zwykle nie byo sposobu, by flag t wczy. Jeli flaga ta jest ustawiona, TCP nie wysya adnych opqi w segmencie SYN. Opcja T C P _ N O O P T zostaa dodana po to, by umoliwi funkcjonowanie T /T C P w kontakcie z implementacjami TCP, ktre nie s zgodne ze specyfikacj i nie ignoruj nieznanych opcji TCP ( RFC 1323 wprowadza dwie nowe opcje TCP). T /T C P nie zmienia kodu, ktry okrela, czy opcja MSS powinna zosta wysana (strona 908, tom 2). Ten kod nie wysya opcji MSS, jeeli flaga T F _ N 0 0 P T jest ustawiona. Bob Braden stwierdza jednak w RFC 1323, e nie ma w istocie przyczyny, dla ktrej opcja MSS nie powinna by wysyana. Opcja MSS uwzgldniona bya w oryginalnej specyfikacji zawartej w RFC 793.
-----------------------------------------------------------------------------------------------299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327
tcp_output.c
/* * W y s a n a z o s t a j e jedna z opcji CC, jeeli ch c e m y u y w a opcji CC * (TF_REQ_CC), o p c j e s d o z w o l o n e (!TF_N00PT) i n i e j e s t to RST. */ if ((t p - > t _ f 1 ags i ( TF_REQ_CC | T F _ N 0 0 P T ) ) = = T F _ R E Q _ C C && (flags & T H _ R S T ) = 0) ( sw i t c h (flags & (TH_SYN | T H _ A C K ) ) ( /* * Jest to n o r m a l n e A C K (nie SYN); * wysyamy CC, jeeli o t r z y m a l i m y CC od partnera. */ c a s e TH_ACK: if (!(tp- > t _ f l a g s & T F _ R C V D _ C C ) ) break; /* na ko n i e c bloku */ /* * Moemy tu dosta si tylko w stanie S Y N_SENT* protokou * gdy w y s y a m y s e g ment inny ni SYN bez czek a n i a na A C K * segmentu SYN. Wczeniej w tej funkcji sprawdzilimy, e * to tylko, jeeli p a r t n e r r o z u m i e T/TCP. */ c a s e 0; opt[optlen++] = T C P0PT_N0P; opt[optlen++] = T C P0PT_N0P; opt[optlen++] = TCP0PT_CC; optfoptlen++] = T C P 0LEN_CC; * ( u _ i n t 3 2 _ t *) 4 o p t [ o p t l e n ] = h t o n l ( t p - > c c _ s e n d ) ; o p t l e n += 4; break; T/TCP, naszego robimy
------------------------------------------------------------------------------------------------- tcp_output.c Rysunek 9.6 tcp_output-w ysanie jednej z opcji CC, cz pierwsza
Brak flagi SYN, flaga ACK ustawiona
310-313 Jeli flaga SYN jest wyczona, a flaga ACK wczona, mamy do czynienia z normalnym potwierdzeniem (tzn. poczenie jest nawizane). Opcja CC zostaje wysana tylko wtedy, jeli partner przysa opcj CC.
Brak flagi SYN, flaga ACK wyczona
314-320 Obie flagi mog by wyczone tylko w stanie SYN_SENT*, kiedy wysya my segment bez flagi SYN, zanim poczenie zostanie nawizane. Oznacza to, e klient wysya wicej danych ni moe si zmieci w jednym segmencie (liczba bajtw danych wiksza ni MSS). Kod przedstawiony na rysunku 9.2 zapewnia, e
Sekcja 9.2
Funkcja tcp_output
111
sytuacja taka moe si zdarzy tylko wtedy, jeeli partner rozumie T /T C P . Skoro tak, to opcja CC zostaje wysana.
Utworzenie opcji CC
321 -327
Opcja CC zostaje utworzona. Poprzedzona jest ona dwoma rozkazami pu stymi (NOP). Warto cc_send dla tego poczenia zostaje wysana w opcji CC.
Klauzule case odpowiadajce pozostaym dwm kombinacjom flag SYN i ACK pokazane s na rysunku 9.7. -----------------------------------------------------------------------------------------------328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343
tcp_output.c
/* * Jest to nasz i n i c j u j c y SYN (czyli k l i e n t w y k o n u j e a k t y w n e * otwarcie). S p r awdzamy, czy w y s a CC. czy CCnew. */ case T H _ S Y N : o p t [ o p t l e n + + ] = TCPOP T _ N O P ; o p t [ o p t l e n + + ] = T C P0PT_N0P; opt[optlen++] = (t p - > t _ f 1 ags & T F _ S E N D C C N E W ) ? TCP0PT_CCNEW : TCP0PT_CC; o p t [ o p t l e n + + ] = T C P0LEN_CC; * ( u _ i n t 3 2 _ t *) & o p t t o p t l e n ] = h t o n l (t p - > c c _ s e n d ) ; op t l e n += 4; break; /* * Jest to s e g m e n t z SYN i A C K (odpow i e d s e r wera na * o t w a r c i e w y k o n a n e przez klienta). W y s y a m y CC i * jeeli o t r z y m a l i m y od part n e r a if CC lub CCnew. aktywne CCecho,
344
345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 362 363
*/
case (TH_SYN | TH_ACK): if (t p - > t _ f 1ags & T F _ R C V D _ C C ) ( o p t [ o p t l e n + + ] = T C P0PT_N0P; o p t t o p t l e n + + ] = TCP0P T _ N 0 P ; o p t [ o p t l e n + + ] = TCP0PT _ C C ; o p t [ o p t l e n + + ] = T C P0LEN_CC; * ( u _ i n t 3 2 _ t *) & o p t [ o p t l e n ] op t l e n += 4; opt[optlen++] opt[optlen++] opt[optlen++] opt[optlen++] * ( u _ i n t 3 2 _ t *) o p t l e n += 4; = = = = &
= htonl(tp->cc_send);
TCP0P T _ N 0 P ; T C P0PT_N0P; TCP0PT_CCECH0; T C P0LEN_CC; opt[optlen] = htonl(tp->cc_recv);
361
I break;
} hd r l e n += optlen;
-----------------------------------------------------------------------------------------------Rysunek 9.7 tcp_output-w ysanie jednej z opcji CC, cz druga
cp_output.c
Flaga SYN wczona, brak flagi ACK (aktywne otwarcie wykonane przez klienta)
328-340
Flaga SYN jest wczona i brak jest flagi ACK - klient wykonuje aktywne otwarcie. Kod przedstawiony na rysunku 12.3 ustawia flag T F_S E N D C C N E W , jeli powinna by wysana opcja CCnew zamiast opcji CC, i rwnie ustala warto
cc_send.
112
Rozdzia 9
Flagi SYN i ACK wczone (odpowied serwera na SYN klienta)

3 4 1 -3 6 0
Jeli obie flagi, SYN i ACK, s wczone, mamy do czynienia z odpowiedzi na aktywne otwarcie partnera. Jeeli partner wysa opcj CC lub CCnew (flaga T F _ R C V D _ C C jest ustawiona), wysyamy wtedy opcj CC (cc_send) oraz opcj CCecho z wartoci CC otrzyman od partnera (cc_recv).
Korekta rozmiaru danych dla opcji TCP t _ m a x o p d to nowy czon struktury tcpcb. Okrela on maksymaln dugo da nych oraz opcji w zwyym segmencie TCP. Moliwa jest sytuacja, gdy opcje w seg mencie SYN (rysunki 2.2 i 2.3) zajmuj wicej miejsca ni opcje w segmencie innym ni SYN (rysunek 2.4), poniewa opcja skali okna i opcje CC obecne s jednoczenie tylko w segmentach SYN. Kod przedstawiony na rysunku 9.8 kory guje rozmiar danych przeznaczonych do wysania, opierajc si na rozmiarze opcji TCP. Przedstawiony kod zastpuje linie 270-277 na stronie 909 w tomie 2.
-----------------------------------------------------------------------------------------------364 365 366 367 368 369 370 371 372 373 374 375 376 377 /*
k k
tcp_output.c
K o r y g u j e m y d u g o d a n y c h - u m i e s z c z e n i e opcji m o e z m i e n i d u g o p a k i e t u tak, e b dz ie on w i k s z y ni w y n i k a j c y k z t _maxopd. Z e ru j e m y bit FIN, p o n i e w a o b c i n a m y ko ni ec * segmentu. if (len + op t le n > tp - > t _ m a x o p d ) */ flags &= ~ T H _ F I N ; len = t p - > t _ m a x o p d s e n d a l o t = 1; ) - optlen;
*/
/* * Nie z a m yk a p o cz en i a, jeeli p o z o s t a j e j e s z c z e co do
------------------------------------------------------------------------------------------------Rysunek 9.8 tcp_output-korekta rozmiaru danych przeznaczonych do wysania w zalenoci od rozmiaru opcji TCP
3 6 4 -3 7 7
tcp_output.c
Jeeli rozmiar danych (1 en) plus rozmiar opcji jest wikszy ni t_maxopd, ilo danych do wysania jest zmniejszana, flaga FIN wyczana (jeli bya wczo na), a flaga sendal ot zostaje wczona (co wymusza powtrzenie t c p _ o u t p u t po wysaniu aktualnego segmentu).
Ten fragment kodu nie jest specyficzny dla T /T C P . Powinien by uywany dla dowol nych opqi TCP, ktre umieszczane s w segmentach zawierajcych dane (na przykad opq'a znacznika czasu opisana w RFC 1323).
9.3
Podsumowanie
Okoo 100 linii kodu zostaje dodanych wraz z T /T C P do liczcej 500 linii funkcji tcp_output. Wiksza cz wprowadzonych uzupenie dotyczy wysyania no wych opcji T/TC P: CC, CCnew i CCecho. Dodatkowo funkcja t c p _ o u t p u t z T /T C P umoliwia wysyanie wicej ni jednego segmentu w stanie SYN_SENT, pod warunkiem, e partner rozumie T/TC P.
10

10.1 Wstp
W niniejszym rozdziale omawiamy kilka rnych funkcji TCP ulegajcych zmia nom przy wprowadzeniu T/TC P. Zajmiemy si tu funkcjami, ktre nie s om wione w innych rozdziaach. W poprzednim rozdziale opisalimy zmiany w funk cji tcp_output, w nastpnych dwch przedstawimy funkcje t c p _ i n p u t i tcp_usrreq. W tym rozdziale definiujemy dwie nowe funkqe - tcp_rtl ookup i tcp _get t a o c a c h e , ktre przeszukuj pami TAO. Funkcja tc p _ c l ose zostaje zmodyfikowana, tak by dla poczenia, ktre uywao T /T C P, zachowane zostay w tablicy rutowania oszacowane wartoci redniego czasu przesania pakietu w obie strony oraz redniego odchylenia od tej redniej wartoci. W normalnym przypadku wartoci te s okrelone i zapamitane jedynie wtedy, gdy przynajmniej 16 segmentw o penym rozmiarze byo przesanych w czasie poczenia. T /T C P zwykle przesya jednak znacznie mniej danych, a mi mo to wspomniane wartoci powinny by oszacowane i zachowane na podstawie rnych pocze z tym samym partnerem. Opcja MSS jest rwnie inaczej przetwarzana w T/TCP. Z jednej strony zmiany polegaj na zastpieniu jednej, zbyt uniwersalnej funkq'i kodu N et/ 3, t c p_ms s, dwie ma oddzielnymi funkcjami. Jedna z tych funkcji (tcp_msssend) oblicza warto MSS przeznaczon do wysania, druga funkcja (t c p_ms s rc vd) przetwarza otrzyman opcj MSS. T /T C P zapisuje rwnie ostatnio otrzyman od partnera warto MSS w pamici TAO. W ten sposb wysyana opcja MSS moe zosta zainicjowana, gdy T /T C P wysya dane w segmencie SYN, przed otrzymaniem SYN i MSS od serwera. Funkcja tcp_doo pti ons z kodu N e t/3 zostaje zmieniona, tak by rozpoznawaa trzy nowe opcje T/TC P: CC, CCnew i CCecho.
10.2
Funkcja tcp_newtcpcb
Funkcja ta jest woana, gdy danie P R U _ A T T A C H tworzy nowe gniazdo. Pi linii kodu na rysunku 10.1 zastpuje linie 177-178 na stronie 865 w tomie 2. tcp_subr.c
180 181 182 183 184 t p - > t _ m a x s e g = t p - > t _ m a x o p d = t c p _ m ss df lt : if (t cp _ do _ r f c l 3 2 3 ) t p - > t _ f 1 ags = (T F _ R E Q _ S C A L E if (t cp _ do _ r f c l 6 4 4 ) t p - > t _ f 1ags |= TF_REQ_ CC : | T F _ R E Q _ T S T M P );
tcp_snbr.c Rysunek 10.1 Funkcja tcp_new tcpcb-zm iany zwizane z T/TCP
114
Rozdzia 10
180
Tak jak wspomnielimy przy okazji omawiania rysunku 8.3, t _ m a x o p d jest rwna maksymalnej liczbie bajtw danych i opcji TCP wysyanych w kadym segmencie. Zmienna ta, podobnie jak t_maxseg, otrzymuje warto domyln rwn 512 (tcp_mssdfl t). Z faktu, e obie zmienne s rwne, wynika zaoenie, e adne opcje TCP nie s wysyane w segmencie. Na pokazanych dalej rysunkach 10.13 i 10.14 zobaczymy, e t _ m a x s e g zostaje zmniejszona, jeli opcja znacznika czasu lub opcja CC (lub obie te opcje) maj by wysane w kadym segmencie. 183-184 Jeli globalna zmienna t c p _ d o _ r f c l 6 4 4 jest niezerowa (warto domylna tej zmiennej wynosi 1), ustawiona zostaje flaga T F _ R E Q _ C C , co powoduje wysanie przez funkcj t c p _ o u t p u t w segmencie SYN opcji CC lub te CCnew (rysunek
9.6).
10.3
Funkcja tcp.rtlookup
Pierwsz operacj wykonywan przez tcp_ms s (strona 936, tom 2) jest wczytanie m arszruty zachowanej dla aktualnego poczenia (przechowywanej w czonie i n p _ r o u t e internetowego bloku PCB). Jeeli marszruta dla tego poczenia nie zostaa jeszcze znaleziona, wywouje si funkcj r t a l l o c . Operacja wczytania marszruty jest teraz (po zmianach zwizanych z T /T C P) umieszczona w oddziel nej funkcji tcp_rtl ookup pokazanej na rysunku 10.2. Dzieje si tak, poniewa operacja ta jest wykonywana czciej w T/TCP - wpis w tablicy rutowania zawiera bowiem rwnie informacje TAO. 4 3 8 - 4 5 2 Jeeli marszruta dla danego poczenia nie jest jeszcze wyznaczona, m ar szrut znajduje funkcja r t a 11 o c . Marszruta moe jednak zosta wyznaczona tylko wtedy, jeeli adres partnera w bloku PCB jest niezerowy. Dlatego przed wywoa niem rtal 1 oc wypeniona zostaje struktura sockadd r_i n, naleca do struktury
route.
Na rysunku 10.3 przedstawiamy struktur r o u t e .W kadym internetowym bloku PCB zawarta jest jedna taka struktura. Rysunek 10.4 schematycznie ilustruje te struktury. Przyjto, e adres partnera jest 128.32.33.5. ------------------------------------------------------------------------------------------------- tcp_subr.c
432 s t r u c t r t entry * 433 t c p _ r t l o o k u p ( i n p ) 434 str u c t inpcb *inp; 435 ( st r u c t route *ro; 436 st r u c t r t entry *rt; 437 438 439 440 441 442 443 444 445 446 447 448 449 ro = & i n p - > i n p _ r o u t e ; rt = ro->ro_rt; if (rt == NULL) I /* Brak marszr u t y , p r b u j e m y z n a l e m a r s z r u t */ if ( i n p - > i n p _ f a d d r . s _ a d d r != INADDR_ANY) ( ro->ro_dst.sa_family = A F _ I N E T : ro->ro_dst.sa_len = sizeof(ro->ro_dst); ((struct s o c k a d d r _ i n *) & r o - > r o _ d s t )-> s i n _ a d d r = i np->i n p _ f a d d r ; rtalloc(ro); rt = ro->ro_rt;
Sekcja 10.4
Funkcja tcp_gettaocache
115
450 ) 451 r et ur n (rt); 452 )
------------------------------------------------------------------------------------------------R ysu n ek l0.2 Funkcja tcp _ rtlo o k u p ------------------------------------------------------------------------------------------------46 s tr u c t r o ute ( 47 s t r u c t r t e n t r y *ro_rt; 48 s t r u c t s o c k a d d r ro_dst; 49 J :
tcp_subr.c
route.h
/* w s k a n i k do s t r u k t u r y z i nf o r m a c j a m i */ /* ad res p r z e z n a c z e n i a dla tej m a r s z r u t y */
------------------------------------------------------------------------------------------------Rysunek 10.3 Struktura ro u te

inpcbO
route.h
Rysunek 10.4 Marszruta przechowywana w internetowym bloku PCB
10.4
Funkcja tcp_gettaocache
Informacja TAO dla danego hosta jest przechowywana we wpisie do tablicy rutowania dla tego hosta, a dokadniej w polu rmx_f i ller struktury rtjnetri cs (rozdzia 6.5). Pokazana na rysunku 10.5 funkcja t c p _ g e t t a o c a c h e zwraca wskanik do informacji TAO dla danego hosta.
116
Rozdzia 10
45 8 st r u c t rmxp _ t a o * 459 t c p _ g e t t a o c a c h e ( i n p ) 460 s t r u c t inpcb *inp; 461 { 462 st r u c t r t entry *rt = t c p _ r t l o o k u p ( i n p ) ; 463 464 465 466 467 468 )
------------------------------------------------------------------------------- ------------------
tcp_subr.c
/* U p e w n i a m y si, e jest to a k t ywna m a r s z r u t a do hosta. */ if (rt = = NULL || (r t - > r t _ f 1ags & (RTFJJP | R T F _ H 0 S T ) ) != ( RTF_UP I R T F _ H 0 S T )) return (NULL); re t u r n (r m x _ t a o p ( r t - > r t _ r m x ));
-----------------------------------------------------------------------------------------------Rysunek 10.5 Funkcja tcp _ g etta o ca ch e

4 6 0 -4 6 8
tcp_subr.c
Funkcja tcp_rtl ookup zwraca wskanik do odpowiadajcej partnerowi struktury rt e n t ry . Jeli funkcja tcp_rtlookup zostaje wykonana pomylnie i jeli flagi RTFJJP i RTF_H0ST s wczone, to makroinstrukcja rmx_taop (rysunek 6.3) zwraca wskanik do struktury rmxp_tao.
10.5
Obliczenie czasu oczekiwania na powtrzenie transmisji
TCP w N e t/3 oblicza czas oczekiwania na powtrzenie transmisji (RTO) przez pomiar czasu przesania segmentw danych w obie strony i przez ledzenie wy gadzonego" (smoothed) oszacowania RTT (srt) i wygadzonego" redniego od chylenia (rttvar). rednie odchylenie jest dobr estymat redniego odchylenia standardowego i jest atwiejsze do obliczenia ni rednie odchylenie standardowe, poniewa nie wymaga obliczania pierwiastka kwadratowego. W pracy [Jacobsen 1988] podane zostay dodatkowe szczegy pomiarw RTT, co doprowadzio do sformuowania nastpujcych rwna: delta = data - srtt srtt - srtt + g x delta rttvar < rttvar + h ( Idelta I - rttvar) RTO = srtt + 4 x rttvar gdzie delta jest rnic pomidzy wanie zmierzonym czasem przesania w obie strony (data) i aktualn wygadzon" estymat RTT (srtt), g - czynnikiem-wzmocnieniem dla RTT, rwnym 1 /8 , h - wzmocnieniem dla estymaty redniego odchy lenia rwnym 1 /4 . Oba wzmocnienia i czynnik 4 uyty przy obliczeniu RTO nie bez przyczyny s (pod)wielokrotnociami 2 - mog by obliczone przy zastosowa niu operacji przesuwania, zamiast mnoenia lub dzielenia. W rozdziale 25 tomu 2 przedstawiono dokadniej, jak te wartoci s wyznaczane i przechowywane przy uyciu staopozycyjnych liczb cakowitych. W zwykym poczeniu TCP estymaty srtt i rttvar mog by wyznaczone na podstawie wielu zmierzonych wartoci RTT. W przypadku minimalnego pocze nia TCP przedstawionego na rysunku 1.9, dysponujemy przynajmniej dwoma
Sekcja 10.5
Obliczenie czasu oczekiwania na powtrzenie transmisji
117
wartociami RTT. Ponadto w pewnych okolicznociach N e t/3 bdzie przechowy wa i wykorzystywa te dwie estymaty dla rnych pocze pomidzy tymi samymi hostami. Wartoci te aktualizuje i zapisuje funkcja tcp_c1 ose, woana, gdy poczenie zostaje zamknite, jeeli przynajmniej 16 segmentw zostao otrzy manych w ramach tego poczenia i jeeli wpis w tablicy rutowania dla partnera nie jest wpisem domylnym. Estymaty zostaj zapisane w czonach r mx_ rtt i r m x _ r t t v a r struktury r t _me trics znajdujcej si w tablicy rutowania. Przy inicjacji nowego poczenia obie estymaty, srtt i rttvar, otrzymuj wartoci poczt kowe odczytane z wpisu w tablicy rutowania przy pomocy funkcji tc p _ m s s rcvd (rozdzia 10.8). W przypadku pocze T /T C P problem polega na tym, e najkrtsze poczenie umoliwia zmierzenie tylko jednej wartoci RTT, a poniewa zwykle przesya nych jest mniej ni 16 segmentw, wartoci estymat nie s przechowywane pomi dzy rnymi poczeniami dla tych samych partnerw. Oznacza to, e T /T C P nigdy nie moe okreli dobrej estymaty RTO dla pierwszego wysyanego seg mentu. Rozdzia 25.8 w tomie 2 pokazuje, w jaki sposb inicjacja dokonana przez t c p _ n e w t c p c b powoduje, e pierwsza warto RTO wynosi 6 sekund. Spowodowanie, by funkcja tcp_cl ose przechowywaa wygadzone" estymaty dla pocze T /T C P nie jest trudne - nawet gdy odebrano mniej ni 16 segmentw (odpowiednie modyfikacje pokaemy w rozdziale 10.6). Trudno polega na tym, e nie jest jasne jak, w spjny sposb doczy nowe estymaty do wartoci estymat otrzymywanych metod standardow. Niestety, problem ten nie zosta jeszcze rozwizany [Paxson 1995a]. Przeanalizujmy rysunek 10.6, by pozna rne moliwoci. Sto 400-bajtowych diagramw UDP zostao wysanych przez Internet od jednego z hostw autora do serwera echa w innym komputerze. Prba zostaa wykonana w godzinach popo udniowych w zwykym dniu roboczym - jest to zwykle czas najwikszego nat enia ruchu w Internecie. Zwrcone zostay 93 datagramy (7 zagino gdzie w Internecie). Na rysunku 10.6 pokazujemy pierwszych 91 zwrconych datagramw. Prby wykonano w 30-minutowym przedziale czasu i odstpy czasu pomi dzy wysaniem poszczeglnych datagramw byy jednolicie przypadkowo rozo one w przedziale od 0 do 30 sekund. Wartoci RTT zostay otrzymane przy pomocy programu Tcpdump uruchomionego w komputerze klienta. Kropki na rysunku przedstawiaj zmierzone wartoci RTT. Trzy linie cige (RTO, srtt i rttvar, od grnej do dolnej) odpowiadaj wartociom wyznaczonym przy pomo cy wzorw przedstawionych na pocztku obecnego podrozdziau. Obliczenia zostay wykonane w arytmetyce zmiennoprzecinkowej, a nie przy pomocy staopozycyjnych liczb cakowitych uywanych w N et/3. Kada warto RTO pokaza na na rysunku zostaa obliczona przy uyciu wartoci zmierzonej odpowiadajcej danemu punktowi. To znaczy, warto RTO pierwszego punktu (okoo 2200 ms) jest obliczona uywajc pierwszego punktu danych - ta warto RTO zostaaby uyta dla nastpnego wysyanego segmentu.
118
Rozdzia 10
Rysunek 10.6 Pomiar RTT i odpowiadajce wartoci RTO, srtt i rttvar Cho zmierzone RTT wynosi rednio nieco mniej ni 800 ms (system penicy rol klienta jest poczony z Internetem przez telefoniczne cze PPP, a serwer znajduje si na drugim kracu USA), to w 26 pomiarze otrzymano warto niemal 1400 ms, a kilka nastpnych wartoci ukada si w pobliu 1000 ms. Jak zauwaono w pracy [ Jacobson 1994], jeli istniej poczenia jednoczenie uywajce tej samej cieki, chwilowe fluktuacje RTT rzdu podwojonej wartoci minimalnej s zupenie nor malne (odpowiadaj one nawizywaniu lub odnawianiu innych pocze po ich przerwaniu), tak wic warto RTO nie powinna nigdy by mniejsza ni 2 x RTT." W momencie gdy nowe wartoci estymat maj by zapisane w tablicy rutowania, trzeba podj decyzj, jak duy ma by wpyw nowo otrzymanych wartoci na wartoci przechowywane. Uywane s tu wzory: savesrtt = g x savesrtt + (1-g) x srtt saverttvar = g x saverttvar + (1-g) x rttvar Wzory te maj charakter filtru dolno-przepustowego, ze sta g wzmocnienia filtru zawart w przedziale od 0 do 1, a savesrtt i saverttvar s wartociami wpisywanymi do tablicy rutowania. Gdy N e t/3 uaktualnia wpis w tablicy rutowania uywajc tych wzorw (w momencie gdy poczenie zostaje zamknite i przynajmniej 16 wartoci RTT zostao zmierzonych), uywane jest wzmocnienie rwne 0,5: nowa warto wpisana do tablicy rutowania rwna si sumie poowy nowej wyznaczo
Sekcja 10.5__________Obliczenie czasu oczekiwania na powtrzenie transmisji
119
nej wartoci i poowy wartoci wczeniej przechowywanej. W kodzie T /T C P Boba Bradena uywane jest natomiast wzmocnienie rwne 0,75. Na rysunku 10.7 przedstawione zostao porwnanie wynikw zwykych oblicze wykonywanych przez TCP (rysunek 10.6) i wartoci otrzymanych przy uyciu wzmocnienia 0,75. Trzy kropkowane linie prezentuj trzy zmienne z rysunku 10.6 (poczynajc od gry: RTO, srtt i rttvar). Linie cige przedstawiaj trzy odpowied nie zmienne obliczone przy zaoeniu, e kady punkt danych jest oddzielnym poczeniem T /T C P (jeden pomiar RTT na poczenie) i e wartoci wpisane do tablicy rutowania po kadym poczeniu obliczane s ze wzmocnieniem filtra rwnym 0,75. Zwrmy uwag na rnic: przy liniach kropkowanych zakada si pojedyncze poczenie TCP z 91 wartociami RTT zebranymi w cigu 30 minut, podczas gdy przy linii cigej zakada si 91 oddzielnych pocze T /T C P , kade z pojedynczym pomiarem RTT, w cigu tego samego 30-minutowego okresu. Przy liniach cigych zakadamy rwnie, e obie estymaty s uaktualniane w tablicy rutowania po kadym z 91 pocze.
Rysunek 10.7 Porwnanie wygadzania" estymat RTT w TCP i T/TCP Linie cige i kropkowane dla srtt rni si nieznacznie. Dua jest natomiast rnica pomidzy liniami dla rttvar. Linia ciga dla rttvar (T/TC P) ley zwykle wyej ni linia kropkowana (pojedyncze poczenie TCP), co oznacza wikszy czas oczekiwania na powtrzenie transmisji w przypadku T/TC P.
120
Rozdzia 10
Istniej inne czynniki wpywajce na pomiar RTT dokonywany przez T /TC P. Z punktu widzenia klienta zmierzona warto RTT zwykle zawiera czas przetwa rzania pakietu przez serwera. Moe te pojawi si zwoka zwizana z opnionym potwierdzeniem (dehyed-ACK timer) wysyanym przez serwera. W kodzie N e t/3 czas oczekiwania na wysanie opnionego potwierdzenia upy wa co 200 ms, a pomiary RTT wykonywane s w jednostkach 500 ms zlicze zegara, tak wic zwizane z tym opnienie nie powinno by due. Rwnie przetwarzanie segmentw T /T C P odbywa si zwykle z wykorzystaniem powol nej cieki przetwarzania wejcia TCP (slow TCP input processing patii), co moe spowodowa zwikszenie mierzonych wartoci RTT. (Rnica pomidzy powol n i szybk ciek przetwarzania jest jednak prawdopodobnie zaniedbywalna, w porwnaniu z wpywem 200 ms opnionych odpowiedzi.) Wreszcie - w przy padku, gdy wartoci zachowane w tablicy rutowania s stare" (byy na przykad ostatni raz uaktualnione przed godzin) - wynik aktualnego pomiaru powinien by moe po prostu zastpi wartoci w tablicy rutowania w momencie, gdy transakcja zostaje zakoczona (zamiast uaktualniania tych wartoci). Tak jak napisano w RFC 1644, konieczne s dalsze badania efektw dynamicznych TCP, a szczeglnie sposobu wyznaczania wartoci RTT w poczeniach T /TC P.
10.6
Funkcja tcp_close
W kodzie funkcji tcp _ cl ose wymagana jest tylko jedna zmiana: estymaty RTT dla transakcji T /T C P musz by uaktualniane, nawet jeli w trakcie poczenia w y mieniono mniej ni 16 segmentw. Uzasadnilimy konieczno wprowadzenia tej zmiany w poprzednim podrozdziale. Odpowiedni kod przedstawiony jest na rysunku 10.8. --------------------------------- - --------------------------------------------------
25 2 253 254
tcp_subr.c
(
if ( S E Q _ L T ( t p - > i s s + s o - > s o _ s n d .s b _ h i w a t * 16, t p - > s n d _ m a x ) && (rt = i n p - > i n p _ r o u t e . r o _ r t ) & & (( st ru c t s o c k a d d r _ i n *) r t _ k e y ( r t )) - > s i n _ a d d r .s _ a d d r != I N A D D R _ A N Y )
/* s t ro ny
932, 934 w t o mi e 2 */
304 } el se if ( t p - > c c _ r e c v != 0 && 30 5 (rt = i n p - > i n p _ r o u t e . r o _ r t ) && 3 06 (( struct s o c k a d d r _ i n *) r t _ k e y ( r t ) ) - > s i n _ a d d r . s _ a d d r != 1 N A D D R _ A N Y ) { 307 /* 308 * Dla trans ak cj i m u s i m y p r z e c h o w y w a w ar t o c i s rt t i rt tv ar 309 * nawet, jee li nie ma m y " w y s t a r c z a j c y c h danych. 31 0 */ 311 31 2 313 314 31 5 31 6 317 u _l on g i;
if (( r t - > r t _ r m x .rm x _ l o c k s & RT V_ R TT ) = = 0 ) ( i = tp->t_srtt * (R T M _ R T T U N I T / ( PR _ SL 0W HZ * T C P _ R T T _ S C A L E )); if ( r t - > r t _ r m x . r m x r t t && i) /* * Fi ltr a kt u al i z a c j i : 3/4 starej wa rt o c i plus
Sekcja 10.7
Funkcja tcp_msssend
121
318 319 320 321 3 22 323 324 325 326 327 328 329 330 331 332 333 334
* 1/4 nowej. Z m i e n i a m y skal. */ rt->rt_rmx.rmx_rtt = (3 * r t - > r t _ r m x . r m x _ r t t + i) / 4; el se r t - > r t _ r m x .r m x _r tt = i; 1 if ( ( r t - > r t _ r m x .rm x _ l o c k s & R T V_ R TT VA R) = = 0) ( i = tp->t_rttvar * ( R T M _ R T T U N I T / (P R_ SL 0 WH Z * T C P _ R T T V A R _ S C A L E ) ); if (r t - > r t _ r m x . r m x _ r t t v a r && i) rt->rt_rmx.rmx_rttvar = (3 * r t - > r t _ r m x .r m x _ r t t v a r + i) / 4; else r t - > r t _ r m x .r m x _ r t t v a r = i;
] )
-----------------------------------------------------------------------------------------------tcp_subr.c Rysunek 10.8 Funkcja tcp _ cl os e-aktualizacja estymat RTT dla transakcji T/TCP
Aktualizacja tylko dla transakcji T/TCP 304-311
Wartoci zapisane w tablicy rutowania zostaj uaktualnione tylko wtedy jeli dla danego poczenia uywany jest protok T /T C P (cc_recv jest rna od zera), odpowiedni wpis w tablicy rutowania istnieje i marszruta nie jest marszrut domyln. Ponadto, obie estymaty RTT zostaj zaktualizowane, tylko jeeli nie s one zablokowane (locked) (bity RT V _ R T T i RTV_RTTVAR).
Aktualizacja RTT
312-324 Warto t_s rtt oznacza liczb 500 ms zlicze zegara pomnoon przez 8, a r mx_rtt jest wyraana w mikrosekundach. Dlatego t_s rtt zostaje pomnoona przez 1 000 000 (RTM_RTTU NIT) i podzielona przez 2 (zliczenia zegara na sekund) razy 8. Jeeli warto rmx_rtt ju istnieje, to nowa warto jest rwna 3 / 4 starej
wartoci plus 1 / 4 nowej. Jest to wspomniane w poprzednim podrozdziale wzmoc nienie filtra 0,75. W przeciwnym przypadku, gdy brak jest wczeniejszej wartoci rmx_rtt, zapisana zostaje aktualnie wyznaczona warto.
Aktualizacja redniego odchylenia 325-334
Ten sam algorytm zostaje uyty dla estymaty redniego odchylenia. W ar to ta jest rwnie wyraana w mikrosekundach, co wymaga zamiany jednostek - warto t_r 11 v a r wyraana jest w jednostkach odpowiadajcych liczbie zlicze zegara pomnoonej przez 4.
10.7
Funkcja tcpjnsssend
W kodzie N e t/3 istnieje jedna funkcja t c p_ms s (rozdzia 27.5, tom 2) woana przez tcp_i nput, gdy przetwarzana jest opcja MSS, oraz przez tcp_output, gdy opcja MSS ma by wysana. W kodzie rozszerzonym o T/T C P, ta istniejca wczeniej funkcja otrzymuje now nazw - tcp_mss rcvd i jest wywoywana z tcp_i nput po otrzymaniu segmentu SYN (niezalenie od tego, czy segment SYN zawiera opcj MSS, czy nie, jak pokazane zostanie pniej na rysunku 10.18). Funkcja ta jest
122
Rozdzia 10
rwnie wywoywana dla da P R U _ S E N D i P R U _ S E N D _ E O F (rysunek 12.4), gdy poczenie jest niejawnie otwierane lub zamykane. Nowa funkcja tcp _msssend, ktr pokazujemy na rysunku 10.9, wywoywana jest wycznie przez tcp _o u t put, gdy wysana ma by opcja MSS.
1911 int 1912 t c p _ m s s s e n d ( t p ) 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 ) (
-------------------------------------------------- ----- ---------------------------------------
tcp_input.c
1913 struct tcpcb *tp:

s truct r t e n t r y * r t ; ex t e r n int t c p _ mssdflt; rt = tcp r t l o o k u p ( t p - > t inpcb); if (rt = = N U L L ) return (t c p _ m s s d f l t ) ; /* * Jeeli istnieje w a r t o MTU dla tej m a r s z r u t y - u y w a m y jej * Jeeli nie - u ywamy MTU w y s y a j c e g o interfejsu. */ if ( r t - > r t _ r m x .r m x _ m t u ) return (r t - > r t _ r m x .r m x _ m t u - s i z e o f t s t r u c t tcpip h d r ) ) ; return ( r t - > r t _ i f p ->if_mtu - s i z e o f t s t r u c t t c p i p h d r ) ) ;
------------------------------------------------------------------------------------------------Rysunek 10.9 Funkcja tcp_mss send-zwrcona zostaje ivarto MSS, ktra ma by wysana iv opcji MSS
Odnalezienie wpisu w tablicy rutowania
tcp_input.c
1917-1919 Tablica rutowania jest przegldana w poszukiwaniu wpisu odpowiadaj cego partnerowi. Jeli taki wpis nie moe by znaleziony, zwracana jest warto domylna rwna 512 (tcp_mssdf 11). Odpowiedni wpis w tablicy rutowania po winien zawsze zosta odnaleziony, chyba e partner jest nieosigalny.
Zwrcenie wartoci MSS
1920-1926 Jeeli tablica rutowania zawiera odpowiedni warto MTU (w czonie rmx_mtu struktury rt_metrics - wpisana przez administratora systemu przy pomocy programu route), to warto ta zostaje zwrcona. W przeciwnym przy padku zwracana warto rwna si wartoci MTU dla interfejsu wyjciowego pomniejszonej o 40 (na przykad 1460 dla Ethernetu). Interfejs wyjciowy jest znany, poniewa marszruta zostaa wyznaczona przez tcp_rtl ookup.
Innym sposobem zapisania wartoci MTU w tablicy rutowania jest tzw. wyznaczenie cieki MTU {path M TU discovery) (rozdzia 24.2, tom 1). W kodzie N e t/3 metoda ta nie jest jednak jeszcze dostpna.
Dziaanie przedstawionej funkcji rni si od normalnego dziaania BSD. Kod N et/3 (strona 938 tomu 2), dla nielokalnego partnera (wedug funkcji i n_l ocal addr) z metryk rmx_nitu rwn zero, zawsze informuje, e MSS wynosi 512 (tcp_mssdf 11). Zadaniem opcji MSS jest poinformowanie hosta na drugim kocu poczenia, jak duy segment jest w stanie zaakceptowa host wysyajcy opcj. W RFC 793
Sekcja 10.8
Funkcja tcp_mssrcvd
123
stwierdza si, e opcja MSS informuje, jaki jest maksymalny rozmiar otrzymane go segmentu dla moduu TCP wysyajcego ten segment". W niektrych imple mentacjach ograniczeniem moe by maksymalny rozmiar datagramu IP, ktry host jest w stanie odtworzy. W wikszoci wspczesnych systemw rozsdny limit wynika jednak z wartoci MTU dla interfejsu wyjciowego, poniewa szyb ko dziaania TCP istotnie maleje w przypadku fragmentacji, gdy fragmenty zaczynaj by gubione. Nastpujce komentarze pochodz ze zmian w kodzie rdowym, wprowadzo nych na potrzeby T /T C P przez Boba Bradena: Uywanie opcji TCP wymaga, niestety, wprowadzenia istotnych zmian w BSD, poniewa obsuga opcji MSS w tym kodzie bya niepoprawna. Kod BSD zawsze wysya opcj MSS i dla nielo kalnej sieci opcja ta zawieraa warto 532. Takie zachowanie wynika z niezrozu mienia roli opcji MSS, ktra powinna informowa wysyajcego partnera o tym, co odbierajcy partner jest w stanie obsuy. Wysyajcy host powinien wic zadecy dowa, jaka warto MSS ma by uywana, biorc pod uwag zarwno warto MSS, ktr otrzyma, jak i ciek (pcith). Jeeli stosujemy wyznaczanie MTU (M TU discovery), cieka bdzie prawdopodobnie miaa warto MTU wiksz ni 536; w takim przypadku sposb uycia opcji przez BSD zmniejsza przepustowo. Std procedura ta jedynie wyznacza warto MSS, ktra ma by WYSANA: warto MTU dla lokalnego interfejsu minus 40." (Zamiast wartoci 536 w powy szych komentarzach powinno by 512.) W nastpnym podrozdziale (rysunek 10.12) zobaczymy, e to host odbierajcy opcj MSS ogranicza warto MSS do 512 bajtw, jeeli partner nie jest lokalny.
10.8
Funkcja tcp_mssrcvd
Funkcja t c p _ m s s r c v d jest woana przez t c p _ i n p u t po otrzymaniu segmentu SYN, a take - przy poczeniu nawizywanym niejawnie - dla da P RU_S E N D i PRU_SEND_E0F. Funkcja ta jest podobna do tcp_mss, rnice s jednak na tyle due, e musimy zaprezentowa kod rdowy caej funkcji. Gwne zadanie tej funkcji to ustalenie wartoci dwch zmiennych - t_ m a x s e g (maksymalna ilo danych wysyanych w jednym segmencie) i t _ m a x o p d (maksymalna ilo danych plus rozmiar opcji wysyanych w jednym segmencie). Pierwsza cz kodu przed stawiona zostaa na rysunku 10.10. ------------------------------------------------------------------------------------------------17 55 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 void t c p _ m s s r c v d ( t p , offer) s tr u ct tcp cb *tp; int offer; ( s truct rten tr y *rt: s t ru ct i fnet *i f p ; int rtt, mss; u _ lo ng bufs i z e ; struct inp cb *inp; s t ru ct s o ck et *so; s t ru ct rm x p _ t a o *taop;
tcpjnput.c
124
Rozdzia 10
1767 1768 1769 1770 1771 1 77 2 17 73 17 74 17 75 17 76 1777 17 78 17 79 17 80 1781 17 82 17 83 1784 1 78 5 17 86 1787 17 88 17 89 1 79 0 1791 1792 1793 1794 17 95 1796 1797 17 98 17 99
int o r i g o f f e r = offer; e x t e r n int t c p _ m s sd fl t ; e xt er n int t c p _ d o _ r f c l 3 2 3 ; e xt e rn int t c p _ d o _ r f c l 644; inp = t p- >t _ in pc b; if ((rt = t c p _ r t l o o k u p ( i n p ) ) = = NULL) I t p - > t _ m a x o p d = t p - > t _ m a x s e g = tc p _m ss df l t; return; ) ifp = rt- >r t _i fp ; so = i n p - > i n p _ s o c k e t ; taop = r m x _ t a o p ( r t - > r t _ r m x ) ; /* * O f f e r = = -1 o zn a cz a, e nie o t r z y m a l i m y j e s z c z e s e g m e n t u SYN; * w t a k im p r z y p a d k u u y wa m y w ar to ci z a ch o wa ne j. */ if ( offer = = -1) of f e r = t a o p - > t a o _ m s s o p t ; /* * O f f e r = = 0 oznacza, e w s e g m e n c i e SYN n ie byo wa rt o c i MSS * or az brak w ar to ci z a ch ow an e j w pamici TAO. Uywamytcp_mssdflt. */ if ( offer = = 0) of f e r = tcp_mss df l t; else /* * S p r a w d z e n i e s e n s o w no c i : ma x o p d musi by na ty le due, * by w s e g m e n c i e mo g y z n a j d o w a si j ak ie d a n e - n a w et jeeli * uy ta je st caa p r z e s t r z e p r z e z n a c z o n a na o p c j e (40 bajtw). *Jeli nie - w t c p _ o u t p u t mo g si d z i a d z i w n e rzeczy. */ of f e r = ma x (o f f e r , 64); t a o p - > t a o _ m s s o p t = offer;
------------------------------------------------------------------------------------------------Rysunek 10.10 Fimkcja t cp_ms srcvd, cz pierwsza

Odnalezienie marszruty i informacji TAO dla partnera
17 71 -1 7 7 7
tcpjnput.c
Fimkcja tcp_rtl ooku p znajduje marszrut do partnera. Jeli z jakich przyczyn to si nie udaje, zmienne t_ m a x s e g i t _ m a x o p d otrzymuj obie warto
512 (tcp_mssdfl t).
17 78 -1 7 9 9
taop wskazuje na informacje TAO dla danego partnera zawart w tablicy rutowania. Jeli t c p _ m s s r c v d jest wywoana, poniewa proces wywoa s e ndt o (niejawne otwarcie poczenia, jako cz dania P R U _ S E N D lub PRU_SEND_E0F), zmienna off er otrzymuje warto odczytan z pamici TAO. Jeli ta warto z pamici TAO wynosi 0, off er otrzymuje warto 512. Warto w pamici TAO zostaje uaktualniona. Nastpna cz funkcji pokazana na rysunku 10.11 jest taka sama jak kod przedsta wiony na stronie 937 w tomie 2. ------------------------------------------------------------------------------------------------1800 1801 1802 1003 1804 1805 1806
tcpjnput.c
/* * S p r aw dz am y , czy is tn i e j e p o c z t k o w a w a r t o rtt lub rtt var. * Z a m i e n i a m y j ed n os tk i: z j e d n o s t e k u y w a n y c h w t a b l i c y rutowania * na w i e l o k r o t n o ok r es u p o w o l n e g o zegara. */ if ( t p - > t _ s r t t = = 0 && (rtt = r t - > r t _ r m x . r m x _ r t t ) ) l /*
Sekcja 10.8
Funkcja tcp_mssrcvd
125
1807 * XXX bit b l o k o w a n i a (lock) dla RTT oznac za , e je st to r w n ie 1 80 8 * warto mi ni ma l n a . To zmi e ni a si z czasem. 1809 */ 18 10 if (r t - > r t _ r m x . r m x _ l o c k s &RTV_RTT) 1811 t p - > t _ r t t m i n = rtt / (R T M _ R T T U N I T / PR_S L0 WH Z ); 1812 t p - > t _ s r t t = rtt / (R T M _ R T T U N I T /(P R_ SL 0 WH Z * T C P _ R T T _ S C A L E )); 1813 if ( r t - > r t _ r m x . r m x _ r t t v a r ) 1814 tp->t_rttvar = rt->rt_rmx.rmx_rttvar / 18 15 (R TM _ R T T U N I T / (P R_ S L O W H Z * T C P _ R T T V A R _ S C A L E )); 18 16 else 1817 / * d o m y l n y w a r i a n t jest +- 1 rtt */ 18 18 tp->t_rttvar = 18 19 t p - > t _ s r t t * T C P _ R T T V A R _ S C A L E / T C P _ R T T _ S C A L E ; 1 82 0 TCPT_RANGESET(tp->t_rxtcur. 1821 ( ( t p - > t _ s r t t 2) + t p - > t _ r t t v a r ) 1, 1822 tp-> t_ r tt mi n , T C P T V _ R E X M T M A X ): 1 82 3 )
-----------------------------------------------------------------------------------------------Rysunek 10.11 Funkcja tcp _ m ssrcv d - inicjacja zmiennych RTT wartociami z tablicy rutozuania
1 300-1823
tcp_input.c
Jeli brak wczeniejszych pomiarw RTT dla danego poczenia (t_ s rtt wynosi 0), a metryka rmx_rtt jest niezerowa, wtedy zmienne t_s rtt, t_rttva r i t_rxtcur zostaj zainicjowane wartociami z tablicy rutowania. 1806-1811 Jelibit R TV_RTT we fladze blokowania w tablicy rutowania (ro u t in g metric lock f l a g ) jest ustawiony, oznacza to, e warto rmx_rtt powinna by rwnie uywana do inicjacji wartoci minimalnej RTT dla tego poczenia (t_rttmin). t_rttmi n otrzymuje warto domyln odpowiadajc dwm zliczeniom zegara (tick). W ten sposb administrator systemu moe zmieni warto domyln. Nastpna cz funkcji tcp_mssrcvd (rysunek 10.12) ustala warto lokalnej zmiennej dynamicznej mss. --------------------- - --------------------------------------------------------------- tcp_input.c
1824 1825 1826 1827 1 82 8 1829 1 83 0 1831 1832 1833 1834 1835 18 36 1837 18 38 18 39 18 40 1841 1842 /* * W y k o r z y s t u j e m y w a r t o MTU dla da nej ma r sz r u t y , jeeli if ( r t - > r t _ r m x . r m x _ m t u ) mss = r t - > r t _ r m x . r m x _ m t u - s i z e o f (s t ru ct t c pi ph dr ) ; else mss = i f p - > i f _ m t u - s i z e o f t s t r u c t tcpiphdr); if ( ! i n _ l o c a l a d d r ( i n p - > i n p _ f a d d r ) ) mss = mi n tmss, t c p _ m s s d f 1 t ); } mss = min tmss, /* * t _ m a x o p d to m a k s y m a l n a d u g o d an yc h ORAZ opcji w s eg m en c i e . * t _ m a x s e g to ilo da n y c h w n o r m a l n y m segmencie. * Musimy przechowywa t _m a x o p d w u z u p e n i e n i u do t_ma x se g, * p o n i e w a teraz kady s e g m e n t moe z a w i e r a opcje. * D l a te g o m a m y teraz z wy kl e niec o mniej da n y c h w se gm e nc ie . */ tp->t_maxopd = mss; offer); ( i stnieje. */
------------------------------------------------------------------------------------------------Rysunek 10.12 Funkcja tcp_m ssrcvd-obliczenie wartoci zmiennej
tcp_input.c
126
Rozdzia 10
1824-18 34
Jeeli istnieje warto MTU zwizana z dan marszrut (metryka
rmx_mtu), to ta warto jest uywana. W przeciwnym razie mss oblicza si jako
warto MTU interfejsu wyjciowego minus 40. Dodatkowo, jeli partner znajduje si w innej sieci lub - by moe - w innej podsieci (zgodnie z informacj z funkcji in_l ocal addr), to maksymalna warto mss wynosi 512 ( t cp_m ssdf 11). Nie sprawdza si, czy poczenie jest lokalne, jeli warto MTU znajduje si we wpisie do tablicy rutowania.
Ustalenie wartoci t_maxopd
1835 -18 42
t _ m a x o p d otrzymuje warto rwn mss, czyli maksymalny rozmiar seg mentu, cznie dane i opcje.
Nastpny fragment kodu pokazany na rysunku 10.13 zmniejsza warto ms s o roz miar opcji, ktre pojawi si w kadym segmencie. ------------------------------------------------------------------------------------------------1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1 85 8 18 59 18 60
tcp_inpu.c
/* * K o r y g u j e m y mss, tak by byo m i e j s c e na opcje. W y w o a n i e tej funkcji * n a s t p u j e z koca t c p _ d o o p t i o n s , m o e m y w i c uy flag * R EQ/RCVD, by spraw dz i , czy o p cj e b d uywane. */ /* * Dla T/TCP, o r i g o f f e r == -1 o zn acza, e nie o d e b r a n o j e s z c z e a d ny ch * s e g m e n t w (tzn. k l i e n t w y w o a sendto). W t ym p r z y p a d k u po p r o s t u * z ga d uj e m y , w p r z e c i w n y m r azie r ob im y to, co p r z ed T /TCP. */ if ( (t p - > t _ f 1ags & (T F _ R E Q _ T S T M P | TF_N00PT)) = = T F _ R E Q _ T S T M P && ( o r i g o f f e r = = -1 I | (t p->t flags & T F _ R C V D _ T S T M P ) = = T F _ R C V D _ T S T M P ) ) mss -= T C P 0 L E N _ T S T A M P _ A P P A ; if ( (t p - > t _ f 1ags & (T F _ R E Q _ C C | TF_N00PT)) == TF_REQ_CC ( o r i g o f f e r = = -1 I| (t p - >t _ f 1 ags & T F _ R C V D _ C C ) == T F _ R C V D _ C C ) ) mss -= T C P O L E N _ C C _ A P P A ; &&
1861 y/i f ( M C L B Y T E S & ( M C L B Y T E S - 1)) = = 0 1862 if (mss > M C L BY TE S) 18 63 mss &= - ( M C L B Y T E S 1): 1 86 4 # e l s e 1 86 5 if (mss > M C L B Y T E S ) 18 66 mss = mss / M C L B Y T E S * M C L B YT E S; 1867 # e n d i f
------------------------------------------------------------------------------------------------tcp_input.c R ysun ek l0.13 Funkcja tcp_m ssrcvd-zm niejszenie ms s w zalenoci od opcji
Zmniejszenie mss, jeeli opcja znacznika czasu bdzie uywana

1 8 4 3 -1 8 5 6
Warto mss zostaje zmniejszona przez rozmiar opqi znacznika czasu (TC P0 LE N_TSTAMP_AP PA, czyli 12 bajtw), jeeli speniony jest ktry z poniszych warunkw: nasz koniec poczenia zada opcji znacznika czasu (TF_REQ_TSTAMP), a nie otrzymalimy jeszcze opcji MSS od hosta na drugim kocu poczenia (origo ffer jest rwne -1),
Sekcja 10.8
Funkcja tcp_mssrcvd
127
otrzymalimy opcj znacznika czasu z drugiego koca poczenia. Tak jak zaznacza komentarz w tekcie programu, drugi z warunkw jest popraw ny, poniewa t c p_m s s r c v d jest woana na kocu t c p_d o o p t i o n s, po przetworze niu wszystkich opcji.
Zmniejszenie mss, jeli uywana bdzie opcja CC
1 85 7-1 860
Podobny algorytm moe zmniejszy warto mss o 8 bajtw (TCPO-
LEN_CC_APPA).
Symbol A P P A w wymienionych powyej dwch nazwach pochodzi std, e dodatek A (Appendix A) w RFC 1323 zawiera sugesti, by opcja znacznika czasu bya poprzedzona dwoma rozkazami pustymi (NOP), tak by poprawnie umieci w czterobajtowych grani cach czterobajtow warto znacznika czasu. Cho RFC 1644 zawiera dodatek A, nie ma tam nic na temat rozmieszczania opcji w czterobajtowych granicach. Jednake poprze dzenie kadej z trzech opq'i CC dwoma rozkazami pustymi jest sensowne - pokazalimy to na rysunku 9.6.
Obcicie MSS do wielokrotnoci MCLBYTES

18 61 -1 8 6 7
Warto mss jest zaokrglona w d do wielokrotnoci MCLBYTES, czyli do rozmiaru klastra mbuf wyraonego w bajtach (najczciej 1024 lub 2048).
W tym fragmencie kodu w zawikany i nieelegancki sposb usiuje si zoptym alizowa dziaanie program u przez uywanie operacji logicznych, zamiast mnoenia i dzielenia, jeli M C L B Y T E S jest wielokrotnoci 2. Fragm ent ten wywodzi si z N e t /l i powinien zosta przeredagowany.
Na rysunku 10.14 przedstawiona zostaa ostatnia cz tcp _mssrc vd, w ktrej ustalony zostaje rozmiar buforw wysykowego i odbiorczego.
Modyfikacja rozmiaru bufora wysykowego gniazda
1 86 8-1 883
Wartoci metryk r m x _ s e n d p i p e i r m x _ r e c v p i p e mog zosta ustalone przez administratora systemu za pomoc programu route. Zmienna b u f s i z e otrzymuje warto rwn wartoci metryki rmx _sendpi pe (jeli metryka taka zostaa zdefiniowana), lub rwna jest aktualnej wartoci ograniczenia wypenienia (high-water mark) bufora wysykowego gniazda. Jeli warto b u f s i z e jest mniej sza ni mss, to warto mss zostaje zmniejszona do wartoci bufsize. (Jest to metoda na wymuszenie dla danego adresu przeznaczenia mniejszej wartoci MSS ni warto domylna.) W przeciwnym razie warto b u f s i z e jest zaokrglana w gr do najbliszej wielokrotnoci mss. (Rozmiar bufora gniazda powinien by zawsze wielokrotnoci rozmiaru segmentu.) Grnym ograniczeniem jest warto sb_max, ktra w kodzie N e t/3 wynosi 262 144. Ograniczenie wypenienia bufora gniazda ustalone zostao przez sbreserve.
Ustalenie wartoci t_maxseg
1884
Zmiennej t _ m a x s e g przypisana zostaje warto rwna rozmiarowi danych (bez zwykych opcji), ktre TCP bdzie wysya do partnera.
128
Rozdzia 10
tcp_input.c
1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 /* * Jeeli i s tn i e j e " p i p e s i z e . p r z y j m u j e m y taki w a n i e r o z m i a r bufoi gniazd a . R o z m i a r b u f o r w g n i a zd a ma by c a k o w i t w ie l o k r o t n o c i ; mss. Jeeli mss jest w i k s z e ni r o z m i a r b ufora gniazd a , * to z m n i e j s z a m y mss. */ if' ( ( b uf s iz e = r t - > r t _ r m x . r m x _ s e n d p i p e ) = = 0) bufsize = so->so_snd.sb_hiwat; if C bu fs i ze < mss) mss = bufsize; el se l b u f s i z e = r o u n d u p t b u f s i z e , mss); if ( bu f s i z e > sb_max) b u f s iz e = sb_max; (v o i d ) s b r e s e r v e ( & s o - > s o _ s n d , bufs ize); } tp -> t _m a x s e g = m s s ; if ( ( b u fs iz e = r t - > r t _ r m x . r m x _ r e c v p i p e ) == 0) bufsize = so->so_rcv.sb_hiwat; if ( bu fs i z e > mss) ( b u f s i z e = r ou n d u p ( b u f s i z e , mss); if ( bu f s i z e > sb_max) b u f s i z e = sb_max; (void) s b r e s e r v e ( & s o - > s o _ r c v , b ufsize); } /* k Don t force s l o w - s t a r t on local net work. k / if ( ! i n _ l o c a l a d d r ( i n p - > i n p _ f a d d r ) ) t p - > s n d _ c w n d = mss; if ( r t - > r t _ r m x . r m x _ s s t h r e s h ) ( /* * I s tn i e j e j akie o g r a n i c z e n i e na rozmi a r bu fo ra dla tej c ie k * U y w a m y go do ok r e l e n i a l i mitu p o w o l n e g o startu, li mit ten * u s t a l a m y j e d n a k na w a r t o nie m n i e j s z ni 2*mss. * */ t p - > s n d _ s s t h r e s h = m a x ( 2 * mss, r t - > r t _ r m x . r m x _ s s t h r e s h ) ; I )
-----------------------------------------------------------------------------------------------Rysunek 10.14 Funkcja tcp _m ssrcv d - ustalenie rozmiaru buforw wysykowegoi odbiorczego
Modyfikacja rozmiaru bufora odbiorczego gniazda
tcpjnput.c
1885-1892 Podobny sposb postpowania zostaje zastosowany w przypadku ograni czenia wypenienia bufora odbiorczego gniazda. Na przykad, dla lokalnego po czenia wykorzystujcego Ethernet - przy zaoeniu, e uywane s opcje znaczni ka czasu oraz opcje CC - warto t_maxopd wyniesie 1460, a warto t_maxseg bdzie rwna 1440 (rysunek 2.4). Rozmiary buforw gniazda odbiorczego i wysy kowego zostan zaokrglone w gr od wartoci domylnych rwnych 8192 (ry sunek 16.4, strona 493, tom 2) do wartoci 8640 (1440 x 6).
Start w trybie powolnym dla nielokalnego partnera
1893-1897 Jeli partner nie znajduje si w sieci lokalnej (i n_l ocal addr zwraca war to fasz") zainicjowany zostaje powolny start. Rozmiar okna przecienia (eongestion window), snd_cwnd, ustalany jest na jeden segment.
Sekcja 10.9
Funkcja tcp_dooptions
129
Wymuszanie powolnego startu tylko dla nielokalnego partnera jest zmian w prow adzo n wraz z T /T C P. Umoliwia to klientowi lub serwerowi T /T C P wysanie wicej ni jednego segmentu do lokalnego partnera, bez naraania si na dodatkowe opnienia zwizane z przesyaniem segmentw w obie strony, co jest wym agane w trybie powolne go startu (rozdzia 3.6). W kodzie N e t/3 zawsze wykonywany jest powolny start.
Ustalenie progu powolnego startu 1898-1906
Jeli metryka progu powolnego startu r m x _ s s t h r e s h (slow start threshold) jest niezerowa, to zmiennej s n d _ s s t h r e s h przypisana zostaje warto tej metryki. Zaleno pomidzy rozmiarem bufora odbiorczego z MSS a pamici TAO moe my przeledzi na rysunkach 3.1 i 3.3. Na pierwszym rysunku klient wykonuje niejawne otwarcie poczenia, danie PRU_SEND_EOF wywouje funkcj t c p _ m s s r c v d z wartoci of fer rwn -1 i funkcja znajduje t a o _ m s s o p t rwne 0 dla serwera (poniewa klient wanie zosta przeadowany). Uyta zostaje warto domylna 512. Poniewa uywana jest jedynie opcja CC (w przykadach w roz dziale 2 wyczylimy znaczniki czasu), warto ta ulega zmniejszeniu o 8 bajtw (rozmiar opcji), co daje warto 504. Zauwamy, e zaokrglenie liczby 8192 w gr do wielokrotnoci 504 daje 8568, i to jest rozmiar okna podawany przez klienta w jego segmencie SYN. Jednake serwer, wywoawszy tcp_ms srcvd, otrzyma SYN klienta z wartoci MSS rwn 1460. Warto ta zostaje zmniejszona o 8 bajtw (rozmiar opcji), dajc 1452, a 8192 zaokrglone w gr do wielokrotno ci 1452 daje 8712. Taki te rozmiar okna serwer podaje w swoim segmencie SYN. Gdy klient przetwarza segment SYN serwera (trzeci segment na rysunku), funkcja t c p _ m s s r c v d zostaje wywoana ponownie, tym razem z wartoci off er rwn 1460. To zwiksza warto t _ m a x o p d klienta do 1460, warto t _ m a x s e g klienta rwna jest 1452, a zaokrglony w gr rozmiar bufora odbiorczego klienta wynosi 8712. Taki rozmiar okna klient podaje w potwierdzeniu segmentu SYN serwera. Na rysunku 3.3, gdy klient wykonuje niejawne otwarcie poczenia, warto tao_m ssopt wynosi teraz 1460. Jest to ostatnia warto otrzymana od partnera. Klient podaje rozmiar okna rwny 8712, co jest wielokrotnoci liczby 1452, wi ksz ni 8192.
10.9
Funkcja tcp_dooptions
W kodzie N e t/l oraz N e t/2 funkcja t c p _do opti ons rozpoznawaa jedynie opcje NOP, EOL i MSS i miaa trzy argumenty. W kodzie N e t/3 wprowadzono opcje skali okna i znacznika czasu, co spowodowao, e liczba argumentw funkcji wzrosa do siedmiu (strona 972 w tomie 2). Trzy z tych argumentw zwizane byy z opcj znacznika czasu. Wprowadzajc teraz opcje CC, CCnew i CCecho zrezygnowano z dodawania kolejnych argumentw funkcji, przeciwnie - liczba argumentw zostaa zmniejszona do 5 i zastosowano inn technik zwracania informacji o tym, jakie opcje s obecne oraz jakie maj wartoci. Na rysunku 10.15 pokazano struktur tcpopt. Struktura taka jest alokowana w tcp_i nput (jedyna funkcja woajca tcp_doo pti ons) i wskanik do tej struktu-
130
Rozdzia 10
ry jest przekazywany do funkcji tcp_doop tions , ktra wpisuje odpowiednie wartoci w pola struktury. t c p _ i n p u t uywa wartoci zawartych w strukturze w czasie przetwarzania otrzymanego segmentu. -----------------------------------------------------------------------------------------------138 st r u c t tcpopt ( 139 u J ong t o _ f 1 a g ; 140 u_long to_tsval; 141 u_ l o n g to_tsecr; 142 tc p _ c c to_cc; 143 tc p _ c c to_ccecho; 144 ) /* /* /* /* /*
tcp_var.h
flagi T 0 F _ x x x */ w a r t o zna c z n i k a cza s u */ o d p o w i e d "echo" z n a c z n i k a c z asu */ w a r t o CC lub C C n e w */ w a r t o CC e c h o */
-----------------------------------------------------------------------------------------------Rysunek 10.15 Struktura tcpopt, wypeniana wfunkcji tcp_doopti ons
tcp_var.h
Rysunek 10.16 pokazuje cztery wartoci, ktre mog by umieszczone w czonie t o _ f 1 ag.
to _flag Opis obecna jest opcja CC obecna jest opcja CCnew obecna jest opcja CCecho obecna jest opcja znacznika czasu
T0F_CC T0F_CCNEM T0F_CCECH0 T0F_TS
Rysunek 10.16
Wartoci t o _ fla g
Na rysunku 10.17 przedstawiamy deklaraq funkcji wraz z argumentami. Pierw sze cztery argumenty s takie same jak w N e t/3 , natomiast ostatni argument zastpuje trzy ostatnie argumenty z kodu N et/3. ------------------------------------------------------------------------------------------------1520 1521 1522 1523 1524 1525 1526 1527 void t c p _ d o o p t i o n s ( t p , cp, cnt, t i , to) struct t c pcb *tp; u_char *cp; int cnt; struct t c p i p h d r *ti; struct tc p o p t *to: I
tcp_input.c
-----------------------------------------------------------------------------------------------Rysunek 10.17 Funkcja tcp_doopti ons - argumenty
tcp_input.c
Nie bdziemy omawia tu przetwarzania opcji EOL, NOP, MSS, skali okna i zna cznika czasu, poniewa odpowiedni kod jest niemal taki sam jak na stronach 972-973 w tomie 2. (Rnice dotycz nowego sposobu przekazywania argumen tw, omawianego powyej.) Na rysunku 10.18 przedstawiony jest kocowy frag ment funkcji odpowiedzialny za przetwarzanie trzech nowych opcji T/TCP.
Sekcja 10.10
Funkcja tc p je a s s
131
Sprawdzanie dugoci opcji i czy opcja ma by przetwarzana
1580-1584 Sprawdzana jest dugo opcji (musi by rwna 6 dla wszystkich trzech opcji CC). Otrzymana opcja CC bdzie przetwarzana, gdy jestemy w trybie wysyania opcji CC (flaga TF_REQ_CC jest ustawiona przez tcp_newtcpcb, jeeli zostaa ustawiona flaga jdra tc p_do_r f c l644) oraz gdy flaga TF_N00PT nie jest ustawiona. (Ta ostatnia flaga zapobiega wysyaniu flag przez TCP w segmencie SYN.)
Ustaw odpowiedni flag i skopiuj 4-bajtow warto
1585-1588 Odpowiednia flaga czonu t o _ f 1 ag jest ustawiona. Czterobajtowa w ar to opcji zostaje zapisana w czonie t o _ c c struktury tcpopt i kolejno bajtw jest dostosowana do kolejnoci bajtw obowizujcej dla danego hosta. 1589 -1595 Jeli jest to segment SYN, to dla danego poczenia zostaje ustawiona flaga TF_RCVD_CC, poniewa otrzymalimy opcj CC.
Opcje CCnew i CCecho
1596-1623 Kolejne kroki przetwarzania opcji CCnew i CCecho s podobne do odpo wiednich krokw dla opcji CC. Wykonywane jest dodatkowe sprawdzenie, czy otrzymany segment zawiera flag SYN, poniewa opcje CCnew i CCecho maj prawo pojawi si tylko w segmencie SYN.
Cho flaga T0F_CCNEW jest poprawnie ustawiona, nigdy si jej nie sprawdza. Wynika to z tego, e kod przedstawiony na rysunku 11.6 usuwa zachowan warto CC (tzn. ustawia warto 0), jeeli opcja CC nie jest obecna. Jeli obecna jest opcja CCnew, to warto c c_ re cv jest w dalszym cigu poprawna (zauwamy, e wartoci opcji CC i CCnew s obie wpisywane do to _ c c na rysunku 10.18). Po przeprowadzeniu potrjnego uzgodnie nia (rysunek 11.14) do ta o _ cc kopiowana jest warto cc_r ecv.
Przetwarzanie otrzymanej opcji MSS
1625-1626 Zm ienna lokalna mss zaw iera albo w arto opcji MSS (jeli opcja ta jest obecna), lub wynosi 0 (jeli opcja jest nieobecna). W kadym przypadku, funkcja tcp_mss rcvd ustala wartoci t_maxseg i t_maxopd. Funkcja ta musi zosta wywoana na kocu tcp_dooptions, poniewa tcp_mssrcvd uywa flag TF_RCVD_TSTMP i TF_RCVD_CC, tak jak pokazano to na rysunku 10.13.
10.10
Funkcja tcp_reass
Jeeli serwer otrzymuje segment SYN zawierajcy dane, przy zaoeniu, e test TAO daje wynik negatywny lub segmentnie zawiera opcjiCC, funkcja tc p _i nput umieszcza dane w kolejce, czekajc na zakoczenie potrjnego uzgodnienia. Stan poczenia zostaje ustalony na SYN_RCVD (rysunek 11.6), przetwarzanie skiero wane do t rimthenstep6 do miejsca oznaczonego etykiet dodata (strona 1031, tom 2), makroinstrukcja TCP_REASS stwierdza, e poczenie nie jest w stanie ESTABLISHED, wywouje wic t c p _ r e a s s , b y doda segment do kolejki segmen tw otrzymanych w nieprawidowej kolejnoci w ramach danego poczenia.
132
RozdziaHO
(Dane nie zostay w istocie otrzymane w nieprawidowej kolejnoci, wyprzedziy one jedynie zakoczenie potrjnego uzgodnienia. Mimo to dwa liczniki statystyczne tcps_rcvoopack i t cps_rcvoobyt e - w dolnej czci rysunku 27.19, strona 951 w tomie 2 - s bdnie zwikszane.) tcpjnput.c
1580 1581 1582 1583 1584 1585 1586 1587 1588 15 89 159 0 1591 159 2 1593 1594 1595 15 96 159 7 15 98 15 99 16 00 1601 160 2 1 60 3 16 04 160 5 16 06 160 7 16 08 1 60 9 16 10 1611 1 61 2 16 13 161 4 16 15 161 6 1617 1 61 8 16 19 1 62 0 1621 16 22 162 3 1624 1625 162 6 1627 1 case T C P 0 P T _ C C : if (optlen != T C P 0 L EN _C C) continue; if ( ( t p - > t _ f l a g s & (T F _ R E Q _ C C | T F _ N 0 0 P T ) ) != T F _ R E Q _ C C ) continue; /* nie w y s y a m y opcji CC */ t o - > t o _ f l a g |= T0F_CC; b c o p y ( ( c h a r *) cp + 2, (char *) &t o -> t o _ c c , Sizeof(to->to_cc)); NTOHLt t o - > t o _ c c ) ; /* * Opc ja CC lub CCnew o trzymana w segm en c ie SYN powoduje, * e wy s y a n i e CC w n as t p ny ch segment ac h s taj e si poprawne. */ if (t i - > t i _ f 1ags & TH_SYN) t p - > t _ f l a g s |= T F _ R CV D _C C; break; ca se TC P 0P T_ C C N E W : if (optlen != T C P0 L E N _ C C ) continue; if ( ( t p - > t _ f 1ags & ( T F _ R E Q _ C C I T F _ N O O P T ) ) != T F _ R E Q _ C C ) conti n ue ; /* nie w y s y a m y opcji CC */ if (! ( t i ->t i _ f 1ags & T H _ S Y N ) ) co ntinue; t o - > t o _ f l a g = T 0 F_ CC NE W ; bcopy((char cp + 2, (char *) & t o -> to _ cc , s i z e o f ( t o - > t o _ c c ) ); NT0HL(to->to_cc); /* * O pcja CC lub CCnew o trzymana w s e gm en c ie SYN powoduje, * e w y s y a n i e CC w n as t p ny ch se gm en t ac h staj e si poprawne. */ t p -> t _ f 1 ags break; |= T F _ R C V D _ C C ;
ca se T C P 0 P T _ C C E C H 0 : if (optlen != T C P 0 L E N _ C C ) continue; if (! ( t i - > t i _ f 1ags & T H _ S Y N )) co ntinue; t o - > t o _ f l a g |= T 0 F _C CE C H0 ; b c o p y ( ( c h a r *) cp + 2, (char *) & t o - > t o _ c c e c h o , s i z e o f (t o - > t o _ c c e c h o )); NT0HL(to->to_ccecho); break: 1 ] if ( t i - >t i _ f 1ags & TH_S YN ) t c p _ m s s r c v d ( t p , mss); /* usta w ia t _ m a x s e g */
tcpjnput.c Rysunek 10.18 Funkcja tcp_doop 1 1ons - przetwarzanie nowych opcji T/TCP
Sekcja 10.11
Podsumowanie
133
Gdy potwierdzenie segmentu SYN serwera zostaje pniej otrzymane (zwykle jako trzeci segment potrjnego uzgodnienia), wykonywana jest instrukcja case TCPS_SYN_RECEIVED (stronie 1011 w tomie 2), ktra zmienia stan poczenia na ESTABLISHED i woa funkcj t c p _ r e a s s z drugim argumentem rwnym 0, by przekaza dane z kolejki do procesu. Zobaczymy jednak (rysunek 11.14), e to wywoanie t c p _ r e a s s zostaje ominite, jeeli nowy segment zawiera dane lub jeli flaga FIN jest ustawiona, poniewa kady z tych warunkw powoduje w yw o anie T C P _ R E A S S w punkcie, gdzie znajduje si etykieta doda ta. Problem polega na tym, e to wywoanie T C P _ R E A S S nie spowoduje przekazania danych do procesu, jeeli nowy segment cakowicie przykryje (overlap) wczeniejszy segment. Problem ten moe zosta zlikwidowany przez prost modyfikacj tcp_reass: zastpienie return w linii 106 na stronie 951 tomu 2 instrukcj skoku do etykiety
present.
10.11
Podsumowanie
Informacja TAO dla danego hosta jest przechowywana we wpisie do tablicy rutowania. Funkcja t c p _ g e t t a o c a c h e wczytuje przechowywane informacje dla danego hosta i woa tcp_rtl ookup w poszukiwaniu marszruty dla hosta, jeeli odpowiednia marszruta nie znajduje si jeszcze w bloku PCB. T /T C P modyfikuje funkcj tcp_cl ose, tak by dwie estymaty, srtt i rttvar, zapisy wane byy w tablicy rutowania dla pocze T /TC P, nawet jeli mniej ni 16 penowymiarowych segmentw byo wysanych w danym poczeniu. W ten sposb nastpne poczenie T /T C P z tym samym hostem moe by zainicjowane uywajc wartoci tych dwch estymat (zakadajc, e przed nawizaniem nastpnego poczenia nie mija okres wanoci wpisu w tablicy rutowania). Funkcja tcp _mss z kodu N e t / 3 zostaje funkcjonalnie podzielona na dwie czci zawarte w funkcjach t c p _ m s s r c v d i tcp_msssend. Pierwsza z tych funkcji jest woana po otrzymaniu opcji MSS, druga - przy wysyaniu MSS. Druga z tych funkcji dziaa inaczej ni zwykle w BSD: podaje warto MSS rwn wartoci MTU interfejsu wyjciowego pomniejszonej o rozmiar nagwkw TCP i IP. Sy stem BSD ustaliby warto MSS dla nielokalnego partnera na 512. Przy wprowadzeniu T /T C P zostaje zmodyfikowana funkcja tcp _ d o o p t i ons z kodu N e t/3 . Zrezygnowano z licznych argumentw funkcji, umieszczajc odpo wiednie wartoci w strukturze. W ten sposb funkcja moe przetworzy nowe opcje (takie jak trzy opcje wprowadzone wraz z T /T C P), bez zwikszania liczby argumentw.
11

11.1 Wstp
Wikszo zmian wymaganych przez T /T C P zlokalizowanych jest w funkq'i tcp_input. Zmian, ktra dotyczy wielu fragmentw funkcji, s nowe argumenty i sposb przekazywania informacji przez funkcj t c p_d oopti ons (rozdzia 10.9). Nie pokazujemy tu wszystkich fragmentw kodu zmienionych w zwizku z t modyfikacj tcp_dooptions. Rysunek 11.1 jest powtrzeniem rysunku 28.1 ze stron 962-963 w tomie 2. Pogru bionym drukiem zaznaczylimy zmiany zwizane z T/TC P.
voi d tcp_input()
suma k o n t r o l n a n a g w k a TCP i d a n y c h ; p o m i j a m y n a g w k i I P/ TCP w m b u f :
findpcb: o d n a j d PCB s e g m e n t u : i f Cni e o d n a l e z i o n y ) goto dropw ithreset; r e i n i c j a c j a z e g a r w : z e g a r b e z c z y n n o c i 0, z e g a r p od trzymy wa ni a 2 g o d z i n y przetwarzanie o p c ji, if jeeli n i e w s t a n i e LISTEN;
( p a k i e t zgodny z przewidywaniem nagw ka) { c a k o w i t e p rz etw orz en ie odebranego segmentu; return;
switch ( tp - > t_ s t a te ) I c a s e TCPS_LISTEN: j e e l i u s t a w i o n a f l a g a SYN, z a a k c e p t u j nowe p o c z e n i e ; wy k o n u j e my t e s t TAO goto trimthenstepS: TCPS_SYN_SENT: s p r a w d z a m y o p c j CCec ho j e e l i ACK n a s z e g o SYN - p o c z e n i e g o t o w e ; trimthenstepS: w yc inaj dane n i e m i e s z c z c e s i w o k n i e : i f ( f l a g a ACK u s t a w i o n a ) goto processack: goto step6; c a s e TCPS_LAST_ACK: c a s e TCPS_CL0SING: c a s e TCPS_TIME_WAIT: c z y nowy s y n j e s t n i e j a w n y m p o t w i e r d z e n i e m p o p r z e d n i e g o w c i e l e n i a ; case
136
Rozdzia 11
p r z e t w a r z a n i e z n a c z n i k a c z a s u RFC 1 3 2 3 ; s p r a w d z a m y o p c j CC; sprawd, c z y we wn t r z o k n a o d b i o r c z e g o s j a k i e b a j t y d a n y c h ; aby z m i e c i s i w o k n ie ;
o b e t n i j segment t a k , if
)
if
( u s t a w i o n a f l a g a RST) l p r z e t w a r z a n i e z a l e n e od st an u ; g oto drop; ( f l a g a ACK w y c z o n a ) i f (SYN_RCVD | | p o o w i c z n i e z s y n c h r o n i z o w a n e ) goto step6; else g oto dropp;
( u s t a w i o n a f l a g a ACK) { i f ( s t a n SYN_RCVD) o t w a r c i e pas ywne l ub z a k o c z e n i e o t w a r c i a j e d n o c z e s n e g o ; i f ( p o w i e l o n e ACK) algorytm sz y b k ie g o od zy skiw an ia; processack: o d w i e e s t y m a t o r y RTT j e e l i b y s p r a w d z a n y c z a s ; i f (adne dane n i e z o s t a y p o t w ie r d z o n e ) goto stepS; otwrz okno p r z e c i e n i a ; usu p o t w i e r d z o n e d a n e z b u f o r a n a d a w c z e g o ; z m i e s t a n , j e e l i t e r a z w FIN_MAIT_1, CLOSING, l u b LAST_ACK;
if
)
step6: odwie in form ac je okna; flagi URG; d o d a n i e do k o l e j k i odtwarzania p a k ie t w ;
przetwarzanie
dodata: p r z e t w a r z a n i e danych z segmentu, if if if
( u s t a w i o n a f l a g a FIN) p r z e t w a r z a n ie z a l e n e od st anu; ( o p c j a g n i a z d a SO_DEBUG) tcp_trace(TA_IN PJT);

||
(potrzebn y output tcp_output(); return;
potwierd teraz)
dropafterack; t c p _ o u t p u t ( ) w c e l u w y g e n e r o w a n i a ACK; return; dropwithreset: t c p _ r e s p o n d ( ) w c e l u w y g e n e r o w a n i a RST; return; drop: if ( o p c j a g n i a z d a SO_DEBUG) tcp_trace(TA_DROP); return;
) Rysunek 11.1 Podsumoimnie przetwarzania na wejciu TCP. Zmiany wprowadzone z T/TCP zaznaczone s pogrubionym drukiem
Sekcja 11.2
Przetwarzanie wstpne
137
Zmiany w tcp_i nput prezentujemy w takiej kolejnoci, w jakiej odbywa si prze twarzanie.
11.2
Przetwarzanie wstpne
Zdefiniowane zostaj trzy nowe dynamiczne zmienne lokalne. Jedn z nich jest struktura tcpopt uywana przez t c p _d oopti ons. Nastpujce linie zastpuj lini 190 na stronie 964 w tomie 2:
s t r u c t t c p o p t to; s t r u c t r m x p _ t a o *taop; struct rmxp_tao tao_noncached; b z e r o ( ( c h a r *)&to, si z eo f( to ) ): tcpstat.tcps_rcvtotal++; /* op c j e w tym s e g m e n c i e */ /* w s k a n i k do w p i s u T A O */ /* g dy b ra k w p i s u T AO */
Inicjacja struktury tcpopt wartoci 0 jest istotna: w ten sposb czon to_cc (odebra na warto CC) otrzymuje warto 0, co oznacza, e zmienna ta jest niezdefiniowana. W kodzie N e t/ 3 przetwarzanie powraca do etykiety f i n d p c b jedynie wtedy, gdy nowy segment SYN jest przetwarzany dla poczenia, ktre nadal znajduje si w stanie UM E_W AIT (strona 998, tom 2). Mamy tu jednak do czynienia z bdem, poniewa dwie linie kodu:
m - > m _ d a t a + = s i z e o f ( s t r u c t t c p ip hd r) m->m_len -+ s i z e o f ( s t r u c t t c pi p hd r) + off - s i z e o f ( s t r u c t tcphdr); + off - s i z e o f (struct tcphdr);
ktre pojawiaj si dwukrotnie po findpcb, wykonywane s po raz drugipo instrukcji goto. (Te dwie linie kodu pojawiaj si na stronie 979 i ponownie na stronie 980 tomu 2; tylko jeden z tych dwch powtrzonych fragmentw zostaje wykonywany - zalenie od tego, czy segment jest zgodny z przewidywaniem nagwka (header prediction), czy te nie.) Przed wprowadzeniem T /T C P bd ten nie stwarza problemw poniewa segmenty SYN rzadko zawieray rwnie da ne, a bd si uwidacznia jeli przychodzi nowy SYN zawierajcy dane, przezna czone dla poczenia pozostajcego w stanie TIME_WAIT. Dla T /T C P pojawia si jednak drugie odgazienie przetwarzania powracajce do f i n d p c b (odpowie dzialne za przetwarzanie niejawnego potwierdzenia z rysunku 4.7, patrz rysunek 11.11), a przetwarzany SYN bdzie prawdopodobnie zawiera dane. Dlatego wspomniane dwie linie musz by przeniesione przed etykiet findpcb, tak jak to pokazano na rysunku 11.2. Dwie linie, o ktrych mowa, powinny by nastpnie usunite z kodu na stronie 979 i 980 w tomie 2.
138
Rozdzia 11
-----------------------------------------------------------------------------------------------------2 74 275 276 277 278 279 280 281 282 283
t c p jn p u t .c
/* * P o m i j a m y na g wki TCP i IP o ra z op c j e T C P w mbu f. * o p tp i ti nadal w s k a z u j na n a g w e k TCP header, ale to je st OK. */ m - > m _ d a t a + = s i z e o f t s t r u c t t c p ip hd r) + off - s i z e o f t s t r u c t tcphdr); m - > m _ l e n -= s i z e o f t s t r u c t tcpi p hd r) + o ff - s i z e o f t s t r u c t tc p hdr); /* * Z n a j d u j e m y pcb dla se gmentu. */ fin dpcb:
------------------------------------------------------------------R ysunek 11.2 t cp _ i n p u t - modyfikacja wskanika i dugoci m buf odbywa si przed fin d p c b
tcp jn p u t.c
Nastpna zmiana pojawia si w linii 327 na stronie 969 tomu 2 - utworzenie nowego gniazda, gdy przychodzi segment dla nasuchujcego gniazda ( listening socket). Po przypisaniu t_ s t a t e wartoci T C P S _ L I S TEN, dwie flagi, T F _ N 0 P U S H i TF_N0 0 PT, musz zosta przeniesione z gniazda nasuchujcego do nowego gniazda:
t p - > t _ f 1ags |= t p O - > t _ f 1ags & ( T F _ N 0 P U S H | T F _ N 0 0 P T ) ;
gdzie tpO jest lokaln zmienn dynamiczn, ktra wskazuje na tcpcb dla odbie rajcego gniazda. Wywoanie funkcji tcp_doop ti ons w liniach 344-345 na stronie 971 w tomie 2 zostaje zmienione, tak by uwzgldni zmodyfikowany sposb przekazywania parametrw dla tej funkcji (rozdzia 10.9);
if (optp && tp->t_state != T C P S _ L I S T E N ) t c p _ d o o p t i o n s ( t p . optp. optlen, ti. Sto);
11.3
Przewidywanie nagwka
Pocztkowy test, czy przewidywanie nagwka moe by zastosowane (strona 975, tom 2), musi obejmowa sprawdzenie, czy ukryte flagi stanu s wyczone. Jeli ktrakolwiek z tych flag jest wczona, moe by konieczne jej wyczenie przez powoln ciek przetwarzania w tcp_input. Nowy test przedstawiony zosta na rysunku 11.3. ------------------------------------------------------------------------------------------------3 98 39 9 400 401 4 02 40 3 404 4 05 4 06 407 4 08 409 4 10
tcpjnput.c
if (t p ->t_s ta te = = T C P S _ E S T A B L I S H E D && (t i fl ag s & (TH_SYN I T H _F IN | T H _ R S T | T H J J R G | T H _ A C K ) ) = = T H _ A C K && ((t p - > t _ f 1ags & ( T F _ S E N D S Y N I TF___S E N D F I N )) = = 0) && ( ( t o . t o _ f l a g i T 0 F _T S ) == 0 || T S T M P _ G E Q ( t o . t o _ t s v a l , t p - > t s _ r e c e n t ) ) && /* * Jeeli zac zlimy uywa opcji CC, to uywanie jej staje si obowizkowe: * s e g m e n t je st OK, jeeli n i e u y w a n i e T / T C P nie z o s t a o * w y n e g o c j o w a n e lub jeeli s e g m e nt z a w i er a CC rw ne CCrecv. */ ( ( t p - > t _ f 1ags & (T F _ R E Q _ C C I T F _ R C V D _ C C ) ) != ( T F _ R E Q _ C C I T F _ R C V D _ C C ) || (t o .t o _ f 1 ag & T0F_C C) != 0 && t o . t o _ c c = = t p - > c c _ r e c v ) && ti -> t i _ s e q = = t p - > r c v _ n x t & &
Sekcja 11.3
Przewidywanie nagwka
139
411 412 4 13 414 415 416 417 418 4 19 4 20 421 422 4 23
tiw in && t i w in = t p - > s n d _ w n d && tp->snd_nxt == tp->snd_max) [ /* * Jeeli o s t a t n i e A C K zawi er a si w r a ma ch n u m e r w s e k w e n c y j n y c h * tego segm en tu , to r e j e s t r u j e m y z n a c z n i k czasu. * UWAGA: test z osta z m o d y f i k o w a n y z g o d n i e z p r o p o z y c j * z listy t c p l w @ c r a y . c o m (Braden 1 99 3/ 04 / 26 ). */ if ( ( t o .t o _ fl ag & T 0 F _ TS ) != 0 && SEQ_LEQ(ti->ti_seq, tp->last_ack_sent)) ( t p - > t s _ r e c e n t _ a g e = tcp_now; t p - > t s _ r e c e n t = t o . t o _t sv a l; ]
------------------------------------------------------------------tcp_input.c R y s u n e k ll .3 t c p _ i n p u t - czy przewidywanie nagwka moe by zastosowane? Sprawdzenie, czy ukryte flagi stanu s wyczone
400
Pierwsza zmiana polega na sprawdzeniu, czy wyczone s obie flagi, TF_SENDSYN i TF_SENDFIN.
Sprawdzenie opcji znacznika czasu (jeli jest obecna)
40 1 -4 0 2
Nastpna zmiana wie si z modyfikacjami funkcji tcp_dooptions: za miast sprawdza t s _ p r e s e n t , sprawdzany jest bit T0F_TS w t o _ f 1 ag. Jeli znacz nik czasu jest obecny, jego warto znajduje si w t o _ t s v a l , zamiast w t s _ v a l .
Sprawdzenie CC, jeli uywany jest protok T/TCP
4 0 3-409
Ostatecznie, jeeli uycie T /T C P nie zostao wynegocjowane (dalimy opcji CC, ale jej nie otrzymalimy od partnera, lub nawet nie zgaszalimy takiego dania), wykonywane s dalsze sprawdzenia i f. Jeeli T /T C P jest uywane, to otrzymany segment musi zawiera opcj CC i warto CC musi by rwna cc_ re c v. W przeciwnym razie dalsze testy i f nie s przeprowadzane.
Spodziewamy si, e przewidywanie nagwka bdzie rzadko wykorzystywane dla krtkich transakcji T/TCP. Dzieje si tak dlatego, poniewa w najmniejszej wy mianie T/TCP pierwsze dwa segmenty maj ustawione flagi kontrolne (SYN i FIN) i drugi test na rysunku 11.3 daje wynik negatywny. Te segmenty T/TC P s przetwa rzane powoln ciek w tcp_i nput. Natomiast opcji CC bd uywa dusze poczenia (na przykad przekaz duych iloci danych) pomidzy hostami znaj cymi T /T C P i takie poczenia mog korzysta z przewidywania nagwka.
Aktualizacja ts_recent na podstawie otrzymanego znacznika czasu
41 3 -4 2 3
Sprawdzenie, czy warto t s _ r e c e n t powinna zosta uaktualniona, rni si od sprawdzenia w liniach 371-372 na stronie 975 w tomie 2. Przyczyna wpro wadzenia modyfikacji przedstawionych na rysunku 11.3 jest wyjaniona szczeg owo na stronach 903-906 w tomie 2.
140
Rozdzia 11
11.4
Inicjacja pasywnego otwarcia
Zastpujemy teraz cay kod przedstawiony na stronie 984 w tomie 2 - ostatnia cz przetwarzania otrzymanego segmentu SYN dla gniazda w stanie LISTEN. Gdy serwer otrzymuje SYN od klienta, mamy do czynienia z inicjacj pasywnego otwarcia. (Nie przytaczamy tu po raz drugi kodu na stronie 982 w tomie 2, ktry wykonuje pocztkowe przetwarzanie w tym stanie.) Pierwszy fragment tego kodu pokazany jest na rysunku 11.4.
545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 56 8 569 570 571 572 tp-> t_ t em pl ate = t c p _ t e m p l a t e ( t p ); if ( t p - > t _ t e m p l a t e = = 0) l tp = t c p _ d r op (t p, ENOBUFS); d r o p s o c k e t = 0; /* g n ia zd o z o s t a o ju u s u n i t e */ goto drop; ) if ((taop = t c p _ g e t t a o c a c h e ( i n p ) ) = = NULL) I taop = & t a o _ n o n c a c h e d ; b z e ro (t a op , s i z e o f (* t a o p ) ); ) if (optp) t c p _ d o o p t i o n s ( t p , optp, optlen, ti, &to); if (iss) t p -> iss = i s s ; else t p -> iss = tcp_i s s ; tcp_i SS + = T C P _ I S S I N C R / 4; tp->irs = ti- >t i _s eq : t c p _ s e n d s e q i n i t (t p ) ; tcp_rcvseqinit(tp); /* * Inic j ac ja tc p c b dla tr an sakcji: * set S N D . W N D = SEG.WND, * i n i c j a c j a CC se nd i CCrecv. */ t p - > s n d _ w n d = tiwin; / * p o c z t k o w e o kn o w y s y k o w e */ tp->cc_send = C C _ I N C ( t cp_ccgen); t p - > c c _ r e c v = to.to_cc;
Rysunek 11.4
tcp_input-zuczytanie wpisu TAO, inicjacja bloku kontrolnego dla transakcji.
Odczytanie wpisu TAO dla klienta

551 -554
t c p_ g e t t a o c a c h e szuka wpisu TAO dla danego klienta. Jeli wpis taki nie zostaje znaleziony, uyta jest lokalna zmienna dynamiczna z wyzerowanymi wszystkimi wartociami.
Przetwarzanie opcji i inicjacja numerw sekwencyjnych
555-5 64
tcp_dooptions przetwarza opcje (funkcja ta nie bya woana wczeniej, poniewa poczenie jest w stanie LISTEN). Pocztkowy wysykowy numer se kwencyjny (initial send sequence number - i s s) oraz pocztkowy odbiorczy numer
Sekcja 11.4
141
sekwencyjny (initio! receive sequence number - i r s) zostaj zainicjowane. Wszystkie zmienne bloku kontrolnego zawierajce numery sekwencyjne s inicjowane przez tcp_sendseqi ni t oraz tcp_rcvseqi ni t.
Aktualizacja okna wysykowego
56 5 -570
ti w i n jest rozmiarem okna przekazanym przez klienta w segmencie SYN (strona 968 w tomie 2). Jest to pocztkowy rozmiar okna dla nowego gniazda. Zwykle okno wysykowe nie jest uaktualniane a do odebrania segmentu z ACK (strona 1025, tom 2). T /TC P musi jednak uy wartoci z otrzymanego segmentu SYN, nawet gdy segment nie zawiera flagi ACK. Rozmiar okna okrela, jak wiele danych serwer moe natychmiast wysa w odpowiedzi do klienta (drugi segment w najmniejszej, trzysegmentowej wymianie T/TCP).
Okrelenie wartoci cc_send i cc_recv
57 1 -57 2
Warto cc_send jest przepisywana z tcp_ccgen, a cc_recv otrzymuje warto rwn wartoci CC, jeli opcja CC bya obecna. Jeli za opcja CC nie bya obecna, to - poniewa struktura to zostaa zainicjowana na pocztku funkcji tcp_i nput wartoci 0 - cc_recv otrzyma te warto 0 (niezdefiniowana). Na rysunku 11.5 przedstawiony jest test TAO dla otrzymanego segmentu.
Wykonanie testu TAO
5 7 3-587
Test TAO zostaje przeprowadzony tylko wtedy, gdy segment zawiera opcje CC. Test TAO daje wynik pozytywny, jeli otrzymana warto CC jest niezerowa i wiksza ni warto przechowywana dla danego klienta (tao_cc).
Pozytywny test TAO - uaktualnienie pamici TAO dla klienta
588 - 594
Warto przechowywana dla danego klienta zostaje uaktualniona i pocze nie wchodzi w stan ESTABLISHED*. (Ukryta flaga stanu zostaje ustawiona kilka linii niej, co oznacza, e poczenie znajduje si w tym poowicznie zsynchronizo wanym stanie z gwiazdk.)
Sprawdzenie, czy potwierdzenie ma by opnione
595 - 606
Jeli segment zawiera flag FIN, lub jeli segment zawiera dane, oznacza to, e kod aplikacji uwzgldnia uycie T /T C P (tzn. aplikacja wywoaa sendto z flag MSG_E0F i nie moga wywoa connect, wri te i shutdown). W tym przypadku potwierdzenie zostaje opnione, tak by umoliwi serwerowi przesanie po twierdzenia naoonego (piggyback acknowledgement) na segment SY N /A C K ser wera.
Jeli flaga FIN nie jest ustawiona, a segment zawiera dane, to - poniewa segment zawiera rwnie flag SYN - jest to najprawdopodobniej pierwszy z kilku segmen tw z danymi wysyanymi przez klienta. W tym przypadku, jeeli klient nie jest w podsieci lokalnej (i n_l ocal addr zwraca 0), to potwierdzenie nie zostaje opnione, poniewa klient wykonuje prawdopodobnie powolny start.
142
Rozdzia 11
------------------------------------------------------------------------------------------------573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 59 9 6 00 601 60 2 60 3 60 4 60 5 60 6 60 7 608 6 09 6 10 611 6 12 613 6 14 615 /* * * * * * * * * * * * * * */ if
tcpjnput.c
P r z e p r o w a d z a m y test T A O dla e w n e t u a l n i e o d e b r a n e j opcji CC (SEG.CC): - P o r w n u j e m y S E G . C C z w a r t o c i CC z a c h o w a n a dla t e g o hosta (jeli w a r t o taka istnie je). -Jeeli SE G . C C > w a r t o zachow an a, SYN j es t n ow y i z o s t a j e n a t y c h m i a s t z a a k c e p t o w a n y : nowa w a r t o CC j es t za c ho w a n a , g n i a z d o o z n a c z o n e j a ko pocz on e , p o c z e n i e je st w s t a n i e ES T AB LI SH E D, w c z a m y flag p o w o d u j c w y s a n i e SYN w n a s t p n y m segmencie. W i r tu al n y rozmiar okna w p i s a n y jest do rcv_adv, by z a i n i c j o w a z a b e z p i e c z e n i e SWS. Nastpnie p r z e p r o w a d z a m y zwyke pr ze tw a r z a n i e segmentu: po m i j a m y SYN, p r z e t w a r z a m y d a n e i FIN. -W p r z e c i w y m razie w y k o n u j e m y z w y k e p o t r j n e uz g o d n i e n i e . ( Ct o . t o _ f l a g & T 0 F _C C) != 0) ( if ( t a o p - > t a o _ c c != 0 && C C _ G T ( t o . t o _ c c , t a o p - > t a o _ c c )) ( /* * W o t r z y m a n y m s e g m e n c i e SYN bya opcja CC i te st * T A O da w y n i k pozytywny. */ tcpstat.tcps_taook++; t a o p - > t a o _ c c = to .to_cc; t p - > t _ s t a t e = TCP S__E ST AB LIS HE D : /* * Jeeli je st FIN lub jeli s d an e i p o c z e n i e je st * lokalne, o p n i a m y S Y N ,A C K (S Y N ), m a j c n a d z i e j * e b d z i e m y mogli je n a o y na s e g m e n t o d p o w i e d z i . * W i nn y m p r z y p a d k u AC K musi by w y s a n e tera z * p a r t n e r m o e w y k o n y w a p o w o l n y start. */ if ( (tiflags & TH_F IN ) | I (ti - >t i_1en 1= 0 && in_l o c a l a d d r ( i n p - > i n p _ f a d d r ))) t p -> t _ f 1ags |= (T F _ D E L A C K | T F _ S E N D S Y N ) ; el se t p - > t _ f l a g s |= (T F _ A C K N 0 W | T F _ S E N D S Y N ); t p - > r c v _ a d v + = tp->rcv _w nd ; tcpstat.tcps_connects++; soisconnected(so): tp->t_timer[TCPT_KEEP] =TCPTV_KEEP_INIT; d r o p s o c k e t = 0; /* z w i z a n e z g n i a z d e m */ tcpstat.tcps_accepts++; go t o t r i m t h en st ep 6 ; ) e ls e if ( t a o p - > t a o _ c c != 0) t c p s t a t .tc ps _ t a o f a i 1 + + :
-----------------------------------------------------------------------------------------------Rysunek 11.5 t c p _ in p u t - test TAO dla otrzymanego segmentu

Ustalenie wartoci rcv_adv
tcpjnput.c
607 Zmienna rcv_adv jest zdefiniowana jako najwyszy zgoszony (advertised) numer sekwencyjny plus 1 (rysunek 24.18, strona 838 w tomie 2). Makroinstrukcja tcp_rcvseqi ni t (rysunek 11.4) zainicjowaa jednak t zmienn wartoci rwn otrzymanemu numerowi sekwencyjnemu plus 1. Na tym etapie przetwarzania rcv_wnd bdzie rozmiarem bufora odbiorczego gniazda (strona 980 w tomie 2). Dodanie rcv_wnd do rcv_adv spowoduje, e rcv_adv bdzie wskazywa na pierwszy bajt poza aktualnym oknem odbiorczym. rcv_adv musi zosta zainicjo wana tutaj, poniewa zmienna ta jest uywana przez mechanizm unikania wysy ania gupich segmentw w tcp_output (strona 915, tom 2). W arto rcv_adv jest ustawiana na kocu tcp_output zwykle wtedy, gdy ma by wysany pierwszy
Sekcja 11.4
143
segment (w tym przypadku byby to segment SYN/ ACK serwera wysyany w odpowiedzi na SYN klienta). T /T C P wymaga jednak, by warto rcv_adv bya okrelona przy pierwszym przejciu przez funkcj t cp_output, poniewa dane mog by umieszczone w pierwszym wysyanym segmencie.
Nawizanie poczenia
6 0 8 -6 09
Zwikszenie tcps_connects i wywoanie soi sconnected nastpuj zwy kle, gdy otrzymany jest trzeci segment potrjnego uzgodnienia (strona 1011, tom 2). W przypadku T /T C P obie te czynnoci s wykonywane teraz, poniewa po czenie zostao wanie nawizane. 610-613 Z e g a r nawizywania poczenia ( c onnection-e stablishm ent tim er ) zostaje usta wiony na 75 sekund, flaga dropsocket otrzymuje warto 0 i wykonany jest skok do etykiety trimthenstep6. Na rysunku 11.6 pokazana zostaa pozostaa cz przetwarzania segmentu SYN otrzymanego w stanie LISTEN. -----------------------------------------------------------------------------------------------616 617 618 619 620 621 622 623 624 625 626 627 628 629 63 0 631 63 2 63 3 ] else { /* * Brak opcji CC, m o e jed n a k jest * kasuj e m y w a r t o p r z e c h o w y w a n . */ t a o p - > t a o _ c c = 0; ] CCnew:
tcpjnput.c
/* * Test TAO da w y n i k negatywny, lub nie byo opcji * w y k o n u j e m y s t a n d a r d o w e p o t r j n e u z g o d nienie. */ t p -> t _ f 1 ags ]= TF_ACKN0W; tp->t_state = TCPS_SYN_RECEIVED; t p -> t__t im e r[TC PT_KE E P ] = T C P T V _ K E E P _ I N I T ; d r o p s o c k e t = 0: /* z w i z a n e z g n i a z d e m */ t c p s t a t .t c p s _ a c ce pt s+ + ; goto t ri mt h e n s t e p 6 ; )
CC -
-----------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.6 t cp_ in p u t - przetwarzanie w stanie LISTEN. Brak opcji CC lub negatywny wynik testu TAO
Brak opcji CC; przechowywana warto CC staje si niezdefiniowana
616-622
Klauzula else odpowiada sytuacji, gdy brak jest opcji CC (pierwsza instrukcja i f na rysunku 11.5). Przechowywana warto CC zostaje ustawiona na 0 (niezdefinio wana). Jeli okae si, e segment zawiera opcj CCnew, warto przechowywana zostaje uaktualniona po zakoczeniu potrjnego uzgodnienia (rysunek 11.14).
Wymagane potrjne uzgodnienie
623 - 633
Segment nie zawiera opcji CC, lub opcja CC bya obecna, ale test TAO da wynik negatywny. W kadym z tych przypadkw wymagane jest przeprowadze nie potrjnego uzgodnienia. Pozostae linie s takie same jak kocowa cz rysunku 28.17, strona 984 w tomie 2: flaga TF_ACKN0W zostaje ustawiona i ustalony
144
Rozdzia 11
jest stan SYN_RCVD, co spowoduje natychmiastowe wysanie segmentu SYN /ACK.
11.5
Inicjacja aktywnego otwarcia
Nastpny przypadek (case) odpowiada sytuacji, gdy poczenie znajduje si w stanie SYN_SENT. Modu TCP wysa wczeniej segment SYN (aktywne otwarcie) i prze twarza teraz odpowied serwera. Rysunek 11.7 pokazuje pierwsz cz zwizanego z tym kodu. Odpowiedni fragment kodu N et/3 zaczyna si na stronie 986 w tomie 2. -----------------------------------------------------------------------------------------------634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665
tcpjnput.c
* Jeeli j e s t e m y w stanie SYN_SENT: * jeeli s e g m e n t zawiera ACK, ale nie dla n a s z e g o SYN, o d r z u c a m y * o t r z y m a n e dane. * jeeli s e g m e n t z a wiera RST. o d r z u c a m y p o czenie. * jeeli s e g m e n t nie zawiera SYN, o d r z u c a m y ten segment. * W p r z e c i w n y m razie, jest to a k c e p t o w a l n y s e g m e n t SYN * i n i c j u j e m y t p - > r c v _ n x t i tp->irs * jeeli s e g m e n t z a wiera ack to z w i k s z a m y t p - > s nd_una. * jeeli SYN zosta p o t w i e r d z o n y z m i e n i a m y stan na E S T A B LISHED, jeeli nie - na S Y N _ R C V D * s p o d z i e w a m y si, e s e g ment z o s t a n i e p o t w i e r d z o n y * kontynuujemy przetwarzanie pozostaych danych/komunikatw k ontrolnych, p o c z y n a j c od URG */ case T C P S _ S Y N _ S E N T : if ((taop = t c p _ g e t t a o c a c h e ( i n p )) = = NULL) ( taop = & t a o _ n o n c a c h e d ; bzero t t a o p , s i z e o f ( * t a o p ) ); ) if ((ti flags & TH_ACK) && (S E Q _ L E Q ( t i - > t i _ a c k , tp->iss) || S E Q _ G T (ti->ti_ack, t p - > s n d _ m a x ) )) ( /* * Jeeli m a m y CCsent dla o d d a l o n e g o hosta, to znaczy, * e nie byo przed chwil p r z e a d o w a n i a - nie w y s y a m y RST. * Moe to by ret r a n s m i s j a w y k o n a n a przez partnera, po * z a g u b i e n i u n a s zego w c z e n i e j s z e g o potwie r d z e n i a . * Nasz nowy SYN, gdy dotrze, p o s u y za w y m a g a n e * potwierdzenie. */ if ( t a o p - > t a o _ c c s e n t != 0) goto drop; else goto dropw i t h r e s e t ;
/*
666
667 6 68 669 670 671 672 673 674 675 676 677
)
if (tiflags & TH_RST) ( if ( t i f 1ags & TH_ACK) tp = tcp_drop(tp, E C O N N R E F U S E D ) ; goto drop; I if ((tiflags & T H _ S Y N ) == 0) goto drop; t p - > s n d _ w n d = t i ->ti_win; /* p o c z t k o w e o k n o w y s y k o w e t p - > c c _ r e c v = to.to_cc; /* w a r t o CC p a r t n e r a */ tp->irs = ti->ti_seq; tcp_rcvseqinit(tp);
*/
------------- ----------------------------------------------------------------------------------- tcpjnput.c Rysunek 11.7 t cp_ i n p u t - pocztkowe przetwarzanie w stanie SYN_SENT
Sekcja 11.5
145
Pobranie wpisu TAO

6 4 7 -65 0
Informacja TAO dla serwera zostaje pobrana. Odpowiedni wpis powinien istnie, poniewa niedawno wysalimy segment SYN.
Obsuga niepoprawnego ACK
65 1 -6 6 6
Jeeli segment zawiera ACK, ale pole potwierdzenia jest niepoprawne (opis porwnywanych pl przedstawiony zosta na rysunku 28.19 w tomie 2), nasza odpowied zaley od tego, czy mamy zachowan warto t a o _ c c s e n t dla tego hosta. Jeeli warto tao_ccsent jest niezerowa, po prostu odrzucamy ten seg ment i nie wysyamy RST. Jeeli natomiast warto t a o _ c c s e n t wynosi 0, odrzu camy segment i wysyamy RST, co w tym stanie jest normaln odpowiedzi TCP na niepoprawne potwierdzenie.
Sprawdzenie, czy flaga RST jest obecna
667-671
Jeeli otrzymany segment zawiera flag RST, segment zostaje odrzucony. Dodatkowo, jeeli ustawiona jest flaga ACK, oznacza to, e serwer TCP aktywnie odmawia poczenia i komunikat o bdzie ECONNREFUSED zostaje zwrcony do woajcego procesu.
Flaga SYN musi by ustawiona
672 -67 3 6 7 4 -6 77
Jeeli flaga SYN nie jest ustawiona, segment zostaje odrzucony.
Pocztkowe okno wysykowe otrzymuje warto rwn wartoci zgoszo nej w otrzymanym segmencie, a cc_recv otrzymuje warto rwn otrzymanej wartoci CC (0, jeeli opcja CC nie bya obecna), i r jest pocztkowym odbior czym numerem sekwencyjnym, a makroinstrukcja tcp_rcvseqinit inicjuje zmienne odbiorcze w bloku kontrolnym. Przetwarzanie odbywa si teraz rnymi ciekami, w zalenoci od tego, czy segment zawiera potwierdzenie naszego segmentu SYN (normalny przypadek), czy te flaga ACK nie jest ustawiona (jednoczesne otwarcie, przypadek rzadszy). Normalny przypadek przedstawiony jest na rysunku 11.8.
Flaga ACK jest wczona
678
Jeeli flaga ACK jest wczona, to z testu t i_a c k na rysunku 11.7 wiemy, e ACK potwierdza nasz segment SYN.
Sprawdzenie wartoci CCecho, jeli opcja ta jest obecna
679 -69 3
Jeeli segment zawiera opcj CCecho, ale warto CCecho nie jest rwna wysanej przez nas wartoci CC, segment zostaje odrzucony. (To nie powinno si nigdy zdarzy", chyba e partner nie dziaa poprawnie, poniewa flaga ACK potwierdza nasz segment SYN.) Jeli w ogle nie wysyalimy opcji CC (tao_ccsent wynosi 0), to rwnie zostaje wysana flaga RST.
146
Rozdzia 11
-----------------------------------------------------------------------------------------------678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726
tcpjnput
if (ti flags 4 TH_ACK) ( /* * Nasz SYN zosta po t w i e r d z o n y . Jeeli s e g m e n t z a w i e r a CCecho. * s p r a w d z a m y t opcj, by si j e s z c z e raz upewni, e ten * s e g m e n t r z e c z y w i c i e o d p o w i a d a n a s z e m y segmentowi SYN. * Jeeli nie - o d r z u c a m y s e g m e n t jako stary dup l i k a t . Jeeli * jed n a k kie r u j e m y si starymi reguami, to w y s y a m y RST. */ if ((t o . t o _ f l a g 4 T 0 F _ C C E C H 0 ) 44 t p - > c c _ s e n d != t o .t o _ c c e c h o ) ( if ( t a o p - > t a o _ c c s e n t != 0) ( tcpstat.tcps_badccecho++; goto drop; ] else goto dropwi t h r e s e t ; } tcpstat,tcps_connects++; soisconnected(so); /* Czy w y k o n y w a s k a l o w a n i e okna dla tego p o c z e n i a ? */ if ((t p ->t _ f 1 ags 4 ( T F _ R C V D _ S C A L E | T F _ R E Q _ S C A L E ) ) = (T F _ R C V D _ S C A L E | T F _ R E Q _ S C A L E )) ( tp->snd_scale = tp->requested_s_scale; tp->rcv_scale = tp->request_r_scale; ) /* S e g ment jest a k c e p t o w a l n y - u a k t u a l n i a m y pa m i TAO, * jeeli j e s t n i e z d e f i n i o w a n a . */ if ( t a o p - > t a o _ c c s e n t = = 0) t a o p - > t a o _ c c s e n t = t o .to_ccecho; t p - > r c v _ a d v + = tp->rcv_wnd; tp->snd_una++; /* SYN jest p o t w i e r d z o n y */
/* *Jeeli s dane, o p o n i a m y ACK; jeeli jest r w nie FIN *flaga A C K N O W z o s t a n i e w c z o n a pniej. */ i f ( t i -> t i _ 1 e n != 0) t p -> t _ f 1ags 1= TF_DELACK; else t p - > t _ f l a g s 1= TF_ACKN0W; /* * Rece i v e d < S Y N , A C K > in SY N__SE N T [*] State. * T ra n s i t i o n s : * SYN_SENT --> E S T A B L I S H E O * S Y N _ S E N T * --> FI N _W AI T_ 1 */ if (t p - > t _ f 1ags & T F _ S E N D F I N ) ( tp->t_state = TCPS_FIN_WAIT_1; t p - > t _ f 1ags 4 = ~T F _ S E N D F I N ; ti flags 4= ~ T H _ S Y N : ) else tp->t_state = TCPS_ESTABLISHED:
-----------------------------------------------------------------------------------------------tcpjnput Rysunek 11.8 tcp_ input - przetwarzanie odpowiedzi na SYN/ACK w stanie SYN_SENT
Oznaczenie gniazda jako poczonego i przetworzenie opcji skali okna
694 -701
Gniazdo zostaje oznaczone jako poczone i opcja skali okna jest przetwa rzana - jeli jest obecna.
W implementacji T /T C P Boba Bradena te dwie linie kodu bdnie zostay umieszczone przed sprawdzeniem wartoci CCecho.
Sekcja 11.5
147
Aktualizacja pamici TAO, jeli pami TAO jest niezdefiniowana

702-704
Segment jest akceptowalny, wic jeli wpis TAO dla danego serwera jest niezdefiniowany (po przeadowaniu klienta i wysaniu przez niego opcji CCnew), nastpuje jego uaktualnienie otrzyman wartoci CCecho (0, jeli opcja CCecho nie jest obecna).
Ustalenie wartoci rcv_adv
7 0 5-706
Warto rcv_adv zostaje uaktualniona, takjak to pokazano na rysunku 11.4. Warto snd_una (najstarszy niepotwierdzony numer sekwencyjny) zostaje zwi kszona o 1, poniewa nasz SYN zosta potwierdzony.
Czy ACK ma by opnione?
707-714
Jeeli serwer wysa dane w swoim segmencie SYN, to opniamy potwier dzenie. W przeciwnym przypadku wysyamy ACK natychmiast (jest to bowiem najprawdopodobniej drugi segment potrjnego uzgodnienia). Potwierdzenie zo staje opnione, poniewa - jeeli segment SYN serwera zawiera dane - to serwer uywa zapewne T /T C P i nie ma powodu, by wysya potwierdzenie natychmiast, skoro moemy oczekiwa kolejnych segmentw z dalszym cigiem odpowiedzi. Jeeli jednak okae si, e segment zawiera rwnie flag FIN serwera (drugi segment minimalnej, trzysegmentowej wymiany T /T C P), kod na rysunku 11.18 wczy flag TF_ACKN0W, by potwierdzenie zostao wysane natychmiast. W iem y,e t_state rwna si TCPS_SYN_SENT, ale jeeli ukrytaflaga stanu TF_SENDFIN jest rwnie wczona, znajdujemy si w istocie w stanie SYN_SENT*. W tym przypadku przechodzimy do stanu FIN_WAIT_1. (Tak na prawd - zgodnie z diagramem zmiany stanw w RFC 1644 - jest to kombinacja dwch zmian stanw. Otrzymanie flagi SYN w stanie SYN_SENT* zmienia stan na FIN_WAIT_1*, a potwierdzenie naszego segmentu SYN powoduje przejcie do stanu FIN_WAIT_1.) Klauzula el se odpowiadajca instrukcji i f na pocztku rysunku 11.8 pokazana zostaa na rysunku 11.9. Klauzula ta odpowiada jednoczesnemu otwarciu: wysa limy SYN i nastpnie otrzymalimy SYN bez flagi ACK. Ten fragment kodu zastpuje linie 581-582 na stronie 988 w tomie 2.
Natychmiastowe potwierdzenie i wyczenie zegara retransmisji
71 5 -7 2 6
73 9 -740
Potwierdzenie jest wysane natychmiast i zegar retransmisji (re tran sm issio n zostaje wyczony. Nawet przy wyczonym zegarze funkcja tcp_output bdzie wy woywana na kocu tcp_input, poniewa wczona jest flaga TF_ACKN0W. Zegar retransmisji ponownie uruchamia si w momencie, gdy potwierdzenie zo staje wysane, poniewa brak jest potwierdzenia co najmniej jednego bajtu danych (SYN).
im er )
148
Rozdzia 11
-----------------------------------------------------------------------------------------------727 728 729 730 731 732 7 33 734 735 736 737 73 8 739 740 741 742 743 744 7 45 746 747 7 48 74 9 75 0 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 } e ls e (
tcp_input.c
/* * J e d n o c z e s n e otwarcie. * Otrzymalimy i n i c j u j c y SYN w s t a n i e S Y N - S E NT [* ]. * Jeeli s e g m e n t z a w ie ra o pc j CC i i s tn i e j e z a c h o w a n a w a r t o * CC, s t o s u j e m y te st TAO. Jeeli test d a j e p o m y l n y wynik, * p o c z e n i e je st p o o w i c z n i e z s y n c h r o n i z o w a n e . * W p r z e c i w n y m razie w y k o n u j e m y p o t r j n e u z g o d ni en ie . * S Y N - S E N T -> SY N - RE C EIV ED * S Y N - S E N T * -> S Y N -RE C E I V E D * * Jeeli nie by o opcji CC - k a s u j e m y z a c h o w a n w a r t o CC. */ t p -> t _ f 1 ags |= T F _ A C K N 0 W ; tp-> t_ti m e r [ T C P T _ R E X M T ] = 0; if ( t o . t o _ f l a g & T O F _C C) l if ( t a o p - > t a o _ c c != 0 && C C _ G T ( t o .t o _ c c , t a o p - >t a o _ c c )) ( /* * u a k t u a l n i a m y p am i TAO i w y k o n u j e m y p r ze j c i a : * S Y N - S E N T -> E S T A B L I S H E D * * S Y N - S E N T * -> F I N - W A I T - 1 * */ tcpstat.tcps_taook++; taop->tao_cc = - to.to_cc; if (t p - > t _ f 1ags & T F _ S E N D F I N ) ( tp->t_state = TCPS_FIN_WAIT_1; t p -> t _ f 1ags &= ~ T F _ S E N D F I N ; ) else tp->t_state = TCPS_ESTABLISHED: t p -> t _ f 1 ags ]= TF__S E N D S Y N ; 1 else { tp->t_state = T C P S _SYN_RECEIVED: if ( t a o p - > t a o _ c c != 0) t c p s t a t .t cp s _ t a o f a i 1 + + : ) ) else ( /* C Cn e w lub brak opcji => s k a s o w a p am i T A O */ t a o p - > t a o _ c c = 0; tp->t_state = TCPS_SYN_RECEIVED; ) }
-------------------Rysunek 11.9 tcp_ inpu t -jednoczesne otwarcie
tcpjnput.c
Wykonanie testu TAO

741 - 755
Jeli otrzymany segment zawiera opcj CC, to wykonywany jest test TAO: warto zachowana (tao_cc) musi by niezerowa, a otrzymana warto CC wi ksza od wartoci zachowanej. Jeli test TAO daje wynik pozytywny, wtedy prze chowywana warto CC zostaje uaktualniona wartoci otrzyman i nastpuje przejcie ze stanu SYN_SENT do ESTABLISHED* lub ze stanu SYN_SENT* do stanu FIN_WAIT_1*.
Negatywny test TAO lub brak opcji CC
75 6-765
Jeli test TAO daje wynik negatywny, nowym stanem jest SYN_RCVD. Jeeli brak byo opcji C C , warto C C w pamici TAO ustalona zostaje na O (niezdefiniowana) i nowym stanem jest SYN_RCVD.
Sekcja 11.5
149
Na rysunku 11.10 widoczna jest etykieta trimthenstep6, do ktrej wykonany zosta skok na kocu przetwarzania w stanie LISTEN (rysunek 11.5). Wiksza cz kodu na tym rysunku jest skopiowana ze strony 990 w tomie 2. -----------------------------------------------------------------------------------------------767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 7 88 789 * 790 791 792 793
tcpjnput.c
trimthenstep6: /* * Z w i k s z a m y t i - > t i _ s e q tak, by o d p o w i a d a p i e r w s z e m y bajtowi * danych. Jeeli s dane, k o r y g u j e m y ich rozmiar, tak by zmieci * si w oknie, o d r z u c a j c FIN, jeli to konieczne. */ ti->ti _ s e q + + ; if ( t i->ti_len > tp-> r c v _ w n d ) ( tod r o p = t i - > t i _ l e n - tp->rcv_wnd; m_adj(m, -todrop); ti ->t i _ 1 e n = tp->rcv_wnd; tiflags &= TH__F I N ; t c p s t a t .t c p s _ r c v p a c k a f t e r w i n++; t c p s t a t .t c p s _ r c v b y t e a f t e r w i n += todrop; ) t p - > s n d _ w l l = ti -> t i_ se q - 1; t p - > r c v _ u p = ti ->t i _ s e q ; /* * J e s t e m y k l i e n t e m transa kc ji - w y s a l i m y ju SYN i dane. * Jeeli p a r t n e r uy T/ T C P do w e r y f i k a c j i SYN, n a sz e dane * z o s ta n p o t w i e r d z o n e - jeli tak, to r o z p o c z y n a m y n o r m a l n e * p r z e t w a r z a n i e s e g m e n t u da n y c h (w ro dk u step5) i p r z e t w a r z a m y potwierdzenie. W p r z e c i w n y m p r z y p a d k u w y k o n u j e m y s k o k do step6. */ if (tiflags & TH_ACK) go to p ro cessack; go t o step6;
--------------------------------------------------------------tc p jn p u t.c Rysunek 11.10 tc p _ i nput-etykieta trim th en step 6 osignita po aktywnym lub pasywnym otwarciu
ACK nie moe by pominite w przypadku klienta
784 - 793 Jeeli flaga ACK jest wczona, oznacza to, e jestemy klientem transakcji. To znaczy, nasz segment SYN zosta potwierdzony i znalelimy si tutaj po przejciu ze stanu SYN_SENT, a nie ze stanu LISTEN. W tym przypadku nie moemy wykona skoku do s tep6, poniewa spowodowaoby to ominicie prze twarzania potwierdzenia (patrz rysunek 11.1). Jeli wysalimy dane w naszym segmencie SYN, musimy przetworzy ewentualne potwierdzenie tych danych. (Zwyke TCP moe pomin przetwarzanie ACK w tym punkcie, poniewa dane nigdy nie s wysyane w segmencie SYN.) Nastpny krok przetwarzania zosta instrukcja s w i t c h (rozpoczynajca si przypadki (case) dla stanw LISTEN T /T C P dodaje przypadki dla stanw (ry su n e k ll.il). wprowadzony wraz z T /TC P. Zwykle na stronie 982 w tomie 2) zawiera tylko i SYN_SENT (ktre wanie opisalimy). LAST_ACK , CLOSING i TIME_WAIT
150
Rozdzia 11
794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825
------------------------------------------------------------------------------------- ----------
/* * W s ta ni e LAST_ACK, C L O S I N G lub T I M E _ W A I T : *jeeli s e g m e n t zawi e ra SYN i CC [nie CCnew] * i p a r t n e r r o z u m ie T/ T C P (c c_ re c v != 0): * if state = = T I M E _W AI T i czas trwa nia pocze ni a > MSL,
tcpjnput.c
* o d r z u c a m y pa k ie t i w y s y a m y RST * * jeeli SEG.CC > C Cr e cv w t e d y jest to no wy SYN i mo e * niejawnie po twierdzi FIN (i dane) w kolejce re t ra nsmisji. * Z a mykamy i ka sujemy TCPCB. P r z e t w ar z am y segment * ponownie - moe znajdziemy nowy TCPCB w stanie LISTEN; * * jeeli nie - musi to by sta ry SYN; od rzuci. * jeeli nie - w y k o n u j e m y n o r m a l n e p rz et w a r z a n i e . */ ca se T C P S _ L A S T _ A C K : ca se T C P S _ C L 0 S I N G : ca se T C P S _ T I M E _ W A I T : if ((ti f la gs & T H _ S Y N ) && ( t o . t o _ f l a g & T0F _C C) && t p - > c c _ r e c v != 0) ( if ( tp - > t _ s t a t e = = T C P S _ T I M E _ W A I T && t p - > t _ d u r a t i o n > TC P TV _M SL ) goto d r o p w i t h r e s e t ; if ( C C _ G T ( t o .t o _ c c , t p - > c c _ r e c v ) ) { tp = t c p _ c l o s e ( t p ) ; t c p s t a t .t c p s _ i m p l i e d a c k + + ; goto findpcb; 1 else goto drop; } brea k; /* k o n t y n u u j e m y normalne p r z e t w a r z a n i e */ }
------------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.11 t cp_ in p u t - pocztkowe przetwarzanie dla stanw LAST_ACK, CLOSING i TIM EJN AIT
8 1 2 -8 1 3
Nastpujce sprawdzenia zostaj wykonane tylko wtedy, jeli otrzymany segment zawiera flag SYN i opcj CC oraz jeli mamy zachowan warto CC dla tego hosta (cc_rec v jest rna od 0). Zauwamy te, e - b y znale si w jednym z tych trzech stanw - modu TCP musia wysa i otrzyma FIN (rysunek 2.6). TCP w stanach LAST_ACK i CLOSING czeka na potwierdzenie wysanej flagi FIN. Sprawdzane jest wic, czy nowy SYN w stanie TIME_WAIT moe bezpiecz nie skrci stan TIME_WAIT, albo czy nowy SYN w stanie LAST_ACK lub CLO SING niejawnie potwierdza wysan flag FIN.
Nie skraca TIME_WAIT, jeli czas trwania > MSL
8 1 4 -8 1 6
Zwykle jest dopuszczalne przyjcie nowego segmentu SYN w stanie TIME_WAIT (strona 998, tom 2). Jest to niejawne skrcenie stanu TIME_WAIT moliwe w systemach wywodzcych si z systemu Berkeley, przynajmniej od czasw N e t / l . (Rozwizanie wiczenia 18.5 z tomu 1 mwi o tej waciwoci.) W przypadku T /T C P skrcenie takie nie jest dopuszczalne, jeeli czas trwania poczenia bdcego w stanie TIME_WAIT jest wikszy ni MSL. Jeli mamy do czynienia z tak wanie sytuacj, to jest wysyana flaga RST. (Mwilimy o tym ograniczeniu w rozdziale 4.4.)
Sekcja 11.6
Zabezpieczenie przed za winitymi" numerami sekwencyjnymi (PA WSJ__________ 151_
Nowy SYN jest niejawnym potwierdzeniem istniejcego poczenia

8 1 7 -8 2 0
Jeli otrzymana warto CC jest wiksza ni przechowywana warto CC, wtedy test TAO daje wynik pozytywny (tzn. jest to nowy SYN). Istniejce pocze nie zostaje zamknite i nastpuje skok z powrotem do f i n d p c b w nadziei znalezie nia gniazda w stanie LISTEN, by przetworzy nowy SYN. Na rysunku 4.7 przed stawilimy przykad gniazda serwera, ktre znajdowaoby si w stanie LAST_ACK, gdy przetwarzane jest niejawne ACK.
11.6
Zabezpieczenie przed zawinitymi numerami sekwencyjnymi (PAWS)
Test PAWS (Protection Against Wrapped Sequence Numbers - zabezpieczenie przed zawinitymi" numerami sekwencyjnymi) pozostaje taki sam jak na stronie 991 w tomie 2 - jest to kod wykorzystujcy opcj znacznika czasu. Test pokazany na rysunku 11.12 umieszczany jest po sprawdzeniach dotyczcych znacznika czasu i sprawdza otrzyman opcj CC. ------------------------------------------------------------------------------------------------860 861 862 863 864 865 866 867 868 869 870 871
tcpjnput.c
/* * M e c h a n i z m T/TCP: * Jeli w y n e g o c j o w a n o u y ci e T/TCP. a s e g m e n t nie ma CC, lub * o t r z y m a n a opcja CC je st bdna, to s e g m e n t n a l e y odrz uc i . * S e g m e n t y RST nie m us z si do tego s t osowa. */ if ((tp ->t_f 1 ags & (TF_REQ_CC | TF_RCVD_CC)) = (TF_REQ_CC | TF_RCVD. ((to .t o f la g & T O F CC) = = 0 1 1 t p- >c c recv != t o . to cc) && ( t if la gs & T H _ R S T ) = = 0) ( tcpstat.tcps_ccdrop++; g ot o d r o p a f t e r a c k ; )
------------------------------------------------------------------------------------------------Rysunek 11.12 tcp_1 nput-sprawdzenie otrzymanej opcji CC

860-871
tcpjnput.c
Jeeli uywany jest protok T/T C P (flagi T F _ R E Q _ C C i T F _ R C V D _ C C s w czone), wtedy otrzymany segment musi zawiera opcje CC i warto CC musi by rwna wartoci uytej dla tego poczenia (cc_recv). W przeciwnym razie seg ment zostaje odrzucony jako duplikat starego segmentu (ale jest potwierdzony, poniewa potwierdzone zostaj wszystkie duplikaty starych segmentw). Jeeli segment zawiera flag RST, to nie zostaje on odrzucony, ale jest przetwarzany przez odpowiedni fragment kodu w dalszej czci funkqi.
11.7
Przetwarzanie ACK
Na stronie 1006 w tomie 2 wida, e segment zostaje odrzucony po przetworzeniu RST, jeeli flaga ACK nie jest ustawiona. To normalne zachowanie TCP zostaje zmodyfikowane w przypadku T /T C P - odpowiedni fragment kodu pokazujemy na rysunku 11.13.
152
Rozdzia 11
-----------------------------------------------------------------------------------------------1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035
tcpjnput.c
/* * Jeeli bit A C K jest 0 to w stanie S Y N - R E C E I V E D lub przy us t a w i o n e j * fl a d z e SENDSYN (poowiczna synchronizacja), dane u m i e s z c z a m y * w k o l e j c e - z o s tan p r z e t w o r z o n e pniej. W in n y c h p r z y p a d k a c h * o d r z u c a m y segment. */ if ((ti flags & T H _ACK) = = 0) { if (t p -> t _ s t a t e == T C P S _ S Y N _ R E C E I V E D || (t p -> t _ f 1ags & T F _ S E N D S Y N ) ) goto step6; else goto drop; )
------------------------------------------------------------------------------------------------Rysunek 11.13 tcp _ i n p u t - obsuga segmentw bez flagi ACK
tcpjnput.c
1024-1035 Jeeli flaga ACK jest wyczona, to w stanie SYN_RCVD lub przy wczo nej fladze T F_S E N D S Y N (tzn. poowiczna synchronizacja), segment nie jest odrzuca ny, lecz nastpuje skok do s t e p6. W ten sposb obsugujemy przypadek segmentu danych, ktry przybywa bez flagi ACK przed ustanowieniem poczenia, ale po pocztkowym segmencie SYN (przykadami takich segmentw s segmenty 2 i 3 z rysunku 3.9).
11.8
Zakoczenie pasywnych i jednoczesnych otwar
Przetwarzanie ACK jest kontynuowane w kodzie opisanym w rozdziale 29 w to mie 2. Wikszo kodu na stronie 1011 pozostaje bez zmian (linia 806 jest usuni ta), a kod na rysunku 11.14 zastpuje linie 813-815. W tym miejscu jestemy w stanie SYN_RCVD i przetwarzamy ACK, ktre zakacza potrjne uzgodnienie. Jest to normalne przetwarzanie po stronie serwera.
1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078
------------------------------------------------------------------------------I* */
tcpjnput.c
* Po p o m y l n y m p r z e p rowadzeni u p o t r j n e g o u z g o d n i e n i a u a k t u a l n i a m y
* pa m i TAO - jeeli bya n i e z d e f i n i o w a n a . P r z e k a z u j e m y d a n e z * kolejki do u y t k o w n i k a i o d p o w i e d n i o o k r e l a m y stan poc z e n i a .
if ((taop = t c p _ g e t t a o c a c h e ( i n p ) ) != NULL & & t a o p - > t a o _ c c = = 0) t a o p - > t a o _ c c = t p - > c c_recv;
/*
* W y k o n u j e m y przejcia: * SYN-RECEIVED -> E S T A B L I S H E D * S Y N - R E C E I V E D * -> FIN-WAIT-1 & TF_SENDFIN) ( = TCPS_FIN_WAIT_1; &= ~ T F _ S E N D F I N : = TCPS_ESTABLISHED;
if ( t p ->t _ f 1 ags tp->t_state t p ->t _ f 1 ags ) el se tp->t_state
*/
/*
*
* Jeeli segment zawiera dane lub FIN, tcp_reass() wywo a m y pniej; jeeli nie - robimy to teraz, by przekaza dane z kolejki do u y t k o w n i k a .
*/
Sekcja 11.9
Przetwarzanie A C K (kontynuacja)
153
10 79 10 80 1081 10 82 10 83
if (t i -> t i _ l e n = = 0 && ( t iflags & TH_F I N) == 0) (void) t c p _ re a ss (t p, (struct t c p i p h d r *) 0, (struct m b u f *) 0); t p - > s n d _ w l l = t i ->t i_seq - 1; /* w p a d a m y w ... */
-----------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.14 tcp_ in p u t - zakoczenie aktywnego lub pasywnego otzuarcia

Aktualizacja zachowanej wartoci CC, jeli warto ta jest niezdefiniowana
1 057-1064
Wpis TAO dla danego partnera zostaje wczytany i - jeli przechowywana warto CC wynosi 0 (niezdefiniowana) - zostaje ona uaktualniona otrzyman wartoci CC. Zwracamy uwag, e zdarza si to tylko wtedy, jeeli warto przechowywana jest niezdefiniowana. Przypominamy, e na rysunku 11.6 zmien na t a o _ c c jawnie otrzymaa warto 0, jeli opcja CC bya nieobecna (wic ta aktualizacja bdzie miaa miejsce, jeli przeprowadzone zostao potrjne uzgod nienie). Natomiast gdy test TAO da wynik negatywny, warto t a o _ c c pozostaa nie zmieniona. W przypadku negatywnego wyniku testu TAO chodzi o to, by segment SYN - przybywajcy w nieprawidowej kolejnoci - nie spowodowa zmiany tao_cc, tak jak to przedstawilimy na rysunku 4.11.
Przejcie do nowego stanu
1 065-1074
Stan SYN_RCVD przechodzi w stan ESTABLISHED i jest to normalna zmiana stanw TCP dla serwera zakaczajcego potrjne uzgodnienie. Stan SYN_RCVD* przechodzi w stan FIN_WAIT_1, poniewa proces zamkn wysya jc cz poczenia przy pomocy flagi M S G _ E 0 F .
Sprawdzenie: dane lub FIN
1075-1081
Jeli segment zawiera dane lub flag FIN, to - by przekaza dane do procesu - w punkcie oznaczonym etykiet doda ta wywoywana jest makroinstruk cja TCP_REASS (przypominamy rysunek 11.1). Na stronie 1031 w tomie 2 pokazano wywoanie tej makroinstrukcji w punkcie doda ta i ten kod nie zmienia si przy wprowadzeniu T /T C P. W przeciwnym przypadku - by przekaza do procesu dane znajdujce si w kolejce - t c p _ re ass jest wywoywana tutaj z drugim argumentem rwnym 0.
11.9
Przetwarzanie ACK (kontynuacja)
Algorytm szybkiej retransmisji (fast retransmit) i algorytm szybkiego odtworzenia poczenia (fast recovery) (rozdzia 29.4 w tomie 2) pozostaj niezmienione. Kod przedstawiony na rysunku 11.15 powinien zosta umieszczony pomidzy liniami 899 i 900 na stronie 1017 w tomie 2.
154
Rozdzia 11
-----------------------------------------------------------------------------------------------1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182
/*
tcpjnput.c
* Jeeli o s i g n l i m y ten punkt, A C K nie j e s t d u p l i k a t e m , * czyli co potwierdza. */ if (t p - > t _ f 1 ags & T F _ S E N D S Y N ) ( /* * T/TCP: P o c z e n i e byo p o o w i c z n i e z s y n c h r o n i z o w a n e i nasz * SYN zo s t a p o t w i e r d z o n y ( p o c z e n i e jest w i c teraz * w peni z s y n c h r o n i z o w a n e ) . W c h o d z i m y w stan bez gwiazdki * i z w i k s z a m y s n d _ u n a dla AC K s e g m e n t u SYN. */ t p ->t _ f 1 ags &= ~ T F _ S E N D S Y N ; t p - > snd_una++; I p r ocessack:
------------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.15 tcp _ i n p u t - wyczenie flagi TF_SENDSYN, jeli jest ona wczona
Wyczenie ukrytej flagi stanu TF_SENDSYN
1168-1181
Jeli ukryta flaga stanu T F _ S E N D S Y N bya wczona, zostaje ona wyczo na. Dzieje si tak dlatego, bo otrzymana flaga ACK potwierdza co, co wczeniej wysalimy, wic poczenie nie znajduje si ju w trybie poowicznej synchronizaq'i. Warto snd_una zostaje zwikszona o 1, poniewa segment SYN zosta potwierdzony i SYN zajmuje 1 bajt w przestrzeni numerw sekwencyjnych. Kod przedstawiony na rysunku 11.16 powinien zosta umieszczony pomidzy liniami 926 i 927 na stronach 1018-1019 w tomie 2. ------------------------------------------------------------------------------------------------1210
/*
tcpjnput.c
1211 1212 1213 1214 1215
* Jeeli p o t w i e r d z o n y by tylko *pomi j a m y reszt D r z e t w a r z a n i a */ if (acked == 0) goto step6;
SYN
(a nie dane), ACK.
------------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.16 tcp _in p u t -pomin pozosta cz przetwarzania ACK, jeeli adne dane nie zostay potwierdzone
Koniec przetwarzania ACK, jeeli brak potwierdzenia danych
1210- 1215
Jeeli nie nadeszo adne potwierdzenie danych (jedynie potwierdzony zosta nasz segment SYN), pozostaa cz przetwarzania ACK jest pomijana. Pominity zostaje fragment kodu, ktry otwiera okno przecienia ( congestion window) i usuwa potwierdzone dane z bufora wysykowego.
T o s p r a w d z e n i e i s k o k w y k o n y w a n e s niezalenie o d T / T C P . W ten s p o s b s k o r y g o w a n y zostaje bd o m a w i a n y w rozdziale 14.12, polegajcy n a tym, e se r w e r r o z p o c z y n a p o w o l n y start wysyajc d w a j e d n a k o w e (back-to-back) s e g m e n t y zamiast jednego.
Nastpna zmiana pokazana zostaa na rysunku 11.17, ktry zastpuje rysunek 29.12 ze strony 1023 w tomie 2. Jestemy w stanie CLOSING i przetwarzamy ACK, co powoduje zmian stanu poczenia na TIME_WAIT. T /T C P moe umoliwi skrcenie stanu TIME_WAIT (rozdzia 4.4).
Sekcja 11.10______________________ Przetwarzanie flagi FIN _______________________________ 155
-----------------------------------------------------------------------------------------------126 6 126 7 12 68 1269 12 70 1271 12 72 1273 1274 12 75 1276 1277 1278 1279 1280 1281 1282 12 83
tcpjnput.c
/* * W s t a n i e CL OSING, w u z u p e n i e n i u p r z e t w a r z a n i a dla st anu * E ST AB LI S HE D, jeeli A C K p o t w i e r d z a nasz FIN, * to w c h od z im y w stan T I M E - W A I T : w p r z e c i w n y m razie ig no ru j e m y * segment. */ ca se T C P S _ C L O S I N G : if (o u r f i n i s a c k e d ) ( tp->t_state = TCPS_TIME_WAIT; tcp_canceltimers(tp): /* S k r c e n i e T I M E _ W A I T [RFC 1644, s t r . 28] */ if (t p- > c c _ r e c v != 0 U t p - > t _ d u r a t i o n < T C P T V _ M S L ) tp->t_timer[TCPT_2MSL] = tp->t_rxtcur * TCP T V _ T W T R U N C ; else tp->t_ti m e r [ T C P T _ 2 M S L ] = 2 * T C P T V_ M SL ; soisdisconnected(so): ) break;
-----------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.17 tcp_ i n p u t - potzuierdzenie otrzymane w stanie T1ME_WAIT; ustalenie czasu trwania stanu TIME_WAIT
1 2 7 6- 1280
Jeli otrzymalimy od partnera warto CC i czas trwania poczenia by krtszy ni MSL, czas trwania stanu TIME_WAIT zostaje ustalony na T C P T V_T W T R U N C (8) razy aktualny czas oczekiwania na retransmisj.
11.10
Przetwarzanie flagi FIN
Nastpne trzy sekcje przetwarzania na wejciu TCP - aktualizacja informacji okna, przetwarzanie w trybie nagym i przetwarzanie otrzymanych danych - pozostaj nie zmienione w protokole T/TC P (patrz rysunek 11.1). Przypominamy rwnie (rozdzia 29.9 w tomie 2), e jeeli flaga FIN jest ustawiona, ale nie moe by potwierdzona, poniewa pojawia si przerwa w cigu numerw sekwencyjnych, kod w tej czci tcp_i nput wycza flag FIN. Dlatego na tym etapie przetwarza nia wiemy, e flaga FIN powinna zosta potwierdzona. Nastpna zmiana, ktr pokazujemy na rysunku 11.18, pojawia si przy przetwa rzaniu flagi FIN. Kod przedstawiony na tym rysunku zastpuje lini 1123 na stronie 1033 w tomie 2.
Decyzja o opnieniu ACK
1414-1424
Jeli poczenie jest poowicznie zsynchronizowane (czyli ukryta flaga stanu TF_SENDSYN wczona), potwierdzenie zostaje opnione i nastpi prba wysania potwierdzenia w segmencie zawierajcym dane (piggyback ACK). Jest to typowa sytuacja dla serwera T/TC P otrzymujcego segment SYN w stanie LISTEN - powoduje to ustawienie flagi T F_S E N DS Y N przez kod z rysunku 11.5. Zauwamy, e flaga opnionego potwierdzenia zostaa ju ustawiona na rysun ku 11.5, obecnie jednak TCP podejmuje decyzj na podstawie flagi FIN, ktra jest rwnie ustawiona. Jeeli flaga TF_SENDSYN nie jest wczona, potwierdzenie nie zostaje opnione.
156
R o z d z ia u
-----------------------------------------------------------------------------------------------1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426
tcpjnput.c
/* * Jeeli o t r z y m a l i m y FIN -p o t w i e r d z a m y FIN i i n f o r m u j e m y * uy t k o w n i k a , e p o c z e n i e jest zamykane. */ if ( ti flags & T H _ F I N ) ( if (TC PS_HAV E R C V D F I N ( t p - > t_s ta t e ) = = 0) ( socantrcvmore(so); /* * Jeeli p o c z e n i e jest p o o w i c z n i e z s y n c h r o n i z o w a n e (tzn. * w c z o n a flaga TF_S E N D S Y N ) , to o p n i a m y A C K - z o s t a n i e * ono n a o o n e na w y s y a n y SYN. * Jeeli nie jest, skoro o t r z y m a l i m y FIN, nie o t r z y m a m y nic * wicej, wic w y s y a m y AC K teraz. */ if (t p ->t_f 1 ags & T F _ S E N D S Y N ) t p ->t_f 1 ags |= TF_DELACK; else t p ->t_f 1 ags |= T F _ A C K N 0 W ; t p - > r cv_nxt++; 1
-----------------------------------------------------------------------------------------------Rysunek 11.18 tcp _ i nput-decyzja czy ACK ma by opnione
tcpjnput.c
Normalnie przejcie do stanu TIME_WAIT nastpuje ze stanu FIN_WAIT_2. To rwnie musi by zmodyfikowane na potrzeby T/TC P, tak by moliwe byo skrcenie stanu TIME_WAIT (rozdzia 4.4). Jest to pokazane na rysunku 11.19. Kod zaprezentowany na tym rysunku zastpuje linie 1142-1152 ze strony 1035 w tomie 2. tcpjnput.c
1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 /* * W stanie F I N _ W A I T _ 2 w c h o d z i m y w stan TIME_WAIT, * r o z p o c z y n a j c o d l i c z a n i e czasu o c z e k i w a n i a i w y c z a j c * inne s t a n d a r d o w e zegary. */ case T C P S FIN WAIT 2: tp - > t _ s t a t e = T C P S _ T I M E _ W A I T ; tcp c a n c e l t i m e r s ( t p ) : /* S k r c e n i e T I M E _ W A I T [RFC 1644, str.28] */ if (tp->cc recv != 0 && tp->t d u r a t i o n < T C PTV MSL) ( tp->t_timer[TCPT_2MSL] = tp->t_rxtcur * T C P T V _ TWTRUNC; /* Dla klienta t r a n s a k c y j n e g o w y m u s z a m y teraz A C K */ t p ->t _ f 1 ags |= T F _ A C K N 0 W ; 1 else tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL; soisdisconnected(so); break;
------------------------------------------------------------------------------------------------tcpjnput.c Rysunek 11.19 tcp_ in p u t - przejcie do stanu TIM EJNAIT, ewentualnie skrcenie oczekiwania
Okrelenie czasu trwania TIME_WAIT
1451-1453
Stan TIME_WAIT zostaje skrcony tylko wtedy, gdy otrzymalimy od partnera opcj CC i czas trwania poczenia jest mniejszy ni MSL (podobnie jak na rysunku 11.17).
Sekcja 11.11
Podsumowanie
157
Wymuszenie natychmiastowego potwierdzenia flagi FIN

1 45 4-1 455
Ta zmiana stanu zachodzi zwykle w module klienta T /T C P , kiedy odpowied serwera zawiera flagi SYN i FIN. Poniewa oba koce poczenia wysay flagi FIN, flaga FIN serwera powinna by potwierdzona natychmiast - nie ma powodu, by opnia potwierdzenie.
S dw ie sytuacje, w ktrych czas trw ania stanu TIM E_W AIT zaczyn a b y liczony od nowa: otrzymanie ACK w stanie TIME_WAIT oraz otrzymanie flagi FIN w stanie TIME_WAIT (strony 1024 i 1035 w tomie 2). T /T C P nie w prow adza tu zmian. Oznacza to, e - nawet jeli stan TIME_WAIT zosta skrcony i jeeli zduplikowana flaga ACK lub FIN zostaa otrzymana w tym stanie - czas trwania stanu zostaje ustawiony ponownie na 2MSL, a nie na zmniejszon warto. Informacja potrzebna do ustalenia skrconego czasu trwania stanu jest wci dostpna (tzn. blok kontrolny), ale poniewa partner musia pow trzy transmisj, bezpieczniej jest zrezygnowa ze skrcenia stanu TIME_WAIT.
11.11
Podsumowanie
Wikszo zmian zwizanych z T /T C P zlokalizowanych jest w tcp_i nput i doty czy gwnie otwierania nowego poczenia. Jeeli segment SYN zostaje odebrany w stanie LISTEN, to wykonujemy test TAO. Jeeli segment przejdzie przez ten test z wynikiem pozytywnym, oznacza to, e nie jest to duplikat starego segmentu i potrjne uzgodnienie nie musi by przepro wadzone. Jeeli segment SYN odbieramy w stanie SYN_SENT, opcja CCecho (jeli bya uyta) pozwala stwierdzi, czy SYN nie jest duplikatem starego seg mentu. Jeeli segment SYN zostaje odebrany w stanie LAST_ACK, CLOSING lub TIME_WAIT, segment ten moe by niejawnym potwierdzeniem, zamykajcym ostatecznie istniejce wcielenie poczenia. Jeeli poczenie zostaje aktywnie zamknite, stan TIME_WAIT zostaje skrcony, pod warunkiem e czas trwania poczenia by krtszy ni MSL.
12
Implementacja T/TCP: dania uytkownika TCP

12.1 Wstp
Funkcja t c p _ u s s r e q obsuguje wszystkie dania PRlLxxx warstwy gniazd. W obecnym rozdziale omwimy jedynie dania PRU_CONNECT, PRU_SEND i PRU_SEND_EOF, poniewa tylko one ulegaj zmianom przy wprowadzeniu T / T C P . Omawiamy rwnie funkcj tcp_us rcl osed, wywoywan, kiedy proces koczy wysyanie danych, oraz funkcj t c p _ s y s c t l , ktra obsuguje nowe zmien ne T C P . Nie omawiamy zmian w kodzie funkcji tcp_ctl o u t p u t (rozdzia 30.6 tomu 2) potrzebnych do obsugi nowych opcji gniazd: TCP_N0PUSH i TCP_N00PT. Koniecz ne zmiany s do proste i jednoznacznie wynikaj z samego kodu rdowego.
12.2
danie PRU_CONNECT
Przetwarzanie da PRU_C0NNECT przez funkcj t c p _ u s r r e q wymagao okoo 25 linii kodu (strona 1055 w tomie 2). Wraz z wprowadzeniem T /T C P wikszo kodu zostaje przeniesiona do funkcji t c p _ c o n n e c t (ktr pokazujemy w nast pnym podrozdziale), a pozostaje tylko fragment kodu przedstawiony na rysunku
12. 1.
137 138 139 140 141
-----------------------------------------------------------------------------------------------c a s e PRU.CONNECT: if ( ( error = t c p _ c o n n e c t ( t p , break; e r ror = t c p _ o u t p u t ( t p ) ; break; nam)) != 0)
tcp_usrreq.c
------------------------------------------------------------------------------------------------R ysunekl2.1 danie PRU_CONNECT

137-141
tcp_usrreq.c
t c p _ c o n n e c t wykonuje kroki konieczne do nawizania poczenia, a t c p _ o u t p u t wysya segment SYN (aktywne otwarcie).
Nawet jeeli oba hosty - lokalny i ten, z ktrym nawizywane jest poczenie znaj T/T C P, gdy proces wywouje connect, nastpuje normalne potrjne uzgod nienie. Dzieje si tak, poniewa nie jest moliwe przesanie danych jednoczenie z wywoaniem funkcji co n n e c t i funkcja t c p _ o u t p u t wysya tylko segment SYN. Aby pomin potrjne uzgodnienie, aplikacja nie moe wywoywa connect, powinna w zamian wywoa se ndto lub sendmsg, podajc dane i adres serwera.
160
Implementacja T/TCP: danie uytkownika TCP
Rozdzia 12
12.3
Funkcja tcp_connect
Nowa funkcja t c p_c o nne c t czyni kroki konieczne do przeprowadzenia aktywne go otwarcia. Funkcja ta jest wywoywana, gdy proces wykonuje connect (danie PRU_CONNECT) lub gdy proces wywouje sendto lub sendmsg, podajc adres part nera, z ktrym ma by nawizane poczenie. Pierwsza cz t cp_connect poka zana zostaa na rysunku 12.2. -----------------------------------------------------------------------------------------------295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 33 4 33 5 3 36 int t c p _ c o n n e c t ( t p . nam) s t r u c t t c pcb *tp; s t r u c t m b u f *nam; [ st r u c t inpcb *inp = t p - > t _ i n p c b . *oinp: st r u c t socket *so = in p - > i n p _ s o c k e t ; st r u c t tcp c b *otp; st r u c t s o c k a d d r _ i n *sin = mtod(nam, st r u c t s o c k a d d r _ i n st r u c t s o c k a d d r _ i n * i f a d d r ; int error; struct rmxp _ t a o *taop; st r u c t rmxp_tao t a o _ n o n c a c h e d ;
tcp_usrreq.c
*);
if (i n p ->i n p _ 1port == 0) ( err o r = in_p c b b i n d ( i n p . NULL); if (error) return (error); ] /* * Nie mona po pr o s t u w y w o a i n _ p cbconnect, p o n i e w a m o e i s t nie * w c z e n i e j s z e w c i e l e n i e tego samego po c z e n i a , p o z o s t a j c e w stanie * TIME_WAIT s p o w o d o w a o b y to bd A D D R I N U S E . */ e r ror = i n _ p c b l a d d r (i n p , nam, &ifaddr); oinp = in_pcblookup(inp->inp_head, s i n - > s i n _ a d d r . sin-> s i n _ p o r t . i n p - > i n p _ l a d d r . s _ a d d r != INADDR _ A N Y ? i n p - > inp _ l a d d r : i f a d d r - > s i n _ a d d r , i n p - > i n p _ l p o r t , 0): if (oinp) { if (oinp != inp && (otp = i n t o t c p c b ( o i n p ) ) != NULL o t p - > t _ s t a t e == T C P S _ T I M E _ W A I T && o t p - > t _ d u r a t i o n < T C P T V _ M S L && (o t p - > t _ f 1 ags & T F _ R C V D _ C C ) ) otp = t c p _ c l o s e ( o t p ) ; else return ( E A D D R I N U S E ) : ] if (i n p - > i n p __ 1a d d r .s _a dd r = = I NA D DR_ANY) inp->inp_laddr =ifaddr->sin_addr; i n p - > i n p _ f a d d r = s in -> si n _a dd r; inp->inp_fport = sin->sin_port; &&
------------------------------------------------------------------------------------------------Rysunek 12.2 Funkcja tcp _co n n ect, cz pierwsza

Zwizanie lokalnego portu
tcp_usrreq.c
308-312 nam wskazuje na internetow struktur adresow zawierajc adres IP i nu mer portu serwera, z ktrym ma by nawizane poczenie. Jeeli lokalny port nie
Sekcja 12.3
Funkcja tcp_connect
161
zosta jeszcze przypisany do gniazda (zwyky przypadek), i n_pcbbi nd przypisuje numer takiego portu (strona 758 w tomie 2).
Przypisanie lokalnego adresu, sprawdzenie jednoznacznoci pary gniazd
3 1 3 -32 3
i n_pcbl addr przypisuje lokalny adres, jeli taki adres nie zosta jeszcze zwizany z gniazdem (normalny przypadek). Funkcja i n_pcbl ookup szuka pasu jcego bloku, zwracajc niezerowy wskanik, jeeli blok taki zostaje znaleziony. Pasujcy blok powinien zosta znaleziony jedynie wtedy, gdy proces zwiza si z konkretnym lokalnym portem. Jeli i n_pcbbi nd wybiera lokalny port - jest to port aktualnie nie uywany. W przypadku T /T C P jest bardziej prawdopodobne, e klient zwie si z jednym lokalnym portem dla caego zestawu transakcji (rozdzia 4.2).
Poczenie istnieje; sprawdzenie, czy TIME_WAIT moe by skrcony
3 2 4 -3 3 2
Jeli znaleziony zosta pasujcy blok, wykonywane s nastpujce spraw dzenia:
- czy blok jest w stanie TIME_WAIT, - czy czas trwania poczenia by krtszy ni MSL, - czy poczenie uywao T /T C P (to znaczy, czy opcja CC lub CCnew zostaa otrzymana od partnera). Jeli wszystkie te warunki s spenione, istniejcy blok zostaje zamknity przez t cp_c l ose. Jest to skrcenie stanu TIME_WAIT, gdy nowe poczenie uywa tej samej pary gniazd i wykonuje aktywne otwarcie. Omawialimy ten przypadek w rozdziale 4.4.
Uzupenienie pary gniazd w internetowym PCB
3 3 3 -3 3 6
Jeli lokalny adres ma wci form wieloznaczn (wildccird ), warto wyzna czona przez i n_pcb 1 addr zostaje zapisana w PCB. Zewntrzny (foreign ) adres i port rwnie zostaj zapisane w PCB. Kolejne kroki na rysunku 12.2 s podobne do odpowiednich krokw w kocowej czci rysunku 7.5. Kocowa cz tcp_connect pokazana zostaa na rysunku 12.3. Ten kod jest podobny do ostatniej czci dania PRU_CONNECT ze strony 1055 w tomie 2.
Inicjacja nagwkw IP i TCP
337-341
tcp_templ a t e alokuje mbuf dla kopii nagwkw IP i TCP oraz inicjuje oba nagwki, wpisujc w nie wszystkie moliwe (aktualnie dostpne) informacje.
Obliczenie czynnika skali okna
342 - 345
Zostaje wyznaczona warto czynnika skali okna dla bufora odbiorczego .
162
Rozdzia 12
------------------------------------------------------------------------------------------------337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 )
cp_usrreq.c
tp->t_template = tcp_template(tp); if ( t p - > t _ t e m p l a t e = = 0) ( in_pcbdisconnect(inp); r et ur n (ENOBUFS); ) /* O b l i c z a m y d an e s k a l o w a n i e okna */ w h i l e ( t p - > r e q u e s t _ r _ s c a l e < T C P _ M A X _ W I N S H I F T && ( T C P _ M A X W I N << t p - > r e q u e s t _ r _ s c a 1e ) < s o - > s o _ r c v , s b _ h i w a t ) tp->request_r_scale++; s o i s c o n n e c t i n g ( s o ); tcpstat.tcps_connattempt++; tp->t_state = TCPS_SYN_SENT; tp->t_timer[TCPT_KEEP] = TCPTV_KEEP_INIT; t p ->i ss = tc p_iss; t c p j s s + = T C P _ I S S I N C R / 4; t c p _ s e n d s e q i ni t C t p ) ; /* * G e n e r u j e m y w a r t o CC dla tego p o c z e n i a i sp r aw d z a m y , czy * n a l e y uy CC, czy te CCnew. */ if ((taop = t c p _ g e t t a o c a c h e ( t p - > t _ i n p c b ) ) = = NULL) ( t ao p = & t a o _ n o n c a c h e d ; bzer o tt ao p, s i z e o f ( * t a o p ) ): ) tp->cc_send = CC_INC(tcp_ccgen); if ( t a o p - > t a o _ c c s e n t != 0 & & CC_GEQ(tp->cc_send, t a o p ->tao_ccsent)) ( t a o p - > t a o _ c c s e n t = t p -> cc _s e nd ; ] e ls e 1 t a o p - > t a o _ c c s e n t = 0; t p - > t _ f 1ags 1= T F _ S E N D C C N E W ; ) r eturn (0);
------------------------------------------------------------------------------------------------Rysunek 12.3 Funkcja tcp _co n n ect, cz druga

Ustalenie stanu gniazda i poczenia
346-349
tcp_usrreq.c
soi sconnecti ng ustawia odpowiednie bity w zmiennej stanu gniazda, a stan poczenia T C P jest ustalony na SYN_SENT. (Zobaczymy wkrtce, e jeeli proces wywoa sendto lub sendmsg z flag MSG_E0F zamiast connect, to funkcja tcp_usrcl osed ustawia ukryt flag stanu TF_SENDSYN, wprowadzajc pocze nie w stan SYN_SENT*. Zegar nawizywania poczenia zostaje zainicjowany wartoci 75 sekund.)
Inicjacja numerw sekwencyjnych
350-352
Pocztkowy wysykowy numer sekwencyjny zostaje skopiowany z global nej zmiennej tcp_iss i zmienna ta zostaje nastpnie zwikszona o warto T C P _ I S S I NCR podzielon przez4. Wysykowe numery sekwencyjne s inicjowane przez tcp_sendseqi ni t.
Przypisanie ISS losowej wartoci, co omawialimy w rozdziale 3.2, odbywa si w makroinstrukqi TCP_ISSINCR.
Sekcja 12.4
dania P RU _SEN D i P R U _SE N D _EO F
163
Ustalenie wartoci CC
353-361
Zawarto pamici TAO dla danego partnera zostaje wczytana. Warto zmiennej globalnej tcp _ccgen jest zwikszana o CC_I N C (rozdzia 8.2) i zapisuje si j w zmiennej tcp_ccgen. Tak jak zauwaylimy wczeniej, warto t c p_c c g e n jest zwikszana dla kadego poczenia nawizywanego przez hosta bez wzgldu na to, czy opcje CC s uywane, czy nie.
Stwierdzenie, czy opcja CC lub CCnew ma by uywana
362-368
Jeeli wpis w pamici TAO dla danego hosta (tao_ccsent) jest niezerowy (czyli to nie pierwsze poczenie z tym hostem) i warto cc_send jest wiksza bd rwna tao_ccsent (warto CC nie jest zawinita"), wtedy opcja CC zostaje wysa na i do pamici TAO wpisuje si now warto CC. W przeciwnym przypadku, wysana jest opcja C C n ew i t a o_c c s e n t otrzymuje warto 0 (niezdefiniowana).
Wrmy do rysunku 4.12, by zobaczy, w jaki sposb druga cz instrukcji i f moe otrzyma warto fasz" - ostatnia warto CC wysana do tego hosta wynosi 1 (tao_ccsent), ale aktualna warto tcp_ccgen (ktra staje si wartoci cc_send dla tego poczenia) jest 2 147483 648. T /T C P musi wysa opcj CCnew zamiast opcji CC, poniewa - jeli wylemy opcj CC z wartoci 2 147 483 648, a partner cigle przechowuje nasz ostatni warto CC (1) - partner wymusi potrjne uzgodnienie, warto CC jest bowiem zawinita". Host na drugim ko cu poczenia nie moe stwierdzi, czy SYN z wartoci CC rwn 2 147 483 648 jest duplikatem starego segmentu, czy nie. Rwnie, jeeli wylemy opcj CC, nawet po pomylnym przeprowadzeniu potrjnego uzgodnienia, partner nie uaktualni informacji TAO dla naszego hosta (przypominamy rysunek 4.12 raz jeszcze). Wysyajc opcj CCnew, klient wymusza potrjne uzgodnienie oraz po woduje, e serwer po przeprowadzeniu potrjnego uzgodnienia, uaktualni zacho wan warto CC.
Implementacja T /T C P Boba Bradena sprawdza, czy naley wysa opcj CC, czy te CCnew w funkcji tc p_output, a nie tutaj. Jest to przyczyn subtelnego bdu, ktry uwidacznia si w sposb opisany poniej [Olah 1995]. Rozwam y sytuacj przedstawion na rysunku 4.11, ale zamy, e segment 1 zostaje skasowany przez jaki poredniczcy ruter. Segmenty 2-4 pozostaj bez zmian i to poczenie z portu 1601 klienta zakoczone zostaje pomylnie. Nastpnym segmentem jest przesany ponownie segment 1. Zawiera on jednak teraz opcj CCnew z wartoci 15. Jeeli segment ten jest pomylnie odebrany, w ym usza on potrjne uzgodnienie ze strony serwera. Po przeprowadzeniu potrjnego uzgodnienia serwer wpisuje do pamici TAO dla klienta warto CC rw n 15. Jeeli sie dostarczy teraz duplikat starego segmentu 2 z wartoci CC 1500, segment ten zostanie zaakceptowany przez serwera. Sprawdzenie czy wysa opcj CC, czy CCnew powinno wic odbywa si, gdy klient wykonuje aktywne otwarcie, a nie - gdy segment jest wysyany przez t c p_o u t p u t.
12.4
dania PRU_SEND i PRU_SEND_EOF
Na stronie 1058 w tomie 2 przetwarzanie dania PRU_SEND sprowadza si do wywoania sbappend i nastpnie tcp_output. W przypadku T /T C P danie to jest przetwarzane dokadnie w ten sam sposb, jednak kod jest teraz poczony
164
Implementacja TfTCP: danie uytkownika TCP
Rozdzia 12
z kodem odpowiedzialnym za przetwarzanie dania PRU_SEND_EOF, co pokazu jemy na rysunku 12.4. Widzielimy wczeniej, e danie P R U _ S E N D _ E O F jest wygenerowane dla TCP przez sosend, gdy zostaa podana flaga M S G _ E 0 F (rysu nek 5.2) i gdy do protokou zosta wysany ostatni bufor mbuf. -----------------------------------------------------------------------------------------------169 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205
206
tcpjusrrecj.c
case P R U _SEND_E0F: case PRU_SEND: s b a p p e n d ( & s o - > s o _ s n d , m); if (nam && t p - > t _ s t a t e < T C P S _ S Y N _ S E N T ) ( /* * Jeeli p o c z e n i e nie jest j e s z c z e nawiz a n e , w y k o n u j e m y * n i e j a w n e otwarcie, i n i c j u j e m y okno w a r t o c i domyln i * inicjujemy m a x s e g / m a x o p d uyw a j c warto c i MSS zachowanej * dla tego partnera. */ e r ror = t c p _ c o n n e c t ( t p , nam); if (error) break; tp->snd_wnd = TTCP_CLIENT_SND_WND; t c p _ m s s r c v d ( t p , -1); ] if (req = = P R U _ S E N D _ E 0 F ) [
/*
207 208 209 210 211

212 1
* Z a m kn w y s y a j c po o w p o czenia, jeeli dane * z o s t a y wysane. */ socantsendmore(so); tp = t c p _ u s r c l o s e d ( t p ) ; if (tp != NULL) err o r = t c p _ o u t p u t ( t p ) ; break;
213 214 215
------------------------------------------------------------------------------------------------Rysunek 12.4 dania PRU_SEND i PRU_SEND_EOF

Niejawne connect
tcp_usrreq.c
192-202 Jeli argument namjest niepusty, oznacza to, e proces wywoa sendto lub s en dms g i poda adres partnera. Jeli poczenie jest w stanie CLOSED lub LISTEN, wtedy tcp_connect niejawnie nawizuje poczenie. Pocztkowy rozmiar okna zostaje ustawiony na 4096 (TTC P_C LIE N T_S N D_W N D), poniewa klient T /T C P moe wysa dane przed otrzymaniem od serwera informacji o rozmiarze okna (rozdzia
3.6). Ustalenie pocztkowej wartoci MSS dla poczenia
203-204 Wywoanie tcp_mssrcvd z drugim argumentem rwnym -1 oznacza, e jeszcze nie otrzymalimy segmentu SYN, tak wic warto przechowywana dla tego hosta (t a o_ms s opt) zostaje uyta jako pocztkowa warto MSS. Po wykona niu tcp_mssrcvd wartoci zmiennych t_maxseg i t_maxopd s ustalane na pod stawie przechowywanej wartoci t a o_ms s opt lub na podstawie wartoci dla kon kretnego hosta wpisanej przez administratora systemu do tablicy rutowania (czon rmx_mtu struktury rt_metri cs). Funkcja tcp_mssrcvd zostanie wywoana ponownie przez tcp_doopt i ons, gdy serwer otrzyma segment SYN z opcj MSS. T/TC P musi jednak ustali warto MSS w bloku kontrolnym TCP teraz, przed
Sekcja 12.5
Funkcja tcp_usrclosed
165
otrzymaniem segmentu SYN, poniewa dane s wysyane przed otrzymaniem opcji MSS od partnera.
Przetwarzanie flagi MSG.EOF
2 05 - 2 1 2
Jeli flaga MSG_E0F bya podana przez proces, socantsendmore ustawia flag gniazda SS_CANTSENDM0RE. Funkcja tcp_usrcl osed zmienia wwczas stan poczenia ze stanu SYN_SENT (ustawionego przez tcp_connect) na stan SYN_SENT*.
Wysanie pierwszego segmentu
2 13 - 2 14
tcp_output sprawdza, czy segment powinien by wysany. W przypadku klienta T /T C P , ktry wywouje sendto z flag MSG_E0F (rysunek 1.10), wywoanie tcp_output powoduje wysanie segmentu zawierajcego SYN, dane i FIN.
12.5
Funkcja tcp_usrclosed
W kodzie N e t/3 funkcja ta bya woana przez tcp_di sconnect oraz gdy byo przetwarzane danie PRU_SHUTD0WN. W T /T C P - jak widzielimy na rysunku 12.4 - funkcja ta jest rwnie woana przez danie PRU_SEND_E0F. Na rysunku 12.5 pokazana zostaa funkcja zastpujca kod na stronie 1066 w tomie 2. -----------------------------------------------------------------------------------------------533 st r u c t tcp c b * 534 t c p _ u s r c l o s e d ( t p ) 535 st r u c t tcpcb *tp; 535 [ 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 ) sw i t c h (t p - > t _ s t a t e ) I
tcp_usrreq.c
case TCPS_CLOSED: case T C P S _ LISTEN: tp->t_state tp = t c p _ c l o s e ( t p ) ; break; case T C P S _ S Y N _ S E N T : case T C P S _ S Y N _ R E C E I V E D : tp->t_flags break; case T C P S _ E S T A B L I S H E D : tp->t_state break;
= TCPS_CL0SED;
|= T F _ S E N D F I N ;
= TCPS_FIN_WAIT_1;
case TCPS_CL0SE_WAIT; tp->t_State = TCPS_LAST_ACK; break; ] if (tp && t p - > t _ s t a t e >= T C P S _ F I N _ W A I T _ 2 ) s o i s d i s c o n n e c t e d ( t p - > t _ i n p c b - > i n p _ s o c k e t ); return (tp);
------------------------------------------------------------------- tcp_usrreq.c
R ysunekl2.5 Funkcja t c p _ u s r c l osed
166
Rozdziaf 12
543-546
Dla poczenia T /T C P zainicjowane przez uytkownika zamknicie w sta nach SYN_SENT lub SYN_RCVD powoduje przejcie do odpowiedniego stanu z gwiazdk przez ustawienie flagi TF_SENDFIN. Pozostae zmiany stanw nie zo staj zmodyfikowane przez T/TC P.
12.6
Funkcja tcp_sysctl
W raz ze zmianami zwizanymi z T /T C P wprowadzono rwnie moliwo m o dyfikacji zmiennych TCP przy pomocy programu sysctl . Modyfikacja ta - cho nie zwizana cile z T /T C P - umoliwia atwiejsz, w porwnaniu z uyciem debugera, modyfikacj niektrych zmiennych TCP. Zmienne TCP osigane s z uyciem przedrostka net.inet.tcp. Wskanik do tej funkcji jest przechowywa ny w czonie pr_sysctl struktury TCP protosw (strona 829, tom 2). Funkcja ta pokazana zostaa na rysunku 12.6. ------------------------------------------------------------------------------------------------561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 int t c p _ s y s c t l C n a m e , na melen, oldp, oldle n p, newp, newl en ) int *name; u _int na melen; void *oldp; s i z e _ t * o ldlenp; vo id *newp: s i z e _ t newlen; ( e x t e r n int t c p _ d o _ r f c l 3 2 3 ; e x t e r n int t c p _ d o _ r f c l 6 4 4 ; e x t e r n int t c p_ ms sd f lt ; /* W s z y s t k i e naz wy sysctl na t ym p o z i o m i e s k o c z c e */ if ( na m el en != 1) re t u r n (E NOTDIR): s w i t c h ( name[0]) ( ca se T C P C T L _ D 0 _ R F C 1 3 2 3 : re t u r n (s y s c t l _ i n t (o l d p , oldlen p, ca se T C P C T L _ D 0 _ R F C 1 6 4 4 : re tu rn (s ys c t l _ i n t ( o l d p , oldlenp, case T C P C T L _ M S S D F L T : return ( s y s c t l _ i n t ( o l d p , oldlen p, de fa ul t : re tu rn ( E N 0 P R 0 T 0 0 P T ) ; ) /* n i e o s i g a n y */ 1
tcp_usrrecj.c
newp, newlen, 4 t c p _ d o _ r f c l 3 2 3 )); newp, newlen, & t c p _ d o _ r f c l 6 4 4 )); newp, newlen, & t c p _ m s s d f l t ) );
------------------------------------------------------------------------------------------------Rysunek 12.6 Funkcja tcp_sysctl

570-572
cp_usrreq.c
Dostpne s na razie tylko trzy zmienne. Kolejne zmienne mog by atwo udostpnione.
12.7
Przyszo T/TCP
Ciekawe moe by przeledzenie, jak upowszechniay si zmiany TCP wprowa dzone w RFC 1323, czyli opq'e skali okna i znacznika czasu. Przyczyn wprowa
Sekcja 12.8
Podsumowanie
167
dzenia tych zmian byo zwikszenie szybkoci sieci (linie telefoniczne T3 i FDDI) i moliwo uywania cieek o duym opnieniu (poczenia satelitarne). Jedna z pierwszych implementacji zostaa wykonana przez Thomasa Skibo dla stacji roboczych SGI. Ten sam autor zmodyfikowa nastpnie kod N e t/2 systemu Berke ley i publicznie udostpni wprowadzone zmiany w maju 1992 roku. Mniej wicej rok pniej (kwiecie 1993) Bob Braden i Liming Wei udostpnili podobne, oparte na RFC 1323, zmiany kodu rdowego dla SunOS 4.1.1. Zmiany wprowadzone przez Skibo zostay dodane do wersji 4.4BSD systemu Berkeley w sierpniu 1993 roku i udostpniono je publicznie wraz z systemem 4.4BSD-Lite w kwietniu 1994 roku. Do roku 1995 niektrzy komercyjni dostawcy uwzgldnili RFC 1323 w ofe rowanych systemach, inni poinformowali o takim zamiarze. RFC 1323 nie jest jednak stan-dardem, szczeglnie jeli chodzi o implementacje PC. (Rzeczywicie, w rozdziale 14.6 widzimy, e mniej ni 2% klientw kontaktujcych si z konkret nym serwerem WWW wysao opcje skali okna i znacznika czasu.) Upowszechnianie T /T C P bdzie prawdopodobnie przebiegao podobnie. Pierw sza implementacja z wrzenia 1994 roku (rozdzia 1.9) zawieraa zmiany kodu rdowego dla SunOS 4.1.3 i bya mao interesujca dla wikszoci uytkowni kw, chyba e dysponowali oni kodem rdowym systemu SunOS. Jest to jednak podstawowa implementacja T /T C P napisana przez twrc protokou. Implemen tacja FreeBSD (oparta na zmianach w kodzie rdowym SunOS), udostpniona publicznie na pocztku roku 1995, przeznaczona na wszechobecn platform sprztow (80x86), powinna spowodowa rozpowszechnienie T /T C P wrd wie lu uytkownikw. Celem tej czci ksiki byo przedstawienie przykadw T /T C P , tak by jasne si stao, dlaczego T /T C P jest wartociowym rozszerzeniem TCP, a take szczego we udokumentowanie i objanienie zmian w kodzie rdowym. Podobnie jak w przypadku zmian opisanych w RFC 1323, implementacje T /T C P wsppracuj z implementacjami nie obsugujcymi T /TCP i opcje CC s uywane tylko wtedy, jeeli oba koce poczenia potrafi te opcje przetworzy.
12.8
Podsumowanie
W raz z T / TC P wprowadzono now funkcj - tcp_connect. Jest ona wywoywa na przy jawnym wykonaniu connect i przy niejawnym nawizaniu poczenia (sendto lub se nd m s g z podaniem adresu przeznaczenia). Dopuszcza ona utworze nie nowego wcielenia poczenia znajdujcego si w stanie TIME_WAIT, jeeli poczenie to wykorzystywao T /T C P i jeli czas trwania tego poczenia by krtszy ni MSL. Zostao te wprowadzone nowe danie - PRU_SEND_E0F. danie to jest genero wane przez warstw gniazd, gdy pojawia si ostateczne wywoanie wyjcia proto kou i jeli aplikacja podaje flag MSG_E0F. To danie dopuszcza niejawne nawi zanie poczenia i rwnie wywouje tcp_usrcl osed, jeeli zostaa podana flaga
MSG_E0F.
168
Rozdzia 12
W funkcji t c p _u s rc l osea wprowadzona zostaa jedna modyfikacja. Modyfikacja ta umoliwia procesowi zamknicie poczenia znajdujcego si wci w stanie SYN_SENT lub SYN_RCVD. Wykonanie takiego zamknicia powoduje ustawie nie ukrytej flagi TF_SENDFIN.
13
HTTP protok przesyania hipertekstu

-
13.1
Wstp
HTTP - protok przesyania hipertekstu (Hypertext Transfer Protocol) jest podsta w W W W - wiatowej Pajczyny ( World Wide Web). W tym rozdziale przedstawia my ten protok, a w nastpnym badamy dziaanie rzeczywistego serwera WWW, wracajc do wielu zagadnie z tomw 1 i 2 w kontekcie dziaania aplikacji w rzeczywistych warunkach. Naley na wstpie zaznaczy, i ten rozdzia nie jest wprowadzeniem do Pajczyny, ani nie zawiera omwienia przegldarki WWW. Dane statystyczne ze szkieletowej sieci NSFnet (rysunek 13.1) pokazuj niepra wdopodobny wzrost intensywnoci uywania HTTP od stycznia 1994 do kwietnia 1995 roku.
Miesic HTTP NNTP RP (dane) 21,4 20,0 19,8 19,7 18,8 14,0 Telnet SMTP DNS Liczba pakietw x109 55 71 74 100 87 59
Stycze Kwiecie Lipiec
1994 1994 1994
1,5 2,8 4,5 7,0 13,1 21,4
8,8 9,0 10,6 9,8 10,0 8,1
15,4 13,2 13,9 12,6 10,4 7,5
7,4 8,4 7,5 8,1 7,4 6,4
5,8 5,0 5,3 5,3 5,4 5,4
Padziernik 1994 Stycze Kwiecie 1995 1995
Rysunek 13.1 Liczba pakietio (w procentach) dla rnych protokow w szkieletowej sieci NSFnet Przedstawione liczby dotycz liczby pakietw, a nie liczby przesanych bajtw. (Wszystkie te statystyki s dostpne w f t p :/ / f t p .mer i t .edu/sta t i sti cs.) Wi dzimy, e procentowy udzia pakietw HTTP ronie, maleje natomiast udzia pakietw FTP i Telnetu. Zauwaamy rwnie, i cakowita liczba pakietw rosa w roku 1994, by nastpnie zmale w roku 1995. Przyczyn spadku liczby pakietw jest fakt, e inne szkieletowe sieci zaczy zastpowa NSFnet w grudniu 1994 roku. Mimo to porwnanie wzgldnej liczby pakietw w dalszym cigu zwraca uwag i wskazuje na wzrost wykorzystania HTTP. Zasada dziaania Pajczyny zostaa przedstawiona w uproszczony sposb na ry sunku 13.2.
170
H TTP - protok przesyania hipertekstu
Rozdzia 13
Rysunek 13.2 System klient-serwer w wiatowej Pajczynie Klient WWW, czsto nazywany przegldark (browser) W W W nawizuje kontakt z serwerem WWW, uywajc jednego lub wicej pocze TCP. Dobrze-znanym portem (well-known port) serwera WWW jest port numer 80. Serwer i klient do komunikacji po poczeniu TCP uywaj protokou zwanego HTTP (Hypertext Transfer Protocol - protok przesyania hipertekstu), omawianego w tym rozdzia le. Pokazujemy rwnie, jak dany serwer moe wskazywa na" inne serwery W W W przy pomocy linkw hipertekstu (hypertext links). Linki te nie s ograniczone zreszt do wskazywania tylko na kolejne serwery WWW. Serwer W W W moe take wskazywa na przykad na serwer FTP lub serwer Telnetu. Cho protok HTTP by uywany od roku 1990, pierwsza dokumentacja tego protokou pojawia si dopiero w roku 1993 ([Bemers-Lee 1993], przybliony opis wersji 1.0 HTTP). By to dokument typu szkicu internetowego" (Internet draft), ktry ju dawno temu utraci wano (i nie jest dostpny). W czasie gdy powstaje ta ksika najnowsz dostpn wersj dokumentami jest opracowanie T. Bemersa-Lee i wsppracownikw [Bemers-Lee, Fielding i Nielsen 1995]), wci jeszcze w for mie szkicu internetowego. Specjalnym rodzajem dokumentu dostarczanego klientowi przez serwera WWW jest tekst w jzyku hipertekstoioego znakowania informacji - HTML (Hypertext Markup Language), opisanym w [Bemers-Lee i Connolly 1995]. Serwer dostarcza rwnie dokumenty innego rodzaju (pliki graficzne, PostScript, prosty format tekstowy, itd.) - kilka przykadw pokaemy w dalszej czci tego rozdziau. W nastpnym podrozdziale przedstawimy krtkie wprowadzenie do protokou HTTP i do dokumentw HTML, po czym przeanalizujemy protok HTTP bardziej szczegowo. Nastpnie przyjrzymy si, w jaki sposb popularna przegldarka (Ne tscape) uywa tego protokou, przedstawimy troch danych statystycznych dotycz cych uycia TCP przez HTTP i omwimy pewne zagadnienia zwizane z szybkoci dziaania HTTP. Wiele spotykanych na co dzie problemw zwizanych z funkcjo nowaniem serwera W W W jest opisanych w pracy [Stein 1995].
Sekcja 13.2
Wprowadzenie do H TTP i HTML
171
13.2
Wprowadzenie do HTTP i HTML
HTTP jest prostym protokoem. Klient nawizuje poczenie TCP z serwerem, wysya danie i odczytuje odpowied serwera. Serwer zaznacza koniec swojej odpowiedzi zamykajc poczenie. Plik udostpniony przez serwera zwykle za wiera wskaniki (linki hipertekstu) do innych plikw rozmieszczonych w innych serwerach. Prostota protokou z punktu widzenia uytkownika polega na atwoci ledzenia linkw pomidzy rnymi serwerami.
To klient (przegldarka) zapewnia t prostot dla uytkownika, korzystajc z wyszukanego interfejsu graficznego. Serwery HTTP jedynie udostpniaj dokumenty zadane przez klienta. Serwer jest wic prostszy ni klient. Na przykad serwer NCSA wersji 1.3 dla systemw unixowych zawiera okoo 6500 linii kodu rdowego w C, natomiast unbcowy klient, Mosaic 2.5, dziaajcy w systemie X Windows, m a okoo 80 000 linii kodu w C.
Podobnie jak przy wielu innych protokoach internetowych, najatwiejszym spo sobem przyjrzenia si dziaaniu protokou jest uruchomienie klienta Telnetu i po czenie si z odpowiednim serwerem. W przypadku HTTP jest to moliwe, poniewa klient wysya do serwera komendy ASCII (zakaczane znakami karetki i nowej linii, oznaczanymi C R /LF), a odpowied serwera rozpoczyna si liniami ASCII. HTTP uywa 8-bitowego zestawu znakw ISO Latin 1, bdcego rozsze rzeniem ASCII, uwzgdniajcym znaki uywane w jzykach zachodnio-europej skich rwnie ISO Latin 2 - znaki z jzykw rodkowoeuropejskich, w tym polskie - przyp. tum. (Informacja na temat rnych zestaww znakw dostpna jest w http: / / un ic o d e. org.) W przykadzie przedstawionym poniej cigamy stron wywoawcz w ydaw nictwa Addison-Wesley.
sun % t e l n e t www.aw.com 80 Trying 192.207.117.2... C o n n e c t e d to aw.com. E sc a p e c h a r a c t e r is A] .
GET /
<HTML> < HEAD> <TITLE>AW s HomePage</TITLE> < /HE A D> < B0DY> < C E N T E R X I M G SRC = " a w p l o g o b . g i f " ALT=" ><BRX/CENTER> A d d i son-Wesley L o n g m a n < / H l X / C E N T E R > W e l c o m e to o ur Web serve r.
poczenie z portem 80 serwera wydruk klienta Telnetu wydruk klienta Telnetu wydruk klienta Telnetu wpisujemy tylko t lini pierwsza lima wydruku serwera WWW
< D D X I M G A L I G N = b o t t o m SR C="bal 1_whi .g i f " ALT=" "> I n f o r m a t i o n Re s o u r c e <A H R EF = "h t t p : / / w w w . n c s a . u i u c . e d u / S D G / S o f t w a r e / M o s a i c / M e t a I n d e x . h t m l "> Meta- Index </ A > </B0 DY > </HT ML > C o n n e c t i o n cl os ed by fore ig n host.
pomijamy 33 linie wydruku
omijamy 4 linie xvydruku wydruk klienta Telnetu
Wpisujemy jedynie lini GET / i serwer przesya 51 linii zawierajcych 3611 bajtw. W ten sposb cignita zostaje strona wywoawcza (home page) serwera z katalogu gwnego serwera WWW. Ostatnia linia wydruku klienta Telnetu oznacza, e serwer zamyka poczenie po wypisaniu ostatniej linii.
HTTP - protok przesyania hipertekstu
Rozdzia 13
Kompletny dokument w HTML zaczyna si od < H T M L > i koczy si na < / H T M L > . Wikszo komend HTML zgrupowanych jest w podobne pary. Dokument zawie ra nagwek (hecid), ograniczony przez < H E A D > i < / H E A D > oraz korpus (body), ograniczony przez <B0DY> i < / BODY>. Tytu (<TITL E > ) jest zwykle wywietlany przez klienta w grnej czci okna. Jzyk HTML zosta przedstawiony bardziej szczegowo w opracowaniu [Raggett, Lam i Aleksander 1996]. Nastpna linia wyszczeglnia plik graficzny (w tym przypadku logo korporacji).
< C E N T E R X I M G SRC = "a wp l o g o b . g i f " A L T = " "> 
Znacznik <CENTER> informuje klienta, e grafika ma by umieszczona porodku linii, a instrukcja <IMG> zawiera informacje o obrazie graficznym. SRC podaje nazw pliku graficznego, ktry klient musi cign, a A L T zawiera cig znakw, ktry trzeba wywietli, jeli klient nie ma moliwoci wywietlania grafiki (w tym przypadku jest to tylko spacja). oznacza koniec linii. Serwer nie wysya pliku graficznego wraz ze stron wywoawcz. Wysyana jest tylko nazwa pliku zawie rajcego t grafik i klient musi otworzy nowe poczenie TCP do serwera, by cign ten plik. (Zobaczymy w dalszej czci tego rozdziau, e wymg tworze nia nowego poczenia dla kadego wskazywanego pliku graficznego zwiksza obcienie serwera.) Nastpna linia

rozpoczyna nowy akapit ( ), tekst powinien by umieszczony na rodku linii 1 jest to nagwek pierwszego poziomu <H1> (istniej te nagwki poziomw od 2 do 7), zwykle wywietlany wiksz i pogrubion czcionk.
Widzimy tu rnic pomidzy jzykiem znakowania informacji (markup language), a jzykiem formatowania tekstu (formatting language), takim jak na przykad Troff, TeX czy PostScript. HTML wywodzi si z SGML, standardowego uoglnionego jzyka znakowania informa cji (Standard Generalized Markup Language). (Wicej informacji o SGML m ona znale w h t t p : //www. sgml o pen. org .) HTML okrela zawarto dokumentu i jego struktur (na gwek pierwszego poziomu w przedstawionym przykadzie), ale nie okrela, w jaki sposb przegldarka powinna sformatowa wywietlany dokument.
Pomijamy du cz strony wywoawczej nastpujc po przywitaniu Welcom e", a do punktu, w ktrym znajduj si linie:
< D D X I M G A L I G N = b o t t o m SRC="bal l_whi .gi f ALT=" > I n f o r m a t i o n Re so u rc e <A HREF = "h t t p : / / w w w . n c s a . u i u c . e d u / S D G / S o f t w a r e / M o s a i c / M e t a I n d e x . h t m l ' ' > Meta-Index</A>
<DD> oznacza kolejn pozycj listy. Pozycja ta rozpoczyna si obrazem graficz nym (biaa kula - zuhite bali), po ktrym nastpuje tekst Information Resource Meta-Index". Ostatnie sowo tekstu jest wskanikiem do linku hipertekstu (znacz nik <A> ) z odnonikiem zaczynajcym si od tekstu h t t p : / / w w w . n c s a . u i u c . e d u . Takie linki hipertekstu s zwykle przedstawiane przez przegldark jako tekst podkrelony lub wywietlane s w innym kolorze. Tak jak w przypadku obrazu graficznego, ktry napotkalimy wczeniej (logo korporacji), serwer nie wysya
Sekcja 13.3
Protok HTTP
173
obrazu lub dokumentu HTML, wskazywanego przez link hipertekstu. Klient zwy kle cignie grafik natychmiast (by j wywietli na stronie wywoawczej), ale nie zrobi nic z linkiem hipertekstu, chyba e uytkownik wybierze ten link (to znaczy przesunie wskanik graficzny na ekranie i wcinie przycisk myszy). Gdy link zostanie wybrany przez uytkownika, klient otworzy poczenie HTTP do hosta w w w.ncsa.uiuc.edui wykona GET dla wyszczeglnionego dokumentu.
h t t p : / / w w w . n c s a .u i u c . e d u / S D G / Softw are/Mo saic/ MetaIndex.html jest przyka dem tzw. URL jednolitego lokalizatorci zasobw - ( Uniform Resource Locator). Okrele nie i znaczenie URL zostay podane w RFC 1738 [Berners-Lee, Masinter i McCahill 1994]. URL jest czci wikszego schematu zwanego URI-jednolitego identyfikato ra zasobio ( Uniform Resource Identifiers), w skad ktrego wchodz rwnie obiekty zwane URN ( Universal Resource Names) - uniioersalne nazwy zasobw. URI zostay przedstawione w RFC 1630 [Berners-Lee 1994]. URN powinny by bardziej nieza wodne ni URL, obiekty te nie s jednak jeszcze zdefiniowane.
Wikszo przegldarek W W W oferuje rwnie moliwo obejrzenia kodu rdowego strony W W W . Na przykad, Netscape i Mosaic udostpniaj funkcj View Source".
13.3
Protok HTTP
Polecenie GET / uyte przez klienta w przykadzie z poprzedniego podrozdziau jest poleceniem HTTP w wersji 0.9. Wikszo serwerw akceptuje polecenia tej wersji (dla kompatybilnoci wstecz), jednak aktualn wersj jest 1.0 (w roku 1995, gdy ksika bya pisana - przyp. tum.). Serwer zauway rnic pomidzy w er sjami, poniewa poczynajc od wersji 1.0 klient podaje numer wersji jako cz linii dania, na przykad:
GET / HTTP/1.0
W obecnym podrozdziale przyjrzymy si dokadniej protokoowi H TTP/1.0.
Rodzaje komunikatw: dania i odpowiedzi

Istniej dwa rodzaje komunikatw w H TTP/1.0: dania i odpowiedzi. Format dania H TTP/1.0 jest nastpujcy: linia-danie nagwki (0 lub wicej) <linia pusta> korpus (tylko dla dania POST) Format linii-dania jest natomiast taki: danie danie-URI wersja-HTTP Dostpne s trzy rne dania. 1. danie GET, ktre zwraca dowoln informacj okrelon przez danie-URI. 2. danie HEAD jest podobne do dania GET, serwer zwraca jednak nagwek, a nie zawarto (korpus) danego dokumentu. Ta forma dania jest czsto
174
Rozdzia 13
stosowana do sprawdzenia linku hipertekstu pod ktem aktualnoci, dost pnoci, czy wprowadzonych ostatnio modyfikacji.
3. danie POST uywane jest do nadawania poczty elektronicznej, wysyania
informacji sieciowych lub wysyania formularzy, ktre mog zosta interakcyj nie wypenione przez uytkownika. Jest to jedyna forma dania, wraz z ktra wysyany jest korpus komunikatu. Dugo korpusu musi by poprawnie okre lona w polu nagwka Co n t e n t - Length (opisujemy to pole poniej). W prbce 500 000 da klientw odebranych przez silnie aktywnego serwera W W W , 99,68% da byy to dania G ET, 0,25% stanowiy dania H E AD, a pozo stae 0,07% to dania POST. Inaczej by to prawdopodobnie wygldao w przypad ku serwera umoliwiajcego interakcyjne zamwienie pizzy. Format odpowiedzi w H T T P/1.0 jest nastpujcy:
linia-stanu nagiuki (0 lub wicej) <pusa linia> korpus
Format linii-stanu (status-lme) jest taki:

iversja-HTTP kod-odpowiedzi fraza-odpowiedzi
Niej omwimy pokrtce poszczeglne elementy odpowiedzi.
Pola nagwkw
W H TTP/1.0 tak danie jak i odpowiedz mog zawiera dowoln liczb pl nagw kowych. Pola nagwkw od korpusu oddziela pusta linia. Pole nagwka skada si z nazwy pola (rysunek 13.3), po ktrej umieszczony jest dwukropek, nastpnie jedna spacja i warto pola. Due i mae litery nie s rozrniane w nazwie pola. Mona wyrni trzy rodzaje nagwkw: uywane z daniami, uywane z od powiedziami i okrelajce korpus. Niektre nagwki s uywane zarwno z daniami, jak i z odpowiedziami (na przykad Da te ). Nagwki okrelajce korpus mog pojawi si w daniach POST i w dowolnych odpowiedziach. Rysunek 13.3 pokazuje 17 rnych nagwkw opisanych w opracowaniu [Bemers-Lee, Fiel ding i Nielsen 1995]. Nieznane pola nagwka powinny zosta zignorowane przez odbierajcego hosta. Przyjrzymy si pniej niektrym czsto spotykanym na gwkom, ale najpierw przedyskutujemy kody odpowiedzi.
Kody odpowiedzi
Pierwsza linia odpowiedzi serwera zwana jest lini stanu. Na pocztku tej linii znajduje si okrelenie wersji HTTP, nastpnie podana jest trzycyfrowa liczba okrelajca kod odpowiedzi, a na kocu czytelne dla uytkownika wyraenie (fraza odpowiedzi). Znaczenie trzycyfrowych kodw odpowiedzi zostao przed stawione na rysunku 13.4. Pierwsza z trzech cyfr przypisuje kod do jednej z trzech oglnych kategorii.
Sekcja 13.3
Protok HTTP
175
Uycie trzycyfrowego kodu odpowiedzi nie jest przypadkowe. Zobaczym y pniej, e NNTP rwnie uywa kodw odpowiedzi tego rodzaju (rysunek 15.2), podobnie jak inne aplikacje internetowe, na przykad FTP i SMTP.
Nagwek A l 1 ow A u t h o r i z a t i on C o n t e n t - E n c o d i ng C o n te n t-L e n g th C o n te n t-T y p e D a te E xp i re s Fro m If - M o d if ie d - S in c e L a s t - M o d i f i ed L o c a t i on M IM E - V e r s i on P ra g m a R e fe re r S e rv e r U se r-A g e n t W W W -A u th e n ti c a t e danie? Odpowied? Korpus?
Rysunek 13.3 Nazwy nagwkw HTTP

Kod odpowiedzi Opis Informacja. Aktualnie nie uywany Sukces. 200 201 202 204 OK, danie przetworzone pomylnie. OK, utworzone zostay nowe zasoby (polecenie P O S T ) danie zaakceptowane, ale przetwarzanie nie zakoczone. OK, ale brak tekstu do przestania. Przeadresowanie; dalsze czynnoci konieczne po stronie uytkownika. dany zasb otrzyma na stae nowy URL. dany zasb chwilowo jest dostpny pod innym URL. Dokument nie by zmodyfikowany (warunkowe GET) Bd klienta Ze danie. Brak autoryzacji; danie wymaga sprawdzenia tosamoci uytkownika. Zabronione z nieokrelonego powodu. Nie znaleziono. Bd serwera. Wewntrzny bd serwera. Nie zaimplementowane. Zy gateway. Za odpowied od gatewaya lub poredniczcego serwera. Usuga chwilowo nie dostpna.
1yz
301 302 304
400 401 403 404
500 501 502 503
Rysunek 13.4 Trzycyfrowe kody odpowiedzi HTTP
176
Rozdzia 13
Przykady rnych nagwkw

Jeeli przy uyciu H TT P/1.0 cigniemy obrazek logo (wymieniony na stronie odwoawczej w poprzednim podrozdziale) otrzymamy nastpujcy dialog mi dzy serwerem i klientem:
sun % t e l n e t w w w . a w . c o m 80 T r y i n g 19 2 . 2 0 7 . 1 1 7 . 2 . . . C o n n e c t e d to aw.co m. E s c a p e c h a r a c t e r is 'A ] . GET /awplogob.gif HTTP/1.0 From: r s t e v e n s @ n o a o . e d u
H T T P / 1 . 0 200 OK Date: S a t ur d ay . 1 9- A u g - 9 5 2 0 : 2 3 : 5 2 GMT S erver: N C S A / l . 3 M I M E - v e r s i o n : 1.0 Content-type: image/gif L a s t - m o d i f i e d : Monday. 1 3 - M a r -95 01 :4 7: 5 1 GMT C o n t e n t - l e n g t h : 2859
wpisujemy t Uni i t lini nastpnie wpisujemy pust lini, by zakoczy danie pierwsza linia odpowiedzi serwera
puste linie kocz nagwki odpowiedzi serwera

C o n n e c t i o n cl os ed by f o r e i g n host. - 2589-bajtowy plik GIF zostaje przesany wydruk klienta Telnetu
Zaznaczamy numer wersji w daniu GET. Wysyamy pojedynczy nagwek From, ktry moe zosta zarejestrowany (za pisany w log file") Linia stanu serwera wymienia numer wersji, kod odpowiedzi 200 i fraz odpo wiedzi OK". Nagwek Date zawiera czas i dat wedug serwera, podane zawsze w czasie uniwersalnym (GMT). Serwer z naszego przykadu wysya dat w przestarza ym formacie. Zalecanym formatem jest:
Date: Sat, 19 Aug 199 5 2 0: 23 : 5 2 GMT
z nazw dnia tygodnia w formie skrconej, bez mylnika w dacie i rokiem wyraonym jako liczba czterocyfrowa. Serwer podaje typ i wersj uywanego programu: serwer NCSA wersja 1.3. Uywany jest format MIME w wersji 1.0. Informacje na temat MIME mona znale w rozdziale 28.4 tomu 1 oraz w pracy [Rose 1993]. Typ danych zawartych w korpusie jest okrelony przez pola Content-Type i Content-Encoding. Pierwsze z tych pl przedstawione jest jako typ, po ktrym nastpuje ukonik, a nastpnie podtyp. W naszym przykadzie typem jest i mage, a podtypem gi f . HTTP uywa typw danych internetowych wyszczeglnio nych w ostatnim opracowaniu Assigned Numbers RFC (wersja aktualna w czasie, gdy powstawaa ta ksika: [Reynolds and Postel 1994]). Innymi typowymi wartociami s:
Content-Type: Content-Type: Content-Type: text/html text/plain appli cati o n / p o s t s c r i p t
Jeli korpus jest zakodowany, pojawia si rwnie nagwek Content-Encodi ng. Na przykad dla pliku PostScript skompresowanego za pomoc unixo-
Sekcja 13,3
Protok HTTP
177
wego programu compress (zwykle plik taki ma nazw z rozszerzeniem . ps . Z) pojawiyby si nastpujce dwa nagwki.
C o n t e n t - T y p e : appli c a t i o n / p o s t s c r i pt Content-Encoding: x-compress
Last-Modi fied okrela czas ostatniej modyfikacji ciganego pliku. Wielko pliku graficznego (2859 bajtw) podana jest w nagwku Cont ent Length. Po ostatnim nagwku serwer wysya pust lini (znaki C R /L F) i bezporednio po tym plik graficzny. Przesyanie danych binarnych przez poczenie TCP jest dopu szczalne, poniewa HTTP uywa omiobitowych bajtw. Inaczej wyglda to w przypadku niektrych innych aplikacji internetowych. W szczeglnoci proto k SMTP (rozdzia 28, tom 1) przesya 7-bitowe znaki ASCII przez poczenie TCP, jawnie ustawiajc warto najbardziej znaczcego bitu na 0 i uniemoliwiajc tym samym wymian danych binarnych. Czsto spotykanym nagwkiem klienta jest User-Agent identyfikujcy program klienta. Typowymi przykadami s:
Us e r- A g e n t : M o z i l l a / l . l N (Windows; I; 16bit) U s e r - A g e n t : N CS A M o s a i c / 2 . 6 b l (X I 1 ; Sun OS 5.4 sun4m) libwww/2.12 modified
Przykad: pami podrczna klienta

Wiele programw dziaajcych jako klient przechowuje dokumenty HTTP w pod rcznej pamici na dysku wraz z czasem i dat, kiedy te dokumenty zostay cignite. Jeeli cigany aktualnie dokument znajduje si w pamici podrcznej klienta, moe zosta wysany przez klienta nagwek I f -Modi f i ed - Si nce i to pozwala unikn wysyania przez serwera drugiej kopii tego samego dokumentu -jeli dokument nie zosta zmieniony. Jest to tak zwane warunkowe danie GET.
sun 1 t e l n e t w w w . a w . c o m 80 Tryi ng 1 9 2 . 2 0 7 . 1 1 7 . 2 . . . C o n n e c t e d to aw.com. E s c a p e c h a r a c t e r is A ]'. GET /awplogob.gif HTTP/1.0 I f - M o d i f i e d - S i n c e : Sat ur da y, 0 8 - A u g - 9 5 2 0 : 2 0 : 1 4 GMT H T T P / 1 . 0 304 Not m o d i f i e d Date: Satu rd ay , 1 9 - A u g - 9 5 2 0 : 2 5 : 2 6 GMT Server: N C S A / l . 3 M I M E - v e r s i o n : 1.0 C o n n e c t i o n c lo s ed by f o re ig n host.
pusta linia koczy danie klienta
pusta linia koczy nagwki odpowiedzi serwera
Tym razem kod odpowiedzi jest 304, co oznacza, e dokument nie by zmodyfiko wany. Z punktu widzenia protokou TCP, umoliwia to uniknicie przesyania od serwera do klienta korpusu dokumentu, czyli w tym przykadzie 2859 bajtw pliku w formacie GIF. W dalszym cigu musz by przesane segmenty potrjnego uzgodnienia oraz cztery pakiety koczce poczenie, czyli musz by wykonane typowe czynnoci administracyjne protokou TCP.
178
Rozdzia 13
Przykad: przeadresowanie wykonane przez serwera

Nastpny przykad pokazuje przeadresowanie wykonane przez serwera. Prbuje m y cign stron wywoawcz autora, ale celowo opuszczamy kocowy uko nik (jest on wymagan czci URL okrelajcego katalog).
sun % t e l n e t w w w . n o a o . e d u 80 Trying 140.252.1.11... C o n n e c t e d to g e m i n i . t u c . n o a o . e d u E sc a p e c h a r a c t e r is A] .
GET / ~ r s t e v e n s H T T P / 1 .0
pusta linia koczy danie klienta H T T P / 1 . 0 302 Found Date: Wed. 18 O ct 1995 1 6 :3 7 : 2 3 GMT Server: N C S A / 1.4 Loca ti o n: h t t p : / / w w w . n o a o , e d u / ~ r s t e v e n s / C o n t e n t - t y p e : text/html pusta linia koczy nagwki odpowiedzi serwera <HEADXTITLE>Document moved</TITLEX/HEAD> D o c u m e n t moved</Hl> T hi s d o c u m e n t has m o v e d < A H R E F = " h t t p : / / w w w . n o a o . e d u / ~ r s t e v e n s / >here</A>. </B0DY>
Kod odpowiedzi jest 302, co oznacza, e dany dokument zmieni swoj lokaliza cj. Nagwek Loc at i o n okrela nowy adres, zawierajcy tym razem kocowy ukonik. Wikszo przegldarek automatycznie ciga dokument wskazywany przez nowy URL. Serwer wysya rwnie plik HTML, ktry moe by wywietlo ny przez przegldark, jeeli przegldarka nie chce automatycznie ciga nowe go URL.
13.4
Przykad
Przeanalizujemy teraz szczegowo jeden przykad uywajc popularnej przegl darki W W W (Netscape 1.1N) i zwrcimy szczeglnie uwag na sposb wykorzy stania HTTP i TCP. Zaczniemy od strony wywoawczej wydawnictwa Addison-Wesley ( h t t p : / / w w w . a w . com) i uyjemy trzech linkw umieszczonych na tej stronie (wszystkie do w w w .a w .com) dochodzc do strony zawierajcej opis tomu 1. Nawi zywanych jest 17 pocze TCP, 3132 bajty przesyane s od klienta do serwera, a serwer zwraca ogem 47 483 bajty. Spord 17 pocze, cztery su do przesa nia dokumentw HTML (28 159 bajtw), a w 13 poczeniach przesyane s pliki graficzne GIF (19 324 bajty). Pami podrczna na dysku klienta uywana przez program Netscape zostaa wczeniej wyczyszczona, zmuszajc klienta do ciga nia od serwera wszystkich plikw. Wszystkie segmenty - wysyane lub odbierane - byy rejestrowane przy pomocy programu Tcpdump uruchomionego w kompu terze klienta. Tak jak si spodziewamy, pierwsze poczenie TCP suy do przesania strony wywoawczej (GET /), ktra zawiera odnoniki do siedmiu plikw graficznych GIF. Gdy tylko klient otrzyma t stron, cztery poczenia TCP zostan rwnolegle otwarte dla pierwszych czterech plikw graficznych. Jest to waciwo klienta Netscape, ktra pozwala zredukowa cakowity czas transmisji. (Wikszo klien-
Sekcja 13.4
Przykad
179
tw W W W nie jest a tak agresywnych i ciga pliki pojedynczo.) Liczba symul tanicznych pocze moe by zmieniona przez uytkownika - domylnie liczba ta okrelana jest na 4. Gdy tylko ktre z tych pocze zostaje zamknite, otwiera ne jest natychmiast nowe poczenie - by cign kolejny plik GIF. Procedura ta jest kontynuowana a do momentu, gdy wszystkie siedem obrazw graficznych zostaje cignitych. Na rysunku 13.5 pokazujemy diagram czasowy dla tych 8 pocze TCP.
Rysunek 13.5 Diagram czasowy dla 8 pocze TCP uytych do cignicia strony wywoawczej i siedmiu plikw GIF Wszystkich 8 pocze jest zainicjowancych przez klienta i uywaj one kolejnych numerw portw - od 1114 do 1121. Wszystkie te poczenia zostaj zamknite przez serwera. Przyjmujemy, e poczenie zaczyna si, gdy klient wysya poczt kowy segment SYN (connect klienta) i koczy si, gdy klient - po otrzymaniu segmentu FIN od serwera - wysya swj segment FIN (cl ose klienta). Potrzeba okoo 12 sekund, by cign stron wywoawcz i wszystkie 7 plikw graficznych wymienionych na tej stronie.
180
Rozdzia 13
W nastpnym rozdziale, na rysunku 14.22, przeledzimy wymian pakietw odpowiadajc pierwszemu poczeniu zainicjowanemu iprzez klienta (port 1114).
Zauwam y, e poczenia uywajce portw 1115, 1116 i 1117 rozpoczynaj si zanim pierwsze poczenie (port 1114) si skoczy . Dzieje si tak, bo klient Netscape iniq'uje te trzy nieblokujce poczenia po tym, gdy odbierze znak koca pliku w pierwszym poczeniu, ale przed zamkniciem tego poczenia. Rzeczywicie, na rysunku 14.22 zauw aam y opnienie nieco ponad p sekundy pomidzy otrzymaniem FIN, a wysa niem FIN przez klienta.
Czy symultaniczne poczenia s korzystne dla klienta, czyli czy ta technika zmniejsza czas transakcji dla interakcyjnego uytkownika? eby to sprawdzi, uyty zosta klient Netscape z hosta sun (rysunek 1.13) do cignicia strony wywoawczej Addison-Wesley. Ten host poczony zosta z Internetem przez modem i poczenie telefoniczne o szybkoci 28 800 bitw na sekund, co jest dzi typowe dla WWW. Liczba pocze uywanych przez klienta moe zosta zmie niona w pliku preferencji uytkownika i prbowano uy wartoci od 1 do 7. Pami podrczna na dysku bya wyczona. Klient wykonywa swoje funkcje trzy razy dla kadej wartoci i otrzymane wyniki zostay urednione.
Liczba jednoczesnych pocze w sekundach 1 2 3 4 5 6 7 Cakowity czas
14,5 11,4 10,5 10,2 10,2 10,2 10,2
Rysunek 13.6 Cakowity czas operacji zmierzony dla klienta WWW przy rnych liczbach jednoczesnych pocze Dodatkowe poczenia, a do czterech rwnoczesnych, rzeczywicie zmniejszaj cakowity czas operacji. Kiedy jednak wymiana pakietw zostaa przeanalizowa na przy pomocy Tcpdump, okazao si, e cho uytkownik mg zezwoli na wicej ni 4 poczenia, program w rzeczywistoci i tak ogranicza ich liczb do 4. Bez wzgldu na to, biorc pod uwag rnice czasw pomidzy uyciem 1 , 2 , 3 i 4 pocze, mona sdzi, e zwikszenie liczby pocze ponad 4 daoby niewielki, jeli w ogle jakikolwiek, efekt.
Cakowity czas transakcji z rysunku 13.5 jest o 2 sekundy wikszy od najkrtszego czasu (10.2) pokazanego na rysunku 13.6. Przyczyna pojawienia si tych dodatkowych 2 sekund zwizana jest z rnicami sprztowym i (wywietlanie) pomidzy dw om a klientami. Przykad z rysunku 13.6 by wykonany na stacji roboczej, podczas gdy przykad, ktrego dotyczy rysunek 13.5, wykonywany by na wolniejszym komputerze PC z wolniejsz kart graficzn.
Sekcja 13.5
Dane statystyczne H TTP
181
W opracowaniu [Padmanabhan 1995] zauwaono dwa problemy zwizane z sy multanicznymi poczeniami. Po pierwsze, takie zachowanie moe by uciliwe dla innych protokow, takich jak FTP, ktre uywaj zawsze jednego poczenia (pomijajc poczenie kontrolne). Po drugie, jeeli jedno z symultanicznych po cze natyka si na przecienie i postpuje zgodnie z algorytmem unikania prze cienia (congestion avoidance) informacja algorytmu unikania przecienia (opisa ny w rozdziale 21.6 w tomie 2), nie jest przekazywana do innych pocze.
W praktyce jednak symultaniczne poczenia z jednym hostem prawdopodobnie uyw a j tej samej marszruty. Jeli jedno poczenie zaczyna traci pakiety na skutek przecie nia, jest wysoce prawdopodobne, e inne poczenia spotkaj si z tym sam ym efektem.
Innym problemem zwizanym z wykorzystywaniem rwnoczesnych pocze jest to, e w przypadku uycia takich pocze prawdopodobiestwo przepenie nia niekompletnej kolejki poczenia serwera jest wiksze, co moe prowadzi do duych opnie, gdy klient musi przesya ponownie swoje segmenty SYN. W rozdziale 14.5 omwimy w szczegach to zagadnienie zwizane z umieszcza niem danych w kolejkach pocze - w odniesieniu do serwerw WWW.
13.5
Dane statystyczne HTTP
W nastpnym rozdziale przyjrzymy si dokadniej niektrym waciwociom ze stawu protokow TC P/IP i przeanalizujemy sposb uycia tych protokow (rwnie niewaciwego) w silnie obcionym serwerze HTTP. W obecnym pod rozdziale pragniemy sprawdzi jak wyglda typowe poczenie HTTP. Bdziemy uywa opisanego w nastpnym rozdziale zestawu danych zebranych w cigu 24 godzin przez program Tcpdump. Na rysunku 13.7 zebralimy dane statystyczne uzyskane dla okoo 130 000 od dzielnych pocze HTTP. W przypadkach gdy klient zakoczy poczenie w sposb nienormalny, na przykad przerywajc poczenie telefoniczne, moemy nie by w stanie okreli z wydruku Tcpdump wartoci jednego lub obu licznikw bajtw. redni czas poczenia rwnie moe by zafaszowany w stron wi kszych wartoci, z powodu pocze, ktre serwer zamkn po wyczerpaniu si czasu oczekiwania.
Mediana klienci bajty/poczenie seiwer bajty/poczenie czas trwania poczenia (sekundy) 224 3093 3,4 Warto rednia 226 7900 22,3
Rysunek 13.7 Statystyka oddzielnych pocze HTTP Wikszo opracowa dotyczcych statystyki pocze HTTP podaje zarwno warto najczciej spotykan (median), jak i warto redni, poniewa mediana jest parametrem w wielu przypadkach lepiej okrelajcym normalne" poczenia.
182
Rozdzia 13
rednia czsto ma warto wysz, co spowodowane jest przez niewielk liczb bardzo dugich plikw. W opracowaniu [Mogul 1995b] przeanalizowano 200 000 pocze HTTP i stwierdzono, e liczba bajtw danych zwracanych przez serwera miaa median rwn 1770 bajtw i warto redni 12 925 bajtw. Inny pomiar (rwnie [Mogul 1995b]), w ktrym uwzgldniono niemal 1,5 miliona pocze z innym serwerem, przynis median 958 bajtw i warto redni 2394 bajty. Dla serwera NCSA zmierzono median [Braun i Claffy 1994] rwn okoo 3000 bajtw i redni okoo 17 000 bajtw. Oczywistym wnioskiem jest, e wielko odpowie dzi serwera zaley od rodzaju plikw udostpnianych przez tego serwera i moe zmienia si w bardzo szerokich granicach dla rnych serwerw. Liczby dyskutowane do tej pory w tym podrozdziale dotyczyy pojedynczych pocze HTTP uywajcych TCP. Najczciej uytkownicy przegldarki WW W cigaj wiele plikw z danego serwera w trakcie tzw. sesji HTTP. Pomiar wielko ci charakteryzujcych sesj jest trudniejszy, poniewa jedyna informacja dotycz ca klienta dostpna w serwerze to numer IP klienta. Moliwa jest sytuacja, w ktrej kilku uytkownikw tego samego klienta czy si jednoczenie z tym samym serwerem. Co wicej, wiele instytucji kieruje wszystkie dania klientw HTTP przez kilka hostw-serwerw, co powoduje, e wielu uytkownikw uywa po zornie jednego adresu IP (czsto jest to zwizane z istnieniem sieciowych cian ogniowych). (Serwery takie zwane s czsto senuemmi proxy). Mimo tych trudnoci wykonano [Kwan, McGrath i Reed 1995] prby scharakteryzowania sesji dla ser wera NCSA, definiujc sesj jako zestaw pocze odbywajcych si w czasie najwyej 30 minut. W cigu takich 30-minutowych sesji kady klient wysa red nio 6 da HTTP, powodujc przesanie przez serwera 95 000 bajtw. Wszystkie wielkoci statystyczne wymieniane w tym podrozdziale byy mierzone po stronie serwera. Naley zaznaczy, i na wszystkie te wielkoci m a wpyw rodzaj dokumentw HTTP udostpnianych przez danego serwera. W arto red nia liczby bajtw wysyanych przez serwera udostpniajcego na przykad due mapy pogody, bdzie znacznie wysza ni analogiczna wielko dla serwera wysyajcego gwnie informacje tekstowe. Lepsze dane statystyczne dotyczce W W W mona by otrzyma ledzc dania wielu rnych klientw wysyane do wielu rnych serwerw. Tego typu pomiary zostay przedstawione w opracowa niu [Cunha, Bestavros i Crovella 1995]. Przeanalizowano tam 4700 sesji HTTP, zainicjowanych przez 591 uytkownikw, w ramach ktrych przesano ogem 575 772 pliki. Otrzymano redni wielko pliku rwn 11 500 bajtw. Autorzy podaj rwnie rednie wielkoci dokumentw okrelonego typu (HTML, grafika, dwik, video, text, itd.). Podobnie jak w innych pomiarach, stwierdzono, e rozkad wielkoci plikw ma dugi ogon odpowiadajcy duym plikom, co pow o duje przesunicie wartoci redniej. Stwierdzono rwnie, e najczciej przesya ne s pliki mae.
Sekcja 13.6_________ Problemy zwizane z szybkoci i sprawnoci dziaania
183
13.6
Problemy zwizane z szybkoci i sprawnoci dziaania
Biorc pod uwag duy wzrost uycia HTTP (rysunek 13.1), wpyw tego protoko u na funkcjonowanie Internetu jest wyjtkowo interesujcy. Oglne wykresy natenia ruchu dla serwera NCSA mona znale w pracy [Kwan, McGrath i Reed 1995]. Wykresy te sporzdzone zostay na podstawie plikw rejestrujcych (log files) otrzymanych dla rnych tygodni w cigu piciu miesicy 1994 roku. Zauwaono na przykad, e 58% da pochodzi z komputerw osobistych, a licz ba da ronie o 11-14% miesicznie. Przedstawione s rwnie dane statystycz ne liczby da w zalenoci od dnia tygodnia, rednie dugoci pocze, itd. Inn analiz pracy serwera NCSA znajdziemy w pracy [Braun i Claffy 1994]. Przedstawiono tam rwnie, jakie zyski w szybkoci i sprawnoci dziaania serwe ra mona osign, gdy serwer HTTP dokumenty najczciej wymieniane w od nonikach przechowuje w podrcznej pamici na dysku. Najistotniejszym czynnikiem wpywajcym na czas odpowiedzi serwera mierzo ny przez interaktywnego uytkownika jest sposb uycia pocze TCP przez HTTP. Jak widzielimy, dla kadego dokumentu uywane jest jedno oddzielne poczenie. To zagadnienie opisane jest w opracowaniu [Spero 1994a], zaczynaj cym si od sw H TTP/1.0 le wsppracuje z TCP." Innymi istotnymi czynnika mi s czas RTT pomidzy klientem i serwerem oraz obcienie serwera. We wspomnianym opracowaniu ([Spero 1994a]) zauwaa si rwnie, e kade poczenie rozpoczyna si w trybie powolnym (slow start, opisny w rozdziale 20.6 w tomie 1), co dodatkowo zwiksza opnienie. Wpyw powolnego trybu rozpo czynania poczenia zaley od rozmiaru dania klienta i wartoci MSS ogoszonej przez serwera (zwykle 512 lub 536 dla pocze nawizywanych przez Internet). Przy wartoci MSS 512 bajtw, jeeli danie klienta nie jest dusze ni 512 bajtw, powolny tryb rozpoczynania poczenia nie ma znaczenia. (Naley jednak pamita o czsto spotykanej w implementacjach wywodzcych si z systemu Berkeley zalenoci od buforw mbuf - opisujemy j w rozdziale 14.11 - ktra moe spowodowa start w trybie powolnym.) W przypadku gdy danie klienta jest wiksze ni MSS, powolny tryb nawizywania poczenia zwiksza opnienie o dodatkowe wartoci RTT. Rozmiar dania klienta zaley od progra mu przegldarki. Klient Xmosaic we wspomnianym opracowaniu ([Spero 1994a]) wygenerowa 1130-bajtowe danie, ktre byo przesane w trzech segmentach TCP. (danie to zawierao 42 linie, z ktrych 41 byo nagwkami Accept.) W przykadzie z rozdziau 13.4 klient Netscape 1.1N utworzy 17 da o rozmia rze od 150 do 197 bajtw, tryb powolnego startu nie by wic uywany. Mediana i warto rednia rozmiaru dania klienta na rysunku 13.7 pokazuj, e wi kszo da odbieranych przez tego serwera nie powoduje powolnego startu, natomiast taki powolny start powoduje wikszo odpowiedzi wysyanych przez serwera.
Przed chwil wspomnielimy, e klient Mosaic wysya wiele nagwkw Accept, ale nagwek ten nie jest wymieniony na rysunku 13.3 (poniewa nie pojawia si on w opra cowaniu [Beme-Lee, Fielding i Nielsen 1995]). Nagwek Accept zosta pominity w tym
184
H T T P - protok przesyania hipertekstu
Rozdzia 13
szkicu internetowym ze wzgldu na to, i tylko nieliczne serwery robi cokolwiek z tym nagwkiem. Przy jego pom ocy klient informuje serwera, jakie form aty danych klient bdzie akceptowa (grafiki GIF, pliki PostScript, itd.). Niewiele jest jednak serwerw, ktre przechowuj kopie tego samego dokumentu w rnych formatach, i nie m a zwykle moliwoci uzgodnienia formatu danych przez klienta i serwera.
Istotne jest te, e poczenie zostaje zwykle zamknite przez serwera HTTP, co powoduje wprowadzenie poczenia w stan oczekiwania TIME_WAIT po stronie serwera. Wynikiem tej sytuacji moe by obecno w silnie zajtym serwerze duej liczby blokw kontrolnych pocze w tym stanie. Zaproponowano [Padmanabhan 1995] i [Mogul 1995b], by serwer nie zamyka poczenia TCP po wysaniu odpowiedzi i by takie poczenie midzy klientem i serwerem byo zachowywane. Jest to moliwe, gdy serwer zna rozmiar swojej odpowiedzi (przypominamy nagwek C o n t e n t - L e n g t h z naszego wczeniejsze go przykadu ze strony 177, w ktrym podany zosta rozmiar grafiki GIF). W prze ciwnym przypadku serwer musi zamkn poczenie, by poinformowa klienta o kocu poczenia. Taka modyfikacja protokou wymaga wprowadzenia zmian zarwno w oprogramowaniu serwera, jak i klienta. By zapewni kompatybilno wstecz, klient generuje nagwek P r a g m a : h old-c onnect ion. Nagwek ten po zwala nowym klientom komunikujcym si z nowymi serwerami zachowa po czenie, kiedy tylko jest to moliwe, i jednoczenie umoliwia wspprac w szy stkich istniejcych serwerw i klientw. Serwer, ktry nie rozumie takiego na gwka Pragma:, ignoruje go i zamyka poczenie po przesaniu dokumentu.
Trwae poczenia zostan prawdopodobnie uwzgldnione w nastpnej wersji HTTP, cho szczegy implementacji m og by inne ni przedstawiono powyej. Serwer moe w is tocie uy trzech rnych sposobw, by poinformowa klienta o zakocze niu odpowiedzi. Pierwszym zalecanym sposobem jest uycie nagwka C o n t e n t - l e n g t h . Kolejn moliwoci jest wysanie nagwka C o n t e n t - T y p e z atrybutem boundary=. (Przykad uycia tego atrybutu mona znale w rozdziale 6.1.1 pracy [Rose 1993], Nie wszystkie implementaq'e klienta uwzgldniaj ten atrybut.) Najgorszym sposobem, cho najczciej uywanym, jest zamknicie poczenia przez serwera.
Padmanabhan i Mogul proponuj rwnie wprowadzenie dwch nowych da klienta umoliwiajcych czenie kilku odpowiedzi serwera w jedn: G ETA L L (ser wer wysya w jednej odpowiedzi dokument HTML oraz wszystkie wbudowane inline - grafiki) oraz GET LI ST (odpowiada wysaniu przez klienta serii da GET). danie G ETA L L byoby uywane, jeli klient nie przechowuje w pamici podrcz nej adnych plikw pochodzcych od tego serwera. Idea zwizana z drugim nowym daniem jest taka, by klient najpierw wykonywa GET dla dokumentu HTML, a nastpnie uywa GET LI ST do cignicia wszystkich wymienianych w tym dokumencie plikw, o ile nie znajduj si one w pamici podrcznej. Podstawowym problemem zwizanym z HTTP jest niedopasowanie protokou TCP - zorientowanego na przesyanie strumienia bajtw, i usugi HTTP - zorien towanej na przesyanie komunikatw. Idealnym rozwizaniem jest protok w ar stwy sesji oparty na TCP, tworzcy interfejs pomidzy klientem i serwerem HTTP, nastawiony na przesyanie komunikatw w ramach jednego poczenia TCP.
Sekcja 13.7
Podsumowanie
185
W opracowaniu [Spero 1994b] omawiane jest takie podejcie. Zaproponowany protok, nazwany HTTP-NG, uywa jednego poczenia TCP, podzielonego na tzw. sesje. W ramach jednej sesji przesyane s informacje kontrolne - dania klienta i kody odpowiedzi serwera, a w innej sesji serwer przesya dane pliki. W ramach poczenia TCP przesyany jest 8-bajtowy nagwek (zawierajcy kilka bitw flag, identyfikator sesji oraz dugo nastpujcych po nagwku danych) oraz dane odpowiadajce danej sesji.
13.7
Podsumowanie
Protok HTTP jest prosty. Klient nawizuje poczenie TCP z serwerem, wysya danie i czyta odpowied serwera. Serwer zaznacza koniec odpowiedzi, zamyka jc poczenie. Plik przesany przez serwera zawiera zwykle wskaniki (linki hipertekstu) do innych plikw, umieszczonych by moe w innych serwerach. Prostota protokou z punktu widzenia uytkownika polega na oczywistej atwoci ledzenia takich linkw od serwera do serwera. dania klienta maj form zwykych linii ASCII, a odpowiedzi serwera skadaj si z linii ASCII (nagwki), po ktrych nastpuj dane (binarne lub ASCII). Opro gramowanie klienta (przegldarka) analizuje odpowied serwera, formatuje otrzymane informacje i zaznacza linki do innych dokumentw. Ilo danych przesyanych w poczeniu HTTP jest maa. dania klienta zawiera j zwykle po kilkaset bajtw, a odpowiedzi serwera typowo od kilkuset do 10 000 bajtw. Poniewa niewielka liczba duych plikw moe w istotny sposb zmieni warto redni rozmiaru plikw, opracowania statystyczne dotyczce HTTP po daj zwykle median rozkadu dugoci odpowiedzi serwera. Wiele rnych ana liz pokazuje, e mediana ta ma warto mniejsz ni 3000 bajtw. Najwikszym problemem rzutujcym na wydajno uycia HTTP jest fakt, e protok ten uywa oddzielnego poczenia TCP dla kadego przesyanego pliku. W przykadzie, ktry przedstawilimy w rozdziale 13.4, cignicie jednej strony wywoawczej spowodowao, e klient utworzy 8 pocze TCP. Jeeli danie klienta jest wiksze ni warto MSS zgoszona przez serwera, to powolny tryb nawizywania poczenia powoduje dodatkowe opnienie w kadym pocze niu TCP. Innym problemem jest to, e zamknicie poczenia przez serwera powo duje pojawienie si po stronie serwera stanu TIME_WAIT zwizanego z tym poczeniem i e aktywny serwer moe skumulowa bardzo wiele takich zaka czanych pocze. Mona przeprowadzi pewne historyczne porwnanie. Protok Gopher powsta mniej wicej w tym samym czasie co HTTP. Protok Gopher jest opisany w RFC 1436 [Anklesaria i in. 1993]. Biorc pod uwag dziaanie sieci, HTTP i Gopher s do podobne. Klient otwiera poczenie z portem serwera (port numer 70 dla Gophera) i wysya danie. Serwer wysya odpowied i zamyka poczenie. R nica dotyczy zawartoci odpowiedzi serwera. Cho protok Gopher dopuszcza przesyanie nietekstowej informacji, wikszo klientw Gophera wsppracuje
186
Rozdzia 13
jedynie z terminalami ASCII. Dlatego te wikszo dokumentw przesyanych przez serwery Gophera to pliki tekstowe. W czasie gdy powstaje ta ksika, wiele wzw internetowych likwiduje usugi Gophera, poniewa HTTP zaczyna zdecy dowanie dominowa. Wiele przegldarek W WW potrafi jednak uy protokou Gopher i komunikuje si z takimi serwerami, gdy URL ma form g o p h e r : f /hostncime. Bd pojawia si kolejne wersje HTTP zazwyczaj jako szkic internetowy". Wprowadzone zostan by moe takie rozszerzenia jak weryfikacja tosamoci (iauthentication), trwae poczenia TCP i ustalanie formatu zawartoci dokumen tw.
14

14.1 Wstp
W tym rozdziale prezentujemy inne spojrzenie na protok HTTP i niektre bar dziej oglne waciwoci internetowego zestawu protokow. Przeanalizujemy tutaj pakiety przetwarzane przez silnie obciony serwer HTTP. W ten sposb moemy powiza niektre waciwoci T C P/IP przedstawione w tomach 1 i 2, analizujc je w warunkach rzeczywistego uytkowania. Obecny rozdzia pokazuje te, jak rne (a czasami zupenie dziwaczne) moe by dziaanie protokou TCP i jego implementacji. W tym rozdziale poruszamy wiele zagadnie - w kolejnoci odpowiadajcej mniej wicej etapom czynnoci w poczeniu TCP: nawizanie poczenia, przesanie danych i zakoczenie poczenia. Dane uyte w rozdziale zostay zebrane w systemie bdcym komercyjnym do stawc usug internetowych. System dostarcza usug HTTP dla 22 rnych insty tucji. W systemie dziaaj 22 kopie serwera NCSA httpd. (Zagadnienie urucha miania wielu serwerw jednoczenie omwimy szerzej.) CPU systemu to procesor Intel Pentium i wykorzystywany jest system operacyjny BSD/OS V I.1. Zebrane zostay trzy zestawy danych. 1. W okresie 5 dni program n e t s t a t z opq' - s uruchamiany by raz na godzin, by zebra wartoci wszystkich zmiennych statystycznych protokow interne towych. S to zmienne omawiane w tomie 2, na przykad na stronach 216 (IP) i 827 (TCP). 2. Program Tcpdump (dodatek A tomu 1) by uruchomiony cznie na 24 godziny w cigu tych 5 dni i rejestrowa kady pakiet TCP odebrany lub wysany przez port 80, zawierajcy flag SYN, FIN lub RST. W ten sposb moemy szczego wo przeanalizowa statystyk pocze HTTP. Tcpdump zarejestrowa 686 755 pakietw w cigu wspomnianego okresu, co sprowadzio si do 147 103 prb nawizania poczenia. 3. Zarejestrowany zosta kady pakiet otrzymany lub wysany przez port 80 w cigu 2,5 godziny po zakoczeniu piciodniowego okresu. Dziki temu ze stawowi danych moemy dokadniej przyjrze si kilku szczeglnym przypad kom, analizujc segmenty inne ni te, ktre zawieraj flagi SYN, FIN i RST. W cigu tego okresu zarejestrowano 1 039 235 pakietw, co daje redni okoo 115 pakietw na sekund. Do zebrania danych S Y N /FIN /R ST w okresie 24-godzinnym uylimy polecenia:
$ t c p d u m p -p -w d a t a . o u t tcp and po rt 80 and t c p [13:1] & 0x7 !- 0'
188
Rozdzia 14
Flaga - p powoduje, e interfejs nie pracuje w tzw. trybie nasuchu (promiscuous mode), tak wic zostaj zarejestrowane tylko pakiety odebrane lub wysane przez hosta, w ktrym zosta uruchomiony program Tcpdump - tylko takimi pakietami jestemy zainteresowani. Uywajc tej flagi zmniejszamy objto danych zebra nych z sieci lokalnej i zmniejszamy rwnie prawdopodobiestwo zagubienia pakietw.
Flaga ta nie gwarantuje pracy w trybie nienasuchowym. Interfejs m g by przestawiony w tryb nasuchu przez inny proces. W cigu kilku rnych dugich okresw dziaania Tcpdump zaobserwowalimy, e gu biony jest jeden pakiet na 16 000-20 000 pakietw zarejestrowanych.
Flaga - w powoduje zbieranie danych w pliku binarnym - zamiast wywietlania ich w postaci tekstowej na ekranie. Utworzony plik jest pniej konwertowany (z uyciem flagi - r) do formatu tekstowego. Zbierane s tylko pakiety TCP odbierane lub wysyane przez port 80. Ponadto logiczne AND pojedynczego bajtu na 13 pozycji wzgldem pocztku nagwka TCP i liczby 7 musi dawa warto niezerow. W ten sposb sprawdzamy, czy flaga SYN, FIN lub RST jest ustawiona (strona 263 tomu 1). Zbierajc tylko takie pakiety i nastpnie analizujc numery sekwencyjne w segmentach SYN i FIN moemy okreli, ile bajtw zostao przesanych w obu kierunkach poczenia. Oprogramowanie tc p d u m p - reduce, napisane przez Verna Paxsona, zostao uyte do analizy danych produkowanych przez Tcpdump ( h t t p : //town .hall .o r g / A r chi v e s / / p u b / ITA/).
Pierwszy z prezentowanych wykresw (rysunek 14.1) pokazuje cakowit licz b prb pocze, aktywnych i pasywnych, w cigu piciodniowego okresu. Przedstawione liczby odpowiadaj dwm zmiennym statystycznym TCP, t c p s _ c o n n a t t e m p t i t c p s _ a c c e p t s ze strony 827 tomu 2. Pierwsza zmienna jest inkrementowana, gdy zostaje wysany segment SYN w aktywnym otwarciu, a druga - gdy SYN zostaje otrzymany przez odbierajce gniazdo. Zmienne te s uaktualniane dla wszystkich pocze TCP w danym systemie, nie tylko dla po cze HTTP. Spodziewamy si, e system, ktry przede wszystkim peni rol serwera W W W , bdzie znacznie czciej odbiera poczenia ni je nawizywa. (System peni te inne funkcje, ale wikszo ruchu T C P/IP stanowi pakiety HTTP.) Dwie linie przerywane w czasie zblionym do pitkowego i sobotniego poudnia ograniczaj 24-godzinny okres, w ktrym segmenty SYN /F IN /R S T byy zbierane. Biorc pod uwag tylko pasywne prby pocze zauwaamy, e kadego dnia w okresie od przedpoudnia do pnocy nachylenie wykresu jest wiksze, tak jak si tego zreszt spodziewamy. Zauwaamy rwnie, e nachylenie jest mniejsze w cigu weekendu, poczynajc od pnocy w pitek. Te dobowe periodyczne zmia ny s lepiej widoczne na wykresie czstotliwoci pasywnych prb pocze poka zanym na rysunku 14.2
Sekcja 14.1
Wstp
189
wtorek poudnie
roda poudnie
czwartek poudnie
pitek poudnie
sobota poudnie
niedziela poudnie
czas dziaania systemu od przeadowania (minuty)
Rysunek 14.1 Cakowita liczba aktywnych i pasywnych prb pocze
wtorek poudnie
roda poudnie
czwartek poudnie
pitek poudnie
sobota poudnie
niedziela poudnie
czas dziaania systemu od przeadowania (minuty)
Rysunek 14.2 Jednoczenie dziaajce serwery HTTP
190
Rozdzia 14
Jak m ona zdefiniowa silnie obcionego" serwera? Badany system odbiera nieco ponad 150 000 pocze TCP dziennie. Daje to redni 1,74 poczenia na sekund. W pracy [Braun i Claffy 1994] omwiono serwer NCSA, ktry otrzym ywa rednio 360 000 da klientw dziennie (we wrzeniu 1994) i obcienie podwajao si po ka dych 6-8 tygodniach. Inny autor [Mogul 1995b] analizuje prac dwch serwerw, ktre okrela jako wzgldnie obcione". Jeden z tych serwerw przetwarza milion, a drugi 40 000 da dziennie w okresie ponad 3 miesicy. W The Wall Street Journal" z 21 czerw ca 1995 r. wyliczono 10 najbardziej obcionych serwerw W W W , na podstawie pomiarw wykonanych w tygodniu od 1 do 7 maja 1995 r. Serwery te odbieray od 4,3 miliona pocze na tydzie ( w w w . n e t s c a p e , c o m) do zaledwie 300 000 pocze dzien nie. Na podstawie danych przytoczonych powyej widzimy, e wszelkie stwierdzenia dotyczce szybkoci i sprawnoci dziaania serwerw W W W oraz odpowiednich danych statystycznych naley przyjmowa z rezerw. Jak zobaczymy w tym rozdziale, mog istnie wielkie rnice pomidzy serwerami, dotyczce liczby prb pocze na dzie, liczby nawizanych pocze, liczby klientw i liczby sesji. Innym czynnikiem, ktry powinien by wzity pod uwag, jest liczba hostw, na ktrych dziaa serw er danej instytucji, co bdziemy omawia w nastpnym podrozdziale.
14.2
Jednoczesne serwery HTTP
Z najprostsz sytuacj mamy do czynienia, gdy pojedynczy serwer HTTP jest uruchomiony w jednym komputerze. Cho wiele wzw moe by zorganizowa nych wanie w ten sposb, istniej dwie inne czsto spotykane sytuacje. 1. Jeden host, wiele serwerw. Ta metoda bya uyta w serwerze, ktry dostarczy danych analizowanych w tym rozdziale. Pojedynczy host wiadczy usugi HTTP dla wielu instytucji. Nazwie domeny W W W kadej z tych instytucji (w w w . organ i za t i on. com) odpowiada inny adres IP (wszystkie adresy nale do tej samej podsieci) i do wszystkich tych adresw IP zostaje przypisany jeden interfejs internetowy. (W rozdziale 6.6 tomu 2 opisalimy, w jaki sposb N e t/3 dopuszcza wiele rnych adresw IP dla jednego interfejsu. Dodatkowe adresy IP przypisane do interfesju, oprcz podstawowego, nazywane s aliasami.) Kada z 22 kopii serwera h 11 p d obsuguje tylko jeden adres IP. Kady z tych 22 serwerw wie jeden lokalny adres IP ze swoim odbierajcym gniazdem, tak e odbiera on tylko poczenia przeznaczone dla tego adresu IP. 2. Kilka hostw udostpnia po jednej kopii serwera. Ta technika stosowana jest przez silnie obcione instytucje w celu rozoenia obcienia na kilka hostw (load balancing - wyrwnywanie obcienia). Wiele rnych adresw IP zostaje przypisanych do domeny WWW danej instytucji, w ww. organi z a t i on . c omjeden adres IP dla kadego hosta z uruchomionym serwerem HTTP (wielokrot ne rekordy A w DNS, rozdzia 14 w tomie 2). Serwer DNS instytucji musi potrafi dostarcza wielorakie adresy IP w rnej kolejnoci dla rnych da klienta DNS. W protokole DNS postpowanie takie nazywane jest przetioarzciniem cyklicznym (round-robin) i zostaje udostpniane choby przez aktualn wersj powszechnie spotykanego serwera DNS (BIND).
Sekcja 14.3__________ Czas pomidzy otrzymaniem kolejnych segmentw SYN
191
Na przykad NCSA udostpnia dziewi serwerw HTTP. Przy pierwszym zapytaniu skierowanym do serwera DNS tej instytucji otrzymujemy:
$ ho s t -t a w w w . n c s a . u i u c . e d u n e w t o n . n c s a . u i u c . e d u S erv er: n e w t o n . n c s a . u i u c . e d u A d d r e s s : 141.142.6.6 141.142.2.2 www.ncsa.uiuc.edu www.ncsa.uiuc.edu w w w . n c s a .ui u c .edu w w w .n c s a .ui u c .edu w w w .n c s a .ui u c .edu w w w . n c s a .ui uc.e du www.ncsa.uiuc.edu www.ncsa.uiuc.edu w w w . n c s a .ui u c .edu A A A A A A A A A 141 141 141 141 141 141 141 141 141 142.3.129 14 2. 3. 1 31 1 42 . 3 . 1 3 2 1 4 2 .3 . 13 4 1 42 .3 .7 6 1 42 .3 .7 0 1 42 .3 .7 4 1 42 .3 .3 0 1 42 . 3 . 1 3 0
(Program h o s t zosta opisany w rozdziale 14 tomu 1.) Ostatni argument jest nazw serwera DNS, NCSA, do ktrego skierowane jest zapytanie. Jeli ten argument nie bdzie podany, program skontaktuje si z lokalnym serwerem DNS, a ten bdzie prawdopodobnie posiada 9 rekordw A w swojej pamici podrcznej i bdzie je zwraca za kadym razem w tej samej kolejnoci. Przy nastpnym uruchomieniu programu, kolejno rekordw jest inna:
$ ho st -t a w w w . n c s a . u i u c . e d u n e w t o n . n c s a . u i u c . e d u Server: n e w t o n . n c s a . u i u c . e d u Ad d r e s s : 1 4 1 . 1 4 2 . 6 . 6 1 4 1 . 1 4 2 . 2 . 2 www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu www.ncsa.uiuc.edu A A A A A A A A A 141.142.3.132 141.142.3.134 141.142.3.76 141.142.3.70 141.142.3.74 141.142.3.30 141.142.3.130 141.142.3.129 141.142.3.131
14.3
Czas pomidzy otrzymaniem kolejnych segmentw SYN
Interesujce moe by przeanalizowanie odstpw czasu pomidzy kolejnymi segmentami SYN. W ten sposb moemy stwierdzi, jaka jest rnica pomidzy redni czstotliwoci da, a czstotliwoci maksymaln. Serwer powinien by w stanie spenia swoje funkcje w warunkach maksymalnego, a nie tylko redniego obcienia. Moemy zmierzy czas pomidzy segmentami SYN otrzymywanymi przez ser wera w czasie 24-godzinnej rejestracji segmentw SYN /FIN /R ST. W cigu 24 godzin serwery HTTP odebray 160 948 segmentw SYN. (Na pocztku tego rozdziau zauwaylimy, e zarejestrowano 147103 prby nawizania poczenia. Rnica zwizana jest z powtrnie przesyanymi segmentami SYN. Zauwamy, i niemal 10% segmentw SYN jest retransmitowanych.) Najmniejszy i najwikszy odstp czasu midzy segmentami SYN wynosi odpowiednio 0,1 ms i 44,5 sekundy.
192
Rozdzia 14
Warto rednia wynosi 538 ms, mediana 222 ms. 91% odstpw czasu jest krt szych ni 1,5 sekundy. (Rozkad odstpw czasu pokazujemy na rysunku 14.3.)
Przedstawiony histogram, cho interesujcy, nie podaje jednak maksymalnej cz stotliwoci otrzymywania segmentw SYN. eby wyznaczy czstotliwo m a ksymaln, dzielimy 24-godzinny okres na przedziay 1-sekundowe i obliczamy liczb segmentw SYN otrzymywanych w kadej sekundzie. (W rzeczywistoci czas trwania pomiaru by o par minut duszy ni 24 godziny i wynosi 86 622 sekundy.) Na rysunku 14.4 prezentujemy liczby przedziaw jednosekundowych, w ktrych odebranych byo 0,1,2,...20 segmentw. W drugiej kolumnie na rysunku przedstawiono cakowite liczby segmentw, w kolumnie trzeciej - liczby segmen tw otrzymane po odrzuceniu segmentw przesyanych powtrnie. Wartoci widniejce w ostatniej kolumnie wykorzystamy na kocu tego podrozdziau. Jeeli wemiemy pod uwag wszystkie odbierane segmenty SYN, to stwierdzamy, e byo 27 868 sekund (32% 24-godzinnego okresu), w ktrych nie odebrano adnego segmentu SYN, 22 471 sekund (26% okresu) z jednym odebranym seg mentem SYN, itd. Maksymalnie w cigu sekundy odebralimy 73 segmenty i byy dwie takie sekundy w cigu doby. Jeli wemiemy pod uwag wszystkie sekundy, w ktrych odebranych byo 50 lub wicej segmentw SYN, stwierdzamy, e wszystkie takie sekundy pojawiaj si w cigu 3-minutowego okresu. Jest to poszukiwane maksimum obcienia.
Sekcja 14.3_________ Czas pomidzy otrzymaniem kolejnych segmentw SYN
193
Liczba segmentw SYN otrzymywanych w cigu 1 sekundy 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Cakowita liczba przypadkw
Liczba przypadkw dla nowych SYN
27868 22471 13036 7906 5499 3752 2525 1456 823 536 323 163 90 50 22 14 12 4 5 2 3 86560
30565 22695 12374 7316 5125 3441 2197 1240 693 437 266 130 66 32 18 10 9 3 2 1 0 86620
Rysunek 14.4 Liczba segmentw SYN odbieranych w danej sekundzie Na rysunku 14.6 przedstawilimy wykres dla godziny zawierajcej maksimum obcienia. Sumujemy 30 jednosekundowych licznikw i tak okrelamy skal na osi y, by odpowiadaa ona liczbie otrzymywanych segmentw SYN na sekund. rednia czstotliwo otrzymywania SYN wynosi okoo 3,5 segmenta na sekund, a wic prze ca t godzin przychodzce segmenty SYN s przetwarzane z cz stotliwoci niemal dwukrotnie wiksz od czstotliwoci redniej. Na rysunku 14.7 przedstawiamy dokadniej owe trzy minuty z maksymalnym obcieniem. Zmiany czstotliwoci w tym trzyminutowym okresie s sprzeczne z intuicj i sugeruj patologiczne zachowanie jakiego klienta. Jeli spojrzymy na wydruk Tcpdump dla tych trzech minut, widzimy, e problem zwizany jest rzeczywicie z jednym klientem. W cigu 30 sekund obejmujcych pierwsze (z lewej strony rysunku) maksimum na rysunku 14.7, klient ten wysya 1024 segmenty SYN z dwch rnych portw, co daje redni okoo 30 segmentw SYN na sekund. W kilku okresach jednosekundowych zaobserwowano po 60-65 segmentw, co w sumie z segmentami pochodzcymi od innych klientw dao maksimum na
194
Pakiety znalezione w serwerze H TTP
Rozdzia 14
poziomie okoo 70 segmentw na sekund. rodkowe maksimum na tym rysunku byo rwnie spowodowane przez tego samego klienta. Na rysunku 14.5 pokazujemy zwizany z tym klientem fragment wydruku Tcpdump.
1 2 3 0 .0 0 . 0 0 1 6 5 0 (0 .0016) 0 . 0 2 0 0 6 0 (0 .0184) 0 . 0 2 0 3 3 2 (0 .0003) 0 . 0 2 0 7 0 2 (0 .0004) 1 . 9 3 8 6 2 7 (1 .9179) 1 . 9 5 8 8 4 8 (0.0202) 1 . 9 5 9 8 0 2 (0.0010) 2 . 0 2 6 1 9 4 (0 .0664) 2 . 0 2 7 3 8 2 (0.0012) 2 . 0 2 7 9 9 8 (0.0006) server ,8 0: S 1 3 1 7 0 7 9 : 1 3 1 7 0 7 9 ( 0 ) w i n 2 04 8 <mss 1460 > s e r v e r . 8 0 > C l i e n t . 1537: S 2 1 0 4 0 1 9 9 6 9 : 2 1 0 4 0 1 9 9 6 9 ( 0 ) ack 1317080 win 4096 <mss 512> C l i e n t . 1537 > server. 80 : S 1 3 1 7 0 9 2 : 1 3 1 7 0 9 2 ( 0 ) w i n 2048 <mss 1460> s e r v e r . 8 0 > C l i e n t . 1537: R 2 1 0 4 0 1 9 9 7 0 : 2 1 0 4 0 1 9 9 7 0 ( 0 ) ack 1 3 1 7 0 8 0 w i n 4096 s e r v e r . 8 0 > C l i e n t . 1537: R 0:0( 0) ack 1 3 1 7 0 9 3 win 0 C l i e n t . 1537 > s er ve r. 8 0: R 1 3 1 7 0 8 0 : 1 3 1 7 0 8 0 ( 0 ) w i n 2 0 4 8 C l i e n t . 1537 server.80 > c l i e n t . 1537 server.80 > server.80 > > se r ve r. 80 : S 1 3 1 9 0 4 2 : 1 3 1 9 0 4 2 ( 0 ) w i n 2048 <m ss 1460> Client. 1537: S 2 1 0 5 1 0 7 9 6 9 : 2 1 0 5 1 0 7 9 6 9 ( 0 ) ack 1319043 win 4096 <mss 512> > server. 8 0: S 1 3 1 9 0 8 3 : 1 3 1 9 0 8 3 ( 0 ) w i n 2 0 48 <mss 14 60> C l i e n t . 1537: R 2 1 0 5 1 0 7 9 7 0 : 2 1 0 5 1 0 7 9 7 0 ( 0 ) ack 1 3 1 9 0 4 3 wi n 4096 C l i e n t . 1537: R 0 :0(0) ack 1 3 1 90 8 4 win 0 C l i e n t . 1537 >
4
5 6
7
8 9
10 11
Rysunek 14.5 Wcidliiuy klient wysyajcy z du czstotliwoci niepoprawne segmenty SYN - wydruk Tcpdump
liczba segmentw SYN otrzymywanych w cigu sekundy
czas (minuty)
Rysunek 14.6 Liczba otrzymywanych segmentw SYN na sekund w 60-minutowym przedziale czasu
Sekcja 14.3_________ Czas pomidzy otrzymaniem kolejnych segmentw SYN
195
Rysunek 14.7 Liczba otrzymanych segmentw SYN na sekund w 3-minutoivym przedziale czasu z maksimum obcienia W linii pierwszej widzimy SYN klienta, a w drugiej segment SYN /A C K serwera. W trzeciej znajdujemy natomiast inny segment SYN, z tego samego portu tego samego klienta, z pocztkowym numerem sekwencyjnym wikszym o 13 od nu meru sekwencyjnego z linii pierwszej. Serwer wysya RST w linii czwartej i nastp ne RST w linii pitej, a klient wysya RST w linii szstej. Scenariusz powtarza si, poczynajc od linii sidmej. Dlaczego serwer wysya pod rzd dwa segmenty RST do klienta (linie czwarta i pita)? Jest to prawdopodobnie spowodowane przez jakie segmenty, ktre nie s tu pokazane, gdy ten wydruk Tcpdump zawiera, niestety, jedynie segmenty z flagami SYN, FIN i RST. Mimo to wida wyranie, e klient dziaa wadliwie, wysyajc segmenty SYN z tak du czstotliwoci z tego samego portu i z nie znacznie zmieniajcymi si numerami sekwencyjnymi pomidzy kolejnymi seg mentami SYN.
Obliczenia powtrzone bez retransmitowanych SYN

Musimy jeszcze raz przeanalizowa czas pomidzy kolejnymi otrzymanymi seg mentami, pomijajc powtrnie przesyane segmenty SYN, poniewa - jak wanie stwierdzilimy - jeden wadliwy klient moe znaczco zmieni wyniki. Tak jak wspomnielimy na pocztku tego rozdziau, odrzucamy w ten sposb okoo 10% segmentw SYN. Pomijajc powtrzone segmenty SYN, analizujemy te czstotli wo nawizywania nowych pocze z serwerem. Podczas gdy czstotliwo
196
Rozdzia 14
odbierania wszystkich segmentw SYN ma znaczenie dla przetwarzania protoko u T C P /IP (poniewa kady SYN jest przetwarzany przez program obsugi urz dzenia, wejcie TCP i wreszcie wyjcie TCP), to czstotliwo nawizywania po cze wie si z dziaaniem serwera HTTP (ktry obsuguje nowe danie dla kadego poczenia). Przedstawiona na rysunku 14.3 warto rednia wzrasta od 538 do 600 ms, a me diana zwiksza si od 222 do 251 ms. Na rysunku 14.4 podane zostay wczeniej liczby segmentw otrzymywanych w cigu sekundy. Piki, takie jak te przedsta wione na rysunku 14.6, s teraz znacznie mniejsze. W cigu trzech sekund z naj wiksz w cigu dnia liczb segmentw SYN otrzymano 19, 21 i 33 takie segmen ty. Odbieranych jest wic od 4 segmentw na sekund (dla mediany rozkadu odstpu czasu midzy segmentami rwnej 251 ms) do maksymalnie 33 segmen tw na sekund, czyli czstotliwo otrzymywanych segmentw wzrasta o czyn nik rzdu 8 w stosunku do wartoci najczciej spotykanej. Oznacza to, e przy projektowaniu serwera W W W powinnimy przewidzie maksimum czstotliwo ci pocze o podobnej wielkoci w stosunku do wartoci redniej. W rozdziale 14.5 omwimy wpyw takich okresw o wyjtkowo duej czstotliwoci pocze na kolejk odbieranych da.
14.4
Pomiary RTT
Zajmiemy si teraz okreleniem czasu przesania pakietw w obie strony (RTT) pomidzy serwerem i rnymi klientami. Niestety, nie jestemy w stanie wyzna czy RTT na podstawie zestawu danych zawierajcego segmenty SYN /FIN /R ST. Na rysunku 14.8 przedstawilimy potrjne uzgodnienie TCP oraz cztery segmenty koczce poczenie (z pierwszym segmentem FIN wysanym przez serwera). Pogru bione linie odpowiadaj segmentom zarejestrowanym w zestawie SYN/FIN/RST. Klient moe wyznaczy swoj warto RTT jako rnic pomidzy czasem wysa nia wasnego SYN, a czasem otrzymania segmentu SYN od serwera, my jednak wykonujemy pomiary po stronie serwera. Moemy rozwaa wyznaczenie RTT serwera jako czasu pomidzy wysaniem flagi FIN serwera, a otrzymaniem flagi FIN od klienta. Taki pomiar zawiera jednak zmienne opnienie po stronie klien ta: czas pomidzy otrzymaniem przez aplikacj klienta znaku koca pliku, a za mkniciem poczenia po stronie klienta. Do pomiaru RTT serwera potrzebujemy zestawu danych zawierajcego wszystkie pakiety. Uyjemy wic danych zebranych w okresie 2,5-godzinnym i wyznaczy my czas pomidzy wysaniem SY N /A C K przez serwera, a otrzymaniem przez serwera flagi ACK klienta. Potwierdzenie przez klienta segmentu SYN serwera zwykle nie jest opnione (strona 988jtom 2), pomiar ten nie obejmuje wic (w zasadzie) opnionego ACK. Dobrze, by rozmiary segmentw byy najmniejsze z moliwych (44 bajty dla segmentu SYN serwera zawierajcego opcj MSS z warto ci MSS uywan przez serwera i 40-bajtowe potwierdzenie klienta) - segmenty te nie powinny by znaczco opnione w wolnych liniach SLIP lub PPP.
Sekcja 14.4
Pomiary R T T
197
W czasie 2,5-godzinnego okresu wykonano 19 195 pomiarw RTT dla 810 klien tw o rnych adresach IP. Najmniejsza warto RTT wyniosa 0 (dla klienta w tym samym komputerze), najwiksza 12,3 sekundy, warto rednia bya rwna 445 ms, a mediana 187 ms. Rozkad RTT dla wartoci nie wikszych ni 3 sekundy pokazany jest na rysunku 14.9. W tym przedziale mieci si 98,5% otrzymanych wartoci. Widzimy z tych pomiarw, e przy teoretycznej wartoci RTT dla najbar dziej oddalonych klientw (wschodnie - zachodnie wybrzee w USA - przyp. tum.) rwnej okoo 60 ms, wartoci otrzymane dla typowych klientw s przynaj mniej trzykrotnie wiksze.
Dlaczego mediana (178 ms) jest a o tyle wiksza od teoretycznej wartoci dla najbardziej oddalonych klientw (60 ms)? Pierwszym moliwym wytumaczeniem jest to, e wiele klientw uywa linii telefonicznych, a kady, nawet szybki modem (28 800 bps) dodaje 100-200 ms do kadej wartoci RTT. Moliwe take, e niektre implementacje klienta opniaj jednak trzeci segment potrjnego uzgodnienia - potwierdzenie przez klienta segmentu SYN serwera.
198
Rozdzia 14
14.5
Drugi argument funkcji listen
Serwer, by przygotowa gniazdo do odbioru przychodzcych pocze, tradycyj nie wykonuje

1 isten(sockfd. 5);
Drugi argument funkcji 1 i sten zwany jest argumentem przepenienia (backlog) w na gwku < s y s / s o c k e t .h>. Jeeli aplikacja podaje wiksz warto, warto ta zo staje w istocie milczco zredukowana do S0MAXC0NN. W nowszych jdrach warto S 0 M A X C 0 N N zostaa zwikszona na przykad do 10 z przyczyn, ktre za chwil omwimy. Dla gniazda argument przepenienia (strony 470-471 w tomie 2). Gdy otrzymane zostaje danie poczenia TCP (SYN klienta), TCP wywouje sonewconn i przepro wadzone zostaje nastpujce sprawdzenie (linie 130-131 na stronie 477 w tomie 2):
if ( h e a d - > s o _ q l e n + h e a d - > s o _ q 0 1 e n > 3 * h e a d - > s p _ q l i m i t / 2) r e t u r n (( st r uc t so c k e t *)0):
Jak opisano w tomie 2, mnoenie przez czynnik 3 / 2 dodaje margines bezpieczestwa do Argumentu przepenienia l i s t e n podanego przez aplikacj - ogranicza w rzeczywistoci liczb oczekujcych pocze do 8, gdy warto argumentu wynosi 5. Taki margines bezpieczestwa istnieje tylko w implementacjach w ywodzcych si z systemu Berkeley (strony 299-301 w tomie 1).
Sekcja 14.5
199
Limit liczby pocze w kolejce ogranicza w rzeczywistoci sum nastpujcych wartoci: liczba pozycji w kolejce niekompletnych pocze (so_q01 en - poczenia, dla ktrych nadszed segment SYN, ale potrjne uzgodnienie jeszcze nie zostao zakoczone), liczba pozycji w kolejce kompletnych pocze (s o_q 1 en - potrjne uzgodnie nie jest zakoczone i jdro czeka a proces wywoa accept).
Na stronie 476 w tomie 2 przedstawiono dokadnie kolejne kroki przetwarzania, gdy odebrane zostaje danie poczenia TCP. Ograniczenie liczby pocze umieszczanych w kolejce moe zosta osignite, gdy kolejka kompletnych pocze zapeni si (tzn. proces serwera lub host serwe ra s tak zajte, e proces nie moe wystarczajco szybko wywoa c o n n e c t i usun poczenia z kolejki) lub gdy zapeni si kolejka niekompletnych po cze. Ta druga sytuacja zdarza si w przypadku serwera HTTP, gdy czas przesa nia pakietu w obie strony jest dugi w porwnaniu z czstotliwoci otrzym yw a nia nowych da pocze. Dzieje si tak dlatego, bo nowy segment SYN zajmuje miejsce w tej kolejce przez czas RTT. Przedstawione to zostao na rysunku 14.10.
Rysunek 14.10 Czas istnienia wpisu w kolejce niekompletnych pocze Program n e t s t a t zosta zmodyfikowany tak, by moliwe byo sprawdzenie, czy wypenia si kolejka niekompletnych pocze (a nie pocze kompletnych). Zmodyfikowany program wypisuje w sposb cigy wartoci dwch zmiennych, s o _ q 01 en i so_ql en, dla najbardziej zajtych odbierajcych serwerw HTTP. Pro gram zosta uruchomiony na przecig dwch godzin, w czasie ktrych zebrano 379 076 wartoci obu zmiennych, co daje jeden pomiar co 19 ms. Wyniki przedsta wiono na rysunku 14.11.
200
Rozdzia 14
Dugo kolejki
Liczba przypadkw dla kolejki niekompletnych pocze 167123 116175 42185 18 842 12871 14581 6 346 706 245 379076
Liczba przypadkw dla kolejki kompletnych pocze 379075 1
0 1 2 3 4 5 6 7 8
379076
Rysunek 14.11
Rozkad dugoci kolejek pocze dla silnie obcionego senuera HTTP
Tak jak wspomnielimy wczeniej, warto argumentu przepenienia rwna 5 dopuszcza maksymalnie 8 pocze oczekujcych w kolejce. Kolejka kompletnych pocze jest niemal zawsze pusta, poniewa gdy tylko co pojawia si w tej kolejce, wywoanie accept w kodzie serwera zwraca kontrol i serwer usuwa kompletne poczenie z kolejki. Gdy kolejka przepenia si, TCP ignoruje przychodzce dania pocze (strona 969 w tomie 2), zakadajc, e klient po upywie czasu oczekiwania na retransmisj wyle ponownie SYN, i by moe po paru sekundach znajdzie miejsce w kolejce. Kod N e t/3 nie zlicza jednak w aden sposb takich zignorowanych segmentw SYN, administrator systemu nie m a wic adnej moliwoci sprawdzenia, jak czsto co takiego si zdarza. W zwizku z tym wprowadzilimy nastpujc modyfikacj w kodzie serwera:
if ( s o - > s o _ o p t i o n s & S 0 _ A C C E P T C 0 N N ) so = s o n e w c o n n ( s o , 0); i f (s o = = 0) I tcpstat.tcps_listendrop++; g ot o drop: ( /* no wy l i c z n i k */
I Dodalimy w ten sposb nowy licznik pocze. Na rysunku 14.12 pokazujemy wartoci tego licznika rejestrowane raz na godzin w cigu piciu dni. Co prawda licznik obejmuje wszystkie serwery w naszego hosta, ale - biorc pod uwag, e host ten gwnie peni rol serwera W W W moemy by pewni, e przepenienia kolejki zdarzaj si dla odbierajcych gniazd httpd. rednio host ten ignoruje zaledwie trzy przychodzce poczenia na minu t (22 918 przepenie podzielonych przez 7139 minut), widoczne s jednak wyrane skoki, gdy liczba przepenie jest znaczco wiksza. W czasie oznaczo nym na rysunku jako 4500 (godz. 4.00 w pitek po poudniu) 1964 segmenty SYN zostay zignorowane w cigu 1 godziny, co daje 32 zignorowane segmenty na minut (jeden segment co 2 sekundy). Dwa inne znaczce skoki pojawiaj si w czwartek po poudniu.
Sekcja 14.5
201
wtorek poudnie
roda poudnie
czwartek poudnie
pitek poudnie
sobota poudnie
niedziela poudnie
przepenienia kolejki
odbiorczej
czas dziaania systemu od przeadowania w minutach
Rysunek 14.12 Przepenienie kolejki odbiorczej serwera W jdrach systemw obsugujcych silnie obcione serwery warto argumentu przepenienia jest pod tym wzgldem wadliwa, poniewa w tej wersji liczba 5 jest bezporednio wpisana jako warto drugiego argumentu funkcji 1 i sten:
listen ts d. 5);
W wersji 1.4 warto argumentu jest zwikszona do 35, ale nawet ta warto moe by zbyt maa dla silnie obcionych serwerw. W systemach pochodzcych od rnych dostawcw, stosowane s rne meto dy zwikszania argumentu przepenienia, na przykad globalna zmienna jdra s o m a x c o n n inicjowana jest wartoci 16 i moe by zwikszona przez administra tora systemu. Solaris 2.4 umoliwia administratorowi zmian wartoci parametru TCP t c p _ c o n n _ r e q _ m a x przy pomocy programu ndd. Warto domylna wynosi 5 i moe by maksymalnie zwikszona do 32. W systemie Solaris 2.5 warto domylna jest zwikszona do 32, a warto maksymalna wynosi 1024. Niestety, nie istnieje prosty sposb sprawdzenia przez aplikacj, jaka jest aktualna warto argumentu wywoania funkcji 1 i sten w jdrze. Najlepiej wic, by w aplikacji podana bya dua warto argumentu (warto zbyt dua nie powoduje bdu funkcji listen), lub by uytkownik mg poda t warto jako argument w linii polecenia. Zaproponowano rwnie [Mogul 1995c], by argument przepenienia by ignorowany, a jdro ustalao moliwie najwiksz warto limitu.
202
Rozdzia 14
Niektre aplikaq'e z premedytacj podaj nisk warto argum entu przepenienia. Po winna wic istnie moliwo uniknicia zwikszania tej wartoci dla niektrych aplikacji.
Bd SYN_RCVD
Przy okazji analizowania wydruku n e t s t a t zauwaono, e jedno gniazdo pozo stawao w stanie SYN_RCVD przez wiele minut. W kodzie N e t/3 czas trwania tego stanu jest ograniczony przez zegar nawizywania poczenia (connection-establishment timer, strony 860 i 984 w tomie 2) do 75 sekund, wic zaobserwowana sytuacja nie bya spodziewana. Na rysunku 14.13 przedstawiamy wydruk Tcpdump.
0 .0 C l i e n t . 48 21 > s er ve r. 8 0: S 3 2 3 2 0 0 0 0 : 3 2 3 2 0 0 0 0 ( 0 ) w in 6 1 4 40 <mss 512> 0 . 0 0 1 0 4 5 ( 0.00 10 ) s e r v e r . 8 0 > C l i e n t . 4821: S 3 6 5 7 7 7 4 0 9 : 3 6 5 7 7 7 4 0 9 ( 0 ) ack 32 320001 win 4096 <mss 512> S 365777409:365777409(0) ack 32 320001 w in 4096 <mss 512> 5 . 8 2 7 4 2 0 ( 0 . 0 3 58 ) C l i e n t . 4821 > s er v er .8 0: S 3 2 3 2 0 0 0 0 : 3 2 3 2 0 0 0 0 ( 0 ) w i n 6 1 4 4 0 <ms s 5 1 2> 5 . 8 2 7 7 3 0 ( 0.0003) s e r v e r . 8 0 > C l i e n t . 4821: S 3 6 5 7 7 7 4 0 9 : 3 6 5 7 7 7 4 0 9 ( 0 ) ack 32 320001 win 40 96 <mss 512> ( 23.9738) s e r v e r . 8 0 > C l i e n t . 4821: S 3 6 5 7 7 7 4 0 9 : 3 6 5 7 7 7 4 0 9 ( 0 ) ack 32 320001 win 40 96 <mss 5 1 2> 2 9 . 8 2 8 2 5 6 ( 0.02 68 ) C l i e n t . 4821 > s er ve r .8 0: S 3 2 3 2 0 0 0 0 : 3 2 3 2 0 0 0 0 ( 0 ) win 6 1 4 40 <mss 5 1 2> 2 9 . 8 2 8 6 0 0 ( 0.0 0 03 ) s e r v e r \ 8 0 > C l i e n t . 4821: S 3 6 5 7 7 7 4 0 9 : 3 6 5 7 7 7 4 0 9 ( 0 ) ack 32320001 win 4096 <mss 5 1 2> S 365777409:365777409(0) ack 323 20001 win 40 96 <mss 512> 1 4 1 . 8 2 1 7 4 0 (64. 0 09 9) s e r v e r . 8 0 > C l i e n t . 4821: S 3 6 5 7 7 7 4 0 9 : 3 6 5 7 7 7 4 0 9 ( 0 ) ack 32320001 win 4096 <mss 512> serwer ponawia przestanie SYN/ACK co 64 sekundy 77.811791 (47. 98 3 2) s e r v e r . 8 0 > C l i e n t . 4821: 29.801493 5 . 7 9 1 5 7 5 ( 5.79 05 ) s e r v e r . 8 0 > Client.4821:
1
2 3
4
5 6 7
8
9
10
18
6 5 4 . 1 9 7 3 5 0 (64 .1 9 11 ) s e r v e r . 8 0 > Client. 4821: S 3 6 5 7 7 7 4 0 9 : 3 6 5 7 7 7 4 0 9 ( 0 ) ack 32 320001 win 4096 <mss 512>
Rysunek 14.13 Gniazdo serwera pozostajce ponad 11 minut w stanie SYN_RCVD Flaga SYN klienta otrzymana zostaje w segmencie pierwszym, a drugi segment zawiera SYN /A C K serwera. Serwer ustawia zegar nawizywania poczenia na 75 sekund i ustala czas oczekiwania na retransmisj na 6 sekund. Czas ten upywa w trzeciej linii i serwer wysya powtrnie SYN /ACK . Jest to zgodne z oczekiwa niami. Klient odpowiada w linii czwartej, ale odpowied jest powtrzeniem oryginalne go segmentu SYN z linii pierwszej, a nie oczekiwanym potwierdzeniem segmentu SYN serwera. Wydaje si, e klient dziaa wadliwie. Serwer poprawnie odpowiada powtrzonym segmentem SYN /A CK. Otrzymanie czwartego segmentu powodu je, e wejcie TCP ustawia zegar podtrzymywania" poczenia (keepalive timer, strona 971 tomu 2) na 2 godziny. Zegary nawizywania poczenia i podtrzymy-
Sekcja 14.6
Opcje w segmencie SYN klienta
203
wania poczenia uywaj jednak tego samego licznika w bloku kontrolnym (ry sunek 25.2, strona 849 w tomie 2), tak wic pozostajce 69 sekund zegara nawizy wania poczenia zostaje zastpione 2 godzinami. Zwykle klient zakacza potrj ne uzgodnienie potwierdzeniem segmentu SYN serwera. Kiedy to potwierdzenie jest przetworzone, zegar podtrzymywania poczenia otrzymuje warto 2 godzin 1 zegar oczekiwania na powtrzenie transmisji jest wyczony. Linie szsta, sidma i sma s podobne. Czas oczekiwania serwera na powtrze nie transmisji upywa po 24 sekundach, serwer wysya ponownie SYN /A C K , ale klient bdnie wysya swj oryginalny SYN jeszcze raz, tak wic serwer poprawnie powtarza wysanie SYN /A CK . W linii dziewitej czas oczekiwania serwera na powtrzenie transmisji upywa raz jeszcze po 48 sekundach i SYN /A C K jest ponownie wysany. Zegar oczekiwania na powtrzenie transmisji osiga nastp nie maksymaln warto rwn 64 sekundy i wykonanych zostaje 12 retransmisji (staa TCP_M AX RXTSHIFT, strony 874,875 tomu 2, ma warto 12,) po czym pocze nie zostaje odrzucone. Bd mona poprawi unikajc ustawienia zegara podtrzymywania poczenia na 2 godziny, gdy poczenie nie jest nawizane (strona 971 w tomie 2), jako e licznik T C P T _ K E E P jest uywany wsplnie przez zegar podtrzymywania poczenia i ze gar nawizywania poczenia. Wprowadzenie takiej modyfikacji wymaga jednak, by po nawizaniu poczenia zegar podtrzymywania poczenia zosta ustawiony na 2 godziny.
14.6
Poniewa w 24-godzinnym zestawie danych rejestrujemy wszystkie segmenty SYN, moemy przyjrze si wartociom rnych parametrw i opcjom zawartym w segmentach SYN.
Numery portw klientw

Systemy wywodzce si z systemu Berkeley przypisuj efemeryczne numery por tw z zakresu od 1024 do 5000 (strona 758, tom 2). Tak jak si spodziewamy, 93,5% spord 160 000 numerw portw klientw zawiera si w tym zakresie. Otrzyma nych zostao 14 da klientw z numerem portu mniejszym ni 1024, czyli z zakresu odpowiadajcego zarezerwowanym numerom portw w N e t/3 , a po zostae 6,5% da miao numery portw pomidzy 5001 i 65 535. Niektre syste m y, w szczeglnoci Solaris 2.x, przypisuj numery portw poczynajc od 32 768. Rysunek 14.14 pokazuje rozkad numerw portw klientw. Numery te zgrupo wane s w przedziaach o szerokoci 1000. Zwracamy uwag na logarytmiczn skal osi y. Zauwamy, e nie tylko wikszo numerw portw zawiera si w przedziale od 1024 do 5000, ale dwie trzecie tych numerw ulokowanych jest pomidzy 1024 i 2000.
204
Rozdzia 14
100000 50000
20000-
100000
-5 0 0 0 0
-
20000
10000
10000
5000 2000 1000

5000
2000
1000
liczba przypadkw (skala logarytmiczna)
^
100
500
200
100
502010|
50
-20
10
-5
2 1
numer portu klienta
2
1
5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 55000 60000 65000
Rysunek 14.14
Rozkad numerw portu klientw
Maksymalny rozmiar segmentu (MSS)

Zgoszony maksymalny rozmiar segmentu (MSS) moe wynika z wartoci MTU sieci (patrz nasza wczeniejsza dyskusja w zwizku z rysunkiem 10.9) lub mog by uywane pewne ustalone wartoci (512 lub 536 dla nielokalnych partnerw, 1024 dla starszych systemw BSD, itd.). RFC 1191 [Mogul i Deering 1990] wylicza 16 rnych, typowych wartoci MTU. Spodziewalimy si wic znale kilkana cie rnych wartoci MSS zgaszanych przez klientw WWW. Znalelimy nato miast 117 rnych wartoci w zakresie od 128 do 17 520. Na rysunku 14.15 pokazujemy trzynacie najczciej spotykanych wartoci MSS zgoszonych przez klientw. Tych 5071 klientw stanowi 94% wszystkich 5386 klientw, ktre czyy si z serwerami WWW. Okrelenie brak" w pierwszej pozycji w tabeli oznacza, e segment SYN klienta nie zgasza wartoci MSS.
Informacja o pocztkowym rozmiarze okna
Segmenty SYN klientw zawieraj rwnie informacje klienta o pocztkowym rozmiarze okna. Zanotowano 117 rnych wartoci rozoonych w caym dozwo lonym zakresie od 0 do 65 535. Rysunek 14.16 pokazuje liczby zlicze dla 14 najczciej spotykanych wartoci.
Sekcja 14.6
205
MSS brak 212 216 256 408 472 512 536 966 1024 1396 1440 1460
Liczba przypadkw Komentarz 703 53 47 516 24 21 465 1097 123 31 117 248 1626 5071 MTU Ethernetu (1500)-40 512-40 czsto spotykana warto domylna dla nielokalnego hosta czsto spotykana warto domylna dla nielokalnego hosta ARPANET MTU (1006)-40 warto uywana dawniej w BSD dla lokalnego hosta 256-40 poczenie SLIP lub PPP z MTU = 296 R FC 1122 nakazuje przyj 536, jeeli opcja nie jest uyta
Rysunek 14.15
Rozkad najczciej spotykanych wartoci MSS zgaszanych przez klientw
Rozmiar okna 0 512 848 1024 2048 2920 4096 8192 8760 16384 22099 22792 32768 61440
Liczba przypadkw Komentarz 317 94 66 67 254 296 2062 683 179 175 486 128 94 89 4990 60x10 24 7x7x11x41 7x8x11x37 ? ? 2 x 14 60 czsto spotykana warto domylna rozmiaru buforu odbiorczego rzadziej spotykana warto domylna 6 x 1460 (warto czsto spotykana dla Ethernetu)
Rysunek 14.16
Rozkad pocztkowych rozmiarw okna zgaszanych przez klientw
Wymieniona na rysunku suma 4990 stanowi 93% wszystkich informacji o rozmia rze okna podanych przez 5386 rnych klientw. Niektre wartoci s sensowne, inne natomiast - jak na przykad 22099 - stanowi zagadk.
206
Rozdzia 14
Najwidoczniej istniej przegldarki W W W w komputerach PC, ktre pozwalaj uyt kownikowi na podanie wartoci takich jak MSS, czy informacja o pocztkowym rozm ia rze okna. Niektre zaobserwowane dziwaczne wartoci mogy wic zosta wprowadzone przez uytkownikw, ktrzy nie rozumieli znaczenia ustawianych parametrw. Mimo e znalelimy 117 rnych wartoci MSS i 117 rnych pocztkowych rozmiarw okna, po zbadaniu 267 rnych kombinacji MSS i rozmiaru okna nie stwierdzilimy adnej oczywistej korelacji midzy tymi dwoma liczbami.
Opcje skali okna i znacznika czasu

RFC 1323 okrela opcje skali okna i znacznika czasu (rysunek 2.1). Spord 5386 rnych klientw 78 wysyao opcj skali okna, 23 obie opcje, natomiast aden nie wysya tylko opcji znacznika czasu. Wszystkie opcje skali okna zawieray czynnik przesunicia rwny zero (co oznacza czynnik skalujcy rwny 1, czyli rozmiar okna rwny zgoszonemu rozmiarowi okna TCP).
Wysyanie danych w segmencie SYN

Piciu klientw wysao dane w segmencie SYN, ale aden z tych segmentw SYN nie zawiera nowych opcji T/T C P. Okazao si, e kade z pocze zawierajcych takie segmenty SYN byo zgodne z tym samym schematem. Klient wysya zwy ky, nie zawierajcy danych segment SYN. Serwer odpowiada trzecim segmen tem potrjnego uzgodnienia. Okazywao si jednak, e segment ten by zagubio ny. Klient wysya wic powtrnie SYN. Wysyany powtrnie segment SYN za kadym razem zawiera rwnie dane (200 do 300 bajtw, zwyke danie HTTP).
Wyznaczanie MTU cieki

Wyznaczanie MTU cieki jest opisane w RFC 1191 [Mogul i Deering 1990] i w rozdziale 24.2 tomu 1. Moemy sprawdzi, jak wielu klientw uywa tej opcji sprawdzajc, czy segmenty SYN maj ustawiony bit DF (don't fragment, nie dzieli na fragmenty). Okazuje si, e w naszym zestawie danych 679 klientw (12,6%) stosuje wyznaczanie MTU cieki.
Pocztkowe numery sekwencyjne klienta

Zdumiewajco dua liczba klientw (troch ponad 10%) stosuje pocztkowy nu mer sekwencyjny rwny zero, co jest w jawnej sprzecznoci ze specyfikacj TCP. Okazuje si, e te implementacje klientw T C P/IP uywaj wartoci 0 dla wszyst kich aktywnych pocze. Wniosek ten wycigamy z faktu, e obserwujemy wiele pocze z rnych portw tego samego klienta w sekundowych odstpach czasu i kade z tych pocze uywa pocztkowego numeru sekwencyjnego rwnego 0. Rysunek 14.19 pokazuje jednego z takich klientw.
14.7
Powtrne wysania SYN klienta
Systemy wywodzce si z systemu Berkeley retransmituj segment SYN po 6 se kundach od wysania inicjujcego SYN i nastpnie - jeeli odpowied cigle
Sekcja 14.7
Powtrne wysania SYN klienta
207
jeszcze nie jest otrzymana (strona 860, tom 2) - po 24 sekundach. W 24-godzinnym zestawie danych mamy wszystkie segmenty SYN (z wyjtkiem zagubionych w sieci i przez program Tcpdump), moemy wic sprawdzi, jak czsto segmenty SYN s wysyane ponownie przez klientw i jakie s odstpy czasu pomidzy kolejnymi powtrzeniami wysania. W 24-godzinnym zestawie danych znajduje si 160 948 przychodzcych segmen tw SYN (rozdzia 14.3), z czego 17 680 segmentw (11%) stanowi segmenty, ktre uznajemy za duplikaty. (Liczba prawdziwych duplikatw jest mniejsza, poniewa w niektrych przypadkach odstp czasu pomidzy kolejnymi segmen tami SYN otrzymanymi z tego samego portu i hosta (adres IP) by do duy, co oznacza, e drugi segment SYN nie by duplikatem, lecz inicjowa nowe wcielenie tego samego poczenia. Nie usiowalimy pomin takich segmentw w analizie, poniewa stanowiy one niewielk cz wspomnianych 11%.) Dla segmentw SYN, ktre byy przesyane ponownie tylko raz, czas od wysania pierwszego segmentu SYN wynosi zwykle 3 ,4 lub 5 sekund. Jeeli segmenty byy retransmitowane wielokrotnie, uywany by czsto algorytm BSD: pierwsza re transmisja nastpowaa po 6 sekundach, a nastpna 24 sekundy pniej. Oznaczy m y t sekwencj jako {6,24}. Zaobserwowano te nastpujce sekwencje: (3; 6; 12; 24] {5; 10; 20; 40; 60; 60} (4; 4; 4; 4} (sprzeczne z wykadniczym algorytmem postpowania w sytuacjach awaryjnych - exponential backoff-w ym agan ym przez RFC 1122) {0,7; 1,3} (zbyt agresywne powtarzanie transmisji przez hosta, ktry oddalony jest w istocie o 20 hopw; znaleziono 20 pocze od tego hosta z retransmitowanymi segmentami SYN i we wszystkich tych poczeniach czas pomidzy kolejnymi powtrzeniami transmisji by mniejszy ni 500 ms !) {3; 6,5; 13; 26; 3; 6,5; 13; 26; 3; 6,5; 13; 26) (ten host uruchamia od nowa wykad niczy algorytm po kadych czterech powtrzeniach transmisji) (2,75; 5,5; 11; 22; 44} (21; 17; 106} (5; 0,1; 0,2; 0,4; 0,8; 1,4; 3,2; 6,4} (po pierwszym dugim oczekiwaniu postpowa nie zdecydowanie zbyt agresywne) {0,4; 0,9; 2; 4} (jeszcze jeden przesadnie agresywny klient oddalony o 19 hopw) {3; 18; 168; 120; 120; 240} Jak widzimy, pewne sekwencje s zdumiewajce. Niektre z wielokrotnie retransmitowanych segmentw SYN pochodz prawdopodobnie od hostw z bdnie okrelonymi marszrutami: hosty te mog wysya pakiety do serwera, ale nigdy nie otrzymuj odpowiedzi. Istnieje rwnie moliwo, e niektre z powtrze s daniami utworzenia nowego wcielenia wczeniejszego poczenia (na stronie 998 w tomie 2 opisano, w jaki sposb serwer BSD zaakceptuje nowe danie poczenia dla poczenia w stanie TIME_WAIT, jeeli numer sekwencyjny no wego SYN jest wikszy ni ostatni num er sekwencyjny poczenia w stanie
208
Rozdzia 14
TIME_WAIT), lecz odstpy czasu (na przykad oczywiste wielokrotnoci 3 lub 6 sekund), czyni to mao prawdopodobnym.
14.8
Nazwy domen
W cigu okresu 24-godzinnego 5386 hostw o rnych adresach IP czyo si z serwerami WWW. Poniewa Tcpdump (z flag -w) rejestruje jedynie nagwek pakietu z adresem IP, odpowiadajc nazw domeny musimy ustali pniej. W pierwszej prbie powizania adresw IP z nazwami domen przy uyciu DNS znalelimy nazwy tylko dla 4052 (75%) adresw. Dzie pniej sprbowalimy znale nazwy dla pozostaych 1334 adresw uywajc DNS - udao si to w 62 przypadkach. Oznacza to, e 23,6% klientw nie posiada poprawnego odwrotne go odwzorowania adresw IP na nazwy domen. (W rozdziale 14.5 w tomie 1 takie odwzorowania przedstawione s szerzej.) Mimo e wielu z tych klientw moe znajdowa si na kocu linii telefonicznych, ktre s wyczone przez wikszo czasu, nazwy klientw powinny by udostpniane przez serwery nazw, podsta wowe i alternatywne, poczone stale z Internetem. Uylimy programu Ping, eby sprawdzi, czy hosty bez poprawnego odwzoro wania adresu na nazw byy chwilowo niedostpne. Program Ping by urucho miony dla 1272 pozostajcych klientw natychmiast po tym, jak fiaskiem zako czyo si poszukiwanie nazwy przez DNS. Ping osign 520 hostw (41%). Pord poprawnie znalezionych nazw domen byo 57 rnych domen najwysze go poziomu (top level). Pidziesit z nich to domeny o dwuliterowych nazwach odpowiadajce innym krajom ni USA, co oznacza - nawiasem mwic - e przymiotnik wiatowa" jest dla Pajczyny waciwy.
14.9
Ograniczenie czasu sondowania trwaoci poczenia
N e t/3 nigdy nie przestaje sondowa trwaoci poczenia (persist probes). To zna czy, gdy N e t/3 otrzymuje od partnera informacje o rozmiarze okna rwn 0, kod ten wysya w nieskoczono prbki trwaoci poczenia, bez wzgldu na to, czy kiedykolwiek otrzymuje cokolwiek z drugiego koca poczenia. Stwarza to prob lem, gdy partner znika kompletnie (na przykad przerwane zostaje telefoniczne poczenie SLIP lub PPP). Przypominamy (strona 944, tom 2), e nawet gdy jaki poredniczcy ruter uywajc protokou ICMP wysya komunikat o bdzie infor mujcy, e host jest nieosigalny, TCP ignoruje taki komunikat, jeli poczenie zostao ustanowione. Jeli takie poczenia nie zostan odrzucone, TCP bdzie stale wysya prbki trwaoci co 60 sekund do nieistniejcego hosta (niepotrzebnie obciajc sie). Dodatkowo kade takie poczenie zajmuje pami hosta (TCP i odpowiednie bloki kontrolne). Kod pozwalajcy zlikwidowa ten problem, przedstawiony na rysunku 14.17, pojawia si w 4.4BSD-Lite2 i zastpuje kod na stronie 858 w tomie 2.
Sekcja 14.9___________ Ograniczenie czasu sondowania trwaoci poczenia
209
------------------------------------------------------------------------------------------------c as e T C P T _ P E R S I S T : t c p s t a t .t cp s_ p er si sttim eo + +;
tcp_timer.c
/*
* * * * *
Uwaga : jeli p a r t n e r je st m a r t w y / n i e o s i g a l n y , n ie p r z e r y w a m y wy s y a n i a , jeeli okno z o s t a j e z a mk ni t e . Po w y k o n a n i u w s z y s t k i c h c zynnoci p r z e w i d z i a n y c h dla sy tuacji a wa r yj n e j , p o c z e n i e z o s t a j e od rz u c o n e , gdy o s i g n i t y z o s t a n i e m a k s y m a l n y czas b e z c z y n n o c i (brak odpow ie d zi na prbki).
if ( t p - > t _ r x t s h i f t == T C P _ M A X R X T S H 1 F T && (t p - >t _ i d 1e >= t c p _ m a x p e r s i s t i d l e || t p - > t _ i d l e >= T C P _ R E X M T V A L ( t p ) * t c p _ t o t b a c k o f f )) { t c p s t a t .tcps_p e rs i s tdrop++; tp = t c p _ dr op ( tp , E TI MEDOUT); break; tcp_setpersist(tp); t p - > t _ f o r c e = 1; (v o i d ) t c p _ o u t p u t ( t p ) ; t p - > t _ f o r c e = 0; break:
*/
------------------------------------------------------------------------------------------------Rysunek 14.17 Poprawiony kod obsugi prbek trwaoci, wprowadzajcy ograniczenie czasu
tcpjim er.c
Nowy kod zawiera si w instrukcji i f. Zmienna t c p _ m a x p e r s i sti dl e jest nowa i zostaa zainicjowana wartoci T C P T V _ K E E P _ I D L E (14 400 psekundowych zli cze zegara, czyli 2 godziny). Zmienna t c p _ t o t b a c k o f f jest rwnie nowa i ma warto 511, co jest sum wszystkich elementw w tablicy t c p _ b a c k o f f (strona 868 w tomie 2). Wreszcie tcps_pe rsi s t drop to take nowa zmienna w strukturze t c p s t a t (strony 826-827 w tomie 2), ktra zlicza porzucone poczenia. Warto T C P _ M A X R X T S H I F T wynosi 12 i okrela maksymaln liczb retransmisji, gdy TCP czeka na ACK. Po 12 powtrzeniach transmisji poczenie zostaje odrzu cone, jeli nic nie zostao otrzymane w cigu 2 godzin lub w czasie rwnym 511 razy aktualna warto RTO dla danego partnera - w zalenoci od tego, ktra z tych dwch wartoci jest mniejsza. Na przykad, jeeli RTO wynosi 2,5 sekundy (5 zlicze zegara, co jest wartoci rozsdn), druga cz sprawdzenia OR powo duje odrzucenie poczenia po 22 minutach (2640 zlicze zegara), poniewa 2640 jest wiksze ni 2555 (5 x 511).
Komentarz w kodzie na rysunku 14.17 nie jest konieczny. W RFC 1122 stwierdza si, e TCP musi utrzym ywa poczenie w nieskoczono, nawet jeli otrzym any rozmiar okna jest 0, tak dugo jak dugo odbierajcy m odu TCP wysya potwierdzenia w odpo wiedzi na segmenty prbkujce". Odrzucenie poczenia po duszym okresie bez odpo wiedzi na prbki jest poprawne.
Przedstawiony kod zosta dodany, eby sprawdzi jak czsto opisana sytuacja ma miejsce. Na rysunku 14.18 pokazujemy, jak zmienia si warto nowego licznika w okresie 5 dni. W badanym systemie pojawiao si 90 odrzuconych pocze dziennie, czyli prawie 4 takie poczenia na godzin.
210
Rozdzia 14
wtorek poudnie
roda poudnie
czwartek poudnie
pitek poudnie
sobota poudnie
niedziela poudnie
liczba odrzuconych
czas dziaania systemu od przeadowania w minutach
Rysunek 14.18
Liczba pocze odrzuconych po czasie oczekiwania na potwierdzenie prbek trwaoci
Przyjrzyjmy si dokadniej jednemu z tych pocze. N a rysunku 14.19 przedsta wiamy szczegowy wydruk z programu Tcpdump. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0.0 0 .00 1212 0 .36 4841 0. 481275 0 .54 6304 0.546761 1.393139 1.394103 1.394587 1.582501 1.583139 1.583608 2 .85 1548 2.852214 2.852672 3.812675 5.257997 C l ient.1464 > serv.80: S 0:0(0) win 4096 <mss 1396> s ery.80 > c l i e n t .1464: S 3 23 93 01 1 3 : 3 2 3 9 3 0 1 1 3 ( 0 ) ack 1 win 409 6 <mss 512> C l i e n t . 1464 serv.80: P ack 1 win 4096 C l i e n t . 1464 > serv.80 serv.80 > c l i e n t . 1464 serv.80 > c l i e n t . 1464 c l i e n t . 1464 > serv.80 serv.80 > c l i e n t . 1464 serv.80 > c l i e n t . 1464 c l i e n t . 1464 > serv.80 serv.80 > c l i e n t . 1464 ser v.80 > c l i e n t . 1464 c l i e n t . 1464 > serv.80 serv.80 > c l i e n t . 1464 ser v.80 > c l i e n t . 1464 C l i e n t . 1464 > serv.80 C l i e n t . 1464 > serv.80 s erv .80 > c l ie nt . 1464 s erv .80 > c l i e n t . 1464 s erv .80 > c l ie nt . 1464 P 1: 183(182) ack 1 win 4096 . 1:513(512) ack 183 win 4096 P 513:1 02 5( 5 12 ) ack 183 w in 4096 FP 183:183(0) ack 513 win 3584 . 1025:15 37(512) ack 184 win 4096 . 1537:20 49(512) ack 184 win 4096 FP 183:183(0) ack 1025 win 3072 . 2049:2561(512) ack 184 win 4096 . 2561:3 073(512) ack 184 win 40 96 P ack 2049 w in 2048 . 3073:3585(512) ack 184 win 4096 . 3585:4097(512) ack 184 win 4096 P P . . . ack 3073 win 1024 ack 4097 win 0 4097:40 98 (1 ) ack 4097:40 98 (1 ) ack 4 09 7: 40 9 8( 1) ack 184 win 4096 184 win 4096 184 win 4096
(0.0012) (0.3636) (0.1164) (0.0650) (0.0005) (0.8464) (0.0010) (0.0005) (0.1879) (0.0006) (0.0005) (1.2679) (0.0007) (0.0005) (0.9600) (1.4453)
10.024936 (4.7669) (6.0104) 16.035379 28 .0 55130 (12.0198)
Sekcja 14.9___________ Ograniczenie czasu sondowania trwaoci poczenia
211
21
22 23 24
5 2 . 0 8 60 26 (24.0309) 1 00 .1 3 53 80 (48.0494) 1 60 .1 9 55 29 (60.0601) 2 20 .2 5 5 0 5 9 (60.0595)
serv.80 serv.80 serv.80 serv.80
> C l i e n t . 1464: > c l i e n t . 1464: > c l i e n t . 1464: > c l i e n t . 1464:
.4097:4 0 98 (1 ) ack 184 win
. 4097:4 09 8( 1 ) ack 184 win . 4097:4 09 8( 1 ) ack 184 win . 4 09 7: 4 09 8( 1) ack 184 w i n
4096 4096 4096 40 96
w y s y a n i e prbek trwaoci jest k o nt yn uo w an e
140 141
71 87 . 6 0 3 9 7 5 (60.0501) 7 2 4 7 .6 4 39 05 (60.0399)
serv.80 > c l i e n t . 1464: serv.80 > c l i e n t . 1464:
. 40 97 :4 0 98 (1 ) ack 184 win R 40 98 :4 0 98 (0 ) ack 184 win
4096 409 6
Rysunek 14.19 Wydruk Tcpdump: oczekiwanie na potwierdzenie prbek trwaoci W liniach od pierwszej do trzeciej widzimy zwyke potrjne uzgodnienie protoko u TCP. Pojawiaj si jednak niepoprawny pocztkowy numer sekwencyjny (0) i dziwna warto MSS. Klient wysya 182-bajtowe danie w linii czwartej. Serwer potwierdza danie w linii pitej i segment ten zawiera rwnie pierwsze 512 bajtw odpowiedzi. W linii szstej znajduje si nastpne 512 bajtw odpowiedzi. Klient wysya FIN w linii sidmej, serwer potwierdza FIN i kontynuuje wysyanie odpowiedzi - nastpne 1024 bajty - w liniach smej i dziewitej. Klient potwierdza kolejne 512 bajtw odpowiedzi serwera i przesya ponownie swoj flag FIN w linii dziesitej. Linie jedenasta i dwunasta zawieraj nastpne 1024 bajty odpo wiedzi serwera. Ten sam scenariusz powtarza si w liniach od trzynastej do pitnastej. Zauwamy, e gdy serwer wysya dane, informacja klienta o rozmiarze okna w liniach 7,10,13 i 16 zawiera coraz mniejsze wartoci, a w linii 17 osiga warto 0. Klient TCP otrzyma cznie 4096 bajtw odpowiedzi serwera w linii siedemnastej, ale - poniewa 4096-bajtowy bufor odbiorczy jest wypeniony - klient informuje, e rozmiar okna wynosi 0. Aplikacja klienta nie wczytaa adnych danych z bufora odbiorczego. Linia osiemnasta jest pierwsz prbk trwaoci poczenia, wysan przez serwe ra po okoo 5 sekundach od zerowej informacji o rozmiarze okna. Prbki trwaoci poczenia wysyane s dalej zgodnie z typowym scenariuszem pokazanym na rysunku 25.14 w tomie 2. Wydaje si, e klient straci poczenie z Internetem pomidzy liniami siedemnast i osiemnast. Zostaje wysanych cznie 124 prbek trwaoci w cigu nieco ponad 2 godzin, po czym serwer w linii 141 rezygnuje i wysya RST. (Flaga RST zostaje wysana przez tcp_d rop, strona 930, tom 2.)
Dlaczego, biorc pod uw ag przedstawione na pocztku tego podrozdziau w ytum acze nie drugiej czci warunku OR w kodzie rdowym 4.4BSD-Lite2, prbki trwaoci w omwionym przykadzie wysyane s przez 2 godziny? Kod ograniczenia czasu sprawdzania trwaoci poczenia w systemie BSD/OS V2.0, dziaajcy w m onitorowa nym komputerze, zawiera jedynie sprawdzenie czy t _ i d l e jest wiksze lub rwne t c p _ m a x p e r s i s t i d l e . D ruga cz warunku OR zostaa w p row ad zon a d op iero w 4.4BSD-Lite2. W naszym przykadzie m oemy zobaczy, dlaczego dodano drug cz warunku OR: wysyanie prbek przez 2 godziny nie m a sensu, skoro jest oczywiste, e drugi koniec poczenia znikn.
212
Rozdzia 14
Powiedzielimy, e w systemie odrzucanych byo 90 pocze dziennie, po w y czerpaniu si czasu oczekiwania na potwierdzenie prbek trwaoci. Jeli prbki takie byyby wysyane w nieskoczono, po czterech dniach mielibymy 360 takich zawieszonych" pocze, wysyajcych okoo 6 niepotrzebnych segmen tw TCP na sekund. Dodatkowo - poniewa serwer HTTP usiuje przesa dane w tych poczeniach - w kolejce wysykowej oczekuj przeznaczone do wysania bufory mbuf. W opracowaniu [Mogul 1995a] stwierdzono, e gdy klient przed wczenie przerywa poczenia TCP, mog si ujawni bdy przyczajonych serwe rw, ktre mog istotnie zmniejszy sprawno sieci". W linii sidmej na rysunku 14.19 serw er otrzymuje segm ent FIN od klienta. N a skutek tego poczenie po stronie serwera zostaje w prowadzone w stan CLOSE_WAIT. Cho nie moemy tego stwierdzi na podstawie wydruku Tcpdump, wiemy, e serwer w pewnym momencie analizowanego okresu w yw o a cl ose, wprowadzajc poczenie w stan LAST_ACK. Rzeczywicie, wikszo zawieszonych pocze wysyajcych prbki trwaoci jest w stanie LAST_ACK. W czasie gdy opisany tu problem gniazd zawieszonych w stanie LAST_ACK by dyskutowany po raz pierwszy na pocztku 1995 roku w ramach listy dyskusyjnej Usenet, zaproponowano midzy innymi, by do wykrywania znikajcych klientw i zakaczania takich pocze zostaa wykorzystana opcja rda S O _ K E E P A L I VE. (W rozdziale 23 w tomie 1 przedyskutowano, jak dziaa ta opcja, a w rozdziale 25.6 tomu 2 przedstawiono szczegy implementacji tej opcji.) Niestety, w ten sposb problem nie zostaje rozw izany. N a stronie 860 w tomie 2 opcja keepalive" nie koczy poczenia w stanach FIN_WAIT_1, FIN_WAIT_2, CLOSING lub LAST_ACK. Niektrzy dostawcy systemw podobno zmienili t waciwo opcji.
14.10
Symulacja rozmiaru tablicy rutowania T/TCP
Host, dla ktrego zaimplementowano T /T C P , tworzy wpis w tablicy rutowania dla kadego hosta, z ktrym nawizuje poczenie (rozdzia 6). Wikszo hostw przechowuje obecnie w tablicy rutowania najczciej tylko marszrut domyln i by moe najwyej kilka marszrut do konkretnych hostw, tak wic implementa cja T /T C P moe potencjalnie utworzy tablic rutowania znacznie wiksz od normalnej. Uyjemy danych z serwera HTTP, aby zasymulowa tablic rutowania T /T C P i sprawdzimy, jak rozmiar tej tablicy zmienia si w czasie. Nasza symulacja jest prosta. Uywamy danych zebranych w okresie 24-godzinnym do stworzenia tablicy rutowania dla kadego z 5386 rnych adresw IP, odpowiadajcych hostom czcym si serwerami W W W w danym komputerze. Kady wpis pozostaje w tablicy rutowania przez okrelony czas po jego uyciu. Symulacj wykonamy dla czasu utraty wanoci wpisu rwnego 30 minut, 60 minut i 2 godziny. Tablica rutowania jest przegldana co 10 minut i wszystkie wpisy starsze ni zadany okres wanoci s kasowane (podobnie do dziaania funkcji in_rtqtimo w rozdziale 6.10) oraz zliczane s te wpisy, ktre pozostaj
Sekcja 14.10
Symulacja rozmiaru tablicy rutowania T/TCP
213
w tablicy rutowania. Liczba pozostajcych wpisw pokazana zostaa na rysunku 14.20.
Rysunek 14.20
Symulacja tablicy rutowania T/TCP: liczba wpisw wfunkcji czasu
W wiczeniu 18.2 w tomie 2 wspomnielimy, e kady wpis w tablicy rutowania w kodzie N e t/3 zajmuje 152 bajty. W przypadku T /T C P rozmiar wpisu zwiksza si do 168 bajtw, gdy zostaje dodanych 16 bajtw struktury r t_me tr i cs (rozdzia 6.5) uywanych przez pami TAO. W istocie zasady alokowania pamici systemu BSD powoduj, e zajtych zostaje 256 bajtw. Dla najduszego czasu utraty wanoci rwnego 2 godziny liczba wpisw osiga niemal 1000, co odpo wiada prawie 256 000 bajtom. Zmniejszenie okresu wanoci wpisu do poowy zmniejsza zajt pami mniej wicej dwukrotnie. Przy czasie utraty wanoci rwnym 30 minut tablica rutowania zawiera maksy malnie 300 wpisw, przy 5386 rnych hostach czcych si z tym serwerem. Jest to cakowicie akceptowalny rozmiar tablicy rutowania.
Ponowne uycie wpisu w tablicy rutowania

Rysunek 14.20 informuje nas, jak dua staje si tablica rutowania przy rnych czasach utraty wanoci oraz pokazuje, jak czsto wpisy przechowywane w tabeli s ponownie uywane. Nie ma sensu przecie przechowywa wpisw, ktre bardzo rzadko s ponownie uywane.
214
Rozdzia 14
Przygldamy si 686 755 pakietom w 24-godzinnym zbiorze danych i szukamy segmentw SYN klientw, ktre pojawiaj si przynajmniej 10 minut po otrzyma niu ostatniego pakietu od danego klienta. N a rysunku 14.21 pokazany jest wykres liczby hostw w funkcji czasu braku aktywnoci w minutach. Na przykad 683 hosty (spord 5386 klientw) wysyaj nowy segment SYN po czasie braku aktywnoci rwnym 10 lub wicej minut. Ta liczba zmniejsza si do 669 hostw dla czasu braku aktywnoci 11 lub wicej minut i do 367 hostw dla czasu braku aktywnoci 120 lub wicej minut.
Rysunek 14.21
Liczba hostw wysyajcych SYN po pewnym okresie braku aktywnoci
Jeeli przyjrzymy si nazwom hostw odpowiadajcym adresom IP pojawiajcym si powtrnie po pewnym okresie braku aktywnoci, wiele z nich ma form w wwproxyl, webgatel, proxy, g a t e w a y i podobne, co oznacza, e s to serwery poredniczce (proxy) odpowiednich instytucji.
14.11
Wspdziaanie z buforami mbuf
Interesujce spostrzeenie zostao poczynione przy okazji obserwowania za po moc programu Tcpdump wymian pakietw HTTP. Jeeli aplikacja wpisuje od 101 do 208 bajtw, 4.4BSD dzieli dane na dwa bufory mbuf - pierwszy zawiera 100 bajtw, drugi pozostae 1-108 bajtw - co powoduje wysanie dwch segmentw TCP, nawet jeli warto MSS jest wiksza ni 208 (co zwykle ma miejsce). Przy czyna tej anomalii zaw arta jest w funkcji s o s e n d (strony 514-516 tom u 2). Poniewa TCP nie jest protokoem niepodzielnym (atomie protocol), za kadym
Sekcja 14.12
Blok protokou TCP i przewidywanie nagwka
215
razem gdy bufor mbuf zostaje wypeniony, wywoywana jest funkcja wyjcia protokou. Co gorsza, poniewa danie klienta zawarte jest teraz w wicej ni jednym segmencie, poczenie uruchamiane jest w trybie powolnym (powolny start). Klient zanim wyle drugi segment - wymaga, by serwer potwierdzi pierwszy segment. Cakowity czas przesania dania zostaje wic zwikszony o warto RTT. Bardzo wiele da HTTP ma rozmiar od 101 do 208 bajtw. Rzeczywicie, wszystkie dania wysane w przykadzie w rozdziale 13.4 miay wielko od 152 do 197 bajtw. Dzieje si tak dlatego, e danie klienta ma w zasadzie ustalony format, w ktrym jedynie URL zmienia si pomidzy poszczeglnymi daniami. Problem moe by usunity w atwy sposb (jeeli mamy kod rdowy jdra systemu). Warto staej M IN C LSI ZE (strona 41 w tomie 2) powinna zosta zmie niona ze 101 na 208. Wprowadzenie tej zmiany usuwa te maksimum widoczne w punkcie odpowiadajcym 200 bajtom na rysunku A.6 i A.7. Klient z rysunku 14.22 zawiera t zmian. Bez tej zmiany pierwszy segment klienta zawieraby 100 bajtw danych, nastpnie klient czekaby przez czas rwny RTT na potwierdzenie pierwszego segmentu (powolny start) i po otrzymaniu potwierdze nia wysaby pozostae 52 bajty. Dopiero wtedy serwer wysaby pierwszy seg ment odpowiedzi.
Istniej alternatywne sposoby usunicia problemu. Po pierwsze, rozm iar mbuf mgby zosta zwikszony ze 128 do 256 bajtw. W niektrych systemach wywodzcych si z systemu Berkeley wprowadzono wanie t modyfikacj (na przykad A I X ). Po drugie, m ona by zmodyfikowa funkcj s o s e n d , tak by wyjcie TCP nie byo uruchamiane wielokrotnie, kiedy uywane s struktury mbuf (a nie klastry mbuf).
14.12
Gdy TCP w kodzie N e t / 3 otrzymuje segment, TCP zachowuje wskanik do odpo wiedniego internetowego bloku (wskanik tcp_l ast_i npcb do struktury i npc b na stronie 967 w tomie 2) majc nadziej, e nastpny otrzymany segment m o e nalee do tego samego poczenia. W ten sposb omijane jest kosztowne przeszukiwanie powizanej listy blokw protokou TCP. Za kadym razem, gdy nastpny segment naley do innego poczenia, inkrementowany jest licznik t c p s _ p c b c a c h e m i ss. W przykadowym zestawie danych statystycznych ze stro ny 827 w tomie 2 niemal w 80% przypadkw segment nalea do tego samego poczenia. System, na ktrym zostay zebrane te dane, by jednak systemem oglnego przeznaczenia wykonujcym wiele funkcji jednoczenie, a nie serwerem HTTP. Wejcie TCP wykonuje rwnie przewidywanie nagwka (rozdzia 28.4 w tomie 2), gdy kolejny otrzymany segment w danym poczeniu jest nastpnym spodziewa nym potwierdzeniem (strona wysyajca dane) lub nastpnym spodziewanym segmentem danych (strona odbierajca dane).
216
Rozdzia 14
server.80
0,0
0,441223 (0,4412) 0,442067 (0,0008) 0,579457 (0,1374)
1,101392 (0,5219) 1,241115(0,1397) 1,249376 (0,0083)
1,681472 (0,4321) 1,821249 (0,1398) 1,853057 (0,0318)
j c k 2049, win
M r.A
,0 4 9:2561(512) a! l l 5 V ^ 09^ 1,960825 (0,1078) 2,048981 (0,0882)
ack 2561, winSflcw
^2561_^3073^12)_aK_153i_wn_^2B5
2,251285 (0,2023) FIN, 2,362975 (0,1117) 2,369026 (0,0061) 2,693247 (0,3242) 2,957395(0,2641) PSH 3073^3420^347)_ackJ531 _wl!Li555
13 14
^LîlwinS032^
jd (3 4 2 1 , w in flia ?
3421, win 8192 ack 1 5 V in 4 0 9 5 _ 18
3,220193 (0,2628)
Rysunek 14.22
Transakcje klient-serwer HTTP
Dla serwera HTTP omawianego w tym rozdziale stwierdzono, e: w 20% przypadkw mg by uyty przechowywany wskanik do (segment nalea do tego samego poczenia) (18-20%) w 15% przypadkw przewidywanie nagwka byo poprawne dla nastpnego potwierdzenia (14-15%) w 30% przypadkw przewidywanie nagwka byo poprawne dla nastpnego segmentu danych (20-35%).
Sekcja 14.12
217
Wszystkie trzy wartoci s niskie. Wartoci te zmieniay si nieznacznie w pomia rach wykonywanych co godzin przez okres 2 dni. Minimalne i maksymalne wartoci podano w nawiasach. Pierwsza z podanych wartoci jest niska, ale nie moe to dziwi, biorc pod uwag du liczb klientw uywajcych jednoczenie TCP dla silnie zajtego serwera HTTP. Niska warto trafie" wynika z faktu, e HTTP to w istocie protok transakcyjny, a pokazano [McKenney i Dove 1992], e efektywno wykorzystania przechowywanego wskanika w N e t/3 dla protokou transakcyjnego jest niska. Serwer HTTP zwykle wysya wicej danych ni otrzymuje. Na rysunku 14.22 przedstawione s zalenoci czasowe dla pierwszego dania klienta z rysunku 13.5 (port klienta 1114). danie klienta jest wysane w segmencie 4, a odpowied serwera w segmentach 5, 6, 8, 9, 11, 13 i 14. Istnieje tylko jedna potencjalna moliwo wykonania przewidywania nastpne dane" dla serwera - segment 4. Przewidywanie serwera nastpne potwierdzenie" jest potencjalnie moliwe dla segmentw 7, 10, 12, 15 i 16. (Poczenie nie jest nawizane, gdy przychodzi segment 3, a flaga FIN w segmencie 17 wyklucza przewidywanie dla tego segmen tu.) To, czy w istocie ktry z tych segmentw ACK kwalifikuje si do przewidy wania nagwka, zaley od zgoszonej informaq'i o rozmiarze okna, co z kolei zaley od sposobu, w jaki klient HTTP czyta dane przesane przez serwera i od tego, kiedy klient wysya ACK. W segmencie 7, na przykad, TCP potwierdza 1024 bajty otrzymane przez serwera, ale aplikacja klienta HTTP przeczytaa tylko 260 bajtw z buforu gniazda (1024 - 8192 + 7428).
To potwierdzenie z dziwn informaq' o rozmiarze okna jest opnionym potw ierdze niem, wysanym gdy upywa 200-milisekundowy okres oczekiwania TCP. Rnica czasu midzy segmentami 7 i 12 - oba te segmenty s opnionymi potwierdzeniami - wynosi 799 ms, co odpowiada czterem 200-milisekundowym zegarowym przerwaniom TCP. Wanie ta rnica czasu wiadczy o tym, e oba segmenty s opnionymi potw ierdze niami wysanymi w zwizku z przerwaniem zegarowym, a nie w wyniku odczytania innego fragmentu danych z bufora gniazda. Wydaje si, e segment 10 jest rwnie opnionym potwierdzeniem, poniewa czas pomidzy segmentami 7 i 10 wynosi 603 ms.
Segment ACK z mniejsz wartoci informacji o rozmiarze okna uniemoliwia przewidywanie nagwka na drugim kocu poczenia, poniewa przewidywa nie nagwka jest wykonywane, tylko jeeli otrzymany rozmiar okna jest rwny rozmiarowi aktualnego okna wysykowego. Podsumowujc, nie jestemy zdziwieni nisk efektywnoci kodu przewidywania nagwka w serwerze HTTP. Przewidywanie nagwka dziaa najlepiej dla po cze TCP, w ktrych wymieniane s due iloci danych. Poniewa statystyka przewidywania nagwka jest obliczana wsplnie dla wszystkich pocze TCP, moemy jedynie domniemywa, e wiksza procentowa efektywno przewidy wa typu nastpne dane" (porwnujc z przewidywaniami typu nastpne po twierdzenie") pochodzi od bardzo dugich pocze NNTP (rysunek 15.3), w ra mach ktrych otrzymywanych jest rednio 13 milionw bajtw na jedno pocze nie TCP.
218
R o z d z ia u
Bd w trybie powolnego startu

Zauwamy, e - wbrew oczekiwaniom - serwer na rysunku 14.22 wysya odpowied bez powolnego startu. Spodziewalibymy si, e serwer wyle pierw szy 512-bajtowy segment, zaczeka na ACK od klienta i nastpnie wyle kolejne dwa 512-bajtowe segmenty. Serwer jednak wysya natychmiast dwa 512-bajtowe segmenty (segmenty 5 i 6), nie czekajc na potwierdzenie. Rzeczywicie, ta anoma lia pojawia si w wikszoci systemw wywodzcych si z systemu Berkeley. Jest ona rzadko zauwaana, poniewa w wielu aplikacjach wikszo danych wysya klient do serwera. Nawet w przypadku cigania pliku od serwera przy pomocy FTP, to serwer FTP otwiera poczenie transferu danych, stajc si w rzeczywisto ci klientem tego transferu. (Na stronie 494 w tomie 1 pokazany jest przykad takiej sytuacji.) Bd tkwi w funkcji tcp_i nput. Nowe poczenie rozpoczyna si z jednosegmentowym oknem przecienia. Kiedy nawizywanie poczenia zostaje zakoczone po stronie klienta (strony 988-990 w tomie 2), wykonywany jest skok do etykiety step6, omijajcy przetwarzanie potwierdzenia. Gdy pierwszy segment danych by wysany przez klienta, okno przecienia tego segmentu wynosi jeden seg ment - i jest to poprawne. Kiedy jednak nawizywanie poczenia zostaje zako czone po stronie serwera (strona 1011 w tomie 2), kontrola jest przekazana do fragmentu kodu przetwarzajcego ACK i okno przecienia - w zwizku z otrzy manym ACK - zwiksza si o jeden segment (strona 1019, tom 2). Dlatego serwer rozpoczyna od wysania dwch podobnych segmentw. Bd mona skorygowa wczajc kod z rysunku 11.16, bez wzgldu na to, czy implementacja obsuguje T/T C P , czy nie. Kiedy serwer otrzymuje ACK w segmencie 7, okno przecienia serwera zwiksza si do trzech segmentw, ale serwer najwyraniej wysya tylko dwa segmenty (8 i 9). Na podstawie rysunku 14.22 nie moemy stwierdzi, czy segmenty 10 i 11 miny si gdzie w sieci pomidzy klientem i serwerem, poniewa rejestrowali my segmenty tylko na jednym kocu poczenia (uruchamiajc Tcpdump w komputerze klienta). Jeli to si w rzeczywistoci zdarzyo, to serwer mia trzyseg mentowe okno przecienia, tak jak tego oczekiwalimy. Na podstawie wartoci RTT wyznaczanych dla rnych segmentw, moemy domyla si, e segmenty rzeczywicie miny si w sieci. Warto RTT klienta zmierzona dla segmentw 1 i 2 wynosi 441 ms, dla segmentw 4 i 5 - 521 ms, a dla segmentw 7 i 8 - 432 ms. Wartoci te s sensowne i uywajc programu Ping w komputerze klienta otrzymujemy RTT dla tego serwera rwne 461 ms. Warto RTT dla segmentw 10 i 11 wynosi jednak duo mniej: 107 ms.
14.13
Podsumowanie
Silnie obciony serwer WWW stawia wysokie wymagania implementacji TC P/IP. Zobaczylimy, e czsto bardzo dziwne pakiety mog by otrzymywane od wielu rozmaitych klientw w Internecie.
Sekcja 14.13
Podsumowanie
219
W obecnym rozdziale przeanalizowalimy pakiety zarejestrowane w obcionym serwerze W W W , zwracajc uwag na kilka rnych waciwoci implementacji. Poczynilimy nastpujce spostrzeenia: Maksymalna czstotliwo otrzymywania segmentw SYN od klientw moe przekroczy warto redni o czynnik 8 (pomijamy patologicznie zachowuj cych si klientw). Warto rednia RTT pomidzy klientem i serwerem wynosi 445 ms, a mediana rozkadu RTT jest rwna 187 ms. Kolejka niekompletnych da pocze moe atwo zosta przepeniona przy typowych wartociach limitu przepenienia rwnych 5 lub 10. Problem polega nie na tym, e proces serwera jest zbyt zajty, ale na tym, e segmenty SYN klientw pozostaj w tej kolejce przez czas RTT. Wartoci limitu przepenienia dla obcionych serwerw W W W musz by wic duo wiksze. Powinien rwnie istnie w jdrze systemu licznik przepenie tej kolejki, tak by admini strator systemu mg stwierdzi, jak czsto kolejka ulega przepenieniu. System musi mie moliwo odrzucania pocze zawieszonych w stanie LAST_ACK i wysyajcych prbki trwaoci poczenia. Takie zawieszone po czenia pojawiaj si czsto. W wielu systemach wywodzcych si z systemu Berkeley, dania o rozmiarze od 101 do 208 bajtw le wspdziaaj z buforami mbuf (jest to typowy rozmiar dania dla wielu klientw). Zasada zachowywania wskanika do bloku stosowana w wielu systemach wywodzcych si z systemu Berkeley oraz przewidywania nagwka stosowa ne w wikszoci systemw nie maj wikszego znaczenia w przypadku obci onego serwera WWW. Podobna analiza innego obcionego serwera WWW przedstawiona zostaa w opracowaniu [Mogul 1995d].
15

15.1 Wstp
NNTP (Network News Transfer Protocol), sieciowy protok przesyania informacji, rozprowadza w sieci artykuy informacyjne (news articles) zawierajce rnego rodzaju wiadomoci. (aden z moliwych polskich odpowiednikw nie oddaje w peni znaczenia angielskiego okrelenia news", szczeglnie w kontekcie news" przesyanych w sieci Usenet. Przy braku oglnie przyjtego odpowiednika zde cydowalimy si na na uycie terminu informacje", zdajc sobie spraw, e takie tumaczenie moe budzi kontrowersje - przyp. tumacza.) NNTP jest protokoem aplikacyjnym, uywajcym TCP. Opisany zosta w RFC 977 [Kantor i Lapsley 1986]. Powszechnie zaimplementowane rozszerzenia protokou s udokumen towane w opracowaniu [Barber 1995]. RFC 1036 [Horton i Adams 1987] opisuje zawarto rnych pl nagwkw artykuw informacyjnych. Informacje sieciowe (network news) zainicjowane zostay przez listy adresowe (mailing lists) w sieci ARP ANET, a nastpnie przeksztaciy si w system informacji Usenet. Listy adresowe s wci szeroko uywane, ale biorc pod uwag ilo przesyanych wiadomoci, to przede wszystkim informacje sieciowe rozwiny si znacznie w cigu ostatniej dekady. Rysunek 13.1 pokazuje, e liczba pakietw przesyanych przez protok NNTP jest zbliona od liczby pakietw poczty elek tronicznej. W pracy [Paxson 1994a] zauwaono, e od roku 1984 ruch w sieci zwizany z przesyaniem informacji sieciowych rs jednostajnie - okoo 75% rocznie. Usenet nie jest sieci fizyczn, lecz logiczn, zaimplementowan na bazie sieci fizycznych rnych typw. Kilka lat temu popularnym sposobem rozpowszech niania informacji sieciowych byo uycie linii telefonicznych (zwykle w godzinach popoudniowych i nocnych, gdy poczenia telefoniczne s tasze). Obecnie pod staw rozpowszechniania informacji sieciowych jest Internet. (Histori Usenet szczegowo przedstawiono w rozdziale 15 ksiki [Salus 1995].) Na rysunku 15.1 schematycznie przedstawilimy typowy system rozpowszech niania informacji sieciowych. Jeden host jest serwerem informacji dla danej insty tucji i przechowuje wszystkie artykuy informacyjne na dysku. Serwer ten komu nikuje si z innymi serwerami informacji w Internecie i rne serwery przekazuj sobie wzajemnie artykuy informacyjne. Protok NNTP jest uywany do komuni kacji pomidzy serwerami. Istnieje wiele rozmaitych implementacji serwerw informacji. Popularnym serwerem unixowym jest INN (InterNetNews).
222
Rozdzia 15
sie wewntrzna instytucji
Rysunek 15.1 Schemat typowego systemu informacji sieciowych Hosty nalece do tej samej instytucji kontaktuj si z serwerem informaqi, by prze czyta artykuy informacyjne oraz by nada artykuy przeznaczone dla wybranych grup informacyjnych (newsgroups). Dla tych hostw uywamy okrelenia klient informaq'i". Klienci informacji kontaktuj si z serwerem informaq'i uywajc proto kou NNTP. Programy penice role klienta informacji, kontaktujce si z serwerem informacji w tym samym komputerze, zwykle rwnie uywaj protokou NNTP. Istniej dziesitki rozmaitych czytnikw informacji (klientw) - rnych dla r nych systemw operacyjnych uywanych w komputerze klienta. Oryginalnym unixowym klientem by program Readnews. Jego nastpc jest program Rn i wiele programw pochodnych: Rm to wersja dziaajca zdalnie, w sytuacji gdy klient i serwer znajduj si w rnych hostach; Tm oznacza threaded news" (informacje wtkowe) i jest okreleniem czytnika potraficego ledzi rne wtki dyskusji w ramach jednej grupy informacyjnej; X m to wersja Rn dla systemu X-windows. GNUS jest popularnym czytnikiem dziaajcym w rodowisku edytora Emacs. Powszechne stao si rwnie wyposaanie przegldarek WWW, takich jak Nets cape, w interfejs umoliwiajcy czytanie informacji sieciowych bez wychodzenia z przegldarki, tak e posiadanie oddzielnego czytnika informacji przestaje by konieczne. Kady klient informacji posiada inny interfejs uytkownika - przywo-
Sekcja 15.2
Protok NNTP
223
ajmy w tym miejscu mnogo rnych interfejsw uytkownika uywanych przez rozmaite czytniki poczty elektronicznej. Bez wzgldu na program klienta, wspln cech wszystkich klientw, wic programy klienta z serwerem, jest protok NNTP i ten to protok stanowi temat tego rozdziau.
15.2
Protok NNTP
NNTP uywa TCP i dobrze-znany port dla serwera NNTP m a numer 119. NNTP jest podobny do innych aplikacji internetowych (HTTP, FTP, SMTP, itd.) - w tym sensie, e klient wysya do serwera polecenia w formie cigw znakw ASCII, a serwer odpowiada liczbowym kodem odpowiedzi, po ktrym opcjonalnie nast puj dane ASCII (w zalenoci od polecenia). Linie polece i odpowiedzi s zakoczone znakami karetki i koca linii. Najprostszym sposobem zbadania protokou jest uycie klienta Telnet i poczenie si z portem NNTP hosta, w ktrym uruchomiony jest serwer NNTP. Zwykle musi my jednak poczy si z hosta-klienta znanego serwerowi, najczciej znajdujcego si w sieci tej samej instytucji. Dla przykadu, jeeli poczymy si z serwerem przez Internet z hosta w innej sieci, otrzymamy nastpujcy komunikat o bdzie:
vangogh.cs.berkeley.edu L t e l n e t n o a o . e d u n n tp Trying 140.252.1.54... C o n n e c t e d to noao .e du . E s c a p e c h a r a c t e r is A ]'. 502 You h av e no p e r m i s s i o n to talk. Goodbye. C o n n e c t i o n c lo se d by f o r e ig n host.
wydruk klienta Telnetu wydruk klienta Telnetu wydruk klienta Telnetu wydruk klienta Telnetu
Pita linia na wydruku powyej, z kodem odpowiedzi 502, pochodzi od serwera NNTP. Gdy poczenie TCP jest nawizywane serwer NNTP otrzymuje adres IP klienta i porwnuje ten adres z list adresw uprawnionych klientw. W nastpnym przykadzie czymy si z lokalnego" klienta.
s u n . t u c . n o a o . e d u % te l n e t n o a o . e d u nntp Trying 140.252.1.54.. . C o n n e c t e d to noa o .e du . E s c a p e c h a r a c t e r is A] . 200 n oa o I n t e r N e t N e w s NN RP se rv er INN 1.4 2 2 - D e c - 9 3 r eady ( p os t i n g ok).
Tym razem kod odpowiedzi jest 200 (polecenie OK) i pozostaa cz linii zawiera informacje o serwerze. Na kocu tej informacji znajduje si okrelenie posting ok", lub no posting", w zalenoci od tego, czy klient jest upowaniony do nadawania artykuw, czy nie. (Jest to kontrolowane przez administratora syste mu i zaley od adresu IP klienta.) Zauwaam y w linii odpowiedzi serwera, e jest to serwer NNRP (Network News Reading Protocol - protok czytania informaq'i sieciowych), a nie serwer INND (InterNetNews daemon - demon InterNetNews). Okazuje si, e serwer INND akceptuje danie poczenia otrzymane od klienta i nastpnie sprawdza adres IP klienta. Jeeli adres klienta zostaje zaakceptowany, ale klient nie jest jednym ze znanych dostarczycieli informacji (news feed), zamiast INND uruchamiany jest
224
NNTP - sieciowy protok przesyania informacji_____________ Rozdzia 15
serwer NNRP - zgodnie z zaoeniem, e klient chce czyta informacje, a nie dostarcza informacje do serwera. W ten sposb implementacja moe oddzieli serwera dostarczania informacji (news feed server, okoo 10 000 linii kodu C) od serwera czytania informacji (news reading server; okoo 5000 linii kodu C). Znaczenie pierwszej i drugiej cyfry numerycznego kodu odpowiedzi zostao przedstawione na rysunku 15.2. Znaczenie tych kodw jest podobne do znaczenia kodw uywanych przez FTP (strona 488, tom 1).
Odpowied 1yz 2yz 3yz 4yz 5yz xOz x1z x2z x3z x4z x8z x9z Opis Komunikat informacyjny. Polecenie poprawne. Polecenie poprawne, jak dotd. Wylij pozosta cz polecenia. Polecenie byo poprawne, nie mogto by wykonane z jakiego powodu. Polecenie nie jest zaimplementowane, jest bdne, lub pojawi si powany bd w programie. Poczenie, konfiguracja i komunikaty rnego rodzaju. Wybr grupy informacyjnej Wybr artykuu. Funkcje dystrybucyjne. Nadawanie. Niestandardowe rozszerzenia. Kontrola poprawnoci i poszukiwanie bdw.
Rysunek 15.2 Znaczenie pierwszej i drugiej cyfry trzycyfrowego kodu odpowiedzi Pierwszym naszym poleceniem wydanym serwerowi jest help, ktre powoduje wypisanie wszystkich polece znanych serwerowi.
hel p 100 Lega c o m m a n d s kodem odpowiedzi jest 100 a u t h i n f o user Na m e l p a s s Pa s sw o r d article [MessagelD|Number] bo d y [ M e s s a g e l D | N u m b e r ] d at e gr o u p n e w s g r o u p head [ M e s s a g e I D | N u m b e r ] hel p i have 1 ast list [a c t i v e | n e w s g r o u p s | d i s t r i b u t i o n s | s c h e m a ] 1 i st g r o u p n e w s g r o u p m o d e r eader n e w g r o u p s y y m m d d hh mmss ["GMT"] [ < d i s t r i b u t i o n s > ] n e w n ew s n e w s g r o u p s y y m m d d hhmmss ["GMT"] [ < d i s t r i b u t i o n s > ] next post slav e st at [ M e s s a g e l D | N u m b e r ] xgtitle [group_pattern] xhdr header [ rang|MessagelD] x o v e r [rang] x pa t h e ad er r a n g e | M e s s a g e I D pat [ m o r e pa t .. .] x pa t h xp a t h M e s s a g e l D R ep or t pr ob l e m s to < u s e n e t @ n o a o .edu
linia zawierajca tylko kropk koczy odpowied serwera
Sekcja 15.2
Protok NNTP
225
Poniewa klient nie wie, ile linii bdzie zawieraa odpowied serwera, protoko wymaga, by serwer zakoczy odpowied lini zawierajc jedynie kropk. Jeeli jaka linia odpowiedzi zaczyna si od kropki, serwer poprzedza kropk jeszcze jedn kropk, a klient usuwa dodatkow kropk po odebraniu linii. Nastpne nasze polecenie to 1 i s t, ktre - jeli jest wydane bez adnych argumen tw - wypisuje nazwy wszystkich grup informacyjnych wraz z numerem ostatnie go artykuu w grupie, numerem pierwszego artykuu w grupie oraz symbolem y" lub m ", w zalenoci od tego, czy wysyanie artykuw do danej grupy jest dozwolone i czy grupa jest moderowana.
list 215 N e w s g r o u p s in f o r m " gr o up high Iow flags" . a l t . a c t i v i s m 0 0 0 0 1 1 3 9 7 6 13444 y a l t . a q u a r i a 0 0 0 0 0 5 0 1 1 4 44 7 8 2 y c o m p .p r o t o c o l s .t cp -i p 0 0 0 0 0 4 3 8 3 1 4128 9 y c o m p . s e c u r i t y . a n n o u n c e 0 0 0 0 0 0 0 1 4 1 00 117 m rec.skiing.alpine 0000025451 03612 y r e c . s k i i n g . n o r d i c 0 0 0 0 0 0 7 5 4 1 0150 7 y kodem odpowiedzi jest 215 opuszczamy wiele linii opuszczamy wiele linii linia zawierajca tylko kropk koczy odpowied serwera
Tak jak poprzednio, 215 jest kodem odpowiedzi, a nie liczb grup informacyjnych. W tym przykadzie serwer wypisuje 4238 nazw grup informacyjnych i zostaje przy tym przesanych 175 833 bajtw od serwera do klienta. Ominlimy niemal wszystkie (z wyjtkiem szeciu) linie z nazwami grup. Przesana lista grup nie jest zwykle uporzdkowana alfabetycznie. ciganie z serwera takiej listy przez powoln lini telefoniczn czsto moe powodowa znaczce opnienie przy uruchamianiu klienta informacji siecio wych. Na przykad, zakadajc szybko przesyania danych rwn 28 800 bitw na sekund, cignicie listy z przedstawionego przykadu zajmie okoo 1 minuty. (W rzeczywistoci czas zmierzony przy uyciu modemu o podanej szybkoci, kompresujcego rwnie dane, wynis 50 sekund.) W Ethernecie zajmuje to mniej ni 1 sekund. Polecenie gr o u p powoduje, e wybrana grupa staje si grup aktualn" dla danego klienta. Polecenie przedstawione poniej wybiera grup c o m p . p r o t o col s .tcp - i p jako aktualn.
group comp.protocols.tcp-ip 211 181 4 1 28 9 43 831 c o m p . p r o t o c o l s . t c p - i p
Serwer odpowiada kodem 211 (polecenie OK), po ktrym nastpuje przybliona liczba artykuw w grupie (181), numer pierwszego artykuu w grupie (41289), numer ostatniego artykuu w grupie (43831) oraz nazwa grupy. Rnica pomidzy numerem ostatniego i pierwszego artykuu (43831 - 41289 = 2542) jest czsto wiksza ni liczba artykuw (181). Jedn z przyczyn jest to, e niektre artykuy, w szczeglnoci grupy FAQ (Frequently Asked Questions - czsto zadawane pyta nia) maj duszy okres wanoci (na przykad 1 miesic) ni wikszo artykuw (czsto kilka dni, w zalenoci od pojemnoci dysku serwera). Artykuy mog by
226
Rozdzia 15
rwnie kasowane wybirczo, co oczywicie te zmienia liczb artykuw w gru pie. damy teraz, uywajc polecenia head, by serwer przesa linie nagwkw jednego wybranego artykuu (o numerze 43814, w tym przykadzie).
h ea d 4 3 8 1 4 221 43 8 1 4 < 3 v t r j e $ o t e @ n o a o . e d u > head Path: n o a o ! r s t e v e n s From: r s t e v e n s @ n o a o . e d u (W. Rich a rd St evens) N e w s g r o u p s : c o m p .protocol s .tcp - i p S ub je ct : Re: IP Mapper: Us ing RAW so ck e ts ? Date: 4 Aug 1995 19 :1 4 : 5 4 GMT O r g a n i z a t i o n : National Optical A s t r o n o m y O b s e r v a t o r i e s . Lines: 29 Message-ID: <3vtrje$ote@noao.edu> References: <3vtdhb$jnf@oclc.org> N N T P - P o s t i n g - H o s t : gemini . t u c. no ao . ed u
Tucson,
AZ, USA
Pierwsza linia odpowiedzi zaczyna si kodem 221 (polecenie OK), po ktrej nast puje 10 linii nagwka i linia zawierajca tylko kropk.
Wikszo pl nagwka nie wym aga wyjanie, ale zagadkowy wygld maj identyfika tory komunikatw. INN usiuje wygenerowa jednoznaczny identyfikator komunika tu w nastpujcym formacie: aktualny czas, znak dolara, identyfikator procesu , znak at" (tzw. mapa) i pena nazwa lokalnego hosta. Czas i identyfikator procesu s wartociami liczbowymi zapisanymi w kodzie radix-32: warto liczbowa jest zamieniona na 5-bitowy symbol ikady taki symbol drukowany jest przy uyciu znakw alfabetu: 0...9a...v.
Nastpnie podajemy polecenie body z tym samym numerem artykuu, co powo duje przesanie treci artykuu.
bo d y 43 8 1 4 222 4 3 81 4 < 3 v t r j e $ o t e @ n o a o .e d u > bo dy > My g r o u p is l o ok in g at i m p l e m e n t i n g an IP addre ss m a p p e r on a UNIX 28 linii artykuu zostao opuszczonych
Linie nagwka wraz z treci artykuu m og by cignite przy pomocy jednej komendy, a rti cl e, ale wikszo klientw informacji ciga najpierw nagwki, dajc uytkownikowi okazj do wybrania artykuw na podstawie ich tematw (subject), a nastpnie cignita zostaje tre tylko tych artykuw, ktre zostay wybrane przez uytkownika. Poczenie z serwerem zakaczamy przy pomocy polecenia qui t.
qui t 205 C o n n e c t i o n c l o s e d by f o r e i g n host.
Odpowiedzi serwera jest kod liczbowy 205. Nasz klient Telnet informuje, e serwer zamkn poczenie. Cay przedstawiony dialog midzy klientem i serwerem odbywa si przy uyciu jednego zainicjowanego przez klienta poczenia TCP. Wikszo danych przesy anych jest jednak od serwera do klienta. Czas trwania poczenia oraz ilo przesanych danych zaley od tego, jak dugo uytkownik czyta informacje.
Sekcja 15.3
Prosty klient informacji
227
15.3
Prosty klient informacji
Obserwujemy teraz wymian polece NNTP i odpowiedzi w czasie krtkiej sesji, uywajc przy tym prostego klienta informacji - Rn. Rn to jeden z najstarszych czytnikw informacji. Wybralimy ten program, poniewa jest on prosty do obser wacji i poniewa posiada opcj ledzenia dziaania programu - debug (opcja linii polecenia -Dl6 , zakadajc e klient by skompilowany z opcj umoliwiajc ledzenie dziaania programu). Dziki temu moemy obserwowa wydane pole cenia NNTP jednoczenie z odpowiedziami serwera. Polecenia klienta oznaczamy pogrubionym drukiem. 1. Pierwszym poleceniem jest l i s t , ktre - jak widzielimy w poprzednim pod rozdziale - spowodowao wysanie przez serwera okoo 175 000 bajtw; jedna linia dla kadej grupy informacyjnej. Rn przechowuje w pliku .newsrc (w macierzystym katalogu uytkownika) spis grup informacyjnych, ktre uytkownik chce czyta, wraz z list numerw przeczytanych artykuw. Na przykad jedna linia pliku .newsrc zawiera:
c o m p . p r o t o c o l s .t c p - i p : 1-43 0 15
Porwnujc zapisany w pliku numer ostatniego artykuu z danej grupy z numerem ostatniego artykuu podanym przez polecenie list, klient stwier dza, czy dana grupa zawiera nieczytane artykuy. 2. Nastpnie klient sprawdza, czy zostay stworzone jakie nowe grupy informa cyjne.
N E W S G R O U P S 9 5 0 8 0 3 1 9 2 7 0 8 GMT 231 New n e w s g r o u p s fol Iow.
231 jest kodem odpowiedzi
W pliku . rnl ast w katalogu macierzystym uytkownika Rn zapisuje czas, w ktrym otrzyma ostatni informacj o nowej grupie informacyjnej. Ten czas zostaje podany jako argument polecenia newsgroups. (Warto zaznaczy, e due i mae litery nie s rozrniane w poleceniach NNTP i w argumentach tych polece.) W naszym przykadzie w pliku . rnl ast zapisany by czas: August 3,1995,19:27:08 GMT. Odpowied serwera jest pusta (nie ma adnych linii midzy lini z kodem odpowiedzi 231, a lini zawierajc jedynie kropk), co oznacza, e nie ma nowych grup informacyjnych. Gdyby pojawiy si nowe grupy, klient mgby zapyta uytkownika, czy naley si zapisa do grupy, czy nie. 3. Rn wywietla nastpnie liczb nieczytanych artykuw w piciu pierwszych grupach i pyta, czy chcemy czyta artykuy z pierwszej grupy, comp.protocols.tcp-ip. Odpowiadamy znakiem rwnoci, co powoduje wywietlenie przez Rn jednoliniowego podsumowania wszystkich artykuw w grupie. Ma my wtedy szans wybra artykuy, ktre chcemy przeczyta. (Moemy okreli konfiguracj Rn w pliku . rn i n i t, tak by w podsumowaniu wywietlane byy dowolnie wybrane informacje dla kadego artykuu. W konfiguracji przyjtej przez autora wywietlane s: numer artykuu, temat, liczba linii w artykule
228
i nadawca artykuu.) Rn wydaje polecenie gro up i grupa zostaje uznana za grup aktualn.
GROUP comp.protocols.tcp-ip 211 182 4 1 2 89 4 3 83 2 c o m p . p r o t o c o l s . t c p - i p
Zostaj cignite nagwek i tre pierwszego nieczytanego artykuu:

A R T I C L E 438 15 220 4 3 8 1 5 < 3 v t q 8 o $ 5 p l @ n e w s f 1a s h .c o n c o r d i a .c a > a r t i c l e artyku nie jest pokazany
Jednoliniowe podsumowanie pierwszego nieczytanego artykuu jest wywiet lane na ekranie. 4. Zostaje wydane polecenie x h d r, a nastpnie h e a d dla kadego z 17 pozostaych nieczytanych artykuw w tej grupie informacyjnej. Na przykad:
X H D R s u b j e c t 43816 221 s u b j e c t f ields f ollow 4 3816 Re: RIP-2 and m e s sy s ub - n e t s H E A D 43 8 1 6 221 4 3 8 1 6 < 3 v t q e 3 $ c g b @ x a p . x y p l e x . c o m head 14 linii nagwkw nie zostao pokazanych
Polecenie xhdr moe zaakceptowa nie tylko pojedynczy numer artykuu, ale rwnie zakres numerw artykuw i dlatego odpowied serwera skada si ze zmiennej liczby linii i jest zakoczona lini zawierajc tylko kropk. Jednoli niowe podsumowanie kadego artykuu wywietlane jest na ekranie. 5. Wciskamy klawisz spacji, wybierajc w ten sposb pierwszy nieczytany arty ku. Wydane zostaje polecenie head, po ktrym nastpuje polecenie a rti cl e. Artyku zostaje wywietlony na ekranie. Przy przechodzeniu do kolejnych artykuw powtarzana jest sekwencja tych dwch polece. 6. Po zakoczeniu czytania artykuw z aktualnej grupy i przejciu do nastpnej zostaje wysane przez klienta kolejne polecenie group. damy wywietlenia jednoliniowego podsumowania wszystkich nieczytanych artykuw i opisana przed chwil sekwencja polece zostaje powtrzona dla nowej grupy. Pierwsz rzecz, ktr zauwaamy jest .to, e klient Rn wydaje zbyt wiele polece. Na przykad, chcc otrzyma jednoliniowe podsumowanie wszystkich nieczyta nych artykuw, Rn wydaje polecenia xhd r - by cign temat artykuu, a nastp nie head - by cign cay nagwek. Pierwsze z tych dwch polece mogoby by pominite. Pewnym wytumaczeniem takich nadliczbowych polece jest fakt, e klient ten zosta oryginalnie napisany z myl o pracy w komputerze, ktry by jednoczenie serwerem informacji, bez potrzeby uywania NNTP. Tak wic do datkowe komendy byy szybkie", nie wymagay przesania pakietw w obie strony. Moliwo zdalnej wsppracy z serwerem przy uyciu NNTP zostaa opracowana pniej.
Sekcja 15.4
Bardziej skomplikowany klient informacji
229
15.4
Bardziej skomplikowany klient informacji
Przyjrzyjmy si teraz bardziej skomplikowanemu klientowi informacji, przegl darce W W W Netscape w wersji 1.1N, ktra posiada wbudowany czytnik informa cji. Ten klient nie ma opcji ledzenia dziaania programu, wic - by stwierdzi, jakie czynnoci s wykonywane - ledzilimy pakiety TCP wymieniane pomidzy przegldark a serwerem informacji. 1. Gdy uruchamiamy klienta i wybieramy funkcj czytania informacji siecio wych, klient czyta nasz plik . n ew s r c i pyta serwera tylko o grupy informacyj ne, ktre prenumerujemy. By okreli pocztkowe i kocowe numery artyku w, dla kadej takiej grupy wydane zostaje polecenie group. Numery te s porwnywane z numerem ostatniego czytanego artykuu w pliku .newsrc. W naszym przykadzie autor zaprenumerowa tylko 77 spord ponad 4000 grup informacyjnych, polecenie gr oup wysane jest wic do serwera 77 razy. Zajmuje to tylko 23 sekundy w poczeniu przez lini telefoniczn z PPP, co mona porwna z 50 sekundami potrzebnymi na wykonanie polecenia l i s t uywanego przez Rn. Zmniejszenie liczby grup z 4000 do 77 powinno znacznie bardziej zredukowa czas wykonania polece ni do 23 sekund. Rzeczywicie, wysanie tych samych 77 polece g r o up do serwera uywajc funkcji s o c k (dodatek C tomu 1) zajmu je tylko 3 sekundy. Wydaje si, e przegldarka jednoczenie z wysyaniem tych 77 polece wykonuje inne czynnoci inicjujce. 2. Wybieramy jedn grup zawierajc nieczytane artykuy, comp. p r o t o col s .tcp - i p. Wydane zostaj nastpujce dwa polecenia:
gr o u p c o m p . p r o t o c o l s . t c p - i p 211 181 4 1 2 89 43831 c o m p . p r o t o c o l s . t c p - i p xo v e r 4 3 8 1 5 - 4 3 8 3 1 224 data fo llows 4 3 8 1 5 \ t p i n g w or k s but n e t s c a p e is f 1a k y \ t r o o t @ P R 0 B L E M _ W I T H _ I N E W S _ D 0 M A I N _FILE (r o o t ) \ t 4 Aug 1995 1 8 : 5 2 : 0 8 G M T \ t < 3 v t q 8 o $ 5 p l @ n e w s f 1 a s h . c o n c o r d i a . ca > \ t \ t l 2 0 2 \ t l 3 4 3 8 1 6 \ t R e : help m e to s el ec t a terminal s e r v e r \ t g v c n e t @ h n t p 2 .hin e t . n e t (g v c n e t )\t 5 Aug 1995 0 9 : 3 5 : 0 8 G M T \ t < 3 v v e 0 c $ g q 5 @ s e r v .hi net .net>\t<cl_aude. 807 537 607@ba u v 111 \ 1 1 5 0 3 \ 1 23
jednoliniowe podsumowanie pozostaych artykuw
Pierwsze polecenie ustanawia aktualn grup, drugie oznacza danie w y wietlenia podsumowania wyszczeglnionych artykuw. Pierwszym nieczytanym artykuem jest artyku 43 815, a ostatnim artykuem w grupie jest 43 831. Jednoliniowe podsumowanie kadego artykuu skada si z: numeru artykuu, tematu, autora, czasu i daty, identyfikatora komunikatu, identyfikatorw ko munikatw odpowiadajcych artykuom, do ktrych odnosi si aktualny arty ku, liczby bajtw i liczby linii. (Zauwamy, e jednoliniowe podsumowanie kadego artykuu jest dugie, przedstawiamy je wic w paru liniach. Zastpili my rwnie przez symbol \ t znaki tabulacji, oddzielajce poszczeglne pola, po to by znaki te byy widoczne.)
230
Klient Netscape porzdkuje otrzymane podsumowania wedug tematw i przedstawia list tematw nieczytanych artykuw wraz z nazwiskiem (na zw) autora i liczb linii. Artykuy i odpowiedzi na te artykuy s zebrane razem, co nazywane jest uporzdkowaniem wtkowym ( threading), poniewa ze brane zostaj artykuy omawiajce jeden wtek dyskusji. 3. Dla kadego wybranego artykuu zostaje wydane polecenie a r t i c l e i artyku zostaje wywietlony. Wida z tego krtkiego opisu, e klient informacji Netscape optymalizuje czytanie grup informacyjnych na dwa sposoby, zmniejszajc czas oczekiwania uytkowni ka na wywietlenie danych informacji. Po pierwsze, Netscape ciga tylko gru py, do ktrych uytkownik jest zapisany, zamiast wykonywa polecenie list. Po drugie, podsumowanie jest dostarczane przy pomocy polecenia xover, zamiast polece h e a d i x h d r wydawanych dla kadego artykuu w grupie.
15.5
Statystyka NNTP
Zbadalimy typowy sposb uycia NNTP, rejestrujc w tym samym komputerze, ktrego dziaanie byo analizowane w rozdziale 14, wszystkie segmenty SYN, FIN i RST uywane przez NNTP. Host ten otrzymuje grupy informacyjne od jednego dostawcy informacji (istniej zwykle serwery penice rol alternatywnego do stawcy, ale wszystkie zarejestrowane segmenty pochodziy z jednego rda) i do starcza informacje dziesiciu innym hostom. Tylko dwa spord tych dziesiciu hostw uywaj NNTP, pozostaych 8 uywa UUCP. Tak wic dane zebrane przy pomocy Tcpdumpt zawieraj tylko segmenty wysyane do dwch hostw NNTP. Tylko niewielka cz otrzymywanych informacji jest przekazywana do tych dwch hostw. Wreszcie, poniewa host peni rol dostawcy usug interneto wych, wielu klientw czyta informacje traktujc naszego hosta jako serwera NNTP. W szyscy uytkownicy czytajcy informacje uywaj NNTP - dotyczy to zarwno procesw uruchamianych w tym samym komputerze, jak i czytnikw informacji w innych komputerach, zwykle podczonych przez cza PPP lub SLIP. Tcpdump uruchomiony zosta na okres 113 godzin (4,7 doby), podczas ktrych zarejestrowanych zostao 1250 pocze. Zebrane dane zostay podsumo wane na rysunku 15.3. Przede wszystkim zauwaamy, e host otrzymuje okoo 186 milionw bajtw dziennie, co odpowiada 8 milionom bajtw na godzin. Zauwaamy te, e typo we poczenie NNTP z podstawowym dostawc informacji trwa przez dugi czas - 100 minut, w trakcie ktrych przesyanych jest 13 milionw bajtw. Po okresie braku aktywnoci w poczeniu pomidzy naszym hostem a dostawc informacji poczenie zostaje zamknite przez serwera informacji. Poczenie jest pniej nawizywane ponownie, w miar potrzeb.
Sekcja 15.6
Podsumowanie
231
Przyjmowanie informacji (od jednego hosta) liczba pocze liczba odbieranych bajtw (cznie) liczba wysyanych bajtw (cznie) cakowity czas trwania (minuty) liczba odbieranych bajtw na jedno poczenie liczba wysyanych bajtw na jedno poczenie redni czas trwania poczenia 67 875 345 619 4 071 785 6 686 13 064 860 60 773 100
Wysyania informacji (do dwch hostw) 32 4499 1 194 086 407 141 37 315 13
Czytniki informacji
Suma
1 151 593 731 56488 715 21 758 516 49 078 19
1 250 875 943 849 61 754 586 28 851
Rysunek 15.3 Statystyka pocze NNTP jednego hosta zebrana w cigu 4,7 doby Typowy czytnik informacji uywa poczenia NNTP przez 19 minut, czytajc okoo 50 000 bajtw informacji. Ruch w poczeniach NNTP jest przewanie jednokierunkowy: od podstawowego dostawcy informacji do serwera i od serwe ra do czytnikw informacji. Rnice pomidzy poszczeglnymi instytucjami i wzami rozpowszechniania informacji sieciowych - jeli chodzi o objto danych przesyanych przez NNTP s bardzo due. Przedstawiona statystyka powinna by traktowana jako przykad - nie ma typowych wartoci dla tego rodzaju danych.
15.6
Podsumowanie
NNTP jest kolejnym przykadem prostego protokou uywajcego TCP. Klient wydaje polecenia ASCII (serwer rozpoznaje okoo 20 rnych polece), a serwer przesya liczbowy kod odpowiedzi, po ktrym nastpuje jedna lub wicej linii odpowiedzi zakoczonych jedn lini zawierajc tylko kropk (jeeli odpowied moe mie zmienn dugo). Podobnie jak wiele innych protokow interneto wych, protok NNTP pozostaje niezmieniony od lat, ale klient obsugujcy inter akcyjnego uytkownika zmienia si bardzo szybko. Wiele rnic pomidzy rnymi czytnikami informacji sieciowych zwizanych jest ze sposobem uycia protokou przez aplikacj. Widzielimy rnice pomidzy klientami Rn i Netscape - czytniki te w inny sposb okrelaj, ktre artykuy nie byy czytane i inaczej cigaj nieczytane artykuy. NNTP uywa jednego poczenia TCP dla caej wymiany pakietw pomidzy klientem i serwerem. Mamy tu do czynienia z inn sytuacj ni w przypadku HTTP, kiedy do przesania kadego pliku uywane byo oddzielne poczenie TCP. Rnica ta wynika midzy innymi z faktu, e klient NNTP komunikuje si z jednym serwerem, podczas gdy klient HTTP czy si z wieloma rnymi serwe rami. Zobaczylimy rwnie, e wikszo danych w poczeniu NNTP jest prze syanych jednokierunkowo.
16

16.1 Wstp
Protokoy domeny unixowej s form komunikacji midzyprocesowej - IPC (inerprocess communication), dostpn przy pomocy tego samego interfejsu API gniazd co interfejs uywany do komunikacji sieciowej. W lewej czci rysunku 16.1 przed stawiono programy klienta oraz serwera napisane z uyciem gniazd i komuniku jce si w jednym komputerze za porednictwem protokow internetowych. Programy klienta i serwera przedstawione w prawej czci rysunku, uywaj gniazd i protokow domeny unbcowej.
host
host
Rysunek 16.1 Programy klienta oraz serwera uywajce protokow internetowych i protokow domeny unixowej Gdy klient wysya dane do serwera uywajc TCP, dane s najpierw przetwarzane przez wyjcie TCP, nastpnie przez wyjcie IP, program obsugi ptli zwrotnej (rozdzia 5.4 w tomie 2), gdzie dane s umieszczane w kolejce wejciowej IP, nastpnie s przetwarzane przez wejcie IP, wejcie TCP i ostatecznie dochodz do serwera. Procedura taka dziaa poprawnie i nie ma to znaczenia, e klient i serwer znajduj si w jednym komputerze. Pojawiajce si przy opisanym postpowaniu intensywne przetwarzanie w stosie protokou T C P /IP nie jest jednak niezbdne, gdy dane nigdy nie opuszczaj jednego komputera.
234
Rozdzia 16
Protokoy domeny unixowej wykonuj mniej czynnoci (to znaczy s szybsze), poniewa wiadomo, e dane nie opuszczaj komputera. Nie ma koniecznoci obliczania sumy kontrolnej, nie istnieje moliwo, eby dane zostay otrzymane w nieprawidowej kolejnoci, kontrola przepywu danych jest uproszczona, ponie wa jdro moe kontrolowa dziaanie obu procesw, itd. Cho inne formy IPC (kolejki komunikatw - message queues, pami wsplna - shared memory, potoki z nazwami - named pipes, itd.) maj podobne cechy, gwn zalet protokow unbcowych jest to, e uywaj one tego samego co aplikacje sieciowe interfejsu gniazd: klient wywouje connect, serwer wywouje l i s t e n i a c c e p t , klient i ser wer uywaj r e a d i w r i t e , itd. Inne formy IPC uywaj zupenie innych interfej sw API, niektre z tych interfejsw nie wspdziaaj dobrze z gniazdami i inny mi formami I /O (na przykad nie moemy uywa funkcji sel e c t z kolejkami komunikatw w Systemie V).
Niektre implementacje T C P /IP usiuj poprawi sprawno dziaania przez w prow a dzenie rnego rodzaju optymalizaji, takich jak ominicie obliczania i sprawdzania sum y kontrolnej TCP, gdy pakiety przeznaczone s dla interfejsu ptli zwrotnej.
Protokoy domeny unixowej udostpniaj zarwno gniazdo strumieniowe (stream socket - S O C K _ S T R E A M - podobne do strumienia bajtw w TCP), jak i gniazdo datagramw (datagram socket - S O C K _ D G R A M - podobne do datagramw UDP). Rodzin adresow (address family) dla gniazda domeny unixowej jest AF_U NIX. Nazwy uywane do identyfikacji gniazd domeny unixowej maj form nazw cieek w systemie plikw. (Protokoy internetowe do identyfikacji gniazd TCP i UDP uywaj kombinacji adresu IP i numeru portu.)
W standardzie IEEE POSIX 1003.1 g , rozwijanym na potrzeby program ow ania sieciowych interfejsw API, uwzgldniono obsug protokow domeny unixowej pod nazw local IPC". Rodzin adresow jest AF _L 0CAL, rodzin protokow jest PF_L0CAL. Termin U nix" okrelajcy te protokoy moe straci aktualno.
Protokoy domeny unixowej mog rwnie stworzy moliwoci nie istniejce w IPC pomidzy rnymi maszynami. Przykadem takiej moliwoci jest przeka zywanie deskryptorw pomidzy niezwizanymi procesami poprzez gniazdo do meny unixowej, co opisujemy w rozdziale 18.
16.2
Zastosowania
Lista aplikacji uywajcych protokow domeny unixowej jest duga: 1. Potoki (pipes). W jdrach wywodzcych si z systemu Berkeley potoki s zaim plementowane przy pomocy strumieniowych gniazd domeny unixowej. W rozdziale 17.3 omawiamy implementacj odwoania systemowego pi pe. 2. X Window System. Klient X II wybiera protok w momencie, gdy czy si z serwerem X II, w zalenoci od wartoci zmiennej systemowej D I S P L A Y lub wartoci argumentu linii polecenia -display. Warto ta ma form hostname:display.screen, gdzie nazwa hosta (hostname) jest opcjonalna, warto domy
Sekcja 16.3
Szybko dziaania
235
lna to aktualny, lokalny host, a uyty protok to najbardziej efektywna forma komunikacji. Dla lokalnego klienta zwykle wybierany jest strumieniowy proto k domeny unixowej. Warto un i x wymusza uycie protokou domeny unixowej. Nazwa zwizana z gniazdem unixowym m a posta zblion do
/tm p/.X l l - u n i x / X O .
Poniewa serwer X zwykle obsuguje jednoczenie klientw podczonych przez sie i klientw w tym samym komputerze, serwer oczekuje na dania pocze pojawiajce si w gniazdach TCP oraz w unixowych gniazdach stru mieniowych. 3. Program y odpowiedzialne za drukowanie (print spooler) w systemie BSD (klient 1 pr i serwer 1 pd, opisane szczegowo w rozdziale 13 ksiki [Stevens 1990]) komunikuj si w ramach jednego hosta uywajc gniazda domeny unbcowej zwanego /dev/lp. Podobnie jak serwer X, serwer lpd obsuguje poczenia z klientami w tym samym komputerze uywajc gniazda u rn o w e go, a poczenia z klientami sieciowymi - uywajc gniazda TCP. 4. Programy rejestracji zdarze systemowych (system logger) - funkcja bibliotecz na sysl og, ktra moe by wywoana przez dowoln aplikacj, oraz serwer sysl ogd - komunikuj si lokalnie uywajc datagramowego gniazda domen unixowych o nazwie / dev/1 og. Klient wpisuje komunikat do tego gniazda, a serwer czyta i przetwarza ten komunikat. Serwer obsuguje rwnie, uywa jc gniazda UDP, komunikaty od klientw w innych hostach. Wicej szczeg w na ten temat mona znale w rozdziale 13.4.2 ksiki [Stevens 1992], 5. Demon InterNetNews (i nnd) tworzy unixowe gniazdo datagramowe, w kt rym czyta komunikaty kontrolne, oraz unixowe gniazdo strumieniowe, w kt rym czyta artykuy z lokalnego serwera informacji. Gniazda te zwane s cont roi oraz nntpi n i znajduj si zwykle w katalogu /va r/news/run. Powysza lista nie jest kompletna: istniej inne aplikacje uywajce gniazd dome ny unbcowej.
16.3
Szybko dziaania
Interesujce bdzie porwnanie szybkoci dziaania gniazd domeny unbcowej i gniazd TCP. Jedna z wersji publicznie rozpowszechnianego programu t t c p zo staa zmodyfikowana, tak by oprcz gniazd TCP i UDP byo uywane strumienio we gniazdo domeny unbcowej. Przesyamy 16 777 216 bajtw pomidzy dwiema kopiami tego samego programu dziaajcymi w jednym komputerze. Wyniki przedstawiamy na rysunku 16.2.
236
Rozdzia 16
Jdro
TC P (najszybszy) (bajty/sek.)
Domena unixowa (bajty/sek.)
Wzgldny wzrost szybkoci TCP-Unix (%) 114 137 120 26 148
DEC 0SF/1 V3.0 SunOS 4.1.3 BSD/OS V1.1 Solaris 2.4 AIX 3.2.2
14980 000 4877000 3459 000 2 829 000 1 592 000
32109000 11 570000 7 626 000 3 570000 3 948 000
Rysunek 16.2 Pornmanie szybkoci dziaania gniazda domeny unixowej i TCP Przy porwnaniu gniazda TCP i gniazda domeny unixowej istotny jest wzgldny przyrost szybkoci, a nie absolutna szybko przesyania danych. (Testy zostay przeprowadzone w piciu rnych systemach, z procesorami o znaczco rnych szybkociach przetwarzania. Porwnywanie szybkoci wyszczeglnionych w r nych rzdach tabeli jest wic pozbawione sensu.) Jdra wszystkich systemw, z wyjtkiem Solaris 2.4, wywodz si z systemu Berkeley. Widzimy, e w syste mach wywodzcych sie z systemu Berkeley gniazda domen unixowych s dw u krotnie szybsze ni gniazda TCP. Wzgldna rnica jest mniejsza dla systemu Solaris.
Solaris i system SVR4, z ktrego wywodzi si Solaris, maj cakowicie inn implementacj gniazd domeny unixowej. Rozdzia 7.5 ksiki [Rago 1993] zawiera przegld opartej na strumieniach implementacji gniazd domen unixowych w systemie SVR4.
W przedstawionych testach termin najszybszy TCP" oznacza, e testy byy w y konane z rozmiarami buforw wysykowych i odbiorczych rwnymi 32 768 (co jest wartoci wiksz ni domylne rozmiary buforw w niektrych systemach), a adres interfejsu ptli zwrotnej by podany jawnie, zamiast wasnego adresu IP hosta. We wczeniejszych implementacjach BSD - jeeli podawany by wasny adres IP hosta - pakiet by wysyany do interfejsu ptli zwrotnej dopiero po wyko naniu kodu ARP (strona 31 tomu 1). Zmniejszao to szybko dziaania gniazda (i dlatego w testach podawano bezporednio adres interfejsu ptli zwrotnej). Takie hosty maj w tablicy rutowania wpis do lokalnej sieci, ktrej interfejsem jest program obsugi sieci. Przykadem moe by wpis dla sieci 140.252.13.22 w grnej czci strony 133 w tomie 1 (SunOS 4.1.3). Nowsze jdra BSD maj jawnie podan marszrut do wasnego adresu IP, a odpowiednim interfejsem jest program obsu gi ptli zwrotnej. Wpis dla 140.252.13.35 na rysunku 18.2, strona 576 w tomie 2, jest tu dobrym przykadem (BSD/OS V2.0). Do tematu szybkoci dziaania wrcimy w rozdziale 18.11, po przedstawieniu implementacji protokow domeny unbcowej.
Sekcja 16.4
Przykady programw
237
16.4
Przykady programw
Pokaemy jak niewielkie s rnice pomidzy klientem-serwerem TCP, a klientem-serwerem domeny unixowej. W tym celu zmodyfikowalimy program y klien ta i serwera przedstawione na rysunkach 1.5 i 1.7, tak by wykorzystywane byy protokoy domeny unixowej. Na rysunku 16.3 przedstawiamy klienta domeny unixowej. Zmiany w stosunku do rysunku 1.5 zaznaczamy pogrubionym drukiem. ------------------------------------------------------------------------------------------------1 #include 2 #1nclude " c l is er v .h " <sys/un.h>
unixcli.c
3 int 4 m a i n ( i n t argc, c ha r * ar gv[]) 5 ( /* p ro st y kl i e n t d o m e n y u n i x o w e j */ 6 struct s o c k a d d r _ u n serv: 7 c ha r request[REQUEST], reply[REPLY]; 8 int sockfd, n: 9 10 11 12 13 14 IB 16 17 18 if (argc != 2) e r r _ q u i t ( " u s a g e : unixcli if (( sockfd = s o c k e t ( P F _ U N I X , e r r _ s y s ( "socket error");
"); S 0C K _ S T R E A M . 0)) < 0)
m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v . s u n _ f a m i l y - AF _U N I X ; s t r n c p y ( s e r v . s u n _ p a t h , argv[l], if ( co nn ec t t s o c k f d , (SA) &serv, e r r _ s y s ( " co nn ec t error"); /* u t w o r z e n i e da ni a r e q ue st [ ]
sizeof(serv.sun_path)); s i z e o f ( s e r v ) ) < 0)
...
*/
19 if ( w r i t e t so ck fd , req uest, RE QU ES T ) != R E 0 U E S T ) 20 e r r _ s y s (" wr i te error"); 21 if (s h u t d o w n t s o c k f d , 1) < 0) 22 e r r _ s y s (" sh u t d o w n e rr or"); 23 24 25 26 27 ( if ((n = r e a d _ s t r e a m ( s o c k f d , e r r _ s y s ( " r e a d er ror"); /* p r z e t w o r z e n i e exi t (0); reply, REPLY)) < 0)
" n b a j t w odpowie dz i
reply[]
...
*/
------------------------------------------------------------------------------------------------Rysunek 16.3 Klient transakcji uywajcy gniazda domeny unixowej 2-6
unixcli.c
Doczamy nagwek <s y s / u n . h > i struktury adresowe gniazd s teraz typu sockaddr_un.
239
Rozdzia 16
11-1 5
Rodzin protokow dla odwoania do socket jest PF_U NIX. Struktura adre sowa gniazda zostaje wypeniana przy pomocy strncpy nazw cieki zwizan z serwerem (z argumentu linii polecenia). W nastpnym rozdziale, przy omawianiu implementacji, pokaemy, jakie s po wody wprowadzenia tych zmian. Na rysunku 16.4 pokazany jest serwer domeny unixowej. Tak jak poprzednio, zmiany w stosunku do rysunku 1.7 zaznaczylimy pogrubionym drukiem. umxserv.c
1 //include 2 #include " c l i se rv . h" <sys/un.h> "/tmp/tcpipiv3.serv"
3 #define SERV_PATH
4 int 5 main() 6 ( /* p ro st y se r w e r d o m e n y u n i x o w e j */ 7 st r u c t s o c k a d d r _ u n serv, cli; 8 char request[REQUEST], reply[REPLY]; 9 int li stenfd, sockfd, n, clilen; 10 11 12 13 14 15 16 17 18 19 20 21 22 if (( li st e n f d = s o c k e t ( P F _ U N I X , S O C k _ S T R E A M , 0)) < 0) e r r _ s y s ( s oc ke t er ror"); m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v . s u n _ f a m i l y - AF _ UNIX; s t r n c p y ( s e r v . s u n _ p a t h , S E RV _P AT H . s i z e o f ( s e r v . s u n _ p a t h ) ); if ( b i n d ( l i s t e n f d , (SA) &serv, e r r _ s y s ( " b i n d e r ror"); sizeof(serv)) < 0)
if ( l i s t e n ( l i s t e n f d , S 0M AX C 0 N N ) < 0) e r r _ s y s ("1 i sten e r r o r ); for ( ; ; ) ( c l i l e n = s i z e o f ( c l i ); if ((soc kf d = a c c e p t ( 1 i s t e n f d , (SA) err_sys( accept er ror");
&cl1, &cli 1 e n )) <
0)
23 if ((n = r e a d _ s t r e a m ( s o c k f d . request, 24 e r r _ s y s ("read error"); 25
R E O U E ST )) < 0)
/* p r z e t w o r z e n i e n" b a j t w d an i a requ es t[ ] * o d po wi ed z i reply[] . . . * / if ( w r i t e ( so ck fd , reply, REPLY) e r r _ s y s (" w r it e e r r o r ); close(sockfd); ] != REPLY)
i utworzenie
26 27 28 29 30 )
unixserv.c Rysunek 16.4 Senuer transakcji uywajcy gniazda domeny unixowej
Sekcja 16.5
Podsumowanie
239
2-7
Doczamy nagwek <sys / un .h> oraz definiujemy (#def i ne) nazw cie ki zwizanej z tym serwerem. (Zwykle cieka byaby zdefiniowana w nagwku doczanym przez klienta i serwera; dla uproszczenia definicj umieszczamy tu taj.) Struktury adresowe gniazd s teraz typu sockaddr_un. 13-14 Struktura adresowa gniazda serwera jest wypeniana nazw cieki przy uyciu strncpy.
16.5
Podsumowanie
Protokoy domen unixowych udostpniaj sposb komunikacji midzyprocesowej uywajcy tych samych interfejsw programowych (gniazd), co komunikacja sieciowa. Protokoy domeny unixowej udostpniaj zarwno gniazdo strumienio we, podobne do TCP, jak i gniazdo datagramowe, podobne do UDP. Uywajc domeny unixowej zyskujemy na szybkoci: dla jder systemu wywodzcych si z systemu Berkeley protokoy domeny unixowej s dwukrotnie szybsze ni TC P/IP. Najwaniejszymi uytkownikami protokow domeny unucowej s potoki i X Window System. Jeeli serwer X stwierdza, e klient X dziaa w tym samym komputerze, uywane jest strumieniowe poczenie domeny unixowej zamiast poczenia TCP. Rnice w kodzie systemw klient-serwer uywajcych TCP i domen unixowych s minimalne. W nastpnych dwch rozdziaach przedstawimy implementacj gniazd domeny unixowej w kodzie jdra N e t/3.
17

17.1 Wstp
Kod rdowy implementacji protokow domeny unixowej skada si z 16 funkcji zebranych w pliku ui p c _ u s r r e q .c. W sumie ta implementacja liczy okoo 1000 linii kodu w C, co jest wielkoci podobn do 800 linii koniecznych do implemen tacji UDP (tom 2), jednoczenie jest to znacznie mniej ni 4500 linii implementacji TCP. Nasz prezentacj implementacji protokow domeny unixowej podzielimy na dwa rozdziay. W tym rozdziale omawiamy wszystkie zagadnienia oprcz I/O i przekazywania deskryptorw, ktre zostan przedstawione w rozdziale nastp nym.
17.2
Wprowadzenie do kodu rdowego
Bdziemy zajmowa si 16 funkcjami w C umieszczonymi w jednym pliku, Ponadto w oddzielnym pliku C zebrane zostay rozmaite definicje. W ykorzysty wane bd te dwa nagwki. Uywane pliki zebralimy na rysunku 17.1. W tym rozdziale omwimy rwnie dwa odwoania systemowe uywajce funkcji dome ny unixowej: pi pe i socketpai r.
Plik s y s / u n .h sys/u n p cb . h k e rn /u i p c _ p ro to . c k e rn /u i p c _ u s rre q . c k e rn / u i p c _ s y s c a l1s . c Opis Definicja struktury s o c k a d d r _ u n Definicja struktury u n p c b Definicje p r o t o s w { ) i doma i n { ) domeny unixowej Funkcje domeny unixowej Systemowe odwoania p i p e i s o c k e t p a i r
Rysunek 17.1 Pliki omawiane w tym rozdziale
Zmienne globalne
Na rysunku 17.2 pokazujemy zmienne globalne wprowadzone w tym i nastpnym rozdziale.
242
Protokoy domeny unixowej: implementacja_______________ Rozdzia 17
Zmienna u n ix d o m a in u n i xsw su n _n o n am e u n p _d e fe r u n p _ g c i ng u n p _ i no u n p _ ri g h ts u n p d g _re c v sp a c e un p d g _sen d sp ace u n p st_re c v sp a c e u n p st_se n d sp a c e
Typ danych stru c t d o m a in
Opis definicje domeny (rysunek 17.4) definicje protokou (rysunek 17.5) struktura adresowa gniazda zawierajca pust nazw cieki licznik opnionych wpisw procedury zbierania niepotrzebnych danych ustawiona, jeli zbieranie niepotrzebnych danych jest wanie wykonywane nastpny faszywy numer wza i-node, ktry bdzie przypisany licznik deskryptorw plikw, ktre s w locie domylny rozmiar bufora odbiorczego gniazda datagramowego, 4096 bajtw domylny rozmiar bufora wysykowego gniazda datagramowe go, 2048 bajtw domylny rozmiar bufora odbiorczego gniazda strumieniowego, 4096 bajtw domylny rozmiar bufora wysykowego gniazda strumieniowe go, 4096 bajtw
s t r u c t p ro to sw stru c t i nt i nt i n o _t i nt u _ lo n g u J ong u _ lo n g u _ lo n g so ckad d r
Rysunek 1 7 2 Zmienne globalne wprowadzone w tym rozdziale
17.3
Unixowe struktury domain iprotosw
Na rysunku 17.3 pokazane zostay trzy struktury doma i n istniejce zwykle w sy stemie N e t/3 , oraz odpowiadajce im tablice p r o t o s w .
Historyczne przyczyny istnienia dwch nie przetworzonych pozycji IP (raw) omwione s na stronie 199 w tomie 2.
Sekcja 17.3
Unixowe struktury domain i protosw
243
Domeny internetowe i domeny rutowania byy omwione w tomie 2. Rysunek 17.4 przedstawia pola struktury domai n (strona 195 w tomie 2) dla protokow domeny unixowej.
Czton d o m _ fa m i l y d o m _nam e d o m _i n i t d o m _ e x te rn a l i ze d o m _d i s p o s e d o m _p ro to sw d o m _p ro to sw N P R O T O S W d o m _n ext d o m _rta tta c h d o m _ rto ffs e t d o m _m a xrtk e y Warto Opis rodzina protokow dla domeny nazwa nie uywany w domenie unixowej uzewntrznienie praw dostpu (rys. 18.12) usunicie wewntrznych praw dostpu (rys. 18.14) tablica stmktur przecznikw protokou (rys. 17.5) wskanik poza koniec struktury przecznika proto kou wypenianyprzezdom ai n i n i t , str.202,tom 2
PF_UNIX unix 0 unp_externa1i ze unp_dispose urixsw
0 0 0
nie uywany w domenie unixowej nie uywany w domenie unixowej nie uywany w domenie unixowej
Rysunek 17.4 Struktura un ixdoma in Tylko domena unbcowa definiuje funkcje dom_external i ze i dom_di spose. Opi szemy te funkcje w rozdziale 18 przy okazji omawiania przekazywania deskryptorw. Ostatnie trzy czony struktury nie s zdefiniowane, poniewa domena unixowa nie uywa tablicy rutowania. Na rysunku 17.5 pokazujemy inicjacj struktury unixsw. (Analogiczn struktur dla protokow internetowych pokazano na stronie 200 w tomie 2.) uipc_proto.c
41 s t r u c t p r o t o s w u ni xs w[ ] = 42 ( (SOCK STREAM, & u n i x d o m a i n , 0. PR C 0 N N R E 0 U I R E D | PR _WANTRCVD | P R _ R I G H T S , 43 44 0, 0, 0. 0. u ip c usrreq, 45 0, 0, 0. 0. 46 47 1. (S OCK OGRAM, & u n i x d o m a i n , 0, PR A T 0 M I C 1 PR A D D R 1 P R _R IG HT S , 48 49 0. 0, 0. 0. 50 ui pc usrreq, 51 0, 0, 0, 0. 52 ). 53 (0, 0, 0, 0, 54 raw_inp ut . 0, r a w _ c t l i n p u t , 0, raw_usrreq, 55 raw init, 0, 0, 0, 56 57 1, 58 ) ;
------------------------------------------------------------------------------------------------Rysunek 17.5 Inicjacja tablicy unixsw
uipc_proto.c
244
Rozdzia17
Zdefiniowane s trzy protokoy: protok strumieniowy podobny do TCP protok datagramowy podobny do UDP protok danych nie przetworzonych (raw) podobny do protokou danych nie przetworzonych IP (rciw IP). Protokoy domeny unixowej - strumieniowy i datagramowy - uywaj flagi PR_RIGHTS, poniewa domena ta stosuje prawa dostpu (przekazywanie deskryp torw, ktre omawiamy w nastpnym rozdziale). Dwie kolejne flagi protokou strumieniowego, PR_CONNREOUIRED i PR_W ANTRCVD, s identyczne z flagami TCP, a dwie nastpne flagi, PR_ATO MIC i PR_AD DR, s takie same jak flagi UDP. Zauwa my, e jedynym wskanikiem funkcji zdefiniowanym dla protokow strumienio wego i datagramowego jest ui pc_u s r req, obsugujcy wszystkie dania. Cztery wskaniki w strukturze protosw protokou danych nie przetworzonych (wszystkie z nazwami zaczynajcymi si od r a w _ ) s tymi samymi wskanikami, ktre s uywane w domenie PF_R0UTE, opisanymi w rozdziale 20 w tomie 2.
Autor nie zna adnej aplikacji uywajcej protokou danych nie przetworzonych domeny unixowej.
17.4
Struktura adresowa gniazda domeny unixowej
Na rysunku 17.6 pokazana jest definicja struktury adresowej gniazda domeny unbcowej, sockaddr_un, zajmujcej 106 bajtw. ------:-----------------------------------------------------------------------------------------38 str u c t s o c k a d d r _ u n ( 39 u _ c h a r sun_len; 40 u_ c h a r sun_ f a m i l y ; 41 char sun_path[104]; 42 ); /* d u g o s o c k a d d r cznie z /* A F _ U N IX */ /* nazwa cieki (gag) */ z e r e m */
un.h
------------------------------------------------------------------------------------------------Rysunek 17.6 Struktura adresowa gniazda domeny unixowej
un.h
Pierwsze dwa pola s takie same, jak we wszystkich strukturach adresowych gniazd: bajt dugoci, po ktrym nastpuje rodzina adresowa (AF_UNIX).
Komentarz gag'" istnieje w tym miejscu od czasw 4.2BSD (zachowano oryginaln posta komentarza, mona to przetumaczy jako oszukastwo" - przyp. tum.). M oe m y si domyla, e autor tego fragmentu kodu nie by zwolennikiem uywania nazw cieek do identyfikacji gniazd domen unixowych lub by moe komentarz odnosi si do faktu, e w mbuf nie ma wystarczajco duo miejsca na kompletn nazw cieki (ktrej maksymalna dugo wynosi 1024 bajty).
Zobaczymy, e gniazda domen unixowych uywaj do identyfikacji gniazd nazw cieek systemu plikw i nazwa cieki jest przechowywana w czonie s un_pa t h. Czon ten ma 104 bajty dugoci, by moliwe byo zmieszczenie struktury adreso wej gniazda wraz z koczcym bajtem zerowym w 128-bajtowym mbuf. Pokazu jemy to na rysunku 17.7.
Sekcja 17.5
Bloki kontrolne protokou domeny unixowej
245
m_type
(MT_SONAME) sun_len , sun_family (AF_UNIX) s u n _ p a t h [104]
nagwek mbuf 20 bajtw 1 1
m _ h d r ()
sockaddr un(}
* U---------------mbuf () (128bajtw)
Rysunek 17.7 Struktura adresowa gniazda domeny unixowej umieszczona w mbuf Pokazujemy pole m _ t y p e bufora mbuf z wartoci MT_S0NAME, poniewa jest to normalna warto w sytuacji, gdy mbuf zawiera struktur adresow gniazda. Cho okazuje si, e ostatnie 2 bajty nie s uywane i e maksymalna dugo nazwy cieki wynosi 104 bajty, zobaczymy, e funkcje unp_bi nd i unp_connect dopuszczaj nazwy cieki o dugoci 105 bajtw, z bajtem zerowym umieszczo nym po nazwie cieki.
Gniazda domeny unixowej m usz gdzie znale przestrze na przechowywanie nazw. Do tego celu zostay uyte nazwy cieek, poniewa przestrze przeznaczona na nazw y cieek systemu plikw ju istniaa. Dla przykadu, protokoy internetowe uywaj adre sw IP i num erw portu jako przestrzeni nazw, a System V IPC (rozdzia 14 ksiki [Stevens 1992]) uywa 32-bitowych kluczy. Poniewa nazw y cieek s uyw ane przez klientw domeny unixowej do komunikowania si z serwerem , stosowane s zwykle bezwzgldne nazw y cieek (zaczynajce si od znaku / ) . Jeeli uyte zostaj wzgldne nazw y cieek, klient i serwer musz znajdowa si w tym sam ym katalogu, w przeciw nym razie nazwa cieki, z ktr zwie si serwer, nie zostanie znaleziona przez funkcje c o n n e c t i s e n d t o wywoane przez klienta.
17.5
Bloki kontrolne protokou domeny unixowej
Gniazda w domenie unixowej posiadaj odpowiedni blok kontrolny protokou (PCB) - struktur unpcb. Pokazujemy t 36-bajtow struktur na rysunku 17.8. -----------------------------------------------------------------60 s t r u c t u n p c b ( s tr u c t s oc ke t * un p _ s o c k e t ; 61 s t r u c t v node * u np _v n od e; 62 i no_t unp_ino; 63 s t r u c t u npcb * un p_ c on n; 64 s tr u c t u n pc b * un p _r ef s: 65 s t r u c t u n pc b * u n p _ n e x t r e f ; 66 s tr u c t mb uf *u np _ ad dr ; 67 int unp_cc; 60 int unp_mb cn t; 69 70 71 #define sotounpcb(so) /* /* /* /* /* /* /* /*
/*
unpcb.h
p o w r o t n y w s k a n i k do s t r u k t u r y g n i a z d a */ n i ez er ow y . jeli z w i z a n y z p l i k i e m */ f a s z y w y n u me r in o d e */ blok k o n t r o l n y p o c z o n e g o g n i a z d a */ o d n i e s i e n i e do powi z an ej listy gni az da */ wizanie w licie unp_refs */ z w i z a n y adre s g n i a z d a */ kopia r c v . s b _ c c */ kopia r c v . s b _ m b c n t */
(( st ru c t u n pc b * ) ( ( s o ) - > s o _ p c b ) )
unpcb.h Rysunek 17.8 Blok kontrolny protokou domeny unixowej
246
Rozdzia 17
W przeciwiestwie do internetowych blokw kontrolnych i blokw kontrolnych uywanych w domenie rutowania, alokowanych przez funkcj jdra M A L LOC (stro ny 687 i 742 w tomie 2), struktury unpcb s przechowywane w buforach mbuf. Wynika to najprawdopodobniej ze wzgldw historycznych. Kolejna rnica polega na tym, e wszystkie inne bloki kontrolne, poza blokami kontrolnymi domeny unixowej, s przechowywane w postaci dwukierunkowej listy cyklicznej, ktra jest przeszukiwana, gdy przychodz dane i gdy s one kierowane do odpowiedniego gniazda. W przypadku blokw kontrolnych dome ny unbcowej, lista taka nie jest potrzebna, poniewa rwnowan operacj - na przykad odszukanie bloku kontrolnego serwera, gdy klient wywouje c o n n e c t wykonuj funkcje istniejce w jdrze, suce do przeszukiwania cieek nazw. Adres raz znalezionego bloku unpcb serwera jest przechowywany w bloku unpcb klienta, poniewa klient i serwer znajduj si w jednym komputerze z gniazdami domen unixowych. Na rysunku 17.9 pokazany zosta ukad rnych struktur danych zwizanych z gniazdami domen unixowych. Prezentujemy dwa gniazda domeny unbcowej. Zakadamy, e serwer (prawa strona rysunku) zwiza nazw cieki ze swoim gniazdem, a klient (lewa strona) poczy si z nazw cieki serwera. Czon unp _ c o n n klienta wskazuje na serwera. unp _ r e f s serwera wskazuje na pierwszego klienta, ktry poczy si z tym PCB. (W przeciwiestwie do gniazd strumieniowych, z pojedynczym serwerem moe poczy si wicej ni jeden klient datagramowy. Poczenia datagramowych gniazd domeny unbcowej anali zujemy szczegowo w rozdziale 17.11.) Czon u n p _ v n o d e gniazda serwera wskazuje na czon vno de skojarzony z nazw cieki zwizan z gniazdem serwera, a czon v _ s o c k e t struktury vn o d e wskazuje na s o c k e t serwera. Takie poczenie jest wymagane, by zlokalizowa blok unpcb, zwizany z nazw cieki. Na przykad, gdy serwer wie nazw cieki z gniaz dem domeny unbcowej, powstaje struktura vnode i wskanik do u np c b umiesz czony zostaje w czonie v _ s o c k e t wza v-node. Gdy klient czy si z tym serwe rem, kod poszukiwania nazwy cieki w jdrze znajduje wze v-node i nastpnie ze wskanika v _ s o c k e t otrzymuje wskanik do unpcb serwera. Nazwa, ktra bya zwizana z gniazdem serwera, zawarta jest w strukturze soc k a d d r _ u n , t a struktura z kolei jest zawarta w strukturze m b u f , na ktr wska zuje czon unp_addr. Unbcowe wzy v-node nigdy nie zawieraj nazwy cieki prowadzcej do tego wza v-node, poniewa w systemie plikw Unixa plik (tzn. v-node) moe by wskazywany przez wiele nazw (tzn. pozycji w katalogu). Rysunek 17.9 pokazuje dwa poczone gniazda datagramowe. Zobaczymy pniej (rysunek 17.26), e analogiczny diagram dla gniazd strumieniowych wyglda nieco inaczej.
Sekcja 17.5_______________ Bloki kontrolne protokou domeny unixowej
247
248
R o z d z ia u
17.6
Funkcja uipc_usrreq
Zobaczylimy na rysunku 17.5, e jedyn funkcj wymienian w strukturze u n i x s w dla protokow strumieniowych i datagramowych jest u i pc_usrreq. Ry sunek 17.10 przedstawia gwn cz tej funkcji. -----------------------------------------------------------------------------------------------47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 i nt u i p c _ u s r r e q ( s o . req, m, nam, c o n t r o l ) s t r u c t so c k e t *so; int req; s t r u c t m b u f *m, *nam. * c o n t r o l ; ( s t r u c t u n p c b * un p = s o t o u n p c b ( s o ) ; s t r u c t so ck e t *so2; int e r ro r = 0; s t r u c t pr oc *p = cu rproc; /* XXX */ if (req = = P R U _ C 0N TR 0 L) r e tu rn ( E O P N O T S U P P ) ; if (req != P R U _ S E N D && control && c o n t r o l - > m _ l e n ) e rr o r = EOPNO TS U PP ; goto release; ) if (unp = = 0 && req != P R U_ AT TA C H) { e rr o r = EINVAL; g o t o release;
uipc_usrrecj.c
)
s w i t c h (req) 1
/* i n s t r u k c j e s wi tc h (omawi ane w n a s t p n y c h podr oz dz i a a h ) . */
246 d ef au l t: 247 panic("piusrreq"); 248 ] 249 release; 250 i f (control ) 251 m _ f r e e m ( c o n t r o l ); 252 if (m) 253 m_freem(m); 254 r eturn (error); 255 )
------------------------------------------------------------------------------------------------Rysunek 17.10 Gwna cz funkcji u ip c _ u s rre q

danie PRU_CONTROL nie jest akceptowane
57-58
uipcjusrreq.c
danie P R U _ C 0 N T R 0 L pochodzi z systemowego odwoania i octl i nie jest obsugiwane przez domen unixow.
Informacje kontrolne dopuszczalne tylko dla PRU_SEND

59 - 6 2
Jeeli informacja kontrolna zostaa przekazana przez proces (przy pomocy systemowego odwoania sendmsg), danie musi by daniem PRU_SEND, w przeciwnym przypadku zwracany jest komunikat o bdzie. Dla tego dania przy uyciu informacji kontrolnej - przekazywane s deskryptory (pokazujemy to w rozdziale 18.)
Sekcja 17.7
danie PRU_ATTACH i funkcja unp_attach
249
Gniazdo musi mie blok kontrolny
63 - 66 Jeeli struktura socket nie wskazuje na blok kontrolny domeny unixowej, to jedynym dopuszczalnym daniem jest PRU_ATTACH, w przeciwnym razie zwracany jest komunikat o bdzie.
67-248
Poszczeglne instrukcje case z tej funkcji oraz rne wywoywane funkcje imp_xxx omawiamy w nastpnych podrozdziaach.
249-255
Zwalniane s wszystkie informacje kontrolne oraz dane buforw mbuf i funkcja zwraca kontrol do woajcej procedury.
17.7
danie PRU_ATTACH i funkcja unp_attach
danie PRU_ATTACH (pokazane na rysunku 17.11) tworzone jest przez systemowe odwoanie s o cke t i przez funkcj so n e w c o n n (strona 477, tom 2), gdy przychodzi danie poczenia dla odbierajcego gniazda strumieniowego. ------------------------------------------------------------------------------------------------68 69 70 71 72 73 74 ca se P R U _ A T T A C H : if (unp) ( e r ro r = EISCONN; break; 1 err o r = unp_a tt a c h (s o ): break;
uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 17.11 danie PRU_A TTACH

68-74
uip_usrreq.c
Caa obsuga tego dania wykonywana jest przez funkcj u n p _ a t t a c h (rysunek 17.12). Alokacja i inicjacja struktury socket zostaa ju wykonana w w ar stwie gniazda i zaley to teraz ju tylko od warstwy protokou, czy alokowa i inicjowa wasny blok kontrolny protokou - w tym przypadku struktur unpcb.
Ustawienie znaku przepenienia gniazda
2 7 7 -2 9 0
Jeeli wysyany znak przepenienia (high-water mark) gniazda lub odbierany znak przepenienia gniazda jest 0, s o r e s e r v e ustawia wartoci domylne pokaza ne na rysunku 17.2. Znaki przepenienia ograniczaj ilo danych w buforze od biorczym lub wysykowym gniazda. Gdy funkcja u n p _ a t t a c h jest woana po przez odwoanie systemowe socket, oba te znaki przepenienia s rwne 0, nato miast w przypadku wywoania poprzez sonewconn, znaki te maj wartoci odpo wiednie dla odbierajcego gniazda.
Alokacja i inicjacja
29 1 - 2 9 6
m_getcl r otrzymuje mbuf dla struktury unpcb, zeruje mbuf i ustawia typ na MT_PCB. Zauwamy, e wszystkie czony inicjowane s wartoci 0. Struktury s o cke t i unp cb powizane s przez wskaniki s o _pc b i unp_socket.
250
R o z d z ia u
------------------------------------------------------------------------------------------------270 271 272 273 274 275 276 277 278 2 79 280 281 282 283 284 285 28 6 287 28 8 28 9 29 0 291 292 293 294 295 296 297 298 int unp_attach(so) s t r u c t s oc ke t *so; ( st r u c t m b u f *m; s t r u c t u np c b *unp; int error; if ( s o - > s o _ s n d . s b _ h i w a t = = 0 || s w it ch ( s o - > s o _ t y p e ) ( c as e S 0C K _ S T R E A M : e r ro r = so r e s e r v e ( s o , break; case S 0 C K _ D G R A M : e r ro r = s o r e s e r v e ( s o , break; d ef ault: panic("unp_attach"); } if (error) re turn (error); ) m = m _ g e t c l r ( M _ D 0 N T W A I T , MT _PCB); if (m = = NULL) return ( E N O B U F S ) ; unp = mtodtm, s t r u c t u n p c b *); s o - > s o _ p c b = (caddr_t) unp; u n p - > u n p _ s o c k e t = so; re tu rn (0); I s o - > s o _ r c v .s b _ h i w a t = = 0) (
uipc_usrreq.c
unpst_sendspace, unpst_recvspace);
unpdg_sendspace, unpdg_recvspace);
------------------------------------------------------------------------------------------------Rysunek 17.12 Funkcja unp_a t ta ch
uipc_usrreq.c
17.8
danie PRU_DETACH i funkcja unp_detach
danie PRILD ETACH (rysunku 17.13) jest tworzone przy zamykaniu gniazda (stro na 488, tom 2) i nastpuje po daniu PRU_DISC0NNECT (generowanym tylko dla poczonych gniazd). ------------------------------------------------------------------------------------------------75 76 77 c as e P R U _ D E T A C H : unp_detach(unp); break;
uipc_usrreq.c
--------------------------------------------------------- --------------------------------------Rysunek 17.13 danie PRU_DETACH 75-77 Funkcja u n p _ d e t a c h PRUJDETACH.
uipc_usrreq.c
(rysunek 17.14) wykonuje ca obsug dania
Sekcja 17.8
danie PRU _D ETACH i funkcja unp_detach
251
---------------------------------------------------------------------------------299 void 300 u n p _ d e t a c h ( u n p ) 301 s t r u c t unp c b *unp; 302 ( 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327
uipc_nsrrecj.c
if (u n p ->u n p _ v n o d e ) ( u n p - > u n p _ v n o d e - > v _ s o c k e t = 0; vrele(unp->unp_vnode); u n p - > u n p _ v n o d e = 0; ] if (unp - > u n p _ c o n n ) unp_disconnect(unp); w h i l e (unp - > u n p _ r e f s ) u n p _ d r o p ( u n p - > u n p _ r e f s , E C O N N RESET); soisdisconnected(unp->unp_socket); unp->unp_socket->so_pcb = 0; m_freem(unp->unp_addr); (void) m _ f r e e ( d t o m ( u n p ) ); if ( u n p _ rights) ( /* * Zwykle b u for o d b i o r c z y jest o p r n i a n y pniej, w sofree, * jeli je d n a k nasz bufor o d b i o r c z y p r z e c h o w u j e odnoniki * do d e s k r y p t o r w , ktre s teraz zbdne, p o z b d z i e m y si tych * o d n o n i k w do d e s k r y p t o r w po z e b r a n i u ich przez f u n k c j * zbierajc bezuyteczne dane (powodujc: "panie: closef: count < 0"). */ sorflush(unp->unp_socket); u n p _ g c ( ); ) ]
----------------------------------------------------------------------------------R ysunekl7.14 Funkcja unp_detach

Zwolnienie v-node
303-307
uipc_usrreq.c
Jeli gniazdo jest zwizane z wzem v-node, wskanik do struktury tego bloku otrzymuje warto 0 i vrei e zwalnia v-node.
Rozczenie, jeeli zamykane gniazdo jest poczone
3 08-309
Jeeli zamykane gniazdo jest poczone z innym gniazdem, funkcja unp_di sconnect rozcza gniazda.
Rozczenie gniazda poczonego z zamykanym gniazdem

310-311
Jeeli inne gniazda datagramowe poczone s z zamykanym gniazdem, to poczenia te zostaj odrzucone przez u n p _ d r o p i gniazda otrzymuj komunikat o bdzie ECONNRESET. Ptla whi l e przechodzi przez powizan list wszystkich struktur unpcb poczonych z unpcb zamykanego gniazda. Funkcja un p _ d r o p wywouje funkcj unp_di sconnect, ktra zmienia czon unp_ r e f s bloku, tak e czon ten wskazuje na nastpn pozycj listy. Po przetworzeniu caej listy wskanik un p _ r e f s bloku bdzie rwny 0. Zamykane gniazdo zostaje rozczone przez a wskanik struktury socket do bloku jest zerowany.
soi sdi sconnected,
312-313
252
Protokoy domeny unixowej: implementacja_______________ R o z d z ia u
Zwolnienie adresu i buforw mbuf

314-315
Jeeli gniazdo zwizane zostao z adresem, bufor mbuf zawierajcy ten adres jest zwalniany przez m_freem. Zauwamy, e kod nie sprawdza, czy wskanik unp_a dd r jest niezerowy, poniewa sprawdzenie to wykonuje m_f reem. Struktura unpcb jest zwalniana przez m_f ree.
To odwoanie do m _ f r e e powinno by przeniesione na koniec funkcji, poniewa wskanik u n p moe by uyty przez nastpny fragment kodu.
Sprawdzenie przekazywanych deskryptorw

316-326
Jeeli istniej deskryptory aktualnie przekazywane przez dowolny proces w jdrze, warto unp_ri ghts jest niezerowa, co powoduje wywoanie sorf 1 ush i unp _ g c (garbage collector - funkcja zbierajca bezuyteczne dane). (Przekazywa nie deskryptorw omawiamy w rozdziale 18.)
17.9
danie PRU_BIND i funkcja unp_bind
Gniazda strumieniowe i datagramowe w domenie unbcowej mog by zwizane z nazwami cieek w systemie plikw przy pomocy funkcji bind. Systemowe odwoanie bind tworzy danie P RU_B I ND, co pokazujemy na rysunku 17.15. ------------------------------------------------------------------------------------------------78 79 80 c as e PRU_BIND: e rr o r = u np _ bi n d ( u n p , break: nam, p);
uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 17.15 danie PRU_BIND

7 8- 80
uipc_usrreq.c
Cae przetwarzanie jest wykonywane przez funkcj un p_b i nd, pokazan na rysunku 17.16. ------------------------------------------------------------------------------------------------3 28 329 3 30 331 3 32 333 334 335 336 337 338 int u n p _ b i n d ( u n p , nam. p) s tr u c t u n pc b *unp; s t r u c t m b u f *nam; s t r u c t proc *p; ( s t r u c t s o c k a d d r _ u n *s oun = m t od (n a m, s t r u c t v n od e *vp; s t r u c t v a tt r vattr; int error; s t r u c t n a m e i d a t a nd;
uipc_usrreq.c
st r uc t s o c k a d d r _ u n *);
339 NDINIT( &nd, CREATE, F0LL0W | LOCKPARENT, U I 0 _ S Y S S P A C E . s o u n - > s u n _ p a t h , p); 340 if ( u n p - > u n p _ v n o d e != NULL) 341 r et ur n (EINVAL); 342 if ( n a m - > m _ l e n == M LEN) ( 343 if (*(mt o d( na m, c ad d r _ t ) + n a m - > m _ l e n - 1) != 0) 344 r e t u r n (E I N V A L ) ; 345 ] else 346 * (m to d ( n a m , c ad dr _ t) + n a m - > m _ l e n ) = 0; 347 /* P O W I N N A B YC M O L I W O U Y C I A I S T N I E J C Y C H PL IK W I W Y K O N A N I A w a k e u p O , * J A K DLA FI F0 */
Sekcja 17.9
danie PRU_BIND i funkcja unp_bind
253
348 349 350 351 352 35 3 354 35 5 356 357 358 359 36 0 361 36 2 36 3 36 4 3 65 366 367 368 3 69 370 371
if (error = n a m e i (& n d )) r et ur n (error); vp = nd .ni_vp; i f (vp != NULL) ( V 0 P _ A B 0 R T 0 P ( n d .n i _ d v p , & n d .n i _ c n d ); if (n d .ni _ dv p = = vp) v r e l e ( n d .n i _ d v p ); el se vput(nd,ni_dvp); vrele(vp); r et ur n (E A D D R I N U S E ); VATTR_NULL(&vattr); v a t t r . v a _ t y p e = VSOCK; v at t r .va_mode = A C C E S S P E R M S ; if (error = V O P _ C R E A T E ( n d . n i _ d v p , r et ur n (error);
& nd . ni _ v p , & n d . n i _ c n d ,
&v at tr ) )
vp = nd.ni_vp; v p - > v _ s o c k e t = un p- > un p _ s o c k e t ; u n p - > u n p _ v n o d e = vp; u n p - > u n p _ a d d r = m_ co p y ( n a m , 0, (int) M _ C 0P YA LL ) ; V 0 P _ U N L 0 C K ( v p , 0, p); r et u rn (0); }
uipc_usrreq.c Rysunek 17.16 Funkcja unp_bind

Inicjacja struktury nameidata
3 3 8 -3 3 9
unp_bi nd alokuje struktur typu namei data, ktra zawiera wszystkie argu menty funkcji namei, i inicjuje t struktur przy pomocy makroinstrukcji NDINIT. Argument C R E A T E oznacza, e utworzona bdzie nazwa cieki, F0L L 0 W pozwala na ledzenie symbolicznych linkw, a L 0 C K P A R E N T informuje, e macierzysty w ze v-node musi by zablokowany przy wyjciu (by inny proces nie mg zm ody fikowa v-node, dopki nasze przetwarzanie nie zostanie zakoczone). Z kolei U 1 0_S Y S S P AC E oznacza, e nazwa cieki znajduje si w jdrze (poniewa prze twarzanie odwoania systemowego bind kopiuje j z przestrzeni uytkownika do mbuf). soun ->su n _ p a t h jest pocztkowym adresem nazwy cieki (przekazywa nym do unp_bi nd jako argument nam). Wreszcie p jest wskanikiem do struktury proc dla procesu, ktry wykona odwoanie systemowe bi nd. Ta struktura zawie ra ca informacj o procesie, ktr jdro musi przechowywa w pamici przez cay czas. Makroinstrukcja NDI NIT tylko iniquje struktur, odwoanie do namei znajduje si dalej w tekcie funkcji.
Historycznie, funkcja szukajca nazw cieek w systemie plikw zw ana bya namei, co bierze si z okrelenia name-to-inode". Funkcja ta przeszukiwaa system plikw w poszukiwaniu podanej nazw y i - jeli nazwa zostaa znaleziona - inicjowaa struktur i node w jdrze, zawierajc kopi informacji wza i-node pliku z dysku. Cho wzy i-node zostay zastpione przez wzy v-node, to nazwa namei pozostaa. Po raz pierwszy stykamy si bliej z systemem plikw w jdrze BSD. Jdro obsuguje systemy plikw rnych typw: standardowy dyskowy system plikw (zw any czasem szybkim systemem plikw" - fast filesystem), sieciowy system plikw (NFS - netioork filesystem), system plikw CD-ROM, system plikw MS-DOS, system plikw w pamici (:memory based filesystem; dla katalogw takich jak /tm p ), itd. [Kleiman 1986] opisuje w czesn implementacj v-node. Funkcje z nazw am i zaczynajcym i si od V 0 P _ s podstaw ow ym i funkcjami wykonujcymi operacje na wzach v-node. Istnieje okoo 40
254
takich funkcji i kada z nich, gdy zostaje wywoana, uruchamia funkcj zdefiniowan dla danego systemu plikw do wykonania odpowiedniej operacji. Funkcje z nazwami zaczy najcymi si od maej litery v s funkcjami jdra, ktre m og wywoa jedn lub wicej funkcji V0P_. Na przykad v pu t wywouje V 0P _U NL OC K , a nastpnie vrel e. Funkcja vrel e zwalnia wze v-node: licznik odwoa do wza v zostaje zmniejszony i jeli osignie w arto 0, wywoywana jest funkcja V0P_I NACTIVE.
Sprawdzenie, czy gniazdo jest ju zwizane

340-341
Jeeli czon unp_vnode bloku gniazda ma niezerow warto, gniazdo zo stao ju zwizane, co jest bdem.
Zero koczce nazw cieki
342-346
Jeeli dugo bufora mbuf zawierajcego struktur sockaddr_un wynosi
108 (ML EN) - ktra to warto jest kopiowana z trzeciego argumentu systemowego
odwoania bi nd - to ostatni bajt bufora mbuf musi by bajtem zerowym. Nazwa cieki musi by zakoczona zerem - jest to wymagane przy poszukiwaniu nazw cieek w systemie plikw. (Funkcja sockargs, strona 467 w tomie 2, gwarantuje, e dugo struktury adresowej gniazda przekazanej przez proces nie jest wiksza ni 108.) Jeeli dugo mbuf jest mniejsza ni 108, bajt zerowy jest umieszczany na kocu nazwy cieki, na wypadek, gdyby proces nie zakoczy nazwy cieki bajtem zerowym.
Poszukiwanie nazwy cieki w systemie plikw
347-349
n ame i poszukuje nazwy cieki w systemie plikw i usiuje utworzy plik o odpowiedniej nazwie w odpowiednim katalogu. Na przykad, jeeli nazwa cieki wizana z gniazdem jest /tmp/ .Xll-unix/XO, wtedy nazwa X0 musi by dodana do katalogu / tmp/ .Xll-unix. Katalog zawierajcy X0 zwany jest katalogiem macierzystym (parent directory). Jeeli katalog / t m p / .X I I - unix nie istnieje, lub jeeli istnieje i zawiera ju plik X 0, zwracany jest komunikat o bdzie. Moe te pojawi si bd wynikajcy z tego, e proces nie m a uprawnie do utworzenia nowego pliku w katalogu macierzystym. Oczekujemy, e funkcja na me i zwrci warto 0 i wskanik n d .n i_v p bdzie wskanikiem zerowym (plik jeszcze nie istnieje). Jeeli oba te warunki s spenione, wtedy n d . n i _ d v p zawiera nazw katalogu macierzystego, w ktrym bdzie utworzony nowy plik.
Komentarz o uyciu istniejcej nazwy cieki odnosi si do sytuacji, gdy b i n d zwraca bd, poniewa plik ju istnieje. Dlatego aplikacje wykonujce bi nd dla gniazda domeny unixowej najczciej poprzedzaj b in d odwoaniem do un 1 i nk, by usun nazw cieki, jeli ju istnieje.
Plik istnieje
350-359
Jeeli wskanik nd.ni_vp jest niezerowy, oznacza to, e plik o podanej nazwie ju istnieje. Odwoania do v-node zostaj usunite i komunikat o bdzie E A D D R I N U S E zostaje zwrcony do procesu.
Sekcja 17.10
danie PRU_CO N N ECT i funkcja unp_connect
255
Utworzenie v-node
360 -3 6 5
Struktura vattr zainicjowana jest przez makroinstrukcj VATTR_NULL. Ustalony zostaje typ VS 0 C K (gniazdo) i tryb dostpu otrzymuje oktaln warto 777 (A C C E S SPERMS ). Ustawionych jest wszystkich dziewi bitw praw dostpu, dopuszczone jest wic pisanie, czytanie i wykonywanie przez waciciela, grup i innych uytkownikw. Plik zostaje utworzony w podanym katalogu przez funk cj systemu plikw, wy woan porednio przez funkcj V 0 P_C R E AT E. Argumenta mi do funkcji tworzcej plik s: n d .n i_d vp (wskanik do wza v-node macierzy stego katalogu), nd.ni_cnd (dodatkowa informacja z funkcji namei, ktra musi by przekazana do funkcji V0P) oraz struktura vattr. Drugi argument, nd .ni_vp, przekazuje informacj zwracan przez funkcj, wskazujc na nowo utworzony wze v-node (jeli funkcja zostaa wykonana pomylnie).
Powizanie struktur
3 6 5 -3 6 7
vnode i socket wskazuj wzajemnie na siebie poprzez czony v_socket i unp_vnode.

Zachowanie nazwy cieki
368-371
Wykonana zostaje, przy pomocy m_copy, kopia bufora mbuf zawierajcego nazw cieki zwizanej przed chwil z gniazdem. Czon unp_addr bloku wska zuje na nowy bufor mbuf. Wze v-node zostaje odblokowany.
17.10
danie PRU_CONNECT i funkcja unp_connect

uipc_usrreq.c
Na rysunku 17 .1 7przedstawione s dania P RU_LI STE Ni PRU_C0NNECT.
----------------------------------------------------------------------------------81 82 83 84 85 86 87 ca se P R U _ L I S T E N : if ( u n p - > u n p _ v n o d e = e r r o r = EINVAL; break; 0)
ca se P RU _ C0 NN EC T : e r r o r = u n p _ c o n n e c t ( s o , nam. p); break;
----------------------------------------------------------------------------------Rysunek 17.17 dania PRU_LISTENi PRU_CONNECT

Sprawdzenie, czy odbierajce gniazdo jest zwizane
81 -84
uipc_usrreq.c
Odwoanie systemowe listen' moe by wykonane tylko dla gniazda, kt re zostao zwizane z nazw cieki. Dla TCP taki wymg nie istnieje. Na stronie 1054 w tomie 2 widzielimy, e gdy dla niezwizanego gniazda TCP woane jest 1 i sten, TCP wybiera i przypisuje do gniazda efemeryczny port.
8 5 -8 7
Ca obsug dania P R U _ C 0 N N E C T wykonuje funkcja unp_connect. (Pierwsz cz tej funkcji przedstawiamy na rysunku 17.18.) Funkcja ta jest w y woywana przez danie P RU_C O N N E C T (zarwno dla gniazda strumieniowego, jak
256
R o z d z ia u
i dla gniazda datagramowego) i rwnie - przy tymczasowym czeniu niepo czonego gniazda datagramowego - przez danie PRU_SEND. ------------------------------------------------------------------------------------------------3 72 3 73 374 375 376 377 3 78 379 3 80 381 3 82 38 3 3 84 3 85 3 86 387 3 88 3 89 3 90 391 3 92 3 93 3 94 3 95 3 96 397 3 98 39 9 40 0 401 40 2 40 3 4 04 40 5 40 6 407 int u n p _ c o n n e c t ( s o , nam, p) s t r u c t s oc ke t *so; st r u c t m b u f *nam: st r u c t proc *p; ( s t r u c t s o c k a d d r _ u n * s o un = mto dt na m, s t r u c t v n o d e *vp; s t r u c t so ck e t *so2, s t r u c t un p c b *unp2, int error; s t r u c t n a m e i d a t a nd;
uipc_usrreq.c
s tr uc t s o c k a d d r _ u n *); *so3; *unp3;
N D IN I T ( & n d . L00KU P, F0 L L0 W | L O C K L E A F , U I 0 _ S V S S P A C E , s o u n - > s u n _ p a t h , p); if ( na m - > m _ d a t a + n a m - > m _ l e n = = & n a m - > m _ d a t [ M L E N ] ) ( /* XXX */ if ( *( mt od ( na m, c ad d r _ t ) + n a m - > m _ l e n - 1) != 0) r et ur n (E MSGSIZE); ) el se * ( m to d (n am , c ad dr _ t) + n a m - > m _ l e n ) = 0; if ( error = n a m e i ( & n d ) ) re tu r n (error); vp = n d . n i _ v p ; if ( v p - > v _ t y p e != VS0CK) ( e r r or = EN0TS0CK; go t o bad; ) if ( error = V 0 P _ A C C E S S ( v p , VWRITE, p - > p_ uc re d , p)) g ot o bad; so2 = v p- >v _s o c k e t ; if (so2 = = 0) [ er r o r = E C 0 NN R EF US ED ; g ot o bad: if ( s o - > s o _ t y p e != s o 2 - > s o _ t y p e ) { e r r o r = EPR0T 0 TY PE ; goto bad; )
----------------------------------------------------------------------------------R y s u n e k 17.18 Funkcja u np_connect, cz pierwsza

Inicjacja struktury nameidata
3 83 - 3 84
uipc_usrreq.c
Makroinstrukcja N D I NIT inicjuje struktur nameidata. Argument L00KUP oznacza, e nazwa cieki ma by poszukiwana, F0LL0W dopuszcza ledzenie symbolicznych linkw, a LOCKLEAF stwierdza, e wze v-node musi by zabloko wany przy wyjciu (by inny proces nie mg zmodyfikowa wza v-node, dopki nasze przetwarzanie nie zostanie zakoczone). U10_SYSSPACE stwierdza, e na zwa cieki znajduje si w jdrze, a soun ->sun_path jest pocztkowym adresem nazwy cieki (przekazanym do unp_connect w argumencie nam), p to wskanik do struktury proc dla procesu, ktry wykona systemowe odwoanie connect lub sendto.
Sekcja 17.10
danie PRU_CO N N ECT i funkcja unp_connect
257
Zakoczenie nazwy cieki bajtem zerowym

3 8 5 -3 8 9
Jeeli dugo struktury adresowej gniazda wynosi 108 bajtw, to ostatni bajt musi by rwny 0. Jeli nie, bajt zerowy zostaje umieszczony na kocu nazwy cieki.
Ten fragment kodu jest podobny do kodu z rysunku 17.16. Istniej jednak istotne rnice. Nie tylko pierwsza instrukcja i f zostaa zapisana inaczej, ale rwnie komunikat o b dzie - zwracany, gdy ostatni bajt jest niezerowy - jest inny: E M S G S I ZE tutaj i E I N V A L na rysunku 17.16. Przedstawiony tu test spenia te dodatkow rol: sprawdza, czy dane nie s zawarte w klastrze. Ten efekt uboczny jest jednak prawdopodobnie przypadkowy, ponie wa funkcja s o c k a r g s nigdy nie umieszcza struktury adresowej gniazda w klastrze.
Poszukiwanie i sprawdzenie nazwy cieki

3 9 0 -3 9 8
namei szuka nazwy cieki w systemie plikw. Jeli poszukiwanie koczy si pomylnie, wskanik do struktur vnode jest zwracany w nd . ni _vp .Ty p v-node musi by VS0 CKi aktualny proces musi mie prawo do pisania dla tego gniazda.
Sprawdzenie, czy gniazdo jest zwizane z nazw cieki
3 9 9 -4 0 3
Gniazdo musi by aktualnie zwizane z nazw cieki, to znaczy wskanik przeciwnym przypadku danie poczenia jest odrzucane. Moe si to zdarzy, jeeli serwer nie dziaa w tym momencie, ale nazwa cieki pozostaa w systemie plikw od czasu, gdy serwer ostatnio dziaa.
v _ s o c k e t musi by niepusty. W Sprawdzenie typu gniazda
4 0 4 -4 0 7
Typ gniazda czcego si klienta (so) musi by taki sam jak typ gniazda serwera, z ktrym poczenie jest nawizywane (s o 2). To znaczy gniazdo strumie niowe nie moe poczy si z gniazdem datagramowym - lub na odwrt. Rysunek 17.19 pokazuje pozosta cz funkcji unp_connect, w ktrej najpierw obsugiwane s czce si gniazda strumieniowe, a nastpnie wywoywana jest funkcja u n p _ c o n n e c t 2 - b y powiza dwie struktury unpcb. ------------------------------------------------------------------------------------------------408 if ( s o - > s o _ p r o t o - > p r _ f l a g s & P R _ C 0 N N R E Q U I R E D ) { 4 09 if (( s o 2 - > s o _ o p t i o n s & S 0 _ A C C E P T C 0 N N ) = = 0 || 4 10 (so3 = s o n e w c o n n ( s o 2 . 0)) = = 0) ( 411 e r ro r = E C O N N R E F U S E D : 4 12 g ot o bad; 4 13 ) 414 unp2 = s o t o u n p c b ( s o 2 ) ; 415 unp3 = s o t o u n p c b ( s o 3 ) ; 416 if ( un p 2 - > u n p _ a d d r ) 417 unp3->unp_addr = 4 18 m _ c o p y ( u n p 2 - > u n p _ a d d r , 0, (int) M_ C 0 P Y A L L ) ; 4 19 so2 = So3; 420 ) 42 1 e r r o r = u n p _ c o n n e c t 2 ( s o , so2); 4 22 bad: 4 23 vput (v p) ; 424 r e t u r n (error); 425 )
uipcjusrrecj.c
------------------------------------------------------------------------------------------------Rysunek 17.19 Funkcja unp_connect cz druga
uipc_usrreq.c
258
Poczenie gniazd strumieniowych

4 0 8 -4 1 5
Gniazda strumieniowe s obsugiwane w specjalny sposb, poniewa nowe gniazdo musi by utworzone z odbierajcego gniazda. Po pierwsze, gniazdo serwera ma by gniazdem odbierajcym, czyli musi by ustawiona flaga S0_ ACCEPTC0NN. (Robi to funkcja s o 1 i s t e n, strona 470-471 w tomie 2.) Nastpnie wywoywana jest funkcja sonewconn, by utworzy nowe gniazdo z gniazda odbierajcego. Funkcja s o n e w c o n n umieszcza rwnie nowe gniazdo w kolejce niekompletnych pocze odbierajcego gniazda (so_q0).
Kopia nazwy zwizanej z odbierajcym gniazdem
4 1 6 -4 1 8
Jeeli odbierajce gniazdo zawiera wskanik do bufora mbuf zawierajcego
s oc ka dd r_un z nazw zwizan z gniazdem (co zawsze powinno by prawd), to dla nowo utworzonego gniazda przy pomocy m_c o py kopiowany jest bufor mbuf.
Rysunek 17.20 pokazuje stan rnych struktur bezporednio przed przypisaniem so2 = so3. Wykonywane s nastpujce kroki: Struktury file, socke t i unpcb, przedstawione po prawej stronie rysunku, s tworzone, gdy serwer wywouje socket. Serwer nastpnie woa bi nd, co po woduje utworzenie odnonika do vn ode i do odpowiedniego bufora mbu f zawierajcego nazw cieki. Serwer nastpnie wywouje listen, umoliwia jc klientowi poczenie. Struktury file, s o c k e t i unpcb przedstawione w lewej czci rysunku tworzo ne s, gdy klient wywouje socket. Klient nastpnie wywouje funkcj connect, ktra woa unp_connect. Struktura s o cke t przedstawiona porodku, ktr nazywamy poczonym gniazdem serwera", utworzona jest przez funkcj sonewconn, ktra tworzy nastpnie danie PRU_ATTACH, powodujc utworzenie struktury unpcb. Funkcja sonewconn wywouje rwnie soqi nsque,by umieci nowo utworzo ne gniazdo w kolejce niekompletnych pocze odbierajcego gniazda (zaka damy, e kolejka bya dotd pusta). Pokazujemy rwnie pust kolejk kom pletnych pocze dla odbierajcego gniazda (so_q i so_ql en). Czon so _ h e a d nowo utworzonej struktury socket wskazuje z powrotem na gniazdo odbierajce. Funkcja u n p _ c o n n e c t wywouje m_copy, by utworzy kopi bufora mbuf za wierajcego nazw cieki zwizanej z odbierajcym gniazdem. Na ten bufor mbuf wskazuje rodkowa struktura unpcb. Zobaczymy, e kopia jest potrzebna dla odwoania systemowego getpeername. Zauwamy wreszcie, e nowo utworzona struktura soc k e t nie jest jeszcze wskazywana przez struktur f i 1 e (i rzeczywicie, zostao to zaznaczone przez ustawienie flagi S S _ N 0 F D R E F w sonewconn). Alokacja struktury fil e dla tej struktury soc ket, wraz z odpowiednim deskryptorem pliku, zostanie wykona na, gdy odbierajcy proces serwera wywoa accept. Wskanik do vnode nie jest kopiowany z gniazda odbierajcego do poczonego gniazda serwera. Ta struktura vnode ma za zadanie jedynie umoliwienie klien tom wywoujcym connect znalezienie odpowiedniej struktury socket serwera, za porednictwem wskanika v_s o c k e t.
Sekcja 17.10
danie P RU _C O N N EC Ti funkcja unp_connect
259
deskryptor klienta
odbierajcy deskryptor serwera
file O
file O
f_type f_data
f_type f_data
soclcat{)
j/
N ULL N ULL
so3
socket{}
so2
so head so_qO s o_q01en so_q so_qlen
0
NULL
so head so_qO so q01en so_q so qlen so_pcb

utworzona przez sonewconn
so head so_qO so_q01en so_q so_qlen so_pcb
NULL
1
NULL
SO_J5Cb
unp2
u n p c b {)
u n p c b {}
unpcb{}
^ / unP3
//
unp_socket unp_vnode unp_ino unp_conn unp_refs unp_nextref unp_addr unp_cc unp_mbcnt m b u f {}

MT_SONAME
unp_socket unp vnode unp_ino unp_conn unp_refs unp_nextref unp_addr unp_cc - unp_mbcnt m b u f {>
MT_SONAME
unp_socket unp vnode unp_ino unp_conn unp_refs unp_nextref unp_addr unp_cc - unp_mbcnt
v n e d e {>
sockaddr_un{}
zawiera nazw cieki zwizan z odbierajcym gniazdem
sockaddr_un{}
v socket
Rysunek 17.20
Rne struktury w czasie zoykonywania co n n ect dla gniazda strumieniowego
260
Rozdzia 17
Poczenie dwch gniazd strumieniowych lub datagramowych

421
Ostatni czynnoci w un p_con n ect jest wywoanie funkcji un p_co n nec 1 2 (pokazanej w nastpnym podrozdziale), co jest wykonywane zarwno dla gniazd strumieniowych, jak i datagramowych. W ten sposb powizane zostan ze sob czony unp_conn rodkowej i lewej struktury unpcb z rysunku 17.20 oraz nowo utworzona struktura socket zostanie przeniesiona z kolejki niekompletnych po cze do kolejki kompletnych pocze dla odbierajcej struktury socket serwera. Pokaemy wynikajce z tych operacji struktury danych w nastpnym podrozdzia le (rysunek 17.26).
17.11
danie PRU_CONNECT2 i funkcja unp_connect2
danie PRU_C0NNECT2, pokazane na rysunku 17.21, powstaje tylko w wyniku wykonania systemowego odwoania soc ketpa i r. To danie istnieje tylko w do menie unixowej. ------------------------------------------------------------------------------------------------88 89 90 c a s e PR U _ C 0 N N E C T 2 : e rr o r = u n p _ c o n n e c t 2 ( s o , (struct s oc ke t *) nam); break;
uipc_usrrec\.c
------------------------------------------------------------------------------------------------Rysunek 17.21 danie PRU_C0NNECT2

8 8 -9 0
uvpc_usrreq.c
Cae przetwarzanie tego dania odbywa si w funkcji unp_connect2. Funkcja ta jest rwnie wywoywana z dwch innych miejscw jdrze, tak jak to pokazujemy na rysunku 17.22.
Rysunek 17.22
Wywoania funkcji unp_connect2
Sekcja 17.11___________ danie PRU _C 0N N EC T2 i funkcja unp_connect2
261
W rozdziale 17.12 opisujemy odwoanie systemowe socket pa i r i funkcj soc on nect2, a odwoanie systemowe pi pe - w rozdziale 17.13. Funkcja u n p _ c o n n e c t 2
przedstawiona jest na rysunku 17.23. ------------------------------------------------------------------------------------------------4 26 427 428 4 29 4 30 431 432 433 434 43 5 43 6 437 4 38 43 9 44 0 441 44 2 44 3 44 4 445 446 447 448 449 450 451 452 int u n p _ c o n n e c t 2 ( s o , so2) s t r u c t s oc ke t *so: st r u c t s o c k e t *so2; { st r u c t u np c b * un p = s o t o u n p c b ( s o ) ; s t r u c t u n p c b *unp2; if (s o 2- >s o t y p e != s o - > s o type) r et ur n (E P R O T O T Y P E ); un p2 = s o t o u n p c b ( s o 2 ) ; u n p - > u n p _ c o n n = unp2: s w i t c h ( s o- >s o _ t y p e ) ( c as e S 0 C K _ D G R A M : unp->unp_nextref = unp2->unp_refs u n p 2 - > u n p _ r e f s = unp; soisconnected(so); break; c as e S0 CK _S T RE AM : u n p 2 - > u n p _ c o n n = unp; soisconnected(so); soisconnected(so2); break; default: p a n i c C u n p c o n ne c t2 ") ; ) re t u r n (0); )
uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 17.23 Funkcja unp_connect2

Sprawdzenie typu gniazd
4 2 6 -4 3 4
uipc_usrreq.c
Dwa argumenty funkcji s wskanikami do struktur soc k e t - so czy si z so2. Najpierw sprawdzane jest, czy oba gniazda s tego samego typu: strumie niowe lub datagramowe.
Poczenie pierwszego gniazda z drugim gniazdem
4 3 5 -4 3 6
Pierwszy blok unp cb zostaje poczony z drugim przez czon unp_conn. Nastpne kroki dla gniazd datagramowych i strumieniowych s jednak rne.
Poczenie gniazd datagramowych
4 3 8 -4 4 2
Czony u n p _ n e x t r e f i u n p _ r e f s bloku cz gniazda datagramowe. Roz wamy na przykad datagramowe gniazdo serwera zwizane z nazw cieki /tmp/foo. Klient datagramowy czy si z t nazw cieki. Rysunek 17.24 pokazuje odpowiednie struktury danych, po zakoczeniu przetwarzania w u np_connect2. (Dla uproszczenia, nie pokazujemy odpowiednich struktur file czy socket, ani struktury vno de zwizanej z gniazdem pokazanym z prawej strony.) Pokazujemy dwa wskaniki, unp i unp2, ktre uywane s w unp_connect2.
262
Rysunek 17.24
Poczone gniazda datagramowe
Dla gniazda datagramowego, z ktrym nawizano poczenie, czon u np_ r e f s wskazuje na pierwszy blok w powizanej licie wszystkich gniazd, ktre poczy y si z tym gniazdem. Po licie tej mona si przemieszcza, ledzc wskaniki
unp_nextref.
Rysunek 17.25 pokazuje stan trzech blokw po tym, jak trzecie gniazdo datagra mowe (to po lewej stronie) poczyo si z tym samym serwerem / tmp/foo.
Rysunek 17.25 Kolejne gniazdo (po lewej) czy si z gniazdem pokazanym po prawej stronie Dwa pola bloku, unp _ r e f s i unp_nextref, musz by rozdzielone, poniewa gniazdo po prawej stronie na rysunku 17.25 moe samo poczy si z innym gniazdem datagramowym.
Poczenie gniazd strumieniowych
4 4 3 -4 4 7
Poczenie gniazda strumieniowego rni si od poczenia gniazda datagra mowego, poniewa z gniazdem strumieniowym (serwerem) moe poczy si tylko jedno gniazdo klienta. Czony u n p_c o n n obu blokw wskazuj na blok partnera, tak jak pokazano na rysunku 17.26. Rysunek ten jest kontynuacj rysunku 17.20.
Sekcja 17.11
danie PR U _C 0N N EC T2 i funkcja unp_connect2
263
deskryptor klienta
odbierajcy deskryptor serwera
fila O
file O
f_type f data
socketf >
so head so_qO so gOlen so_q so_qlen so_pcb
NULL NULL
0
NULL
, unP u n p c b {}
Utworzona przez sonewconn u n p c b {)
unP2
u n p c b {)
unp_socket unp vnode unp_ino unp_conn unp_refs unp_nextref - unp__addr unp_cc unp m bcnt
vnode{}
MT_SONAME sockaddr un{|

MT_SONAME
sockaddr un{}
Rysunek 17.26
Poczone gniazda strumieniowe
264
Rozdzia 17
Kolejn zmian w tym schemacie jest fakt, e wywoanie s o i s c o n n e c t e d z argu mentem so2 przenosi gniazdo z kolejki niekompletnych pocze odbierajcego gniazda (so_qO na rysunku 17.20) do kolejki kompletnych pocze (so_q). Z tej kolejki gniazdo zostanie pobrane przez accept (strona 474 w tomie 2). Zauwamy, e soi s c o n n e c t e d (strona 479, tom 2) ustawia rwnie flag S S _ I S C O N N E C T E D w so_state. s o i s c o n n e c t e d przenosi gniazdo z kolejki niekompletnych po cze do kolejki kompletnych pocze tylko wtedy, jeli wskanik s o_h e a d gniaz da jest niezerowy. (Jeli wskanik so _ h e a d jest zerowy, to gniazdo nie znajduje si ani w jednej, ani w drugiej kolejce.) Dlatego pierwsze wywoanie soi s c o n n e c t e d na rysunku 17.23 z argumentem so zmienia tylko so_state.
17.12
Odwoanie systemowe socketpair
Odwoanie systemowe socketpai r istnieje tylko w domenie unixowej. Odwoa nie to tworzy i czy dwa gniazda, zwracajc dwa deskryptory wzajemnie po czone ze sob. N a przykad proces uytkownika wykonuje
int fd[2]; sock e tp ai r( P F J J N I X , S O C K _ S T R E A M , 0, fd);
by utworzy par dwukierunkowych (full-duplex) wzajemnie poczonych stru mieniowych gniazd domeny unbcowej. Pierwszy deskryptor jest zwracany w f d [ 0 ], a drugi w f d Cl]. Jeeli drugim argumentem jest S0CK_DGRAM, zostaje utworzona para poczonych gniazd datagramowych domeny unbcowej. socketpa i r zw ra ca warto 0, jeeli gniazda zostay utworzone pomylnie, lub -1, w przypadku bdu. Na rysunku 17.27 pokazano implementacj odwoania systemowego so c ke tpai r. ------------------------------------------------------------------------------------------------229 s t r u c t s o c k e t p a i r _ a r g s 230 int domain; 231 int type; 232 i nt protocol: 233 int *rsv; 234 I; 2 35 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 (
uipc_syscals.c
s o c k e t p a i r ( p , uap. r e t v a l ) s t r u c t p ro c *p; st r u c t s o c k e t p a i r _ a r g s *uap; int r e t v a 1[ ]: ( st r u c t fi le d e s c * fd p = p - > p _ f d : st r u c t file *fpl, *fp2; st r u c t so ck e t *sol, *so2; int fd, error, s v [ 2 ] : if if if ( error = s o c r e a t e ( u a p - > d o m a i n , &sol, u a p - > t y p e . u a p - > p r o t o c o l )) re t ur n (error); (error = socreate(uap->doinain, &so2, u a p O t y p e , u a p - > p r o t o c o l )) go to freel;
(error = fa lloc(p, &fpl. &fd)) go to free2; sv[0] = fd; f p l ->f _ f 1 ag = FR EAD I F W R I T E ; fpl->f_type = DTYPE_S0CKET;
Sekcja 17.12
265
253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 2 68 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 }
f p l - > f _ o p s = soc ke t op s; f p l - > f _ d a t a = (caddr_t) sol; if (error = fal 1o c ( p , &fp2, &fd)) go to free3; f p 2 - > f _ f l a g = FREAD I FWRITE; f p 2 - > f _ t y p e = D T Y PE _S 0 CK ET ; f p 2 - > f _ o p s = J s o ck e to ps ; f p 2 - > f _ d a t a = (caddr_t) so2; s v C 1] = fd; if (error = s o c o n n e c t 2 ( s o l , so2)) go to free4; if ( u a p -> ty pe = = S 0 C K _ D G R A M ) I
/*
* P o c z e n i e g n i az da d a t a g r a m o w e g o j e st as y m e t r y c z n e .
if (error = s o c o n n e c t 2 ( s o 2 , g o t o free4;
*/
sol)) 2 * s i z e o f ( i n t ) );
e r r o r = c o p y o u t ((c a d d r _ t ) sv, ( caddr_t) uap - >r sv . r e t v a l [0] = s v [0]; /* XXX ??? */ r e t v a l [1] = s v [1]: /* XXX ??? */ r e t u r n (error); free4: ffree(fp2); f d p - > f d _ o f i l e s [ s v [ l ] ] = 0; free3: f f r e e t f p l ); f d p - > f d _ o f i 1 e s [ s v [0]] = 0; free2: (void) s o c l o s e ( s o 2 ) ; freel: (void) s o c l o s e ( s o l ) ; r et ur n (error);
------------------------------------------------------------------------------------------------Rysunek 17.27 Odwoanie systemowe socketpa i r

Argumenty
uipc_syscalls.c
229-239 Cztery argumenty typu cakowitego, poczynajc od d o m a i n po rsv, s argumentami, ktre zostay uyte w przykadowym wywoaniu s o c k e t p a i r przez uytkownika na pocztku tego podrozdziau. Trzy argumenty pokazane w defini cji funkcji s o c k e t p a i r (p, uap i retval) s argumentami przekazywanymi do odwoania systemowego przez jdro.
Utworzenie dwch gniazd i dwch deskryptorw
244-261 Funkcja s o c r e a t e jest woana dwukrotnie, tworzc dwa gniazda. Pierwszy z dwch deskryptorw zostaje alokowany przez f a 11 oc. Warto deskryptora jest zwracana w fd, a wskanik do odpowiadajcej struktury f i 1 e - w f pl. Ustawione zostaj flagi FREAD i FWRITE (poniewa mamy do czynienia z gniazdem dwukie runkowym - fuli duplex), ustalony jest typ pliku DTYPE_S0CKE T, wskanik f_ops jest ustawiony tak, by wskazywa na tablic piciu wskanikw funkq'i (rysunek 15.13 na stronie 460 w tomie 2), a wskanik f_data na struktur socket. Drugi deskryptor jest alokowany przez fal 1 oc i odpowiednia struktura file zostaje zainicjowana.
266
Poczenie dwch gniazd

262-270
s o c o n n e c t 2 tworzy danie PRU_C0NNECT2, ktre istnieje tylko w domenie unbcowej. Jeeli odwoanie systemowe tworzy gniazda strumieniowe, to po wyko naniu s o c o n n e c t 2 otrzymujemy ukad struktur pokazany na rysunku 17.28.
Jeeli tworzone s dwa gniazda datagramowe, wymagane s dwa wywoania soconnect2, przy czym kade wywoanie powoduje ustanowienie poczenia w jednym kierunku. Po drugim wywoaniu otrzymujemy ukad struktur pokaza ny na rysunku 17.29.
Sekcja 17.12
267
Kopiowanie dwch deskryptorw z powrotem do procesu

271 - 274
copyout kopiuje dwa deskryptory z powrotem do procesu.
Dwie instrukcje z komentarzami XXX ? ? ? po raz pierwszy pojawiy si w systemie 4.3BSD Reno. S one niepotrzebne, poniewa dwa deskryptory s zwracane do procesu przez c o py o u t . Zobaczymy, e odwoanie systemowe p i p zw raca oba deskryptory ustawiajc r e t v a l [ 0 ] i r e t v a l [ l ] , gdzie retval jest trzecim argum entem odwoania systemowego. Asemblerowa procedura w jdrze, obsugujca odwoania systemowe, zawsza zw raca dwie wartoci cakowite retval [0] i retval [ 1 ] w rejestrach procesora, jako cz w yni ku przetworzenia dowolnego odwoania systemowego. Procedura asemblerowa procesu uytkownika wywoujca odwoanie systemowe musi by odpowiednio zaprogram ow a na, tak by wykorzystywaa wartoci zaw arte w rejestrach i zw racaa je, tak jak tego oczekuje proces. Funkcja pi pe w bibliotece C rzeczywicie dziaa w taki sposb, w prze ciwiestwie do funkcji s o c k e t p a i r.
268
Rozdzia 17
Funkcja soconnect2
Funkcja ta (pokazana na rysunku 17.30) tworzy danie PRU_C0 N NECT2. Jest ona wywoywana jedynie przez odwoanie systemowe socketpai r . ------------------------------------------------------------------------------------------------225 s o c o n n e c t Z t s o l , so2) 226 s t r u c t s o ck et *sol; 227 s t r u c t s o ck et *so2; 228 ( 229 i nt s = s p l n e t ( ); 230 int error; 231 232 233 234 235 e r r or = ( * s o l - > s o _ p r o t o - > p r _ u s r r e q ) (sol, P R U _ C 0 N N E C T 2 , (struct m b u f *) 0, (struct mb uf *) so2, (str uc t m b u f *) 0); spl x (s ); return (error); )
uipc_socket.c
------------------------------------------------------------------------------------------------Rysunek 17.30 Funkcja soconnectZ
uipc_syscalls.c
17.13
Odwoanie systemowe pip
Odwoanie systemowe pip, pokazane na rysunku 17.31, jest niemal identyczne z odwoaniem systemowym socketpair. ------------------------------------------------------------------------------------------------645 646 647 6 48 6 49 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 pipe(p, uap, r e t v a l ) st r u c t proc *p; s t r u c t pi p e _ a r g s *uap; int retval[]; ( s tr u c t f i l e d e s c * fd p = p->p_fd; s tr u c t fi le *rf, *wf; s tr u c t s ocket *rso, *wso; int fd, error; if (error = s o c r e a t e ( A F _ U N I X , &rso, S 0 C K _ S T R E A M , 0)) r et ur n (error); if (error = s o c r e a t e ( A F _ U N I X , &wso, S 0 C K _ S T R E A M , 0)) goto freel; if (error = falloc(p, &rf, & f d )) goto free2; r e t v al [ 0] = fd; rf->f_flag = FREAD; rf->f_type = DTYPE_S0CKET; r f - > f _ o p s = S s oc ke t op s; r f - > f _ d a t a = (caddr_t) rso; if (error = fa lloctp, &wf, & f d )) goto free3; wf->f_flag = FWRITE; wf->f_type = DTYPE_S0CKET; w f - > f _ o p s = s o c ke t op s; w f - > f _ d a t a = (caddr_t) wso; r e t v a l [1] = fd; if (error = u n p _ c o n n e c t 2 ( w s o , rso)) goto free4; r et u rn (0); free4: ffree (w f) ; f dp -> f d _ o f i 1e s [ r e t v a l [1]] = 0; free3:
uipc_syscalls.c
Sekcja 17.14
danie P R U _A C C E P T
269
679 680 681 682 683 684 685
ffree ( rf ); f d p - > f d _ o f i l e s [ r e t v a l [0]] = 0; free2: (void) s o c l o s e ( w s o ) ; freel: (void) s o c l o s e t r s o ) ; r et u rn (error);
686 ]
------------------------------------------------------------------------------------------------Rysunek 17.31 Odwoanie systemowe p ip
uipc_syscalls.c
645-686 Wy woania funkcji s o c r e a t e tworz dwa gniazda domeny unbcowej. Jedy na rnica pomidzy tym odwoaniem systemowym a odwoaniem systemowym pip polega na tym, i p i pe ustala, e pierwszy z dwch deskryptorw moe by tylko czytany ( read-only), a drugi tylko zapisywany (write-only); oba deskryptory s zwracane przez argument ret v al , a nie przez copyout. Ponadto pi pe wywouje u n p _ c o n n e c t 2 bezporednio, a nie poprzez soconnect2.
Niektre wersje Unixa, na przykad SVR4, tworz potoki (pipes) z praw em zapisu i odczy tu dla obu kocw.
17.14
danie PRU_ACCEPT
Wikszo czynnoci zwizanych z akceptacj nowego poczenia dla gniazda strumieniowego jest wykonywanych przez inne funkcje jdra: s on ewc on n tworzy now struktur s o cke t i generuje danie PRU_ATTACH, a odwoanie systemowe a cce p t usuwa gniazdo z kolejki kompletnych pocze i wywouje soaccept. Ta ostatnia funkcja (strona 475 w tomie 2) tworzy tylko danie PRU_ACCEPT, co dla domeny unixowej pokazujemy na rysunku 17.32. ------------------------------------------------------------------------------------------------94 95 96 97 98 99 100 101 102 103 104 105 106 107 108
uipc_usrreq.c
ca s e PRU ACCEPT: /* * Naz wa p o c z o n e g o g n i az d a z o s t a j e p r z e k a z a n a z powrotem, * jeeli g n i a z d o b y o z w i z a n e i wc i j e s t e m y po cz en i * (nasz p a r t n e r m g j u z a m k n p o c z e n i e !). */ if ( u n p - > u n p _ c o n n && u n p - > u n p _ c o n n - > u n p _ a d d r ) { nam->m_len = unp->unp_conn->unp_addr->m_len: b c o p y ( m t o d ( u n p - > u n p _ c o n n - > u n p _ a d d r . c a d d r _ t ). m t o d (n am , c a ddr_t), (unsign e d) n a m - > m _ l e n ) ; 1 else 1 nam->m_len = sizeof(sun_noname); *( m to d ( n a m , s t r u c t s o c k a d d r *)) = sun noname; ) break;
------------------------------------------------------------------------------------------------Rysunek 17.32 danie PRU_ACCEPT

Zwrcenie nazwy cieki klienta
9 4 -1 0 8
uipc_usrreq.c
Jeeli klient wywoa funkcj bind i jeli jest nadal poczony, danie P R U _ A C C E P T kopiuje struktur s o c k a d d r _ u n zawierajc nazw cieki klienta do
270
bufora mbuf wskazywanego przez argument nam. W przeciwnym przypadku zostaje zwrcona pusta nazwa cieki (sun_noname).
17.15
danie PRU_DISCONNECT i funkcja unp_disconnect
Jeeli gniazdo jest poczone, odwoanie systemowe tworzy danie P R I L D I S C O N N E C T (rysunek 17.33). ------------------------------------------------------------------------------------------------91 92 93 c as e P R U _ D I S C O N N E C T : u n p _ d i s c o n n e c t (u n p ); break;
uipc_syscalls.c
------------------------------------------------------------------------------------------------Rysunek 17.33 danie PRU_DISCONNECT

9 1 -9 3
uipc_syscolls.c
Cae przetwarzanie jest wykonane w funkcji unp_di s c o n n e c t (rysunek
17.34.) ------------------------------------------------------------------------------------------------453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 vo id unp_disconnect(unp) s t r u c t u n pc b *unp; { s t r u c t u n p cb *un p2 = u n p - > u np _c on n ; i f (unp2 = = 0) return; u n p - > u n p _ c o n n = 0; sw i t c h (u n p - > u n p _ s o c k e t - > s o _ t y p e )
uipcjusrre.c
ca s e S 0 C K _ D G R A M : if ( u n p 2 - > u n p _ r e f s = = unp) unp2->unp_refs = unp->unp_nextref; else ( un p2 = u n p 2 - > u n p _ r e f s ; for (;;) 1 if (unp2 = = 0) panic("unp_disconnect''); if ( u n p 2 - > u n p _ n e x t r e f = = unp) break; unp2 = u n p 2 - > u n p _ n e x t r e f ; unp2->unp_nextref = unp->unp_nextref; u n p - > u n p _ n e x t r e f = 0; u n p - > u n p _ s o c k e t - > s o _ s t a t e &= ~ S S _ I S C O N N E C T E D ; break; c as e S O C K _ S T R E A M ; soi sdi s c o n n e c t e d (u n p - > u n p _ s o c k e t ); u n p 2 - > u n p _ c o n n = 0; soi sdi s c o n n e c t e d (u n p 2 - > u n p _ s o c k e t ); break; )
------------------------------------------------------------------------------------------------Rysunek 17.34 Funkcja u n p _ d i s c o n n e c t
uipcjusrrecj.c
Sekcja 17.15
danie PRU_D ISCO N N ECT i funkcja unp_disconnect
271
Sprawdzenie, czy gniazdo jest poczone
458-460 Jeeli to gniazdo nie jest poczone z innym gniazdem, funkcja zakacza przetwarzanie natychmiast. W przeciwnym razie czon unp _ c o n n otrzymuje w ar to 0, by zaznaczy, e to gniazdo nie jest poczone z innym.
Usunicie zamykanego datagramowego PCB z powizanej listy
4 6 2 -4 7 8
Ten fragment kodu usuwa blok PCB odpowiadajcy zamykanemu gniazdu z powizanej listy poczonych datagramowych blokw PCB. Na przykad, jeeli zaczniemy od rysunku 17.25 i zamkniemy lewe gniazdo, otrzymamy struktury danych przedstawione na rysunku 17.35. Poniewa wskanik u n p 2 - > u n p _ r e f s jest rwny unp (zamykany PCB znajduje si na pocztku powizanej listy), wskanik un p_next ref zamykanego, staje si pocztkiem powizanej listy.
Jeeli jeszcze raz zaczniemy od rysunku 17.25 i zamkniemy rodkowe gniazdo, otrzymujemy struktury danych przedstawione na rysunku 17.36. Tym razem blok PCB odpowiadajcy zamykanemu gniazdu nie znajduje si na pocztku powiza nej listy. Wskanik unp2 otrzymuje pocztkow warto odpowiadajc pocztko wi listy i poszukiwany jest blok poprzedzajcy zamykany PCB. unp2 pozostawio ny zostaje z wartoci odpowiadajc temu blokowi (lewy blok na rysunku 17.36). Wskanik u n p _ n e x t r e f zamykanego PCB jest nastpnie kopiowany do pola u n p _ n e x t r e f poprzedzajcego (unp).
Zakoczenie rozczania gniazda strumieniowego
4 7 9 -4 8 3
Poniewa strumieniowe gniazdo domeny unixowej moe by poczone tylko z jednym partnerem, rozczanie jest prostsze, bowiem powizana lista nie jest uywana. Wskanik unp_conn partnera otrzymuje warto 0 i funkcja soi sdi s c o n n e c t e d wywoywana jest dla obu gniazd.
272
Rozdzia 17
unp2 u n p c b {)
f
/
unp
zamknite gniazdo u n p c b {)
\ \
--------
u n p c b {)
unp_conn unp refs unp_nextref
unp_conn
NULL NULL
NULL NULL NULL f
unp_conn
^ ----- - unp_refs
NULL NULL
unp_refs unp_nextref
unp_nextref
connect("/tmp/foo")
connect("/tmp/foo")
bind("/tmp/foo )
V. Rysunek 17.36 Struktury danych z rysunku 17.25 po zamkniciu rodkowego gniazda
17.16
danie PRU_SHUTDOWN i funkcja unp_shutdown
danie P R U _ S H U T D O W N pokazane na rysunku 17.37 zostaje utworzone, gdy proces woa s h u t d o w n i zapobiega dalszemu wysyaniu jakichkolwiek danych. ------------------------------------------------------------------------------------------------109 110 111 112 case PRU_SH U T D 0 W N : socantsendmore(so): unp_shutdown(unp); break;
uipcjusrre.c
------------------------------------------------------------------------------------------------Rysunek 1 7 3 7 danie PRU_SHUTDOm
uipc_usrreq.c
109-112 s o c a n t s e n d m o r e ustawia flagi gniazda, tak by wysyanie jakichkolwiek dalszych danych byo zablokowane. Nastpnie woana jest funkcja u n p _ s h u t d o w n (pokazana na rysunku 17.38). ------------------------------------------------------------------------------------------------494 4 95 4 96 497 498 v oi d unp_shutdown(unp) s t r u c t unpc b *unp; ( st r u c t so ck e t *so; if ( u n p - > u n p _ s o c k e t - > s o _ t y p e = = S 0 C K _ S T R E A M && u n p - > u n p _ c o n n && (so = u n p - > u n p _ c o n n - > u n p _ s o c k e t ) ) socantrcvmore(so):
uipc_usrrecj.c
------------------------------------------------------------------------------------------------Rysunek 17.38 Funkcja u n p _ s h u t d o w n

Powiadomienie partnera dla gniazda strumieniowego
4 9 9 -5 0 2
4 99 500 501 502 )
uipcjusrre.c
W przypadku gniazda datagramowego nie robi si nic. Jeeli jednak gniaz do jest gniazdem strumieniowym cigle poczonym z partnerem i partner cigle posiada struktur socket, dla gniazda partnera woana jest funkcj asocant rcvmore.
Sekcja 17.17
danie PR U _A B O R T i funkcja unp_drop
273
17.17
danie PRU_ABORT i funkcja unp_drop
Na rysunku 17.39 pokazane jest danie PRU_AB0RT/ generowane przez socl ose, jeli gniazdo jest gniazdem odbierajcym, i poczenia cigle oczekuj w kolejce, socl ose generuje danie PRU_AB0RT dla kadego gniazda w kolejce niekomplet nych pocze oraz dla kadego gniazda w kolejce kompletnych pocze (strona 488 w tomie 2). -----------------------------------------------------------------------------------------------209
210 211 case P R U _ A B 0 R T : unp_drop(unp, ECONNABORTED); break;
uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 17.39 danie PRU_AB0RT

2 09-211
uipc_usrreq.c
Funkcja unp_drop (pokazana na rysunku 17.40) generuje bd ECONNABORTED. Na rysunku 17.14 widzielimy, e u n p _ d e t a c h rwnie wywouje u n p _ d r o p z ar gumentem ECONNRESET. ------------------------------------------------------------------------------------------------503 504 505 506 507 508 void un p _ d r o p ( u n p , errno) s t r u c t u n pcb *unp; int errno; ( st r u c t socket *so = u n p - > u n p _ s o c k e t ; s o - > s o _ e r r o r = errno; unp_disconnecttunp); if (s o - > s o _ h e a d ) ( s o - > s o _ p c b = (caddr_t) 0; m_freem(unp->unp_addr); (void) m _ f r e e ( d t o m ( u n p ) ); s o f ree(so); }
uipc_usrreq.c
509 510 511 512 513 514 515 516 517 )
------------------------------------------------------------------------------------------------Rysunek 17.40 Funkcja u n p _ d r o p

Zachowanie symbolu bdu i rozczenie gniazda
5 0 9 -5 1 0
uipc_usrreq.c
Warto s o _ e r r o r gniazda zostaje ustalona i jeeli gniazdo jest poczone, wywoana zostaje funkcja unp_di sconnect.
Usunicie struktur danych w kolejce odbiorczej serwera
5 1 1 -5 1 6
Jeeli wskanik gniazda s o_h e a d jest niepusty, oznacza to, e gniazdo znaj duje si aktualnie w kolejce niekompletnych pocze lub w kolejce kompletnych pocze gniazda odbierajcego. Wskanik struktury od s o cket do unpcb otrzy muje warto 0. Wywoanie m _ f r e e m zwalnia bufor mbuf zawierajcy nazw zwizan z odbierajcym gniazdem (przypominamy rysunek 17.20), a wywoanie m_f r e e zwalnia struktur unpcb. sofree zwalnia struktur socket. Gniazdo znaj dujce si w ktrej z dwch kolejek odbiorczych serwera nie moe mie skojarzo
274
nej struktury file, poniewa struktura taka jest alokowana przez accept przy usuwaniu gniazda z kolejki kompletnych pocze.
17.18
Rne dania
uipc_usrreq.c
Rysunek 17.41 pokazuje sze pozostaych da. ------------------------------------------------------------------------------------------------212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 c a s e PRU_SEN SE : ( (s t r u c t stat *) m ) - > s t _ b l k s i z e = s o - > s o _ s n d . s b _ h i w a t if ( s o - > s o _ t y p e = = S 0 C K _ S T R E A M && u n p - > u n p _ c o n n != 0) so2 = u n p - > u n p _ c o n n - > u n p _ s o c k e t : (( s tr uc t st at *) m ) - > s t b l k s i z e + = s o 2 - > s o r c v.sb 1 ( (s t r u c t stat *) m ) - > s t _ d e v = N 0 0 E V : i f ( u n p - > u n p _ i n o = = 0) u n p - > u n p _ i n o = unp_ino++; ( (s t r u c t stat *) m ) - > s t _ i n o = un p - > u n p _ i n o ; re t ur n (0); c as e PRU RCVOOB: re t ur n (EOP NO TS U PP ): c a s e PR IL SE N DO OB : e rr o r = EOPNO TS UP P ; break; case P R U _ S O C K A D D R : if ( u n p - > u n p _ a d d r ) ( nam->m_len = unp->unp_addr->m_len; b c o p y ( m t o d ( u n p - > u n p _ a d d r , c a d d r _ t ), m t o d( n am , c a ddr_t), (u ns i gn ed ) n a m- > m _ l e n ) ; ) else n a m - > m _ l e n = 0; break; c a s e PR U _ P E E R A D D R : if ( u n p - > u n p _ c o n n & & unp->unp_conn->unp_addr) ( nam->m_len - unp->unp_conn->unp_addr->m_len; bcopy(mtod(unp->unp_conn->unp_addr. cadd r _ t ) , mt o d t n a m , c a d dr _t ), (u ns ig n ed ) n am - > m _ l e n ) ; 1 el se n a m - > m _ l e n = 0; break; c as e P R U _ S L 0 W T I M O : break;
------------------------------------------------------------------------------------------------Rysunek 17.41 Rne dania PRU_xxx

danie PRLLSENSE
212-217
uipc_usrrecj.c
To danie jest generowane przez odwoanie systemowe f stat. Aktualna warto znaku przepenienia bufora wysykowego gniazda zostaje zwrcona jako czon s t_bl ksi ze struktury stat. Dodatkowo, jeli gniazdo jest gniazdem stru mieniowym, do tej wartoci dodana zostaje liczba bajtw znajdujcych si w tym momencie w buforze odbiorczym gniazda partnera. Gdy bdziemy omawia danie PRU_SEND w rozdziale 18.2, zobaczymy, e suma tych dwch wartoci jest prawdziw pojemnoci cznika" pomidzy dwoma poczonymi gniazdami strumieniowymi.
Sekcja 17.18
Rne dania
275
Czon st_dev otrzymuje warto N0DEV (warto staa zawierajca wszyst kie bity rwne 1, reprezentujca nie istniejce urzdzenie). 219 -221 Wzy i-node identyfikuj pliki w systemie plikw. Warto zwrcona jako numer i-node gniazda domeny unbcowej (czon s t _in o struktury stat) jest po prostu jednoznaczn wartoci otrzyman ze zmiennej globalnej unp_i no. Jeeli jeden z takich faszywych numerw i-node nie zosta jeszcze przypisany do stru ktury unpcb, warto zmiennej globalnej un p_i no zostaje przypisana, a nastpnie zmienna ta jest inkrementowana. Uywamy okrelenia faszywy", poniewa nu mery te nie odpowiadaj plikom rzeczywicie istniejcym w systemie plikw. S one po prostu tworzone w miar potrzeb z wartoci globalnego licznika. Jeeli gniazda domeny unixowej musiayby by zwizane z nazw cieki w systemie plikw (co nie jest wymagane), danie P R U _ S E N S E mogoby uywa wartoci st_dev oraz st_i no odpowiadajcych dowizanej nazwie cieki.
218 Zmienna globalna unp_i no powinna by inkrementowana przed przypisaniem wartoci, a nie po przypisaniu. Przy pierwszym wywoaniu f s t a t dla gniazda domeny unixowej po przeadowaniu jdra, warto wpisana do bloku unpcb gniazda bdzie rw na 0. Jeli jednak f s t a t wywoana zostanie jeszcze raz dla tego samego gniazda, poniewa zacho w ana warto jest 0, aktualna niezerowa warto unp_i no bdzie wpisana do PCB.
dania PRU_RCV00B i PRU.SENDOOB

223 - 227
Dane przesyane zwikszonym priorytetem (out-of-band) nie s obsugiwane przez domen rum ow.
danie PRU.SOCKADDR
2 2 8 -2 3 5
To danie zwraca adres protokou (nazw cieki w przypadku domeny unixowej). Jeli nazwa cieki zostaa dowizana do gniazda, u n p _ a d d r wskazuje na struktur mbuf zawierajc sockaddr_un z t nazw. Argument nam funkcji u i p c _ u s r r e q wskazuje na bufor mbuf alokowany przez woajc procedur w ktrej przekazany bdzie wynik. m _ c o p y robi kopi struktury adresowej gniaz da. Jeeli cieka nie zostaa dowizana do gniazda, pole dugoci otrzymanego bufora mbuf otrzymuje warto 0.
danie PRU_PEERADDR
2 3 6 -2 4 3
To danie jest obsugiwane podobnie do poprzedniego dania, z tym e wymagana nazwa cieki to nazwa zwizana z gniazdem poczonym z wywou jcym gniazdem. Jeeli wywoujce gniazdo zostao poczone z partnerem, w ar to u n p _ c o n n bdzie niezerowa.
Obsuga przez te dwa dania gniazda, ktre nie ma dowizanej nazwy cieki jest inna ni w przypadku dania P R I L A C C E P T (rysunek 17.32). Odwoania systemowe getsockname i getpeername zwracaj warto 0 w swoim trzecim argumencie, gdy brakuje nazwy. Natomiast funkcja a ccept w swoim trzecim argumencie zw raca warto 16 i nazw a cieki, zawarta w strukturze sockaddr_un zwrconej w drugim argumencie, zawiera tylko bajt zerowy. (Przypominamy, e sun_noname jest ogln struktur soc kaddr i jej rozmiar wynosi 16 bajtw.)
276
danie PRU_SLOWTIMO
24 4 -2 4 5
To danie nigdy nie powinno by wygenerowane, poniewa protokoy domeny unixowej nie uywaj adnych zegarw (licznikw czasu).
17.19
Podsumowanie
Implementaqa protokow domeny unbcowej, ktr przedstawilimy w tym roz dziale, jest nieskomplikowana i oczywista. Udostpnione s gniazda strumienio we i datagramowe, przy czym gniazda strumieniowe podobne s do TCP, gniazda datagramowe za do UDP. Do gniazd domeny unixowej mog zosta dowizane nazwy cieek. Serwer dowizuje (bind) swoj dobrze-znan nazw cieki (well-known pathname), a klient czy si (connect) z t ciek. Gniazda datagramowe mog rwnie zosta poczone i - podobnie jak w przypadku UDP - wicej ni jeden klient moe poczy si z jednym serwerem. Nienazwane gniazda domeny unixowej rwnie mog by utworzone przy pomocy funkcji soc k e t p a i r. Unixowe odwo anie systemowe pi pe tworzy dwa poczone wzajemnie gniazda domeny unixowej. Potoki w systemach wywodzcych si z systemu Berkeley s w rzeczywisto ci gniazdami strumieniowymi domeny unixowej. Blokiem kontrolnym uywanym z gniazdami domeny unixowej jest struktura unpcb. Te bloki - w przeciwiestwie do innych domen - nie s jednak przechowy wane w postaci powizanej listy. W zamian, gdy gniazdo domeny unbcowej musi znale inne gniazdo domeny unbcowej (przy co n n e c t lub sendto), blok kontrol ny u n p c b przeznaczenia zos taje znaleziony przez nalec do jdra funkcj poszu kiwania nazwy cieki (namei). Funkcja ta znajduje struktur vnode, a ta z kolei pozwala odszuka unpcb.
18
Protokoy domeny unixowej: 1/0 i przekazywanie deskryptorw

18.1 Wstp
W tym rozdziale kontynuujemy rozpoczt w poprzednim rozdziale prezentacj implementacji protokow domeny unixowej. Najpierw omwimy operacje wej cia/w yjcia (I/O ) - dania P R U _ S E N D i PRU_RCVD, a nastpnie zajmiemy si przekazywaniem deskryptorw.
18.2
dania PRU_SEND i PRU_RCVD
danie P RU_S E N D zostaje utworzone zawsze, gdy proces wpisuje dane lub infor macj kontroln do gniazda domeny unbcowej. Pierwsza cz dania, przetwa rzajca informacj kontroln, a nastpnie gniazda datagramowe, jest pokazana na rysunku 18.1.
Przetworzenie informacji kontrolnej na format wewntrzny
141 -142
Jeeli proces przekaza informacj kontroln uywajc sendmsg, to funkq'a unp_i nternal i ze zamienia wbudowane deskryptory na wskaniki file. Oma
wiamy t funkq w rozdziale 18.4.

Tymczasowe poczenie niepoczonego gniazda datagramowego
1 4 6 -1 5 3
Jeeli proces przekazuje struktur adresow gniazda zawierajc adres przeznaczenia (tzn. argument n a m jest niepusty), gniazdo nie moe by poczone. Gdy gniazdo jest poczone, zwracany jest komunikat o bdzie EI SC 0 N N . Niepo czone gniazdo zostaje poczone przez unp_connect. (To tymczasowe czenie niepoczonego gniazda datagramowego przypomina kod UDP pokazany na stro nie 788 w tomie 2.) Jeeli proces nie przekaza adresu przeznaczenia, zwrcony zostaje bd
E N O T C O N N dla niepoczonego gniazda. Przekazanie adresu nadawcy
154 -1 5 9
160-164
so2 wskazuje na struktur socket gniazda przeznaczenia. Jeeli wysyajce gniazdo ma dowizan nazw cieki, wskanik fro m wskazuje na struktur s o c k a d d r _ u n zawierajc nazw cieki. W przeciwnym przypadku f r o m wska zuje na sun_noname, ktra jest struktur so c k a d d r _ u n z zerowym pierwszym bajtem nazwy cieki.
278
Protokoy domeny unixowej: 1/0 i przekazywanie deskryptorw _______ Rozdzia 18
140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174
------------------------------------------------------------------------------------------------c as e PRU_SEND: if (control && (error = break; s w i t c h (s o -> so _ t y p e ) I u n p _ i n t e r n a l i z e ( c o n t r o l , p)))
uipc_usrrea.c
c as e S O C K _ D G R A M ;{ st r uc t s o c k a d d r *from; if (nam) ( if ( un p - > u n p _ c o n n ) { e r r or = E I S C O N N ; break; 1 e r r o r = u n p _ c o n n e c t ( s o . nam, p); if (error) break; } e l se ( if (u n p - > u n p _ c o n n = = 0) { e r r or = EN0TC0NN; break; ) ) so2 = u n p - > u n p _ c o n n - > u n p _ s o c k e t : if (u np - > u n p _ a d d r ) fr om = m t o d ( u n p - > u n p _ a d d r , s t ru ct s o c k a d d r *); else f r o m = & s u n _ no n am e; if ( s b a p p e n d a d d r ( & s o 2 - > s o _ r c v , from, m, c on t r o l ) ) ( sorwakeup(so2); m = 0; control = 0; ] el se er r o r = ENOBUFS; if (nam) unp_disconnect(unp); break; )
utpcjusrrecj.c
Rysunek 18.1
danie PRU_SEND dla gniazd datagramowych
Jeeli nadawca datagramu domeny unbcowej nie zwie nazwy cieki z gniazdem, odbior ca datagramu nie moe wysa odpowiedzi, poniewa nie zna adresu przeznaczenia (czyli nazwy cieki), ktry powinien by uyty w wywoaniu sendto. Inaczej jest w przypadku UDP, gdzie efemeryczny port zostaje automatycznie przypisany do niezwizanego gniazda datagramowego, przy pierwszym przesaniu datagramu do gniazda. UDP moe automatycznie wybra numer portu dla aplikacji midzy innymi dlatego, e odpowiednie numery portw uywane s tylko przez UDP. Nazwy cieek nie s jednak zarezerwowane dla gniazd domen unixowych. Automatyczne wybranie nazwy cieki dla niezwizanego gniazda domeny unixowej mogoby prowadzi do konfliktw w pniejszym czasie. Odpowied m oe by w ym agana lub nie, w zalenoci od aplikacji. Funkcja s y s 1 o g nie zwizuje cieki z datagram owym gniazdem domeny unixowej. Funkcja ta jedynie w ysy a komunikat do lokalnego demona sy s 1 ogd i nie oczekuje odpowiedzi.
Doczenie informacji kontrolnej, adresu i danych do kolejki odbiorczej gniazda

1 6 5 - 17 0
sbappendaddr docza informacj kontroln (jeli istnieje), adres nadawcy i dane do kolejki odbiorczej odbierajcego gniazda. Jeeli zostaje to przeprowa dzone pomylnie, to funkcja sorwakeup budzi" procesy oczekujce na odbir danych i wskaniki m oraz control otrzymuj warto 0, by zapobiec zwolnieniu tych wskanikw na kocu funkcji (rysunek 17.10). W przypadku bdu (prawdo podobnie z powodu braku miejsca na dane, adres lub informacj kontroln w ko lejce odbiorczej), zwrcony zostaje komunikat ENOBUFS.
Sekcja 18.2
dania P RU _SEN D i PRU _RCV D
279
Obsuga tego bdu jest inna ni dla UDP. W przypadku datagram ow ego gniazda dome ny unbcowej nadawca otrzymuje komunikat o bdzie powstaym w wyniku wasnej operacji wyjciowej zakoczonej bdem spowodowanym brakiem miejsca w kolejce odbiorczej. W przypadku UDP nadawca uznaje, e operacja wyjcia zakoczya si po mylnie, jeeli nie brakuje miejsca w kolejce wyjciowej interfejsu. Jeeli odbierajcy m odu UDP stwierdza, e brak jest miejsca w kolejce odbierajcego gniazda, wysya zwykle do nadaw cy komunikat ICMP o nieosigalnym porcie. Nadaw ca nie otrzym a jednak tego komunikatu, chyba, e poczy si z odbiorc (tak jak to opisano na stronach 774-775 w tomie 2). Dlaczego nadawca w domenie unbcowej nie zostaje zablokowany, a zamiast tego otrzy muje komunikat E N O B U FS? Gniazda datagram owe s tradycyjnie uwaane za zawodne i nie dajce gwarancji dostarczenia danych. W opracowaniu [Rago 1993] stwierdza si, e w SVR4 jest to zalene od dostawcy systemu, czy wczy w trakcie kompilacji jdra kontrol przepywu dla datagram owych gniazd domeny unbcowej, te czy nie.
Rozczenie tymczasowo poczonego gniazda

17 1 -1 7 2
unp_d i sc on n ec t rozcza poczone gniazdo.
Na rysunku 18.2 przedstawione jest przetwarzanie dania PRU_SEND dla gniazd strumieniowych. ------------------------------------------------------------------------------------------------uipc_usrreq.c
c as e S0 CK _ ST RE AM : 175 176 y/defi ne rcv ( &s o 2 - > s o _ r c v ) 177 #defi ne snd ( & so -> so _ sn d) 178 if ( s o - > s o _ s t a t e & S S _ C A N T S E N D M 0 R E ) l e r r o r = EPIPE; 179 break: 180 181 ) if ( u n p - > u n p _ c o n n = = 0) 182 p a n i c C " u i p c 3"); 183 184 so2 = u n p - > u n p c o n n - > u n p socket; /* 185 186 * W y s a n i e do o d p o w i e d n i e g o o d b i e r a j c e g o portu. 187 * Znak p r z e p e n i e n i a z o s t a j e z m n i e j s z o n y , by z a c h o w a * o d p o w i e d n i e " cinienie". * O b u d z e n i e p r o c e s w c z y t a j c yc h. 188 189 */ 190 if (c ontrol) { if ( s b a p p e n d c o n t r o l ( r c v , m, c o n tr o l) ) 191 192 control = 0: 193 ) el se 194 s b a p p e n d t r c v , m); s n d - > s b _ m b m a x -= 195 rcv->sb_mbcnt - unp->unp_conn->unp_mbcnt; 196 197 u n p - > u n p _ c o n n - > u n p _ m b c n t = r c v - >s b_ m bc nt ; 198 s n d - > s b _ h i w a t -= r c v - > s b _ c c - u n p - > u n p _ c o n n - > u n p _ c c ; 199 u n p - > u n p _ c o n n - > u n p _ c c = rc v- >sb_cc; sorwakeup(so2); 200 m = 0; 201 202 # u n d e f snd 203 # u n d e f rcv 204 break; 205 206 207 208 d ef au l t: p a n i c C u i p c 4"); ) break;
------------------------------------------------------------------------------------------------Rysunek 18.2 danie PRU_SEND dla gniazd strumieniowych
uipcjusrrecj.c
280 ______________ Protokoy domeny unixowej: 1/0 i przekazywanie deskryptorw _______ Rozdzia 18
Sprawdzenie stanu gniazda

1 7 5 -1 8 3
Jeeli wysyajca strona gniazda zostaa zamknita, to zostaje zwrcony komunikat EPIPE. Gniazdo musi by poczone. Jeli nie jest, wywoana zostaje funkq'a pani c, poniewa sosend sprawdza, czy gniazdo dajce poczenia jest poczone (strona 511 w tomie 2).
Pierwszy z tych warunkw prawdopodobnie jest pozostaoci z wczeniejszych wersji. Sprawdzenie takie wykonuje wczeniej s o s e n d (strona 511 w tomie 2).
Doczenie struktur mbuf do bufora odbiorczego

18 4 -1 9 4
s o 2 wskazuje na struktur soc k e t dla odbierajcego gniazda. Jeeli proces przekaza informacj kontroln uywajc sendmsg, bufory mbuf - kontrolne i za wierajce dane - zostaj doczone przez s b a p p e n d c o n t r o l do bufora odbiorcze go odbierajcego gniazda. Jeeli za informaq'a kontrolna nie bya przekazana, sbappend docza bufory mbuf zawierajce dane. Gdy wykonanie sbappendcontrol koczy si bdem, wskanik control otrzymuje warto zero, by nie nastpio odwoanie do m_f reem na kocu funkcji (rysunek 17.10), funkcja sbappendcontrol zwolnia bowiem ju mbuf. Aktualizacja licznikw nadawcy i odbiorcy
195 -1 9 9
Uaktualnione zostaj dwie zmienne nadawcy, s b _ m b m a x (maksymalna do puszczalna liczba bajtw we wszystkich mbuf w buforze) oraz s b_h iwa t (maksy malna dopuszczalna liczba bajtw danych znajdujcych si aktualnie w buforze). W tomie 2 (strona 511) zaznaczylimy, e ograniczenie na liczb bajtw w mbuf zapobiega zajmowaniu zbyt wielu buforw mbuf przez bardzo liczne mae komu nikaty. Dla strumieniowych gniazd domeny unixowej te dwa limity odnosz si do sumy dwch licznikw w buforze wysykowym i odbiorczym. Na przykad pocztkowa warto sb_hiwat jest 4096 zarwno dla bufora nadawczego, jak i dla bufora odbiorczego strumieniowego gniazda domeny unbcowej (rysunek 17.2). Jeeli na dawca wpisuje 1024 bajty do gniazda, nie tylko zmienna s b_c c odbiorcy (aktualna liczba bajtw w buforze gniazda) zmienia si z 0 na 1024 (tego si spodziewamy), ale rwnie s b_h iwa t nadawcy zmienia si z 4096 na 3072 (czego si nie spodzie walimy). W innych protokoach, takich jak TCP, warto s b _ h i w a t nie zmienia si nigdy, chyba e zostanie jawnie ustawiona przez opcj gniazda. Podobnie zachowuje si sb_mbmax: zwikszenie wartoci s b _ m b c n t odbiorcy wie si ze zmniejszeniem sb_mbmax nadawcy.
Ta manipulacja limitem nadawcy i aktualn wartoci licznika odbiorcy uzasad niona jest faktem, e dane wysyane przez strumieniowe gniazdo domeny unixowej nigdy nie s umieszczane w buforze wysykowym wysyajcego gniazda. Dane s doczane natychmiast do bufora odbiorczego odbierajcego gniazda. Nie ma powodu, eby marnowa czas na umieszczanie danych w kolejce wysykowej wysyajcego gniazda, a nastpnie - natychmiast lub pniej - przenosi dane do kolejki odbiorczej. Jeeli w buforze odbiorczym nie ma miejsca, nadawca musi
Sekcja 18.2
dania P RU _SEN D i PRU _RCV D
281
zosta zablokowany. Jednake, by funkcja sosend zablokowaa nadawc, ilo miejsca w buforze wysykowym musi odpowiada iloci miejsca w buforze od biorczym. Zamiast modyfikowa liczniki bufora wysykowego, gdy brak jest da nych w buforze wysykowym, atwiej jest zmodyfikowa ograniczenia dla bufora wysykowego, tak by zgodne byy z iloci miejsca w odpowiednim buforze odbiorczym.
198-199 Zajmiemy si tylko manipulacj wartoci sb _ h i w a t nadawcy i wartoci unp_cc odbiorcy (manipulacje sb _ m b m a x i u n p _ m b c n t s niemal identyczne). W tym miejscu rcv - >sb _ c c zawiera liczb bajtw w buforze odbiorczym, ponie
wa dane zostay wanie doczone do bufora odbiorczego. Naley zaznaczy, e u n p - > u n p_c onn->unp_ccjest poprzedni wartoci r c v - > s b_c c, tak wic rnica tych dwch zmiennych jest liczb bajtw wanie doczonych do bufora odbior czego (czyli liczb wpisanych bajtw). s n d - > s b _ h i w a t zostaje zmniejszona o t warto. Aktualna liczba bajtw w buforze odbiorczym zostaje zachowana w u n p - > u n p _ c o n n ->unp_cc, tak wic przy nastpnym przejciu tego kodu moemy obliczy, jak duo danych zostao wpisanych. Na przykad w momencie gdy gniazda zostaj utworzone, warto sb_hiwat wynosi 4096, a wartoci sb_cc i unp_cc odbiorcy s obie rwne 0. Jeeli przekaza ne zostaj 1024 bajty, to sb_hiwat nadawcy ma warto 3072, a zmienne sb_cc i unp_cc odbiorcy wynosz obie 1024. Zobaczymy pniej (rysunek 18.3), e gdy odbierajcy proces czyta te 1024 bajty, warto sb_hiwat zostaje zwikszona do 4096 bajtw, a sb_cc i unp_cc odbiorcy zostaj zmniejszone do 0.
Obudzenie procesw czekajcych na dane
200-201
s o r w a k e u p budzi procesy oczekujce na dane. m otrzymuje warto 0, by m_f reem nie zostaa wywoana na kocu funkcji, poniewa bufor mbuf znajduje
si teraz w kolejce odbiorczej. Ostatnim fragmentem kodu I/O jest danie P RU_RC V D przedstawione na rysunku 18.3. To danie jest tworzone przez sorecei ve (strona 541 w tomie 2), gdy dane s czytane z gniazda i protok ustawi flag PR_WANTRCVD, okrelon dla strumie niowego protokou domen unbcowych na rysunku 17.5. Zadaniem tego dania jest umoliwienie przejcia kontroli przez warstw protokou, gdy warstwa gniazd usuwa dane z bufora odbiorczego gniazda. Na przykad TCP uywa tego dania, by sprawdzi, czy powinna by wysana do partnera informaqa o roz miarze okna, poniewa bufor odbiorczy gniazda ma teraz wicej miejsca. Strumie niowy protok domen unbcowych uywa tego dania do uaktualnienia buforo wych licznikw nadawcy i odbiorcy.
282
------------------------------------------------------------------------------------------------113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 case P R U _ R C V D : s w i t c h ( so -> s o _ t y p e ) case S O C K _ D G R A M : p a n i c C u i p c 1"); /* N O T R E A C H E D */ ca s e S0 CK _S T RE AM : # d e f i n e rcv ( & s o- >s o_ r cv ) # d e f i n e snd (& so 2 - > s o _ s n d ) if ( u n p - > u n p _ c o n n = = 0) break; so2 = u n p - > u n p _ c o n n - > u n p _ s o c k e t ; /* * Ko re kc j a o g r a n i c z e po s t r o n i e n a d a w c y * i obudzeniepiszcych procesw */ snd->sb_mbmax += unp->unp_mbcnt - rcv->sb_mbcnt; u n p - > u n p _ m b c n t = rc v- > sb _m bc n t; s n d - > s b _ h i w a t += u n p - > u n p _ c c - rc v- >sb_cc; u n p - > u n p _ c c = rc v->sb_cc; sowwakeup(so2); # u n d e f snd # u n d e f rcv break; defaul t : panicCuipc 2 ): ) break; I
utpc_usrreq.c
---------------------------------------
uipc_usrreq.c
Rysunek 18.3
danie PRU_RCVD
Sprawdzenie, czy partner jeszcze istnieje
121 -122 Jeeli partner, ktry wpisa dane, zakoczy ju dziaanie, nie pozostaje nic do zrobienia. Zauwamy, e dane odbiorcy nie zostaj skasowane; liczniki bufora nadawcy nie mog by jednak uaktualnione, poniewa wysyajcy proces zamk n swoje gniazdo. Nie trzeba uaktualnia licznikw bufora, poniewa nadawca nie bdzie wicej wpisywa danych do gniazda.
Aktualizacja licznikw buforowych
123-131
so2 wskazuje na struktur socket nadawcy. Wartoci sb_mbmax i sb_hi wat zostaj uaktualnione odpowiednio do iloci przeczytanych danych. Na przykad unp->unp_cc minus r c v - >s b _c c daje liczb wanie przeczytanych bajtw.
Obudzenie piszcych procesw
132
Gdy dane z kolejki odbiorczej s czytane, warto sb_hi wat nadawcy jest zwikszana. Procesy czekajce (ewentualnie) na wpisanie danych zostaj wic zbudzone, poniewa - by moe - pojawio si teraz wolne miejsce w kolejce.
18.3
Przekazywanie deskryptorw
Przekazywanie deskryptorw (descriptorpassing) to technika komunikacji midzyprocesowej o duych moliwociach. Rozdzia 15 ksiki [Stevens 1992] przedsta wia przykady tej techniki w systemach 4.4BSD i SVR4. Cho odwoania systemo-
Sekcja 18.3
283
we rni si dla tych dwch implementacji, przykady te udostpniaj funkcje biblioteczne, ktre mog uczyni rnice systemowe niewidocznymi dla aplikacji. Historycznie przekazywanie deskryptorw zwane byo przekazywaniem praw dostpu (access rigths). Jedn z moliwoci reprezentowanych przez deskryptory jest uprawnienie do wykonywania operacji wejcia/wyjcia na obiektach. (Jeli nie mielibymy tego uprawnienia, jdro nie otworzyoby dla nas deskryptora.) Takie uprawnienie do operacji wejcia/wyjcia ma jednak znaczenie tylko w odniesienu do procesu, w ktrym deskryptor jest otwarty. Na przykad proste przekazanie pomidzy procesami deskryptora o numerze - powiedzmy - 4 nie przenosi uprawnie, poniewa deskryptor 4 moe nie by otwarty w odbierajcym proce sie, a nawet jeli jest otwarty, prawdopodobnie odnosi si do innego pliku ni plik w procesie wysyajcym. Deskryptor jest po prostu identyfikatorem, ktry ma znaczenie tylko w danym procesie. Przekazywanie deskryptorw pomidzy pro cesami, wraz z uprawnieniami zwizanymi z deskryptorami, wymaga dodatkowago wsparcia ze strony jdra. Jedynym typem uprawnie (praw dostpu), ktre mog by przekazywane pomidzy procesami, s deskryptory. Rysunek 18.4 pokazuje struktury danych uczestniczce w przekazywaniu de skryptorw pomidzy procesami. Wykonywane s kroki wymienione poniej.
proc{} ile{) s ocket{} u n p c b {}
Rysunek 18.4
Struktury danych uczestniczce w przekazywaniu deskryptorw
284
1. Zakadamy, e proces przedstawiony w grnej czci rysunku to serwer ze strumieniowym gniazdem domeny unbcowej, w ktrym odbierane s pocze nia. W dolnej czci rysunku pokazany jest klient. Klient tworzy strumieniowe gniazdo domeny unbcowej i czy to gniazdo z gniazdem serwera. Klient odwou je si do swojego gniazda jako do fdm, serwer odwouje si do swojego gniazda jako do fdi. W tym przykadzie uywamy gniazd strumieniowych. Zobaczymy jednak, e przekazywanie deskryptorw dziaa te w przypadku datagramowych gniazd domeny unbcowej. Zakadamy rwnie, efdi jest poczonym gniazdem serwera, zwrconym przez accep t (tak jak to byo pokazane w rozdziale 17.10). Dla uproszczenia nie pokazujemy struktur dla odbierajcego gniazda serwera. 2. Serwer otwiera inny plik i odwouje si do tego pliku jako do fdj. Moe to by plik dowolnego typu, do ktrego serwer odwouje si przez deskryptor: plik, urzdzenie, gniazdo, itd. Pokazujemy to jako plik ze struktur vnode. Licznik odwoa do pliku - czon f_count struktury fi 1 e - w chwili gdy plik zostaje otwarty po raz pierwszy rwny jest 1. 3. Serwer wywouje sendmsg dla fdi z informacj kontroln zawierajc typ S C M _R I G H T S i wartoci /d;'. W ten sposb przez strumieniowe gniazdo domeny unbcowej zostaje przekazany deskryptor" do odbiorcy, ktrym jestfdm w pro cesie klienta. Licznik odwoa zwizany z fdj w strukturze f i l e zostaje zwi kszony do 2. 4. Klient wywouje recvmsg dla fdm, okrelajc bufor kontrolny. Zwrcona infor macja kontrolna ma typ S C M _ R I G H T S i warto fdn, czyli najmniejszy nieuywa ny deskryptor klienta. 5. Po wykonaniu sendmsg w serwerze, serwer zwykle zamyka deskryptor, ktry wanie przekaza (fdj). Powoduje to zmniejszenie licznika odwoa do wartoci 1. Mwimy, e deskryptor jest w locie (inflight) pomidzy sendmsg i recvmsg. Przy okazji omawiania przekazywania deskryptorw natkniemy si na 3 liczniki przechowywane w jdrze. 1. f_ c o unt jest czonem struktury fi 1 e i zlicza aktualne odwoania do tej struktu ry. Gdy wiele deskryptorw wykorzystuje t sam struktur f i l e , licznik ten zlicza liczb deskryptorw. Na przykad - gdy proces otwiera plik - licznik f_count dla tego pliku otrzymuje warto 1. Jeli proces teraz wywoa fork, licznik f _c o unt otrzymuje warto 2, poniewa struktura f i l e jest teraz wyko rzystywana jednoczenie przez proces macierzysty i potomny. Kady z dwch procesw m a deskryptor, ktry wskazuje na t sam struktur f i l e . Gdy deskryptor zostaje zamknity, warto f_count zostaje zmniejszona o 1. Jeeli f_count osiga warto 0, odpowiadajcy plik lub gniazdo zostaj zamknite i struktura f i l e moe zosta uyta ponownie. 2. f_msgcount jest rwnie czonem'struktury f i l e , lecz czon ten m a warto niezerow tylko w czasie przekazywania deskryptora. Gdy deskryptor jest przekazywany przez sendmsg, czon f_msgcount zostaje zwikszony o 1. Gdy deskryptor zostaje otrzymany przy pomocy recvmsg, warto f_msgcount maleje
Sekcja 18.3
285
o 1. f_ m s g c o u n t zlicza odwoania do danej struktury file zwizane z deskryptorami w kolejkach odbiorczych gniazda (to znaczy aktualnie w locie).
3. u n p _ r i g h t s jest zmienn globaln jdra, zliczajc aktualnie przekazywane
deskryptory, czyli jest to cakowita liczba deskryptorw znajdujcych si aktu alnie w kolejkach odbiorczych gniazda. Dla otwartego deskryptora, nie przekazywanego w danym momencie, warto f_count jest wiksza ni 0. Na rysunku 18.5 pokazane s wartoci trzech liczni kw w trakcie przekazywania deskryptora. Przyjmujemy, e adne inne deskryp tory nie s w tym czasie przekazywane przez jdro.
f_count po o p e n nadawcy po s e n d m s g nadawcy w kolejce odbiorcy po r e c v m s g odbiorcy po cl o s e nadawcy 1 2 2 2 1 f_msgcount 0 1 1 0 0 unp_ri ghts 0 1 1 0 0
Rysunek 18.5 Wartoci zmiennych jdra w trakcie przekazywania deskryptorw Zakadamy tutaj, e nadawca zamyka deskryptor po zakoczeniu przetwarzania przez funkcj recvmsg odbiorcy. Nadawca moe zamkn te deskryptor w trak cie jego przesyania, przed wywoaniem recvmsg przez odbiorc. Na rysunku 18.6 pokazujemy wartoci trzech licznikw w tym ostatnim przypadku. Okazuje si, e rezultat kocowy jest ten sam - niezalenie od tego, czy nadawca zamyka de skryptor przed czy po wywoaniu recvmsg przez odbiorc. Widzimy rwnie na obu rysunkach, e sendmsg zwiksza wszystkie trzy liczniki, podczas gdy recvmsg zmniejsza tylko dwa ostatnie liczniki w tabeli.
f_count po o p e n nadawcy po s e n d m s g nadawcy w kolejce odbiorcy po cl o s e nadawcy w kolejce odbiorcy p o r e c v m s g odbiorcy 1 2 2 1 1 1 f_msgcount 0 1 1 1 1 0 unp_ri ghts 0 1 1 1 1 0
Rysunek 18.6 Wartoci zmiennych jdra w trakcie przekazywania deskryptorw Kod jdra odpowiedzialny za przekazywanie deskryptorw jest pojciowo nie skomplikowany. Przekazywany deskryptor zostaje zamieniony na odpowiadaj cy wskanik f i l e i przekazany do drugiego koca gniazda domeny unixowej. Odbiorca zamienia wskanik f i l e na najniszy nieuywany deskryptor odbie rajcego procesu. Pojawiaj si jednak problemy w przypadku wystpienia b dw. Na przykad odbierajcy proces moe zamkn swoje gniazdo domeny unixowej w czasie, gdy deskryptor znajduje si w kolejce odbiorczej.
286
Zamiana deskryptora na odpowiadajcy wskanik f i l e przez wysyajcy proces zwana jest zamian na format wewntrzny (intemalizing), a zamiana wskanika f i 1 e na najniszy deskryptor odbierajcego procesu zwana jest zamian na for mat zewntrzny (exernalizing). Funkcja u n p _ i n t e r n a l i z e bya wywoywana przez danie P RU_S END (rysunek 18.1) - jeeli proces przekaza informacj kon troln. Funkcja u n p _ e xt ernal i ze jest wywoywana przez s o r e c e i v e - jeeli bufor m b u f typu M T _ C 0 N T R 0 L jest czytany przez proces (strona 536 w tomie 2). Na rysunku 18.7 pokazana zostaa definiqa informacji kontrolnej przekazywanej przez proces do se n d m s g przy przekazywaniu deskryptora. Struktura tego same go typu jest wypeniana w rec vmsg przy odbieraniu deskryptora. Przykadowo, na rysunku 18.8 pokazujemy format informacji kontrolnej w przypadku, gdy proces wysya dwa deskryptory z wartociami 3 i 7. Pokazujemy rwnie dwa pola w strukturze msghdr okrelajce informacj kontroln. ------------------------------------------------------------------------------------------------251 s t r u c t c m s g h d r ( 252 u_in t cm sg_len; 253 int c m s g_ l ev el ; 254 int cm s g_ t y p e : 255 /* f o l l o w e d by u_ c h a r 256 ); /* l i c z n i k b a j t w c z n i e z n a g w k i e m /* p r o t o k w y s y a j c y */ /* typ s p e c y f i c z n y dla p r o t o k o u */ cm sg _ d a t a [ ] ; */ */
socket.h
------------------------------------------------------------------------------------------------Rysunek 18.7 Struktura cmsghdr
socket.h
msghdr{) msg_name ms g _namelen ms g _iov m s g iovlen msg_control m s g_controllen msg__f lags
cmsghdrO cmsg len cmsg_level cmsg_type /

20
20 SOL_SOCKET SCM _RIGHTS 3 7
Rysunek 18.8 Przykad informacji kontrolnej przy przekazywaniu dwch deskryptorw Proces moe w zasadzie wysa dowoln liczb deskryptorw przy pomocy jedne go wywoania sendmsg, ale aplikacje przekazujce deskryptory zwykle przekazu j tylko jeden deskryptor. Istnieje wewntrzne ograniczenie cakowitego rozmiaru informacji kontrolnej. Informacja ta musi si zmieci w pojedynczym buforze mbuf (ograniczenie to jest wprowadzone przez funkcj sockargs, wywoywan przez funkcj s end i t - patrz odpowiednio strony 467 i 504 w tomie 2), co ograni cza liczb deskryptorw przekazywanych przez dowolny proces do 24.
W e wczeniejszych ni 4.3BSD Reno wersjach systemu czony m s g _ c o n t r o l i m s g _ c o n t r o l len struktury m s g h d r nazwane byy m s g _ a c c r i g h t s i m s g _ a c c r i g h t s len. Pole c m s g _ l en - zawsze rwne m s g _ c o n t r o l 1 en - jest zbdne. Pole to ma umoliwia pojawienie si wicej ni jednej informacji kontrolnej w pojedynczym buforze kontrol
Sekcja 18.3
287
nym. Zobaczymy jednak pniej, e kod nie wykorzystuje tej moliwoci w ym agajc, by tylko jedna informaq'a kontrolna znajdowaa si w jednym buforze kontrolnym. Jedynym rodzajem informacji kontrolnej dopuszczalnym w domenie internetowej jest zw rot adresu IP przeznaczenia dla datagram u UDP (strona 802 w tomie 2). Protokoy OSI obsuguj cztery rne typy informacji kontrolnej uywanej do celw specyficznych dla OSI.
Rysunek 18.9 podsumowuje funkcje wywoywane przy wysyaniu i odbieraniu deskryptorw. (Funkcje zacieniowane omawiane s w tym tekcie, pozostae przedstawione zostay w tomie 2.)
288
Rysunek 18.10 podsumowuje czynnoci funkcji unp_i nternal i ze oraz unp_external i ze dotyczce deskryptorw i wskanikw f i 1 e w buforze kontrolnym uytkownika oraz w buforze mbuf jdra.
| unp _ i n t e r n a l i z e
V zastpuje deskryptory z wysyajcego procesu j odpowiednimi wskanikami file
s b a p pendcontrol
proces wysyajcy docza dane i kontrolne bufory mbuf do buforu odbiorczego odbierajcego gniazda
....... H .........
proces odbierajcy
f
jdro mbut{}
] unp _ e x t e r n a l i z e v zastpuje wskaniki file deskryptorami
wanie alokowanymi w odbierajcym procesie
R ysunek 18.10
Operacje wykonywane przez u np _ i n t e r n a l 1ze i u n p _ e x t e r n a 1 i z e
18.4
Funkcja unpjnternalize
Funkcja unp_i nternal i ze zostaa pokazana na rysunku 18.11. Jak widzielimy na rysunku 18.1, funkcja ta jest woana przez ui pc_us rreq, gdy utworzone zostaje danie P RU_S E N D i proces przekazuje deskryptory.
Sekcja 18.4
Funkcja unpjnternalize
289
------------------------------------------------------------------------------------------------553 554 555 556 557 558 559 560 561 562 563 int u n p _ i n t e r n a l i z e ( c o n t r o l , p) struct mbuf * c o n t r o l ; s t r u c t proc *p; ( s t r u c t fi le d e s c * fd p = p->p_fd; s t r u c t c m s g h d r * cm = m t o d ( c o n t r o l , struct c m s g h d r *); s t r u c t file **rp; s t r u c t file *fp; i nt i , fd; int oldfds;
uipc_usrreq.c
564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 ]
if ( c m - > c m s g _ t y p e != S C M _ R I G H T S || c m- >c m s g _ l e v e l != S 0 L _ S 0 C K E T c m - > c m s g _ l e n != c o n t r o l - > m _ l e n ) r eturn (E I N V A L ) ; oldfds = (cm->cmsg_len s iz e o f ( * c m ) ) / s i z e o f ( i n t ) : rp = (struct file **) (cm + 1); for (i = 0; i < oldfds: i++) < fd = * ( i n t *) rp++; if (( unsigned) fd >= fd p- >f d _n fi l es || f d p - > f d _ o f i 1 e s [ fd] = NULL) re tu rn (E B A D F ); ] rp = (struct file **) (cm + 1); for (i = 0; i < oldfds; i++) ( fp = f d p - > f d _ o f i l e s [ * ( i n t *) rp]; * r p + + = fp; fp -> f _ c o u n t + + ; fp->f_msgcount++; un p_ ri g h t s + + ; ) re t ur n (0) ;
||
------------------------------------------------------------------------------------------------Rysunek 18.11 Funkcja unp_ in te rn a l i ze

Sprawdzenie pl cmsghdr
564-566
uipc_usrrec\.c
Struktura cm s g h d r uytkownika musi poda typ S C M _ R I GHTS, poziom S0L_S0CKET. Pole dugoci tej struktury musi odpowiada iloci danych w mbuf (pole to jest kopi czonu m sg_ contro l len struktury m s g h d r przekazanej przez proces do funkcji sendmsg).
Sprawdzenie wanoci przekazywanych deskryptorw
567-574
ol dfds otrzymuje warto rwn liczbie przekazywanych deskryptorw, a rp wskazuje na pierwszy deskryptor. Dla kadego przekazywanego deskryptora ptla for sprawdza, czy deskryptor jest nie wikszy ni maksymalny deskryptor aktualnie uywany przez proces i czy wskanik jest niezerowy (czyli czy deskryp tor jest otwarty). Zastpienie deskryptorw wskanikami file
575 -578
Wskanik r p zostaje ustawiony tak, by wskazywa na pierwszy deskryptor, a ptla f o r zastpuje kady deskryptor przez wskanik f p struktury file.
290 ______________ Protokoy domeny unixowej: 1/0 i przekazywanie deskryptorw
Rozdzia 18
Aktualizacja wartoci trzech licznikw

579-581
Wartoci czonw
f_count
f_msgcount
struktury
f i 1e
zostaj zwikszo-
zostaje zamknity, drugi natomiast jest zmniejszany przez u n p_e x terna! i ze. Do datkowo zmienna globalna unp_ri ghts jest zwikszana przez unp _ i n t e r n a l ize dla kadego przekazanego deskryptora. Zobaczymy, e warto ta zostanie nastpnie zmniejszana przez u np_ extern al i ze dla kadego otrzymanego de skryptora. Warto tej zmiennej zawsze rwna si liczbie deskryptorw w locie. Na rysunku 17.14 zobaczylimy, e gdy gniazdo domeny unixowej jest zamykane i zmienna ta m a niezerow warto, to nastpuje uruchamianie funkcji zbierajcej niepotrzebne dane u n p_g c (garbage collection) - poniewa zamykane gniazdo moe zawiera deskryptory w locie w kolejce odbiorczej.
18.5
Funkcja unp_externalize
Przyjrzyjmy si funkcji u np_ extern al i ze pokazanej na rysunku 18.12. Jest ona wywoywana jako dom _exter nal i ze przez s o r e c e i v e (strona 536 tomu 2), gdy bufor mbuf typu M T _ C 0 N T R 0 L zostaje znaleziony w kolejce odbiorczej gniazda i jeli proces jest przygotowany do przyjcia informacji kontrolnej. ------------------------------------------------------------------------------------------------523 int 524 u n p _ e x t e r n a l i z e ( r i g h t s ) 525 s tr u c t m b uf *rights; 526 ( s tr uc t proc *p = curproc; /* X XX */ 527 i; 528 i nt s tr uc t c m s g h d r * c m = m t o d tr i gh ts , s t r u c t c m s g h d r *); 529 s tr u c t file ** rp = (struct file **) (cm + 1): 530 s tr u c t fi 1e * f p ; 531 i nt n ew f ds = ( c m- > cm sg len - s i z e o f ( * c m ) ) / s i z e o f ( i n t ) 532 f; int 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 } i f (!fdav ai l( p , n ew f ds )) ( for (i = 0; i < newfds; i++) { fp = *rp; unp_discard(fp); * rp + + = 0; 1 r eturn (EMSGSIZE); ) for (i = 0 ; i < newfds; i++) ( if (fda 1 1 o c (p , 0, &f)) pani c ( " u n p _ e x t e r n a l i z e " ) ; fp = * r p ; p - > p _ f d - > f d _ o f i l e s [ f ] = fp; f p ' > f _ m s g c o u n t - -; unp_ri g h t s - -; * ( i nt *) rp++ = f ; ) r e t u r n (0);
uipc_usrreq.c
uipc_usrreq.c Rysunek 18.12 Funkcja u n p _ e x te rn a 1 iz e
Sekcja 18.6
Funkcja unp_discard
291
Sprawdzenie, czy proces ma wystarczajco wiele dostpnych deskryptorw

532-541
newfds jest licznikiem wskanikw f i 1 e w aktualnie przetwarzanym na format zewntrzny buforze mbuf. f da v a i 1 to funkcja jdra sprawdzajca, czy proces m a wystarczajco wiele dostpnych deskryptorw. Jeeli brakuje deskryp torw, to dla kadego deskryptora woana jest funkcja unp_di scard (pokazana w nastpnym podrozdziale) i komunikat EMSGSIZE jest zwracany do procesu.
Zamiana wskanikw file na deskryptory
542-546
Dla kadego przekazywanego wskanika fi 1 e alokowany jest przez naj niszy nieuywany deskryptor procesu f da 11 oc. Drugi, zerowy argument funkcji fdal 1 oc informuje, e struktura f i l e nie ma by alokowana, poniewa w tym punkcie potrzebny jest wycznie deskryptor. Deskryptor zostaje zwrcony przez fdal 1 oc w f. Deskryptor w procesie wskazuje na wskanik f i l e .
Zmniejszenie dwch licznikw
5 47 - 5 48
Dwa liczniki - f_msgcount i unp_ri ghts - zostaj zmniejszone dla kadego przekazanego deskryptora.
Zastpienie wskanikw file deskryptorem
549
Alokowany przed chwil deskryptor zastpuje wskanik f i l e w buforze mbuf. Jest to warto zwracana do procesu jako informacja kontrolna.
Co si dzieje, jeeli bufor przekazany przez proces do recvm sg nie jest wystarczajco duy, by pomieci otrzymane deskryptory? u n p _ e x te rn a l i ze w dalszym cigu alokuje w procesie dan liczb deskryptorw i wszystkie deskryptory wskazuj na waciw struktur f i l e . r e c v i t (strona 521 w tomie 2) zw raca jednak tylko informacj kontroln mieszczc si w buforze alokowanym przez proces. Jeeli powoduje to obcicie informa cji kontrolnej, w polu m s g _flag s ustawiona zostaje flaga MSG_CTRUNC. Proces m oe sprawdzi warto tej flagi przy zakoczeniu przetwarzania przez recvms g.
18.6
Funkcja unp_discard
Funkcja u n p _d i s c a r d , pokazana na rysunku 18.13, bya wywoywana na rysunku 18.12 dla kadego przekazywanego deskryptora, gdy okazywao si, e odbieraj cy proces nie mia wystarczajco wielu dostpnych deskryptorw. ------------------------------------------------------------------------------------------------726 727 728 729 void unp_discard(fp) s t r u c t file *fp: { f p - > f _ m s g c o u n t - -; unp_ri g h t s - -: (void) c i o s e f (f p . (struct proc *) NULL);
uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 18.13 Funkcja u np _disca rd
730 731 732 733 ]
uipc_usrreq.c
292
Zmniejszenie dwch licznikw

730-731
Liczniki f_msgcount i unp_ri ghts zostaj zmniejszone.
Wywoanie closef
732
S truktura f i l e zostaje zamknita przez funkcj c l o s e f , ktra zmniejsza f_count i wywouje funkcj fo_cl ose deskryptora (strona 487 w tomie 2), jeeli f_count ma teraz warto 0.
18.7
Funkcja unp_dispose
Przypominamy (rysunek 17.14), e unp_detach woa s o r f l ush przy zamykaniu gniazda domeny unixowej, jeli zmienna globalna unp_rights jest niezerowa (tzn. deskryptory s w locie). Jedna z ostatnich czynnoci wykonywanych przez s o r f l ush (strona 485 w tomie 2) to wywoanie funkcji domeny dom_di spose, jeeli funkcja ta zostaa zdefiniowana i jeeli protok ustawi flag PR_RIGHTS (rysunek 17.5). To wywoanie jest wykonywane, poniewa bufory mbuf, ktre maj wanie by zwolnione, mog zawiera deskryptory w locie. Poniewa liczni ki f_count i f_msgcount w strukturze fi 1 e oraz zmienna globalna unp_ri ghts byy zwikszone przez unp_i nternal i ze, wszystkie te liczniki musz by skory gowane, tak by uwzgldnione byy deskryptory, ktre zostay przekazane, lecz nie zostay nigdy odebrane. Funkcj dom_di spose dla domeny unbcowej jest unp_di spose (rysunek 17.4), ktr pokazujemy na rysunku 18.14. ------------------------------------------------------------------------------------------------682 683 684 685 686 687 void unp_dispose(m) s t r u c t m b u f *m; { if (m) u n p_ s ca n( m, unp_discard);
uipc_usrreq.c
-------------------------------------------------------------- 1 ---------------------------------Rysunek 18.14 Funkcja u n p _ d i s p o s e

Wywoanie unp_scan
686 - 6 8 7
688 )
uipc_usrreq.c
Cae przetwarzanie wykonywane jest przez funkcj unp_s c a n (omawiamy j w nastpnym podrozdziale). Drugim argumentem w wywoaniu funkcji jest wskanik do funkcji unp_di scard, ktra - jak zobaczylimy w poprzednim pod rozdziale - usuwa deskryptory znalezione przez unp_scan w buforach kontrol nych kolejki odbiorczej gniazda.
Sekcja 18.8
Funkcja unp_scan
293
18.8
Funkcja unp_scan
unp_scan jest wywoywana z unp_di spose, z drugim argumentem unp_di scard, a pniej z unp_gc,zdrugim argumentem unp_mark. Funkcj unp_scan pokazuje my na rysunku 18.15. ------------------------------------------------------------------------------------------------6 89 69 0 691 69 2 693 694 695 696 697 69 8 void un p _ s c a n ( m O , op) s t r u c t mb uf *m0; v oi d (*op) (struct fi le *); ( s t r u c t mb uf *m; s t r u c t file **rp; s t r u c t c m sg hd r *cm; i nt i; int qfds; w h i l e (mO) ( fo r (m = mO; m; m = m - > m _ n e x t ) if ( m - > m _ t y p e = = M T _ C 0 N T R 0 L U m - > m _ l e n >= s i z e o f ( * c m ) ) ( cm = mtodtm, s truct c m s g h d r *); if ( c m -> c ms g_ le v el != S O L _ S O C K E T |] c m - > c m s g _ t y p e != S C M _ R I G H T S ) cont inue; qf ds = ( c m - > c m s g _ l e n - si z eo f *cm) / s i z e o f t s t r u c t file *); rp = (struct file **) (cm + 1); fo r (i = 0; i < qfds; i++) (*op) (*rp++); break; /* XXX, ale d a j e o s z c z d n o c z a s u mO = m0->m_nextpkt;
uipc_usrreq.c
69 9 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 )
*/
) uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 18.15 Funkcja unp_scan

Poszukiwanie kontrolnych buforw mbuf
699-706 Funkcja ta przeglda acuch mbuf dla kadego pakietu w kolejce odbior czej gniazda (argument m0), szukajc bufora mbuf typu MT_C0NTR0L. Jeeli infor macja kontrolna zostaje znaleziona, gdy aktualnym poziomem jest S0L_S0CKET, a typem SCM_RIGHTS, to mbuf zawiera nigdy nie odebrane deskryptory w locie.
Zwolnienie wskanikw file
707-716 qf ds to liczba tablicowych wskanikw f i 1 e w komunikacie kontrolnym. Dla kadego wskanika fi 1 e woana jest funkcja op (unp_di scard lub unp_mark). Argumentem funkcji o p jest wskanik f i l e zawarty w komunikacie kontrolnym. Po przetworzeniu tego kontrolnego bufora mbuf, break powoduje przejcie do nastpnego pakietu w buforze odbiorczym.
Komentarz XXX pojawia si, poniewa b r e a k zakada (susznie), e istnieje tylko jeden kontrolny bufor mbuf w acuchu mbuf.
294
__________ Protokoy domeny unixowej: 1/0 i przekazywanie deskryptorw _______ Rozdzia 18
18.9
Funkcja unp_gc
Widzielimy ju jedn z form zbierania niepotrzebnych danych (garbage collection) dla deskryptorw w locie: w u n p_d e t a c h za kadym razem, gdy gniazdo domeny unixowej jest zamykane i deskryptory s w locie, sorfl ush zwalnia deskryptory w locie zawarte w kolejce odbiorczej zamykanego gniazda. Deskryptory przeka zywane przez gniazda domeny unixowej mog by jednak zgubione" w innych okolicznociach. Moe si to zdarzy na trzy sposoby. 1. Gdy deskryptor jest przekazywany, bufor mbuf typu M T _ C 0 N T R 0 L jest umiesz czany przez s b a p p e n d c o n t r o l w kolejce odbiorczej gniazda (rysunek 18.2). Jeli jednak odbierajcy proces wywouje r e cvm sg bez zaznaczenia, e chce odbiera informacje kontrolne, lub wywouje jedn z innych funkcji wejcia, ktre nie mog odbiera informacji kontrolnych, to sorecei ve woa MFREE, by usun i zwolni mbuf typu MT_ C 0 N T RO L z buforu odbiorczego gniazda (strona 536 tom 2). Jeli struktura f i l e , do ktrego odwoywa si ten bufor mbuf, zostaje zamknita przez nadawc, to liczniki f _ c o u n t i f _ m s g c o u n t struktury file maj warto 1 (przypominamy rysunek 18.6), a zmienna globalna u n p _ r i g h t s w dalszym cigu pokazuje, e deskryptor jest w locie. Jest to struktura f i 1 e, do ktrej nie odwouje si i nigdy nie bdzie si odwoywa aden deskryptor. Struktura ta znajduje si jednak w powizanej licie aktyw nych struktur f i l e .
Na stronie 305 ksiki [Leffler i inni 1989] zaznaczono, e problem polega na tym, i jdro nie pozwala, by protok mia dostp do komunikatu po jego przekazaniu do warstwy gniazda w celu dostarczenia do adresu przeznaczenia. Ci sami autorzy zauwaaj te, e problem ten powinien by zaatwiony przez specyficzn dla domeny funkq' w yw oyw a n, gdy bufor mbuf typu M T _ C O N T R O L jest zwalniany.
2. Gdy deskryptor jest przekazywany, a odbierajce gniazdo nie m a miejsca na
komunikat, deskryptor w locie zostaje usunity bez ladu. Nie powinno si to nigdy zdarzy dla strumieniowego gniazda domeny unbcowej, poniewa - jak widzielimy w rozdziale 18.2 - znak przepenienia nadawcy odzwierciedla ilo miejsca w buforze odbiorcy, co powoduje zablokowanie nadawcy a do czasu, gdy w buforze odbiorczym znajdzie si wystarczajco duo miejsca. Bd moe si jednak zdarzy dla gniazda datagramowego. Jeli brakuje miej sca w buforze odbiorczym, funkcja s b a p p e n d a d d r (woana na rysunku 18.1) zwraca 0, e r r o r otrzymuje warto E N 0 B U F S i kod oznaczony etykiet re l e a s e (rysunek 17.10) kasuje bufor mbuf zawierajcy informacj kontroln. Prowadzi to do tej samej sytuacji, co poprzednio: pojawia si struktura f i l e , do ktrej nie odwouje si i nigdy nie bdzie odwoywa si aden deskryptor. 3. Gdy gniazdo domeny unbcowej fdi jest przekazywane do innego gniazda do meny unixowej fdj, a fdj jest rwnie przekazywane do fdi. Jeeli oba gniazda domeny unixowej zostaj nastpnie zamknite bez odebrania przekazywanych deskryptorw, deskryptory mog by zagubione. Zobaczymy, e problem ten jest jawnie obsugiwany w BSD (rysunek 18.18).
Sekcja 18.9
Funkcja unp_qc
295
W pierwszych dwch przypadkach kluczowe znaczenie ma fakt, e zagubiona" struktura file ma warto f _cou nt rwn f _ m s g c o u n t (tzn. jedyne odwoania do tego deskryptora znajduj si w komunikatach kontrolnych) oraz e adne infor macje kontrolne znalezione w kolejkach odbiorczych gniazd domeny unixowej w jdrze nie odwouj si do tej struktury fi 1 e. Jeeli warto f_co un t struktury jest wiksza ni f_msgcount, to rnica jest liczb deskryptorw w procesach, ktre odwouj si do tej struktury, a wic struktura nie zostaa zagubiona. (W po prawnie dziaajcym systemie warto f_ c o u n t nigdy nie jest mniejsza ni f_ m s g c o u n t .) Jeeli warto f _c o u n t ma warto rwn f_ m s g c o u n t, ale do stru ktury f i l e odwouje si komunikat kontrolny w gniedzie domeny unixowej, to struktura nie zostaa zagubiona, poniewa jaki proces moe cigle otrzyma deskryptor z tego gniazda. Funkcja zbierania niepotrzebnych danych, unp_gc, znajduje takie zagubione stru ktury f i l e i je odzyskuje. Struktura f i l e zostaje odzyskana przez wywoanie cl ose f (pokazano to na rysunku 18.13), poniewa cl o sef zwraca nieuywan struktur f i l e do zasobnika wolnych struktur w jdrze (kemeYs free pool). Za uwamy, e funkcja ta jest woana tylko wtedy, gdy istniej deskryptory w locie, to znaczy, gdy warto unp_ri ghts jest niezerowa (rysunek 17.14) i gdy jakie gniazdo domeny unixowej zostaje zamknite. Dlatego te funkcja ta jest rzadko wykonywana i tylko pozornie stanowi rdo dodatkowego obcienia komputera. Do zbierania niepotrzebnych danych funkcja unp_gc uywa algorytmu typu zaznaczanie-wymiatanie (mark-and-sweep). Pierwsza cz funkcji - zaznaczanie przeglda wszystkie struktury fil e w jdrze i zaznacza te, ktre s uywane. Uywana struktura f i 1 e, to taka, do ktrej odwouje si deskryptor w procesie lub komunikat kontrolny w kolejce odbiorczej gniazda domeny unixowej (tzn. stru ktura odpowiada deskryptorowi w locie). Druga cz funkcji - wymiatanie odzyskuje niezaznaczone, czyli nieuywane struktury f i l e . Pierwsza cz funkcji unp_gc jest pokazana na rysunku 18.16. uipcjusrrecj.c
587 void 5 88 u n p _ g c ( ) 589 ( 5 90 st r u c t fil e *fp, *nextfp; 591 s t r u c t s oc ke t * s o ; 592 s t r u c t fil e ** ex t r a _ r e f , **fpp; 593 int nunref, i; 594 595 596 597 598 599 600 601 602 603 604 605 606 if ( u n p_ g ci ng ) return; unp_gci ng = 1; u n p _ d e f e r = 0; for (fp = fi 1 e h e a d .1h _ f i r s t ; fp != 0; fp = f p - > f _ l i s t . l e _ n e x t ) f p - > f _ f 1 ag &= - ( F M A R K | F D E F E R ) ; do ( for (fp = f i 1e h e a d .1 h _ f i r s t ; fp != 0; fp = f p - > f _ l i s t .1 e _ n e x t ) { if ( f p - > f _ c o u n t = = 0) conti nue; if (f p ->f _ f lag & FDEFER) ( f p -> f _ f 1 ag &= -F D EF E R ; u n p _ d e f e r - -;
296

607 608 6 09 610 611 612 613 614 615 616 61 7 6 18 61 9 6 20 621 622 ] else ( if (f p - > f _ f 1 ag & FMARK) continue: if ( f p - > f _ c o u n t = = f p - > f _ m s g c o u n t ) c ontinue; f p -> f _ f 1 ag 1= FMARK; 1 if ( f p - > f _ t y p e != D T Y P E _ S O C K E T || (so = (struct s oc k e t *) f p - > r _ d a t a ) = = 0) continue; if ( s o - > s o _ p r o t o - > p r _ d o m a i n != & u n i x d o m a i n |[ ( s o - > s o _ p r o t o - > p r _ f l a g s & P R _ R I G H T S ) 0) c ontinue; u n p _ s c a n ( s o - > s o _ r c v . s b _ m b , unp_m ar k ); ] } w h i l e (unp_de fe r );
------------------------------------------------------------------------------------------------Rysunek 18.16 Pierwsza cz funkcji unp_gc - zaznaczanie

Zabezpieczenie przed rekursywnym wywoaniem funkcji
5 94 - 5 9 6
uipcjusrrecj.c
Zmienna globalna unp_gci ng zapobiega rekursywnemu wywoaniu funk cji: unp_gc moe bowiem wywoa funkcj sorfl ush, ktra wywouje unp_di spose, a ta z kolei wywouje u np _ d i scard, ktra wywouje unp_detach, ktra woa ponownie unp_gc.
Usunicie flag FMARK i FDEFER
5 9 8 - 59 9
Ta pierwsza ptla przechodzi przez wszystkie struktury file w jdrze i usuwa flagi FMA RK i FDEFER.
Powtarzanie a unp_defer osignie 0
60 0- 6 2 2
Ptla do whi 1 e jest wykonywana do momentu, gdy zmienna unp_defer staje si rwna zero. Zobaczymy, e ta flaga zostaje ustawiona, gdy znajdujemy struktur f i l e , ktr wczeniej przetworzylimy i ktr uznalimy za nieuywa n, cho struktura ta w rzeczy wistoci jest uywana. Gdy taka sytuacja m a miejsce, moemy by zmuszeni do ponownego przejcia przez struktury f i l e , poniewa istnieje moliwo, e struktura, ktr wanie oznaczylimy jako zajt, jest w rze czywistoci gniazdem domeny unixowej zawierajcym odnoniki do f i 1 e w ko lejce odbiorczej.
Ptla dla wszystkich struktur file
601 - 603
W tej ptli analizowane s wszystkie struktury f i 1 e w jdrze. Struktury nie uywane (f_count rwne 0) s pomijane.
Przetworzenie odoonych struktur
604-606
Jeeli flaga F D EFE R bya ustawiona, jest ona wyczana i warto licznika unp_defer zostaje zmniejszona. Gdy unp_mark ustawia flag FDEFER, ustawiona zostaje rwnie flaga FMARK. Wiemy wic, e ta struktura jest uywana i na kocu polecenia i f sprawdzimy, czy jest to gniazdo domeny unixowej.
Sekcja 18.9
Funkcja unp_gc
297
Struktury przetworzone wczeniej s pominite

6 07 -609
Jeeli flaga FMARK jest ustawiona, to struktura jest uywana i bya ju anali zowana.
Nie zaznacza zagubionych struktur
610-611
Warto f_count rwna f_msgcount moe wiadczy, e struktura jest zagubiona. Struktura taka nie zostaje zaznaczona i jest pominita. Poniewa w y daje si, e struktura nie jest uywana, nie moemy sprawdzi, czy jest to gniazdo domeny unbcowej z deskryptorami w locie w kolejce odbiorczej.
Zaznaczenie uywanych struktur
612
W tym punkcie wiemy, e struktura jest uywana, wic flaga FM ARK zostaje ustawiona.
Sprawdzenie, czy struktura jest zwizana z gniazdem domeny unixowej
6 14 -619
Poniewa ta struktura jest uywana, sprawdzamy, czy jest to gniazdo ze struktur socket. Nastpnie sprawdzamy, czy jest to gniazdo domeny unbcowej z ustawion flag PR_R IGHTS. Flaga ta jest wczona dla protokow strumienio wego i datagramowego domen unixowych. Jeli ktrykolwiek z warunkw nie jest speniony, struktura zostaje pominita.
Poszukiwanie deskryptorw w locie w kolejce odbiorczej gniazda domeny unixowej
620
W tym punkcie struktura file odpowiada gniedzie domeny unbcowej. Funkcja u n p_s c a n przeglda kolejk odbiorcz gniazda w poszukiwaniu buforw mbuf typu MT_C0NTR0L zawierajcych deskryptory w locie. Jeeli struktura taka zostanie znaleziona, wywoana jest funkcja un p_ma r k.
W tym miejscu powinna by rwnie przetworzona kolejka kompletnych pocze (so_q) dla gniazda domeny unixowej [McKusick i inni 1996], Moliwe, e klient przeka zuje deskryptor do nowo utworzonego gniazda serwera, cigle oczekujcego na wykona nie accept.
Na rysunku 18.17przedstawiony zosta przykad fazy zaznaczania funkcji unp_gc i zilustrowana jest potencjalna potrzeba kilkukrotnego przejrzenia listy struktur f i l e . Rysunek pokazuje stan struktur przy zakoczeniu pierwszego przejcia listy w fazie zaznaczania, kiedy to zmienna unp_defer rwna si 1, co oznacza konieczno ponownego przejrzenia wszystkich struktur file. Ma tu miejsce omwione niej przetwarzanie dla kadej z czterech struktur - od lewej do prawej.
298
filo O f_type VNODE f_flag FMARK f count 2 fjmagcount - data f_type f_flag f count f_msgcount data
VNODE FMARK FDEFER
fil* O f_type SOCKET f_flag FMARK f count 1 f_msgcount f data
fila o f_type
SOCKET FMARK
f count 2 f_msgcount 1 f data
vnod{ )
vnoda{)
BOCkt{)
socket{}
so rcv
mbuf< )
MT CONTROL
cmsg len cmag_level cmsg_type
_______
mbuf( )
Rysunek 18.17
Struktury danych po zakoczeniu pierwszego przegldu listy wfazie zaznaczania
Sekcja 18.9
Funkcja unp_qc
299
1. Ta struktura f i l e ma dwa deskryptory w procesie odwoujce si do niej (f_count rwna si 2) i nie ma adnych odwoa pochodzcych od deskrypto rw w locie (f_msgcount wynosi 0). Kod z rysunku 18.16 ustawia bit flagi FM A RK w p ou f_f 1 ag. Struktura ta wskazuje na vnode. (Pomijamy przedrostek DTYPE_ w wartoci pokazanej dla pola f_type. Pokazujemy te tylko flagi FMARKi FDEFERwpolu f _ f l ag ; inne flagi w tym polu mog by take ustawio ne.) 2. Wydaje si, e ta struktura nie jest uywana, poniewa f_count rwna si f_msgcount. W fazie zaznaczania pole f _ f 1 ag pozostaje bez zmian. 3. Flaga FM ARK tej struktury zostaje wczona, poniewa do struktury tej odwouje si jeden deskryptor w procesie. Co wicej, poniewa struktura ta odpowiada gniazdu domeny unbcowej, funkcja unp_s c a n przetwarza komunikaty kontrol ne w kolejce odbiorczej gniazda. Pierwszy deskryptor w komunikacie kontrol nym wskazuje na drug struktur f i l e , a poniewa flaga FM ARK nie bya wczona w punkcie 2, unp_ma rk ustawia dwie flagi: FM A RK i FDEFER. Zmienna unp_defer otrzymuje warto 1, poniewa struktura bya ju uznana za nie uywan. Drugi deskryptor w komunikacie kontrolnym wskazuje na czwart struktur f i l e - poniewa flaga FM A RK nie jest ustawiona (struktura ta nie bya nawet jeszcze przetwarzana) - ustawione zostaj flagi FM A RK i FDEFER. Warto unp_defer zostaje zwikszona do 2. 4. Ta struktura ma ustawion flag FDEFER. Kod z rysunku 18.16 wycza t flag i zmniejsza warto unp_defer do 1. Cho do struktury tej odwouje si rw nie deskryptor w procesie, wartoci f _ c o unt i f _ms gc o unt nie s sprawdzane, poniewa wiadomo ju, e do struktury odwouje si deskryptor w locie. W tym miejscu wszystkie cztery struktury f i l e zostay przeanalizowane, ale warto unp_defer wynosi 1, wic wszystkie struktury s przegldane ponownie. Dzieje si tak, poniewa druga struktura, uznana za nie uywan przy pierwszym przegldzie, moe by gniazdem domeny unbcowej z komunikatem kontrolnym w kolejce odbiorczej (w naszym przykadzie tak nie jest). Struktura ta musi by przeanalizowana ponownie - i jeli rzeczywicie domniemanie jest prawdziwe mog zosta wczone flagi FM ARK i FDEFER w jakiej innej strukturze, z listy uznanej wczeniej za nieuywan. Na zakoczenie fazy zaznaczania, ktra moe obejmowa wielokrotne przejrzenie powizanej listy struktur f i 1 e w jdrze, mamy pewno, e niezaznaczone stru ktury s na pewno nieuywane. Nastpna faza, wymiatanie (sweep), zostaa poka zana na rysunku 18.18.
300
------------------------------------------------------------------------------------------------623 6 24 6 25 626 627 6 28 629 6 30 631 63 2 63 2 63 3 63 4 63 5 636 637 6 38 6 39 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 6 58 659 660 661 66 2 66 3 664 66 5 66 6 667 6 68 66 9 67 0 671 67 2 6 73 674 675 67 6 67 7 6 78 679 680 681 )
uipc_usrreq.c
/* * U z y s k u j e m y d o d a t k o w y o d n o n i k dla k a d e g o w p i s u w t a b l i c y * plikw, kt ry nie m o e by o s i g n i t y w inny sposb. * N a s t p n i e z w a l n i a m y u p r a w n i e n i a zaw a rt e w k o m u n ik at ac h w t ak i m wpisie. * * Bd w o r y g i n a l n y m k od z ie wy ma g a w y j a n i e n i a . W y j a n i e n i e t a ki e * p r z e d s t a w i a m poniej. * * B d e m j es t f _ m s g c o u n t - k r o t n e u y c i e u n p _ d i s c a r d dla k a d e g o w pi s u. * Ro z w a m y p r z y p a d e k dw c h gniazd, A i B, z a w i e r a j c y c h w z a j e m n e * od n o ni ki . Pr zy o s t a t n i m z a m k n i c i u j a k i e g o in ne g o g n ia z da * u r u c h a m i a n a je s t funkc j a gc, p o n i e w a liczba p o z o s t a j c y c h u p r a w n i e * ( u n p _r ig h ts ) j e s t n ie ze ro w a. Jeli w f az i e w y m i a t a n i a kod w y k o n u j e * un p _ d i s c a r d , w y k o n u j e m y p e n e z a m k n i c i e (c losef) dla d e s k r y p t o r a . * C l o s e f dla A powoduje: * C l o s e f w y w o u j e soo_cl os e, ktra w y w o u j e so c lose. S o c l o s e n a j p i e r w * (przez "s witch" ui p c _ u s r r e q ) w y w o u j e unp _d et ac h , ktra p o n o w n i e * u r u c h a m i a unp_gc. U n p_ gc od razu zw r a c a ko ntrol, p o n i e w a pr zy * p o p r z e d n i m w y w o a n i u z o s t a a us t a w i o n a flaga u n p _ gc in g. i k on t r o l a * z o s t a j e p r z e k a z a n a a do soclose. S o c l o s e o z n a c z a g n i a z d o p rz y po m o c y * S S _ N 0 FDREF i n a s t p n i e w y w o u j e sofre e. S o f r e e woa s o r fl us h , by * z w o l n i u p r a w n i e n i a c z e k a j c e w kolejce, z a w a r t e w k o m u n i k a t a c h w * g n i e d z i e A, to zn ac zy o d n i e s i e n i a w B. S o r f l u s h w o a (przez * d o m _ d i s p o s e ) "s w itch" u n p _ d i sp os e, ktry w y k o n u j e u n p _ s c a n z * u np _ d i s c a r d . To d r u g i e w y k o n a n i e u n p _ d i s c a r d po p r o s t u robi * c l o s e f na B. * * P o do bn e p r z e t w a r z a n i e ma m i e j s c e dla B, co p o w o d u j e s o r f l u s h na B * i n a s t p n i e cl o s e f na A. N i estety, A j e st ju zamy k an e, a d e s k r y p t o r * z os ta ju o z n a c z o n y p rz y po mo c y S S J O F D R E F , co p o w o d u j e " p a n i e * w t y m mi ejscu. * * U z y s k u j e m y tu n a j p i e r w d o d a t k o w y o d n o n i k do k a d eg o n i e o s i g a l n e g o * d e sk r y p t o r a . N a s t p n i e sami w y w o u j e m y sorf lu sh , w i e d z c teraz, e * jest to g n i a z d o d o m e n y un ixowej. Po u s u n i c i u w s z y s t k i c h p ra w * z a w a r t y c h w ko mu n i k a t a c h , w y k o n u j e m y o s t a t n i e clos ef, by p o z b y si * n a s z e g o d o d a t k o w e g o od n o n i k a . Je st to o s t a t n i e z a m k n i c i e i * u n p _ d e t a c h (itd.) w y c z y gniazdo. * * 91/09 /1 9 . b s y @ c s . c m u . e d u */ e x t r a _ r e f = mai 1oc(nfi 1 es * s i z e o f ( s t r u c t file *), M_F I LE , M_ W A I T 0 K ) ; for (nunref = 0, fp = fi 1 e h e a d .1h _ f i r s t , fpp = ex t ra _r ef ; fp != 0; fp = nex tf p) [ n e x t f p = f p - > f _ l i s t .1e _ n e x t ; if ( f p - > f _ c o u n t = = 0) c o ntinue; if ( f p - > f _ c o u n t = = f p - > f _ m s g c o u n t && !(f p - > f _ f 1 ag & FMARK)) { *fpp++ = f p ; n u nref++; fp->f_count++; ) ) for (i = nunref , fpp = ex tr a _r ef ; --i >= 0; ++ fp p ) if ( ( * f p p ) - > f _ t y p e == D T Y P E _ S 0 C K E T ) s o r f l u s h ( ( s t r u c t so cket *) ( * f p p ) - > f _ d a t a ); for (i = nunref. fpp = ex tr a_ r ef ; --i > = 0; ++ fp p) c l o s e f ( * f p p , (struct proc *) NULL); f r e e ( ( c a d d r _ t ) extra_ re f , M_F ILE); u n p _ g c i n g = 0;
-------------------------------------------------------------------------------------------------uipc_usrreq.c Rysunek 18.18 Druga cz funkcji u n p _ g c - wymiatanie
Sekcja 18.9
Funkcja unp_gc
301
Komentarz o poprawieniu bdu

623-661
Komentarz dotyczy bdu w systemie 4.3BSD Reno i w N et/2. Bd zosta skorygowany w 4 .4BSD przez Bennet S. Yee. Stary kod, ktrego dotyczy komen tarz, pokazany jest na rysunku 18.19.
Tymczasowa alokacja tablicy
662
ma 11 o c alokuje miejsce na tablic wskanikw do wszystkich struktur file jdra, nf i 1 es to liczba aktualnie uywanych struktur file. M_F ILE okrela, w ja kim celu m a by uyta pami. (Polecenie vmstat -m podaje informacje o wyko rzystaniu pamici przez jdro.) M _ W A I T 0 K oznacza, e dopuszczalne jest upienie procesu, jeeli pami nie jest natychmiast dostpna. Ptla dla wszystkich struktur file
663 -665
W tej ptli ponownie s badane wszystkie struktury f i 1 e w jdrze, po to by znale wszystkie struktury, do ktrych nie ma odwoa (czyli zagubione).
Pominicie nieuywanych struktur
663 - 665
Jeeli licznik f _c o u n t struktury wynosi 0, struktura jest pominita.
Sprawdzenie, czy istniej struktury bez odwoa
668
Do struktury nie ma odwoa, gdy warto f_ c o u n t jest rwna f _ m s g c o u n t (odwoania pochodz tylko od deskryptorw w locie) i flaga FMA R K nie bya ustawiona w fazie zaznaczania (deskryptory w locie nie pojawiy si w adnej kolejce odbiorczej gniazda domeny unbcowej).
Zachowanie wskanika do struktury bez odwoa
669-671
Kopia f p wskanika do struktury fi 1 e jest zachowana w alokowanej przed chwil tablicy, licznik nunref zostaje zmniejszony, a licznik f_count zwikszony.
Wywoanie sorflush dla gniazd bez odwoa

6 74 - 6 7 6
Dla kadego pliku (struktury file) bez odwoa woana jest funkcja sorfl ush. Funkcja ta (strona 485 w tomie 2) wywouje z kolei funkcje domeny dom_di spose, w tym przypadku unp_di spose, ktra woa unp_scan, by skaso
wa deskryptory znajdujce si aktualnie w kolejce odbiorczej gniazda. Funkcja u n p _ d i s c a r d zmniejsza wartoci f _ m s g c o u n t i u n p _ r i g h t s i wywouje c l o s e f dla wszystkich struktur f i l e znalezionych w komunikatach kontrolnych w kolej ce odbiorczej gniazda. Poniewa mam y dodatkowe odwoanie do tej struktury file (wczeniej zostaa zwikszena warto f_count) i poniewa struktury z licz nikiem f _c o u n t rwnym zero s ignorowane w ptli, mamy pewno, e f _c o u n t ma warto wiksz lub rwn 2. Dlatego wywoanie c 1 o s e f (w wyniku wykona nia sorflush) jedynie zmniejszy do niezerowej wartoci f_c o u n t struktury. Stru ktura ta nie zostanie cakowicie zamknita. To jest przyczyn wprowadzenia wczeniej dodatkowego odwoania do tej struktury.
302
Ostatnie zamknicie
677- 678
c 1 o s e f jest wywoywana dla struktur f i l e bez odwoa. Jest to ostateczne wywoanie cl osef, tzn. f_count powinno zosta zmniejszone z 1 do 0, gniazdo wtedy zostaje zamknite i struktura f i l e jest zwrcona do zasobnika wolnych struktur w jdrze.
Zwrcenie tymczasowej tablicy
6 7 9- 6 8 0
Tablica otrzymana wczeniej w wyniku uycia mai 1 oc zostaje zwrcona i flaga u n p _ g c i ng zostaje usunita.
Rysunek 18.19 pokazuje faz wymiatania funkcji unp_gc w takiej formie, w jakiej funkcja ta pojawia si w kodzie N et/2. Ten fragment kodu zosta zastpiony przez kod z rysunku 18.18. ------------------------------------------------------------------------------------------------itipc_usrreq.c
for (fp = fi lehead; fp; fp = f p -> f_fi 1e f ) I i f ( f p - > f _ c o u n t = = 0) c ontinue; if (f p - > f _ c o u n t = = f p - > f _ m s g c o u n t && (f p -> f _ f 1 ag & FMARK) = = 0) while (fp->f_msgcount) unp_discard(fp); u n p _ g c i n g = 0; I
------------------------------------------------------------------------------------------------- uipcjusrrecj.c Rysunek 18.19 Bdny kodfazy tin/miaania funkcji unp_gc w Net/2 Do tego fragmentu kodu odnosz si komentarze na pocztku rysunku 18.18.
Niestety, mimo wprowadzonych w N e t/3 poprawek modyfikujcych kod z rysunku 18.19 i usunicia bdu opisanego na pocztku rysunku 18.18, przedstawiony w tym podrozdziale kod nadal nie jest poprawny. Cigle struktury f i l e m og zosta zagubio ne w dwch pierwszych sytuacjach opisanych na pocztku tego podrozdziau.
18.10
Funkcja unpjnark
Funkcja ta jest wywoywana przez funkcj unp_scan uruchamian z kolei przez unp_gc, by zaznaczy struktury f i l e . Zaznaczanie jest wykonywane, gdy de skryptory w locie zostaj znalezione w kolejce odbiorczej gniazda. Funkcja ta przedstawiona zostaa na rysunku 18.20. ------------------------------------------------------------------------------------------------717 voi d 718 u n p _ m a r k ( f p ) 719 st ru c t file *fp; 720 ( 721 722 723 724 725 if ( f p - > f _ f l a g & FMARK) return; u n p _ d ef er + +; f p - > f _ f 1 ag = (F MA RK | FDEFER); ]
uipc_usrreq.c
------------------------------------------------------------------------------------------------Rysunek 18.20 Funkcja unp_mark
uipc_usrreq.c
Sekcja 18.11
Szybko dziaania (raz jeszcze)
303
7 17 - 7 20
Argument fp jest wskanikiem do struktury f i l e znalezionej w kolejce odbiorczej gniazda domeny unbcowej.
Powrt, jeeli struktura zostaa ju zaznaczona
7 21 -722
Jeeli struktura f i l e zostaa ju zaznaczona, nie pozostaje nic wicej do zrobienia. Wiadomo ju, e struktura f i l e jest uywana.
Ustawienie flag FMARK i FDEFER
723-724
Licznik u n p _ d e f e r zostaje zwikszony i flagi FM ARK i F D E F E R zostaj w czone. Jeeli ta struktura f i l e znajduje si na licie jdra w pozycji wczeniejszej ni struktura f i l e gniazda domeny unixowej (tzn. bya ju przeanalizowana przez unp_gc, zostaa uznana za struktur nieuywan i nie zostaa zaznaczona), zwikszenie un p _ d e f er spowoduje jeszcze jedno wykonanie ptli dla wszystkich struktur f i 1 e w fazie zaznaczania unp_gc.
18.11
Szybko dziaania (raz jeszcze)
Po przedstawieniu implementacji protokow domeny unbcowej wracamy teraz do szybkoci dziaania tych protokow i wyjanimy, dlaczego s one dwukrotnie szybsze ni TCP (rysunek 16.2). Wszytkie operacje wyjcia/wejcia wykonywane s za porednictwem sosend i sorecei ve, bez wzgldu na stosowany protok. Ma to swoje dobre i ze strony. Zalet jest to, e te dwie funkcje speniaj wymagania wielu rnych protokow od protokou TCP przesyajcego strumie bajtw, przez protokoy datagramowe (UDP), po protokoy przesyajce rekordy (OSI TP4). Uniwersalno funkcji zmniejsza jednak szybko ich dziaania i komplikuje kod. Wersje tych funkcji zoptymalizowane dla rnych rodzajw protokow dziaayby sprawniej. Porwnujc szybko operacji wyjcia stwierdzamy, e cieka przetwarzania z funkcj sosenddla TCP jest niemal identyczna ze ciek dla protokou domeny unixowej. Jeeli aplikacja wypisuje dane duymi porcjami (dla danych z rysunku 16.2 uywane s bufory o dugoci 32 768 bajtw), to sosend dzieli dane na klastry mbuf i przekazuje kady 2048-bajtowy klaster do protokou, uywajc dania PRU_S END. Dlatego te TCP i domena unixowa bd przetwarza t sam liczb da PRU_SEND. Rnica w szybkoci operacji wyjcia musi wynika z prostoty dania P R U _ S E N D (rysunek 18.2) w domenie unbcowej w porwnaniu do operacji wyjcia protokou TCP (ktry wywouje procedury wyjcia IP, by doczy kady segment do kolejki programu obsugi urzdzenia ptli zwrotnej). Jeli chodzi o odbir danych, jedyn zaangaowan funkcj w przypadku gniazda domeny unbcowej jest soreceive, poniewa danie P RU_S END umieszcza dane w buforze odbiorczym gniazda. W przypadku TCP program obsugi ptli zwrotnej umieszcza kady segment w kolejce wejciowej IP, po czym nastpuje przetwarza nie IP oraz przetwarzanie TCP, w ktrym segment kierowany jest do waciwego gniazda i umieszczany w kolejce odbiorczej gniazda.
304______________ Protokoy domeny unixowej: 1/0 i przekazywanie deskryptorw _______ Rozdzia 18
18.12
Podsumowanie
Dane wpisywane do gniazda domeny unixowej s natychmiast doczane do bufora odbiorczego gniazda. Buforowanie danych w wysyajcym gniedzie nie jest konieczne. Procedura taka dziaa poprawnie dziki temu, e P RU_S EN D i P R U _ R C V D manipuluj znakiem przepenienia bufora wysykowego, tak e znak ten zawsze odzwierciedla ilo miejsca w buforze odbiorczym partnera. Gniazda domeny unbcowej udostpniaj mechanizm przekazywania deskrypto rw pomidzy procesami. Jest to technika komunikacji midzyprocesowej o du ych moliwociach. Przy przesyaniu deskryptora midzy dwoma procesami deskryptor zostaje najpierw przedstawiony w formacie wewntrznym - zamienio ny na odpowiedni wskanik f i 1 e, i dopiero ten wskanik przekazywany jest do odbierajcego gniazda. Kiedy odbierajcy proces czyta informacj kontroln, wskanik f i l e zostaje zamieniony na format zewntrzny - staje si najniszym nieuywanym deskryptorem w odbierajcym procesie. Ten deskryptor zostaje zwrcony do procesu. Jeeli gniazdo domeny unixowej zostaje zamknite w czasie, gdy bufor odbiorczy zawiera komunikaty kontrolne z deskryptorami w locie, pojawia si bd, ktry moe by jednak atwo obsuony. Niestety, moliwe s dwie inne bdne sytuacje, stwarzajce wiksze problemy: gdy odbierajcy proces nie da informacji kon trolnej znajdujcej si w buforze odbiorczym oraz gdy w buforze odbiorczym nie ma wystarczajco wiele miejsca na bufor kontrolny. W tych dwch sytuacjach struktury f i l e zostaj zagubione - to znaczy nie znajduj si w zasobniku wol nych struktur w jdrze i nie s rwnie uywane. By odzyska te struktury, potrzebna jest funkcja zbierajca niepotrzebne dane. Funkcja zbierania niepotrzebnych danych m a faz zaznaczania, w ktrej wszyst kie struktury f i 1 e w jdrze s przegldane i zaznaczone zostaj struktury uywa ne. Po fazie zaznaczania nastpuje faza wymiatania, w ktrej wszystkie niezaznaczone struktury zostaj odzyskane. Cho ta funkcja jest potrzebna, to jednak rzadko jej si uywa.
Dodatek A Pomiary czasu w sieci

W wielu miejscach w tekcie ksiki podajemy czas potrzebny do wymiany pakie tw poprzez sie. W tym dodatku przyjrzymy si dokadniej sposobom wyznacza nia czasu i podamy kilka przykadw takich pomiarw. Przedstawimy pomiary RTT przy uyciu programu Ping, pomiary czasu przechodzenia przez stos proto kou i omwimy rnic midzy czasem propagacji (latency) i szerokoci pasma ( bandwidth). Programista sieciowy lub administrator systemu ma zwykle do swojej dyspozycji dwa sposoby wyznaczenia czasu potrzebnego aplikacji na przeprowadzenie transakcji. 1. Uycie zegara aplikacji. Na przykad w kodzie klienta UDP (rysunek 1.1), odczytujemy czas systemowy przed wywoaniem sendto i po wykonaniu r e c v f rom. Rnica tak odczytanych czasw pozwala okreli czas (zmierzony przez aplikacj) potrzebny na wysanie dania i odebranie odpowiedzi. Jeeli jdro udostpnia zegar o duej dokadnoci (rzdu mikrosekund), tak wyznaczone wartoci (kilka i wicej milisekund) s do dokadne. W dodatku A w tomie 1 ten typ pomiarw zosta omwiony bardziej szczegowo. 2. Uycie narzdzia programowego w rodzaju Tcpdump. Tcpdump ledzi prze syanie danych na poziomie warstwy danych, obserwuje wybrane pakiety i umoliwia obliczenie odpowiedniej rnicy czasu. Wicej szczegw doty czcych tego typu narzdzi zawartych jest w dodatku A w tomie 1. W tym tekcie zakadamy, e ledzenie danych w warstwie danych odbywa si przy pomocy programu Tcpdump wykorzystujcego BPF (BSD Packet Filter) filtr pakietw systemu BSD. Szczegy implementacji BPF przedstawione zo stay w rozdziale 31 w tomie 2. Na stronach 111 i 121 w tomie 2 przedstawiono umiejscowienie odwoa do BPF w typowym programie obsugi Ethernetu, a na stronie 159 tomu 2 znajdziemy odwoanie do BPF w programie obsugi ptli zwrotnej. Najbardziej wiarygodnym sposobem pomiaru czasu jest doczenie analizatora sieci do kabla sieciowego. Taka moliwo zwykle nie jest jednak dostpna. Zaznaczamy, e oba systemy uywane do przeprowadzenia omawianych tu przy kadw (rysunek 1.13) - BSD/OS 2.0 dziaajcy w komputerze z procesorem 80386 oraz Solaris 2.4 uruchomiony w Sparcstation ELC - udostpniaj zarwno zegar o duej dokadnoci, jak i moliwo pomiaru czasu przy pomocy Tcpdump.
306
Dodatek A
A.1
Pomiary RTT z uyciem programu Ping
Wszechobecny program Ping (omwiony szczegowo w rozdziale 7 tomu 1) uywa zegara aplikacji do wyznaczenia RTT dla pakietu ICMP. Program wysya do serwera danie odpowiedzi typu echo protokou ICMP, a serwer zwraca do klienta pakiet echo ICMP. Klient zapisuje czas zegara w momencie wysania pakietu jako opcjonalne dane w daniu echa, i te dane zostaj zwrcone przez serwera. Aktualny czas zegara systemowego jest odczytany w momencie otrzy mania odpowiedzi przez klienta i czas RTT zostaje obliczony i wywietlony. Format pakietu programu Ping przestawiony jest na rysunku A .l.
nagwek IP 20 bajtw
nagwek ICMP 8 bajtw
dane uytkownika (opcjonalne)
Rysunek A .l
Pakiet programu Ping: danie echa lub odpowied typu echo protokou ICMP
Program Ping pozwala okreli ilo opcjonalnych danych uytkownika w pakie cie, moemy wic bada wpyw rozmiaru pakietu na RTT. Ping moe jednak wyznaczy RTT tylko dla pakietw zawierajcych co najmniej 8 bajtw opcjonal nych danych (poniewa zapis czasu w pakiecie zajmuje 8 bajtw). Jeli zadamy wysania mniej ni 8 bajtw, Ping bdzie nadal dziaa, czas RTT nie bdzie jednak obliczany i wypisywany. Na rysunku A.2 przedstawione s typowe wartoci RTT otrzymane za pomoc programu Ping dla hostw w trzech rnych lokalnych (LAN) sieciach Ethernet. rodkowa linia na rysunku odpowiada RTT pomidzy komputerami s u n i b s d i z rysunku 1.13.
Rysunek A.2
Wartoci RTT otrzymane za pomoc programu Ping dla trzech hostw w lokalnych sieciach Ethernet
Sekcja A. 1
Pomiary R T T z uyciem programu Ping
307
Pomiary przeprowadzone byy dla pitnastu rnych rozmiarw pakietw - 8 bajtw danych uytkownika oraz od 100 do 1400 bajtw danych uytkownika (co 100 bajtw). cznie z 20-bajtowym nagwkiem IP oraz 8-bajtowym nagwkiem ICMP, datagramy IP miay rozmiar od 36 do 1428 bajtw. Dla kadego rozmiaru pakietu przeprowadzono 10 pomiarw i na wykresie zaznaczona zostaa naj mniejsza z 10 wartoci. Tak jak si spodziewamy, czas RTT jest wikszy dla wikszych pakietw. Rnice pomidzy trzema liniami wynikaj z rnic szybko ci procesorw, kart interfejsw i systemw operacyjnych. Na rysunku A.3 przedstawione zostay typowe wartoci RTT otrzymane za pom o c Pinga dla rnych hostw w Internecie (czyli sieci WAN). Zwracamy uwag na rnic skali na osi y w porwnaniu z rysunkiem A.2.
Rysunek A.3
Wartoci RTT otrzymane za pomoc programu Ping dla hostw w Internecie (WAN)
Dla sieci W AN przeprowadzono pomiary tego samego typu co dla sieci LAN - 1 0 pomiarw dla kadego z 15 rozmiarw pakietu i zaznaczona zostaje najmniejsza z 10 zmierzonych wartoci. Zaznaczamy rwnie (w nawiasach) liczb hopw dla kadej pary hostw. Linia znajdujca si najwyej (najwiksza warto RTT) odpowiada 25 hopom w Internecie pomidzy dwoma hostami: jednym w Arizonie (noao. edu) i drugim w Holandii (utwente.nl). Druga od gry linia rwnie odpowiada przejciu przez Atlantyk - pomidzy Connecticut (conni x .com) i Londynem (ucl .ac.uk). Nastpne dwie linie s to poczenia przecinajce USA: pomidzy Connecticut
308
Dodatek A
a Arizon (co nn i x .com i noao .edu) oraz pomidzy Kaliforni a Waszyngtonem (be rke 1 e y . e d u i uu.net). Kolejne dwie linie odpowiadaj hostom zlokalizowa nym geograficznie blisko siebie - conn i x .com w Connecticut i a w .com w Bostonie - lecz oddalonym w sensie liczby internetowych hopw (16). Najnisze dwie linie na rysunku (najmniejsza warto RTT) odpowiadaj hostom sieci LAN autora (rysunek 1.13). Najnisza linia zostaa skopiowana z rysunku A.2, dla porwniania typowych wartoci RTT dla sieci LAN i WAN. Jeli chodzi o lini drug od dou, czyli poczenie pomidzy bsdi i 1 aptop, to drugi z tych hostw posiada adapter Ethernetu doczony do rwnolegego portu komputera. Cho komputer jest doczony do Ethernetu, mniejsza szybko przesyania przez port rwnolegy powoduje, e otrzymane wartoci zblione s do wartoci otrzy mywanych dla sieci WAN.
A.2
Pomiary w stosie protokou
Programu Ping, wraz z Tcpdump, moemy rwnie uy do zmierzenia czasu potrzebnego na przejcie przez stos protokou. Na rysunku A.4 pokazujemy kolej ne kroki przetwarzania, gdy uruchamiamy Ping i Tcpdump w pojedynczym kom puterze, podajc adres interfejsu ptli zwrotnej (zwykle 127.0.0.1).
Zakadajc, e aplikacja uruchamia swj zegar bezporednio przed wysaniem dania echa do systemu operacyjnego i zatrzymuje zegar, gdy system operacyjny zwraca odpowied echo, rnica pomidzy czasem zmierzonym przez aplikacje
Sekcja A.2
309
i czasem zmierzonym przy pomocy Tcpdump daje czas przetwarzania przez wyj cie ICMP, wyjcie IP, wejcie IP i wejcie ICMP. Moemy przeprowadzi podobne pomiary dla dowolnej aplikacji typu klient-serwer. N a rysunku A.5 pokazane s kroki przetwarzania dla klienta i serwera UDP z rozdziau 1.2, w przypadku gdy klient i serwer znajduj si w tym samym komputerze.
Rnica pomidzy klientem-serwerem UDP, a przykadem z programem Ping z rysunku A.4, polega na tym, e serwer UDP jest procesem uytkownika, podczas gdy serwer Ping jest czci implementacji ICMP zawartej w jdrze (strona 329 tomu 2). Dlatego te w przypadku serwera UDP konieczne s dwa dodatkowe kopiowania danych klienta pomidzy jdrem i procesem uytkownika: operacje wejcia i wyjcia serwera. Kopiowanie danych pomidzy jdrem i procesem uyt kownika jest zwykle czasochonn operacj. Na rysunku A.6 pokazane s wyniki rnych pomiarw wykonanych dla hosta bsdi. Porwnujemy klienta-serwera Ping z klientem-serwerem UDP. Uylimy oznaczenia zmierzony czas transakcji" dla osiy, poniewa pojcie RTT odnosi si zwykle do podawanego przez Ping czasu przesania w sieci pakietu w obie strony (ktry, jak widzimy na rysunku A.8, jest moliwie najbardziej zbliony do czasu sieci RTT). Dla naszych ukadw klient-serwer UDP, TCP i T /T C P mierzymy w rzeczywistoci czas transakcji wykonywanej przez aplikacj. W przypadku TCP i T /T C P transakcja moe obejmowa przesanie wielu pakietw i czas transakcji moe odpowiada wielokrotnoci RTT.
310
Dodatek A
zmierzony :zas transakcj (ms)
dane uytkownika (bajty)
Rysunek A .6
Pomiary z uyciem Pinga i Tcpdump dla pojedynczego hosta (interfejs ptli zwrotnej)
Pomiary przedstawione na rysunku odpowiadaj 23 rnym rozmiarom pakietw - od 100 do 2000 bajtw danych uytkownika (zwikszane co 100), dodatkowo trzy pomiary dla 8,1508 i 1509 bajtw danych uytkownika. Osiem bajtw jest to najmniejsza dugo danych uytkownika, dla ktrej Ping moe wyznaczy RTT. 1508 bajtw danych daje najwikszy pakiet, dla ktrego nie zachodzi fragmentacja datagramu IP - warto MTU dla BSD wynosi 1536 (1508 + 20 + 8). 1509 bajtw odpowiada najmniejszemu pakietowi przesyanemu z fragmentacj. Wyranie widoczny jest skok czasu w momencie, gdy pojawia si fragmentacja przy dugoci danych uytkownika rwnej 1509 bajtw. Tego si spodziewamy. W przypadku fragmentacji, wywoania operacji wyjcia IP (lewa strona rysunkw A.4 i A.5) powoduj dwa odwoania do programu obsugi ptli zwrotnej, jedno odwoanie dla kadego fragmentu. Cho ilo danych uytkownika wzrasta tylko o 1 bajt, z 1508 do 1509, czas transakcji mierzony przez aplikacj wzrasta mniej wicej o 25%, co jest zwizane z dodatkowym przetwarzaniem dla kadego pakietu. W zrost czasu widoczny dla wszystkich czterech linii w punkcie odpowiadajcym 200 bajtom zwizany jest ze szczegem implementaqi obsugi buforw mbuf w BSD (rozdzia 2, tom 2). Przy najmniejszym rozmiarze pakietu (0 bajtw danych uytkownika dla klienta UDP i 8 bajtw danych uytkownika dla klienta Ping), dane i nagwki mieszcz si w jednym buforze mbuf. W punkcie odpowiadaj cym 100 bajtom, potrzebny jest drugi bufor mbuf, a w punkcie 200 bajtw - trzeci
Sekcja A.2
311
bufor. W kocu przy 300 bajtach jdro decyduje si na uycie 2048-bajtowych klastrw mbuf, zamiast mniejszych buforw mbuf. Jak wida, biorc pod uwag czas przetwarzania, zmiana wielkoci mbuf powinna nastpi wczeniej (na przy kad w punkcie odpowiadajcym 100 bajtom). Jest to przykad klasycznego wybo ru pomidzy optymalizacj czasu przetwarzania i rozmiaru zajmowanej pamici. Decyzja o zwikszeniu rozmiaru mbuf, gdy ilo danych przekracza 208 bajtw, zostaa podjta wiele lat temu, gdy pamici byy bardzo kosztowne.
Czasy przedstawione na rysunku 1.14 zostay zmierzone dla zmodyfikowanego jdra BSD/OS, z wartoci M I N C L S I Z E (strony 41 i 514 w tomie 2) zmienion z 208 na 101. Powoduje to alokacj klastra mbuf w momencie, gdy rozmiar danych uytkownika przekracza 100 bajtw. N a rysunku 1.14 nie obserwujemy wic wzrostu RTT w punkcie odpowiadajcym 200 bajtom. Omawialimy ten problem rwnie w rozdziale 14.11, gdzie stwierdzilimy, e wiele da klientw W W W zawiera si w przedziale od 100 do 200 bajtw.
Rnica pomidzy dwiema liniami UDP na rysunku A .6 wynosi od 1,5 do 2 ms do momentu, gdy pojawia si fragmentacja. Poniewa rnica ta zwizana jest z operacjami wyjcia UDP i IP oraz wejcia IP i UDP (rysunek A.5) - jeeli zaoy my, e przetwarzanie na wejciu protokou zajmuje mniej wicej tyle samo czasu, co przetwarzanie na wyjciu - moemy stwierdzi, e przesanie pakietu od gry do dou stosu protokou zajmuje nieco mniej ni 1 ms i podobnie odbir pakietu przechodzcego przez stos z gry do dou zajmuje te nieco mniej ni 1 ms. Czasy te obejmuj czasochonne kopiowania danych z procesu do jdra - przy wysyaniu danych, oraz z jdra do procesu - przy odbieraniu danych. Poniewa te same cztery kroki (wejcie IP, wejcie UDP, wyjcie UDP i wyjcie IP) obejmowane s przez pomiar przy uyciu Tcpdump (rysunek A.5), spodziewamy si, e wartoci odpowiadajce UDP z Tcpdump take zawarte bd w przedziale 1,5-2 ms (biorc pod uwag tylko punkty bez fragmentacji). Prawie wszystkie warto ci na rysunku A.6, z wyjtkiem pierwszego punktu, ukadaj si pomidzy 1,5 i 2 ms. Rozwaajc wartoci z fragmentacj, rnica pomidzy dwiema liniami UDP na rysunku A.6 wynosi 2,5-3 ms. Tak jak si spodziewamy, wartoci UDP mierzone przy pomocy Tcpdump rwnie zawieraj si pomidzy 2,5 i 3 ms. Zauwamy wreszcie, e linia odpowiadajca pomiarowi Tcpdump dla programu Ping na rysunku A.6 jest niemal zupenie pozioma, podczas gdy pomiar aplikacji w przypadku Ping daje lini o wyranym nachyleniu. Prawdopodobn przyczyn tej rnicy jest to, e pomiar aplikacji obejmuje dwa kopiowania danych pomidzy procesem uytkownika i jdrem, pqdczas gdy takie kopiowania nie s objte przez pomiar Tcpdump (serwer Ping jest czci implementacji ICMP jdra). Rwnie niewielkie nachylenie linii Tcpdump dla programu Ping jest prawdopodobnie spowodowane dwiema operacjami wykonywanymi w jdrze przez serwer Pinga dla kadego bajtu - sprawdzenie otrzymanej sumy kontrolnej ICMP i obliczenie wysyanej sumy kontrolnej ICMP. Moemy te zmodyfikowa nasze programy klienta i serwera TCP oraz T /T C P , przedstawione w rozdziale 1.3 i 1.4, tak by mierzony by czas kadej transakcji
312
Dodatek A
(opisalimy to w rozdziale 1.6), i moemy wykona pomiary dla rnych rozmia rw pakietw. Wyniki takich pomiarw pokazane s na rysunku A.7. (Poniewa TCP unika fragmentacji, poczynajc od tego miejsca przedstawiamy wyniki po miarw dla pakietw o maksymalnym rozmiarze 1400 bajtw.)
Rysunek A .7
Pomiar czasu transakcji klient-serwer TCP i T/TCP w ramach jednego hosta (interfejs ptli zwrotnej)
W pomiarach przy uyciu Tcpdump czas by mierzony poczynajc od pierwszego segmentu wysanego przez klienta (SYN dla klienta TCP, kombinacja SYN, da nych i FIN dla klienta T/T C P), koczc na ostatnim segmencie otrzymanym od serwera (FIN dla klienta TCP, kombinacja danych i FIN dla klienta T/TC P). Rnica pomidzy lini odpowiadajc pomiarowi aplikacji TCP i lini Tcpdump dla TCP jest wic czasem potrzebnym na przetworzenie przez stos protokou wywoania connect i ostatniego segmentu FIN (wymian pakietw przedstawia rysunek 1.8). Rnica pomidzy lini aplikacji i lini Tcpdump dla klienta-serwera T /T C P jest czasem potrzebnym na przetworzenie w stosie protokou wywoania sendto klienta, ktre obejmuje dane klienta i ostateczn flag FIN (wymian pakietw przedstawa rysunek 1.12). Widzimy, e rnica pomidzy dwiema linia mi T /T C P (okoo 4 ms) jest wiksza ni rnica pomidzy dwiema liniami TCP (okoo 2,5 ms), co zrozumiae, poniewa stos protokou wykonuje wicej czynno ci w przypadku T /T C P (wysanie SYN, danych i FIN w pierwszym segmencie) ni w przypadku TCP (tylko SYN w pierwszym segmencie).
Sekcja A.2
313
Wyjtkowo duy czas transakcji w punkcie odpowiadajcym 200 bajtom raz jesz cze pokazuje, e jdro powinno wczeniej decydowa si na uycie klastra mbuf. Zauwamy, e wzrost wartoci w punkcie 200 bajtw dla TCP i T /T C P jest znacznie wikszy ni widzielimy to na rysunku A.6 dla Pinga i UDP. W przypad ku protokow datagramowych (ICMP i UDP), nawet jeli trzy bufory mbuf s uywane do przesania danych uytkownika, wykonywane jest tylko jedno odwo anie warstwy gniazd w jdrze do procedury wyjciowej protokou. Jest to w ywo anie funkcji sendto (rozdzia 16.7 w tomie 2). Natomiast dla protokou strumie niowego (TCP) procedura operacji wyjcia TCP jest woana dwukrotnie: pierwszy raz dla pierwszych 100 bajtw, drugi raz dla nastpnych 100 bajtw danych uytkownika. Rzeczywicie, Tcpdump potwierdza, e w tym przypadku przesya ne s dwa 100-bajtowe segmenty. Dodatkowe wywoanie procedury wyjciowej protokou jest czasochonne. Rnica pomidzy czasami aplikacji TCP i T /T C P, wynoszca okoo 4 ms dla wszystkich wielkoci pakietw, pojawia si poniewa T /T C P przetwarza mniej sz liczb segmentw. Na rysunkach 1.8 i 1.12 widzielimy 9 segmentw w przy padku TCP i 3 segmenty w przypadku T/TCP. Jasne jest, e zmniejszenie liczby segmentw, zmniejsza czas przetwarzania przez hosty na obu kocach poczenia. Na rysunku A.8 pokazane zostao podsumowanie pokazanych na rysunkach A.6 i A .7 pomiarw czasu aplikacji dla ukadw klient-serwer Ping, UDP, T/TC P i TCP. Pomijamy tu pomiary wykonane przy pomocy Tcpdump.
Rysunek A .8
Transakcje klient-serwer w pojedynczym komputerze (interfejs ptli zwrotnej) - Ping, UDP, T/TCP i TCP
314
Dodatek A
Wyniki s takie, jak si spodziewalimy. Czasy dla programu Ping s najmniejsze, i nie ma ju moliwoci otrzymania krtszych czasw, Ping jest bowiem czci jdra. Czasy transakcji UDP s nieco wiksze ni czasy dla Pinga, poniewa dane s dodatkowo dwukrotnie kopiowane pomidzy klientem i serwerem. Rnica pomidzy Pingiem i UDP jest jednak niewielka, ze wzgldu na ograniczone prze twarzanie protokou UDP. Czasy transakcji T /T C P s mniej wicej dwukrotnie wiksze ni czasy transakcji UDP, mimo e liczba pakietw pozostaje taka sama (nasz zegar aplikaq'i nie obejmuje ostatniego segmentu ACK z rysunku 1.12), co zwizane jest z bardziej rozbudowanym przetwarzaniem przez protok. Czas transakcji dla TCP jest o okoo 50% wikszy ni czas T /T C P - przyczynia si do tego wiksza liczba pakietw przetwarzanych przez protok. Rnice pomidzy UDP, T /T C P i TCP na rysunku A.8 nie s takie same jak na rysunku 1.14, ponie wa pomiary w rozdziale 1 zostay wykonane w prawdziwej sieci, podczas gdy czasy prezentowane w tym dodatku uzyskano dla interfejsu ptli zwrotnej.
A.3
Czas propagacji a szeroko pasma
W komunikacji sieciowej dwa czynniki okrelaj czas potrzebny na przesanie informacji: czas propagacji (laency) i szeroko pasma (bandwidth) [Bellovin 1992]. Pomijamy tu czas przetwarzania przez serwera i obcienie sieci, czyli kolejne dwa elementy, ktre oczywicie take wpywaj na czas transakcji mierzony przez klienta. Czas propagacji (zwany te propagation delay), czyli opnienie zwizane z czasem rozchodzenia si sygnau, to stay czas potrzebny na przeniesienie jednego bitu od klienta do serwera i z powrotem. Czas ten jest ograniczony przez prdko wiata i dlatego zaley od odlegoci, ktr optyczne lub elektryczne sygnay musz pokona pomidzy dwoma hostami. Dla transakcji pomidzy wschodnim i za chodnim wybrzeem USA warto RTT nigdy nie bdzie mniejsza ni mniej wicej 60 ms, chyba e kto zdoa zwikszy prdko wiata. Czas propagacji mona zmniejszy przenoszc komputery tak, by dystans midzy klientem i serwerem by mniejszy, lub unikajc tras o duym czasie propagacji (takich jak na przykad poczenia satelitarne).
Teoretycznie, czas przestania impulsu wietlnego przez cat szeroko USA powinien wynosi okoo 16 ms, co dawaoby RTT rwne 32 ms. W rzeczywistoci RTT wynosi 60 ms. A utor przeprowadzi eksperyment, w ktrym uruchomi Traceroute dla hostw znajdujcych si na przeciwlegych kracach USA i rejestrowa tylko minimalne wartoci RTT. Minimalna warto RTT pomidzy Kaliforni i W aszyngtonem wyniosa 58 ms, a pomidzy Kaliforni i Bostonem - 80 ms.
Szeroko pasma (bandwidth) okrela szybko, z jak bit moe by umieszczony w sieci. Nadawca uszeregowuje dane w sieci z szybkoci okrelon przez szero ko pasma. Zwikszenie pasma przenoszenia jest moliwe przez zakup szybszej sieci. N a przykad - jeeli linia telefoniczna w standardzie T l nie jest wystarczaj co szybka (okoo 1 544 000 bitw na sekund) - mona wydzierawi lini T3 (okoo 45 000 000 bitw na sekund).
Sekcja A.3
315
W ogrodowy jest tu dobr analogi (podzikowania dla an Lance Taylor): czas propagaq'i to czas potrzebny na przemieszczenie wody od kurka do spryskiwacza, szeroko pasm a przenoszenia jest natomiast objtoci wody wydobywajcej si ze spryskiwacza w kadej sekundzie.
Sieci staj si coraz szybsze (to znaczy zwiksza si pasmo przenoszenia), ale czas propagacji pozostaje niezmienny. Na przykad przesanie 1 miliona bajtw przez ca szeroko USA (zakadamy czas propagacji w jednym kierunku rwny 30 ms) przez lini telefoniczn typu T l, zajmuje 5,21 sekundy: 5,18 sekundy ma zwizek z szerokoci pasma, a czas propagacji wynosi 0,03. W tym przypadku czynni kiem dominujcym jest pasmo przenoszenia. Przy uyciu linii telefonicznej T3 cakowity czas wynosi 208 ms: 178 ms wynika z pasma przenoszenia, a 30 ms to czas propagacji. W tym drugim przykadzie czas propagacji staje si zbliony do opnienia zwizanego z pasmem przenoszenia, a w przypadku jeszcze szyb szych sieci - czas propagacji zaczyna dominowa. N a rysunku A.3 czas propagacji w obie strony odpowiada z grubsza punktowi przecicia si kadej linii z osi y. Grne dwie linie (z punktami przecicia dla okoo 202 i 155 ms) odpowiadaj przesyaniu danych pomidzy USA i Europ. Nastpne dwie linie (punkty przecicia dla 98 i 80 ms) odpowiadaj przesaniu danych przez ca szeroko USA. Nastpna linia (przecicie przy 30 ms) dotyczy dwch hostw na wschodnim wybrzeu USA. Rosnce znaczenie czasu propagacji, wraz ze wzrostem szerokoci pasma, zwi ksza znaczenie T/TC P. T /T C P zmniejsza bowiem czas propagacji o przynajmniej jedn warto RTT.
Opnienia uszeregowania a rutery

Zamy, e dzierawimy cze telefoniczne do dostawcy usug internetowych, przesyamy dane do innego hosta poczonego z Internetem przy pomocy cza Tl i wszystkie porednie cza s typu Tl lub szybsze. Zobaczymy, e pomiar czasw przesyania daje wyniki inne od oczekiwanych na podstawie prostego oszacowa nia. Jeeli na przykad przeanalizujemy lini rysunku A.3, rozpoczynajc si przy wartoci 80 ms i koczc si wartoci okoo 193 ms, co odpowiada poczeniu pomidzy hostami c o n n i x . c o m w Connecticut i n o a o . e d u w Arizonie, to dla wartoci RTT poczenia pomidzy przeciwlegymi kracami USA punkt przeci cia z osi y w okolicy 80 ms jest zrozumiay. (Program Traceroute informuje nas w istocie, e pakiety wdruj z Arizony do Kalifornii, nastpnie do Texasu, W a szyngtonu i w kocu do Connecticut.) Jeeli jednak obliczymy czas potrzebny na przesanie 1400 bajtw przez telefoniczne cze T l, otrzymamy 7,5 ms, tak wic oszacowalibymy RTT dla pakietu 1400-bajtowego na okoo 95 ms, co jest w arto ci znacznie rnic si od wartoci zmierzonej (193 ms). Mamy tu do czynienia z opnieniem uszeregowania (serialization delay), ktre ronie liniowo wraz z liczb poredniczcych ruterw, poniewa kady ruter musi ode bra cay datagram przed przekazaniem go do interfejsu wyjciowego. Rozwamy
316
Dodatek A
przykad z rysunku A.9. Wysyamy 1428-bajtowy pakiet z hosta po lewej stronie do hosta po prawej stronie, za porednictwem rutera (porodku). Zakadamy, e oba cza s liniami telefonicznymi typu T l, w ktrych wysanie 1428 bajtw zajmuje okoo 7,5 ms. Czas na rysunku pynie od gry do dou strony.
Pierwsza strzaka, od czasu 0 do czasu 1, reprezentuje przetwarzanie datagramu w komputerze nadawcy. Na podstawie pomiarw omwionych wczeniej w tym dodatku zakadamy, e czas tego przetwarzania wynosi 1 ms. Dane s nastpnie poddawane procesowi uszeregowania w sieci, od pierwszego do ostatniego bitu, co zajmuje 7,5 ms. Dodatkowo czas propagacji pomidzy dwoma kocami cza wynosi 5 ms, tak wic pierwszy bit dociera do rutera w czasie 6 ms, a ostatni bit w czasie 13,5 ms. Dopiero po odebraniu ostatniego bitu ruter przekazuje pakiet dalej. Zakadamy, e to przekazywanie zajmuje 1 ms. Pierwszy bit zostaje wic wysany przez rutera w czasie 14,5 ms i dociera do odbiorcy 1 ms pniej (czas propagacji dla drugiego
Sekcja A.3
317
cza). Ostatni bit dociera do odbiorcy w czasie 23 ms. Zakadamy wreszcie, e przetwarzanie w komputerze odbiorcy zajmuje znowu 1 ms. Rzeczywista szybko przesyania wynosi wic 1428 bajtw w cigu 24 ms, czyli 476 000 bitw na sekund. Jeeli zignorujemy 3 ms zuyte na przetwarzanie przez hosty i ruter, otrzymujemy szybko przesyania danych rwn 544 000 bitw na sekund. Tak jak wspomnielimy wczeniej, opnienie uszeregowania jest liniow funkcj liczby ruterw na drodze pakietu. Efekt ten zaley od szybkoci cza (pasmo przenoszenia), rozmiaru kadego pakietu i liczby poredniczcych hopw (liczby poredniczcych ruterw). Na przykad opnienie uszeregowania dla pakietu 552-bajtowego (typowy segment TCP zawierajcy 512 bajtw danych) wynosi niemal 80 ms przy szybkoci cza rwnej 56 000 bitw na sekund, 2,86 ms w przypadku linii T l i tylko 0,13 ms w linii T3. Dlatego 10 hopw Tl dodaje do cakowitego czasu 28,6 ms (co jest niemal rwne czasowi propagacji w jedn stron przez cae Stany Zjednoczone), podczas gdy 10 hopw T3 dodaje tylko 1 ms (co prawdopodobnie mona pomin w porwnaniu z czasem propagacji). Moemy ostatecznie powiedzie, e opnienie uszeregowania jest efektem zwi zanym z czasem propagacji, a nie z szerokoci pasma. Na przykad na rysunku A.9 host wysyajcy, przedstawiony po lewej stronie, moe zacz wysya drugi pakiet w czasie 8,5, a nie czeka do czasu 24 z wysaniem drugiego pakietu. Jeeli host po lewej stronie wysya 10 bezporednio po sobie nastpujcych 1428-bajtowych pakietw, ostatni bit ostatniego pakietu - zakadajc brak czasu martwego pomidzy pakietami - odebrany zostaje w czasie 91,5 (24 + 9 x 7,5). Daje to szybko przesyania danych rwn 1 248 525 bitw na sekund, co jest bliskie szybkoci cza T l . W odniesieniu do TCP wystarczy zwikszy rozmiar okna, by skompensowa opnienie uszeregowania. Wracajc do naszego przykadu, w ktrym dane byy przesyane pomidzy c o n n i x . c o m i n o a o . e d u - jeeli okrelimy rzeczywist marszrut i znamy szyb ko wszystkich czy - musimy te wzi pod uwag opnienie uszeregowania w kadym z 12 ruterw pomidzy naszymi dwoma hostami. Zakadajc czas propagacji rwny 80 ms i czas przetwarzania w kadym z poredniczcych rute rw rwny 0,5 ms, otrzymujemy warto 187 ms. Jest ona znacznie blisza w arto ci zmierzonej ni nasze wczeniejsze oszacowanie - 95 ms.
Dodatek B Programowanie aplikacji T/TCP

W czci pierwszej okrelilimy dwie korzyci wynikajce ze stosowania T /T C P : uniknicie potrjnego uzgodnienia TCP skrcenie stanu TIME_WAIT, gdy czas trwania poczenia jest krtszy ni MSL Jeeli oba hosty zaangaowane w poczeniu TCP potrafi obsugiwa T /T C P , wwczas druga z tych zalet jest dostpna dla wszystkich aplikacji, bez adnych zmian w kodzie rdowym. Uniknicie potrjnego uzgodnienia jest moliwe jednak tylko wtedy, gdy w ko dzie aplikacji znajduj si odwoania do sendto lub sendmsg, zamiast odwoa do c o n n e c t i wri te. Poczenie flagi FIN z danymi jest moliwe, gdy aplikacja, zamiast wywoywania shutdown, w ostatnim wywoaniu send, s e n d t o lub se n d m s g podaje flag MSG_E0F. Kody klienta i serwera w rozdziale 1 uwzgldniaj te zmiany. Dla zachowania moliwie najwikszej przenonoci oprogramowania powinni my programowa aplikacje tak, by korzystay z zalet T /T C P , gdy: host, na ktrym program jest kompilowany, obsuguje T /T C P aplikacja zostaa skompilowana tak, by wykorzystywa T/TC P. Drugi warunek oznacza rwnie, e musimy w trakcie wykonywania aplikacji sprawdzi, czy host, w ktrym dziaa program, obsuguje T /TC P, moliwe jest bowiem czasami, e program by kompilowany z inn wersj systemu operacyjne go ni wersja wykorzystywana w trakcie dziaania programu. Host, w ktrym program jest kompilowany, obsuguje T /T C P, jeeli w nagwku < s y s / s o c k e t .h> zostaa zdefiniowana flaga MSG_E0F. Fakttenm oe zosta wyko rzystany w instrukcji #i f d e f .
#ifdef MSG_E0F /* host o b s u g u j e T / T C P */ Ile 1 se /* host nie o b s u g u j e T/ T C P */ #endi f
Drugi warunek oznacza, e aplikacja wykonuje niejawne otwarcie (sendto lub se n d m s g z podaniem adresu przeznaczenia, bez wywoania connect), ale jedno czenie potrafi obsuy niepomylne zakoczenie takiego otwarcia, gdy host nie zna T/TC P. Wszystkie funkcje operacji wyjcia zwracaj komunikat ENOTCONN, jeeli zostan wykonane dla gniazda zorientowanego na poczenie, ktre nie jest poczone, w komputerze, ktry nie obsuguje T /T C P (strona 511 w tomie 2). Odnosi si to zarwno do systemw wywodzcych si z systemu Berkeley, jak i do
320
Programowanie aplikacji TfTCP
Dodatek B
biblioteki gniazd SVR4. Jeeli aplikacja otrzymuje taki komunikat, na przykad z odwoania do sendto, musi wtedy wywoa connect.
Klient i serwer TCP lub T/TCP

Przedstawione przed chwil idee moemy zaimplementowa w programach, kt re s prostymi modyfikacjami klientw i serwerw T /T C P oraz TCP z rozdziau 1. Podobnie jak w przypadku programw w C w rozdziale 1, nie omawiamy szcze gowo przedstawionych kodw, zakadajc pewn znajomo interfejsu API gniazd. Najpierw prezentujemy kod funkcji ma i n klienta (rysunek B.l). ------------------------------------------------------------------------------------------------1 /Mnclude "clis er v .h " 2 int 3 m a i n ( i n t argc, c ha r * ar g v[ ]) 4 ( /* kl ie n t T/ T C P lub TCP */ 5 st r u c t s o c k a d d r _ i n serv; 6 char request[REQUEST], reply[REPLY]; 7 int sockfd, n; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 if (argc != 3) e r r _ q u i t ( " u s a g e : Cl i en t <IP a d d r es s of s e r v e r > m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v .s i n _ f a m i l y = A F_IN E T ; serv.sin_addr.s_addr = inet_addr(argv[l]); s e r v .s i n _ p o r t = h t o n s ( a t o i (a r g v [ 2 ] )); /* u t w o r z e n i e da ni a requ e st [] <port# >" ) ;
client.c
...
*/
if (( so ck f d = s e n d _ r e q u e s t ( r e q u e s t , REOUEST, 1, (SA) &serv, s i z e o f ( s e r v ) )) < 0) e r r _ s y s ( " s e n d _ r e q u e s t e r ro r %d", sockfd): if ((n = r e a d _ s t r e a m ( s o c k f d , reply, e r r _ s y s ( "read error"); /* p r z e t w o r z e n i e e x i t (0); "n" b a j t w REPLY)) < 0) reply[] ... */
od po w i e d z i
22 }
------------------------------------------------------------------------------------------------Rysunek B .l Funkcja ma i n dla TfTCP lub TCP

8-13
client.c
Internetowa strukura adresowa jest wypeniana adresem IP serwera i nu merem portu. Obie te informacje s wzite z linii polecenia.
15-17
Funkcja s e n d _ r e q u e s t wysya danie do serwera. Zw raca ona deskryptor gniazda - jeeli zostaa wykonana pomylnie, lub warto ujemn - w przypadku bdu. Trzeci argument (1) informuje funkcj, e po wysaniu dania ma by wysany znak koca pliku. 18-19 Funkcja r e a d _ s t r e a m pozostaje bez zmian w stosunku do rysunku 1.6. Funkcja s e n d _ r e q u e s t jest pokazana na rysunku B.2.
Sekcja
321
----------------------------------------------------------------------------------------------- 1 #include 2 #include 3 #include " cl i serv.h" <errno.h> <netinet/tcp.h>
sendrequest.c
4 /* d a n i e transak c ji z o s t a j e w y s a n e do serw er a u y w a j c T/TCP, jeeli 5 * je st to mo liwe. Jeli n ie - uy t y j e s t p r ot o k TCP. W p r z y p a d k u * b du zw r ac a n a j e s t w a r t o < 0. Przy p o m y l n y m w y k o n a n i u z w r a c a n y * jest n i e u j e m n y d e s k r y p t o r gn iazda. */ 6 i nt 7 s e n d _ r e q u e s t ( c o n s t void *requ e st , s i z e _ t nbyt es, 8 co nst SA se rvptr, int ser vs iz e ) 9 ( 10 int sockfd, n; 11 12 if (( so ck f d = s o c k e t (PF_INET, r e tu rn (-1); MSG_E0F int sendeof.
S 0 C K _ S T R E A M , 0)) <
0)
13 # i f d e f 14 15 16 17 18 19
20
/* k o m p i l u j c y host zna T / T C P */
n = 1; if ( s e t s o c k o p t ( s o c k f d , IPPR0T 0_ TC P, T C P _N OP U SH . (char *) &n, s iz eo f ( n ) ) < 0) ( if (errno = = EN0PR0T 00 PT ) goto doconne ct ; r e tu rn (-2):
]
if ( s e n d t o t s o c k f d , request, nbytes, s e n d e o f ? M S G _ E 0 F se rvptr, s e r v si ze ) != nbytes) [ if (errno = = E N OTCONN) goto d o co nn ec t ; r e tu rn (-3); (sockfd); /* sukces */ /* host w y k o n u j c y nie zna T / T C P */ : 0.
21 22 23 24 25 26 27
} r et ur n
28 doconnect: 29 # e n d i f 30 31 32 33 34 35 36 37 38 39 40 41 }
/* * Kod u m i e s z c z o n y poniej jest potrzebny, * T/TCP. Kod ten j es t w y k o r z y s ty w an y, gdy */
nawet gdy k o m pi lu j c y host zna host w y k o n u j c y n ie zna T/TCP.
if ( co n ne c t ( s o c k f d , se rvptr, s e r v si ze ) < 0) r et ur n (-4); if ( w r i t e( s oc kf d, request, nbyt es ) !=nbytes) r et ur n (-5) hu t d o w n t s o c k f d , 1) < 0) i f (s e nd eo f && r et ur n (-6) re t u r n (sockfd) /* s ukces */
----------------------------------------------------------------------------------sendrequest.c Rysunek B.2 Funkcja s e n d _ r e q u e s t : wysanie dania przy uyciu T/TCP i TCP
Prba sendto dla T/TCP
13-29 Ten fragment kodu jest wykonywany, jeeli kompilujcy host obsuguje T/TC P. Opcj gniazda T C P _ N 0 P U S H omwilimy w rozdziale 3.6. Jeeli host, w ktrym program jest wykonywany, nie rozumie T/T C P, to odwoanie do s e t s o c k o p t zwraca E N 0 P R 0 T 0 0 P T i robimy skok do etykiety doconnect, gdzie wykonane zostanie zwyke connect. Znak koca pliku zostaje wysany po da niu, jeeli trzeci argument wywoania funkcji by niezerowy.
322
Programowanie aplikacji TfTCP
Dodatek B
Zwyke odwoania TCP

30-40
Jest to zwyky kod TCP: connect, wri te i opcjonalnie shutdown.
Zmiany w kodzie funkcji ma i n serwera (rysunek B.3) s minimalne. --------------------------------------------------------------------------- :-------------------1 #include "cli se r v. h" 2 int 3 m a i n C i n t argc, char * ar gv [ ]) 4 { /* s er w er T / T C P lub TCP */ 5 s t r u c t s o c k a d d r _ i n serv, cli; 6 c ha r r e q u e s t [ R E Q U E S T ] , r e p l y [ R E P L Y ]; 7 int list enfd, sockfd, n, clilen; 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 if (ar gc != 2) e r r _ q u i t ( " u s a g e ; s er v er <port# >" ); if ( ( l i s t e n f d = s o c k e t ( P F _I N E T , S 0 C K _ S T R E A M , 0)) < 0) e r r _ s y s (" so ck e t e r r o r ); m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v .s i n _ f a m i l y = A F_IN E T ; serv.sin_addr.s_addr = htonl(INADDR_ANY); s e r v .s i n _ p o r t = h t o n s ( a t o i (a r g v [1])); if ( b i n d d i s t e n f d , (SA) &ser v, e r r _ s y s ("bind err or"); s iz e of ( s e r v ) ) < 0)
seruer.c
if (1i s t e n ( 1 i s t e n f d , S0 MA X C0 NN ) < 0) err_sys( listen er ror"); for ( ; ; ) { cl i len = si zeof(cl i ); if ((sock f d = a c c e p t t 1 i s t e n f d , (SA) &cli, c l i l e n ) ) < 0) e r r _ s y s (" acc ep t e r r o r ); if ((n = r e a d _ s t r e a m ( s o c k f d , request, err_sys("read e r r o r ); /* p r z e t w o r z e n i e n b a j t w d an ia * u t w o r z e n i e o dp ow i ed zi reply[j . . . R E O UE S T) ) < 0) re q u e s t [ ] i
*/
*/
27 #i f n de f M S G _ E 0 F 28 //define M S G _ E 0 F 0 29 # e n d i f 30 31 32 33 34 ) )
/* s e n d () z f l a g s= 0 j e s t i d e n t y c z n e z w r i t e O M S G _ E 0 F ) != REPLY)
if (se nd t so ck fd , reply, REPLY, e r r _ s y s ( " s e n d error"); close(sockfd);
------------------------------------------------------------------------------------------------Rysunek B.3 Funkcja ma i n serwera

27-31
semer.c
Jedyna zmiana polega na tym, e zawsze wywoywana jest funkcja send (w kodzie z rysunku 1.7 woana bya funkcja wri te ), z trzecim argumentem rw nym zero, jeeli host nie obsuguje T/TC P. Nawet jeli host kompilujcy zna T/T C P , a host wykonujcy program nie zna T /T C P (w tym przypadku warto MSG_E0F ustalona w trakcie kompilacji nie zostanie zrozumiana przez jdro w trakcie wykonania), funkcja sosend w jdrach wywodzcych si z systemu Berke ley nie protestuje w przypadku uycia nieznanych flag.
Bibliografia
F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey i B. Alberti, 1993, The Internet Gopher Protocol, RFC 1436 (marzec), 16 stron F. Baker (red.), 1995, Requirements for IP Version 4 Routers, RFC 1812 (czerwiec), 175 stron
Odpowiada RFC 1122 [Braden 1989] dla rutera. Zastpuje RFC 1009 i RFC 1716.
S. Barber, 1995, Common NNTP Extensions, Internet Draft (czerwiec),

d r a f t - b a r b e r - n n t p - i m p - 0 1 .txt
S. M. Bellovin, 1989, Security Problems in the TCP/IP Protocol Suit Computer Communication Review", tom 19, nr 2, str. 32-48 (kwiecie)
f t p : / / f t p . r e s e a r c h . a t t . c o m / d i s t / i n t e r n e t _ s e c u r i t y / i p e x t .ps .Z
S. M. Bellovin, 1992, A Best-Case Network Performance Model", informacja pry watna T. Bem ers-Lee, 1993, Hypertext Transfer Protocol, Internet Draft, (listopad), 31 stron
draft-ietf-i i ir-http-00.txt
Nieaktualny ju dokument typu Internet Draft", jest to jednak oryginalna specyfikacja HTTP wersja 1.0.
T. Bemers-Lee, 1994, Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as Used in the World-Wide Web, 28 stron, RFC 1630 (czerwiec)
h t t p :/ / w w w . w 3 .o r g / h y p e r t e x t / W W W / A d d r e s s i n g / U R L / U R l _ 0 v e r v i e w .html
T. Bemers-Lee i D. Connolly, 1995 Hypertext Markup Language - 2.0, Internet Draft (sierpie)
d r a f t - i e t f - h t m l - s p e c -0 5. tx t
T. Bemers-Lee, R. T. Fielding i H. F. Nielsen, 1995, Hypertext Transfer Protocol HTTP/1.0, Internet Draft (sierpie), 45 stron
draft-ietf-http-vl0-spec-02.ps
T. Bemers-Lee, L. Masinter i M. McCahill (red.), 1994, Uniform Resource Locators (URL), RFC 1738 (grudzie), 25 stron R. T. Braden, 1985, Towards a Transport Seruicefor Transaction Processing Applica tions, RFC 955 (wrzesie), 10 stron R. T. Braden (red.), 1989, Requirements for Internet Hosts - Communication Layers, RFC 1122 (padziernik), 116 stron
Pierwsza cz Host Reuirements RFC". W tej czci omwione s: w arstw a cza, IP, TCP i UDP.
R. T. Braden, 1992a, TIME-WAIT Assassination Hazards in TCP, RFC 1337 (Maj), 11 stron R. T. Braden, 1992b, Extending TCP for Transactions - Concepts, RFC 1379 (listopad), 38 stron
324
Biblia TCP/IP - tom III
Bibliografia
R. T. Braden, 1993, TCP Extensions for High Performance: An Update, Internet Draft (czerwiec), 10 stron
h ttp ://w w w .n o a o ,e d u /~ rste v e n s/tcp lw -e x te n si on s. t x t Jest to aktualizacja RFC 1323 [Jacobson, Braden i Borman 1992],
R. T. Braden, 1994, T/TCP - TCP Extensions for Transactions, Functional Specification, RFC 1644 (lipiec), 38 stron L. S. Brakmo i L. L. Peterson, 1994, Performance Problems in BSD4.4 TCP"
f tp ://c s .a r iz o n a .e d u /x k e r n e l/P a p e r s /tc p _ p r o b le m s . ps
H-W. Braun i K. C. Claffy , 1994, Web Traffic Characterization: An Assessment ofthe Impact of Caching Documents from NCSA's Web Seruer, Proceedings of the Second World Wide Web Conference '94: Mosaic and the Web" (padziernik), Chicago, str. 1007-1027
h ttp ://w w w .n csa. ui u c . edu/SDG/IT94/Proceedi n gs/D D ay /claffy /m ain . html
D. P. Cheriton, 1988, VMTP: Versatile Message Transaction Protocol, RFC 1045 (luty), 123 strony C. R. Cunha, A. Bestavros i M. E. Crovella, 1995, Characteristics of WWW Client-based Traces, BU-CS-95-010, Computer Science Department, Boston University (lipiec)
f t p : / / c s - f t p . b u . ed u /tech rep orts/95-010-w w w -cl i e n t - t r a c e s . p s . Z
R. T. Fielding, 1995, Relative Uniform Resource Locators RFC 1808 (czerwiec), 16 stron S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu i L. Zhang, 1995, A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing, Computer Communication Review", tom 25 nr 4 (padziernik), strony 342-356
f t p : / / f t p , e e .1 b l . g o v /p a p e rs/srm l. t e c h . p s . Z
M. Horton i R. Adams, 1987, Standard for Interchange of USENET Messages, RFC 1036 (grudzie), 19 stron V. Jacobson, 1988, Congestion Avoidance and Control, Computer Communication Review", tom 18, nr 4, (sierpie), strony 314-329
f t p : / / f t p . e e . 1b l . gov/papers/congavoid . p s. Z Opis procedury powolnego startu i algorytmw unikania przecienia dla TCP. Klasyka.
V. Jacobson, 1994, Problems ivith Arizona's Vegas, end2end-tf mailing list, 14 marca 1994
h ttp ://w w w .n o a o ,e d u /-rste v e n s /v a n j. 9 4 m a r l4 .tx t
V. Jacobson, R. T. Braden i D. A. Borman, 1992, RFC 1323 TCP Extensions for High Performance, 37 stron (marzec)
Opisuje opcje skali okna i znacznika czasu oraz algorytm PAWS. Omawia rwnie pow ody, dla ktrych te modyfikacje s potrzebne. Aktualniejsze informacje m ona znale w pracy [Braden 1993],
V. Jacobson, R. T. Braden, L. Zhang, 1990, TCP Extensionsfor High-Speed Paths, RFC 1185,21 stron (padziernik)
Mimo e aktualniejsze informacje podawane s w RFC 1323, dodatek na temat zabezpie czenia przed starymi, zduplikowanymi segmentami w TCP jest w art przeczytania.
Bibliografia
Biblia T C P IP - tom III
325
B. Kantor i P. Lapsley, 1986, Network News Transfer Protocol, III stron (luty), RFC 977 S. R. Kleiman, 1986, Vnodes: An Architecture for Multiple File System Types in Sun UNIX, Proceedings of the 1986 Summer USENIX Conference", Atlanta, Ga. strony 238-247 T. T. Kwan, R. E. McGrath i D. A. Reed, 1995, User Access Pattems to NCSA's World Wide Web Server" http://www-pablo.cs.uiuc.edu/Papers/WWW.ps. Z S. J. Leffler, M. K. McKusick, M. J. Karels i J. S. Quarterman, 1989, The Design and Implementation of the 4.3BSD UNIX Operating System", Addison-Wesley, Reading, Mass.
W tej ksice opisany jest system 4.3BSD Tahoe. Opis nowszej wersji BSD zaw arty jest w ksice [McKusick i inni 1996],
P. E. McKenney, i K. F. D ove, 1992, Ejficient Demultiplexing oflncoming TCP Packets, Computer Communication Review", tom 22, nr 4 (padziernik), strony 269279 M. K. McKusick, K. Bostic, M. J. Karels i J. S. Quarterman, 1996, The Design and Implementation of the 4.4BSD Operating System" Addison-Wesley, Reading, Mass. T. Miller, 1985, Internet Reliable Transaction Protocol Functional and Interface Specification, RFC 9 38,16 stron (luty) J. C. Mogul, 1995a, Operating Systems Support for Busy Internet Seruers, TN-49, Digital Western Research Laboratory (maj) http://www.research.di g i t a l . com/wrl/techreports/abstracts/TN-49. htm l J. C. Mogul, 1995b, The Case for Persistent-Connection HTTP, Computer Communi cation Review", tom 25, nr 4, strony 299-313 (padziernik) http: //www.research.di gital.com/wrl/techreports/abstracts/95. 4 . htm l J. C. Mogul, 1995c, informacja prywatna J. C. Mogul, 1995d, Network Behavior of a Busy Web Sewer and its Clients, Raport WRL Research 9 5 /5 , Digital Western Research Laboratory (padziernik) http://www.research.di g i tal.com/wrl/techreports/abstracts/95.5 . htm l J. C. Mogul i S. E. Deering, 1990, Path M TU Discovery, RFC 1191,19 stron (kwiecie) A. Olah, 1995, informacja prywatna V. N. Padmanabhan, 1995, Improving World Wide Web Latency, UCB/CSD -95-875, Computer Science Division, University of California, Berkeley (maj) http://www.cs. berkeley. edu/~padmanab/papers/masters-tr.ps C. Partridge, 1987, Implementing the Reliable Data Protocol (RDP), Proceedings of the 1987 Summer USENIX Conference", Phoenix, Ariz., strony 367-379 C. Partridge, 1990a, Re: Reliable Datagram Protocol, Message-ID < 60240@bbn.BBN.C0M>, Usenet, grupa comp.protocols.tcp-ip (padziernik)
326
Biblia TC P /IP -o m III
Bibliografia
C. Partridge, 1990b, Re: Reliable ??? Datagram Protocols, Message-ID <6034tM3baBBN.COM>, Usenet, grupa comp.protocols.tcp-ip (padziernik) C. Partridge i R. Hinden, 1990, Version 2 of the Reliable Data Protocol (RDP), RFC 1151,4 strony (kwiecie) V. Paxson, 1994a, Growth Trends in Wide-Area TCP Connections, IEEE Network", tom 8, nr 4 (lipiec/sierpie), strony 8-17 ftp: / / f tp .e e . l b l . gov/papers/WAN-TCP-growth-trends. ps. Z V. Paxson, 1994b, Empirically-Derived Analytic Models of Wide-Area TCP Connections, IEEE/A C M Transactions on Networking", tom 2, nr 4, strony 316-336 (sier pie) ftp: / / f t p. e e .1bl. gov/papers/WAN-TCP-models. ps.1 V. Paxson, 1995a, informaq'a prywatna V. Paxson, 1995b, Re: Traceroute and TTL, Message-ID < 48407@dog.ee.lbl.gov>, Usenet, grupa comp.protocols.tcp-ip (wrzesie) http://www.noao.edu/~rstevens/paxson.95sep29.txt J. B. Postel, red., 1981a, Internet Protocol, RFC 791,45 stron (wrzesie) J. B. Postel, red., 1981b, Transmission Control Protocol, RFC 793, 85 stron (wrzesie) D. Raggett, J. Lam i I. Alexander, 1996, The Definitive Guide to HTML 3.0: Electronic Publishing on the World Wide W eb", Addison-Wesley, Reading, Mass. S. A. Rago, 1993, UNIX System V Network Programming", Addison-Wesley Reading, Mass J. K. Reynolds i J. B. Postel, 1994, Assigned Numbers, RFC 1700, 230 stron (padziernik)
Ten dokument RFC, jest regularnie uaktualniany. Aktualny num er mona odszuka w spisie RFC.
M. T. Rose, 1993, The Internet Message: Closing the Book with Electronic Mail", Prentice-Hall, Upper Saddle River, N.J P. H. Salus, 1995, Casting the Net: From ARP ANET to Internet and Beyond", Addison-Wesley, Reading, Mass. Tsutomu Shimomura, 1995, Technical details of the attack described by Markoffin NYT, Message-ID <3g5gkl$5jl@ariel. sdsc.edu>, Usenet, grupa comp.protocols.tcp-ip, (stycze) http://www.noao. edu/~rstevens/shimomura.9 5j an2 5 . txt
Szczegowy opis techniczny wamania internetowego z grudnia 1994, w raz z odpow ied nimi zaleceniami CERT.
S. E. Spero, 1994a, Analysis of HTTP Performance Problems" http://sunsite.unc.edu/mdma-release/http-prob.html S. E. Spero, 1994b, Progress on HTTP-NG", http://www.w3.org/hypertext/WWW/Proto co 1s/HTTP-NG/http-ng-status. htm l L. D. Stein, 1995a, How to Set Up and Maintain a World Wide Web Site: The Guide for Information Providers" Addison-Wesley, Reading, Mass.
Bibliografia
Biblia TCPIP - om III
327
W. R. Stevens, 1990, UNIX Network Prograiruning", Prentice-Hall, Upper Saddle River, N .J. W. R. Stevens, 1992, Advanced Programming in the UNIX Environment" Addi son-Wesley Reading, Mass. W. R. Stevens, 1994, TC P/IP Illustrated, tom 1: The Protocols", Addison-Wesley Reading, Mass.
Pierwsza z trzech ksiek w niniejszej serii. Zawiera wyczerpujce wprow adzenie do protokow internetowych.
D. Velten, R. Hinden i J. Sax, 1984, Reliable Data Protocol, RFC 9 08,57 stron (lipiec) G. R. Wright i W. R. Stevens, 1995, TCP/IP Illustrated, tom 2: The Implementation, Addison-Wesley Reading, Mass.
Druga ksika z niniejszej serii. Jest to opis implementacji protokow internetowych w systemie 4.4BSD-Lite.
Indeks
! #define 3, 239 #ifdef 319 -D16227 -display 234 -p 188 -r 188 -s 187 -w 188, 208 .newsrc 227, 229 .ps.Z 177 .minit 227 .miast 227 / 245 /dev/log 235 /dev/lp 235 /tm p/.Xll-unix 254 / tmp/ .XI l-unix/X0 235,254 /tm p/foo 261-262 / var/news/ run 235 fd 264,267 argv 3,264, 267 inetsw 78,100 3WHS 71 4.2BSD XVI, 27,110,244 4.3BSD Reno 27,267 286,301 4.3BSDTahoe27 4.4BSD-Lite 27 4.4BSD-Lite2 27 4.4BSD-Lite2, kod rdowy 28 </BODY> 172 </HEAD> 172 </HTML> 172 <A> 173 <BODY> 172 172 <CENTER> 172 <DD> 173 <H1> 172 <HEAD> 172 <HTML> 172 <IMG> 172 <netinet/tcp_seq.h> 99
<netinet/timer.h> 103 172 <sys/protosw.h> 77 <sys/socket.h> 10,77,198,319 <sys/un.h> 237,239 <TITLE> 172
A
accept 11,17,48,183,199,234,258,264, 269, 274-275,284, 297 ACCESSPERMS 255 ACCESSPERMS, staa 255 Adams R. 221 adres interfejsu ptli zwrotnej 236,308 AF_LOCAL 234 AF_LOCAL, staa 234 AF_UNIX 234,244 AF_UNIX, staa 234,244 again 53 agresywne zachowanie 207 AIX15,28,215,235 aktywne otwarcie 144-145,147,149 aktywne zamknicie 13,31,37,62-64,67,103 Alberti B. 323 Alexander J. 326 algorytm unikania przecienia 181 alias adresu IP 190 Allow 175 ALT 172 ANSI3 API 13, XVI, 25-26,38,233-234,320 APPA 127 argument przepenienia 198 argument przepenienia, funkcja listen 198 ARP 49,87, 93,236 ARPANET 205,221,326 article 226,228,230 ASCII 223,231 Authorization 175 aw.com 308
330
Indeks
B
Baker F. 6 4 ,3 2 3 Barber S. 221, 323 B ellovinS . M .4 5 , 3 1 4 ,3 2 3 b erkeley.edu 308 Berners-Lee T. 323 Bestavros A . 324 bibliografia 323 bind 5 ,1 7 , 6 1 ,2 5 2 -2 5 4 ,2 5 8 ,2 7 6 blok k on troln y TCP 31, 3 5 ,1 0 1 blok PCB 6 0 ,1 3 7 ,1 6 1 ,2 1 5 -2 1 7 ,2 1 9 ,2 4 5 -2 4 6 , 2 4 9 ,2 5 1 -2 5 2 ,2 5 4 -2 5 5 ,2 6 1 -2 6 2 ,2 7 1 ,2 7 5 -2 7 6 bloki PCB T /T C P 95 bd p ow oln ego startu 154 bd SYN _RCV D 202 b d T cpd u m p 51 b od y 226 B orm an D. A. 32, 324 Bostic K. 325 Boulos S. E. XVI b o u n d ary = 184 B P F 305 B rad en R. T. 1 3 ,1 5 , 25-26, 32, 38, 65, 7 4 ,1 0 2 , 1 1 0 ,1 1 9 ,1 2 3 ,1 4 6 ,1 6 3 ,1 6 7 ,3 2 3 - 3 2 4 B rakm o L. S. 61, 324 B rau n H -W . 1 9 0 ,3 2 4 break 293 BSD 27 B S D /O S 15, 28, 4 5 ,1 8 7 ,2 1 1 ,2 3 5 -2 3 6 , 305, 311 bsdi 2 0 - 2 1 ,2 8 ,4 3 ,5 4 ,3 0 6 ,3 0 8 - 3 0 9 bufsize 127 b zero 106
c
case 1 1 1 ,1 4 4 ,1 4 9 , 249 case TCPS_SYN _RECEIV ED 133 C C _G EQ 100 C C _G T 100 C C J N C 9 9 ,1 0 2 ,1 6 3 C C _L EQ 100 C C _LEQ , m akroinstrukcja 100 C C _LT 100 C C _L T , m akroinstrukcja 100 cc_recv 3 5 ,1 0 1 ,1 1 2 ,1 2 1 ,1 3 1 ,1 3 9 ,1 4 1 ,1 4 5 , 150-151 cc_send 35, 9 9 ,1 0 1 ,1 1 1 - 1 1 2 ,1 4 1 ,1 6 3 C C new 163 C ER T 326 C h eriton D. P. 25, 324 cin_clsroute 94 Claffy K. C. 190, 324
Clark J .J . XVII cliserv 3 cliserv.h 3-5 close 1 7 9 ,2 8 5 close, funkcja 2 1 2 ,2 6 9 , 285 C LO SE_W A IT, stan 1 6 ,3 6 ,4 6 ,2 1 2 C LO SE_W A IT*, stan 3 9 ,4 7 CLO SED, stan 3 6 ,4 7 , 6 5 ,1 6 4 closef 2 9 2 ,2 9 5 ,3 0 1 -3 0 2 CLOSING 1 4 9 -1 5 0 ,1 5 4 ,1 5 7 ,2 1 2 CLOSING* 39 cm sg_d ata, czon 286 cm sg_len 286 cm sg_len, czon 286 cm sg_level, czon 2 8 6 ,2 9 0 ,2 9 3 cm sg_typ e, czon 286 cm sgh dr 2 8 6 ,2 8 9 cm sgh dr, stru ktu ra 2 8 6 ,2 8 8 -2 8 9 cm sghdr{} 288 com p .protocols.tcp-ip 2 2 5 ,2 2 7 ,2 2 9 com p C C _IN C , m akroinstrukcja 9 9 ,1 0 2 ,1 6 3 com p ress 177 connect 8 ,1 1 ,1 7 ,2 1 ,2 9 ,6 1 ,7 8 - 7 9 , 95-96, 98, 1 4 1 ,1 5 9 -1 6 0 ,1 6 2 ,1 6 4 ,1 6 7 ,1 7 9 ,1 9 9 ,2 3 4 , 2 4 5 -2 4 6 ,2 5 6 ,2 5 8 -2 5 9 ,2 7 6 , 312, 319-322 con n ix.com 3 07-308, 315, 317 C onolly D. 323 C ontent-Encoding 175-176 Content-Length 1 7 5 ,1 7 7 ,1 8 4 C ontent-Type 1 7 5 -1 7 6 ,1 8 4 control 2 3 5 ,2 7 8 ,2 8 0 cop you t 267, 269 C ox A. XVI C R EA TE 253 C R EA TE, staa 253 Crovella M. E. 324 C unha C. R. 324 czas propagacji 22, 305, 314-315, 317 czas trw an ia p oczenia 36, 59, 61, 67-69, 75, 9 9 ,1 0 1 -1 0 3 ,1 5 0 ,1 5 5 -1 5 7 ,1 6 1 ,1 6 7 ,2 2 6 ,3 1 9
D
dane statystyczn e T /T C P 100 D ate 174-176 D eering S. E. 5 6 ,2 0 4 ,2 0 6 ,3 2 5 D eSim one A. XVI d esk ryptor 2 ,1 1 , XVI, 234, 241, 243-244, 248, 252, 258, 264-265, 267, 269, 277-278, 280, 282-302, 304, 320 deskryptor d ow oln ego typ u 283 deskryptor w locie 242-243, 284 D F, flaga 56, 206
Indeks
331
d iagram y zalenoci czasow ych 45 D ISPLA Y 234 D ISPLA Y, zm ienna system ow a 234 dugi szeroki p otok 27 DNS 1 ,5 do m _rtattach 243 do w hile 296 d ob rze-zn any p o rtu 5 dobrze znana n azw a cieki 276 d ocon nect 321 d od ata 1 3 1 ,1 3 3 ,1 5 3 d od ata, etykieta 137 d om _d ispose 2 4 3 ,2 9 2 ,3 0 1 d om _externalize 2 4 3 ,2 9 0 d om _fam ily 243 dom _init 243 d om _m axrtk ey 243 d om _n am e 243 d om _n ext 243 d om _p ro tosw 243 d om _p rotosw N PR O T O S W 243 d om _rtattach 8 4 ,2 4 3 dom _rtoffset 243 dom ain 2 4 2 -2 4 3 ,2 6 5 dom ainf) 241 dom aininit 243 D ove K. F. 217, 325 draining 8 9 ,9 1 dropsocket 143 d rzew o p od staw o w e 81 D T Y P E _ 299 D TYPE_SO CK ET 265 d w ukierunkow e zam knicie 62 d w ustronn e zam knicie TCP 62
ESTABLISH ED , stan 3 9 ,4 0 ,4 6 - 4 7 ,5 2 ,5 6 ,7 0 , 1 3 1 ,1 3 3 ,1 4 1 ,1 5 3 ESTABLISHED *, stan 3 9 - 4 0 ,4 7 ,1 4 8 Expires 175
F
f 291 f_count 2 8 4 -2 8 5 ,2 9 0 ,2 9 2 ,2 9 4 -2 9 7 ,2 9 9 ,3 0 1 -3 0 2 f_data 265 f_flag 299 f_m sgcount 2 8 4 -2 8 5 ,2 9 0 -2 9 2 ,2 9 4 -2 9 5 ,2 9 7 , 299, 301 f_ops 265 f_type 299 falloc 265 faszyw y n u m er i-node 2 4 2 -2 4 3 ,2 7 5 FA Q 225 fd 265 fdalloc 291 fdavail 291 FD E FE R 2 9 6 ,2 9 9 ,3 0 3 Fielding R .T . 323-324 file 258, 261, 2 6 5 ,2 7 4 ,2 7 7 , 2 8 4 -2 8 6 ,2 8 8 -2 9 7 , 299, 301-304 file deskryptoram i 288 FIN _W A IT_1 3 8 - 3 9 ,4 7 ,5 2 ,1 4 7 ,1 5 3 ,2 1 2 F IN _W A IT _l 3 9 ,1 4 7 -1 4 8 FIN _W A IT _2 38-39, 4 7 ,5 2 ,1 5 6 , 212 findpcb 1 3 7 -1 3 8 ,1 5 1 Floyd S. 26, 324 FM A RK 2 9 6 -2 9 7 ,2 9 9 ,3 0 1 , 303 fo_close 292 F O LL O W 2 5 3 ,2 5 6 for 289 fork 11, 284 found 89-91 fp 289, 301, 303 fp l2 6 5 FR EA D 265 FreeBSD 2 7 - 2 8 ,8 2 ,1 0 2 ,1 6 7 F rom 1 7 5 -1 7 6 ,2 7 7 fstat 274-275 FTP 5, 9, 23, 26, 28, 59, 69, 218, 223-224 ftp ://ftp .isi.ed u /p u b /b rad en /T T C P .tar.Z 26 f t p :/ / ftp .m e rit.e d u /statistics 169 f tp ://g r e g o r io .stan fo rd .ed u /v m tp -ip 26 FW RITE 265
E
E A D D R IN U SE 6 9 ,9 8 ,2 5 4 E C O N N A BO R T ED 273 E C O N N R E F U S E D 145 E C O N N R ESET 2 5 1 ,2 7 3 ED EST A D D RREQ 78 EIN V A L 257 EISCO N N 277 else 9 1 ,1 4 3 ,1 4 7 EMSGSIZE 2 5 7 ,2 9 1 E N O BU FS 2 7 8 -2 7 9 ,2 9 4 EN O PRO TO O PT 321 EN O T C O N N 7 8 ,2 7 7 , 319 E PIPE 280 err_sys 2 errno 3 error 294
332
Indeks
G
g atew ay 214 G ET 1 7 3 ,1 7 7 ,1 8 4 G ET ). 175 G ET / 1 7 2 -1 7 3 ,1 7 8 G ET A L L 184 geth ostb yn am e 3 G E T L IS T 184 getp eern am e 2 5 8 ,2 7 5 getservbynam e 3 getsock nam e 275 gif 176 G op h er 323 g o p h e r:/ 186 g o to 137 G randi S. XVII grou p 2 2 5 ,2 2 8 -2 2 9
H
H averlock P. M. XVI head 2 2 6 ,2 2 8 ,2 3 0 H e ig h a m C . XVI help 224 H in den R. 2 5 ,3 2 6 -3 2 7 historia p rotokow transakcyjnych 24 H o g u e J. E. XVII H orton M. 2 2 1 ,3 2 4 H P -U X 15 H TTP 9, XII-XIV, 2 3 ,1 6 9 ,2 2 3 http://tow n.hall .o rg /A rch iv e s//p u b /IT A / 188 h ttp ://w w w .a w .c o m 178 h ttp ://w w w .c d ro m .c o m . 28 h ttp ://w w w .c u p .h p .c o m /n e tp e rf /N e tp e r f P age.h tm l 22 h ttp ://w w w .fre e b s d .o rg 27 h ttp ://w w w .n csa.u iu c .edu / SDG / Software /M o saic / M etalndex.html 173 h ttp ://w w w .n c s a .u iu c .e d u 173 h ttp ://w w w .s g m lo p e n .o rg 172 h ttp d 1 8 7 ,1 9 0 ,2 0 0
ifaddr 98 im age 176 in_ 82 in _add route 8 5 ,9 2 , 94 in_clsroute 8 3 ,8 7 ,9 1 - 9 4 in_inithead 8 4 ,8 8 ,9 4 in_localad d r 5 0 ,1 2 2 ,1 2 6 ,1 2 8 ,1 4 1 in _m atroute 8 6 ,9 3 -9 4 in_pcbbind 9 8 ,1 6 1 in_pcbconnect 95-98 in_pcbladdr 9 5 -9 8 ,1 6 1 in_pcblookup 9 8 ,1 6 1 in_rm xp 102 in_rtqkill 88-93 in_rtqtim o 85, 88-90, 92-93, 212 IN A D D R _A N Y 5 inetdom ain 84 inform acja o p ocztk o w ym ro zm iarze okna 204 inform acje w tk ow e 222 IN N 2 2 1 ,2 2 6 IN N D 2 2 3 -2 2 4 ,2 3 5 ino_t 242 inode 253 inp_route 114 inpcb 215 int 8 2 ,2 4 2 ioctl 248 ip_sysctl 8 3 ,1 0 1 IPC XIII, 233-234 IRIX 15 irs 1 4 0 ,1 4 5 IRTP 24 IS N 4 5 ISS 7 4 ,1 4 0 ,1 6 2
J
Jacobson V. 3 2 ,1 1 8 ,3 2 4 jednoczesne otw arcie 3 7 ,1 4 7 -1 4 8 ,1 5 2 jednoczesne serw ery H TTP 190 jednoczesne zam knicie 3 7 ,4 0 jednolity identyfikator zasob w 173 jednolity lokalizator zasob w 173 jzyk form atow ania tekstu 172 jzyk hipertekstowego znakowania informaqi 170 jzyk zn akow ania inform acji 172 Johnson D. 323
I
IC M P 100 icm p _sysctl 101 idle 5 3 ,1 0 7 -1 0 8 IE E E 326 if 7 9 ,1 3 9 ,1 4 3 ,1 4 7 ,1 6 3 ,2 0 9 ,2 5 7 , 296 If-M odified-Since 1 7 5 ,1 7 7
Indeks
333
K
K acker D. XVI K an tor B. 2 2 1 ,3 2 5 Karels M. J. XVII karetka 9, 223 k e m /u ip c_ p ro to .c 241 k e m /u ip c_ u srre q .c 241 k em ?uip c_syscalls.c 241 K ernighan B. W . XVI killed 89-91 klaster m buf 5 3 ,7 9 ,1 2 7 ,2 1 5 ,2 5 7 ,3 0 3 ,3 1 1 , 313 K leim an S. R. 253 klient N N TP 227 k lient-serw er T /T C P 16 k lient-serw er TCP 7 klient-serw er U D P 1 , 3 ,5 klonow anie m arszru ty 81 kod r d o w y T /T C P 28 kod r d o w y, konw encja 2 kody od p ow ied zi N N TP 224 kolejka k om pletnych pocze 198-1 9 9 ,2 0 1 kolejka niekom pletnych pocze 198-199,
Location 1 7 5 ,1 7 8 L O C K LE A F 256 LO C K PA R EN T 253 log 90 L O O K U P 256 lpd 235 Ipr 235
M
m 2 7 8 , 281 mO 293 m _cop y 2 5 5 ,2 5 8 , 275 M _FILE 301 m _free 2 5 2 ,2 7 3 m j r e e m 252, 273, 280-281 m _getclr 249 m _typ e 245 M _W A ITO K 301 m ain 320, 322 M A LLO C 246, 301-302 m ax_sn d w n d 108 m buf 2 4 6 ,2 5 8 ,2 8 6 M cCahill M. 323 M cC anne S. 324 M cG rath R. E. 325 M cK enney P. E. 217, 325 M cKusick M. K. 297 M CLBYTES 127 M ellor A . XVI m em set 3 M FR EE 294 M iller T. 24, 325 M IM E-V ersion 175 M IN C LSIZE 215, 311 M L E N 254 M ogul J. C. XVI, 2 3 ,5 6 ,1 9 0 ,2 0 2 ,2 0 4 ,2 0 6 , 212, 219, 325 m sg_accrigh ts 286 m sg_accrigh tslen 286 m sg_con trol 286 m sg_controllen 286, 289 M SG _CTRU N C 291 M SG _EO F 17, 46-47, 52, 7 7 -7 9 ,1 0 0 ,1 4 1 ,1 5 3 , 1 6 2 ,1 6 4 -1 6 5 ,1 6 7 , 319, 322 M SG _EO R 17 m sg_flags 291 MSG_OOB 79 m sgh d r 286, 289 MSL 13, 3 6 ,4 7 ,5 9 -6 2 , 64-71, 75-76, 9 5 ,9 9 , 1 0 2 ,1 5 0 ,1 5 5 -1 5 7 ,1 6 1 ,1 6 7 , 319 MSS 1 2 1 ,1 2 5 -1 2 7 ,1 3 1 , 204 M T_CO N TRO L 2 8 6 ,2 9 0 ,2 9 3 - 2 9 4 ,2 9 7
201
kom batybilno w stecz T /T C P 43 kom unikat ICM P 2 7 9 ,3 0 6 konw encje typograficzne XVI korpus H TM L 172
L
L am J. 326 Lap sley P. 221, 325 laptop 2 0 -2 1 ,2 8 , 43, 308 LA ST_A C K , stan 4 6 ,1 4 9 -1 5 1 ,1 5 7 , 2 1 2 ,2 1 9 LA ST_A CK *, stan 3 9 ,4 7 last_ad ju sted _tim eout 90 Last-M odified 1 7 5 ,1 7 7 Leffler S. J. 294, 325 len 108, 112 licznik od w oa 284 licznik od w oa do tablicy ru tow an ia 83, 87, 91 licznik p oczenia 3 2 -3 3 ,4 0 , 67, 72, 99-100 Lindner P. 323 link hipertekstu 170 list 2 2 5 ,2 2 7 , 229-230 lista H TM L 173 listen 1 0 ,1 7 , 198-199, 201, 234, 255, 258 LISTEN , stan 38, 40, 5 6 ,1 3 7 ,1 4 0 ,1 4 3 ,1 4 9 , 1 5 1 ,1 5 5 ,1 5 7 ,1 6 4 Liu C. -G. 324
334
Indeks
M T_PC B 249 M T_SO N A M E 245 M TU 5 ,1 0 1 ,1 2 2 - 1 2 3 ,1 2 6 ,1 3 3 ,2 0 4 , 3 1 0 ,3 2 5 M TU cieki 5 6 ,1 2 2 ,2 0 6 M ueller M. XVI
0
offer 1 2 4 ,1 2 9 okn 154 okno przecienia 1 2 8 ,1 3 7 ,2 1 8 oksym oron 25 O lah A. XVIII, 2 7 ,6 7 ,1 6 3 ,3 2 5 oldfds 289 op 293 opcja C C 3 2 -3 3 ,1 0 9 opcja C C echo 32-33 opcja C C new 32-33 opcja MSS 3 3 ,1 0 9 ,1 2 1 opcja skali okna 3 3 ,2 0 6 ,3 2 4 opcja znacznika czasu 3 3 ,1 0 9 ,2 0 6 ,3 2 4 opcje SYN 2 0 3 ,2 0 5 opcje T /T C P 32-33 open 285 opnienie u szeregow an ia 3 1 5 ,3 1 7 opnione potw ierdzenie 5 2 ,5 5 ,1 2 0 ,1 4 1 ,1 4 7 , 1 5 5 ,1 9 6 ,2 1 7 origoffer 126 OSI 1 7 ,7 9 ,2 8 7 ,3 0 3
N
n agw ek H TM L 172 n am 1 6 0 ,1 6 4 ,2 5 3 , 2 5 6 ,2 6 9 ,2 7 5 ,2 7 7 n am ei 2 5 3 -2 5 5 ,2 5 7 ,2 7 6 n am eid ata 253, 256 N C SA 1 8 7 ,1 9 0 -1 9 1 ,3 2 4 n d.ni_cn d 255 n d .ni_d vp 254-255 n d.ni_vp 2 5 4 ,2 5 7 n d.vi_vp 255 n dd 201 ND INIT 2 5 3 ,2 5 6 net.inet.ip 83 net.in et.tcp 1 0 0 ,1 6 6 N e t / l 1 2 7 ,1 2 9 ,1 5 0 N e t /2 1 2 9 ,1 6 7 , 301-302 N e t /3 2 8 ,5 0 ,5 2 ,6 0 - 6 1 ,7 5 ,7 7 , 79-81, 83-85, 9 5 ,1 0 0 ,1 0 8 -1 0 9 ,1 1 3 ,1 1 6 -1 1 8 ,1 2 0 -1 2 2 ,1 2 7 , 1 2 9 - 1 3 0 ,1 3 3 ,1 3 7 ,1 4 4 ,1 6 5 ,1 9 0 ,2 0 0 , 2 0 2 - 2 0 3 ,2 0 8 ,2 1 3 ,2 1 5 ,2 1 7 ,2 3 9 ,2 4 2 ,3 0 2 NetBSD 28 n e tin e t/in _ rm x .c 82 N etp erf 22 n etstat 1 0 0 ,1 8 7 ,1 9 9 ,2 0 2 new fd s 291 n ew sg rou p s 227 nextstop 8 9 -9 0 ,9 2 nfiles 301 N FS 24, 81, 85, 253 niejaw ne o tw arcie p oczenia 122 niejaw ne w ypchnicie 107 N ielsen 323 n iezaw od n o 18 N N R P 223-224 N N T P 9, XV -XVI, 221 nntpin 235 N O A O X IX -X X n oao.ed u 3 0 7 -3 0 8 ,3 1 5 ,3 1 7 N O D EV 275 N O P 3 2 ,4 5 ,1 2 7 ,1 2 9 -1 3 0 n u m ery p ort w klienta T /T C P 5 9 ,6 1 n u m ery p ort w klienta HTTP 203 n un ref 301
P
p 253, 2 5 6 ,2 6 5 Padm anab han V. N. 325 pam i p od rczn a m arszru ty 114-115 p am i pod rczna PCB 2 1 5 ,2 1 7 p am i p od rczn a p er-h ost 35 pam i TA O 3 5 ,4 1 ,4 4 ,4 6 ,5 5 ,9 3 ,1 0 5 - 1 0 6 , 1 1 3 ,1 2 4 ,1 2 9 ,1 4 1 ,1 4 6 - 1 4 8 ,1 5 3 ,1 6 3 panie 280 para gniazd 4 7 ,6 1 ,6 9 , 95, 98 Partrid ge C. XVI-XVII, 7 ,2 5 ,3 2 5 - 3 2 6 pasyw ne otw arcie 1 4 0 -1 4 1 ,1 4 3 ,1 5 2 PA W S 4 3 ,1 5 1 ,3 2 4 Paxson V. 6, XVII, 2 3 ,1 1 7 ,1 8 8 ,2 2 1 , 326 PCB 95, 9 8 ,1 1 4 -1 1 5 , 133 P eterson 6 1 ,3 2 4 P F_L O C A L 2 34 P F_R O U TE 244 P F_U N IX 238 pip 2 3 4 ,2 4 1 ,2 6 1 ,2 6 7 -2 6 9 , 276 pola nagw ka N N T P 221, 225 pole nagw ka H TM L 174 p oow iczn a synchronizacja 3 9 -4 0 ,1 0 2 ,1 0 8 , 1 4 1 ,1 5 2 ,1 5 4 -1 5 5 p oow iczn e 8 p oow iczn e zam knicie 1 3 ,4 7 ,5 2 p om iar czasu , klient serw er 20-21 p om iar RTT 1 9 6 -1 9 7 ,3 0 6 -3 0 7
Indeks
335
p om iary czasu w stosie protokou 308-309, 311, 313 POSIX 234 POST 174 POST ). 175 P o stelJ. B. 2 5 ,3 2 ,3 8 ,5 6 , 326 p ow oln y start 5 0 -5 1 ,1 2 8 -1 2 9 ,1 4 1 ,1 5 4 ,2 1 5 , 218, 324 P PP 1 1 8 ,1 9 6 , 2 0 8 ,2 2 9 -2 3 0 P R _A D D R 244 PR_A TO M IC 244 P R _C O N N R EQ U IR ED 1 0 0 ,2 4 4 pr_flags 7 8 ,1 0 0 P R _IM P LO P C L 7 7 -7 9 ,1 0 0 PR_RIG H TS 2 4 4 ,2 9 2 ,2 9 7 pr_sysctl 1 0 0 ,1 6 6 PR _W A N TR C V D 1 0 0 ,2 4 4 ,2 8 1 P ragm a 175 P ragm a: 184 P ragm a: hold-connection 184 p raw a autorskie XV p raw a d ostpu 2 4 4 ,2 8 3 p resent 133 p rd ko w iata 2 2 ,3 1 4 p ro c 2 5 3 ,2 5 6 P ro g ram h ost 191 p ro g ram obsugi ptli zw rotnej 2 3 3 ,2 3 6 ,3 0 3 , 305, 308-310 p ro g ram T racerou te 3 1 4 -3 1 5 ,3 1 7 protokoy d om en y unixowej 233 protokoy d om en y unixow ej, im plem entaq'a 241 proto k o y d om en y unixowej, przykady p ro g ram w 237 p rotok H TTP 23 proto k przesyania hipertekstu 169 p ro to sw 1 0 0 ,1 6 6 ,2 4 2 -2 4 4 protosw (| 241 p ro x y 214 P R U .A B O R T 273 P R U _A C C E P T 2 6 9 -2 7 0 ,2 7 5 P R U _A T T A C H 1 1 3 ,2 4 9 ,2 5 8 ,2 6 9 P R LLB IN D 252-253 PR U _C O N N E C T 9 5 ,1 5 9 -1 6 1 ,2 5 5 ,2 5 7 ,2 5 9 PR U _C O N N E C T 2 2 6 0 -2 6 1 ,2 6 3 ,2 6 6 ,2 6 8 P R U _C O N T R O L 248 PR U _D E T A C H 250-251 PR U _D ISC O N N EC T 2 5 0 ,2 6 9 ,2 7 1 PR U _LISTEN 255 PR U _P E E R A D D R 275 P R U _R C V D 2 7 7 ,2 7 9 ,2 8 1 -2 8 2 , 304 P R U R C Y O O B 275
PR U _SEN D 7 9 ,9 5 ,1 0 0 ,1 2 2 -1 2 4 ,1 5 9 ,1 6 3 -1 6 4 , 2 4 8 ,2 5 6 ,2 7 4 ,2 7 7 -2 7 9 ,2 8 1 ,2 8 6 ,2 8 8 ,3 0 3 -3 0 4 PR U _SEN D _EO F 53, 7 7 ,7 9 , 9 5 ,1 0 0 ,1 2 2 -1 2 4 , 1 2 9 ,1 5 9 ,1 6 3 -1 6 5 ,1 6 7 PRU _SEN D O O B 7 9 ,2 7 5 PR U _SEN SE 274-275 P R U _SH U TD O W N 1 6 5 ,2 7 2 PRU _SLO W TIM O 276 PRU _SO CK A D D R 275 PR U _X X X 159, 274 przek azyw an ie d esk ryptorw 2 8 2 -2 8 3 ,2 8 5 , 287 p rzestrze n azw 245 przesyanie gru p ow e 26-27, 8 6 ,9 4 przew id yw an ie nagw ka 2 7 ,1 3 7 -1 3 9 , 2 1 5 -2 1 7 ,2 1 9 p rzyszo T /T C P 166
Q
qfds 293 Q u arterm an 325 quit 226
R
rad ix-32 226 rad ix_n od e_h ead 8 3 ,8 5 , 87, 93-94 R aggett D. 326 R ago S. A. 2 3 6 ,2 7 9 , 326 ra w _ 244 rcv-sb _cc 281-282 rcv _ad v 1 4 2 -1 4 3 ,1 4 7 rcv_w n d 142 RD P XIX, 2 5 -2 6 ,3 2 5 -3 2 6 read 9 ,1 7 ,2 1 ,2 3 4 read _stream 9 , 1 1 ,1 7 ,2 1 , 320 recvfrom 3, 5, 7 ,1 7 ,2 0 -2 1 , 305 recvit 2 8 8 ,2 9 1 recvm sg 2 8 4 -2 8 6 ,2 9 1 ,2 9 4 Reed D. A . 325 Referer 175 release 294 R EP LY 3 REQ U EST 3 resid 79 retransm isja SYN 2 06-207 retu rn 133 retv al 2 6 5 ,2 6 7 ,2 6 9 RFC 1009 323 RFC 1036 2 2 1 ,3 2 4 RFC 1045 2 5 -2 6 ,3 2 4
336
Indeks
RFC 1122 13, 3 8 ,2 0 7 , 2 0 9 ,3 2 3 R FC 1151 2 5 ,3 2 6 RFC 1185 1 5 ,6 2 ,6 4 ,3 2 4 RFC 1191 5 6 ,2 0 4 ,2 0 6 ,3 2 5 RFC 1323 3 2 - 3 4 ,4 0 ,4 3 ,1 1 0 ,1 1 2 ,1 2 7 , 166-167, 2 0 6 ,3 2 4 RFC 1337 6 5 ,3 2 3 RFC 1379 1 5 ,2 6 ,3 9 ,7 4 ,3 2 3 RFC 1436 323 RFC 1630 323 RFC 1644 2 6 ,3 2 ,7 1 ,7 5 ,1 0 1 ,1 2 0 ,1 2 7 ,1 4 7 ,3 2 4 R FC 1700 326 RFC 1716 323 RFC 1738 323 R FC 1808 324 RFC 1812 6 4 ,3 2 3 RFC 791 5 6 ,3 2 6 R FC 793 3 2 ,3 8 ,5 6 ,6 2 ,6 4 -6 5 ,6 9 ,1 1 0 ,1 2 2 ,3 2 6 R FC 908 25 RFC 938 2 4 ,3 2 5 RFC 955 2 5 -2 6 ,3 2 3 R FC 97 7 221 rm x_exp ire 86-87, 9 1 ,9 3 rm x_filler 115 rm x_m tu 1 2 2 ,1 2 6 ,1 6 4 rm x_recvp ip e 127 rm x_rtt 1 1 7 ,1 2 1 ,1 2 5 rm x_rttv ar 117 rm x_sen d p ip e 127 rm x_ssth resh 129 rm xp _tao 8 4 ,1 1 6 rm x_taop 8 4 ,1 1 6 rn _ 82 rn _ad d rou te 81, 86 rn_delete 81 rn_inithead 84-85 rn _in ith ead :rn h _ad d ad d r 85 rn _m atch 81, 86 rn_w alktree 81, 88-90, 92 rnh 83, 89 rn h _ad d ad d r 85 rnh_close 83, 8 5 ,8 7 , 93 rn h _m atch ad d r 85-86, 93 R o se M . T. 326 route 9 3 ,1 1 4 -1 1 5 ,1 2 2 ,1 2 7 ro u te_o u tp u t 93 rp 289 R PC 24 rsteven s@ n oao .ed u XVII rsv 265 rt 82 rt_flags 83 rt_m etrics 83, 9 3 ,1 1 5 ,1 1 7 ,1 2 2 ,1 6 4 , 213 rt_prflags 83
rt_refcnt 8 3 ,8 6 rtalloc 114 rtallo cl 86, 93 rten try 8 3 -8 4 ,1 0 2 ,1 1 6 R TF_C LO N IN G 83 RTF_H OST 8 7 ,1 1 6 R TF_LLIN FO 87 R T F J J P 116 rtfree 83, 87, 93 RTM _A D D 85 RTM _LLIN FO 93 RTM _RESO LVE 85 R T M .R T T U N IT 121 RTO 63, 6 6 ,1 0 3 ,1 1 6 -1 1 7 ,1 1 9 , 209 RTPRF_O U RS 8 3 ,8 6 -8 7 ,9 1 R TPR F_W A SC LO N ED 83, 87 rtq_m inreallyold 8 2 ,8 9 -9 0 rtq_reallyold 8 2 ,8 7 ,8 9 -9 2 rtq _tim eout 82, 88-89, 92 rtq _toom an y 8 2 ,8 9 rtq k _arg 88-91 rtrequ est 83, 85, 87, 9 1 ,1 0 2 RTT 6 -7 ,1 1 ,1 7 -1 8 , 22, 31, 62-64, 6 7 ,1 2 5 , 1 9 6 -1 9 9 ,2 1 5 ,2 1 8 -2 1 9 ,3 0 5 -3 1 1 ,3 1 4 -3 1 5 RTV_BIT 125 R T V _R T T 121 RTV_RTTVAR 121
s
SA 3 Salus P. H. 221, 326 Sax J. 25, 327 sb_cc 280-281 sb_hiw at 280-282 sb_m ax 127 sb_m bcnt 280 sb_m bm ax 280-282 sbappend 163, 280 sbap pen d add r 2 7 8 ,2 9 4 sbappendcontrol 280, 294 sbappendcontrol 288 sbreserve 127 Schm idt D. C. XVII SCM _RIGHTS 2 8 4 ,2 8 9 ,2 9 3 se le ct2 3 4 send 1 7 ,7 7 , 7 9 ,3 1 9 ,3 2 2 send_request 320-321 sendalot 112 sendit 286 sendm sg 77-79, 9 5 ,1 5 9 -1 6 0 ,1 6 2 ,1 6 4 ,1 6 7 , 248, 277, 280, 284-286, 289, 319
Indeks
337
send to 3 , 5 ,1 7 ,2 0 - 2 1 ,2 9 ,4 4 ,4 6 , 5 2 ,5 4 , 61, 77-79, 95, 9 8 ,1 0 0 ,1 2 4 ,1 4 1 ,1 5 9 - 1 6 0 ,1 6 2 , 1 6 4 - 1 6 5 ,1 6 7 ,2 4 5 ,2 5 6 ,2 7 6 ,2 7 8 ,3 0 5 , 31 2 -3 1 3 ,3 1 9 -3 2 1 SEQ _xx 100 Server 175 serw er iteracyjny 11 serw er p ored n iczcy (proxy) 214 serw er p ro xy 182 serw er w stp n ie rozgazion y 11 sesja HTTP 182 setsock op t 321 SGM L 172 Shim om ura T. 4 5 ,3 2 6 shu td o w n 8 ,1 7 , 29, 7 7 ,1 4 1 , 272, 319, 322 sie testow a 19 Skibo T. 1 1 0 ,1 6 7 sklonow ana m arszru ta 8 3 ,8 6 Sklow er K. XV skrcenie czasu T IM E_W A IT 6 5 ,6 7 sleep 5 SLIP 1 9 6 ,2 0 8 ,2 3 0 SMTP 9 ,1 5 , 69, 223 snd _cw n d 5 0 -5 1 ,1 2 8 sn d _m ax 108 s n d _ n x t108 snd -sb _h iw at 281 snd _ssth resh 129 snd _un a 1 4 7 ,1 5 4 snd _w nd 50-51 so 2 5 7 ,2 6 1 ,2 6 4 so 2 257, 2 6 1 ,2 6 4 , 2 7 7 ,2 8 0 ,2 8 2 so 2 = so3 258 S O _A C C EPT C O N N 258 so_error 273 so_h ead 2 5 8 ,2 6 4 ,2 7 3 SO _K EEPA LIV E 212 so pcb 249 so_q 2 5 8 ,2 6 4 , 297 so_q0 2 5 8 ,2 6 4 so_q01en 199 so_qlen 1 9 9 ,2 5 8 SO _REU SEA D D R 60-61 so_state 264 soaccep t 269 so can trcvm ore 272 socan tsen d m o re 1 6 5 ,2 7 2 sock 229 SO CK_D G RA M 2 3 4 ,2 6 4 SO CK _RD M 25 SO C K _SEQ PA C K ET 25 SO CK _STREA M 2 5 ,2 3 4 SO CK _TRA N SA C T 26 sock ad d r 275
sockaddr_in 9 6 ,1 1 4 sockad dr_un 237, 2 3 9 ,2 4 1 ,2 4 4 ,2 4 6 ,2 5 4 ,2 5 8 , 2 6 9 ,2 7 5 ,2 7 7 sockargs 2 5 4 ,2 5 7 ,2 8 6 , 288 socket 2 , 5 , 8 , 1 7 , 5 2 ,2 3 8 ,2 4 6 ,2 4 9 ,2 5 1 ,2 5 5 , 2 5 8 ,2 6 0 -2 6 1 ,2 6 5 ,2 6 9 ,2 7 2 -2 7 3 ,2 7 7 ,2 8 0 , 282, 297 socketpair 2 4 1 ,2 6 0 -2 6 1 ,2 6 4 -2 6 8 ,2 7 6 sockfd 11 soclose 273 soconnect2 2 6 1 ,2 6 6 ,2 6 8 -2 6 9 socreate 2 6 5 ,2 6 9 sofree 273 soisconnected 1 4 3 ,2 6 4 soisconnecting 162 soisdisconnected 2 5 1 ,2 7 1 SO L_SOCKET 2 8 9 ,2 9 3 Solaris 1 5 ,5 5 -5 7 ,5 9 ,2 0 1 ,2 0 3 , 236, 305 solisten 258 S O M A X C O N N 1 0 ,1 9 8 ,2 0 1 son dow anie trw aoci poczenia 208-209,
211
sonew conn 1 9 8 ,2 4 9 ,2 5 8 ,2 6 9 soqinsque 258 soreceive 2 8 1 ,2 8 6 ,2 9 0 ,2 9 4 ,3 0 3 soreserve 249 sorflush 2 5 2 ,2 9 2 ,2 9 4 ,2 9 6 ,3 0 1 sorw akeup 2 7 8 ,2 8 1 sosend 5 3 ,7 7 -7 9 ,1 0 0 ,1 6 4 ,2 1 4 -2 1 5 ,2 8 0 -2 8 1 , 303, 322 sou n-sun _p ath 2 5 3 ,2 5 6 Spero S. E. 326 splnet 79 splx 79 SPT 6 - 7 ,1 1 , 1 5 ,1 7 ,2 2 ,5 7 SRC 172 SS.C A N T SEN D M O R E 165 S S JS C O N F IR M IN G 79 S S JS C O N N E C T E D 2 6 4 SS_N O FD R EF 258 st_blksize 274 st_d ev 275 st_ino 275 stan d ard ow y u oglniony jzyk zn akow ania inform acji 172 stany rozszerzon e 38-39 stare duplikaty 6 5 ,6 8 ,7 0 stat 274-275 Stein L. D. 326 step6 1 4 9 ,1 5 2 ,2 1 8 Stevens W . R. 2 ,7 ,1 1 , XIII-XIV, XV I, XVII, 2 4 ,9 0 ,2 3 5 ,2 4 5 ,2 8 2 , 327 Stevens, D A . XVI Stevens, E.M . XVI
338
Indeks
strn cp y 238-239 strona w yw o aw cza 172 stru ct d om ain 242 stru ct p roto sw 242 stru ct sockad dr 242 stru ct sock ad d r * 3 subnetsarelocal 50 sum a kontrolna 1 3 7 ,2 3 4 ,3 1 1 sun XVIII, 180, 306 sun _non am e 2 4 2 ,2 6 9 ,2 7 5 ,2 7 7 sun _path 244 SunOS 1 5 ,2 6 ,2 8 ,1 6 7 ,2 3 6 SVR4 2 8 ,5 4 -5 5 ,5 7 ,2 3 6 , 269, 2 7 9 ,2 8 2 ,3 2 0 sw itch 149 SYN , czas otrzym yw an ia 1 9 1 ,1 9 3 ,1 9 5 SYN _RCV D 3 6 ,3 9 ,1 0 8 ,1 4 8 ,1 5 2 - 1 5 3 ,1 6 6 , 168, 202 SYN _RCV D * 3 9 ,1 0 8 ,1 5 3 S YN _SEN T 3 6 ,3 8 -3 9 ,5 3 ,1 0 5 -1 0 6 ,1 0 8 ,1 4 4 , 1 4 6 ,1 4 8 -1 4 9 ,1 5 7 ,1 6 2 ,1 6 5 -1 6 6 ,1 6 8 SYN _SEN T* 3 8 - 4 0 ,4 5 ,4 7 ,5 3 ,1 0 8 ,1 1 0 , 1 4 7 -1 4 8 ,1 6 2 ,1 6 5 s y s /u n .h 241 s y s /u n p cb .h 241 sysctl 82, 8 7 ,1 0 0 -1 0 1 ,1 6 6 syslog 2 3 5 ,2 7 8 syslogd 9 0 ,2 3 5 ,2 7 8 system plikw 254 szerok o p asm a 314-315 szkic in tern etow y 170 szybka retransm isja 2 7 ,1 5 3 szybkie od tw orzenie poczenia 2 7 ,1 5 3
s
r
w iatow a p ajczyna 169
T
t 229 t_duration 3 5 ,1 0 1 -1 0 3 t_flags 101 t_idle 211 t_m axo p d 1 0 1 ,1 1 2 ,1 1 4 ,1 2 3 -1 2 4 ,1 2 6 , 1 2 8 -1 2 9 ,1 3 1 ,1 6 4 t_m axseg 1 0 1 ,1 1 4 ,1 2 3 -1 2 4 ,1 2 7 -1 2 9 ,1 3 1 ,1 6 4 t_rttm in 125 t_rttv ar 1 2 1 ,1 2 5 t_rxtcu r 125 t_srtt 1 2 1 ,1 2 5 t_state 1 3 8 ,1 4 7 tablica ru tow an ia T /T C P 81 tablica ru tow an ia T /T C P , sym ulacja 212
TA O 1 8 ,3 2 ,6 9 ,7 1 tao_cc 35, 73, 8 1 ,8 3 ,9 3 ,1 0 2 ,1 0 5 ,1 3 1 ,1 4 1 , 1 4 8 ,1 5 3 tao_ccsen t 35, 4 4 ,4 6 ,5 5 ,7 3 ,8 1 , 83, 9 3 ,1 0 7 , 1 4 5 ,1 6 3 tao_m ssop t 3 5 ,4 9 , 8 1 ,8 3 , 9 3 ,1 2 9 ,1 6 4 tao_n on cach ed 105-106 taop 1 0 5 ,1 2 4 T aylor J. L. XVII, 315 tcp_backoff 209 tcp _cc 84, 9 9 ,1 0 1 tcp _ccg en 3 5 ,4 4 ,4 6 ,4 8 ,6 7 ,6 9 - 7 1 ,7 3 - 7 6 , 9 9 -1 0 0 ,1 0 2 -1 0 3 ,1 4 1 ,1 6 3 tcp_close 1 1 3 ,1 1 7 ,1 2 0 - 1 2 1 ,1 3 3 ,1 6 1 tcp_con nect 9 5 ,1 5 9 -1 6 2 ,1 6 4 -1 6 5 ,1 6 7 tcp _con n _req _m ax 201 tcp_ctlou tpu t 159 tcp_d iscon n ect 165 tcp_dooptions 1 1 3 ,1 2 7 ,1 2 9 -1 3 3 ,1 3 5 , 1 3 7 -1 4 0 ,1 6 4 tcp _d o _rfcl323 100 tcp _d o _rfcl644 9 9 -1 0 0 ,1 0 3 ,1 0 9 ,1 1 4 ,1 3 1 tcp_d rop 211 tcp _g ettao cach e 1 1 3 ,1 1 5 -1 1 6 ,1 3 3 ,1 4 0 tcp_init 102 tc p j n p u t 1 1 3 ,1 2 1 ,1 2 3 ,1 2 9 -1 3 1 ,1 3 5 ,1 3 7 -1 4 4 , 146-157, 218 tcp_iss 162 TCP_ISSIN CR 7 4 ,1 6 2 tcp_last_inpcb 215 tcp_m axpersistidle 2 0 9 ,2 1 1 TC P_M A XRXTSH IFT 2 0 3 ,2 0 9 tc p .m s s 1 0 8 -1 0 9 ,1 1 3 -1 1 4 ,1 2 1 ,1 2 3 ,1 3 3 tcp_m ssdflt 1 1 4 ,1 2 2 ,1 2 4 ,1 2 6 tcp_m ssrcvd 1 0 1 ,1 0 9 ,1 1 3 ,1 1 7 ,1 2 1 ,1 2 3 -1 2 9 , 1 3 1 ,1 3 3 ,1 6 4 tcp_m sssen d 1 0 9 ,1 1 3 ,1 2 1 -1 2 2 ,1 3 3 tcp_new tcpcb 1 0 9 ,1 1 3 ,1 1 7 ,1 3 1 T C P_N O O PT 1 1 0 ,1 5 9 TC P_N O PU SH 5 2 -5 4 ,1 0 7 -1 0 8 ,1 5 9 ,3 2 1 tcp_outflags 105 tc p .o u tp u t 5 3 -5 4 ,1 0 5 -1 1 4 ,1 2 1 -1 2 2 ,1 4 2 -1 4 3 , 1 4 7 ,1 5 9 ,1 6 3 ,1 6 5 tcp_rcvseqinit 1 4 0 ,1 4 2 ,1 4 5 TCP_REA SS 5 2 ,1 3 1 ,1 3 3 ,1 5 3 tcp_rtlookup 1 1 3 -1 1 6 ,1 2 2 ,1 2 4 ,1 3 3 tcp_sendseqinit 1 4 0 ,1 6 2 tcp_slow tim o 9 9 ,1 0 1 -1 0 3 tcp_sysctl 1 0 0 -1 0 1 ,1 5 9 ,1 6 6 tcp_taook 100 tcp_tem p late 161 tcp_totbackoff 209 tcp_u srclosed 5 3 ,1 5 9 ,1 6 2 ,1 6 5 ,1 6 7 | tcp _u srreq 1 1 3 ,1 5 9
Indeks
339
tcpcb 3 6 ,1 0 1 ,1 1 2 ,1 3 8 tcpd um p-redu ce 188 T C P O L E N _C C _A P P A 127 T C P O LEN _T ST A M P _A P PA 126 tcp o p t 1 2 9 -1 3 1 ,1 3 7 tcps_accep ts 188 tcps_bad ccecho 100 tcp s_ccd rop 100 tcp s_conn attem p t 188 tcps_conn ects 143 tcps_im pliedack 100 TCPS_LISTEN 138 tcps_pcbcachem iss 215 tcps_persistdrop 209 tcps_rcvoob yte 132 tcp s_rcvoo p ack 132 T C PS_SYN _SEN T 147 tcps_taofail 100 tcpstat 100, 209 TC PT _K EEP 203 TC PTV _K EEP_ID LE 209 TCPTV _M SL 103 TC PTV _TW TR U N C 1 0 3 ,1 5 5 Telnet 5, XVIII, 2 8 ,5 9 ,2 2 3 , 226 T F_A C K N O W 1 4 3 ,1 4 7 TF_N EED FIN 102 T F_N E ED S Y N 102 T F_N O D EL A Y 107 TF_N O O PT 1 0 9 -1 1 0 ,1 3 1 ,1 3 8 T F_N O PU SH 5 3 ,1 0 2 ,1 0 5 ,1 0 7 ,1 3 8 T F_R C V D _C C 1 1 2 ,1 3 1 ,1 5 1 TF_RCV D _TSTM P 1 0 9 ,1 3 1 T F_R E Q _C C 1 0 9 ,1 1 4 ,1 3 1 ,1 5 1 TF_REQ _TST A M P 126 T F_SE N D C C N EW 1 0 2 ,1 1 1 TF_SEN D FIN 4 0 ,1 0 2 ,1 3 9 ,1 4 7 ,1 6 6 ,1 6 8 TF_SEN D SYN 4 0 ,1 0 2 ,1 3 9 ,1 5 2 ,1 5 4 - 1 5 5 ,1 6 2 T F_SEN TFIN 102 T H _FIN 105 TH _SYN 1 0 5 ,1 0 7 ti_ack 145 tim e.tv_sec 87 TIM E_W A IT 13, XIII, 22, 31, 3 6 ,3 8 -3 9 ,4 7 , 5 9 -6 9 ,7 5 -7 6 , 95, 9 8 -9 9 ,1 0 1 -1 0 3 , 137, 1 4 9 -1 5 0 ,1 5 4 -1 5 7 ,1 6 1 ,1 6 7 , 207, 319 tim eout 90, 92 tiwin 141 to 141 to_cc 1 3 1 ,1 3 7 to_flag 1 3 0 -1 3 1 ,1 3 9 to_tsval 139 T O F _C C N E W 131 TOF_TS 139 tom 1 XIII, 327
tom 2 XIII, 327 T orrey D. 323 tp 109 tpO 138 TP4 79 transakcja 1, XIII trim thenstep 1 3 1 ,1 4 3 ,1 4 9 Troff XVII tryb nasuchu 188 ts_present 139 ts_recent 139 ts_val 139 tt_duration 35 ttcp 235 TT CP_C LIEN T_SN D _W N D 164 TTL 6 4 ,3 2 6 tu c 20 tu c.noap.edu 20 typ ed ef 8 4 ,9 9 tytu H TM L 172
U
u _lon g 101, 242 u _sh ort 101 uap 265 ucl.ac.uk 307 U D P 25 U D P_SERV _PO RT 5 udp _sysctl 101 U ICLSYSSPACE 2 5 3 ,2 5 6 uipc_usrreq 244, 248, 275, 288 uipc_usrreq.c 241 unikanie p rzecienia 181, 324 unikanie w ysyan ia gupich segm en tw 107 uniw ersalne n azw y zasob w 173 unix 235 unixdom ain 242-243 unixsw 2 4 2 -2 4 3 ,2 4 8 unlink 254 unp 252, 2 6 1 ,2 7 1 unp2 261, 271 u np2-unp_refs 271 u n p _ad d r 2 4 6 ,2 5 2 ,2 5 5 ,2 7 5 u np _attach 249-250 unp_bind 245, 252-253 u n p _cc 281 unp_conn 246, 260-262, 271, 275 u np _con nect 245, 255-260, 277 unp _con nect2 2 5 7 ,2 6 0 -2 6 1 , 263, 269 u np_defer 242, 296-297, 299, 303 u np _d etach 2 5 0 -2 5 1 ,2 7 3 , 2 9 2 ,2 9 4 , 296 u np _d iscard 291-293, 296, 301
340
Indeks
u n p _d iscon nect 2 5 1 ,2 6 9 -2 7 1 ,2 7 3 ,2 7 9 u np _d isp ose 292-293, 296, 301 u np _d rop 2 5 1 ,2 7 3 unp _extern alize 2 8 6 ,2 8 8 ,2 9 0 -2 9 1 u np _gc 2 5 2 ,2 9 0 ,2 9 3 -2 9 7 ,2 9 9 -3 0 3 u n p _gcin g 2 4 2 ,2 9 6 , 302 u np _ino 242, 275 u np _intem alize 2 7 7 ,2 8 6 ,2 8 8 -2 9 0 ,2 9 2 u np _m ark 2 9 3 ,2 9 6 -2 9 7 ,2 9 9 ,3 0 2 u np _m b cn t 281 u n p _n extref 2 6 1 -2 6 2 ,2 7 1 unp_refs 2 4 6 ,2 5 1 ,2 6 1 -2 6 2 u np _rights 2 4 2 ,2 5 2 ,2 8 5 ,2 9 0 -2 9 2 ,2 9 4 -2 9 5 ,3 0 1 u np _scan 2 9 2 -2 9 3 ,2 9 7 ,2 9 9 ,3 0 1 -3 0 2 u n p _sh u td o w n 272 unp _sock et 249 u np _vn od e 246, 254-255 u n p _xxx 249 unpcb 2 4 0 ,2 4 5 -2 4 6 ,2 4 9 ,2 5 1 -2 5 2 ,2 5 7 -2 5 8 , 2 6 0 -2 6 1 ,2 7 3 ,2 7 5 -2 7 6 u n p d g_recvsp ace 242 u n p d g_sen d sp ace 242 u n p st_recv sp ace 242 u n p st_sen dspace 242 u n p -u n p _cc 282 unp -u n p _con n -u n p _cc 281 unsigned long 99 up d ate 89 u p d atin g 90-92 U RI 173 U R L 173 U R N 173 U ser-A g en t 1 7 5 ,1 7 7 usr_cIosed 168 utw ente.nl 307 u u.net 308
V O P_U N L O C K 254 v p u t 254 vrele 2 5 1 ,2 5 4 VSOCK 2 5 5 ,2 5 7 vsp rin tf 2
W
W ait J. W . XVII w akeup 5 w cielenie poczenia 47, 6 1 -6 2 ,6 4 -6 7 , 6 9 ,7 5 , 9 5 ,9 8 ,1 5 7 ,1 6 0 ,1 6 7 , 207 w eb g atel 214 W ei L. 2 6 ,1 6 7 w hile 251 W olff R. XVII W olm ann G. 27 W rig h t G. R. XIII, XV, 327 w rite 8 , 1 1 ,1 7 ,2 9 , 7 7 ,1 4 1 ,2 3 4 , 319, 322 W W W 5 ,1 0 ,1 3 , XV , 23, 59, 81, 9 0 ,1 6 7 ,1 8 8 , 1 9 0 ,1 9 6 ,2 0 0 ,2 0 4 ,2 0 6 ,2 0 8 , 212, 2 1 9 ,2 2 2 , 2 2 9 ,3 1 1 ,3 2 3 -3 2 4 W W W -A uth enticate 175 w w w .aw .co m 178 w w w .n csa.u iu c.ed u 173 w w w .n etscap e.com 190 w w w .o rg an ization .co m 190 w w w p ro x y l 214
X
X 235 X W in dow s System XVI X 0 254 xh d r 2 2 8 ,2 3 0 xo v er 230 X X X 79
V
v 254 v-n od e 246 v_sock et 2 4 6 ,2 5 5 ,2 5 7 -2 5 8 v a ttr 255 V A T T R _N U LL 255 Velten D. 25, 327 v m stat -m 301 V M TP 2 5 -2 6 ,3 2 4 v n od e 2 4 6 ,2 5 5 , 257-258, 2 6 1 ,2 7 6 ,2 8 4 ,2 9 9 void * 3 VO P 255 V O P_ 253-254 V O P_C R EA T E 255 V O P_IN A C TIV E 254
Y
Y ee B. S. 301
Z
zasad a od p orn oci 56 zbieranie b ezu y teczn ych d an ych 294-295, 2 9 7 ,2 9 9 , 301 zdoln o adaptacyjna XIII zegar nawizywania poczenia 143,162,202-203 zeg ar p od trzym yw an ia p oczenia 202 Z h an g L. 1 5 ,3 2 4

Biblia TCP IP Tom 3 - Uzupelnienie PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Biblia TCP IP Tom 3 - Uzupelnienie PDF

Uploaded by

Copyright:

Available Formats

-/ja \ \

Biblia TCP/IP, tom III. Uzupenienie

Opracowanie wersji polskiej: Marcin Palacz

Protok T/TCP - kontynuacja

Biblia TC P /IP -tom III

Wartoci CC z zawinitym" bitem znaku Podsumowanie

Implementacja T/TCP: warstwa gniazd

implementacja T/TCP: tablica rutowania

Implementacja T/TCP: bloki kontrolne protokou

implementacja T/TCP: przegld TCP

Implementacja T/TCP: wyjcie TCP

Biblia TC P /IP -tom III

Implementacja T/TCP: funkcje TCP

Implementacja T/TCP: wejcie TCP

Implementacja T/TCP: dania uytkownika TCP

HTTP - protok przesyania hipertekstu

Biblia TCP/IP -to m III

13.5 13.6 13.7

Dane statystyczne HTTP Problemy zwizane z szybkoci i sprawnoci dziaania Podsumowanie

181 183 185

Pakiety znalezione w serwerze HTTP

NNTP - sieciowy protok przesyania informacji

Protokoy domeny unixowej: wprowadzenie

Protokoy domeny unixowej: implementacja

Biblia TCP/IP -to m III

Protokoy domeny unixowej: l/O i przekazywanie deskryptorw

Pomiary czasu w sieci

Dodatek B Bibliografia Indeks

Programowanie aplikacji T/TCP

319 323 329

Biblia TC P /IP -tom III

Biblia T C P /IP -to m III

Prawa autorskie kodu rdowego

Biblia TCP/IP -tom III

r ozdziale 6 z a w i e r a n a s t p u j c e zastrzeenie: I n s titute of T e c h n o l o g y

pocz si z serwerem HTTP wydruk z Telnetu

Biblia TCP/IP -to m III

m e m s e t ( & s e r v , 0, s i z e o f ( s e r v ) ); s e r v .s i n _ f a m i l y = A F _ I N E T : s e r v . s i n _ a d d r . s _ a d d r = i n e t _ a d d r ( a r g v [ l ] ); s e r v . s i n _ p o r t = h t o n s ( U D P _ S E R V _ P O R T ); /* t w o r z y m y d a n i e request[] ... */ 0,

17 if ( s e n d t o t s o c k f d , request, REOUEST. 18 (SA) & s e r v . s i z e o f ( s e r v ) ) != REOUEST) 19 e r r _ s y s ("sendto error"); 20 21 22 23 24 25 1

Utworzenie gniazda UDP

w informacj o bdzie odpowiadajc wartoci e r rn o z odwoania systemowego i koczy proces.

//define R E O U E S T 400 y/de fi ne REPLY 400 //define U D P _ S E R V _ P O R T //define T C P _ S E R V _ P O R T //define T T C P _ S E R V _ P O R T

udpsero.c Rysunek 1 3 Serwer UDP odpowiadajcy klientowi UDP z rysunku 1.1

Utworzenie gniazda UDP i powizanie z lokalnym adresem

Serwer wchodzi w nieskoczon ptl, w ktrej czeka na danie klienta

(r ecvfro m ), przetwarza to danie (co pokazujemy jako komentarz) i wysya odpowied ( s e n d t o ).

if ((soc k f d = s o c k e t ( P F _ I N E T , e r r _ s y s (" s ocket error");

/* p r z e t w a r z a m y "n" b a j t w odpowiedzi e x i t(0);

------------------------------------------------------------------------------------------------Rysunek 1.5 Klient transakcji TCP

------------------------------------------------------------------------------------------------- readstream.c Rysunek 1.6 Funkcja read_stream

tcpserv.c Rysunek 1.7 Serwer transakcji TCP

Akceptacja poczenia i przetworzenie dania

Diagram czasowy dla transakcji klient-serwer TCP

Stan oczekiwania TCP

Zmniejszenie liczby segmentw wysyanych przez TCP

Diagram czasowy dla minimalnej transakcji TCP

<1P address of server>"); S 0 C K _ S T R E A M , 0)) < 0)

/* p r z e t w a r z a m y "n" b a j t w odpowiedzi exi t (0);

------------------------------------------------------------------------------------------------Rysunek 1.10 Klient transakcji T/TCP

Utworzenie gniazda TCP

Wysanie dania do serwera

Odpowied serwera jest odczytana przy pomocy odwoania do funkcji

r e a d _ s t r e a m , takiego samego jak w przypadku klienta TCP.

Sekcja 2.4 Diagram zmiany stanw _______ 37