Курс лекцій „Комп’ютерні мережі

Вид материала

Курс лекцій

Содержание Простота та низьке завантаження каналу. Надійність та стабільність. Швидка збіжність. Плоскі на противагу ієрархічним. Стану каналу Затримка маршрутизації Пропускна здатність 1.7.2. Технології управління потоком даних. Розмір вікна 1.7.3. Протоколи транспортного рівня. 1.7.3.2. Формат ТСР-сегменту. 1.7.3.3. Протокол UDP 1.7.3.4. Формат UDP-сегменту. 1.8. Сеансовий рівень. Розділення діалогу (dialogue separation) – 1.8.2. Процедури TWS та TWA. 1.9. Представницький рівень 1.10. Прикладний рівень 2. Протокольний стек ТСР/ІР. 2.2. Протоколи стеку ТСР/ІР. ... Полное содержание

Подобный материал:

• 1. Комп’ютерні мережі Тема Комп’ютерні мережі, 56.68kb.
• Робоча програма з дисципліни " Комп’ютерні мережі" (за вимогами кмсонп) Освітньо-кваліфікаційний, 251.7kb.
• Навчальна програма дисципліни Комп’ютерні мережі в системах управління Напрям підготовки, 70.88kb.
• Програма фахового вступного випробування для навчання за освітньо-кваліфікаційним рівнем, 138.81kb.
• Програма фахового вступного випробування для навчання за освітньо-кваліфікаційним рівнем, 132.16kb.
• Робоча навчальна програма навчальної дисципліни " Системне програмне забезпечення", 184.72kb.
• Способи передачі даних в мережі Internet (на прикладі електронної пошти), 408.96kb.
• Ютерні системи та мережі” Спеціалізація: Комп’ютерні засоби інформатики, 203.69kb.
• Питання на Державний іспит зі спеціальностей 091. 501 "комп’ютерні системи та мережі",, 111.96kb.
• Правила побудови адреси в мережі Internet, 9.49kb.

Цілі проектування.

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

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

Надійність та стабільність. Алгоритм маршрутизації повинен забезпечувати коректну роботу у незвичайній або непередбачуваній ситуації – при відмові частини апаратного забезпечення, пікових навантаженнях мережі та некоректних настройках.

Швидка збіжність. Збіжність – це процес узгодження всіма маршрутизаторами мережі оптимальних маршрутів. Говорять, що мережа збіглася, коли всі маршрутизатори мережі володіють однаковими та вірними відомостями про стан каналів мережі. Перерахунок метрик та зміна інформації про оптимальні маршрути виникає, оскільки топологія мережі періодично змінюється – одні пристрої виходять з ладу, інші, навпаки, стають доступними. Алгоритми, які володіють повільною збіжністю, можуть спричинити появу петель або виходу з ладу всієї мережі.

Гнучкість. Алгоритми маршрутизації повинні бути гнучкими – швидко та точно пристосовуватися до зміни умов функціонування мережі.

Типи алгоритмів.

Алгоритми маршрутизації можуть бути класифіковані за типами.

Статичні на противагу динамічним.

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

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

При необхідності можна поєднувати ці два методи.

Одношляхові на противагу багатошляховим.

Деякі досить складні протоколи маршрутизації підтримують кілька шляхів до однієї точки призначення. На відміну від одношляхових алгоритмів, багатошляхові дозволяють мультиплексацію трафіку через кілька ліній зв’язку. Переваги таких алгоритмів очевидні: значно краща пропускна здатність та надійність. Як правило, цю функцію називають розділенням навантаження (load sharing).

Плоскі на противагу ієрархічним.

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

“Від джерела” на противагу прозорим.

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

Інтрадоменні на противагу інтердоменним.

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

Стану каналу на противагу дистанційно-векторним.

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

Метрики.

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

Алгоритми маршрутизації використовують багато різноманітних метрик. Більш складні алгоритми маршрутизації використовують комбіновані метрики.

У алгоритмах маршрутизації можуть використовуватися наступні метрики:

• довжина шляху;
  
• надійність;
  
• затримка;
  
• пропускна здатність;
  
• завантаженість;
  
• вартість передачі інформації.
  

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

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

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

Пропускна здатність – здатність каналу передавати певний об’єм трафіку за одиницю часу. Але пропускна здатність – це лише теоретична величина, тому не завжди канал із більшою теоретичною пропускною здатністю є більш бажаним, він може бути зайнятим на момент передачі інформації.

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

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

40

1.7. Транспортний рівень.

1.7.1. Функції транспортного рівня.

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

• синхронізацію з’єднання;

• контроль потоку даних;

• відновлення інформації після виникнення помилки;

• надійну передачу інформації.

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

При передачі інформації на транспортному рівні перевіряється цілісність інформації. При виявленні помилки передачі даних ініціюється повторна передача.

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

Однією із переваг використання багаторівневої моделі є те, що кілька додатків можуть одночасно використовувати одне і те ж транспортне з’єднання. Транспортні операції проводяться над кожним сегментом окремо і послідовно. Це означає, що різні сегменти інформації від різних додатків, які надсилаються до одного або до кількох різних отримувачів, обслуговуються за принципом „першим прийшов – першим вийшов” (FIFO).

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

Процес синхронізації на транспортному рівні називають „триразовим рукостисканням” (three-way handshake). Його використовує в основному протокол ТСР.




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

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

Для протоколів TCP та UDP деякі номери портів є зарезервованими, тому ніякі нові розроблювані мережеві додатки не можуть їх використовувати. Номери портів присвоюються наступним чином:

255. для загальновикористовуваних додатків;
     

256-1023 присвоюються компаніями для ринкових додатків

1024 і далі неврегульовано

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

41

1.7.2. Технології управління потоком даних.

На транспортному рівні використовуються наступні технології управління потоком даних та захисту від помилок:

• віконна передача даних (Windowing)
  
• позитивне підтвердження із повторною передачею даних (Positive acknowledgment and retransmission, or PAR)
  

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



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

Протокол ТСР використовує так звані очікувальні підтвердження (expectational acknowledgments) – це означає, що отримувач у якості пдітвердження надсилає номер наступного очікуваного октету.

Дану техніку часто ще називають режимом ковзаючого вікна. При цьому вважається, що термін „ковзаюче вікно” (sliding window) стосується того факту, що розмір вікна узгоджується динамічно у процесі передачі даних.

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

42

1.7.3. Протоколи транспортного рівня.

1.7.3.1. Протокол ТСР.

TCP (Transmission Control Protocol, Протокол керування передачею) було спроектовано в якості зв’язуючого протоколу для забезпечення інтерактивної роботи між комп’ютерами. ТСР забезпечує надійність та достовірність обміну даними між процесами на комп’ютерах, які входять до загальної мережі. ТСР, з одного боку, взаємодіє з прикладним додатком, а з іншого – з протоколом, який забезпечує „функції низького рівня”: маршрутизацію і адресацію пакетів, які, як правило, виконує ІР.

У операційній системі реалізація ТСР представляє собою окремий системний модуль (драйвер), через який, як правило, проходять всі виклики функцій протоколу. Інтерфейс між прикладним процесом і ТСР являє собою бібліотеку викликів – таку ж, як бібліотека системних викликів, наприклад, для роботи з файлами. Користувач може вікрити або закрити з’єднання (як вікрити або закрити файл) і відправити або прийняти дані з встановленого з’єднання (аналогічно операціям читання та запису). Виклики ТСР можуть працювати із прикладним додатком у асинхронному режимі.

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

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

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

У результаті роботи цього механізму кожен TCP-пакет вкладається в "конверт" протоколу нижнього рівня, наприклад, IP. Отримана в такий спосіб дейтаграма містить у собі TCP-пакет так само як TCP-пакет містить користувальницькі дані.

43

1.7.3.2. Формат ТСР-сегменту.

TCP-сегменти відправляються як IP-дейтаграммы. Заголовок TCP, що випливає за IP-заголовком, містить інформацію TCP-протоколу.

0 4 10 16 24 31

Source Port								Destination Port
Sequence Number
Acknowledgement Number
Data Offset	Reserved	U R G	A C K	P S H	R S T	S Y N	F I N	Window
Checksum								Urgent Pointer
Options									Padding
Data

Source Port (16 біт). Порт відправника.

Destination Port (16 біт). Порт одержувача.

Sequence Number (32 біта). Номер кадру. Номер кадру першого октету даних у цьому сегменті (за винятком пакета, де є присутнім прапор SYN). Якщо в пакеті присутній прапор SYN, то номер даного пакета стає номером початку послідовності (ISN) і номером першого октету даних стає номер ISN+1.

Acknowledgment Number (32 біта). Поле номера кадру підтвердженого одержання. Якщо пакет містить установлений контрольний біт АСК, то це поле містить номер наступного пакета даних відправника, що очікує одержувач. При встановленому з'єднанні пакет підтвердження відправляється завжди.

Data Offset (4 біти). Поле величини зсуву даних. Воно містить кількість 32-бітних слів заголовка TCP-пакета. Це число визначає зсув розташування даних у пакеті.

Reserved (6 біт). Резервне поле. Поле зарезервоване.

Прапори керування:

• URG: Прапор терміновості
  
• АСК: Прапор пакета, що містить підтвердження одержання
  
• PSH: Прапор форсованого відправлення
  
• RST: Переустановка з'єднання
  
• SYN: Синхронізація чисел послідовності
  
• FIN: Прапор закінчення передачі з боку відправника
  

Window (16 біт). Вікно. Це поле містить кількість байт даних, що відправник даного сегмента може прийняти, відлічене від номера байта, зазначеного в поле Acknowledgment Number.

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

Urgent Pointer (16 біт). Поле покажчика термінових даних. Це поле містить значення лічильника пакетів, починаючи з якого випливають пакети підвищеної терміновості. Це поле береться до уваги тільки в сегментах із установленим прапором URG.

Options. Поле додаткових параметрів: може бути змінної довжини.

Padding. Заповнення: перемінна довжина. Заповнення (нулями) TCP-заголовка використовується для вирівнювання його по 32-бітному слову.

44

1.7.3.3. Протокол UDP

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

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

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

Його основні характеристики порівняно із ТСР:

• без встановлення з’єднання
  
• ненадійний (не проводить програмної перевірки доставки повідомлень)
  
• не реасемблює вхідні повідомлення
  
• не використовує механізму підтверджень
  
• не забезпечує контролю потоку даних
  

Перевага протоколу UDP полягає в тому, що він вимагає мінімум установок і параметрів для з'єднання двох процесів між собою. Цей протокол використовується при роботі Серверів Доменів (Name Servers), при роботі протоколу TFTP (Trivial File Transfer, Тривіальний протокол передачі даних), роботі з SNMP і побудові систем аутентифікації. Ідентифікатор UDP у IP-заголовку — число 17.

45

1.7.3.4. Формат UDP-сегменту.

0 16 31

Source Port	Destination Port
Length	Checksum
Data

Source Port (16 біт). Порт відправника. Це поле може містити номер порту, з якого був відправлений пакет, коли це має значення (наприклад відправник очікує відповіді). Якщо це поле не використовується, воно заповнюється нулями.

Destination Port (16 біт). Порт призначення — це порт комп'ютера, на який пакет буде доставлений.

Length (16 біт). Поле довжини. Довжина (у байтах) цієї дейтаграми, включаючи заголовок і дані. (Мінімальне значення цього поля дорівнює 8).

Checksum (16 біт). Поле контрольної суми. Контрольна сума UDP-пакета являє собою побітне доповнення 16-бітної суми 16-бітних слів (аналогічно TCP). В обчисленні беруть участь: дані пакета, заголовок UDP-пакета, псевдозаголовок (інформація від IP-протоколу), поле вирівнювання по 16-бітній границі (нульові).

46

1.8. Сеансовий рівень.

1.8.1. Функції сеансового рівня.

Виконання мережевих процесів часто займає досить малий час, для стороннього спостерігача може здатися – миттєво. Але насправді під час передачі даних кожен рівень виконує певний набір дій для узгодження цього процесу. Зокрема, до функцій сеансового рівня відносяться установлення сеансу зв’язку між додатками, визначення режиму передачі даних (одно- чи двонапрямлений), ресинхронізація передачі даних після переривання зв’язку та ін.

Сеансовий рівень встановлює, управляє та перериває сеанс зв’язку між додатками. Це включає старт, зупинку та ресинхронізацію обміну інформацією між додатками на двох вузлах. Процес обміну інформацією можна розглядати як постійні сеанси зв’язку, у кожному з яких вузол відіграє подвійну роль: запитує сервіси, як клієнт, і надає їх, як сервер. Визначення того, яку роль хост відіграє на даний момент, називаєть контроль діалогу (dialogue control).

Розділення діалогу (dialogue separation) – це впорядкована ініціація, термінування та управління сеансом зв’язку, тобто його синхронізація. Синхронізація відбувається на початку та в кінці кожного сеансу зв’язку (первинна синхронізація, major synchronization), а також періодично у процесі роботи (вторинна синхронізація, minor synchronization). Під час синхронізації кожен вузол виконує наступні дії:

1. Зберігає у тимчасові файли отримані дані
   
2. зберігає настройки мережі
   
3. помічає часові параметри
   
4. помічає місце у даних, де відбулася синхронізація (ставить „контрольну точку”, checkpoint)
   

До протоколів сеансового рівня відносяться:

• Structured Query Language (SQL)
  
• Remote Procedure Call (RPC)
  
• X-Window System
  
• AppleTalk Session Protocol (ASP)
  
• Digital Network Architecture Session Control Protocol (DNA SCP)
  

47

1.8.2. Процедури TWS та TWA.

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

Якщо передача або прийом інформації здійснюється строго почергово, такий режим роботи називається двонапрямленим почерговим обміном інформацією (two-way alternate communication, TWA). Якщо процес обміну здійснюється обома учасниками процесу за бажанням кожного, незалежно від того, чия черга передавати на даний момент, це називається двонапрямленим одночасним обміном інформацією (two-way simultaneous communication, TWS).

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

Якщо виникнення таких колізій є неприпустимим, контроль діалогу повинен обрати використання процедури TWА. Це передбачає наявність у системі використання маркера сеансового рівня, володіння яким надає право передачі інформації (подібно до мереж Token Ring).

48

1.9. Представницький рівень

Представницький рівень (Presentation layer) має справу з формою представлення переданої по мережі інформації, не змінюючи при цьому її змісту. За рахунок рівня представлення інформація, передана прикладним рівнем однієї системи, завжди зрозуміла прикладному рівневі іншої системи. За допомогою засобів даного рівня протоколи прикладних рівнів можуть перебороти синтаксичні розходження в представленні даних або ж розходження в кодах символів, наприклад кодів ASCII і EBCDIC. На цьому рівні може виконуватися шифрування і дешифрування даних, завдяки якому таємність обміну даними забезпечується відразу для всіх прикладних служб. Прикладом такого протоколу є протокол Secure Socket Layer (SSL), що забезпечує секретний обмін повідомленнями для протоколів прикладного рівня стеку TCP/IP.

До основних функцій представницького рівня відносяться:

• Форматування (представлення даних)
  
• Шифрування даних
  
• Компресія даних
  

До загальних форматів даних відносяться:

Для текстової інформації – ASCII, EBCDIC

Для графічної інформації – TIFF, PICT, JPEG, GIF

Для аудіо- та відеоінформації – MIDI, MPEG, QuickTime.


49

1.10. Прикладний рівень

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

Існує дуже велика кількість служб прикладного рівня. Наведемо як приклад кілька найбільш розповсюджених реалізацій файлових служб: NCP в операційній системі Novell NetWare, SMB у Microsoft Windows NT, NFS, FTP і TFTP, що входять у стек TCP/IP.

У контексті моделі OSI прикладний рівень підтримує взаємодіючі компоненти додатків. Він відповідає за забезпечення виконання наступних функцій:

• Визначення доступності партнерів по обміну інформацією
  
• Синхронізація взаємодіючих додатків
  
• Досягнення згоди по процедурах відновлення інформації після виникнення помилки
  
• Контроль цілісності інформації
  

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

Більшість додатків, які працюють у мережевому середовищі, мають клієнт-серверну архітектуру. Це дозволяє їм функціонувати без використання додаткових програм для доступу до мережевих ресурсів. Але додатки, які не розроблялися спеціалізовано для роботи у мережі, теж можуть використовувати переваги ЛОМ – завдяки протрамам-редиректорам. Редиректори – це протоколи, які працюють з ОС комп’ютера та мережевими клієнтами замість спеціальних додатків. Прикладами програм-редиректорів є:

• Apple File Protocol
  
• NetBIOS Extended User Interface (NetBEUI)
  
• Novell IPX/SPX
  
• Network File System (NFS) протокольного стеку TCP/IP
  

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

50, 51

2. Протокольний стек ТСР/ІР.

2.1. Призначення протокольного стеку ТСР/ІР.

Мережевий простір роботи ТСР/ІР побудовано за принципом – моделі ланцюгової мережі. Вона передбачає, що у нашому розпорядженні велика кількість незалежних неоднорідних мереж, з’єднаних одна з одною шлюзами, які забезпечують взаємодію мереж між собою. Мережі можуть бути як локальними, так і глобальними. Кожна із підмереж працює у відповідності із своїми специфічними вимогами, вони можуть мати різну топологію, апаратну реалізацію та природу засобів зв’язку. Але передбачається, що кожна мережа може прийняти блок інформації та доставити його за вказаною адресою у конкретній мережі. При виникненні втрат даних та їх спотвореннях необхідно провести повторну передачу.

Для забезпечення всіх цих функцій і було розроблено протокольний стек ТСР/ІР. При відправці повідомлення воно формується програмами прикладного рівня, проводиться відповідне форматування, відкривається сеанс трансляції. Протоколи транспортного рівня (ТСР та UDP) відповідають за розбиття даного повідомлення на сегменти, відновлення його із отриманих сегментів, повторну відправку втрачених або пошкоджених сегментів. Мережевий рівень (ІР) виконує функції маршрутизації та доставки за адресою окремих пакетів.

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

52

2.2. Протоколи стеку ТСР/ІР.

2.2.1 Протоколи ARP та proxy ARP.

При передачі інформації через мережеве середовище відправник повинен знати як логічну адресу отримувача (адресу мережевого рівня), так і фізичну (адресу канального рівня). У мережах Ethernet, які працюють на основі протокольного стеку ТСР/ІР у якості логічної використовується 32-бітна ІР адреса, а у якості фізичної – 48-бітна МАС адреса. Ці адреси між собою ніяк не взаємопов’язані, і не існує механізмів перетворення одних адрес в інші. Тому для встановлення відповідності між МАС та ІР-адресою використовується протокол ARP (Address Resolution Protocol). Така відповідність встановлюється лише для тих ІР-пакетів, які необхідно відправити, оскільки лише у момент відправки формуються заголовки ІР та Ethernet. ARP не використовує для роботи ІР; він є самостійним протоколом на основі кадрів Ethernet.

Основним інструментом роботи протоколу ARP є таблиця відповідності адрес. Пряме перетворення адрес виконується шляхом пошуку підходящого запису у цій таблиці. Ця таблиця, яку ще називають ARP-таблицею, знаходиться у оперативній пам’яті вузла, і містить рядки відповідності для кожного вузла мережі, з яким спілкується даний. У двох стовпчиках таблиці містяться ІР- та МАС-адреси хостів.

ARP-таблиця заповнюється автоматично модулем ARP по мірі необхідності. Коли з допомогою існуючої ARP-таблиці не вдається перетворити ІР-адресу, відбувається наступне:

• по мережі передається широкомовний ARP-запит (на адресу FF-FF-FF-FF-FF-FF);
  
• вихідний ІР-пакет ставиться на чергу.
  

Кожен мережевий адаптер приймає широкомовні передачі. Всі драйвери Ethernet перевіряють поле типу у прийнятому Ethernet-кадрі та передають ARP-запити модулю ARP. ARP-запит можна інтерпретувати таким чином: „Якщо ваша ІР-адреса співпадає з вказаною, то повідомте мені вашу МАС-адресу”. Пакет ARP-запиту містить ІР- та МАС-адресу відправника, ІР-адресу хоста, МАС-адресу якого необхідно визначити та поле типу запиту, яке вказує, що необхідно визначити саме МАС-адресу за даною ІР.

Кожен модуль ARP перевіряє поле шуканої ІР-адреси у отриманому ARP-запиті і, якщо адреса співпадає із його власною, посилає відповідь прями за вказаною МАС-адресою відправника. Така ARP-відповідь містить ІР- та МАС-адресу як відправника, так і отримувача – того, хто послав запит. Після цього даний пакет направляється ARP-модулю, який додає новий запис до ARP-таблиці вузла.

Тепер, з використанням оновленої ARP-таблиці можна створити Ethernet-кадр і передати його по мережі відповідній машині.

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

Формат ARP-пакету:

0 16 24 32

Ethernet destination address
Ethernet dest.	Ethernet source
Ethernet source address
Type code	Hardware address space
Protocol address space	LHA	LPA
Opcode	Апаратна (МАС) та
логічна (ІР) адреса відправника та отримувача; займає байти LHA та LPA
Ethernet checksum

Type code – поле типу робочого протоколу

Hardware address space – поле типу мережі (для Ethernet -1)

Protocol address space – поле типу досліджуваного протоколу (2048 для ІРv4)

LHA – поле довжини апаратної адреси в байтах (для МАС-6)

LPA – поле довжини логічної адреси в байтах (для IPv4 – 4)

Opcode – поле типу виконуваної дії (1 для запиту, 2 для відповіді)

Апаратна та логічна адреса відправника та отримувача займають відповідно LHA та LPA байт.

Якщо отримувач інформації міститься у іншому логічному сегменті мережі, очевидно, що він не зможе самостійно відповісти на ARP-запит відправника. Це відбувається тому, що широкомовні запити 2-го та 3-го рівня, на які відправляється ARP-запит, не передаються через шлюз, в якості якого найчастіше працює маршрутизатор. У такому випадку говорять про роботу proxy ARP. Цей протокол працює наступним чином: якщо ІР-адреса отримувача знаходиться у іншій мережі або підмережі, маршрутизатор формує відповідь на ARP-запит, де у якості МАС-адреси отримувача вказує МАС-адресу власного порта. Вузол, який відправляє інформацію, формує пакет, де вказана ІР-адреса отримувача та МАС-адреса порта маршрутизатора. При отриманні такого пакету маршрутизатор заміняє власну МАС-адресу у полі апаратної адреси отримувача на дійсну апаратну адресу отримувача та відправляє кадр у відповідний сегмент мережі.

53

2.2.2 Протоколи динамічної адресації RARP, BOOTP, DHCP.

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

Протокол RARP (Reverse ARP) дозволяє вузлу, який не знає своєї IP-адреси (наприклад, бездисковій робочій станції) визначити її на основі МАС-адреси. Якщо у мережі використовується протокол RARP, необхідна наявність вузла, який буде виконувати роль RARP-сервера.

