Взаємодія мережевих протоколів
Мережевий протокол - це набір правил, що дозволяє здійснювати з'єднання і обмін даними між двома і більше включеними в мережу компьютерамі.Фактично різні протоколи часто описують лише різні сторони одного типу зв'язку; взяті разом, вони утворюють так званий стек протоколів. Назви "протокол" і "стек протоколів" також вказують і на програмне забезпечення, яким реалізується протокол.
Для успішної взаємодії між вузлами необхідна ефективна взаємодія цілого ряду протоколів.
Ці протоколи реалізовані на рівні обладнання і програмного забезпечення кожного мережевого пристрою.
Взаємодію між протоколами можна представити у вигляді стека протоколів. Протоколи в стеці є багаторівневу ієрархію, в якій протокол верхнього рівня залежить від служб протоколів на більш низьких рівнях.
На цьому зображенні показаний стек протоколів з набором первинних протоколів, необхідних для запуску веб-сервера по мережі Ethernet. Нижні рівні стека відповідають за переміщення даних по мережі і надання служб верхніх рівнів. Верхні рівні більшою мірою відповідають за наповнення пересилаються і призначений для користувача інтерфейс.
Рівні протоколів
Найбільш поширеною системою класифікації мережевих протоколів є так звана модель OSI. Відповідно до неї протоколи діляться на 7 рівнів за своїм призначенням - від фізичного (формування і розпізнавання електричних або інших сигналів) до прикладного (API для передачі інформації додатками):
- Прикладний рівень, Application layer - Верхній (7-й) рівень моделі, забезпечує взаємодію мережі й користувача. Рівень дозволяє додаткам користувача доступ до мережних служб, таким як обробник запитів до баз даних, доступ до файлів, пересилання електронних повідомлень. Також відповідає за передачу службової інформації, надає додаткам інформацію про помилки і формує запити до рівня уявлення. Приклад: HTTP, POP3, SMTP.
- Рівень представлення, Presentation layer - 6-й рівень відповідає за перетворення протоколів і кодування / декодування даних. Запити програм, наданих рівня додатків, він перетворює в формат для передачі по мережі, а отримані з мережі дані перетворить у формат, зрозумілий додаткам. На рівні уявлення може здійснюватися стиснення / розпакування або кодування / декодування даних, а також перенаправлення запитів іншому мережному ресурсу, якщо вони не можуть бути оброблені локально.
- Сеансовий рівень, Session layer - 5-й рівень моделі відповідає за підтримання сеансу зв'язку, що дозволяє додаткам взаємодіяти між собою тривалий час. Сеансовий рівень управляє створенням / завершенням сеансу, обміном інформацією, синхронізацією завдань, визначенням права на передачу даних і підтримкою сеансу в періоди неактивності додатків. Синхронізація передачі забезпечується приміщенням в потік даних контрольних точок, починаючи з яких поновлюється процес при порушенні взаємодії.
- Транспортний рівень, Transport layer - 4-й рівень моделі, призначений для доставки даних без помилок, втрат і дублювання в тій послідовності, як вони були передані. При цьому неважливо, які дані передаються, звідки і куди, тобто він надає сам механізм передачі. Блоки даних він розділяє на фрагменти, розмір яких залежить від протоколу, короткі об'єднує в один, а довгі розбиває. Протоколи цього рівня призначені для взаємодії типу точка-точка. Приклад: TCP, UDP.
- Мережевий рівень, Network layer - 3-й рівень мережної моделі OSI, призначений для визначення шляху передачі даних. Відповідає за трансляцію логічних адрес і імен у фізичні, визначення найкоротших маршрутів, комутацію і маршрутизацію, відстеження неполадок і заторів в мережі. На цьому рівні працює такий мережний пристрій, як маршрутизатор.
- Канальний рівень, Data Link layer - цей рівень призначений для забезпечення взаємодії мереж на фізичному рівні і контролю за помилками, які можуть виникнути. Дані, отримані з фізичного рівня, він упаковує у фрейми, перевіряє на цілісність, якщо потрібно виправляє помилки і відправляє на мережевий рівень. Канальний рівень може взаємодіяти з одним або декількома фізичними рівнями, контролюючи і керуючи цим взаємодією. Специфікація IEEE 802 розділяє цей рівень на 2 підрівні - MAC (Media Access Control) регулює доступ до поділюваного фізичного середовища, LLC (Logical Link Control) забезпечує обслуговування мережного рівня. На цьому рівні працюють комутатори, мости. У програмуванні цей рівень представляє драйвер мережевої плати, в операційних системах є програмний інтерфейс взаємодії канального і мережевого рівнів між собою, це не новий рівень, а просто реалізація моделі для конкретної ОС. Приклади таких інтерфейсів: ODI, NDIS.
- Фізичний рівень, Physical layer - найнижчий рівень моделі, призначений безпосередньо для передачі потоку даних. Здійснює передачу електричних або оптичних сигналів в кабель або в радіоефір і відповідно їх прийом і перетворення в біти даних відповідно до методами кодування цифрових сигналів. Іншими словами, здійснює інтерфейс між мережним носієм і мережним пристроєм. На цьому рівні працюють концентратори (хаби), повторювачі (ретранслятори) сигналу і автоматизації виробництва. Функції фізичного рівня реалізуються на всіх пристроях, підключених до мережі. З боку комп'ютера функції фізичного рівня виконуються мережевим адаптером або послідовним портом.
 |
| Модель багаторівневої системи протоколів |
Application Programming Interface, API
Прикладний програмний інтерфейс (інтерфейс програмування застосунків, інтерфейс прикладного програмування) (англ. Application Programming Interface, API) — набір визначень взаємодії різнотипного програмного забезпечення. API — це зазвичай (але не обов'язково) метод абстракції між низькорівневим та високорівневим програмним забезпеченням.
Одним з найпоширеніших призначень API є надання набору широко використовуваних функцій, наприклад для малювання вікна чи іконок на екрані. Програмісти використовують переваги API у функціональності, таким чином їм не доводиться розробляти все з нуля. API є абстрактним поняттям — програмне забезпечення, що пропонує деякий API, часто називають реалізацією (англ. implementation) даного API. У багатьох випадках API є частиною набору розробки програмного забезпечення, водночас, набір розробки може включати як API, так і інші інструменти/апаратне забезпечення, отже ці два терміни не є взаємозамінювані.
Високорівневі API часто програють y гнучкості. Виконання деяких функцій нижчого рівня стає набагато складнішим, або навіть неможливим.
Наприклад, в мові Java, якщо програміст хоче використовувати клас "Scanner" (клас, який зчитує інформацію від користувача у програмах, орієнтованих на текстові операції), він імпортує бібліотеку "java.util.Scanner", щоб використовувати методи класу "Scanner" (у даному прикладі nextLine() i close() ). Це приклад з API, що дозволяє взаємодіяти з бібліотеками в мові Java.
import java.util.Scanner;
public class Test {
public static void main(String[] args) {
System.out.println("Enter your name: ");
Scanner input = new Scanner(System.in);
String name = input.nextLine();
System.out.println("Your name is " + name + ".");
input.close();
}
}
public class Test {
public static void main(String[] args) {
System.out.println("Enter your name: ");
Scanner input = new Scanner(System.in);
String name = input.nextLine();
System.out.println("Your name is " + name + ".");
input.close();
}
}
Безліч середовищ розробки програмного забезпечення надають документацію, пов'язану з ППІ (Прикладним Програмним Інтерфейсом) у деяких цифрових форматах, наприклад, Perl поставляється разом з програмою perldoc:
$ perldoc -f sqrt
sqrt EXPR
sqrt #Return the square root of EXPR. If EXPR is omitted, returns
#square root of $_. Only works on non-negative operands, unless
#you've loaded the standard Math::Complex module.
Мова python надає інструмент pydoc:
$ pydoc math.sqrt
Help on built-in function sqrt in math:
math.sqrt = sqrt(...)
sqrt(x)
Return the square root of x.
Help on built-in function sqrt in math:
math.sqrt = sqrt(...)
sqrt(x)
Return the square root of x.
Java поставляється з документацією організованою в HTML сторінки (JavaDoc формат), в той час як Microsoft розподіляє ППІ документацію для своїх мов (Visual C++, C#, Visual Basic, F#, і т. ін.), вбудовані в довідкову систему Visual Studio.
Прикладний програмний інтерфейс у об'єктно-орієнтованих мовах
В об'єктно-орієнтованих мовах, прикладний програмний інтерфейс зазвичай включає в себе опис набору визначень класу, з набором форм поведінки, пов'язаних з цими класами. Це абстрактне поняття пов'язане з реальними функціями, які надані або надаватимуться, класами, які реалізуються в методах класу.
Прикладний програмний інтерфейс в даному випадку можна розглядати як сукупність всіх методів, які публічно доступні в класах (зазвичай званий інтерфейс класу). Це означає, що прикладний програмний інтерфейс вказує методи, за допомогою яких взаємодіє з об'єктами, отриманими з визначень класів і обробляє їх.
У більш загальному плані можна визначити Прикладний Програмний Інтерфейс як сукупність усіх видів об'єктів, які можна вивести з визначення класу, і пов'язаних з ними можливих варіантів поведінки.
Наприклад: клас, що представляє Stack може просто виставити публічно два методи Push() (для додавання нового елемента в стек ) і Pop() (для вилучення останнього пункту, ідеально розташований на вершині стека).
У цьому випадку Прикладний Програмний Інтерфейс може бути інтерпретованим як два способи pop() і push(), або, більш широко використовується варіант, коли можна використовувати елемент типу Stack, який реалізує поведінку стека надаючи йому можливість вершині для додавання / видалення елементів. Друга інтерпретація видається більш доречною в дусі об'єктно-орієнтованого підходу.
Якість документації, пов'язаної з Прикладним Програмним Інтерфейсом є часто ключовим фактором, що визначає його успішність з точки зору простоти використання.
Бібліотеки і платформи прикладних програмних інтерфейсів
ППІ, як правило, пов'язаний із бібліотеками програмного забезпечення: ППІ описує і вказує очікувану поведінку в той час, як бібліотека є фактичною реалізацією даного набору правил. Один ППІ може мати декілька реалізацій (або жодної, будучи абстрактним) у вигляді різних бібліотек, які мають такий же інтерфейс.
Прикладний програмний інтерфейс також може бути пов'язаним з платформами програмування: платформа може бути заснована на кількох бібліотеках реалізує декілька інтерфейсів ППІ, але на відміну від звичайного використання ППІ, доступ до поведінки вбудований в платформу опосередкований шляхом розширення його змісту новими класами і вставлений в саму платформу. Крім того, загальний потік управління програми може бути під контролем абонента.
Прикладний програмний інтерфейс та протоколи
Прикладний програмний інтерфейс може бути також реалізацією протоколу.
Коли ППІ реалізує протокол, він може бути заснованим на проксі-методах віддалених викликів, що засновані на протоколі зв'язку. Роль ППІ може заключатися саме в тому, щоб приховати деталі транспортного протоколу. Наприклад: RMI є ППІ, який реалізує протокол або JRMP IIOP як RMI-IIOP.
Протоколи, як правило, розподіляються між різними технологіями і зазвичай дозволяють різним технологіям обмінюватися інформацією, діючи як абстракція між двома світами. ППІ, як правило, є специфічним для конкретної технології: звідси, інтерфейси даної мови не можуть бути використані на інших мовах, якщо виклики функції не будуть перетворені з конкретної адаптації бібліотеки.
Сокет - це один кінець двостороннього каналу зв'язку між двома програмами, що працюють в мережі. Поєднуючи разом два сокета, можна передавати дані між різними процесами (локальними або віддаленими). Реалізація сокетов забезпечує інкапсуляцію протоколів мережевого і транспортного рівнів.
Спочатку сокети були розроблені для UNIX в Каліфорнійському університеті в Берклі. В UNIX забезпечує зв'язок метод введення-виведення слід алгоритму open / read / write / close. Перш ніж ресурс використовувати, його потрібно відкрити, задавши відповідні дозволи та інші параметри. Як тільки ресурс відкритий, з нього можна зчитувати або в нього записувати дані. Після використання ресурсу користувач повинен викликати метод Close (), щоб подати сигнал операційній системі про завершення його роботи з цим ресурсом.
Коли в операційну систему UNIX були додані кошти взаємодії між процесами (Inter-Process Communication, IPC) і мережевого обміну, був запозичений звичний шаблон введення-виведення. Всі ресурси, відкриті для зв'язку, в UNIX і Windows ідентифікуються дескрипторами. Ці дескриптори, або описатели (handles), можуть вказувати на файл, пам'ять або будь-якої іншої канал зв'язку, а фактично вказують на внутрішню структуру даних, яка використовується операційною системою. Сокет, будучи таким же ресурсом, теж видається дескриптором. Отже, для гнізд життя дескриптора можна розділити на три фази: відкрити (створити) сокет, отримати з сокета або відправити сокету і врешті-решт закрити сокет.
Інтерфейс IPC для взаємодії між різними процесами побудований поверх методів введення-виведення. Вони полегшують для гнізд відправку та отримання даних. Кожен цільовий об'єкт задається адресою сокета, отже, ця адреса можна вказати в клієнті, щоб встановити з'єднання з метою.
Потокові сокети (stream socket)
Потоковий сокет - це сокет з встановленим з'єднанням, що складається з потоку байтів, який може бути двонаправленим, т, е. Через цю кінцеву точку додаток може і передавати, і отримувати дані.
Потоковий сокет гарантує виправлення помилок, обробляє доставку і зберігає послідовність даних. На нього можна покластися в доставці упорядкованих, сдублірованние даних. Потоковий сокет також підходить для передачі великих обсягів даних, оскільки накладні витрати, пов'язані з встановленням окремого з'єднання для кожного повідомлення, що відправляється, може виявитися неприйнятним для невеликих обсягів даних. Потокові сокети досягають цього рівня якості за рахунок використання протоколу Transmission Control Protocol (TCP). TCP забезпечує надходження даних на іншу сторону в потрібній послідовності і без помилок.
Для цього типу сокетів шлях формується до початку передачі повідомлень. Тим самим гарантується, що обидві що у взаємодії сторони приймають і відповідають. Якщо додаток відправляє одержувачу два повідомлення, то гарантується, що ці повідомлення будуть отримані в тій же послідовності.
Однак, окремі повідомлення можуть дробитися на пакети, і способу визначити межі записів не існує. При використанні TCP цей протокол бере на себе розбиття переданих даних на пакети відповідного розміру, відправку їх в мережу і складання їх на іншій стороні. Додаток знає тільки, що воно відправляє на рівень TCP певне число байтів і інша сторона отримує ці байти. У свою чергу TCP ефективно розбиває ці дані на пакети відповідного розміру, отримує ці пакети на іншій стороні, виділяє з них дані і об'єднує їх разом.
Потоки базуються на явних з'єднаннях: сокет А запитує з'єднання з сокетом В, а сокет В або погоджується із запитом на встановлення з'єднання, або відкидає його.
Якщо дані повинні гарантовано доставлятися іншій стороні або розмір їх великий, потокові сокети краще дейтаграмним. Отже, якщо надійність зв'язку між двома додатками має першорядне значення, вибирайте потокові сокети.
Сервер електронної пошти являє приклад програми, яка повинна доставляти зміст в правильному порядку, без дублювання і пропусків. Потоковий сокет розраховує, що TCP забезпечить доставку повідомлень по їх призначень.
Дейтаграммний сокети (datagram socket)
Дейтаграммний сокети іноді називають сокетами без організації з'єднань, т. Е. Ніякого явного з'єднання між ними не встановлюється - повідомлення відправляється вказаною сокету і, відповідно, може виходити від зазначеного сокета.
Потокові сокети в порівнянні з дейтаграммний дійсно дають більш надійний метод, але для деяких додатків накладні витрати, пов'язані з установкою явного з'єднання, неприйнятні (наприклад, сервер часу доби, що забезпечує синхронізацію часу для своїх клієнтів). Зрештою на встановлення надійного з'єднання з сервером потрібен час, яке просто вносить затримки в обслуговування, і завдання серверного додатка не виконується. Для скорочення накладних витрат потрібно використовувати дейтаграммний сокети.
Використання дейтаграмним сокетов вимагає, щоб передачею даних від клієнта до сервера займався User Datagram Protocol (UDP). У цьому протоколі на розмір повідомлень накладаються деякі обмеження, і на відміну від потокових сокетів, які вміють надійно відправляти повідомлення сервера-адресату, дейтаграммний сокети надійність не забезпечують. Якщо дані загубилися десь в мережі, сервер не повідомить про помилки.
Крім двох розглянутих типів існує також узагальнена форма гнізд, яку називають необроблюваних або сирими.
Сирі сокети (raw socket)
Головна мета використання сирих сокетів полягає в обході механізму, за допомогою якого комп'ютер обробляє TCP / IP. Це досягається забезпеченням спеціальної реалізації стека TCP / IP, що заміщає механізм, наданий стеком TCP / IP в ядрі - пакет безпосередньо передається з додатком і, отже, обробляється набагато ефективніше, ніж при проході через головний стек протоколів клієнта.
За визначенням, сирої сокет - це сокет, який приймає пакети, обходить рівні TCP і UDP в стеці TCP / IP і відправляє їх безпосередньо з додатком.
При використанні таких гнізд пакет не проходить через фільтр TCP / IP, тобто ніяк не обробляється, і постає у своїй сирої формі. В такому випадку обов'язок правильно обробити всі дані і виконати такі дії, як видалення заголовків і розбір полів, лягає на отримує додаток - все одно, що включити в додаток невеликий стек TCP / IP.
Однак нечасто може знадобитися програма, що працює з сирими сокетами. Якщо ви не пишете системне програмне забезпечення або програму, аналогічну аналізатору пакетів, вникати в такі деталі не доведеться. Сирі сокети головним чином використовуються при розробці спеціалізованих низькорівневих протокольних додатків. Наприклад, такі різноманітні утиліти TCP / IP, як trace route, ping або arp, використовують сирі сокети.
Робота з сирими сокетами вимагає солідного знання базових протоколів TCP / UDP / IP.
Порти
Порт визначено, щоб вирішити завдання одночасної взаємодії з декількома додатками. По суті з його допомогою розширюється поняття IP-адреси. Комп'ютер, на якому в свій час виконується кілька додатків, отримуючи пакет з мережі, може ідентифікувати цільової процес, користуючись унікальним номером порту, певним при встановленні з'єднання.
Сокет складається з IP-адреси машини і номера порту, що використовується додатком TCP. Оскільки IP-адреса унікальний в Інтернеті, а номери портів унікальні на окремій машині, номери сокетів також унікальні в усьому Інтернеті. Ця характеристика дозволяє процесу спілкуватися через мережу з іншим процесом виключно на підставі номера сокета.
За певними службами номера портів зарезервовані - це широко відомі номери портів, наприклад порт 21, що використовується в FTP. Ваша програма може користуватися будь-яким номером порту, який не був зарезервований і поки не зайнятий. Агентство Internet Assigned Numbers Authority (IANA) веде перелік широко відомих номерів портів.
Зазвичай додаток клієнт-сервер, що використовує сокети, складається з двох різних додатків - клієнта, який ініціює з'єднання з метою (сервером), і сервера, що очікує з'єднання від клієнта.
Наприклад, на стороні клієнта, додаток повинен знати адресу цілі і номер порту. Відправляючи запит на з'єднання, клієнт намагається встановити з'єднання з сервером:
Якщо події розвиваються вдало, за умови що сервер запущений раніше, ніж клієнт спробував з ним з'єднатися, сервер погоджується на з'єднання. Давши згоду, серверний додаток створює новий сокет для взаємодії саме з встановив з'єднання клієнтом:
Тепер клієнт і сервер можуть взаємодіяти між собою, зчитуючи повідомлення кожен зі свого сокета і, відповідно, записуючи повідомлення.
Сокет - це один кінець двостороннього каналу зв'язку між двома програмами, що працюють в мережі. Поєднуючи разом два сокета, можна передавати дані між різними процесами (локальними або віддаленими). Реалізація сокетов забезпечує інкапсуляцію протоколів мережевого і транспортного рівнів.
Спочатку сокети були розроблені для UNIX в Каліфорнійському університеті в Берклі. В UNIX забезпечує зв'язок метод введення-виведення слід алгоритму open / read / write / close. Перш ніж ресурс використовувати, його потрібно відкрити, задавши відповідні дозволи та інші параметри. Як тільки ресурс відкритий, з нього можна зчитувати або в нього записувати дані. Після використання ресурсу користувач повинен викликати метод Close (), щоб подати сигнал операційній системі про завершення його роботи з цим ресурсом.
Коли в операційну систему UNIX були додані кошти взаємодії між процесами (Inter-Process Communication, IPC) і мережевого обміну, був запозичений звичний шаблон введення-виведення. Всі ресурси, відкриті для зв'язку, в UNIX і Windows ідентифікуються дескрипторами. Ці дескриптори, або описатели (handles), можуть вказувати на файл, пам'ять або будь-якої іншої канал зв'язку, а фактично вказують на внутрішню структуру даних, яка використовується операційною системою. Сокет, будучи таким же ресурсом, теж видається дескриптором. Отже, для гнізд життя дескриптора можна розділити на три фази: відкрити (створити) сокет, отримати з сокета або відправити сокету і врешті-решт закрити сокет.
Інтерфейс IPC для взаємодії між різними процесами побудований поверх методів введення-виведення. Вони полегшують для гнізд відправку та отримання даних. Кожен цільовий об'єкт задається адресою сокета, отже, ця адреса можна вказати в клієнті, щоб встановити з'єднання з метою.
Типи сокетів
Існують два основних типи сокетів - потокові сокети і дейтаграммний.Потокові сокети (stream socket)
Потоковий сокет - це сокет з встановленим з'єднанням, що складається з потоку байтів, який може бути двонаправленим, т, е. Через цю кінцеву точку додаток може і передавати, і отримувати дані.
Потоковий сокет гарантує виправлення помилок, обробляє доставку і зберігає послідовність даних. На нього можна покластися в доставці упорядкованих, сдублірованние даних. Потоковий сокет також підходить для передачі великих обсягів даних, оскільки накладні витрати, пов'язані з встановленням окремого з'єднання для кожного повідомлення, що відправляється, може виявитися неприйнятним для невеликих обсягів даних. Потокові сокети досягають цього рівня якості за рахунок використання протоколу Transmission Control Protocol (TCP). TCP забезпечує надходження даних на іншу сторону в потрібній послідовності і без помилок.
Для цього типу сокетів шлях формується до початку передачі повідомлень. Тим самим гарантується, що обидві що у взаємодії сторони приймають і відповідають. Якщо додаток відправляє одержувачу два повідомлення, то гарантується, що ці повідомлення будуть отримані в тій же послідовності.
Однак, окремі повідомлення можуть дробитися на пакети, і способу визначити межі записів не існує. При використанні TCP цей протокол бере на себе розбиття переданих даних на пакети відповідного розміру, відправку їх в мережу і складання їх на іншій стороні. Додаток знає тільки, що воно відправляє на рівень TCP певне число байтів і інша сторона отримує ці байти. У свою чергу TCP ефективно розбиває ці дані на пакети відповідного розміру, отримує ці пакети на іншій стороні, виділяє з них дані і об'єднує їх разом.
Потоки базуються на явних з'єднаннях: сокет А запитує з'єднання з сокетом В, а сокет В або погоджується із запитом на встановлення з'єднання, або відкидає його.
Якщо дані повинні гарантовано доставлятися іншій стороні або розмір їх великий, потокові сокети краще дейтаграмним. Отже, якщо надійність зв'язку між двома додатками має першорядне значення, вибирайте потокові сокети.
Сервер електронної пошти являє приклад програми, яка повинна доставляти зміст в правильному порядку, без дублювання і пропусків. Потоковий сокет розраховує, що TCP забезпечить доставку повідомлень по їх призначень.
Дейтаграммний сокети (datagram socket)
Дейтаграммний сокети іноді називають сокетами без організації з'єднань, т. Е. Ніякого явного з'єднання між ними не встановлюється - повідомлення відправляється вказаною сокету і, відповідно, може виходити від зазначеного сокета.
Потокові сокети в порівнянні з дейтаграммний дійсно дають більш надійний метод, але для деяких додатків накладні витрати, пов'язані з установкою явного з'єднання, неприйнятні (наприклад, сервер часу доби, що забезпечує синхронізацію часу для своїх клієнтів). Зрештою на встановлення надійного з'єднання з сервером потрібен час, яке просто вносить затримки в обслуговування, і завдання серверного додатка не виконується. Для скорочення накладних витрат потрібно використовувати дейтаграммний сокети.
Використання дейтаграмним сокетов вимагає, щоб передачею даних від клієнта до сервера займався User Datagram Protocol (UDP). У цьому протоколі на розмір повідомлень накладаються деякі обмеження, і на відміну від потокових сокетів, які вміють надійно відправляти повідомлення сервера-адресату, дейтаграммний сокети надійність не забезпечують. Якщо дані загубилися десь в мережі, сервер не повідомить про помилки.
Крім двох розглянутих типів існує також узагальнена форма гнізд, яку називають необроблюваних або сирими.
Сирі сокети (raw socket)
Головна мета використання сирих сокетів полягає в обході механізму, за допомогою якого комп'ютер обробляє TCP / IP. Це досягається забезпеченням спеціальної реалізації стека TCP / IP, що заміщає механізм, наданий стеком TCP / IP в ядрі - пакет безпосередньо передається з додатком і, отже, обробляється набагато ефективніше, ніж при проході через головний стек протоколів клієнта.
За визначенням, сирої сокет - це сокет, який приймає пакети, обходить рівні TCP і UDP в стеці TCP / IP і відправляє їх безпосередньо з додатком.
При використанні таких гнізд пакет не проходить через фільтр TCP / IP, тобто ніяк не обробляється, і постає у своїй сирої формі. В такому випадку обов'язок правильно обробити всі дані і виконати такі дії, як видалення заголовків і розбір полів, лягає на отримує додаток - все одно, що включити в додаток невеликий стек TCP / IP.
Однак нечасто може знадобитися програма, що працює з сирими сокетами. Якщо ви не пишете системне програмне забезпечення або програму, аналогічну аналізатору пакетів, вникати в такі деталі не доведеться. Сирі сокети головним чином використовуються при розробці спеціалізованих низькорівневих протокольних додатків. Наприклад, такі різноманітні утиліти TCP / IP, як trace route, ping або arp, використовують сирі сокети.
Робота з сирими сокетами вимагає солідного знання базових протоколів TCP / UDP / IP.
Порти
Порт визначено, щоб вирішити завдання одночасної взаємодії з декількома додатками. По суті з його допомогою розширюється поняття IP-адреси. Комп'ютер, на якому в свій час виконується кілька додатків, отримуючи пакет з мережі, може ідентифікувати цільової процес, користуючись унікальним номером порту, певним при встановленні з'єднання.
Сокет складається з IP-адреси машини і номера порту, що використовується додатком TCP. Оскільки IP-адреса унікальний в Інтернеті, а номери портів унікальні на окремій машині, номери сокетів також унікальні в усьому Інтернеті. Ця характеристика дозволяє процесу спілкуватися через мережу з іншим процесом виключно на підставі номера сокета.
За певними службами номера портів зарезервовані - це широко відомі номери портів, наприклад порт 21, що використовується в FTP. Ваша програма може користуватися будь-яким номером порту, який не був зарезервований і поки не зайнятий. Агентство Internet Assigned Numbers Authority (IANA) веде перелік широко відомих номерів портів.
Зазвичай додаток клієнт-сервер, що використовує сокети, складається з двох різних додатків - клієнта, який ініціює з'єднання з метою (сервером), і сервера, що очікує з'єднання від клієнта.
Наприклад, на стороні клієнта, додаток повинен знати адресу цілі і номер порту. Відправляючи запит на з'єднання, клієнт намагається встановити з'єднання з сервером:
 |
| Запит клієнта серверу |
Якщо події розвиваються вдало, за умови що сервер запущений раніше, ніж клієнт спробував з ним з'єднатися, сервер погоджується на з'єднання. Давши згоду, серверний додаток створює новий сокет для взаємодії саме з встановив з'єднання клієнтом:
 |
| Взаємодія клієнта і сервера |
Тепер клієнт і сервер можуть взаємодіяти між собою, зчитуючи повідомлення кожен зі свого сокета і, відповідно, записуючи повідомлення.
Комментарии
Отправить комментарий