Порядок приймання UDP-пакета

IP-модуль передає відповідний пакет UDP-модулю, якщо у заголов­ку пакета зазначено код протоколу UDP. UDP-модуль перевіряє конт­рольну суму в заголовку. Якщо вона не збігається, то пакет буде відки­нуто. В іншому випадку відбувається аналіз порту в пакеті. Повідом­лення з Пакета потрапляє в чергу до застосування, яке відповідає пор­ту, Якщо черга переповнена, то UDP-модуль відкидає пакет.

Сфера застосування протоколу UDP

Транспортний протокол UDP використовується там, де важливим є малі накладні витрати та мала і стабільна затримка у передаванні да­них. Наприклад, при передаванні мультимедійних даних.

Протокол TCP

^Протокол TCP - це пакетний протокол транспортного рівня, який забезпечує надійне передавання. З використанням TCP між гостами встановлюється та підтримується протягом всього сеансу зв 'язку двоточкове сполучення. Пакет протоколу TCP на­зивають "сегментом".

TCP використовують там, де потрібне гарантоване передавання повідомлення за призначенням. Для перевірки цілісності пакетів засто­совують контрольні суми, для відстежування процесу передавання -механізм вікон. TCP використовують такі прикладні процеси, як ftp, telnet та ін.

Формат сегмента

У системах, орієнтованих на сполучення, пара комбінацій IP-адрес та номерів портів однозначно задає канал зв'язку між двома комп'юте­рами. Таку комбінацію називають з'єднувачем (socket). Цей механізм уперше запроваджено в системі 4.3. BSD UNIX.

На вхід модуля TCP від протоколу вищого рівня надходить суціль­ний потік байтів. На рівні TCP байти групують у сегменти. Довжину сегмента зазвичай обирають з врахуванням максимальної довжини пакета, допустимої на нижчих рівнях протоколу. TCP оптимізує розмір сегмента, що є змінним. Для контролю за процесом передавання та отри­манням сегментів у тому самому порядку, в якому вони передавалися, кожен сегмент отримує послідовний номер. Отримувач відсилає під­твердження щодо отриманих сегментів. Для контролю за часом, протя­гом якого повинно надійти підтвердження про одержання пакета, при­значено таймер. Якщо за визначений час підтвердження не надійшло, то передавання повторюється. Сегмент має максимальний час наявно­сті (Maximum Segment Lifetime-MSL). 3 перевищенням цього часу його буде знищено.

Першими полями заголовку сегмента є порти відправника та одержувача (транспортний рівень працює з портами, як і UDP) (рис. 12.8).

Ч> Код позиції в повідомленні визначає порядковий номер першого бай­та даних користувача (номер сегмента, що передається).

^> Номер наступного байта у потоці, що приймається (номер сегме­нту підтвердження

Ч> Hlen - довжина заголовка сегмента.

^ Розмір вікна - кількість байтів, які готовий прийняти приймач.

^> Вказівник важливої інформації містить посилання на останній байт повідомлення, що потребує негайного реагування. Це поле має сенс тільки тоді, коли ознака URG -1.

^ Поле опцій - це список полів змінної довжини. Кожна опція запису­ється у форматі вид - довжина - зміст. Деякі опції - масштаб вікна, часова позначка.

^> Поле даних необов 'язкове.

Ч> Значення деяких бітів з поля ознак: URG - ознака важливої інформації; PSH - якнайшвидше передати дані програмі застосування; SYN- ознака синхронізації номерів сегментів (використовують для на­лагодження сполучення); FIN - відправник закінчив надсилання пакетів.

Порядок передавання

Налагодження сполучення між клієнтом та сервером відбувається протягом таких трьох етапів:

•^ клієнт надсилає S YN-сегмент із зазначенням номера порту серве­ра, з яким потрібно налагодити сеанс зв 'язку;

•> сервер відповідає та надсилає свій S YN-сегмент з ідентифікатором (ISN - Initial Sequence Number), який буде використано для нумерації сегментів під час передавання;

-Ь клієнт надсилає підтвердження SYh'-сегмента з номером 1SN+1.

Кожне сполучення має свій ISN. Один з учасників обміну перебуває в пасивному режимі (passive open), інший - в активному (active open). Систему в протоколі TCP описують 11 станів. Частково стан системи можна проконтролювати командою netstat:

netstat -a -n

Proto Local Address Foreign Address State

TCP 192.168.2.30:1025 192.168.2.1:139

ESTABLISHED налагоджене сполучення

TCP 192.168.2.30:1038 198.168.2.22:139 TIME_WAIT чекаємо

роз'єднання

Для реалізації підтверджень у протоколі TCP використано метод змінних вікон.

У якості номера сегмента використовують номер байта у вхідному потоку. У заголовок кожного сегмента включено два номери - номер байта, що передається, та номер байта, що отримано. Номер байта, що отримано використовують для підтвердження отримання. Для нумеру­вання сегментів використовують цілі 32-х розрядні числа. При досяг­ненні максимального значення у 232 - 1, рахунок починають з нуля.

Вікном передавання називають максимальну кількість отриманих, але не підтверджених байтів (фактично - розмір буферу). Якщо кіль­кість переданих, але не підтверджених байтів перевищує розмір вікна, станція - передавач не може передавати нових даних, а тільки чекає на підтвердження вже переданих. Розмір вікна є змінним та передається у кожному сегменті. По мірі отримання підтверджень вікно переміщу­ється (рис. 12.9), подібно до годинникової стрілки.

Одним з важливих системних параметрів, які постійно вимірює TCP, є RTT (Round Trip Time) - час поширення сигналу до одержувача та назад. Цей параметр використовують для налагодження параметрів таймерів.

Сеанс зв'язку закінчується сегментом надсиланням сегментів з озна-* кою FIN обома учасниками сполучення та обміну підтвердженнями в його отриманні.

Протокол TCP відображено у стандартах RFC 793, 1122, 2581. На сьогодні протокол TCP використовують більш як у 95 % всіх переда­вань Internet [http: // en.wikipedia.org].



ТЕМА 13 СЛУЖБА DSN

Адресу хоста мережі Internet, як уже зазначено, можна записати за допомогою цифр, а також і літерами, що надає їй змістовності, поліп­шує запам'ятовування та опрацювання людьми.

У системі DNS реалізовано дві ідеї: ієрархію імен машин та розподі­лення відповідальності щодо дміністрування. Ця система описана у стандартах RFC 882, 883, 1034, 1035, 1101, 1183. Першу версію DNS створено 1983 p., роботи з удосконаленню DNS тривають.

Системи іменування мережевих об'єктів поділяють на пласкі та ієра­рхічні. У пласких системах кожен комп'ютер має текстовий файл (на­приклад, /etc/hosts), у якому символьні імена відповідають цифровим IP-адресам. Ідентичні копії такого файлу повинні бути у всіх гостах локальної мережі. Однак зі збільшенням мереж узгоджувати текстові файли стає дедалі важче.


DNS є ієрархічною системою іменування.ТЕСТИ ДЛЯ САМОКОНТРОЛЮ

1. Який протокол стеку TCP/IP поділяє цілісний потік на частини:

a) Ethernet IEEE 802.3; б) IP; в) ARP; г) TCP.

2. Нечітка (anycast) адреса:

а) вибирає адресата випадково;

б) адресує один гост з групи;

в) вибирає адресата виходячи з низки нечітких критеріїв та пе­
реваг;