Формат пакету RARP співпадає із форматом пакету ARP, але поле „operation code" має інші значення (3 - для RARP-запиту і 4 для відповіді).

Протокол BOOTP (Bootstrap protocol) оперує виключно у клієнт-серверному середовищі і вимагає єдиного сеансу обміну пакету для отриманні необхідної IP інформації. На відміну від RARP, BOOTP пакети можуть включати інформацію не лише про IP-адресу вузла, а і про адресу шлюза, сервера та ще певну інформацію, специфічну для виробника.

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

Пристрій використовує ВООТР для отримання IP-адреси при ввімкненні. ВООТР використовує UDP в якості транспортного протоколу. UDP повідомлення інкапсулюється у IP-пакет, який відправляється на широкомовну адресу 255.255.255.255. ВООТР-сервер отримує це широкомовне повідомлення і надсилає у відповідь теж широкомовний ІР-пакет, але на МАС-адресу певного пристрою. Якщо клієнт знаходить свою власну МАС-адресу у полі „адреса призначення" та широкомовну адресу у полі „IP-адреса призначення", він зберігає інформацію, яка міститься у ВООТР-повідомленні.

Формат ВООТР-пакету:



Ор операційний код повідомлення. Може приймати значення BOOTREQUEST або BOOTREPLY.

Htype тип фізичної адреси

Hlen довжина фізичної адреси

Hops клієнт встановлює в 0. Це поле використовується сервером для надсилання запиту в іншу мережу.

Xid ідентифікатор транзакції

Seconds час, який пройшов з моменту початку узгодження IP-адреси

dadder IP-адреса клієнта

Yiadder „ваша" (клієнта) IP-адреса

Siadder IP-адреса наступного сервера, який використовується у процесі роботи

Gladder IP-адреса довірчого агента (при використанні завантаження через довірчого агента, протокол SNMP)

Chadder фізична адреса клієнта

Server Host Name ім'я сервера, від якого отримано IP-адресу

Boot File Name дозволяє використовувати декілька ВООТР-файлів при завантаженні кількох операційних

систем

Vendor Specific Area містить необов'язкову інформацію, яка може бути надана клієнту.

Після формування ВООТР-запиту клієнт інкапсулює його у пакет, який в полі адреси отримувача містить широкомовну адресу, а в полі адреси відправника - значення „невідомо". Потім цей пакет вкладається в кадр, де поле адреси відправника містить МАС-адресу клієнта, а поле адреси отримувача - широкомовну. Цей кадр обробляється всіма вузлами мережі, але лише ВООТР-сервер може розпізнати у полі „ор" значення ВООТР-запиту і вірно створити ВООТР-відповідь. Всі інші вузли просто відкидають його. Сервер готує відповідь, куди включає необхідну інформацію. При формуванні пакету IP-адреса все ще виставляється широкомовною, оскільки клієнт все ще не знає своєї логічної адреси. При формуванні кадру заповнюється як поле адреси відправника (МАС-адреса сервера) так і поле адреси отримувача (МАС-адреса клієнта). При отриманні кадру клієнт передає його для обробки мережевому рівню. Детектувавши широкомовну IP-адресу, протоколи мережевого рівня приймають цей пакет і передають його для обробки на транспортний рівень. Там визначається, що це відповідь на ВООТР-запит, станції присвоюється IP-адреса та зберігається вся інша інформація, яка містилася у повідомленні.

54

Протокол DHCP (dynamic host configuration protocol) - це наступник ВООТР у великих гетерогенних мережах.
Він дозволяє повністю автоматизувати процес отримання IP-адреси; адміністратору залишається лише вказати межі
використовуваних IP-адрес. При використанні цього протоколу вся мережева конфі|урація може бути отримана у
одному повідомленні. /

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

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

1. Клієнт завантажує обмежену версію TCP/IP і відправляє запит DHCPDISCOVER на отримання IP-адреси в
   даній мережі. Запит містить апаратну адресу відправника.
   
2. Всі DHCP-сервери даної мережі надсилають широкомовне повідомлення DHCPOFFER, яке містить
   пропоновану IP-адресу, маску підмережі, тривалість терміну призначення адреси і IP-адресу сервера. Також
   сервер резервує дану IP-адресу на випадок згоди.
   
3. Клієнт обирає першу отриману IP-адресу і надсилає повідомлення DHCPREQUEST всім серверам. Вони
   звільняють зарезервовані адреси.
   
4. Сервер, адресу якого прийнято, відправляє повідомлення DHCPACK з IP-адресою, маскою підмережі та
   іншою інформацією (час оренди адреси). Клієнт, який отримав це повідомлення, зберігає дані і може
   працювати в мережі.
   

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

