Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lesson2_net.doc
Скачиваний:
0
Добавлен:
23.11.2019
Размер:
343.55 Кб
Скачать

Стандартизована архітектура протокола

Коли необхідно встановити зв’язок між комп’ютерами різних виробників, зусилля по розробці програмного забезпеченя можуть стати дуже великими. Виробники використовують різніе формати даних та про­токоли обміна даними. Навіть в межах одного модельного ряду різні моделі комп’ютерів можуть взаємодіяти різними способами.

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

  • виробники змушені використовувати стандарти, зважаючи на те, що при широкому розповсюдженні стандартів вироби, які їх не використовують, будуть неконкурентоздатними;

  • у клієнтов з’являється можливість вимагати требовать, щоб обладнання по­стачальників відповідало загальноприйнятим стандартам.

В якості основи розробки універсальних стандартних протоколів прий­няті дві архітектури протоколу: комплект протоколів TCP/IP та еталонна модель OSI. Протоколи TCP/IP найбільш широко розповсюджені в якості универсальної архітектури. Модель OSI не отримала такого широкого розповсюдження, яке очікувалось при її появі. Існує також ще одна часто використовувана схема: Системна мережева архітектура фірми IBM (Systems Network Architecture, SNA.

Модель osi

Стандарти необхідні для взємодії між різним обладнанням та для економії коштів. Через складність задач комунікації недостатньо мати єдиний стандарт. Замість цього всі функції краще розбити на дрібніші фрагменти, якими простіше управляти, а вже із них створювати архітектуру комуніка­ції. Ця архітектура і повина формувати робоче середовище стандартизації. В результаті в 1977г. Міжнародна організація по стандартизації (ISO) створила підкомітет по розробці такої архітектури. Результатом роботи комітету стала еталонна модель OSI. Хоча основні компоненти моделі були розроблені дуже швидко, кінцевий стандарт ISO 7498 було опубліковано тільки в 1984 р.

Модель

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

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

Перерахуємо обоснування причин виділення рівнів моделі OSI (X.200).

  1. Важливим є те, що ця архітектура допускає використання реального спектру фізичних пристроїв для взаємодії з різними управляючими процедурами (наприклад, V.24, V.25 та ін.). При цьому фізичний рівень визначається (physical layer) як самий нижній рівень архітектури.

  2. Деякі фізичні засоби комунікації (наприклад, телефонна лінія) потребують використання специфічних технологій для передачі даних між системами, не дивлячись на відносно високий рівень помилок, (тобто рівень помилок, неприйнятний для більшості додатків). Ці специфічні технології використовуються в процедурах управліня каналом передачі даних, які вивчались та стандартизува­лись протягом декількох років. Зрозуміло, що нові засоби передачі інформації (наприклад, волоконо-оптичні) потре­бують різних процедур управліня каналом передачі даних. Це призводить до виділення канального рівня (data link layer) як рівня, що знаходиться в архітектурі над фізичним рівнем.

  3. В архітектурі відкритих систем деякі відкриті системи будуть виступати в ролі пункта призначення даних. Деякі відкриті системи можуть бути тільки проміжними вузлами (які передають дані на інші системи). Це призводить до визначеня мережевого рівня (network layer), розташованого над канальним рівнем. На цьому рівні будуть групуватися протоколи, орієнтовані на мережу, наприклад маршрутизація. Тому мережевий рівень предоставляє шлях зв’язку (мережеве підключення) між парами транспортних об’єктів, в т. ч. проміжними вузлами.

  1. Управління передачею даних від кінцевої відкритої системи-джерела до цільової кінцевої відкритої системи (не виконується на проміжних вузлах) — це остання функція, яка необхідна для повного забезпечення транспортного сервісу. Тому верхній рівень частини ар­хітектури, зв’язаної з транспортним сервісом, — транспортний рівень (transport layer), який розташований над мережевим рівнем. Транспортний рівень звільняє об’єкти більш високого рівня від необхідності турбуватись про транспортуванняе даних між ними.

  2. Необхідна організація та синхронизація діалога та управління обміном даних. Це призводить до визначення сеансово­го рівня (session layer), який знаходиться над транспортним рівнем.

  3. До інших функцій відносяться ті, які зв’язані з представленням та управлінням структурованими даними приклад­них програм. Це призводить до визначення рівня представлення (presentation layer), який розташований над сеансовим рівнем.

  4. Крім того існують додатки, які складаються із прикладних процес­ів, які виконують обробку інформації. Взаємодія цих при­кладних процесів та протоколів складає рівень додатків (application layer) — самий верхній рівень архітектури.

В архітектурі OSI кожна система містить семь рівнів. На цьому рисунку показано зв’язок між двома додаткими X та Y, розміщеними на двох комп’ютерах. Якщо додаток X збирається послати повідомлення додатку Y, то при цьому він звертається до рівня додатків (рівень 7). Рівень 7 встановлює рівноправний взаємозв’язок з рівнем 7 цільового комп’ютера з допомогою протокола рівня 7 (протокол додатків).Цей протокол вимагає сервіси від рівня 6, два об’єкти рівня 6 використовують власний протокол та далі вниз до фізичного рівня, який фактично пересилає біти інформації через передавальне середовище.

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

PDU також використовується в рамках архітектури OSІ. Коли додаток X збирається відправити повідомлення додатку Y, вона пересилає дані об’єкту додатки на рівні додатків. До даних додається заголовок, який містить необхідну інформацію для рівноправного рівня 7 (інкапсуляція). Вихідні дані разом із заголовком передаються як єдине ціле на рівень 6. Об’єкт презентації розглядає все це як дані та додає свій власний заголовок (друга інкапсуляція). Цей процес продовжується вниз до рівня 2, який додає як заголовок, так і трейлер (запис із контрольной сумою в кінці масива даних). Об’єкт рівня 2, називаємий кадром, потім передається на передавальний пристрій з допомогою фізичного рівня. Коли кадр отримано цільовою системою, процес іде в зворотньому напрямку. При підйомі даних по рівнях кожний рівень видаляє самий крайній заголовок, діючи відповідно до протокольної інформації, яка міститься в даних, а іншу частину інформації передає на вищий рівень.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]