PPP

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

PPP (англ. Point-to-Point Protocol) — протокол точка-точка, який має набір стандартних протоколів, що забезпечують взаємодію програмного забезпечення віддаленого (дистанційного) доступу від різних постачальників. За допомогою підключення з підтримкою РРР можна виробляти підключення до віддалених мереж через будь-який сервер РРР, що підтримує цей промисловий стандарт. РРР також дозволяє комп'ютеру, на якому функціонує служба віддаленого доступу Windows 2000 Server, приймати запити і забезпечувати доступ до мережі клієнтам з програмним забезпеченням віддаленого доступу третіх фірм, відповідним стандартам РРР. Стандарти РРР також відкривають додаткові можливості, недоступні при старіших стандартах, наприклад, Slip. Більшість реалізацій РРР дозволяють повністю автоматизувати послідовність входу в систему.

Протокол канального рівня мережевої моделі OSI.

PPP — це механізм для створення й запуску IP (Internet Protocol) й інших мережевих протоколів на послідовних лініях зв'язку — прямий послідовний зв'язок (по нуль-модемному кабелю), зв'язок поверх Ethernet або модемний зв'язок по телефонних лініях.

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

Протокол РРР є основою для всіх протоколів другого рівня. Зв'язок по протоколу РРР складається із чотирьох стадій: встановлення зв'язку (здійснюється вибір протоколів аутентифікації, шифрування, стиснення і встановлюються параметри з'єднання), визначення автентичності користувача (реалізуються алгоритми аутентифікації, на основі протоколів РАР, CHAP або MS-CHAP), контроль повторного виклику РРР (необов'язкова стадія, у якій підтверджується справжність віддаленого клієнта), виклик протоколу мережевого рівня (реалізація протоколів установлених на першій стадії). PPP включає IP, IPX й NetBEUI пакети всередині PPP кадрів.

Зазвичай використовується для встановлення прямих з'єднань між двома вузлами. Широко застосовується для з'єднання комп'ютерів за допомогою телефонної лінії. Також використається поверх широкосмугових з'єднань. Багато хто з провайдерів використлвують PPP для надання комутованого доступу в Інтернет.

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

РРР забезпечує метод передачі дейтаграм через послідовні канали зв'язку з безпосереднім з'єднанням типу «точка-точка» (point-to-point). Він включає три основні компоненти:

1. Метод інкапсуляції (метод формування дейтаграмм для передачі по послідовних каналах). РРР як базис для формування дейтаграмм при проходженні через канали з безпосереднім з'єднанням використовує кадри, подібні до кадрів процедури HDLC (High-level Data Link Control — управління каналом передачі даних високого рівня).
2. Розширюваний протокол контролю каналу LCP (Link Control Protocol). LCP призначений для організації, вибору конфігурації і перевірки з'єднання каналу передачі даних.
3. Сімейство протоколів контролю мережі NCP (Network Control Protocols). Служить для організації і вибору конфігурації різних протоколів мережевого рівня.

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

RFC 1994 описує Challenge-handshake authentication protocol (CHAP), який є найкращим для з'єднань з провайдерами. Вже застарілий Password authentication protocol (PAP) все ще іноді використовується.

Іншим варіантом аутентифікації через PPP є розширений протокол аутентифікації (EAP — Extensible Authentication Protocol).

Після того, як з'єднання було встановлено, поверх нього може бути налаштована додаткова мережа. Зазвичай використовується Internet Protocol Control Protocol (IPCP), хоча Internetwork Packet Exchange Control Protocol (IPXCP) і AppleTalk Control Protocol (ATCP) були колись популярні. Internet Protocol Version 6 Control Protocol (IPV6CP) отримає більше поширення в майбутньому, коли IPv6 замінить IPv4 як основний протокол мережного рівня.

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

