SCTP (англ. Stream Control Transmission Protocol — «протокол передачі з керуванням потоком») — протокол транспортного рівня в комп'ютерних мережах, створений в 2000 році в IETF. RFC 3286 містить технічний вступ до нього.
Як і будь-який інший протокол передачі даних транспортного рівня, SCTP працює аналогічно TCP або UDP. TCP і UDP працюють настільки по-різному, що проводити аналогію до них обох некоректно. Вся аналогія — в тому, що SCTP, TCP і UDP відносяться до одного і того ж рівня моделі OSI. Але насправді SCTP має в арсеналі широкий спектр приємних[кому?] нововведень, таких як багатопоточність, захист від SYN-flood, а також синхронне з'єднання між двома хостами на двох і більше незалежних фізичних каналах (multi-homing).
Безпечне встановлення підключення Редагувати
Створення нового підключення в протоколах TCP і SCTP відбувається за допомогою механізму підтвердження пакетів. У протоколі TCP ця процедура отримала назву триетапне підтвердження (three-way handshake). Клієнт посилає пакет SYN (скор. Synchronize). Сервер відповідає пакетом SYN-ACK (Synchronize-Acknowledge). Клієнт підтверджує прийом пакета SYN-ACK пакетом ACK. На цьому процедура встановлення з'єднання завершується.
Протокол TCP має потенційну вразливість, обумовлену тим, що порушник, встановивши фальшиву IP-адресу відправника, може послати серверу безліч пакетів SYN. При отриманні пакету SYN сервер виділяє частину своїх ресурсів для встановлення нового з'єднання. Обробка безлічі пакетів SYN рано чи пізно використає всі ресурси сервера і зробить неможливим обробку нових запитів. Така атака отримала назву «відмова в обслуговуванні» (Denial of Service, або скорочено DoS).
Протокол SCTP захищений від подібних атак за допомогою механізму чотирьохетапного підтвердження (four-way handshake) і введенням маркера (cookie). За протоколом SCTP клієнт починає процедуру встановлення з'єднання посилкою пакета INIT. У відповідь сервер посилає пакет INIT-ACK, який містить маркер (унікальний ключ, що ідентифікує нове з'єднання). Потім клієнт відповідає посилкою пакета COOKIE-ECHO, в якому міститься маркер, посланий сервером. Тільки після цього сервер виділяє свої ресурси новому підключенню і підтверджує це відправленням клієнту пакету COOKIE-ACK.
Для вирішення проблеми затримки пересилання даних при виконанні процедури чотирьохетапного підтвердження в протоколі SCTP допускається включення даних в пакети COOKIE-ECHO і COOKIE-ACK.
Поетапне завершення передачі даних Редагувати
Розглянемо відмінності між процедурою закриття сокетів протоколу SCTP і процедурою часткового закриття (half-close) протоколу TCP.
У протоколі TCP можлива ситуація, коли вузол закриває у себе сокет (виконуючи посилку пакету FIN), але продовжує приймати дані. Пакет FIN вказує кореспонденту на відсутність даних для передачі, проте до тих пір, поки кореспондент не закриє свій сокет, він може продовжувати передавати дані. Стан часткового закриття використовується додатками вкрай рідко, тому розробники протоколу SCTP вважали за потрібне замінити його послідовністю повідомлень для розриву існуючої асоціації. Коли вузол закриває свій сокет (надсилає повідомлення SHUTDOWN), обидва кореспонденти повинні припинити передачу даних, при цьому дозволяється лише обмін пакетами, що підтверджують прийом раніше відправлених даних.
Потоки Редагувати
TCP керує послідовністю байт: дані, послані застосунком-відправником, мають надходити до застосунку-одержувача виключно в тому ж порядку (у той час як протокол IP здатний змінити послідовність пакетів; крім того, зниклі пакети надсилаються повторно і зазвичай прибувають до одержувача з порушенням послідовності; для боротьби з цими явищами, дані накопичуються в буфері). SCTP може транспортувати дані між двома точками одночасно за кількома потоками повідомлень. На противагу до TCP, SCTP обробляє цілі повідомлення, а не звичайні байти інформації. Це означає, що якщо відправник відсилає серверу повідомлення, що складається зі 100 байт за перший крок, а за ним ще 50 байт, то одержувач за перший крок отримає саме перші 100 байт в першому повідомленні, а тільки потім і тільки 50 байт на другий операції читання з сокета.
Термін «багатопоточність» (англ. multi-streaming) означає здатність SCTP паралельно передавати по декільком незалежним потокам повідомлень. Наприклад, ми передаємо декілька фотографій через HTTP-застосунок (наприклад браузер). Можна використовувати для цього зв'язок з кількох TCP-з'єднань, однак також є допустимим SCTP-асоціація (англ. SCTP-association), що керує декількома потоками повідомлень для цієї мети.
TCP досягає правильного порядку байт в потоці, абстрактно призначаючи порядковий номер кожного відісланої одиниці, а впорядковуючи прийняті байти, використовуючи призначені порядкові номери, у міру їхнього прибування. З іншого боку, SCTP присвоює різні порядкові номери повідомленням, відісланим в конкретному потоці. Це дозволяє незалежне упорядкування повідомлень з різних потоків. Так чи інакше, багатопоточність є опцією в SCTP. В залежності від бажань користувацького застосунку, повідомлення можуть бути оброблені не в порядку їхнього відправлення, а в порядку їхнього надходження.
Переваги Редагувати
Переваги використання SCTP включають в себе:
- Використання множинних інтерфейсів (англ. Multihoming)
Припустимо, у нас є два хоста і хоча б один з них має декілька мережевих інтерфейсів і, відповідно, кілька IP-адрес. У TCP, поняття «з'єднання» означає обмін даними між двома точками, в той час, як в SCTP має місце концепція «асоціації» (англ. association), що позначає все, що відбувається між двома хостами. - Потік
Дані приходять в точку з незалежних потоків. Це дозволяє усунути феномен en: Head-of-line blocking, яким так страждає TCP. - Пошук шляху з моніторингом
Протоколом вибирається первинний маршрут передачі даних, а також проводиться перевірка і моніторинг зв'язності шляху. - Механізми перевірки дійсності
Захист адресата від flood-атак (технологія 4-way handshake), і повідомлення про втрачені пакети і порушені ланцюжки. - Покращена система контролю помилок, що підходить для jumbo-пакетів в Ethernet.
Частина переваг випливає з того факту, що спочатку розробники SCTP проектували протокол під потреби передачі телефонії (SS7) за протоколом IP.
Причини появи Редагувати
Протокол TCP надає основні засоби для передачі даних по мережі Internet по надійному шляху. Однак TCP накладає деякі обмеження на транспорт даних:
- TCP надає надійну передачу даних у суворій послідовності. Проте одні додатки вимагають передачу без управління і контролю послідовності, а інші будуть цілком задоволені частковою впорядкованістю даних. Обидва цих випадки страждають через непотрібність затримок, пов'язаних з відновленням і впорядкуванням порушених послідовностей TCP.
- Природа TCP орієнтована на потік байт, що викликає незручності. Програми змушені самостійно додавати власні маркери в пакети, щоб распаралелити передачу власних повідомлень, а також використовувати додаткові хитрування, щоб переконатися в тому, що ціле повідомлення було доставлено за певний час.
- Обмежені рамки можливостей TCP- сокетів ще більше ускладнюють завдання надання можливості паралельної передачі інформації до хоста по декількох каналах зв'язку (див.multi-homingвище).
- TCP щодо уразлививості до атак класу «Відмова в обслуговуванні» (DoS), таким як SYN-flood.
Всі ці обмеження наносять шкоду продуктивності роботи телефонних мереж через IP.
Безпека Редагувати
SCTP був розроблений з деякими функціями дозволяють підвищити безпеку, такими як "4-х кратне рукостискання" (у порівнянні з "триразовим рукостисканням" в TCP), щоб запобігти SYN-flood атаки, і великих magic cookie[en] для перевірки автентичності асоціації.
Надійність була одним з ключових аспектів розробки безпеки протоколу SCTP. Multi-homing дозволяє асоціації залишатися відкритою, навіть якщо деякі використовувані маршрути і інтерфейси стали недоступні. Це має особливе значення, який використовуючи SCTP, передає повідомлення та сервіси протоколів ОКС-7 поверх IP мережі, що вимагає сильної стійкості під час відключень лінків для підтримки телекомунікаційних послуг, навіть при серйозних аномаліях в мережі .
Шифрування не є частиною оригінального дизайну SCTP.
SCTP іноді є гарним кандидатом для перевірки на міцність стека TCP/IP. Деякі операційні системи поширюються з підтримкою протоколу SCTP, але зважаючи на його слабку популярність (у порівнянні з TCP або UDP), іноді забувають налаштувати в брандмауері виявлення вторгнень, що дає можливості для сканування трафіку.
Порівняння можливостей протоколів транспортного рівня Редагувати
| Параметр | UDP | TCP | SCTP |
|---|---|---|---|
| Встановлення зв'язку | Ні | Так | Так |
| Надійна передача | Ні | Так | Так |
| Збереження меж повідомлення | Так | Ні | Так |
| Впорядкована доставка | Ні | Так | Так |
| Невпорядкована доставка | Так | Ні | Так |
| Контрольні суми даних | Так | Так | Так |
| Розмір контрольної суми (біт) | 16 | 16 | 32 |
| Шлях MTU | Ні | Так | Так |
| Управління нагромадженням | Ні | Так | Так |
| Багатонитевість | Ні | Ні | Так |
| Підтримка декількох інтерфейсів | Ні | Ні | Так |
| Поєднання потоків | Ні | Так | Так |
Формування кадрів повідомлення Редагувати
При формуванні кадрів повідомлення забезпечується збереження кордонів повідомлення в тому вигляді, в якому воно передається сокетами; це означає, що якщо клієнт посилає серверу 100 байт, за якими йдуть 50 байт, то сервер сприймає 100 байт і 50 байт за дві операції читання. Точно так же функціонує протокол UDP, це є особливістю протоколів, орієнтованих на роботу з повідомленнями.
На противагу їм протокол TCP обробляє неструктурований потік байт. Якщо не використовувати процедуру формування кадрів повідомлення, то вузол мережі може отримувати дані за розміром більше або менше відправлених. Такий режим функціонування вимагає, щоб для протоколів, орієнтованих на роботу з повідомленнями і функціонуючих поверх протоколу TCP, на прикладному рівні було надано спеціальний буфер даних і виконувалася процедура формування кадрів повідомлень (що потенційно є складним завданням).
Протокол SCTP забезпечує формування кадрів при передачі даних. Коли вузол виконує запис у сокет, його кореспондент гарантовано отримує блок даних того ж розміру.
Структура пакета Редагувати
|
SCTP пакети мають простішу структуру, ніж пакети TCP. Кожен пакет складається з двох основних розділів:
- Загальний заголовок, який займає перші 12 байт (виділені синім кольором)
- Блоки даних, які займають решту пакету.
Перший блок відзначений зеленим кольором, і останній з блоків N (N блок) виділено червоним.
Кожен блок має ідентифікатор типу довжиною 1 байт, що дозволяє визначити 255 різних типів блоків. RFC 4960 визначає список видів блоків, всього наразі визначено 15 типів. Інша частина блоку складається з двох байт (максимальний розмір 65535 байт) і даних. Якщо блок не утворює 4 байта, то вона неявно заповнюється нулями, які не включені в довжину блоку.
Обробка помилок Редагувати
Повтор передачі Редагувати
Повторна передача блоків DATA може бути обумовлена тайм-аутом, визначеним таймером повтору (retransmission timer) або отриманням SACK, що показують що блок DATA не був отриманий адресатом. Для зниження ймовірності насичення повтор передачі блоків DATA обмежується. Значення тайм-ауту для повтору (RTO) встановлюється на основі оцінки часу кругового обходу і зменшується експоненціально з ростом частоти втрати повідомлень. Для активних асоціацій з майже постійним рівнем трафіку DATA причиною повтору скоріше за все будуть повідомлення SACK, а не тайм-аут. Для зниження ймовірності непотрібних повторів використовується правило 4 SACK, відповідно до якого повтор передачі відбувається тільки по четвертому SACK, яка вказує на пропуск блоку даних. Це дозволяє запобігти повтору передачі, викликані порушенням порядку доставки.
Збій в дорозі Редагувати
Підтримується лічильник для числа повторів передачі за конкретною адресою одержувача без підтвердження успішної доставки. Коли значення цього лічильника досягає заданого порогу (конфігураційний параметр), адреса оголошується неактивною і протокол SCTP починає використовувати іншу адресу для передачі блоків DATA. Крім того, по всіх невживаним (додатковим) адресами періодично передаються спеціальні блоки Heartbeat і підтримується лічильник числа блоків Heartbeat, переданих без повернення відповідного Heartbeat Ack. Коли значення лічильника досягає заданого порогу (параметр конфігурації), відповідна адреса оголошується неактивною. Блоки Heartbeat передаються по неактивним адресам до тих пір, поки не буде отримано повідомлення Ack, що говорить про відновлення активності адреси. Частота передачі блоків Heartbeat визначається значення RTO і додаткової затримкою, яка дозволяє передавати блоки Heartbeat без перешкод для користувацького трафіку.
Реалізації Редагувати
Протокол SCTP реалізований в наступних операційних системах:
- Linux 2.4 і вище
- Sun Solaris 10
- Cisco IOS 12 +
- DragonFly BSD починаючи з версії 1.4
- QNX Neutrino,
- BSD UNIX (з зовнішнім доповненням від проекту KAME)
- FreeBSD починаючи з версії 7
- HP-UX
- AIX 5
Посилання Редагувати
- http://www.sigtran.org [ 23 березня 2019 у Wayback Machine.]
- http://www.sctp.de [ 24 лютого 2021 у Wayback Machine.]