Дослідження особливостей проектування мережевих додатків на базі платформи dotNet

Теоретичні аспекти проектування мережевих додатків. Опис середовища розробки Visual Studio .NET. Експериментальне дослідження та опис програмної реалізації. Опис інтерфейсу користувача. Економічне обґрунтування доцільності розробки програмного продукту.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык украинский
Дата добавления 22.10.2012
Размер файла 2,2 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Міністерство освіти та науки України

Криворізький інститут

Кременчуцького університету економіки, інформаційних технологій та управління

Кафедра Технічної кібернетики

Дипломна робота

зі спеціальності: Гнучкі комп'ютеризовані системи та робототехніка

тема: Дослідження особливостей проектування мережевих додатків на базі платформи dotNet

Кривий Ріг, 2009

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

Рідкоуса Олександра Віталійовича

(прізвище, ім'я, по-батькові)

1. Тема роботи: Дослідження особливостей проектування мережевих додатків на базі платформи dotNet затверджена наказом по інституту від " 29 " жовтня 2008 р. № 62С-01

2. Термін здачі студентом закінченої роботи 01.06.09.

3. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, довідкова інформація, матеріали наукових досліджень

4. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка задачі, Теоретичні аспекти проектування мережевих додатків. Опис середовища розробки Visual Studio .NET. Експериментальне дослідження та опис програмної реалізації. Економічне обґрунтування доцільності розробки програмного продукту. Охорона праці.

5. Перелік графічного матеріалу (з точними вказівками обов'язкових креслень)

6. Консультанти з роботи, з вказівками розділів роботи, що належать до них

Розділ

Консультант

Підпис, дата

Завдання видав

Завдання прийняв

Спеціальна частина

Старіков О.М.

Програмна частина

Мурашко А.Г.

Економічна частина

Тимко Є.В.

Охорона праці

Климович Г.Б.

7. Дата видачі завдання 31.10.08 р.

Календарний план

№ п/п

Найменування етапів дипломної роботи

Термін виконання етапів роботи

Примітки

1.

Отримання завдання на дипломну роботу

31.10.08

2.

Огляд існуючих рішень

20.02.09

3.

Теоретичне дослідження систем технологій створення тривимірних графічних додатків на базі платформи dotNET

23.03.09

4.

Програмна частина (постановка задачі, створення програмного забезпечення, опис алгоритму рішення задачі, проектування та опис інтерфейсу користувача, опис програми)

28.04.09

5.

Оформлення пояснювальної записки

14.05.09

6.

Оформлення графічної документації

25.05.09

7.

Оформлення електронних додатків до диплому

27.05.09

8.

Представлення дипломної роботи до захисту

01.06.09

Анотація

Метою дипломної роботи є дослідження особливостей проектування мережевих одатків на базі платформи dotNet. Як мова програмування для реалізації поставленого завдання була вибрана мова програмування С#, як середа розробки Microsoft Visual Studio 2008.

Аннотация

Целью дипломной работы является исследование особенностей проектирования сетевых одаткив на базе платформы dotNet. Как язык программирования для реализации поставленной задачи был выбран язык программирования C #, как среду разработки Microsoft Visual Studio 2008.

The summary

The goal is graduate study of the design of network-based platform odatkiv dotNet. As a programming language for implementation of the task was chosen programming language C # as the development environment Microsoft Visual Studio 2008.

Вступ

Метою дипломної роботи є дослідження особливостей проектування мережевих одатків на базі платформи dotNet.

Як мова програмування для реалізації поставленого завдання була вибрана мова програмування С#, як середа розробки Microsoft Visual Studio 2008. Варто відзначити, що середа розробки Microsoft Visual Studio 2008 є абсолютно безкоштовною, але не дивлячись на безкоштовність, надає безліч зручних засобів для створення складних програмних продуктів.

Якщо сказати, що мова С# і пов'язана з ним середа .NET Framework є однією з найважливіших технологій для розробників за багато років, це не буде перебільшенням. .NET спроектована як нова середа, в рамках якої можна розробити практично будь-який додаток для Windows, тоді як С# -- нова мова програмування, призначена спеціально для роботи з .NET. За допомогою С# можливо, наприклад, створити динамічну Web-страніцу, Web-службу XML, компонент розподіленого додатку, компонент доступу до бази даних, класичний настільний додаток Windows або навіть інтелектуальне клієнтське програмне забеспечення, що має засоби онлайнової і автономної роботи.

Переваги .NET:

· Об'єктно-орієнтоване програмування -- і середа .NET Framework, і С# спочатку повністю базувалися на об'єктно-орієнтованих принципах.

· Добрий дизайн -- бібліотека базових класів, яка спроектована "з нуля", виключно інтуїтивно зрозумілим чином.

· Незалежність від мови -- з .NET код всіх мов, тобто Visual Basic .NET, С#, J# і керованого C, компілюється в спільну мову проміжного рівня -- Intermediate .Language. Це означає, що всі ці мови володіють можливостями взаємодії, як ніколи раніше.

· Краща підтримка динамічних Web-страніц -- хоча ASP пропонував високий ступінь гнучкості, він також був і неефективним через свої сценарні мови, що інтерпретувалися, а недолік об'єктно-орієнтованого дизайну часто приводив до заплутаного коду ASP. .NET пропонує інтегровану підтримку Web-страніц із застосуванням нової технології -- ASP.NET. У ASP.NET код сторінок компілюється і може бути написаний на мові високого рівня, що підтримує .NET -- такому як С#, J# або Visual Basic 2005.

· Ефективний доступ до даних -- набір компонентів .NET, відомий під спільною назвою ADO.NET, надає ефективний доступ до реляційних баз даних і широкої різноманітності інших джерел даних. Також доступні компоненти, що надають доступ до файлової системи і каталогів. Зокрема, підтримка XML вбудована в .NET, що дозволяє маніпулювати даними, які можуть бути імпортовані з інших, не-Windows платформ, і експортовані в них

· Розділення коду -- .NET повністю змінила спосіб розділення коду між додатками, ввівши концепцію збірки (assembly), яка замінила традиційні бібліотеки DLL.

· Підвищена безпека -- кожна збірка також може містити вбудовану інформацію безпеки, яка в точності описує, кому і яким категоріям користувачів або процесів, які методи яких класів дозволено викликати.

· Підтримка Web-служб -- .NET пропонує повністю інтегровану підтримку розробки Web-служб.

1. Постановка завдання

1.1 Найменування та галузь застосування

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

1.2 Підстава для створення

Підставою для розробки є наказ № 62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 31.10.08. Закінчення робіт: 01.06.09.

1.3 Характеристика розробленого програмного забезпечення

Система була реалізована в середовищі Microsoft Visual Studio 2005 на мові C#. База даних представлена у форматі SQLite.

До складу системи входять:

- off_forum.exe - головний модуль завантажуваної надбудови;

- db.db - файл бази даних;

- System.Data.SQLite.dll - бібліотека яка виконує доступ до бази даних;

1.4 Мета й призначення

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

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· Робота в середовищі операційних систем Windows 2000/XP;

· Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

· IBM-сумісний комп'ютер, не нижче Pentium IІ, RAM-128Mb, SVGA-800*600*16bit;

· Вільний простір на жорсткому диску не менш 6 Мб.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. Теоретичні аспекти проектування мережевих додатків

2.1 Локалізація трафіку і ізоляція мереж

Трафік в мережі складається випадковим чином, проте в нім відбиті і деякі закономірності. Як правило, деякі користувачі, що працюють над загальним завданням , (наприклад, співробітники одного відділу) найчастіше поводяться із запитами або один до одного, або до загального сервера, і лише інколи вони випробовують необхідність доступу до ресурсів комп'ютерів іншого відділу. Бажано, щоб структура мережі відповідала структурі інформаційних потоків. Залежно від мережевого трафіку комп'ютери в мережі можуть бути розділені на групи (сегменти мережі). Комп'ютери об'єднуються в групу, якщо велика частина породжуваних ними повідомлень, адресована комп'ютерам цієї ж групи.

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

З одного боку, логічні сегменти мережі, розташовані між мостами, недостатньо ізольовані один від одного, а саме, вони не захищені від, так званих, широкомовних штормів. Якщо яка-небудь станція посилає широкомовне повідомлення, то це повідомлення передається всім станціям всіх логічних сегментів мережі. Захист від широкомовних штормів в мережах, побудованих на основі мостів, має кількісний, а не якісний характер: адміністратор просто обмежує кількість широкомовних пакетів, яку дозволяється генерувати деякому вузлу.

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

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

Узгодження протоколів канального рівня.

Сучасні обчислювальні мережі часто будуються з використанням декількох різних базових технологій - Ethernet , Token Ring або FDDI .

Така неоднорідність виникає або при об'єднанні мереж, що вже існували раніше, використовують в своїх транспортних підсистемах різні протоколи канального рівня, або при переході до нових технологій, таких, як Fast Ethernet або 100VG-AnyLAN .

Саме для утворення єдиної транспортної системи, об'єднуючої декілька мереж з різними принципами передачі інформації між кінцевими вузлами, і служить мережевий рівень. Коли дві або більш за мережі організовують спільну транспортну службу, то такий режим взаємодії зазвичай називають міжмережевою взаємодією (internetworking ). Для позначення складеної мережі в англомовній літературі часто також використовується термін інтермережа (internetwork або internet ).

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

Маршрутизація в мережах з довільною топологією.

Серед протоколів канального рівня деякі забезпечують доставку даних в мережах з довільною топологією, але лише між парою сусідніх вузлів (наприклад, протокол PPP ), а деякі - між будь-якими вузлами (наприклад, Ethernet ), але при цьому мережа повинна мати топологію визначеного і вельми простого типа , наприклад, деревовидну.

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

Мережевий рівень дозволяє передавати дані між будь-якими, довільно зв'язаними вузлами мережі.

Реалізація протоколу мережевого рівня має на увазі наявність в мережі спеціального пристрою - маршрутизатора. Маршрутизатори об'єднують окремі мережі в загальну складену мережу (малюнок 2.1). Внутрішня структура кожної мережі не показана, оскільки вона не має значення при розгляді мережевого протоколу. До кожного маршрутизатора можуть бути приєднані декілька мереж (принаймні дві).

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

Маршрут - це послідовність маршрутизаторів, які повинен пройти пакет від відправника до пункту призначення.

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

Рис. 2.1. Архітектура складеної мережі

2.2 Мережевий рівень і модель взаємодії відкритих систем

У моделі OSI , званою також моделлю взаємодії відкритих систем (Open Systems Interconnection - OSI ) і розробленою Міжнародною Організацією по Стандартах (International Organization for Standardization - ISO ), засоби мережевої взаємодії діляться на сім рівнів, для яких визначені стандартні назви і функції.

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

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

Канальний рівень забезпечує передачу кадру даних між будь-якими вузлами в мережах з типовою топологією або між двома сусідніми вузлами в мережах з довільною топологією. У протоколах канального рівня закладена певна структура зв'язків між комп'ютерами і способи їх адресації. Адреси, використовувані на канальному рівні в локальних мережах, часто називають МАС-адресами .

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

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

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

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

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

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

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

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

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

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

· номер фрагмента пакету, потрібний для успішного проведення операцій збірки-розбирання фрагментів при з'єднанні мереж з різними максимальними розмірами кадрів канального рівня

· час життя пакету, вказуючий , як довго він подорожує по інтермережі, цей час може використовуватися для знищення пакетів, що "заблукали"

· інформація про наявність і про стан зв'язків між мережами, що допомагає вузлам мережі і маршрутизаторам раціонально вибирати міжмережеві маршрути

· інформація про завантаженість мереж, що також допомагає погоджувати темп посилки пакетів в мережу кінцевими вузлами з реальними можливостями ліній зв'язку на дорозі дотримання пакетів

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

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

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

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

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

Кожен комп'ютер в мережі TCP/IP має адреси трьох рівнів:

· Локальна адреса вузла, визначувана технологією, за допомогою якої побудована окрема мережа, в яку входить даний вузол. Для вузлів, що входять в локальні мережі, - це МАС-адрес мережевого адаптера або порту маршрутизатора, наприклад, 11-А0-17-3D-BC-01. Ці адреси призначаються виробниками устаткування і є унікальними адресами, оскільки управляються централізовано. Для всіх існуючих технологій локальних мереж МАС-адрес має формат 6 байтів: старші 3 байти - ідентифікатор фірми виробника, а молодші 3 байти призначаються унікальним чином самим виробником. Для вузлів, що входять в глобальні мережі, такі як Х.25 або frame relay , локальна адреса призначається адміністратором глобальної мережі.

· IP-адрес , що складається з 4 байт, наприклад, 109.26.17.100. Ця адреса використовується на мережевому рівні. Він призначається адміністратором під час конфігурації комп'ютерів і маршрутизаторів. IP-адрес складається з двох частин : номери мережі і номера вузла. Номер мережі може бути вибраний адміністратором довільно, або призначений по рекомендації спеціального підрозділу Internet (Network Information Center , NIC ), якщо мережа повинна працювати як складова частина Internet . Зазвичай провайдери послуг Internet отримують діапазони адрес в підрозділів NIC , а потім розподіляють їх між своїми абонентами.

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

· Символьний ідентифікатор-ім'я, наприклад, SERV1 .IBM.COM. Ця адреса призначається адміністратором і складається з декількох частин , наприклад, імені машини, імені організації, імені домена. Така адреса, звана також DNS-именем , використовується на прикладному рівні, наприклад, в протоколах FTP або telnet .

Три основні класи IP-адресов .

IP-адрес має довжину 4 байти і зазвичай записується у вигляді чотирьох чисел, що представляють значення кожного байта в десятковій формі, і розділених крапками , наприклад:

128.10.2.30 - традиційна десяткова форма представлення адреси

10000000 00001010 00000010 00011110 - двійкова форма представлення цієї ж адреси.

На таблиці 4.1 показана структура IP-адреса .

Таблиця 2.1 Структура IР-адреса

Клас А

0

N мережі

N вузла

Клас В

1

0

N мережі

N вузла

Клас З

1

1

0

N мережі

N вузла

Клас D

1

1

1

0

адреса групи multicast

Клас Е

1

1

1

1

0

зарезервований

Адреса складається з двох логічних частин - номери мережі і номера вузла в мережі. Яка частина адреси відноситься до номера мережі, а яка до номера вузла, визначається значеннями перших бітів адреси:

· Якщо адреса починається з 0, то мережу відносять до класу А, і номер мережі займає один байт, останні 3 байти інтерпретуються як номер вузла в мережі. Мережі класу А мають номери в діапазоні від 1 до 126. (Номер 0 не використовується, а номер 127 зарезервований для спеціальних цілей, про що буде сказано нижче.) У мережах класу А кількість вузлів має бути більше 216, але не перевищувати 224.

· Якщо перші два біта адреси рівні 10, то мережа відноситься до класу В і є мережею середніх розмірів з числом вузлів 28 - 216. У мережах класу В під адресу мережі і під адресу вузла відводиться по 16 бітів, тобто по 2 байти.

· Якщо адреса починається з послідовності 110, то це мережа класу З числом вузлів не більше 28. Під адресу мережі відводиться 24 біта, а під адресу вузла - 8 бітів.

· Якщо адреса починається з послідовності 1110, то він є адресою класу D і позначає особливу, групову адресу - multicast . Якщо в пакеті як адреса призначення вказана адреса класу D, то такий пакет повинні отримати всі вузли, яким привласнена дана адреса.

· Якщо адреса починається з послідовності 11110, то це адреса класу Е, він зарезервований для майбутніх вживань .

У таблиці 2.2 приведені діапазони номерів мереж, відповідних кожному класу мереж.

Таблиця 2.2 Класи мереж

Угоди про спеціальні адреси: broadcast , multicast , loopback

У протоколі IP існує декілька угод про особливу інтерпретацію IP-адресов :

· якщо IР-адрес складається лише з двійкових нулів

0 0 0 0 ................................... 0 0 0 0

то він позначає адресу того вузла, який згенерував цей пакет;

· якщо в полі номера мережі стоять 0

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

· якщо всі двійкові розряди IP-адреса дорівнюють 1

1 1 1 1 .........................................1 1

то пакет з такою адресою призначення повинен розсилатися всім вузлам, що знаходяться в тій же мережі, що і джерело цього пакету. Така розсилка називається обмеженим широкомовним повідомленням (limited broadcast );

· якщо в полі адреси призначення стоять суцільні 1

то пакет, що має таку адресу розсилається всім вузлам мережі із заданим номером. Така розсилка називається широкомовним повідомленням (broadcast );

· адреса 127.0.0.1 зарезервований для організації зворотного зв'язку при тестуванні роботи програмного забезпечення вузла без реальної відправки пакету по мережі. Ця адреса має назву loopback .

Вже згадувана форма групової IP-адреса - multicast - означає, що даний пакет має бути доставлений відразу декільком вузлам, які утворюють групу з номером, вказаним в полі адреси. Вузли самі ідентифікують себе, тобто визначають, до якої з груп вони відносяться. Один і той же вузол може входити в декілька груп. Такі повідомлення на відміну від широкомовних називаються мультивещательными . Групова адреса не ділиться на поля номера мережі і вузла і обробляється маршрутизатором особливим чином.

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

Відображення фізичних адрес на IP-адреса : протоколи ARP і RARP .

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

Локальна адреса використовується в протоколі IP лише в межах локальної мережі при обміні даними між маршрутизатором і вузлом цієї мережі. Маршрутизатор, отримавши пакет для вузла однієї з мереж, безпосередньо підключених до його портів, повинен для передачі пакету сформувати кадр відповідно до вимог прийнятої в цій мережі технології і вказати в нім локальну адресу вузла, наприклад його МАС-адрес . У пакеті, що прийшов, ця адреса не вказана, тому перед маршрутизатором встає завдання пошуку його по відомій IP-адресу , яка вказана в пакеті як адреса призначення. З аналогічним завданням стикається і кінцевий вузол, коли він хоче відправити пакет до видаленої мережі через маршрутизатор, підключений до тієї ж локальної мережі, що і даний вузол.

Для визначення локальної адреси по IP-адресу використовується протокол дозволу адреси Address Resolution Protocol , ARP . Протокол ARP працює різним чином залежно від того, який протокол канального рівня працює в даній мережі - протокол локальної мережі (Ethernet , Token Ring , FDDI ) з можливістю широкомовного доступу одночасно до всіх вузлів мережі, або ж протокол глобальної мережі (X.25, frame relay ), як правило, не підтримує широкомовний доступ. Існує також протокол, вирішальний зворотне завдання , - знаходження IP-адреса за відомою локальною адресою. Він називається реверсивний ARP - RARP (Reverse Address Resolution Protocol ) і використовується при старті бездисковых станцій, що не знають в початковий момент своєї IP-адреса , але що знають адресу свого мережевого адаптера.

У локальних мережах протокол ARP використовує широкомовні кадри протоколу канального рівня для пошуку в мережі вузла із заданою IP-адресом.

Вузол, якому потрібно виконати відображення IP-адреса на локальну адресу, формує ARP запит, вкладає його в кадр протоколу канального рівня, вказуючи в нім відому IP-адрес , і розсилає запит широкомовно. Всі вузли локальної мережі отримують ARP запит і порівнюють вказану там IP-адрес з власною. В разі їх збігу вузол формує ARP-ответ , в якій вказує своя IP-адрес і своя локальна адреса і відправляє його вже напрямлено, оскільки в ARP запиті відправник вказує свою локальну адресу. ARP-запросы і відповіді використовують один і той же формат пакету. Оскільки локальні адреси можуть в різних типах мереж мати різну довжину, то формат пакету протоколу ARP залежить від типа мережі. На Таблиці 2.3 показаний формат пакету протоколу ARP для передачі по мережі Ethernet .

Таблиця 2.3 Формат пакету протоколу ARP

Тип мережі

Тип протоколу

Довжина локальної адреси

Довжина мережевої адреси

Операція

Локальна адреса відправника (байти 0 - 3)

Локальна адреса відправника (байти 4 - 5)

IP-адрес відправника (байти 0-1)

IP-адрес відправника (байти 2-3)

Шукана локальна адреса (байти 0 - 1)

Шукана локальна адреса (байти 2-5)

Шукана IP-адрес (байти 0 - 3)

У полі типа мережі для мереж Ethernet вказується значення 1. Поле типа протоколу дозволяє використовувати пакети ARP не лише для протоколу IP , але і для інших мережевих протоколів. Для IP значення цього поля дорівнює 080016.

Довжина локальної адреси для протоколу Ethernet дорівнює 6 байтам, а довжина IP-адреса - 4 байтам. У полі операції для ARP запитів вказується значення 1 для протоколу ARP і 2 для протоколу RARP .

Вузол, що відправляє ARP-запрос , заповнює в пакеті всі поля, окрім поля шуканої локальної адреси (для RARP-запроса не вказується шукана IP-адрес ). Значення цього поля заповнюється вузлом, що пізнав свою IP-адрес .

У глобальних мережах адміністраторові мережі найчастіше доводиться уручну формувати ARP-таблицы , в яких він задає, наприклад, відповідність IP-адреса адресі вузла мережі X.25, який має сенс локальної адреси. Останнім часом намітилася тенденція автоматизації роботи протоколу ARP і в глобальних мережах. Для цієї мети серед всіх маршрутизаторів, підключених до якої-небудь глобальної мережі, виділяється спеціальний маршрутизатор, який веде ARP-таблицу для всіх останніх вузлів і маршрутизаторів цієї мережі. При такому централізованому підході для всіх вузлів і маршрутизаторів уручну потрібно задати лише IP-адрес і локальну адресу виділеного маршрутизатора. Потім кожен вузол і маршрутизатор реєструє свої адреси у виділеному маршрутизаторі, а при необхідності встановлення відповідності між IP-адресом і локальною адресою вузол звертається до виділеного маршрутизатора із запитом і автоматично отримує відповідь без участі адміністратора.

Відображення символьних адрес на IP-адреса : служба DNS .

DNS (Domain Name System ) - це розподілена база даних, що підтримує ієрархічну систему імен для ідентифікації вузлів в мережі Internet . Служба DNS призначена для автоматичного пошуку IP-адреса по відомому символьному імені вузла. Специфікація DNS визначається стандартами RFC 1034 і 1035. DNS вимагає статичної конфігурації своїх таблиць, що відображують імена комп'ютерів в IP-адрес .

Протокол DNS є службовим протоколом прикладного рівня. Цей протокол несиметричний - в нім визначені DNS-серверы і DNS-клиенты . DNS-серверы зберігають частину розподіленої бази даних про відповідність символьних імен і IP-адресов . Ця база даних розподілена по адміністративних доменах мережі Internet . Клієнти сервера DNS знають IP-адрес сервера DNS свого адміністративного домена і по протоколу IP передають запит, в якому повідомляють відоме символьне ім'я і просять повернути відповідну йому IP-адрес .

Якщо дані про запитану відповідність зберігаються в базі даного DNS-сервера , то він відразу посилає відповідь клієнтові, якщо ж немає - те він посилає запит DNS-серверу іншого домена, який може сам обробити запит, або передати його іншому DNS-серверу . Всі DNS-серверы сполучені ієрархічно, відповідно до ієрархії доменів мережі Internet . Клієнт опитує ці сервери імен, поки не знайде потрібні відображення. Цей процес прискорюється через те, що сервери імен постійно кэшируют інформацію, що надається по запитах. Клієнтські комп'ютери можуть використовувати в своїй роботі IP-адреса декількох DNS-серверов , для підвищення надійності своєї роботи.

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

Корінь бази даних DNS управляється центром Internet Network Information Center . Домени верхнього рівня призначаються для кожної країни, а також на організаційній основі. Імена цих доменів повинні слідувати міжнародному стандарту ISO 3166. Для позначення країн використовуються трьохбуквені і двохбуквені абревіатури, а для різних типів організацій використовуються наступні абревіатури:

· com - комерційні організації (наприклад, microsoft .com);

· edu - освітні (наприклад, mit .edu);

· gov - урядові організації (наприклад, nsf .gov);

· org - некомерційні організації (наприклад, fidonet .org);

· net - організації, що підтримують мережі (наприклад, nsf .net).

Кожен домен DNS адмініструється окремою організацією, яка зазвичай розбиває свій домен на піддомени і передає функції адміністрування цих піддоменів іншим організаціям. Кожен домен має унікальне ім'я, а кожен з піддоменів має унікальне ім'я усередині свого домена. Ім'я домена може містити до 63 символів. Кожен хост в мережі Internet однозначно визначається своїм повним доменним ім'ям (fully qualified domain name , FQDN ), яке включає імена всіх доменів по напряму від хоста до Корню. Приклад повного DNS-имени : citint .dol.ru.

Протокол DHCP

Як вже було сказано, IP-адреса можуть призначатися адміністратором мережі уручну . Це представляє для адміністратора утомливу процедуру. Ситуація ускладнюється ще тим, що багато користувачів не володіють достатніми знаннями для того, щоб конфігурувати свої комп'ютери для роботи в інтермережі і повинні тому покладатися на адміністраторів.

Протокол Dynamic Host Configuration Protocol (DHCP ) був розроблений для того, щоб звільнити адміністратора від цих проблем. Основним призначенням DHCP є динамічне призначення IP-адресов . Проте , окрім динамічного, DHCP може підтримувати і простіші способи ручного і автоматичного статичного призначення адрес.

У ручній процедурі призначення адрес активну участь бере адміністратор, який надає DHCP-серверу інформацію про відповідність IP-адресов фізичним адресам або іншим ідентифікаторам клієнтів. Ці адреси повідомляються клієнтам у відповідь на їх запити до DHCP-серверу .

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

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

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

Прикладом роботи протоколу DHCP може служити ситуація, коли комп'ютер, що є клієнтом DHCP , віддаляється з підмережі. При цьому призначена йому IP-адрес автоматично звільняється . Коли комп'ютер підключається до іншої підмережі, то йому автоматично призначається нова адреса. Ні користувач, ні мережевий адміністратор не втручаються в цей процес. Це властивість дуже важлива для мобільних користувачів.

Протокол DHCP використовує модель клієнт-сервер. Під час старту системи комп'ютер-клієнт DHCP , що знаходиться в змозі "ініціалізація", посилає повідомлення discover (досліджувати), яке широкомовно поширюється по локальній мережі і передається всім DHCP-серверам приватної інтермережі. Кожен DHCP-сервер , що отримав це повідомлення, відповідає на нього повідомленням offer (пропозиція ), яке містить IP-адрес і конфігураційну інформацію.

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

Вибраний DHCP-сервер посилає повідомлення DHCP-acknowledgment (підтвердження), що містить ту ж IP-адрес , яка вже була послана раніше на стадії дослідження, а також параметр оренди для цієї адреси. Крім того, DHCP-сервер посилає параметри мережевої конфігурації. Після того, як клієнт отримає це підтвердження, він переходить в стан "зв'язок", знаходячись в якому він може брати участь в роботі мережі TCP/IP. Комп'ютери-клієнти, які мають локальні диски, зберігають отриману адресу для використання при подальших стартах системи. При наближенні моменту закінчення терміну оренди адреси комп'ютер намагається відновити параметри оренди в DHCP-сервера , а якщо ця IP-адрес не може бути виділений знову, то йому повертається інша IP-адрес .

У протоколі DHCP описується декілька типів повідомлень, які використовуються для виявлення і вибору DHCP-серверов , для запитів інформації про конфігурацію, для продовження і дострокового припинення ліцензії на IP-адрес . Всі ці операції направлені на те, щоб звільнити адміністратора мережі від утомливих рутинних операцій по конфігурації мережі.

Проте використання DHCP несе в собі і деякі проблеми. По-перше, це проблема узгодження інформаційної адресної бази в службах DHCP і DNS . Як відомо, DNS служить для перетворення символьних імен в IP-адреса . Якщо IP-адреса будуть динамічно зміняться сервером DHCP , то ці зміни необхідно також динамічно вносити до бази даних сервера DNS . Хоча протокол динамічної взаємодії між службами DNS і DHCP вже реалізований деякими фірмами (так звана служба Dynamic DNS ), стандарт на нього доки не прийнятий.

По-друге, нестабільність IP-адресов ускладнює процес управління мережею. Системи управління, засновані на протоколі SNMP , розроблені з розрахунком на статичність IP-адресов . Аналогічні проблеми виникають і при конфігурації фільтрів маршрутизаторів, які оперують з IP-адресами .

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

2.4 Протокол між мережевої взаємодії IP

Основу транспортних засобів стека протоколів TCP/IP складає протокол міжмережевої взаємодії - Internet Protocol (IP ). До основних функцій протоколу IP відносяться:

· перенесення між мережами різних типів адресної інформації в уніфікованій формі

· збірка і розбирання пакетів при передачі їх між мережами з різним максимальним значенням довжини пакету.

Формат пакету IP

Пакет IP складається із заголовка і поля даних. Заголовок пакету має наступні поля:

· Поле Номер версії (VERS ) вказує версію протоколу IP . Зараз повсюдно використовується версія 4 і готується перехід на версію 6, звану також IPng (IP next generation ).

· Поле Довжина заголовка (HLEN ) пакету IP займає 4 біта і вказує значення довжини заголовка, виміряне в 32-бітових словах. Зазвичай заголовок має довжину в 20 байт (п'ять 32-бітових слів), але при збільшенні об'єму службової інформації ця довжина може бути збільшена за рахунок використання додаткових байт в полі Резерв (IP OPTIONS ).

· Поле Типа сервісу (SERVICE TYPE ) займає 1 байт і задає пріоритетність пакету і вигляд критерію вибору маршруту. Перші три біта цього поля утворюють підполе пріоритету пакету (PRECEDENCE ). Пріоритет може мати значення від 0 (нормальний пакет) до 7 (пакет інформації, що управляє). Маршрутизатори і комп'ютери можуть брати до уваги пріоритет пакету і обробляти важливіші пакети в першу чергу. Поле Тип сервісу містить також три біта, що визначають критерій вибору маршруту. Встановлений біт D (delay ) говорить про те, що маршрут повинен вибиратися для мінімізації затримки доставки даного пакету, біт T - для максимізації пропускної спроможності, а біт R - для максимізації надійності доставки.

· Поле Загальна довжина (TOTAL LENGTH ) займає 2 байти і вказує загальну довжину пакету з врахуванням заголовка і поля даних.

· Поле Ідентифікатор пакету (IDENTIFICATION ) займає 2 байти і використовується для розпізнавання пакетів, що утворилися шляхом фрагментації вихідного пакету. Всі фрагменти повинні мати однакове значення цього поля.

· Поле Прапори (FLAGS ) займає 3 біта, воно вказує на можливість фрагментації пакету (встановлений біт Do not Fragment - DF - забороняє маршрутизатору фрагментувати даний пакет), а також на те, чи є даний пакет проміжним або останнім фрагментом вихідного пакету (встановлений біт More Fragments - MF - говорить про те пакет переносить проміжний фрагмент).

· Поле Зсув фрагмента (FRAGMENT OFFSET ) займає 13 біт, воно використовується для вказівки в байтах зсуву поля даних цього пакету від початку загального поля даних вихідного пакету, підданого фрагментації. Використовується при сборке/разборке фрагментів пакетів при передачах їх між мережами з різними величинами максимальної довжини пакету.

· Поле Час життя (TIME TO LIVE ) займає 1 байт і вказує граничний термін, протягом якого пакет може переміщатися по мережі. Час життя даного пакету вимірюється в секундах і задається джерелом передачі засобами протоколу IP . На шлюзах і в інших вузлах мережі після закінчення кожної секунди з поточного часу життя віднімається одиниця; одиниця віднімається також при кожній транзитній передачі (навіть якщо не прошла секунда). При виділенні часу життя пакет анулюється.

· Ідентифікатор Протоколу верхнього рівня займає 1 байт і вказує , якому протоколу верхнього рівня належить пакет (наприклад, це можуть бути протоколи TCP , UDP або RIP ).

· Контрольна сума (HEADER CHECKSUM ) займає 2 байти, вона розраховується по всьому заголовку.

· Поля Адрес джерела (SOURCE IP ADDRESS ) і Адресу призначення (DESTINATION IP ADDRESS ) мають однакову довжину - 32 біта, і однакову структуру.

· Поле Резерв (IP OPTIONS ) є необов'язковим і використовується зазвичай лише при відладці мережі. Це поле складається з декількох підполів, кожне з яких може бути одного з восьми зумовлених типів. У цих підполях можна вказувати точний маршрут проходження маршрутизаторів, реєструвати прохідні пакетом маршрутизатори, поміщати дані системи безпеки, а також тимчасові відмітки. Оскільки число підполів може бути довільним, то в кінці поля Резерв повинно бути додано декілька байт для вирівнювання заголовка пакету по 32-бітовому кордону .

Максимальна довжина поля даних пакету обмежена розрядністю поля, що визначає цю величину, і складає 65535 байтів, проте при передачі по мережах різного типа довжина пакету вибирається з врахуванням максимальної довжини пакету протоколу нижнього рівня, що несе IP-пакеты . Якщо це кадри Ethernet , то вибираються пакети з максимальною довжиною в 1500 байтів, що уміщаються в полі даних кадру Ethernet .

Управління фрагментацією

Протоколи транспортного рівня (протоколи TCP або UDP ), що користуються мережевим рівнем для відправки пакетів, вважають , що максимальний розмір поля даних IP-пакета дорівнює 65535, і тому можуть передати йому повідомлення такої довжини для транспортування через інтермережу. У функції рівня IP входить розбиття дуже довгого для конкретного типа складової мережі повідомлення на коротші пакети із створенням відповідних службових полів, потрібних для подальшої збірки фрагментів у вихідне повідомлення.

У більшості типів локальних і глобальних мереж визначається таке поняття як максимальний розмір поля даних кадру або пакету, в які повинен інкапсулювати свій пакет протокол IP . Цю величину зазвичай називають максимальною одиницею транспортування - Maximum Transfer Unit , MTU . Мережі Ethernet мають значення MTU , рівне 1500 байт, мережі FDDI - 4096 байт, а мережі Х.25 найчастіше працюють з MTU в 128 байт.

Робота протоколу IP по фрагментації пакетів в хостах і маршрутизаторах ілюструється малюнком 4.2.

Хай комп'ютер 1 пов'язаний з мережею, що має значення MTU в 4096 байтів, наприклад, з мережею FDDI . Під час вступу на IP-уровень комп'ютера 1 повідомлення від транспортного рівня розміром в 5600 байтів, протокол IP ділить його на два IP-пакета , встановлюючи в першому пакеті ознаку фрагментації і привласнюючи пакету унікальний ідентифікатор, наприклад, 486. У першому пакеті величина поля зсуву дорівнює 0, а в другому - 2800. Ознака фрагментації в другому пакеті дорівнює нулю , що показує, що це останній фрагмент пакету. Загальна величина IP-пакета складає 2800+20 (розмір заголовка IP ), тобто 2820 байтів, що уміщається в полі даних кадру FDDI .

Рис. 2.2. Фрагментація IP-пакетов при передачі між мережами з різними максимальними розмірами пакетів. К1 і Ф1 канальний і фізичний рівень мережі 1, К2 і Ф2 канальний і фізичний рівень мережі 2

Далі комп'ютер 1 передає ці пакети на канальний рівень К1, а потім і на фізичний рівень Ф1, який відправляє їх маршрутизатору, пов'язаному з даною мережею.

Маршрутизатор бачить за мережевою адресою, що прибулі два пакети потрібно передати в мережу 2, яка має менше значення MTU , рівне 1500. Ймовірно , це мережа Ethernet . Маршрутизатор витягує фрагмент транспортного повідомлення з кожного пакету FDDI і ділить його ще навпіл, щоб кожна частина уміщалася в полі даних кадру Ethernet . Потім він формує нові пакети IP , кожен з яких має довжину 1400 + 20 = 1420 байтів, що менше 1500 байтів, тому вони нормально поміщаються в поле даних кадрів Ethernet .

В результаті в комп'ютер 2 по мережі Ethernet приходить чотири IP-пакета із загальним ідентифікатором 486, що дозволяє протоколу IP , що працює в комп'ютері 2, правильно зібрати вихідне повідомлення. Якщо пакети прийшли не в тому порядку , в якому були послані , то зсув вкаже правильний порядок їх об'єднання.

Відзначимо, що IP-маршрутизаторы не збирають фрагменти пакетів в крупніші пакети, навіть якщо на дорозі зустрічається мережа, що допускає таке укрупнення. Це пов'язано з тим, що окремі фрагменти повідомлення можуть переміщатися по інтермережі по різних маршрутах, тому немає гарантії, що всі фрагменти проходять через який-небудь проміжний маршрутизатор на їх дорозі .

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

Маршрутизація за допомогою IP-адресов

Розглянемо тепер принципи, на підставі яких в мережах IP відбувається вибір маршруту передачі пакету між мережами.

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

Мал. 2.3. Вибір маршрутизатора кінцевим вузлом

Довжина маршруту може істотно змінитися залежно від того, який маршрутизатор вибере комп'ютер для передачі свого пакету на сервер, розташований , наприклад, в Германії, якщо маршрутизатор 1 сполучений виділеною лінією з маршрутизатором в Копенгагені, а маршрутизатор 2 має супутниковий канал, що сполучає його з Токіо.


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.