РРР використовує принципи, термінологію і структуру блоку даних процедур HDLC (ISO 3309-1979) Міжнародної організації по стандартизації (ISO — International Organization for Standardization), модифікованих стандартом ISO 3309-1984/PDAD1 «Addendum 1:start/stop Trasmission». ISO 3309-1979 визначає структуру блоку даних HLDC для вживання в синхронних оточеннях. ISO 3309-1984/PDAD1 визначає запропоновані для стандарту ISO 3309-1979 модифікацій, які дозволяють його використання в асинхронних оточеннях. Процедури управління РРР використовують визначення і кодування керівників полів, стандартизованих ISO 4335-1979 і ISO 4335-1979/addendum 1-1979. Протокол PPP розроблений для каналів зв'язки, які транспортують пакети між двома одноранговими об'єктами. Ці канали забезпечують повнодуплексне одночасне двонаправлене функціонування і передають пакети у відповідному порядку. Передбачається, що PPP забезпечить загальне рішення для нескладного зв'язку широкої різноманітності хостов, мостів і маршрутизаторів.

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

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

РРР може працювати через будь-який інтерфейс DTE/DCE (наприклад, EIA RS-232-c, EIA RS-422, EIA RS-423 і МСЕ-Т V.35). Єдиною абсолютною вимогою, яка пред'являє РРР, є вимога забезпечення дубльованих схем (або спеціально призначених, або перемиканих), які можуть працювати як в синхронному, так і в асинхронному послідовному режимі, прозорому для блоків даних канального рівня РРР. Протокол РРР не пред'являє яких-небудь обмежень, що стосуються швидкості передачі інформації, окрім тих, які визначаються використовуваним інтерфейсом DTE/DCE.

Ці пакети використовуються для досягнення працездатності кожній з фаз LCP:

• Пакети для організації каналу зв'язку: Використовуються для організації і вибору конфігурації каналу.
• Пакети для завершення дії каналу: Використовуються для завершення дії каналу зв'язку.
• Пакети для підтримки працездатності каналу: Використовуються для підтримки і відладки каналу.

PPP дозволяє працювати декільком протоколам мережного рівня на одному каналі зв'язку. Іншими словами, всередині одного PPP-з'єднання можуть передаватися потоки даних різних мережевих протоколів (IP, IPX Novell і т. д.), а також дані протоколів канального рівня локальної мережі. Для кожного мережевого протоколу використовується протокол управління мережею (NCP) який його конфігурує (погоджує деякі параметри протоколу).

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

Інкапсуляція PPP забезпечує мультиплексування різних протоколів мережевого рівня одночасно в одному і тому ж каналі (ланці передачі даних — ЗПД). Метод інкапсуляції PPP розроблений для збереження сумісності з найчастіше використовуваними апаратними засобами підтримки.

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

• Link Control Protocol встановлює і завершує з'єднання, дозволяючи вузлам визначати налаштування з'єднання. Також він підтримує і байт-, і біт-орієнтовані кодування.
• Протокол управління мережею (Network Control Protocol) використовується для визначення налаштувань мережевого рівня, таких як мережева адреса або налаштування стиснення, після того як з'єднання було встановлено.

