Телекомунікаційні мережі. Лекція з Інші. Робота № 300322

Перехід до торгівельного партнера Binance

Телекомунікаційні мережі

Інформація про навчальний заклад

ВУЗ:

Національний університет Львівська політехніка

Інститут:

Не вказано

Факультет:

Не вказано

Кафедра:

Телекомунікації

Інформація про роботу

Рік:

2002

Тип роботи:

Лекція

Предмет:

Інші

Завантажити

Частина тексту файла (без зображень, графіків і формул):

Міністерство освіти і науки України Національний університет “Львівська політехніка” Кафедра “Телекомунікації” М. Павликевич ТЕЛЕКОМУНІКАЦІЙНІ МЕРЕЖІ 3 мережІ IP Лекції для студентів cпеціальності 7.092402 “Інформаційні мережі зв’язку” Львів, 2002 Зміст TOC \o "1-4" ТЕЛЕКОМУНІКАЦІЙНІ МЕРЕЖІ PAGEREF _Toc19542554 \h 1 3.1. Коротка історія Internet та IP-технологій PAGEREF _Toc19542555 \h 5 3.2. Модель TCP/IP. PAGEREF _Toc19542556 \h 7 3.3. Потреба в проектуванні IP-мереж PAGEREF _Toc19542557 \h 8 3.3.1. Проектування IP-мережі PAGEREF _Toc19542558 \h 9 3.3.1.1. Загальний погляд на проектування. PAGEREF _Toc19542559 \h 9 3.3.1.2. Етапи проектування мережі PAGEREF _Toc19542560 \h 10 3.3.1.3. Розгляд застосувань PAGEREF _Toc19542561 \h 11 3.3.1.4. Розгляд платформ. PAGEREF _Toc19542562 \h 13 3.3.1.5. Розгляд мережевої інфраструктури. PAGEREF _Toc19542563 \h 14 3.3.1.6. Ідеальна мережа PAGEREF _Toc19542564 \h 14 3.4. IP-адресація PAGEREF _Toc19542565 \h 14 3.4.1. Структура IP-адреси. PAGEREF _Toc19542566 \h 14 3.4.2. Повнокласова та безкласова IP-адресація PAGEREF _Toc19542567 \h 15 3.4.2.1. Структура IP-адрес при повнокласовій адресації. PAGEREF _Toc19542568 \h 15 3.4.2.2. Використання мережевої маски. PAGEREF _Toc19542569 \h 18 3.4.2.3. Безкласова IP-адресація PAGEREF _Toc19542570 \h 18 3.4.3. Мережі та підмережі. PAGEREF _Toc19542571 \h 19 3.4.3.1. Спосіб впровадження підмереж. PAGEREF _Toc19542572 \h 19 3.4.3.2. Розширений мережевий префікс і мережева маска. PAGEREF _Toc19542573 \h 21 3.4.3.3. Організація підмереж – складання адресного плану PAGEREF _Toc19542574 \h 21 3.4.3.4. Загальні правила побудови адресного плану мережі з підмережами. PAGEREF _Toc19542575 \h 23 3.4.3.5. Нові розв’язання для масштабування адресного простору Internet. PAGEREF _Toc19542576 \h 24 3.4.3.6. Мережеві маски змінної довжини. PAGEREF _Toc19542577 \h 24 3.4.3.7. Впровадження CIDR PAGEREF _Toc19542578 \h 27 3.4.3.8. Раутінг у безкласовому середовищі. PAGEREF _Toc19542579 \h 29 3.5. Трансляція мережевих адрес PAGEREF _Toc19542580 \h 30 3.5.1. Статична NAT. PAGEREF _Toc19542581 \h 31 3.5.2. Динамічна NAT . PAGEREF _Toc19542582 \h 32 3.5.3. Динамічна NAT з перевантаженням. PAGEREF _Toc19542583 \h 34 3.5.4. Динамічна NAT з надлишковими зовнішніми інтерфейсами. PAGEREF _Toc19542584 \h 35 3.5.5. NAT всередині локальних адрес. PAGEREF _Toc19542585 \h 36 3.5.6. Динамічна NAT з трансляцією номерів портів для глобальної адресації. PAGEREF _Toc19542586 \h 36 3.5.7. Спільне використання статичної та динамічної NAT. PAGEREF _Toc19542587 \h 37 3.5.8. Переваги та недоліки NAT PAGEREF _Toc19542588 \h 38 3.6. Відповідність між MAC-адресами та IP-адресами. PAGEREF _Toc19542589 \h 38 3.6.1. Протоколи високого рівня і MAC-адреси. PAGEREF _Toc19542590 \h 38 3.6.2. Протокол ARP. PAGEREF _Toc19542591 \h 38 3.6.3. Протокол RARP (Reverse Address Resolution Protocol) PAGEREF _Toc19542592 \h 40 3.7. Пересилання данограм. PAGEREF _Toc19542593 \h 41 3.7.1. Концепція пересилання данограм. PAGEREF _Toc19542594 \h 41 3.7.2. IP-данограма. PAGEREF _Toc19542595 \h 41 3.7.2.1. IP-данограма та її формат. PAGEREF _Toc19542596 \h 41 3.7.2.2. Опції данограми. PAGEREF _Toc19542597 \h 43 3.7.1. Інкапсуляція, фрагментація та реасемлювання данограми. PAGEREF _Toc19542598 \h 46 3.7.1.1. Інкапсуляція данограми. PAGEREF _Toc19542599 \h 46 3.7.1.2. Фрагментація данограми. PAGEREF _Toc19542600 \h 46 3.7.1.3. Реасемблювання данограми. PAGEREF _Toc19542601 \h 48 3.8. Протокол повідомлень управління ICMP PAGEREF _Toc19542602 \h 49 3.8.1. Повідомлення ICMP PAGEREF _Toc19542603 \h 49 Коротка історія Internet та IP-технологій У 1960-х та 1970-х роках багато різних мереж вживало власні протоколи і їх впровадження. Спільне використання інформації через ці мережі становило проблему, тому виникла потреба опрацювання спільного протоколу. При опрацювання такого спільного протоколу і системи протоколів ARPANET була впроваджена фундаментальна концепція розшарування. З використанням TCP/IP була створена мережа, яка головним чином використовувалася для потреб урядових організацій та науково-дослідних інститутів і дозволяла спільне використання інформації та співпрацю при дослідженнях. У 1974 році Vinton G. Cerf і Robert E. Kahn запропонували систему протоколів TCP/IP (Transmission Control Protocol/Internet Protocol). Система протоколів TCP/IP, яка походить від протоколів ARPANET, в основному оформилася у 1978 році і забезпечує такі вимоги: здатність до маршрутування даних між підмережами; незалежність від технології у підмережах; незалежність від типу обладнання станцій; незалежність від операційних систем; стійкість до помилок маршрутів у підмережах; надійне відновлення при відмовах; здатність до поповнення новими підмережами і утримання зв’язку. Назва цієї системи походить від назв двох найважливіших протоколів: протоколу управління пересиланням (Transmission Control Protocol – TCP) та протоколу взаємосполучення мереж (Internet Protocol – IP). Іншою назвою є система інтернет-протоколів, яка вживається у офіційних документах Internet. Першою метою створення системи протоколів TCP/IP є побудова взаємосполучення (об’єднання) мереж, яке забезпечує універсальні телекомунікаційні послуги (interconnected network, internetwork або internet). Кожна фізична мережа має власний комунікаційний інтерфейс, залежний від застосованої мережевої технології, який у формі програмного інтерфейсу забезпечує основні комунікаційні функції. Комунікаційні послуги здійснюються програмами, які діють між фізичною мережею та застосуваннями користувача, що забезпечує спільний інтерфейс для цих застосувань, незалежний від базової фізичної мережі. При цьому архітектура фізичної мережі невидима для користувача. Другою метою створення системи протоколів TCP/IP є взаємосполучення різних фізичних мереж у формі, яка дозволяє користувачу працювати в єдиній великій мережі – internet. Щоб об’єднати дві мережі, потрібен комп’ютер, сполучений з обидвома мережами, який може пересилати пакети від одноїх мережі до іншої. Такий комп’ютер називають раутером або маршрутизатором. Також вживають термін IP-раутер, бо функція раутінгу (маршрутизації) є частиною IP-рівня системи протоколів TCP/IP. З точки зору мережі раутер – це звичайна станція, з точки зору користувача раутер невидимий, бо користувач бачить тільки одну велику мережу. Об’єднання мереж у глобальному масштабі називають Internet (з великої літери). Internet – це система доручення пакетів, які переносять інформацію для користувачів. Internet базується на декількох основних ідеях. Ідея 1. Будь-яка станція, під’єднана до Internet, має унікальний 4-байтовий ідентифікатор, який називають IP-адресою. Ідея 2. Дані, які пересилаються через Internet, спочатку ділять на малі блоки – пакети або IP-данограми. Пакет складається з двох частин – заголовка і корисного навантаження. Заголовок містить, зокрема, IP-адресу призначення пакету. Ідея 3. Internet складається з багатьох мереж, взаємосполучених через спеціалізовані комп’ютери - раутери. Коли пакет висилається до Internet, то він пересилається через локальну мережу до першого раутера, який також називають шлюзом. Цей раутер перевіряє адресу призначення пакету і вирішує, котрий раутер з бепосередньо під’єднаних до нього, може переслати пакет до раутера наступного стрибка. Процес продовжується наступними раутерами, аж доки пакет досягне свого призначення. Цей процес визначений протоколом IP. Ідея 4. Доручення пакетів за допомогою протоколу IP ненадійне. Це не означає “погане доручення” або “доручення з низькою якістю”. Це означає, що система доручення може відмовити у коректному дорученні пакету внаслідок, наприклад, впливу електричних завад. Однак більшість пакетів доручаються коректно, бо в концепції Internet закладено засаду найкращого можливого (best effort) доручення за нормальних умов. Ненадійність виявляється, наприклад, при надмірному завантаженні мережі. Ідея 5. Для забезпечення надійного доручення на краях системи впроваджено протокол TCP. Його завдання полягає у перетворенні послуг ненадійного доручення, які здійснює протокол IP, у надійну систему пересилання даних, придатну для побудови мережевих застосувань. Це називають транспортними послугами. Тут використовують поняття прикінцевої системи (end system) або станції (host). Звичайно це комп’ютери, під’єднані до Internet (не раутери). Два об’єкти TCP впроваджені у двох прикінцевих системах, безпосередньо комунікуються один з одним, використовуючи ненадійне комунікаційне середовище – Internet. Об’єкти TCP комунікуються, обмінюючись сегментами. Сегмент TCP – це частина даних застосування разом з невеликим службовим навантаженням – заголовком TCP, який поміщається (інкапсулюється) в IP-данограму. Надійність забезпечується механізмом підтвердження коректно прийнятого сегменту і повторним пересиланням сегменту, якщо таке підтвердження вчасно не отримане. В цілому послуги TCP орієнтовані на сполучення. Сполучення започатковується процесом застосування (або програмою, яка виконується), який запитує TCP про встановлення сполучення з іншим процесом застосування, що виконується у віддаленій прикінцевій системі. Ідея 6. Для сприяння комунікації між процесами TCP використовує абстрактну адресу, яку називають номером протокольного порта. Про процес, який очікує на вхідне сполучення кажуть, що він існує на певному номері порта. TCP-сполучення здійснюється до визначеного порта, бо апріорі для певної послуги передбачений конкретний протокольний порт. Протокольні порти є адресами TCP, які діють у доповнення до IP-адрес: IP-адреса визначає конкретну станцію, а номер протокольного порта конкретизує, який процес, що виконується на цій станції, потребує комунікуватися. Процес, який очікує на сполучення на конкретному порті, називають процесом сервера. Процес, який ініціює сполучення до сервера, називають процесом клієнта. В контектсі протоколу TCP ці терміни маєть специфічні значення. Ідея 7. У традиційній телефонній системі, яка базується на комутації кіл, телефонний виклик резервує коло (канал), яке забезпечує надійний двосторонній зв’язок. Мережа мусить бути побудована так, щоб забезпечити досконалу надійність від моменту встановлення сполучення (кола). Тому традиційна телефонна мережа складна і дорога, а кінцеве обладнання користувача – телефонний апарат – просте і дешеве. Internet забезпечує обернену ситуацію. Мережа, тобто система доручення, яка базується на комутації пакетів, проста, але не гарантує нічого, крім високої ймовірності доручення пакетів. Складність міститься у TCP, який діє тільки у прикінцевих системах - достатньо потужних комп’ютерах. На початку 1980-х років TCP/IP став магістральним протоколом у мережах багатьох виробників, таких як ARPANET, NFSNET та в регіональних мережах. Система протоколів була інтегрована з операційною системою UNIX Каліфорнійського університету і стала доступною для загального використання. Від цього часу TCP/IP стали широко використовувати внаслідок його наявності в UNIX та поширеністю в інших операційних системах. На сьогодні стек протоколів TCP/IP забезпечує можливості для співпраці, об’єднуючи різні фізичні мережі та надаючи користувачам спільну множину функцій. Він дозволяє взаємодію між обладнанням від різних виробників, різних платформ і забезпечує доступ до Internet. Сьогодні Internet складається з великих міжнаціональних, національних і регіональних магістральних мереж, які дозволяють локальним і кампусовим мережам, а також окремим особам мати доступ до глобальних ресурсів. Використання Internet експоненціально зростає протягом останніх років, особливо у комерційних застосуваннях. Це обумовлене як наявністю спільних функцій застосувань для різних платформ і можливістю доступу до Internet, так і передовсім можливостями взаємодії. Відкритість стандартів TCP/IP дозволяє корпораціям з’єднувати або об’єднувати різні платформи, наприклад, комп’ютери IBM і Macintosh. TCP/IP також забезпечує транспорт для інших протоколів – IPX, NetBIOS і т.п. Наприклад, ці протоколи можуть вживати мережу TCP/IP для сполучення з іншими мережами з подібними протоколами. Іншою підставою для поширення TCP/IP є популярність програмного інтерфейсу гнізд (socket programming interface), який є програмним інтерфейсом між рівнем транспортних протоколів та застосуваннями TCP/IP. Багато застосувань на сьогодні написані саме для інтерфейсу гнізд TCP/IP. Процес RFC (Request For Comments) під наглядом IAB (Internet Architecture Board) та IETF (Internet Engineering Task Force) здійснюють постійну модернізацію і розширення системи протоколів TCP/IP. Модель TCP/IP. У той час, як протоколи OSI розвиваються повільно, головним чином внаслідок їх формального, базованого на комітетах, інженерного підходу, система протоколів TCP/IP швидко розвивається і визріває. З політикою впровадження і модифікації системи протоколів RFC він встановився як кращий протокол для більшості комунікаційних мереж. Як еталонна модель OSI і більшість інших комунікаційних протоколів для даних, TCP/IP є стеком протоколів, який складається з чотирьох рівнів (рис. 3.1). EMBED Visio.Drawing.5 Рис. 3.1. Стек протоколів TCP/IP. Рівень застосувань – це процеси користувача, пов’язані з іншими процесами в тій самій або іншій станції. Він забезпечується програмами користувача, які вживають TCP/IP для комунікації. Прикладами поширених застосувань, які використовують TCP/IP, є Telnet – протокол для віддаленого сполучення терміналів, FTP – протокол пересилання файлів, SMTP - протокол пересилання електронної пошти. Існує багато інших, але це основні застосування. За винятком ping (який є простим засобом діагностики – протокол висилає пакет і визначає, чи отримане ехо-відповідь від призначення, щоб визначити досяжність призначення і як довго пакет слідує до призначення і назад), інші застосування є застосуваннями типу “клієнт-сервер”. Файли пересилаються до/від сервера від/до клієнта,електронна пошта висилається від клієнта до поштового сервера, читається із цього сервера клієнтом-приймачем; віддалене управління портом станції фактично є управлінням портом telnet-сервера з боку telnet-клієнта. Для таких застосувань кожен клієнт виконує “клієнтську програму”, тоді як сервер –“серверну програму”. Програми застосувань клієнта і сервера взаємодіють, спочатку для відкриття сесії (повідомлення про реєстрацію, адреса або назва ресурсу, доступ до якого портібний), потім для створення передавального і приймального буферів для сесії у клієнта і сервера, а також для встановлення правильних параметрів подання (кодування, шифрування, компресії, формату друку тощо). Як тільки ця фаза завершеня, то викликається рівень пакування-розпакування – Трансортний рівень. Інтерфейси між Рівнем застосувань і Транспортним рівнем визначені номерами протокольних портів і гніздами (sockets). Транспортний рівень забезпечує наскрізне пересилання даних. Він відповідає за надійний обмін інформацією. В дійсності протоколи Транспортного рівня фізично не переміщають даних, вони тільки здійснюють їх упакування і розпакування. Програми і апаратура для переміщення даних викликаються цими протоколами для виконання властивих їм завдань. Головним транспортним протоколом є TCP (Transmission Control Protocol – протокол управління пересиланням). TCP - це складний повнодуплексний протокол, який здійснює послуги зі встановленням сполучення. Він розділяє файл, що підлягає пересиланню, на частини, які називають “сегментами”. Сегмент TCP складається із заголовка і даних, пов’язаних із ним. Порти джерела і призначення використовуються для визначення номерів сесій клієнта і сервера. Для кожного сегменту його місце у послідовності визначається висиланням спеціального пакету TCP і підтвердженням через отримання відповідного TCP-пакету. При висиланні пакетів TCP управління потоком сегментів керується призначенням “вікна”, яке має стільки бітів, скільки передавач може вислати водночас. Крім того, TCP може позначати дані як “термінові” або як “зовнішньо-термінові/слід_вислати”, і погоджувати максимальний розмір сегменту. Сегменти висилаються послідовно, перевіряються за допомогою циклічної контрольної суми (CRC); при виявленні помилок вимагається повторне пересилання. Порядковий номер сегменту TCP у послідовності, номер підтвердження, CRC, прапорці портів призначення і джерела, а також опції поміщені перед даними у заголовку сегменту. Іншим протоколом Транспортного рівня є UDP (User Datagramm Protocol – протокол данограм користувача), який забезпечує послуги без встановлення сполучення. UDP – це дуже простий протокол, який пов’язує заголовок із даними, що складаються із номерів портів призначення і джерела та CRC, і пересилає дані одним пакетом (данограмою) без контролю послідовності або помилок. Це означає, що застосування, які вживають UDP як транспортний протокол, повинні забезпечувати власне наскрізне управління потоком. Звичайно UDP вживають для застосувань, які потребують швидкого механізму транспорту. Рівень об’єднання мереж, який також називають Рівнем internet або Мережевим рівнем, забезпечує образ віртуальної мережі для об’єднання мереж (internet), є найвищим рівнем для типової мережевої архітектури, розташованої під цим рівнем, і відділяє фізичну мережу від рівнів понад нею. Найважливішим протоколом цього рівня є IP (Internet Protocol). Це протокол без встановлення сполучення, який не передбачає надійності нижніх рівнів. IP не забезпечує надійності, управління потоком або виправлення помилок. Ці функції повинні бути передбачені на вищих рівнях, зокрема, на Транспортному рівні при використанні TCP, або на Рівні застосувань, якщо вживається UDP. Одиницею повідомлення в IP-мережі є данограма. Це основний інформаційний блок, який пересилається через мережу TCP/IP. У стеку протоколів IP забезпечує функції раутінгу для розподілу цих данограм до коректних приймачів (адресатів). Спосіб, у який працює протокол IP, полягає в наступному. У станції-джерелі TCP або UDP сегментують повідомлення і передають сегменти до IP. Протокол IP поміщає сегменти в данограми, дописуючи IP-заголовок, і пересилає данограми до “раутера за замовчуванням” (який в TCP/IP називають шлюзом). Раутер перевіряє заголовок кожної данограми і порівнює IP-адресу призначення з адресами мереж, які знаходяться під контролем цього раутера. Якщо адреса узгоджується, то раутер приймає пакет і пересилає його до мережі, в якій розташована станція-призначення. Якщо ні, то раутер перевіряє свою таблицю раутінгу для знаходження раутера наступного стрибка, до якого пересилає (маршрутує) данограму. Останній раутер, тобто той, який встановив відповідність адреси призначення своїй мережі, доручає данограму до станції-призначення. При цьому раутер використовує таблицю відповідності IP-адрес MAC-адресам станцій в мережі. Це таблиця протоколу розв’язування адрес (Address Resolution Protocol - ARP). Якщо потрібної адреси нема в таблиці, то раутер висилає ARP-запит, отримує ARP-відповідь про MAC-адресу потрібної станції та заносить її у таблицю. Іншими протоколами Рівня internet є ICMP, IGMP та RARP. Рівень мережевого інтерфейсу, який також називають Канальним рівнем, є здійснює інтерфейс до наявного мережевого обладнання (Фізичного рівня). Цей рівень також не гарантує надійного доручення даних; він може бути орієнтованим на пакети або потоки. TCP/IP не визначає жодного конкретного протоколу для цього рівня. Він може використовувати будь-який наявний мережевий інтерфейс, реалізуючи цим гнучкість мережі і сумісність з наявною інфраструктурою. Прикладами протоколів мережевого інтерфейсу, які підтримуються, є IEEE 802.3, Ethernet, X.25 (який є надійним сам по собі), Frame Relay, ATM. Канальний і Фізичний рівні фактично здійснюють транспорт даних. Потреба в проектуванні IP-мереж Якщо планування мережі не здійснювалося, то звичайне взаємосполучення з використанням TCP/IP може створити ряд проблем. Тому заздалегід необхідно вказати на ці проблеми і вияснити суть рішень, які слід зреалізувати для впровадження розв’язань TCP/IP. Наприклад, відсутність ефективного планування розподілу мережевих адрес може призвести до значних обмежень кількості станцій, які можна під’єднати до мережі. Відсутність централізованої координації веде до дублювання найменувань та адрес ресурсів, що не дозволить об’єднати ізольовані мережі. Неузгодженість адрес може заважати під’єднанню до Internet. Інші можливі проблеми включають відсутність трансляції імен ресурсів в їх адреси, оскільки відсутнє сполучення зі серверами імен тощо. Окремі проблеми, які виникли внаслідок неправильного спроектованої або неспланованої мережі, можна просто виправити, але деякі вимагають значного часу і зусиль для корекції. Важко здійснити, наприклад, переконфігурування вручну декількоїх сотень чи тисяч станцій в мережі, якщо схема адресації не відповідає потребам організації. Коли розглядаються завдання проектування нової мережі або можливості під’єднання наявної мережі, то виникають окремі важливі питання, які необхідно розв’язати. Наприклад, як розподілити адреси мережевих ресурсів, як змінити наявні адреси, чи вибрати статичний, чи динамічний раутінг, як сконфігурувати сервер імен і як захистити мережу. В той сам час слід вирішити питання надійності, доступності і резервування, а також питання адміністрування та управління мережею. Проектування IP-мережі Внаслідок простоти та гнучкості IP, мережі можуть бути з’єднані між собою невпорядкованим чином. Це поширений спосіб сполучення мереж і вони можуть добре працювати. Якщо масштаб мереж невеликий. Проблеми виникають тоді, коли необхідно внести зміни, а документація відсутня. IP-мережа, яка не була систематично спроектована, неодмінно створює проблеми від початку стдії впровадження. Коли модернізується чинна мережа, то звичайно наявні інші чинні мережі. Які необхідно під’єднати.Впровадження нової технології без вивчення обмежень наявної мережі також може вести до появи непередбачених проблем. Тому проектування мережі слід здійснювати перед будь-яким впровадженням. Проект мережі повинен постійно переглядатися, коли протягом певного часу змінюються вимоги. Добрий проект включає детальну документацію мережі, потрібну для наступних посилань. Добле спроектовані мероежі прості для впровадження і створюють небагато несподіванок. Методика проектування. Рекомендованою методикою проектування IP-мереж є підхід “зверху вниз”. Ця технологія слідує стеку протоколі TCP/IP. Як видно з рис. , зверху стеку розташований рівень застосувань, тому він єпершим рівнем, який розглядається при проектуванні IP-мережі. Наступні два рівні – це Транспорнтий і Мережевий, а Канальний рівень є останнім. Проектування застосувань визначається потребами організації. Правила діяльності організації, потоки процесів, вимоги безпеки і очікувані результати перетворюють у специфкації застосувань. Ці вимоги не тільки впливають на проектування застосувань, але суттєво відчутні на всіх нижчих рівнях. Як тільки вимоги до Рівня застосувань визначені, то з них слідують вимоги до нижчих рівнів. Наприклад, якщо Рівень застосувань містить програму, яка вимагає двосекундного часу реакції на будь-яку мережеву транзакцію, то у проекті IP-мережі слід взяти це до уваги і вважати оптимізацію характеристик мережі найвищим пріоритетом. Канальний рівень повинен бути спроектований таким чином, щоб ці вимоги могли бути дотримані. При цьому використання плоскої моделі мережі з сотнями станцій, базованих на Windows, не є ідеальним вирішенням. Коли проектування IP-мережі завершене у погодженні з Рівнем застосувань, розпочинається її впровадження. Проектування мережевої інфраструктури відіграє важливу роль і має визначальний вплив на загальний проект. Добрим прикладом є модульність і масштабованість всієї мережі. Нижче наведені основні аспекти проектування IP-мережі. Загальний погляд на проектування. Масштабованість. Добре спроектована IP-мережа масштабується, тобто може зростати при збільшенні вимог до неї. Під’єднання нових станцій, серверів або мереж не повинне вимагати повного перепроектування мережевої топології. Зміни топології можуть з’являтися внаслідок пристосування до зросту вимог організації. Вікриті стандарти. Цілий проект і компоненти, з якиїх складається мережа, повинні базуватися на відкритих стандартах. Відкриті стандарт гарантують гнучкість, необхідну для сполучення різних пристроїв від різних виробників. Власні вирішення можуть бути придатні на короткий час, однак їх тривале застосування може обмежувати можливості внесення змін і може ускладнювати знаходження спільних технологій. Доступність і надійність. Потреби організації безумовно вимагають певного рівня доступності та надійності мережі. Бізнес-система (наприклад, у торгівлі), яка гарантує час реакції для транзакцій у три секунди, не може працювати, якщо мережа не функціонує три зі семи днів у тижні. При проектуванні мережі слід враховувати середній час між відмовами мережі, а також середній час ремонту. Проектування логічної надлишковості мережі є так само важливе, як фізична надлишковість. Це важко здійснити під час стадії впровадження. Модульність. Важливою концепцією є модульний підхід при побудові мережі. Модульність ділить складну систему на малі керовані блоки, що спрощує впровадження. Модульність також дозволяє ізолювати відмову у певній частині мережі, так що вона не спричиняє зупинку всієї мережі. Модульність спрощує розширення мережі. Наприклад, додавання нового мережевого сегменту або нових застосувань до мережі не вимагатиме переадресації всіх станцій. Безпека. Безпека мережі організації є важливим аспектом проектування, зокрема тоді. Коли мережа має доступ до Internet. Аналіз ризиків і вживання заходів для їх зменшення на етапі проектування IP-мережі суттєве для повної впевненості в мережі. Розгляд питань безпеки на пізніх стадіях робить мережу доступною для атак, доки “дірки” в захисті не закриті, тому такий підхід може бути значно коштовніший. Хоч нові “дірки” в захисті можуть бути виявлені пізніше, основні проблеми захисту простіше впроваджувати на стадії проетування. Управління мережею. Управління мережею не повинно розглядатися після побудови мережі. Воно важливе, бо забезпечує шляхи для моніторингу завантаженості мережі, для встановлення умов виконання операцій, для ізолювання відмов і конфігурування пристроїв при внесенні змін. Впровадження структур управління повинне бути інтегроване у процес проектування мережі від самого початку, бо спрби ввести структури управління у спроектовану і впроваджену мережу ведуть до виникнення небажаних проблем. Характеристики. Існують два типи характеристик, які повинні бути враховані при проектуванні мережі. Це вимоги до перепускної здатності мережі і до часу відгуку (затримки). Масштабованість мережі також повинна враховувати вимоги до характеристик. Економічні питання. Збалансування вимог організації до мережі і коштів, які можуть бути виділені для її створення є найбільш складним питанням при проектуванні мережі, яке вирішується шляхом компромісу. Етапи проектування мережі Нижче викладено суть структурованого підходу до проектування IP-мереж. Основні етапи процесу проектування показані на рис. 3.2. EMBED Visio.Drawing.5 Рис. 3.2. Етапи проектування мережі. Визначення цілей мережі. Цей етап проектування вимагає проведення досліджень і може бути тривалим. При цьому слід розглянути такі питання: Хто є користувачами IP-мережі і якими є їх потреби? Які застосування повинні підтримуватися? Чи IP-мережа заміняє чинну комунікаційну систему? Які кроки міграції необхідно розглянути? Якими є конкретні вимоги, загалом сформульовані вище в п. “Загальний погляд на проектування”? Хто відповідає за управління мережею? Чи мережа повинна бути поділена на більш керовані сегменти? Яким є час інснування мережі? Яким є бюджет? Збір інформації для проектування. Інформація, неоюхідна для побудови мережі, залежить від кожного індивідуального впровадження, однак основні види потрібної інформації можуть бути виведені з “Загального погляду на проектування”. Важливо зібрати цю інформацію і витратити дещо часу на її аналіздля зрозуміння вимог середовища і обмежень перед проектуванням нової IP-мережі. Формування пропозицій або специфікацій. Після збору інформації та визначення цілей мережі можна сформулювати пропозиції, які потім можуть бути оптимізовані. Міркування щодо проекту можуть надавати перевагу одній цілі за рахунок інших. Наприклад, мережа може бути оптимізована за характеристиками, за стійкістю до відмов, за захищеністю. Коли пріоритети для проектування визначені, можна створювати і документувати проект. Огляд. Останнім етапом процесу проектування є огляд проекту перед впровадженням. На цьому етапі проект може бути модифікований, перш ніж здійснено інвестиції в інфраструктуру або в роботи з впровадження. Коли цей етап завершено, переходять до впровадження. Розгляд застосувань Як вказано вище, найвищим рівнем TCP/IP є Рівень застосувань. Елементи, які містяться на цьому рівні, визначаються потребами організації і ці компоненти повинні розглядатися як дуже важливі при початковому розгляді проекту в методиці проектування “зверху вниз”. Існує цілий ряд питань, які слід розглянути, при чому окремі з них є спільними для всіх застосувань, тоді як інші стосуються тільки до підмножини застосувань. Ці питання повинні бути визначені та опрацьовані. Вимоги до ширини смуги. Різні застосування потребують різного обсягу смуги мережі. Очевидно, що застосування, які повинна підтримувати мережа, визначають тип мережі, яка буде остаточно спроектована. Не слід проектувати мережу без розгляду того, які застосування потрібні негайно, а які будуть потрібні в майбутньому. Вимоги до характеристик. Слід розглянути вимоги до характеристик мережі від її користувачів. Користувачі мережі можуть допускати більший час відгуку від HTTP- або FTP-застосувань, але можуть не сприймати змін затримок (jitter) при пересиланні голосу через IP (VoIP), оскільки це викликає спотворення звуку. Також слід враховувати величину затримки при пересиланні трафіку. Великі затримки неприйнятні для застосувань, які оперують потоками даних, таких, як відео через IP. Правильність, з якою мережа здатна забезпечити дані для застосувань, також відноситься до проеткування мережі. Різна інфраструктура забезпечує різні рівні правильності для мережі. Необхідні протоколи. Рівень застосувань TCP/IP підтрмує постійно зростаючу кількість протоколів. Основним при виборі протоколу для застосувань є те, чи застосування використовує TCP, чи UDP. TCP здійснює послуги віртуальних кіл, тоді як UDP – послуги данограм. UDP швидше доручає мережевий відгук власлідок того, що відсутнє службове навантаження від заголовку TCP, однак він не має надійності TCP, властивостей управління потоком і корекції помилок. Якість послуг і тип послуг. Якість послуг (Quality of Service – QoS) і тип послуг (Type of Service – ToS) з’являються з одної причини – певні дані користувачів “важливіші” від інших і повинні бути обслужені у першу чергу. Вимоги до QoS і ToS включені в застосування і мають вплив на проектування мережі. Пристрої для сполучення, такі як раутери і комутатори, повинні мати можливість першочергового доручення інформації для підтримки вимог застосування. Окремі застосування, такі як VoIP або системи впорядкування (сортування)інформації повинні працювати в режимі реального часу. Для них мережа повинна гарантувати рівень послуги. Застосування реального часу можуть потребувати впровадження власного управління потоками та виправлення помилок, якщо вони використовують UDP як транспортний протокол. Вимоги застосувань реального часу можуть також мати вплив на впровадження мережевої інфраструктури. Нариклад, мережа ATM може повністю задовільнити ці вимоги, тоді як мережа Ethernet зі спільним використанням середовища (протокол CSMA/CD) не може їх задовільнити. Чутливість до втрат пакетів і затримок. Чутливість застосувань до втрат пакетів і затримок може мати драматичний вплив на користувача. Мережа повинна забезпечувати надійне доручення пакетів для таких застосувань. Наприклад, застосування реального часу з малою буферизацією не допускає затримок в дорученні пакетів, але поодинокі пакети втрачаються. VoIP є одним з прикладів таких застосувань,на відміну від перегляду Web. Багатоадресне пересилання. Доказано, що багатоадресне пересилання (multicastang) – це добрий засіб для ощадності ширини смуги мережі, якщо вона правильно впроваджена. Впровадження багатоадресності залучає до тісної співпраці всі пристрої для сполучення, такі як раутери та комутатори, застосування, клієнтські операційні системи і сервери. Багатоадресне пересилання не може працювати, якщо кожна з цих підсистем не буде дотрмуватися вимог або якщо вони мають жорсткі обмеження. Оснащення дорученнями. Наявність протоколів застосувань, які здійснюють доручення (proxyed), має вплив на вимоги до ширини смуги і на безпеку мережі. Так, застосування HTTP можуть бути просто керовані, коли для безпеки зінстальована “пожежна стінка” (firewall), бо послуги за дорученням (proxy) можуть бути розташовані поза пожежною стінкою в “демілітаризованій зоні” для обслуговування трафіку HTTP через пожежну стінку до застосувань. Однак для застосувань, базованих на протоколі TELNET, це не так просто. Протокол TELNET не підтрмує послуг за дорученням для свого трафіку. Тому або пожежна стінка повинна залишатися відкритою для цього порта, а застосування повинні використовувати сервер SOCK, або застосування не зможуть комунікуватися через пожежну стінку. Потреба у директоріях. Різні застосування вимагають послуг директорій в IP-мережі. Послуги директорій включають DNS (Domain Name Service – послуга доменних імен), NIS, LDAP, X.500, DCE (Distributed Computing Environment – середовище розподілених обчислень) і, можливо, інші. Вибір послуг директорій залежить від підтримки застосувань цими послугами. Наприклад, застосуванням, базованим на стандарті ITU X.500, мало відповідають мережі, яка мають тільки сервери DNS. Певні застосування, базовані на протоколах PING та TFTP, не вимагають послуг директорій для свого функціонуванняч, хоч без цього складнощі з їх вживанням можуть значно зрости. Інші застосування безумовно вимагають послуг директорій, наприклад, електронна пошта, базована на протоколі SMTP. Розподілені застосування можуть вимагати певного рівня послуг від IP-мережі. Ці послуги повинні поставлятися мережею, тому вони мусять бути враховані при її проектуванні. Наприклад, Distributed Computing Environment – середовище розподілених обчислень забезпечує платформу для побудови і використання розподілених застосувань, пов’язаних з такими послугами, як послуга директорії комірок (Cell Directory Service – CDS), послуга глобальної директорії (Global Direcriry Service – GDS), послуга захисту ( Security Service), DCE Threads, послуга розподілу часу (Distributed Time Service – DTS) і послуга розподілених файлів (Distributed File Service – DFS). Ці послуги роблять доступними через мережу, тобто колективними, і вони забезпечують основу захищеного ядра для середовища DCE. Масштабованість. Застосування, які вимагають масштабованості, повинні мати мережу, здатну задовільнити їх майбутні потреби, або придатну до модернізації. Якщо застосування спроектовані модульно, то мережа також повинна бути модульною. Безпека. Безпека застосувань забезпечується протоколами, розташованими нижче, або самими застосуваннями. Наприклад, якщо застосування вживає протокол UDP на Транспортному рівні, то воно мусить використовувати власне шифрування і забезпечити власні потреби захисту. Розгляд платформ. Важливим кроком до побудови застосувань є вибір платформ для застосувань. Слід відповісти на деякі основні питання: Чи робоча станція підтримує графіку, чи тільки текст? Чи робоча станція відповідає основним вимогам щодо характеристик – швидкість процесора, обсяг пам’яті, дисковий простір тощо? Чи робоча станція має можливості для під’єднання до мережі, які відповідають вимогам? Відповіді на наступні запитання можуть бути потрібні , якщо опрацьовуються застосування для робот під стеком TCP/IP: Чи робоча станція підтримує потрібну карту мережевого інтерфейсу? Мультимедійні застосування можуть потребувати використання мережі ATM, однак не всі робочі станції підтримують мережеві карти ATM. Чи ця карта відповідає застосованій кабельній системі? Сучасні мережеві карти мають порт для під’єднання до кабельної системи UTP, однак може бути потрібне під’єднання до багатомодового оптичного кабеля. Чи мережева карта оснащена потрібним драйвером? Чи операційна система станції підтрмує TCP/IP? Існують різні варіанти впроваджень TCP/IP. Добрим прикладом є Classical IP (CIP) та емуляція LAN (LANE) при використанні мережі ATM. Певні операційні системи можуть підтримувати тільки CIP. Чи стек TCP/IP підтримує підмережі? Не всі системи підримують підмережі, особливо старі системи. Чи операційна система підтримує потрібні API? Поширений спосіб побудови застосувань в TCP/IP полягає у використанні програмування гнізд (sockets), однак стек TCP/IP на робочій станції може не повністю підтримувати це програмування. Це особливо небезпечно в мережах з різними типами робочих станцій, які оснащені різними операційними системами. Чи операційна система підтримує декілька маршрутів за замовчуванням (default routes)? Деякі операційні системи (наприклад, Windows 95) не підтримують декількох маршрутів за замовчуванням. Це може бути серйозним пунктом відмови для деяких цільових застосувань. Чи операційна система підтримує багато визначень DNS? Якщо клієнти здатні мати тільки одне визначення DNS, то потрібні опції повинні бути вбудовані в сервер DNS. З другого боку, коли клієнти здатні підтримувати багато DNS, то застосування мусить підтримуватися API, які забезпечують таку можливість. Чи операційна система підтримує багатоадресні пересилання? Це може бути потрібне для доручення відео до користувачів, що дозволяє ощадно використовувати смугу мережі. Однак не всі клієнти підтримують багатоадресні пересилання. Чи операційна система підтримує новітні властивості, такі як протокол резервування ресурсів (Resource Reservation Protocol – RSVP)? Розгляд мережевої інфраструктури. Застосування потребують транспотного механізму для поширення інформації, пересилання даних і висилання запитів для окремих послуг. Транспортний механізм забезпечується нижчим рівнем, який називають Рівнем мережевої інфраструктури або Мережевим рівнем (internet). Побудова мережевої інфраструктури вимагає прийняття ряду рішень, для чого слід відповісти на такі запитання: Які технології слід вилучити? Які технології слід використати для LAN? Які технології слід використати для WAN? Як їх використати разом? Чи вживається комутація? Як повинен виглядати проект мережі? Яке обладнання потрібне? Яким повинне бути зростання мережі? Скільки може коштувати мережа? Як керувати мережею? Яким повинен бути графік впровадження мережі? Яку стратегію прийняти? Ідеальна мережа Що слід вважати ідеальною мережею? Якщо менеджер мережі призначений для побудови мережі організації, то він повинен знати, як уникнути всіх проблем, вказаних вище. Він повинен використати найкраще обладнання і вибрати найкращу з можливих мережевих технологій. Однак все ще неясно, чи побудована мережа буде досконалою. В дійсності ідеальна мережа не існує. Проектування мережі базується на сьогоднішніх вимогах, які можуть не відповідати майбутнім. Середовище діяльності організації змінюється і це має наростаючий вплив на інфраструктуру. Очікувана кількість службовців і потреби користувачів змінюються, нові потреби адресуються застосуванням і це викликає потреби змін у мережевій інфраструктурі. Найкраще, коли мережа придатна до масштабування та адаптивна до змін. До того дня, коли будуть досягнені технічні обмеження мережі, ці два критерії залишаються доречними, після ць...

Лекція Інші

01.01.1970 03:01-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!

поділитись