
- •1. Еволюція обчислювальних систем.
- •2. Обчислювальні мережі як частковий випадок розподілених систем (систем телеобробки).
- •1. Мережі еом локальні.
- •1.1. Основні поняття та визначення.
- •1.2. Ієрархічна організація мереж.
- •1.3. Еталонна модель взаємодії відкритих систем iso/osi.
- •1.4. Модель та протокольний граф тср/ір.
- •1.5. Фізичний рівень.
- •1.5.1. Передача сигналів у середовищі.
- •1.5.2. Перешкоди, шуми, спотворення.
- •1.5.3. Основні типи середовищ передачі даних.
- •1.5.4. Основні фізичні топології локальних мереж.
- •1.5.5. Алгоритм роботи пристроїв фізичного рівня.
- •1.6. Канальний рівень.
- •1.6.1. Структура канального рівня.
- •1.6.3. Пристрої канального рівня.
- •1.6.3.1. Поняття мас-адресації.
- •1.6.3.2. Поняття домену колізій та широкомовного домену.
- •1.6.3.3. Пристрої канального рівня та їх вплив на трафік мережі.
- •1.6.4. Методи доступу до середовища.
- •1.6.4.1. Колективний метод доступу до середовища (csma/cd)
- •1.6.4.2. Маркерний метод доступу до середовища (Token passing)
- •1.6.5. Протоколи канального рівня.
- •1.6.5.1. Мережі Ethernet.
- •1000-Мегабітні версії Ethernet. (Gigabit Ethernet)
- •1.6.5.2 Мережі Token Ring
- •1.5.5.3 Мережі fddi
- •1.7. Мережевий рівень.
- •1.7.1. Функції мережевого рівня.
- •1.7.2. Логічна адресація.
- •1.7.2.1. Класи ір-адрес.
- •1.7.2.2. Спеціальні ір – адреси.
- •1.7.2.3. Маски ір-адрес.
- •1.7.2.4. Безкласова адресація та створення підмереж.
- •1.7.3. Протокол ір.
- •1.7.3.1. Робота протоколу ір.
- •1.7.3.2. Функції ір.
- •1.7.4. Маршрутизація.
- •1.7. Транспортний рівень.
- •1.7.1. Функції транспортного рівня.
- •1.7.2. Технології управління потоком даних.
- •1.7.3. Протоколи транспортного рівня.
- •1.7.3.1. Протокол тср.
- •1.7.3.2. Формат тср-сегменту.
- •1.7.3.3. Протокол udp
- •1.7.3.4. Формат udp-сегменту.
- •1.8. Сеансовий рівень.
- •1.8.1. Функції сеансового рівня.
- •1.8.2. Процедури tws та twa.
- •1.9. Представницький рівень
- •1.10. Прикладний рівень
- •2. Протокольний стек тср/ір.
- •2.1. Призначення протокольного стеку тср/ір.
- •2.2. Протоколи стеку тср/ір.
- •2.2.1 Протоколи arp та proxy arp.
- •2.2.3. Поштові протоколи smtp, рор3, імар4.
- •2.2.4. Протоколи моніторингу та управління мережею snmp, icmp.
- •2.2.5. Протокол нттр.
- •2.3. Діагностика та управління мережею з допомогою утиліт на основі протоколу icmp.
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:” – вказує на склад повідомлення:
„text” – повідомлення містить текстову інформацію у вигляді послідовності символів із набору, вказаного параметром „charset” (us-ascii, iso-8859-1, koi8-r, windows-1251 та ін.)
„multipart” – означає, що дане повідомлення складається з кількох окремих блоків, кожен з яких описує свій склад самостійно.
“application”, “image”, “video”, “audio” – означає, що повідомлення містить двійкові дані певного типу.
“message” – повідомлення містить інше повідомлення.
“Content-Transfer-Encoding” – містить ідентифікатор типу кодування, яка використовується у даному повідомленні або його частині.
56
Протокол SMTP.
Основним протоколом роботи з електронною поштою є SMTP (Simple Mail Transfer Protocol, простий протокол передачі пошти). Він служить для достовірної та надійної передачі повідомлень між хостами мережі Інтернет. SMTP – протокол прикладного рівня, тому над модулем SMTP, як правило, знаходиться поштова служба організації.
SMTP – це незалежний від транспортної підсистеми протокол, для роботи якого необхідна лише наявність транспортного каналу передачі потоку даних. Він може працювати по будь-якому транспортному каналу, який задовільняє вимогам до передачі даних через різні мережі або групи мереж.
Протокол SMTP забезпечує як передачу повідомлень на адресу одного отримувача, так і тиражування кількох копій повідомлення для передачі на різні адреси.
Модель роботи SMTP. Протокол SMTP спроектовано на основі наступної моделі взаємодії: на запит користувача відправник SMTP встановлює двосторонній канал з отримувачем SMTP. Отримувачем SMTP може бути як вузол призначення поштового повідомлення, так і який-небудь проміжний вузол. Команди SMTP генеруються відправником і відправляються отримувачу SMTP, який, в свою чергу, відправляє відповіді обробки отриманих команд відправнику SMTP.
Схеми роботи SMTP-протоколу виглядає наступним чином:
Після встановлення каналу SMTP-з’єднання по будь-якому із транспортних протоколів відправник SMTP посилає команду MAIL, яка ідентифікує атрибути відправника пошти, наприклад, його адресу. Якщо отримувач SMTP може прийняти поштове повідомлення, він відправляє у відповідь команду ОК.
Після цього відправник SMTP відправляє команду RCPT, яка ідентифікує атрибути отримувача пошти, наприклад, адресу поштової скриньки. Якщо отримувач SMTP готовий прийняти пошту в дану поштову скриньку, він відправляє командою ОК, якщо ні, він відповідає відмовою прийняти пошту у вказану поштову скриньку. Якщо віправник вказав кілька поштових скриньок, в які слід помістити повідомлення, то отримувач SMTP відмовити частині з них, при цьому транзакція з’єднання не закінчується.
Віправник 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-канал закривається.
Протокол ІМАР4. Протокол ІМАР4 (Internet Message Access Protocol, version 4, протокол доступу до електронної пошти Інтернет) дозволяє клієнтам отримувати доступ і маніпулювати повідомленнями електронної пошти на сервері.
Суттєвою відмінністю прототолу ІМАР4 від РОР3 є те, що ІМАР4 підтримує роботу з системою каталогів (або папок) повідомлень. ІМАР4 дозволяє управляти каталогами (папками) віддалених повідомлень так само, як ніби вони були розташовані на локальному комп’ютері. ІМАР4 дозволяє клієнту створювати, видаляти та перейменовувати поштові скриньки, перевіряти наявність нових повідомлень та видаляти старі. Завдяки тому, що ІМАР4 підтримує механізм унікальної ідентифікації кожного повідомлення у поштовій папці клієнта, він дозволяє читати з поштової скриньки лише повідомлення, які відповідають певним умовам або їх частині, міняти атрибути окремих повідомлень та переміщати їх.
Структура папок значною мірою залежить від типу поштової системи, але у будь-якій системі у клієнта є спеціальний каталог INBOX, куди потрапляють всі повідомлення, що поступають клієнту.
Протокол ІМАР4 працює поверх транспортного протокола, який забезпечує надійний і достовірний канал передачі даних між клієнтом і сервером ІМАР4. При роботі по ТСР ІМАР4 використовує 143-й порт.
Принцип передачі даних ІМАР4 такий же, як і у інших подібних протоколів. Спочатку клієнт та сервер обмінюються привітаннями. Потім клієнт відправляє на сервер команди та дані. Сервер передає клієнту відповіді на обробку команд і даних. Після завершення обміну канал закривається.
Важливою особливістю протоколу ІМАР4 є те, що взаємодія клієнта з сервером не будується за принципом „запитання-відповідь”. Клієнт може відправити нову команду, не чекаючи відповіді на попередню, якщо ці команди не взаємопов’язані, або відповідь на одну не вплине на результат іншої. Сервер може обробляти кілька команд одночасно і відповідати на кожну з них по її закінченню. При цьому відповідь на більш пізню команду може поступити раніше.
58