Щоб встановити з'єднання по каналу типу «точка-точка», кожне закінчення каналу PPP повинне спочатку послати пакети LCP, щоб конфігурувати і протестувати канал даних. Після того, як зв'язок встановлений, одноранговий об'єкт може бути підданий аутентифікації. Потім PPP повинен послати пакети NCP, щоб вибрати і конфігурувати один або більш за протоколи мережевого рівня. Якщо кожен з вибраних протоколів мережевого рівня конфігурований, то по даному каналу з кожного протоколу мережевого рівня можна посилати дейтаграмми. Канал залишатиметься конфігурованим для зв'язку до тих пір, поки пакети LCP або NCP явно не закриють його або доки не станеться деяка зовнішня подія (завершення роботи неактивного таймера або втручання адміністратора мережі.

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

Зв'язок обов'язково починається і закінчується в стадії «Вимкнено». Коли зовнішня подія вказує, що фізичний рівень до використання готовий, PPP переходить до стадії «Встановлення зв'язку». У перебігу цієї стадії автомат LCP (розглядається нижчим) знаходиться в станах «Початкове» або «Старт». Перехід до стадії «Встановлення зв'язку» виконується по сигналу «Включення» автомату LCP. Примітка: Зазвичай, зв'язок повертається в цю стадію автоматично після роз'єднання модему. В разі інтенсивної роботи, ця стадія може бути надзвичайне короткою — лише для того, щоб виявити присутність пристрою.

Щоб встановити зв'язок, використовується протокол LCP шляхом обміну пакетами вибору конфігурації. При завершенні обміну LCP входить в стан «Відкрито» (коли пакет «Запит конфігурації», описаний нижче, був посланий і отриманий). Всі опції конфігурації, якщо вони не змінені при узгодженні конфігурації, мають значення за умовчанням. Поважно відмітити, що з використанням LCP конфігуруються лише ті опції конфігурації, які є незалежними від специфічних протоколів мережевого рівня. Конфігурація індивідуальних протоколів мережевого рівня виконується відповідно до окремих протоколів контролю мережі (NCP) протягом стадії «Протокол мережевого рівня». Будь-які пакети, не відповідні протоколу LCP, отримані протягом цієї стадії, мають бути скинуті без повідомлення. Здобуття запиту конфігурації LCP викликає перехід із стадій «Протокол мережевого рівня» або «Аутентифікація» до стадії «Встановлення зв'язку».

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

Коли PPP завершує попередні стадії, кожен протокол мережевого рівня (такий як IP, IPX або AppleTalk) має бути індивідуально конфігурований згідно з відповідним протоколом контролю мережі (NCP). Кожен NCP може бути відкритий і закритий у будь-який час. Після того, як NCP досяг стану «Відкрито», PPP передаватиме відповідні пакети протоколу мережевого рівня. Будь-які пакети протоколу мережевого рівня, отримані, коли NCP не знаходиться в стані «Відкрито», мають бути скинуті без повідомлення.

PPP може розірвати зв'язок у будь-який час. Це може статися через втрату носія, невизнання достовірності при аутентифікації, незадовільну якість зв'язку, виділення таймера незайнятого періоду або адміністративне закриття зв'язку. LCP закриває зв'язок шляхом обміну пакетами роз'єднання. Коли зв'язок закривається, PPP інформує протоколи мережевого рівня, щоб вони виконали відповідні дії. Після обміну пакетами роз'єднання додатку для ініціалізації завершення зв'язку слід сигналізувати фізичному рівня про роз'єднання, особливо в разі невизнанні достовірності при аутентифікації. Відправникові запиту роз'єднання слід відокремитися після здобуття підтвердження роз'єднання або після того, як витече лічильник перезапуску. Приймачу запиту на роз'єднання слід чекати, поки одноранговий об'єкт не відокремиться; він не повинен відокремлюватися до тих пір, поки після підтвердження роз'єднання не пройдет принаймні один період перезапуску. PPP слід перейти до стадії «Вимкнено». Будь-який пакет не LCP, отриманий протягом цієї стадії, має бути скинутий без повідомлення. Закриття каналу зв'язку за допомогою LCP є достатнім. Посилати потік пакетів роз'єднання в кожному NCP немає необхідності. Більш того, той факт, що один NCP закрився, не є достатньою причиною для роз'єднання каналу PPP, навіть якщо цей NCP був єдиним в той момент в стані «Відкрито».^[1]

• PPPoE

The Point-to-Point Protocol (PPP) [Архівовано 9 січня 2014 у Wayback Machine.]

Це незавершена стаття про комп'ютерні мережі. Ви можете допомогти проєкту, виправивши або дописавши її.