г) дає змогу адресувати групу гостів.

3. Засобами якого протоколу реалізується передавання повідомлення
про недоступність адресата:

а)ІСМР; 6) IP; в) ARP; г) IGMP.

13.1, Система іменування гостів

У середині 80-х pp. науковці розробили гнучку ієрархічну доменну систему іменування гостів DNS. Головною структурною одиницею у ній є домен. Домени побудовані у вигляді ієрархічного дерева (рис. 13.1), у вершині якого є кореневий домен. Домени першого рівня

відповідають типам організацій або країнам, наприклад, com - комер



ційні, int - міжнародні, mil- військові, net - мережеві агентства та про­вайдери, de - Німеччина, ш - Україна.

Довільний домен або гост має повне доменне ім'я (Fully Qualified Domain Name (FQDN)). Окремі частини імені відділені крапкою. На­приклад, для госта hostl ім'я буде таке:

hostl .acme.kyiv.ua.

Ознакою повного доменного імені (та наявності кореневого доме-на) є остання крапка.

Адресація за повним доменним ім'ям є абсолютною доменною адре­сацією, Крім абсолютної, використовують і відносну Доменну адреса­цію, Зокрема, якщо звертаються до комп'ютера в Межах одного "стар­шого" домену. Наприклад, myserver може звертатися до host2 за адресою

host2

У відносній доменній адресі немає кінцевої крапки і вона автомати­чно доповнюється до абсолютної адреси додаванням адреси "старшо­го" домену. В деяких реалізаціях протоколу TCP/IP вважають: якщо в адресі більше одної позначки доменів, то це абсолютна адреса.

В іменах доменів не враховано регістру. Домени верхнього рівня -edu, gov, mil, net, org. Імена доменів другого рівня видають спеціалізо­вані організації, вони ж гарантують їхню унікальність. За домени ниж­чих рівнів відповідають їхні адміністратори. Обмеження:

^> імена доменів повинні бути унікальними в межах старшого домену,

^> їхня довжина не перевищує 12 символів;

Ч> не допустиме повторення частини імені домену.

У заявці зазначають відповідального спеціаліста, імена та адреси двох машин, на яких буде зберігатися БД домену.

13.2. DNS як розподілена база даних

DNS-це розподілена база даних, окремі частини якої зберігаються на комп'ютерах - серверах імен. У кожному сервері є інформація тіль­ки про частину загального дерева DNS, а також обов'язково посилан­ня на сервери імен, що зберігають інформацію про суміжні частини цього дерева. Сервер імен, як звичайно, відповідає не за один домен, а за декілька суміжних, або їхні частини - так звану зону відповідальності (zone of authority). Зона - це домен без піддоменів.

Типи серверів імен

Програму, яка відповідає на запити DNS, називають сервером імен, а клієнта-визначником. Сервери імен бувають: > головними, > допомі­жними, )> кешування.

Сервери імен обслуговують зону. В кожній зоні є один головний сер­вер імен. Він зберігає головний варіант БД цього домену. Відповідь головного сервера імен є "авторитетною'''', тобто точною. У кожному домені обов'язково повинен бути хоч би один допоміжний сервер, який періодично копіює свої дані з головного сервера, узгоджує та актуалі­зує свої таблиці. Для узгодження даних використовують так звані зонні пересилання. Сервер кешування тримає адреси деяких серверів DNS вищого рівня у своєму файлі конфігурації. Свою БД цей сервер формує з результатів поточних запитів, зберігаючи їх у кеші.

Головним сервером звичайно роблять надійну, недуже перевантаже­ну машину, приєднану через UPS. Головний та допоміжні сервери часто розміщують у різних доменах і різних мережах електричного живлення з метою зменшити ймовірність їхнього одночасного виходу з ладуУ кожній зоні може бути визначено декілька типів серверів DNS.

•^ Первинний сервер імен (Primary Name Server) є центральним схо­вищем інформації про домен.

•> Вторинний сервер імен (Secondary Name Server) зберігає копію ін­формації з первинного сервера, розвантажуючи його. Копії періодично vзгoджyюmьcя.

•> Сервери для кешування (Cache only server) зберігають кешовану інформацію, щоб зменшити навантаження на сервери.

У кожному домені для гарантування надійності повинно бути при­наймні два сервери (первинний та вторинний).

Інформація, в тому числі й отримана від інших серверів DNS, збері­гається у кеш-пам'яті. Визначено максимальний час зберігання інфор­мації у кеші і, отже періоди оновлення інформації з первинного серве­ра. Всі зміни спочатку відбуваються на первинному сервері. На інших серверах нова інформація буде врахована внаслідок нового зчитуван­ня після її вилучення з кешу.

Залежно від порядку обслуговування запитів клієнтів сервери DNS зувають рекурсивними або нерекурсивними. Нерекурсивний сервер шукає відповідь у своєму кеші, або своїй БД. Якщо відповідь не знайде­но, то відбувається відсилання адреси авторитетного сервера іншого цомену, який повинен знати відповідь.

Під час роботи рекурсивного сервера в його кеші накопичуються ре­зультати проміжних запитів, які можуть бути використані для опрацю­вання наступних запитів. Сервери нижчих рівнів звичайно рекурсивні, а сервери першого і частково другого - нерекурсивні (щоб не перевантажу­вати їх запитами, а їхній кеш - інформацією). Відсилання генеровані за ієрархічним принципом. Наприклад, якщо сервер не знає адреси dom.isc.arizona.edu., то він послідовно буде звертатися до доменів isc.arizona.edu, arizona.edu, edu, кореневого. Як звичайно, сервер знає мі­німум адресу сервера кореневого домену зі своїх файлів конфігурування.

Приклад. Визначити адресу хоста lion.cf.iton.edu. Нехай адреса ва­шого сервера імен dn.isc.arizona.edu.

Запит надходить на локальний сервер імен dn.isc.arizona.edu. Він не знаходить потрібної адреси і з огляду на рекурсивність звертається до серверів доменів arizona.edu та edu. Ці сервери нерекурсивні, і сервер sdu надсилає на сервер адресу домену iton.edu. Це дає змогу нашому серверу звернутися до нього. Сервер iton.edu. також рекурсивний; він

звертається до відомого йому сервера домену cf.iton.edu та отримує адресу госта lion. Ця адреса повертається до клієнта. Після виконання описаних операцій:

Ч;> у кеші dn.isc.arizona.edu буде адреса машини lion;

^ в кеші dn.isc.arizona.edu буде адреса сервера iton.edu;

^> сервер iton.edu збереже адресу сервера cf.iton.edu.

База даних DNS

І

ЬБоза даних DNS - це набір текстових файлів, які створює та супроводжує адміністратор.

Ця база даних складається із записів різних типів (RFC 882,1035,1183). Формат запису:

[назва] [час] [клас] тип дані,

де

* назва - ім 'я машини або домену, для якого визначено цей запис. Якщогрупа записів має однакові імена, то всі імена, починаючи з другого, мож
на пропустити. Можна використовувати як повністю, так і неповніс­тю визначені імена. До неповністю визначених імен додають ім 'я локаль­
ного домену;

* час - час, протягом якого запис можна тримати у кеші;

* клас - тип мережі, де діє служба. За замовчуванням приймають I(Internet);

*• тип - тип запису, що характеризує його призначення;

* дані- список параметрів, формат якого окремий для кожного типузапису.

Усі записи умовно розділяють на три групи:

