Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Реалізація способів вирішення імен
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2012
Тип роботи:
Звіт про виконання лабораторної роботи
Предмет:
Операційні системи
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки, молоді та спорту України
НУ « Львівська політехніка »
/
Звіт
Про виконання лабораторної роботи № 3,4
на тему: “ Реалізація способів вирішення імен ”
з дисципліни “Операційні системи, частина 2”
Мета роботи – ознайомитися зі способами організації вирішення імен, набути практичні навики стосовно формування розподілених систем збереження даних та забезпечення доступу до цих даних з будь-якого хоста корпоративної мережі.
Теоретичні відомості
В операційних системах, котрі початково розроблялися для локальних мереж, таких як Novell NetWare, Microsoft Windows або IBM OS/2, користувачі завжди працювали зі символьними іменами комп’ютерів. Оскільки локальні мережі складалися з невеликого числа комп’ютерів, застосовувалися для їх ідентифікації так звані “плоскі” імена, які складалися з послідовності символів, не розділених на частини (наприклад: NW_1, mail2, WS212_1, і т.д). Для встановлення відповідності між символьними іменами комп’ютерів і MAC-адресами у цих операційних системах застосовувався механізм широкомовних запитів. Так, широкомовний спосіб вирішення імен реалізований у протоколі NetBIOS (Network Basic Input/Output System), на якому було побудовано більшість локальних ОС. Для стеку TCP/IP, розрахованому в загальному випадку на роботу у великих територіально розподілених мережах, подібний підхід виявився неефективним (хоча, з метою вирішення проблеми об’єднання в один цих двох протоколів, Internet Engineering Task Force (IETF) випустила серію стандартизуючих документів під назвою RFC 1001 і 1102, які описують роботу NetBIOS над TCP/IP. З тих пір пакет цих документів є відомий під іменем NetBIOS над TCP/IP або NBT (У цьому випадку існує метод прив’язки імені NetBIOS до конкретної IP-адреси. Цей процес називається визначенням імені і може вирішуватися двома способами: а) кожен комп’ютер повинен передати запитувальному свою IP-адресу, після одержання широкомовного запиту на своє NetBIOS ім’я; б) використовувати NBNS (NetBIOS Name Server) для розпізнавання імен NetBIOS в IP-адрес).
У великих мережах (які складаються з великої кількості мереж та підмереж) можливість всезагальної широкомовних запитів не підтримується, тому потрібен інший спосіб вирішення символьних імен. Доброю альтернативою широкомовним запитам є застосування централізованої служби, яка б підтримувала відповідність між різними типами адрес усіх комп’ютерів мережі. Наприклад, компанія Microsoft для своїх корпоративних ОС розробила централізовану службу WINS (Windows Internet Name Service), які підтримує базу даних NetBIOS імен і відповідних їм IP-адрес.
У процесі розростання INTERNET і, відповідно, збільшення кількості вузлів виникла необхідність масштабованого рішення для вирішення імен. Таким рішенням стала централізована служба DNS (Domain Name System – Система Доменних Імен), яка базується на розподіленій базі відображення “доменне ім’я – IP-адреса”. Служба DNS використовує у своїй роботі DNS-сервери і DNS-клієнти. DNS-сервери підтримують розподільну базу відображень, а DNS-клієнти звертаються до серверів зі запитами щодо вирішення доменного імені в IP-адресу.
У доменній системі імен розрізняють короткі імена, відносні імена і повні доменні імена. Коротке ім’я – це ім’я кінцевого вузла мережі (хоста чи порта маршрутизатора). Відносне ім’я – це складене ім’я, яке починається з деякого рівня ієрархії, але не найвищого. Повне доменне ім’я включає складові усіх рівнів ієрархії.
Пошук адреси по доменному імені
Коли Ви користуєтеся ім'ям, наприклад, mx.ihep.su, комп'ютер повинний перетворити його на адресу. Для цього він починає запитувати поміч у DNS-серверів. Це вузли, робітники машини, що володіють відповідною базою даних, у число обов'язків яких входить обслуговування такого роду запитів. DNS-сервер починає опрацювання імені з правого його кінця і рухається по ньому вліво, тобто спочатку провадиться пошук адреси в найбільшій групі (домене), потім поступово звужує пошук. Але для початку опитується на предмет наявності в нього потрібної інформації місцевий вузол. Тут можливі три випадки:
Місцевий сервер знає адресу, тому, що ця адреса утримується в його частині всесвітньої бази даних. Наприклад, якщо Ви під’єднані до локальної мережі якоїсь корпорації то ваш місцевий сервер повинний мати інформацію про всі комп'ютери локальної мережі цієї корпорації (mx, desert, ixwin і т.д.);
Місцевий сервер знає адреси, тому, що хтось нещодавно вже запитував таку ж адресу. Коли запитується адреса, сервер DNS притримує її у себе в пам'яті якийсь час, саме на випадок, якщо хтось ще захоче пізніше скористатися тією ж адресою - це підвищує ефективність системи;
Місцевий сервер адреси не знає, але знає як його з'ясувати.
Місцевий сервер може дізнатися запитану адресу наступним чином. У його прикладному або системному програмному забезпеченні є інформація про те, як зв'язатися з кореневим сервером. Це сервер, що знає адреси серверів імен вищого рівня (самих правих в імені), тут це рівень держав (рангу домена ua, uk). У нього запитується адреса комп'ютера, відповідального за зону ua. Місцевий DNS-сервер зв'язується з цим більш загальним сервером і запитує в нього адресу сервера, відповідального за домен ihep.ua. Тепер уже запитується цей сервер і в нього запитується адреса робочої машини mx.
Насправді, для підвищення ефективності, пошук починається не із самого верху, а з найменшого домена, у який входите і Ви, і комп'ютер, ім'я якого Ви запросили. Наприклад, якщо ваш комп'ютер має ім'я nonlin.mipt.su, то опитування почнеться (якщо ім'я не з'ясується відразу) не з усесвітнього серверу, щоб дізнатися адресу серверу групи ua, а відразу з групи mipt.ua, що скорочує пошук і за обсягом, і за часом.
Цей пошук адреси цілком аналогічний пошуку шляху листа без надписаного поштового індексу. Як визначається цей індекс? Всі регіони пронумеровані - це перші цифри індексу. Лист пересилається на центральний поштамт цього регіону, де є довідник із нумерацією районів цього регіону - це такі цифри індексу. Тепер лист йде на центральний поштамт відповідного району, де вже знають усі поштові відділення в підопічному районі. У такий спосіб по географічній адресі визначається поштовий індекс, йому відповідний. Також визначається й адреса комп'ютера в Internet, але подорожує не послання, а запит вашого комп'ютера про цю адресу. І на відміну від випадку з поштою, інформація про адресу доходить до вас, як якби районний поштамт місця призначення відправляв вам лист, повідомляючи Вас на майбутнє про індекс.
Коли Ви бачите посилання на DNS-сервер, мається на увазі, що ми просто звертаємось до сервера імен. Імена хостів в Інтернеті складаються з частин, розділених крапками. Домен – це сукупність машин що розділяють один і то й же суфікс імені. Домен може знаходитись всередині іншого домену. Наприклад, машина www.tldp.org знаходиться в під домені tldp.org домену .org.
Кожен домен визначається первинним сервером імен, що знає ІР адреси інших машин домену. Первинний сервер може мати резервні копії на випадок, якщо він вийде з ладу. Якщо ви бачите звернення до вторинного доменного сервера, то це говорить саме про те. Вторинні сервери обновлюють свою інформацію з первинних кожних кілька годин, отож зміни, зроблені у відображенні імен у ІР адреси на первинному сервері будуть автоматично продубльовані.
Сервери імен уявлення не мають про розташування всіх машин у інших доменах (включаючи власні піддомени); вони знають лише про місцезнаходження інших серверів імен. В нашому прикладі первинний сервер імен домену .org знає ІР адреси серверів імен tldp.org, але не адреси інших машин домену tldp.org.
Домени у системі DNS нагадують дуже розлоге дерево. У основі є кореневі сервери. Кожен знає ІР адреси кореневих серверів; вони є вшитими у ваші DNS програми. Кореневі сервери знають адреси серверів імен доменів верхнього рівня на кшталт .com чи .org. Кожен сервер верхнього рівня знає адреси доменних серверів дочірнього рівня і так далі. Система доменних імен спроектована дуже акуратно, так що кожен комп’ютер володіє необхідним мінімумом знань про вузли дерева і дуже легко вносити локальні зміни без необхідності перебудовувати всю існуючу базу даних відображення імен у ІР адреси.
Коли Ви робите запит на отримання ІР адреси сайту www.tldp.org, ось що насправді відбувається: перш за все ваш сервер імен запитує кореневий сервер адресу сервера імен домену .org. Після цього він запитує у сервера імен домену .org адресу сервера імен домену .tldp.org. Ну а вже у цього сервера ваш сервер запитує адресу сайту www.tldp.org. Пакети та маршрутизатори
Нехай браузер хоче відправити командний рядок до веб-сервера на www.tldp.org, що виглядає приблизно ось так:
GET /HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html HTTP/1.0
Подивимось, що ж відбувається насправді. Команда вкладається у пакет, блок бітів, подібних до телеграми, що доповнюється трьома важливими речами: адресою джерела (ІР адресою вашої машини), адресою одержувача (152.19.254.81) та номером послуги або номером порта (80 в даному випадку).
Далі Ваш хост відправляє пакет (до вашого провайдера чи по локальній мережі) поки він не дістанеться до маршрутизатора. Маршрутизатор має карту Інтернету у своїй пам’яті – не повну, звісно, але вона повністю описує ваше мережеве оточення та знає як дістатись до інших маршрутизаторів у Інтернеті. Ваш пакет може пройти крізь декілька маршрутизаторів на своєму шляху до цілі. Маршрутизатори є швидкими. Вони дивляться, скільки часу пакет йтиме до інших маршрутизаторів і використовують цю інформацію щоб відправляти пакети по найшвидших з’єднаннях. Вони також спостерігають коли інший маршрутизатор чи кабель виходять з ладу і стараються знайти обхідний маршрут для пакетів.
ТСР та ІР
Щоб зрозуміти, як підтримуються передачі кількох пакетів, ви повинні знати, що Інтернет вживає два протоколи, розташовані один над одним.
Нижчий рівень, ІР (Internet Protocol) відповідає за позначення індивідуальних пакетів з адресами відправника й одержувача двох комп’ютерів, що обмінюються інформацією у мережі. Наприклад, якщо ви звертаєтесь до http://www.tldp.org, пакети, що ви їх відправляєте, будуть мати ІР адресу вашого комп’ютера, скажімо, 192.168.1.101, ну а ІР адреса www.tldp.org 152.2.210.81. Ці адреси працюють точно таким чином, як у випадку, коли вам хтось відправляє листа. На пошті можуть прочитати адресу та визначити яким чином найкраще відправити вам листа, точно так само як маршрутизатор у Інтернеті робить з Інтернет-трафіком.
На верхньому рівні, TCP (Transmission Control Protocol – Протокол контролю передачі) ви отримуєте надійність. Коли дві машини узгоджують ТСР з’єднання (за допомогою ІР), одержувач знає, що він повинен відіслати підтверджувальні пакети відправнику. Якщо відправник не бачить підтверджувального пакету на протязі певного часу, він відсилає пакет повторно. До того ж, відправник присвоює кожному пакету послідовний номер, за допомогою котрих одержувач може відсортувати пакети у правильному порядку (пакети запросто можуть помінятись місцями наприклад якщо мережеве з’єднання пропало на деякий час, а потім знову появилось).
ТСР/ІР пакети містять також контрольні суми для того, щоб мати змогу перевірити правильність даних у пакетах (контрольна сума вираховується таким чином що у випадку якщо пакет чи контрольна сума пошкоджені, повторне їх вирахування на боці одержувача дуже легко виявити помилку). Отож, з точки зору будь-кого, хто використовує ТСР/ІР та сервери імен, це надійний шлях обміну потоків байтів між хостом/номером послуги. Люди, котрі пишуть мережеві протоколи, майже ніколи не повинні задумуватись над поділом на пакети, зворотною збіркою пакетів, перевіркою помилок та контрольних сум, та повторною передачею – це все робиться на нижчих рівнях.
НТТР, прикладний протокол
У попередньому прикладі Веб-браузер та сервер спілкуються по прикладному протоколу, що запускається поверх ТСР/ІР, використовуючи його як простий метод передачі даних туди й назад. Цей протокол називається НТТР (Hyper-Text Transfer Protocol, протокол передачі гіпертексту) і ми вже бачили одну його команду – GET у попередньому прикладі.
Коли команда GET потрапляє до веб-сервера www.tldp.org на порт 80, вона буде перенаправлена відповідній резидентній програмі (“демону”), яка прослуховує відповідний порт. Більшість Інтернет-послуг реалізовані на основі “демонів”, котрі нічого не роблять, а лише прослуховують порти в очікуванні на вхідні команди.
Якщо б структуру Інтернету описувалась одним правилом, воно б звучало так: всі частини мають бути настільки простими й зрозумілими, наскільки це взагалі можливо. НТТР та його родичі (як, наприклад, простий протокол передачі поштових повідомлень, SMTP) прагнуть використовувати прості текстові команди, що завершуються символом нового рядка. Це максимально неефективно; в деяких випадках ви можете отримати значно більшу швидкість, використовуючи щільно закодований бінарний протокол. Але досвід показує, що вигода від команд, котрі людина може легко зрозуміти, значно більша, аніж якщо б ми робили щось швидко й незрозуміло.
Таким чином, відповідь “домена” також буде простим текстом, переданим через ТСР/ІР. Початок відповіді виглядатиме приблизно ось так (кілька заголовків було викинуто):
HTTP/1.1 200 OK
Date: Sat, 10 Oct 1998 18:43:35 GMT
Server: Apache/1.2.6 Red Hat
Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT
Content-Length: 2982
Content-Type: text/html
Після них буде порожній рядок, а далі – текст веб-сторінки, після чого з’єднання обірветься. Ваш браузер просто відобразить сторінку. Заголовки скажуть йому, як саме (зокрема, заголовок Content-Type скаже, що це справді HTML).
Результати виконання лабораторної роботи
Завдання:
Варіант 2 - Розробити власний варіант IP-структуризації корпоративної комп’ютерної мережі (ККМ). Для цього:
1) навести схему ККМ із зазначенням IP-адрес усіх мереж (підмереж), їх масок та вузлів головного будинку корпорації, а для філій – схему із зазначенням IP-адрес префіксів об’єднаних мереж та їх масок, IP-адрес вузлів кожної філії. При цьому має використовуватись наступний діапазон INTRANET адрес мереж : 192.168.0.0 ( 192.168.255.0;
2) забезпечити ІР-адресами вказану кількість мережевих інтерфейсів для кожної підмережі DMZ з пула адрес 129.130.0.0 ( 129.130.255.255 (при цьому використовувати маски мереж змінної довжини для економії ІР-адрес):
60;
30;
14;
3) відобразити маршрути, внесені в таблиці маршрутизації усіх маршрутизаторів корпоративної мережі;
4) забезпечити “вихід” вузлів корпорації в INTERNET;
5) забезпечити централізоване вирішення символьних імен усіх Hosts ККМ у відповідні їм IP-адреси;
6) провести моделювання розробленої корпоративної мережі у середовищі Packet Tracer.
Дані варіанту:
а) забезпечити IP-адресами 500 хостів мережі головного будинку корпорації (без врахування числа хостів щодо попереднього індивідуального завдання);
б) крім того, виділити наступну кількість IP-адрес на адресацію вузлів:
на філію1 4000 IP-адрес;
на філію2 2000 IP-адрес.
7) Здійснити централізоване вирішення “символьне ім’я – ІР-адреса” вузлів Вашої корпоративної мережі (головний будинок (ГБ) і дві філії (Ф1 та Ф2)).
Створити розподілену систему збереження даних на основі DNS та забезпечити доступ до цих даних з будь-якого хоста мережі, при цьому:
а) дані відповідних категорій повинні зберігатися окремо на різних серверах корпорації (задіяти принаймні 3 сервери);
б) сервер домену верхнього рівня повинен знаходитися у Ф1 а сервери доменів нижчих рівнів у ГБ та Ф2 відповідно;
в) централізоване вирішення “символьне ім’я – ІР-адреса” вузлів Вашої корпоративної мережі здійснити використовуючи сервер Ф2.
Схема мережі
/
IP-адреси інтерфейсів маршрутизаторів
Інтерфейс маршрутизатора
IP- адреса інтерфейсу
Маска
RГБ
FastEthernet0/0
129.130.0.66
255.255.255.224
FastEthernet1/0
192.168.24.1
255.255.254.0
FastEthernet4/0
192.168.60.1
255.255.255.0
FastEthernet5/0
192.168.50.1
255.255.255.0
Інтерфейс маршрутизатора
IP- адреса інтерфейсу
Маска
RФ1
FastEthernet0/0
192.168.0.1
255.255.240.0
FastEthernet4/0
192.168.50.2
255.255.255.0
Інтерфейс маршрутизатора
IP- адреса інтерфейсу
Маска
RФ2
FastEthernet0/0
192.168.16.1
255.255.248.0
FastEthernet5/0
192.168.60.2
255.255.255.0
Інтерфейс маршрутизатора
IP- адреса інтерфейсу
Маска
R1
FastEthernet0/0
129.130.0.97
255.255.255.240
FastEthernet1/0
129.130.0.65
255.255.255.224
FastEthernet8/0
129.130.0.1
255.255.255.192
FastEthernet9/0
201.121.10.2
255.255.255.0
Таблиці маршрутизації
RГБ
/
RФ1
/
RФ2
/
R1
/
Конфігурація портів сервера
Server
/
Server1
/
Server2
/
Internet
/
Конфігурація DNS Server
/
Конфігурація DNS Server1
/
Конфігурація DNS Server2
/
Запит lg.mobile.teh в полі URL PC5
/
/
/
/
/
/
Висновок: на лабораторній роботі № 3,4 я навчилася розроблювати власний варіант IP-структуризації корпоративної комп’ютерної мережі (ККМ). Для цього навела схему ККМ із зазначенням IP-адрес усіх мереж (підмереж), їх масок та вузлів головного будинку корпорації, а для філій – схему із зазначенням IP-адрес префіксів об’єднаних мереж та їх масок, IP-адрес вузлів кожної філії, забезпечила ІР-адресами вказану кількість мережевих інтерфейсів для кожної підмережі DMZ, відобразила маршрути, внесені в таблиці маршрутизації усіх маршрутизаторів корпоративної мережі, забезпечила “вихід” вузлів корпорації в INTERNET, забезпечила централізоване вирішення символьних імен усіх Hosts ККМ у відповідні їм IP-адреси. Створила розподілену систему збереження даних на основі DNS та забезпечила доступ до цих даних з будь-якого хоста мережі, провела моделювання розробленої корпоративної мережі у середовищі Packet Tracer.
16.03.2013 23:03-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора