Комп'ютерні мережі

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

Щоправда навіть прикладний рівень потребує службових протоколів, на зразок DNS.

 

30.1. Доменна система імен

Доменна система імен (Domain Name System, DNS) — ієрархічна розподілена система перетворення імені хоста (комп'ютера або іншого мережевого пристрою) в IP-адресу.

Кожен комп'ютер в Інтернеті має свою власну унікальну адресу — число, яке складається з чотирьох (у протоколі IPv4) або шістнадцяти (у протоколі IPv6) байтів. Оскільки запам'ятовування десятків чи навіть сотень номерів — не надто приємна процедура, то всі (чи майже всі) машини мають імена, запам'ятати які (особливо якщо знати правила утворення імен) значно легше.

Уся система імен в Інтернеті — ієрархічна. Це зроблено для того, щоб не підтримувати одне централізоване джерело, а роздати владу на місця.

Повне доменне (domain) ім'я машини (FQDN, Fully Qualified Domain Name) можна розбити на дві частини — ім'я області-домена та власне ім'я машини. Наприклад, m30.ziet.zhitomir.ua — повне доменне ім'я машини m30, яка перебуває у домені ziet.zhitomir.ua.

За порядок у доменах, як правило, відповідає певний комп'ютер, користувачі-адміністратори якого слідкують за тим, щоб не було, наприклад, різних машин з однаковими ІР-адресами. Наприклад, відповідальність за область-домен ziet.zhitomir.ua покладається на машину alpha.ziet.zhitomir.ua Ця влада делегується зверху вниз від машини ns.lucky.net, яка відповідає за домен zhitomir.ua. В свою чергу, відповідальність за область ua делегована машині зверху від так званих кореневих серверів (root server).

Всю цю систему можна уявити у вигляді перевернутого дерева. Список імен доменів верхнього рівня на сайті IANA (https://www.iana.org/domains/root/db). Повний список географічних областей, в основному, відповідає двохбуквеним ISO-кодам країн і його можна знайти, наприклад, на WWW-сервері ISOC (http://www.isoc.org).

Необхідно розрізняти доменне ім'я, та поштову адресу. В поштовій адресі повинен бути знак «@», який в економіці має назву «комерційне at», а в електронній пошті — «равлик». Знак «@» у поштовій адресі відокремлює ім'я поштової скриньки від доменного ім'я. Знак «@» вперше у 1971 році використав Рей Томлінсон, щоб відокремити імена користувача і комп'ютера, коли він відправив повідомлення з одного ДЕК-10 (Digital Equipment Corporation) комп'ютера на інший ДЕК-10. Обидва комп'ютери були розміщені поруч один з одним.

Коли мережа Інтернет була молода та невелика, таблиці відповідності імен та адрес зберігалися у звичайному текстовому файлі, який періодично просто розсилався всім учасникам електронною поштою. Після того, які кількість машин значно збільшилася, така схема перестала ефективно працювати і програмісти університету штату Каліфорнія в Берклі спроектували і написали програму BIND (Berkeley Internet Name Domain), яка відповідає на запити машин користувачів, які стосувалися імен та ІР-адресу.

Служба імен DNS (Domain Name System) — це розподілена база даних доволі простої структури. Для початкового знайомства можна вважати, що це кілька таблиць, у яких записано:

• яку ІР-адресу має машина з певним іменем;
• яке ім'я має машина з визначеною адресою;
• що це за комп'ютер і яка операційна система встановлена на ньому;
• куди потрібно направляти електронну пошту для користувачів цієї машини;
• які псевдоніми є у даної машини.

Для прикладу розглянемо випадок, коли користувач посилає пошту з машини polesye.zhitomir.ua користувачу за адресою rozhik@ziet.zhitomir.ua. При встановленні на машину протоколів TCP/IP системний адміністратор вказує ІР-адресу комп'ютера — найближчого серверу імен. Поштова програма подає цьому найближчому серверу запит: «Куди посилати пошту для ziet.zhitomir.ua» Якщо найближчий сервер не може відповісти, то він, в свою чергу, посилає запит до більш «старшого» серверу. Нарешті, стає зрозумілим, що всю пошту для області ziet.zhitomir.ua необхідно відправляти на машину alpha.ziet.zhitomir.ua або relay2.lucky.net. Разом з цим відповіді містять ще адресу цієї машини. Поштова програма зв'язується з цим комп'ютером (використовуючи не ім'я, а адресу) та передає йому пошту. Всі ці переговори та відправка пошти, як правило, відбувається протягом кількох секунд і користувач не помічає цього. Якщо машина ziet.zhitomir.ua недоступна то тоді пошта на час, в якій неможливо зв'язатися з машиною ziet.zhitomir.ua (наприклад під час профілактики каналу зв'язку) чекає своєї черги на пересилку на машині relay2.lucky.net.

Це характерна для Internet-програм поведінка. Як правило, поштові програми подають доволі багато запитів службі DNS, і ці питання доволі складні. У більшості випадків у програмах користувачів намагаються дізнатися лише одне — яка ІР-адреса у машини з відповідним іменем. Зрозуміло, що всередині цієї системи імен існує маса нюансів, правил та хитрощів. Докладніше з ними можна ознайомитися в описах стандартів Internet або в спеціальних книгах.

Компанія «Хостмастер» спільно з ICANN в Україні ввела у дію локальний кореневий сервер DNS, що містить інформацію про домени верхнього рівня. Сервер є «дзеркалом» одного з 13-кореневих серверів ICANN, відомого під назвою «L-root».

 

30.2. Клієнт-серверна архітектура

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

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

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

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

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

Модель клієнт-серверної взаємодії визначається перш за все розподілом обов'язків між клієнтом та сервером. Логічно можна відокремити три рівні операцій:

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

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

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

 

30.3. BitTorrent

«БітТорент» (BitTorrent) — відкритий протокол обміну інформацією у мережах типу peer-to-peer. Автором проекту є Брам Коен (Bram Cohen), який створив першу версію у квітні 2001 разом із першим клієнтом з тією ж назвою.

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

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

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

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

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

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

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

 

30.4. Secure Shell

Secure Shell, SSH (Secure SHell — «безпечна оболонка») — мережевий протокол рівня застосунків, що дозволяє проводити віддалене управління комп'ютером і тунелювання TCP-з'єднань (наприклад, для передачі файлів). Схожий за функціональністю з протоколом Telnet і rlogin, проте шифрує весь трафік, в тому числі і паролі, що передаються.

Криптографічний захист протоколу SSH не фіксований, можливий вибір різних алгоритмів шифрування. Клієнти і сервери, що підтримують цей протокол, доступні для різних платформ. Крім того, протокол дозволяє не тільки використовувати безпечний віддалений shell на машині, але і туннелювати графічний інтерфейс — X Tunnelling (тільки для Unix-подібних ОС або застосунків, що використовують графічний інтерфейс X Window System). Так само ssh здатний передавати через безпечний канал (Port Forwarding) будь-який інший мережевий протокол, забезпечуючи (при належній конфігурації) можливість безпечної пересилки не тільки X-інтерфейсу, але і, наприклад, звуку.

Підтримка SSH реалізована у всіх UNIX системах, і на більшості з них в числі стандартних утиліт присутні клієнт і сервер ssh. Існує безліч реалізацій SSH-клієнтів і для не-UNIX ОС. Велику популярність протокол отримав після широкого розвитку сніферів, як альтернативне небезпечному телнету рішення для управління важливими вузлами.

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