> зонні записи. Визначають домени, їхні сервери, а також межі діїнаступних записів;

> головні записи. Ці записи зіставляють імена та адреси, а такожперемаршрутизовують пошту;

> додаткові записи. Містять додаткову інформацію.

Зонні записи. SOA

У файлі БД, як звичайно спочатку записують зонні записи, а потім інші. У цьому разі їхній порядок може бути довільним.

Тип запису SOA визначає параметри зони. Зонний запис діє доти, доки у файлі не виявлено запису для іншої зони. Параметри запису най­ліпше розглянути на прикладі.

@ IN SOA ns.cs.colorado.edu admin.cs.colorado.edu.
(1001 ; Serial

21600 ; Refresh, 6 hours

1800 ; Retry, 30min

1209600 ; Expire, 2 weeks 432000) ; Minimum 5 days

Ч> Символ @ використовують для скороченого позначення біжучої зони. "Ь Поле ns.cs.colorado.edu визначає ім'я головного сервера імен зони. ^ Поле admin.cs.colorado.edu. - це адреса електронної пошти у фор­маті користувач.ім'я домену.

^ Поле Serial ідентифікує номер версії файлу БД. З кожним онов­ленням файлу це число повинно збільшуватися. Часто як таке число використовують дату модифікації. Цей номер керує оновленням інфо­рмації на допоміжних серверах.

"Ь Поле Refresh - це інтервал оновлення даних допоміжними серве­рами.

Ч> Поле Retry задає період поновного звертання допоміжного серве­ра до головного, якщо попередня спроба не була успішною.

^ Поле Expire визначає час протягом якого допоміжні сервери бу­дуть обслуговувати домен у разі недоступності головного сервера.

^> Поле Minimum визначає час чинності записів. Зі збільшенням цьо­го часу зменшується навантаження на систему DNS, однак збільшуєть­ся час опрацювання змін у конфігурації.

Зонні записи.NS

Тип запису NS. Ці записи визначають головні та допоміжні сервери зони. Як звичайно, вони йдуть після записів SOA. Формат запису:

[Зона] [час] [клас] NS ім'я_госта Поле Зона є необов'язковим і може бути зчитуване з попереднього запису SOA. Приклад:

cf.iton.edu. IN NS nsl.cf.iton.edu. cf.iton.edu. IN NS ns2. cf.iton.edu. cf.iton.edu. IN NS add_s. cf.iton.edu.

У записах зазначають тільки головні та допоміжні (авторитетні) сер­вери. Водночас тип сервера не специфікований. Записи типу NS факти­чно не використовують у межах локальної зони. Однак вони визнача­ють сервери імен для зовнішніх користувачів. Зовнішні користувачі можуть бачити тільки сервери імен, специфіковані в NS.

Бувають також внутрішні сервери, приховані від зовнішнього світу.

Головні записи

Запис Авикористовують для перетворення імені (доменної адреси) машини в IP-адресу.

Наприклад:

lion IN A 196.168.2.1

Неповне ім'я доповнюють іменем локального домену.

Запис PTRпризначено для перетворення IP-адреси в доменне ім'я го-ста. Щодо цього запис PTR виконує протилежну до запису А функцію.

Значна кількість програм користується сервісом PTR. Як звичайно, вони отримують по мережі деяку IP адресу і повинні знайти відповідне їй ім'я для порівняння зі списками імен у своїх файлах конфігурації. До таких програм належать netstat, sendmail, syslog, XWindow, ftp, finger, rlogind та ін.

Формат запису:

адреса [час] [клас] PTR ім'я__госта

Форма наведення адреси госта в цьому запису неординарна. Адресу записують справа наліво "навпаки" зміною порядку окремих байтів. У кінці адреси не ставлять крапки. Наприклад, адресу 192.168.2.1 буде записано так: 1.2.168.192

Це роблять з метою використання як для прямого, так і для зворот­ного перетворень одного програмного модуля. У разі прямого пере­творення доменне ім'я починається з найменш значущої частини. Тому і для зворотного перетворення потрібно починати адресу з найменш значущої частини.

Такий підхід зумовлює додаткові ускладнення. Відомо так: якщо доменне ім'я наведене у скороченому вигляді, то перед звертанням до DNS воно буде доповнене ім'ям локального домену. Адреса у записі PTR з формального погляду також неповна і мусить бути доповнена. Для цього ввели позначення спеціального фіктивного домену NNN.IN-ADDR.ARPA, де NNN - перший байт IP-адреси. Отже, у нашому


прикладі повне доменне ім'я буде виглядати 1.2.168.192. IN-ADDR.ARPA. Як звичайно, інформація про ім'я поточної зони єдина на кожну зону. Тому для заведення записів PTR потрібно вводити до­даткову зону NNN.IN-ADDR.ARPA, створювати для неї весь набір записів (SOA, NS, PTR). Ще один набір записів доводиться створюва­ти для зони локального госта 127. IN-ADDR.ARPA.

Між записами А та PTR повинна бути повна однозначна відповід­ність.

Додаткові записи

Запис CNAME дає змогу визначати для гостів мнемонічні імена, ви­користовувати декілька варіантів імен для одного госта.

Запис HINFO відображає виробника та модель комп'ютера.

Запис WKS визначає сервісні програми, які пропонує гост.

Запис ТХТ. Довільний текст.

Фактично DNS має значно більші можливості, ніж просте відображення адрес. DNS - це база даних про стан госта, яка є прообразом служби ката­логів мережі, хоч і не містить усіх потрібних у службі каталогів функцій, у тому числі функції підтримки розподілених баз даних.

13.4. Програмна реалізація

Програму, що реалізує функції DNS називають ще й BIND (Berkeley Internet Name Domain). Ця назва склалася історично та відображає мі­сце створення системи.

Сервер імен. Демон сервера імен називають named. Для виконання перетворення імен звертаються до бібліотечних функцій gethostbyname та gethostbyaddr. Крім програми-демона, сервер імен може мати низку

КОнАІГУПЯІтійнит тратг-глпи» ЛоКттіт, тта^~,.: л,~?----------

__ ______________ .,_ vr ^**»ь.<..* ! Іу^І*и, І лІууус/ТСОИ.Л. CC^/Ot^/f &) .

Найважливішим є файл початкового завантаження. Демон named під час початкового завантаження системи зчитує його. Формат файлу etc/named.boot:

directory ім'я__каталогу

cache ім'я_файлу

primary зона ім'я_файлу

secondary зона IP-адреса ім'я_файлу

forwarders список IP-адрес

xfrnets список IP-адрес

bogusns список IP-адрес

Розглянемо окремі директиви цього файлу:

¥ directory визначає каталог, у якому містяться всі файли, зазначені у наступних командах;

# cache визначає назву кореневого домену (.) та назву файлу(/etc/named.са), який містить адреси серверів кореневого домену. Адре­си кореневих серверів зазначені явно та використовувані для отриман­
ня інформації тоді, коли база даних та кеш порожні;

# primary визначає, що це є головний сервер для зазначеної зони таім'я файлу, у якому містяться дані цієї зони;

# secondary визначає що цей сервер використовують як допоміжнийдля зазначеної зони, IP-адресу головного сервера, ім'я кеш-файлу, у
якому зберігаються дані допоміжного сервера. На відміну від файлуголовного сервера, ці дані формуються не вручну, а автоматично са­мим демоном named шляхом їхнього узгодження з головним сервером.В одному файлі конфігурування може бути декілька команд primary та
secondary, оскільки сервер може бути одночасно первинним для однієїзони, а вторинним - для іншої;

¥ forwarders визначає список так званих пересильників. Пересиль-ники - це сервери імен, які кешують запити. Вони можуть бути зовніш­німи щодо конкретної мережі. У цьому випадку сервер імен, отримав­ши запит, переглядає свою базу та кеш. Якщо відповіді не знайдено, то він звертається до пересильників. Отже пересильники - це сервери імен для серверів імен. Як звичайно, завдяки обслуговуванню багатьох за­питів серверів вони мають багато інформації в кеші. Тому їхнє викори­стання розвантажує мережу. Якщо відповіді від пересильника не отри­мано, то сервер виконує зовнішній запит сам;

# xfrnets перераховує у списку адреси мереж та гостів, яким дозво­
лено через зонні пересилання отримувати інформацію з вашої БД DNS;

# bogusns визначає список адрес серверів імен, інформацію з яких
треба ігнорувати.Клієнт

Клієнт (визначник). Головним конфігураційним файлом клієнта є /etc/resolv.conf. Він визначає назву доменів, у яких відбуватиметься по­шук, а також адреси серверів імен.

У директиві search зазначено перелік назв доменів, якими доповню­ють неповністю визначене ім'я перед звертанням до сервера імен.

Спочатку звертаються до першого сервера у списку. Якщо через ви­значений час тайм-ауту відповіді не отримано, то звертаються до на­ступного і т. д. Кожен сервер опитують чотири рази. З кожним новим опитуванням значення тайм-ауту збільшується. Отже, процедура опи­тування у разі недосяжності серверів може тривати довго. Для збіль­шення швидкості роботи ліпше звертатися до абонента безпосередньо за IP-адресою.

Звичайно кожен з серверів, до яких звертається визначник, є рекур­сивним, оскільки визначник не опрацьовує відсилань.

13.5. Нові версії DNS

Найпоширенішою на практиці версією DNS є BIND v. 4.9. Консор­ціум з програмних засобів Internet (Internet Software Consortium) при­пинив розробку версії 4 та рекомендує переходити на версію BIND 8. Порівняно з попередньою ця версія забезпечує:

<=> динамічне оновлення БД DNS;

О повідомлення про зміну змісту БД (Notify, RFC 1996);

•=> підтримку IP v.6;

•=> більшу продуктивність;

^> поліпшені засоби безпеки.

BIND 8 не поділяє сервери DNS на первинні, вторинні, кешування, а переходить до нової моделі "головний - підлеглий" (master - slave). Го­ловні сервери містять оригінал БД, а підлеглі - її копії.

Суттєво змінилися механізми оновлення БД підлеглих серверів. У попередній версії параметр конфігурації підлеглого сервера задавав ін­тервал оновлення. Тому деякий час інформація на вторинному сервері могла бути неактуальною. Нова версія використовує повідомлення NOTIFY (RFC 1996). Після зміни даних у БД головного сервера він надсилає підлеглим повідомлення NOTIFY. Підлеглі в разі потреби

ініціюють оновлення своєї БД.

Змінено і порядок передавання записів БД. У попередніх версіях їх передавали окремими повідомленнями. Тепер в одному повідомленні намагаються об'єднати багато записів.

Динамічне оновлення БД DNS дає змогу клієнтам самостійно онов­лювати БД без втручання адміністратора.

Завдяки цьому DNS може співпрацювати зі службами DHCP. Сер­вер DHCP від імені своїх клієнтів оновлює БД, тимчасово записуючи туди їхні імена Netbios та виділені IP-адреси. Після закінчення терміну дії IP-адреси відповідний запис буде знищено.

У версії BIND 8, як і в попередній, є змога обмежити пересилання інформації (команда allow-transfer, xfrnets).

Команда allow-query визначає обмеження щодо обслуговування DNS-запитів для кожного сервера або зони. Це дає змогу захистити "внутрішні" сервери DNS від зовнішніх запитів.

Тривають роботи з реалізації цифрових підписів (згідно з RFC 2137) для безпечного динамічного оновлення БД;

IETF працює і над механізмом електронного підписування (транс-акційні підписи - Transactional Signature (TSIG) відповідей на запити клієнтів. Кожна відповідь буде підписана повноважним сервером, що унеможливить підміну DNS-повідомлень (DNS-spoofmg).

ТЕСТИ ДЛЯ САМОКОНТРОЛЮ

1. Рекурсивний сервер DNS:

а) підтримує рекурсивний характер роботи на апаратному рівні;

б) якщо не знаходить інформації у своїй базі даних, опитує іншісервера DNS;

в) реалізує рекурсивні алгоритми оновлення власної БД;

г) якщо не знаходить інформації у своїй базі даних, повертаклієнту адреси інших серверів DNS.

2. Для визначення IP- адреси госта за його доменною адресою викори­стовують такий тип запису бази даних DNS:

а) А; б)PTR; в) SO А; г) NS.

3. Допоміжний сервер DNS:

а) зберігає копію бази даних DNS та під 'єднується тільки тоді,коли головний сервер недоступний;

б) немає власної копії бази даних DNS, але використовує інфор­мацію з кешу;

в) використовують як допоміжний сервер у певній зоні;

г) періодично узгоджує зміст власної бази даних з базою данихголовного серверу.


ТЕМА 14 ШШІ ПРОТОКОЛИ МЕРЕЖІ TCP/IP

14.1. Автоматизація налаштування

Кожен комп'ютер у мережі TCP/IP щодо параметрів його конфігу-рування рівноправний з іншими комп'ютерами. Параметри конфігуру-вання такі:

<=> IP-adpeca;

<=> адреса сервера DNS;

^> адреса шлюзу за замовчуванням.

Протокол RARP

Протокол ARP (RFC 826) перетворює IP-адресу у канальну мереже­ву адресу. Протокол RARP (RFC 903) виконує зворотну дію - перетво­рює канальну адресу в IP-адресу. Гост, якому не відома його IP-адреса, надсилає у мережу циркулярний пакет-запит зі своєю МАС-адресою. Сервер RARP відповідає пакетом з IP-адресою.

Як же сервер RARP відшукує відповідність між адресами? Кожен клієнт може визначити свою МАС-адресу за документацією адаптера або командою операційної системи. В системах UNIX відповідність між МАС-адресами та іменами гостів задана у текстовому файлі /etc/ethers, наприклад:

2:80:8а:48:25:48 hostl 4:6b:8a:48:25:49 host2

Для визначення IP-адреси використовують текстовий файл DNS hosts. Протокол RARPдає змогу отримати тільки IP-адресу.

Протокол ВООТР

Первинне призначення протоколу самозавантаження ВООТР (Bootstrap protocol, RFC 951) - автоматизоване завантаження комп'ю­тера. Проте він дає змогу одержати і багато іншої інформації.

Клієнт, що завантажується, надсилає у мережу кадр запиту BOOTREQUEST, що містить МАС-адресу клієнта та передається за

ною адресою 255.255.255.255. Сервер відповідає пакетом BOOTREPLY. Під час роботи протоколу ВООТР задіяні порти UDP 67 (сервер) та UDP 68 (клієнт). Сервер передає дані про всі конфігура­ційні параметри, які йому відомі.

Параметри, які можна одержати з сервера ВООТР: >назва та >міс-це розташування завантажувального файлу, ^список серверів DNS, >МАС-адреса, >тип апаратного забезпечення, >ІР-адреса та ін. Інфор­мацію клієнт одержує у вигляді текстового запису (файлу).

Протокол DHCP

Для додаткового сервісу щодо конфігурації адрес та реконфігурації мережі у великих мережах TCP/IP може діяти протокол DHCP (Dynamic Host Configuration Protocol, RFC 1541, 1534). DHCP - це удосконале­ний ВООТР. Він повністю сумісний з ВООТР, використовує ті ж порти (67, 68) та формат пакетів (BOOTREQUEST, BOOTREPLY). Однак у DHCP дещо розширений набір параметрів та є функція автоматичного поширення адрес.

У випадку використання DHCP адреси можуть бути у таких станах:

^ закріплені за певними клієнтами та виділятися автоматизовано;

^ виділятися автоматизовано з певної множини за випадковим законом;

^> виділятися динамічно на визначений період часу.

Виділення адрес виконують спеціальні сервери DHCP. Розглянемо процес налаштування з використанням DHCP. Нехай нову станцію приєднують у мережу, де діють сервери DHCP. Під час увімкнення ця станція (клієнт DHCP) надсилає циркулярне повідомлення "discover message" - відшукати адресу. Всі сервери DHCP відповідають на цей запит пропозицією унікальних мережевих адрес. Клієнт приймає про­позиції та переходить у стан вибору. У цей час сервери DHCP "притри­мують" запропоновані адреси. Клієнт обирає одну з них та повідомляє про це відповідному серверу. Сервери DHCP розблоковують невибра-ні адреси. Обраний сервер DHCP надсилає клієнту повідомлення під­твердження з додатковими конфігураційними параметрами.

14.2. Передавання ізохронних потоків

Значна частина застосувань сучасних інформаційних мереж потре­бує передавання інформації у масштабі реального часу (ізохронні по-

токи). Вимоги до передавання таких потоків суттєво відрізняються від звичайних (наприклад, під час передавання файлів програм чи записів з баз даних). Головні відмінності такі:

•> кадри з ізохронною інформацією повинні надходити до одержувача в такому ж темпі, з такими ж інтервалами, з якими їх створював від­правник;

•^ допустима втрата деякої частини кадрів без суттєвого зменшен­ня якості інформації в одержувача;

•^ над ізохронними потоками можна виконувати деякі додаткові опе­рації (наприклад, злиття кількох потоків в один (мікшування), або пере­давання кількох варіантів одного і того ж потоку).

Звичайні, не ізохронні, потоки, переважно, не допускають втрати кадрів, однак інтервали та темп надходження кадрів може змінюватися у широких межах, бути непередбачуваним.

Найбільше для передавання ізохронної інформації придатні мережі ATM. Водночас переважною частиною сучасних локальних мереж є мережі Ethernet, які внаслідок особливостей свого методу доступу та через змінний розмір кадру не гарантують часу доставляння кадру Використання швидкісних мереж Ethernet дещо вирішує проблему, осо­бливо якщо є значний резерв у пропускній здатності. Значне збільшен­ня мережі Internet та протокольної архітектури TCP/IP потребують за­безпечення ізохронного передавання на рівні пристроїв, що об'єдну­ють локальні мережі (переважно маршрутизаторів), які часто є "вузьки­ми місцями" мережі. Найчастіше пакети ізохронного потоку затриму­ються на деякий час (буферизуються), а потім надходять до одержува­ча у заданому темпі.

Транспортні протоколи TCP та UDP не підтримують ізохронного передавання. З цією метою створено нові протоколи RTP, RSVP, RTCP, IP Multicast та інші, що забезпечують ізохронність передавання на рів­ні маршрутизаторів.

Коротка характеристика протоколів:

УїЯТР (Real Time Reservation Protocol) забезпечує передавання даних з визначеними часовими параметрами;

^> RSVP (Resource reservation Protocol) дає змогу замовити мережеві ресурси перед початком сеансу зв 'язку (наприклад, з використанням про­токолу RTP);


Ч> RTCP (Real Time Transport Control Protocol) реалізує зворотний зв 'язок з групою одержувачів інформації.

Протокол RTP

RTP є окремим протоколом (RFC 1889), який для передавання ви­користовує протокол UDP. Для того, щоб пакети RTP надходили до адресата у тому ж темпі, в якому їх генерував відправник, кожен RTP-пакет має часову позначку (час його створення). Структура пакета по­казана на рис. 14.1.

Зміст полів такий:

> поле версії (друга);


> поле заповнювача (padding) визначає, чи є заповнювач до фіксованого числа 32-байтових слів;

> поле розширення заголовка визначає, чи використовується розшире­ний формат заголовка;

> поле кількості відправників;

> поле маркера вказує на кінець логічного блока даних (відеокадру абоперіоду мовчання);

> поле тину Змістовної частини визначає тип та формат наведенняІнформації;

> пакети пронумеровані послідовно з метою виявлення їхніх втратта визначення порядку пакетів з однаковою часовою позначкою;

> у часовій позначці записано час створення першого байта пакета;

> випадкове число, яке визначає унікальний номер джерела синхронізації.

Цікавою особливістю протоколу RTP є те, що він дає змогу переда­вати інформацію від багатьох джерел багатьом одержувачам. Злиття пакетів від багатьох джерел в одному RTP-пакеті називають мікшуван­ням (змішуванням). Прикладом операції мікшування є формування єди­ного аудіопотоку накладанням звукових сигналів з кількох джерел. У спрощеному випадку мікшування зводиться до перетворення формату інформації з одного джерела. Таку операцію називають транслюван­ням. Прикладом транслювання є перетворення високоякісного форма­ту відеосигналу у низькоякісний, проте компактніший формат. Іденти­фікатори окремих джерел записані у кінці RTP-пакета.

Передавання інформації протоколом RTP звичайно виконується для групи станцій, визначених попередньо з використанням протоколу IGMP.

Протокол RTCP

Під час сеансу RTP необхідною є інформація зворотного зв'язку, оскі­льки дуже часто одержувачі не можуть приймати інформацію з визначе­ними якісними параметрами, або ж у деяких ситуаціях виникає потреба динамічно зменшити швидкість чи інші параметри передавання. Дл<' одержання такої "зворотної"" інформації, а також для виконання деяки^ функцій керування і призначено протокол RTCP (RFC 1889). Він, як і RTP, використовує сервіс протоколу UDP і має свій номер порту



Протокол RSVP

Протокол RSVP дає змогу попередньо, перед початком сеансу, за­мовити потрібні ресурси на всіх проміжних маршрутизаторах. Він при­датний як для одноадресного, так і для групового передавання.

Резервування ресурсів може відбуватися за участю як відправника, так і одержувачів інформації. У цьому принципи побудови протоколу RSVP відрізняються від принципів резервування, прийнятих, наприклад, у мережах ATM та Frame Relay. Відправники передають маршрутиза-торам головні параметри інформаційного потоку (^інтенсивність, ^рівномірність, ^формати тощо). Однак головне рішення ухвалюва­не на підставі "замовлень", що надходять від одержувачів. Кожен з оде­ржувачів, зважаючи на потреби та можливості, передає на маршрути-затори опис потоку, що складається зі специфікації потоку та фільтра. Специфікація потоку визначає якість обслуговування, а фільтр описує формат та ознаки пакетів, для яких потрібна така якість. Маршрутиза-тори приймають описи потоків від різних одержувачів та визначають узагальнені вимоги до потоків, які вони опрацьовують. У цьому випа­дку маршрутизатор може прийняти або відхилити запит на передаван­ня. Пакети, що не відповідають вимогам фільтра, маршрутизатор пе­редає у міру можливості.

Протокол RSVP використовує повідомлення типів Resv та Path. Повідомлення Resv власне резервують ресурси та переносять специфі­кації потоків і фільтрів. Маршрутизатори комбінують їх та передають від одержувачів інформації відправникам. Повідомлення Path мають на меті інформувати одержувачів про шлях до відправників (потрібний для передавання повідомлень Resv).

Склад програмного агента RSVP містить модулі ^керування досту­пом (admission control) та ^адміністрування (policy control). Модуль керування доступом перевіряє наявність ресурсів для виконання запи­ту, а модуль адміністрування - наявність у застосування-автора запиту відповідних прав. Безпосередньо передаванням даних керують два мо­дулі: > класифікатор пакетів (packet classifier) та > диспетчер пакетів (packet scheduler). Класифікатор визначає належність пакета до певно­го класу обслуговування, а диспетчер опрацьовує черги пакетів, визна­чає пріоритетність передавання.

Http протокол

Протокол HTTP 1.0 (Hypertext transmission protocol) описано в RFC-1945. HTTP це протокол рівня застосувань. Його первинне призначен­ня - передавання HTML-сторінок. Крім того, він дає змогу передавати файли, виконувальні програми та організовувати доступ до баз даних.

Робота протоколу HTTP

Роботу протоколу HTTP описує проста трасакція: клієнт генерує запит, сервер дає відповідь (рис. 14.2). Якщо по дорозі трапляється про-ксі, то він відіграє роль сервера для клієнта і роль клієнта для сервера в цій трансакції.

Формат запиту

Рядки запиту та відповіді розділяють символи CR LF, які є елемен­том протоколу:

[method] [request_URI] [HTTP_Version] [headerl_fieldname]: [fieldl_value] [header2_fieldname]: [field2_value]

[headerN_fieldname]: [fieldN_value]

[data] POST /default.htm HTTP/1.0

Accept: image/gif, *.*

Accept-Language: en

User-Agent: WebSpy (c)

<HTML> <H1> Hello! </Hlx/HTML>

Послідовність заголовків закінчується двома CRLF підряд.

Формат відповіді

[HTTP_Version] [Status_code] [Reason_Phrase] Рядок статусу, містить код статусу та пояснення до нього;

[headerl_fieldname]:

[headerN_fieldname]: [fieldN_value]

[data]

Послідовність заголовків закінчується двома CRLF підряд. Приклад: Запит.