DHCP підтримує 3 способи адресації: динамічний автоматичний розподіл ручний статичний розподіл автоматичний статичний розподіл

У першому випадку DHCP-сервер видає адресу клієнту на певний обмежений час, який називається часом оренди (lease duration), що дає можливість у подальшому повторно використовувати цю ж адресу.

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

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

У якості транспорта DHCP використовує UDP. Цей протокол є досить розповсюдженим і зручним у використанні; більшість виробників впроваджують його підтримку у своїх продуктах (наприклад, WinNT 3.5 і вище мають вбудовану підтримку DHCP-сервера, Win'95 і вище можуть виступати DHCP-клієнтом.

Недоліки:

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

Формат пакету DHCP:

Op операційний код повідомлення. Може приймати значення 1 (запит) або 2 (відповідь)

Шуре тип фізичної адреси

Hlen довжина фізичної адреси

Hops клієнт встановлює в 0. Це поле використовується сервером для надсилання запиту в іншу мережу.

Xid ідентифікатор транзакції

Seconds час, який пройшов з моменту початку узгодження IP-адреси

Flags лівий біт поля використовується в якості прапора широкомовного повідомлення, решта не

використовуються і рівні 0.

Ciadder IP-адреса клієнта Yiadder „ваша" (клієнта) IP-адреса

Siadder IP-адреса наступного сервера, який використовується у процесі роботи

Giadder IP-адреса довірчого агента (при використанні завантаження через довірчого агента, протокол
SNMP)

Chadder фізична адреса клієнта

Server Host Name ім'я сервера, від якого отримано IP-адресу

Boot File Name ім'я файла завантаження

Vendor Specific Area містить необов'язкову інформацію, яка може бути надана клієнту.



55, 56, 57

2.2.3. Поштові протоколи SMTP, РОР3, ІМАР4.

Розглянемо найбільш розповсюджені типи форматів поштових повідомлень та їх взаємодію між собою.

Будь-яке поштове повідомлення складається з конверта повідомлення і тіла повідомлення. Конверт містить інформацію, необхідну для доставки та обробки повідомлення. Тіло повідомлення містить інформацію, яку відправник передає отримувачу. Всі поштові системи використовують інформацію з тіла повідомлення для побудови конверта.

У найпростішому випадку конверт складається лише із заголовка. Кожен рядок заголовка містить ім’я поля заголовка і дані поля заголовка. Ім’я поля відділяється від даних символом „:”. Мінімальний заголовок обов’язково повинен містити наступні поля:

• „From:” - містить адресу відправника. Як правило, цей ідентифікатор встановлюється у параметрах настройки програми поштового клієнта. Дане поле може містити кілька адрес відправників, від імені яких було відправлено поштове повідомлення.
  
• „То:” – містить адресу (адреси) отримувача (отримувачів) повідомлення. Будь-яке повідомлення мусить містити або поле „То:”, або поле „Сс:”, яке містить адреси отримувачів копій даного повідомлення.
  
• “Date:” – містить дату відправки повідомлення поштовою системою. Воно містить дату, час та часову зону. Формат дати також залежить від поштової системи.
  

Наступні поля є необов’язковими.

• “Subject:” – містить тему даного повідомлення, заповнюється користувачем самостійно залежно від інформаційної частини повідомлення.
  
• “Message-Id:” – містить унікальний ідентифікатор повідомлення. Він використовується для посилань інших повідомлень на дане і ідентифікації частин даного повідомлення. Склад ідентифікатора визначається типом поштової системи і, як правило, складається з рядка символів і адреси хоста відправника.
  
• “Reply-To:” – містить адресу поштового ящика, куди слід направляти відповіді на дане повідомлення. Відповіді на повідомлення, в заголовку якого міститься це поле, направляються за вказаною в ньому адресою. Якщо дане поле відсутнє, то відповіді направляються за адресою, вказаною в полі „From:”.
  
• “Received:” – поле добудовується при проходженні через проміжні сервери і містить поля з адресами і часом обробки повідомлення проміжними серверами.
  

Також заголовок може містити записи типу і версії програмного забезпечення клієнта (“X-Mailer:”), коментарі (“Comments:”), пріоритетність (“Priority:”) та ін.

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

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

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

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

Тому для більш зручної роботи з складеними і нестандартними (не ASCII) повідомленнями було розроблено стандарт МІМЕ (Multipurpose Internet Mail Extension, багатоцільове розширення електронної пошти).

Повідомлення побудовано із використанням МІМЕ, якщо у ньому присутні наступні поля:

• “MIME-Version:” – поле містить рядок версії МІМЕ розширення даного повідомлення.
  
• „Content-Type:” – вказує на склад повідомлення:
  
  1. „text” – повідомлення містить текстову інформацію у вигляді послідовності символів із набору, вказаного параметром „charset” (us-ascii, iso-8859-1, koi8-r, windows-1251 та ін.)
     
  2. „multipart” – означає, що дане повідомлення складається з кількох окремих блоків, кожен з яких описує свій склад самостійно.
     
  3. “application”, “image”, “video”, “audio” – означає, що повідомлення містить двійкові дані певного типу.
     
  4. “message” – повідомлення містить інше повідомлення.
     
• “Content-Transfer-Encoding” – містить ідентифікатор типу кодування, яка використовується у даному повідомленні або його частині.
  

56

Протокол SMTP.

Основним протоколом роботи з електронною поштою є SMTP (Simple Mail Transfer Protocol, простий протокол передачі пошти). Він служить для достовірної та надійної передачі повідомлень між хостами мережі Інтернет. SMTP – протокол прикладного рівня, тому над модулем SMTP, як правило, знаходиться поштова служба організації.

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

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

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

Схеми роботи SMTP-протоколу виглядає наступним чином:

1. Після встановлення каналу SMTP-з’єднання по будь-якому із транспортних протоколів відправник SMTP посилає команду MAIL, яка ідентифікує атрибути відправника пошти, наприклад, його адресу. Якщо отримувач SMTP може прийняти поштове повідомлення, він відправляє у відповідь команду ОК.
   
2. Після цього відправник SMTP відправляє команду RCPT, яка ідентифікує атрибути отримувача пошти, наприклад, адресу поштової скриньки. Якщо отримувач SMTP готовий прийняти пошту в дану поштову скриньку, він відправляє командою ОК, якщо ні, він відповідає відмовою прийняти пошту у вказану поштову скриньку. Якщо віправник вказав кілька поштових скриньок, в які слід помістити повідомлення, то отримувач SMTP відмовити частині з них, при цьому транзакція з’єднання не закінчується.
   
3. Віправник SMTP відправляє дані отримувачу SMTP. Якщо отримувач успішно прийняв всі дані, він відправляє команду ОК.
   

SMTP підтримує кілька механізмів передачі пошти: напрямі від вузла користувача-відправника до вузла користувача-отримувача, коли ці вузли з’єднані між собою напряму через один і той же транспортний сервіс; або через сервери SMTP, коли відправник і отримувач не можуть з’єднуватися напряму. Ці сервери виконують роль проміжних пунктів пересилання повідомлень. SMTP-сервери приймають всю пошту, яка на них поступає і потім самостійно переправляють її адресату. Цей процес називається ретрансляцією повідомлень.

В якості транспортного SMTP використовує ТСР протокол, 25 порт.

57

Протокол РОР3. Для невеликих організацій невигідно тримати у себе систему для передачі повідомлень. Це пов’язано з тим, що у невеликих організаціях, які не спеціалізуються на комп’ютерних технологіях, робочі станції клієнтів мережі не мають достатньо ресурсів для забезпечення роботи повного SMTP-сервера. Крім того, таким користувачам електронної пошти може бути невигідно тримати ПК постійно під’єднаним до Інтернет.

Для вирішення цієї проблеми було розроблено поштовий протокол для роботи в офісі – РОР (Post Office Protocol). Його найбільш розповсюджений варіант – РОР3. Цей протокол дозволяє робочим станціям динамічно отримувати доступ до своїх поштових ящиків, розташованих на сервері, призначеному для обслуговування електронної пошти в даній організації.

РОР3 – це найпростіший протокол для роботи користувача з вмістом своєї поштової скриньки. Він дозволяє лише забрати пошту з поштової скриньки сервера на робочу станцію клієнта та видалити її з поштової скриньки на сервері. Всю подальшу обробку поштове повідомлення проходить на комп’ютері клієнта.

РОР3-сервер не відповідає за відправку пошти, він працює лише як універсальна поштова скринька для групи користувачів. Коли користувачу необхідно відправити повідомлення, він повинен встановити з’єднання з SMTP-сервером і відправити туди своє повідомлення по SMTP. Цей SMTP-сервер може бути тим же вузлом, на якому працює РОР3-сервер, а може бути розташований в іншому місці.

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

РОР3-сервіс, як правило, встановлюється на 110-й ТСР-порт сервера, який знаходиться в режимі очікування вхідного повідомлення. Коли клієнт хоче скористатися РОР3-сервісом, він просто встановлює ТСР-з’єднання з портом 110 цього вузла. Після встановлення з’єднання РОР3 відправляє клієнту повідомлення про під’єднання, і можна починати обмін командами і даними. Після закінчення обміну РОР3-канал закривається.