GET /qthief.htmHTTP/1.ОМетод , URI, версія.Accept: image/gif, image/x-bitmap, image/jpeg, */*

; Типи даних, які приймає броузер.Accept-Language: en

Мова результатуизег-Agent: Mozilla/1 . 22 (compatible; MSIE 2.0; Windows 95)

; Клієнтська програма, що зробила aaroiTConnection: Keep-Alive

; Підтримувати комунікаційне сполучення до отриман­ня відповіді.

If-Modified-Since: Sunday, 17-Apr-96

; Прочитати файл, якщо він змінився з зазначеної дати.

ВІДПОВІДЬ.

НТТР/1.0 200 ОКСтатус 200 - все нормально.Date: Sun, 21 Apr 1996 02:20:42 СМТКоли було надіслано відпо­відь. Server: Microsoft-Internet-Information-Server / І.ОСерверна програма.Connection: keep-alivenoronaceHHH

на підтримку сполучення.Content-Type: text/ntmlTnn даних у відповіді.Last-Modified: Thu, 18 Apr 1996 17:39Дата останньої зміни.Content-Length: 2543Довжина даних у байтах.<HTML> any data</HTML>flaHi

_ Якщо дані не поміщаються в один пакет, то тоді відбувається ге­нерування наступного. Браузер, який отримав сторінку, генерує

* нові запити, цього разу на зображення та інші об'єкти, що пропи­сані у сторінці.

Якщо в заголовку зазначено: передати останню версію, у разі зміни, а зміни не було, то у відповідь передається тільки заголовок з кодом 304, Not modified.

Методи запиту

GET- зчитування HTML-сторінок, та також інших файлів, на які є посилання в сторінці. Можна додати заголовок If-modified-Since і зчи­тати тільки змінену інформацію.

HEAD - дає змогу отримати тільки протокольні заголовки без да­них. Використовується для тестування правильності гіперпосилання.

POST-запис. Запит містить дані, призначені для записування на сер­вер. Наприклад, визначаючи URI як каталог, можна зробити запис у цей каталог або таким способом зробити запис у базу даних. POST-запитах використовуються додаткові типи заголовків.

Однак запис на сервері необов'язковий. POST часто застосовують для передавання додаткової інформації на сервер.

У HTTP 1.1. запропоновано нові методи: PUT подібний до POST, тільки зазначає в адресі не ім'я каталогу, а ім'я файлу; PATCH-онов­лення заданого об'єкта, COPY, MOVE, DELETE - операції з копію­вання, перенесення, знищення об'єктів, LINK, UNLINK- налагоджен­ня та розірвання зв'язків між вибраними об'єктами, OPTIONS дає змо­гу запитувати сервер про його можливості, наприклад типи контенту; TRACE- переслати запит назад до клієнта (луна).

У відповідь на кожен запит web-сервер формує відповідь, що міс­тить статус та іншу інформацію у заголовку. Коди статусу належать до однієї з п'яти категорій: ^Informational, ^-Successful, ^Redirection, >Client Error, >Server Error з відповідними кодами 100, 200, 300, 400, 500



74.4. Маршрутизація в мережах if

| # Головний параметр маршрутизації IP-пакета - це його IP-адреса.

Протокол IP поділяє всі комп'ютери на маршрутизатори (routers) та звичайні комп'ютери (hosts). Звичайні комп'ютери не розсилають мар­шрутних таблиць. Водночас на гості можуть бути запущені програми маршрутизації, тобто він може виконувати функції маршрутизатора.

Розглянемо приклад виконання маршрутизації (рис. 14.3).

Автономна система складається з чотирьох локальних мереж (у ро­зумінні протокольного стека TCP/IP), сполучених трьома маршрути-заторами, кожен з яких є одночасно елементом кількох окальних ме­реж. Маршрутизатор має окрему IP-адресу в кожній мережі, по якій до нього звертаються гости цієї мережі. Маршрутна таблиця такої мережі для передавання пакета через М2 в найпростішому випадку могла б


Елементом таблиці маршрути­зації, як звичайно, є маршрут за замовчуванням (default). Якщо маршруту в таблицях не виявле­но, то пакет надсилається за замо­вчуванням маршрутизатору, який має додаткову інформацію.

Алгоритм вибору маршруту:

1. IP-адреса зчитується з да-
нограми.

2. У цій адресі відшукується ад­
реса мережі призначення.

3. Якщо адреса відповідає ло­
кальній мережі, то пакет безпосе­
редньо надходить до адресата.

4. Якщо адреса є в маршрутній
таблиці, то пакет надсилається за
цією адресою.

5. Якщо описано маршрут за
замовчуванням, а адреси нема, то
пакет надсилається за цим марш­
рутом.

6. Інакше видається повідом­
лення про помилку маршрутизації.

Якщо мережа має підмережі, то перед порів-нянням адрес над IP-адресою призначення робиться побітове "&".

Метрика маршруту

І

& Метрика маршруту - це його числова характеристика за пев­ним критерієм (кількість проміжних маршрутизаторів, час пере­давання, надійність тощо).

Найпоширеніші такі протоколи маршрутизації: •> RIP (Routing Information Protocol) RFC 1058, 1721, 27- протокол внутрішньої маршрутизації для невеликих мереж. Розроблений фірмою

Xerox. Простий, використовує одну метрику - кількість кроків. Його поступово витісняє протокол OSPF;

•* OSPF (Open Shortest Pass First) RFC 1850, 1523, 1587, 1584 - про­токол внутрішньої маршрутизації, складний, використовує кілька типів метрик;

•> EGP (Exterior Gateway Protocol) RFC904, 911,1092, 1093-прото­кол зовнішньої маршрутизації. Працює тільки з деревоподібними струк­турами мереж та повідомляє сусідам тільки про один можливий шлях. Його витісняє протокол BGP;

•» BGP (Border Gateway Protocol) RFC 1267, 1771, 1655,57-прото­кол зовнішньої маршрутизації;

-> IGRP (Interior Gateway Routing Protocol) - протокол внутрішньої маршрутизації, розроблений фірмою CISCO для великих неоднорідних мереж. Подібний до OSPF.

Автономні системи провадять кожна власну маршрутну політику, користуються одним протоколом внутрішньої маршрутизації та спо­лучені з іншими автономними системами за допомогою граничних ма­ршрутизаторів, через які проходить весь транзитний трафік (рис. 14.3).

Протокол BGP

Одним з протоколів зовнішньої маршрутизації є BGP (Border Gateway Protocol) (RFC - 1267, 1655,1771-74). На відміну від маршру­тизаторів, що є всередині автономної системи, граничні маршрутиза-тори можуть сполучувати АС з різними протоколами маршрутизації. Кожен граничний маршрутизатор формує свої власні маршрутні таб­лиці і повідомляє сусідні граничні маршрутизатори про зміни у них. Маршрутні таблиці зберігаються у спеціальній базі даних маршрутів RIB (Routing Information Base).

На відміну від внутрішніх маршрутизаторів граничні маршрутиза­тори не зобов'язані передавати всю інформацію на інші. (Один гранич­ний маршрутизатор не зобов'язаний надсилати, а інший - приймати). Протокол визначає тільки формат інформації, порядок обміну.

Тому важливою є політика маршрутизації, її задає адміністратор, який визначає параметри обміну маршрутною інформацією, часові па­раметри, канали, яким треба надавати перевагу, та інше, враховуючи не тільки технічні, а й юридичні, економічні та інші обставини.



14.5. Підсумок: процес передавання у мережі TCP/IP

Як підсумок розглянемо приклад передавання даних в мережі TCP/IP (рис. 14.4).

Нехай користувач увів у вікні браузера адресу http://www.oracle.com. Система аналізує адресу та вияляє що використовується протокол HTTP, за яким закріплено порт 80. Для успішного передавання необ­хідно визначити IP адресу призначення. Броузер звертається до служ­би DNS з запитом та виявляє що IP адреса призначення 141.146.8.66.

Запит проходить через модуль протоколу TCP, що пробує встано­вити сполучення і далі - на модуль протоколу IP. Система звертається до локальних маршрутних таблиць і по відомій IP адресі призначення визначає IP- адресу наступного маршрутизатора (ІР1).

Для передавання на канальному рівні необхідно знати МАС адресу наступного маршрутизатора. Система звертається до протоколу ARP та визначає цю МАС - адресу.

Пакет передається в межах локальної мережі до наступного марш­рутизатора (ІР1). ІР1 в свою чергу аналізує свої маршрутні таблиці та намагається виявити адресу наступного маршрутизатора (ІР2), якому треба передати пакет. Якщо такого маршрутизатора не знайдено, ІР1 генерує ІСМР - пакет "адресат недосяжний" та відправляє його клієн­ту. Якщо маршрутизатор ІР2 знайдено, пакет передається йому. Нада­лі цей процес повторюється - пакет слідує по мережі через низку лока­льних мереж та маршрутизаторів, поки дійде до локальної мережі та сервера - адресата. Сервер, отримавши пакет, визначає, що його адре­совано порту 80 і ставить його у чергу цього порту. Програмне забез­печення TCP - опрацьовує чергу, збирає сегменти TCP та передає інфо­рмацію web- серверу.

ТЕСТИ ДЛЯ САМОКОНТРОЛЮ

1. Виступаючи клієнтом сервера ВООТР (bootpd), ми можемо:

а) отримати IP- та МА С- адреси власного комп 'ютера;

б) проводити завантаження комп 'ютера;

в) отримувати тимчасові IP-адреси;

г) отримати інформацію про сервера DNS;

д) отримати IP-адреси по замовленню.

2. Ізохронні інформаційні потоки - це:

а) часові інтервали між: кадрами в них постійні;

б) пакети в таких потоках несуть часові мітки;

в) їхні кадри повинні надходити до отримувача в такому ж те­
мпі, в якому генерувалися відправником;

г) можуть передаватися одночасно зі звичайними даними;

д) можливо декілька варіантів одного потоку;

е) можуть передаватися з використанням TCP.

3. Протокол RTP:

а) призначений для передавання ізохронної інформації;

б) призначений для резервування ресурсів;

в) дозволяє змішувати потоки від декількох джерел;

г) дозволяє отримувати інформацію від одержувачів про якість
приймання.

4. Протокол RSVP:

а) дає змогу для конкретного сеансу резервувати ресурси на ма-
ршрутизаторах;

б) переносить ізохронну інформацію;

в) аутентифікує сеанс;

г) враховує вимоги як відправників, так і одержувачів інформації.

Лабораторна робота

Вивчення параметрів налаштування та мережевих утиліт стеку протоколів ТСРЯР

Метою роботи є ознайомлення з текстовими файлами параметрів та налаштуваннями протоколів стеку TCP/IP та утілітами командного рядка, набуття вміння правильно аналізувати результати їх виконання.

Засоби та передумови

Робота виконується у навчальному класі, обладнаному локальною комп'ютерною мережею. В локальній мережі встановлені комп'ютери з операційною системою Windows 2000 або Windows ХР. Для кожного комп'ютера налаштовано доступ до мережі ТСРЛР.

Теоретичні відомості

Набір протоколів TCP/IP застосовують у мережах Internet. Для налаштування протоколів використовують ряд текстових файлів конфігурації а також утілити командного рядка. Всі текстові файли налаштувань можна знайти в ОС Windows 2000 у каталозі Windows\System32\Drivers\etc.

Файли налаштувань

Hosts

У файлі'задається відповідність між IP-адресами та назвами комп'ютерів. Це текстовий файл, який містить рядки такого формату:

IP-адреса назва комп'ютера

Наприклад:

127.0.0.1 localhost

192.168.3.24 myhostl 192.168.2.14 myhost2

Services

У файлі services прописані відповідності між назвою застосування, номером порту, та транспортним протоколом. Формат рядка для цього файла наступний:

<service name> <port number>/<protocol> [aliases...] [#<comment>]


де service name - назва застосування, port number - номер порту, protocol -назва транспортного протоколу (tcp або udp), aliases - синоніми до назви застосування. Як правило, порти закріплені за застосуваннями.

Приклад змісту файлу :

echo 7/tcp


echo 7/udp

discard 9/tcp sink null

discard 9/udp sink null

systat 11/tcp users #Active users

systat 11/tcp users #Active users

daytime 13/tcp

daytime 13/udp

qotd 17/tcp quote #Quote of the day

qotd 17/udp quote #Quote of the day

chargen 19/tcp ttytst source ^Character generator

chargen 19/udp ttytst source #Character generator

ftp-data 20/tcp #FTP, data

ftp 21/tcp #FTP. control

telnet 23/tcp

smtp 25/tcp mail #Simple Mail Transfer Protocol

Networks

Файл networks задає відображення між іменем мережі та мережевою частиною IP- адреси.

Формат рядка цього файлу:

<network name> «cnetwork number> [aliases. . .] [#<comment>] ,

де network name - назва мережі, network number - IP-адреса мережі, aliases - синоніми до імені мережі. Наприклад:

loopback 127 campus 284.122.107 london 284.122.108

Protocol

Задає відповідності між назвою протоколу та його числовим ідентифікаторе м.


Формат рядка цього файлу:

<protocol name> <assigned number> [aliases. . .] [#<comment>],

де protocol name - назва протоколу, assigned number - числовий ідентифікатор протоколу, aliases - синоніми до назви протоколу.

Ping

Дозволяє перевірити наявність сполучення з віддаленим комп'ютером.
Крім того, ping використовують для оцінки часу передавання луна - сиг-
_, її---- пналу на віддалений комп'ютер.

Формат команди:

ping[-t] [-a] [-ncount] [-1 length] [-і] [-і ttf] [-v tos] [-r count] [-s count] [[-j computer-list] | [-k computer-list]] [-w timeout] destination-list

Паоаметпн-

3.T>aeeft

Ця yfйлита визначає шлях До госта - адресата, виводячи адреси всіх проміжних маршрутизаторів. Це досягається посиланням ІСМР паке­тів зі зростаючими значеннями TTL. Кожен проміжний маршрутиза-тор декрементує значення TTL і, якщо воно стає рівне нулю - не пере-

дає далі, а повертає повідомлення про помилку. Формат команди:

tracert [-d] [-її maximum_hops] [-j computer-list] [-w timeout] target name

Ipconfig

Ця програма конфігурування відображає всі біжучі налаштування протоколу TCP/IP. Формат команди: ipconfig [/all | /renew [adapter] | /release [adapter] ]

Netstat

Команда відображає статистику передавань для різних протоколів та наявних TCP сполучень. Формат команди:

netstat [-а] [-е] [-n] [-s] [-p protocol] [-r] [interval]

Hostname

Ця команда відображає назву даного госта. Формат:

hostname

Route

Призначена для роботи з таблицями маршрутизації. Формат:

route[-f] [-p] [command [destination] [mask subnetmask] [gateway] [metric costmetric]]

Порядок виконання роботи

1. Знайти та скопіювати у звіт зміст файлів Hosts, Services, Networks
на локальному комп'ютері. Пояснити формат та використання записів

у цих файлах.

2. На завдання викладача перевірити наявність сполучення з визна­
ченими комп'ютерами та запротоколювати параметри сполучення.

3. Визначити та запротоколювати зміст таблиці агр протоколу на ло­
кальному комп'ютері. Пояснити його. Встановити сполучення з іншими
комп'ютерами. Запротоколювати зміни в таблиці агр після цього.

4. Визначити параметри та запротоколювати параметри наявних

мережевих інтерфейсів.

5. На завдання викладача визначити всі проміжні маршрутизатори
на шляху до госта з заданою адресою. Запротоколювати їх.

6. Вивести та запротоколювати статистику використання internet
протоколів на локальному комп'ютері. Пояснити її.

7. Вивести та запротоколювати зміст маршрутних таблиць на зада­
ному гості. Пояснити його.


8. Частина IV

ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ ТА INTERNET

INTERNET ТА ТЕХНОЛОГІЇ ІНФОРМАЦІЙНИХ МЕРЕЖ

РОЗПОДІЛЕНІ АРХІТЕКТУРИ МЕРЕЖЕВИХ ОБЧИСЛЕНЬ

ТЕХНОЛОГІЇ ГРУПОВОЇ РОБОТИ

ТЕМА 15

INTERNET ТА ТЕХНОЛОГИ ІНФОРМАЦІЙНИХ МЕРЕЖ

Четверта частина підручника присвячена сучасним інформаційним технологіям, що базуються на інфраструктурі комп'ютерних мереж.

Розглянемо розподілені інформаційні технології, які є у мережі Internet. Особливу увагу приділимо найважливішій технології - World Wide Web (WWW, Web-технологія).

Історія виникнення та еволюція Internet

Мережа Internet розроблена Міністерством Оборони США як під­сумок проекту ARPA (Advanced Research Projects Agency) 1969 p. Тоді вона називалася ARPANET та об'єднувала університети й оборонні організації. У 1973 p. ARPA розпочало дослідницький проект з об'єд­нання комп'ютерних мереж (Internetting project) за допомогою супуг никових та радіоканалів. Головною проблемою було об'єднання різнотипних мереж. Тоді ж для вирішення цього завдання були винай­дені шлюзи. Спочатку в ARPANET можна було тільки запускати про­грами на віддалених комп'ютерах, однак поступово до функційних можливостей мережі додалися передавання файлів, електронна пошта, конференції та списки поштового розсилання. У 1983 р. вирішено ви­користовувати на всіх вузлових машинах ARPANET протокольний стек TCP/IP, що визначило єдину платформу, ядро мережі. Тоді ж ARPANET розпалася на військову мережу MILNET і мережу університетів та інших наукових і державних установ ARPANET, її використовували для до­сліджень з мережевої проблематики. У 1990 p. ARPANET припинила своє існування. На базі технічної інфраструктури та розроблених прин­ципів функціювання ARPANET виникла Internet. Організацією, яка активно зайнялася підтримкою розвитку Internet на цьому етапі, була NSF (National Scientific Foundation). Вона створила свою мережу NSFNET, яка об'єднала шість суперкомп'ютерів у логічне кільце кана­лами ТЗ (45 Мбіт/с) та була базовою в Internet. Сьогодні роль базових перейшла до мереж InternetMCI, Sprint Link, ANSNET.

Структура Internet

+Internet - це інтермережа, що складається з багатьох мереж, які працюють на базі протоколів TCP/IP..., об 'єднані шлюзами та використовують єдиний адресний простір і простір імен. Головною ознакою Internet є використання протоколів стека TCP/IP.

Internet має декілька опорних мереж, що надають магістральний, базовий сервіс, у США це - InternetMCI, Commercial Internet Exchange, у Європі - EBONE, NORDUnet, DANTE, EUnet. Кожна з таких мереж відповідає за трафік усередині мережі та приєднання до інших мереж. Менші за розмірами регіональні та локальні мережі, які є частинами Internet, відповідають за передавання та одержання даних з Internet, зберігаючи повне адміністрування власними ресурсами та ведучи влас­ну внутрішню політику.

І

Отже, Internet - це конгломерат взаємоприєднаних та мереж, що взаємодіють, у якому кожна з них зберігає повну внутрішню авто­номію та самофінансування.

Командний інтерфейс більшої частини сервісів Internet грунтується на синтаксисі команд UNIX.

Віддалений доступ (telnet)

11 ^ Telnet - це протокол віддаленого доступу, який дає змогу корис-\ \ тувачу виконувати програми на інших машинах.