|
|
Строка 1: |
Строка 1: |
− | == SCTP ==
| |
− | '''SCTP''' ('''Stream Control Transmission Protocol''' {{---}} протокол передачи с управлением потока) {{---}} протокол транспортного уровня. Выполняет те же функции, что и протоколы TCP и UDP. Но объединяет при этом их преимущества, лишает недостатков и добавляет новые возможности.
| |
| | | |
− | Отличия от протоколов TCP и UDP:
| |
− |
| |
− | [[Файл:SctpTable.png]]
| |
− |
| |
− | Основные преимущества (пояснения к таблице):
| |
− | * Сохранение границ {{---}} в протоколе TCP данные передаются непрерывным потоком байт, читаются так же, поэтому программист должен сам следить за тем, как расставлять границы в этом потоке и разделать куски данных. SCTP позволяет ставить границы и обрабатывать данные пакетами, как в UDP. Но при этом гарантирует порядок доставки пакетов, обеспечивает надёжность и ориентирован на соединения. Упорядоченность пакетов, кстати, можно отключить для повышения скорости.
| |
− | * Multihoming (''многолинейность, множественная адресация'', см. иллюстрацию ниже) {{---}} SCTP позволяет устанавливать соединение к одному серверу по разным линиям связи (например, по Wi-Fi и по Ethernet). Таким образом, если одна линия связи отвалится (скорей всего Wi-Fi), то соединение не разорвётся. Это так же позволяет передавать данные сразу по нескольким линиям, что увеличивает скорость передачи. Если в TCP одна линия связи оборвётся, то соединение будет потеряно, придётся устанавливать новое.
| |
− |
| |
− | [[Файл:Multihoming.png]]
| |
− |
| |
− | * Multithreading (''многопоточность'') {{---}} позволяет передавать несколько потоков в рамках одной ассоциации (ассоциацией в SCTP называется соединение между двумя хостами). Например в TCP данные и служебная информация передаются по одному соединению. Поэтому задержка в получении служебнной информации может быть вызвана текущей передачей данных (например, ACK может не прийти вовремя, поэтому мы пошлём дупликат). Такая проблема называется ''head-of-line blocking, HOL''. Многопоточность позволяет передавать эти данные независимо, что приведёт к лучшему использованию доступных ресурсов.
| |
− | * 4-way handshake {{---}} протокол TCP подвержен SYN-flood атакам. Злоумышленник шлёт много пакетов в короткое время для запроса TCP соединения (запрос на соединение помечен битом SYN в заголовке, поэтому и SYN-flood). Но при этом не подтверждает установление соединения. Таким образом на сервере образуются полуоткрытые соединения. Они закрываются сами по истечению таймаута. Но цель злоумышленника состоит в том, чтобы создать как можно больше таких соединений, не давая тем самым создавать новые валидные соединения из-за ограничения в их количестве на стороне сервера (сервер не может иметь бесконечное число соединений, а если сделать таймаут на обрыв слишком маленьким, то валидные соединения могут отваливаться раньше времени, что тоже нехорошо, и это всё делает syn-атаки возможными). В SCTP используется не тройное рукопожатие, а четверное (из разряда: "я хочу установить соединение - ты точно хочешь установить соединение? - да, я точно хочу установить соединение - ну тогда ладно"). Таким образом за короткий промежуток времени нельзя создать много новых соединений.
| |
− |
| |
− | [[Файл:Synfloodsctp.png]]
| |
− |
| |
− | * В SCTP не бывает полузакрытых соединений, как в TCP. Если мы закрываем соединение, то сразу в обе стороны.
| |
− |
| |
− | К сожалению, несмотря на все преимущеста, протокол SCTP не получил пока широкого распространения. Это связано с инертностью (TCP работает, зачем менять?) и сложностью поддержки на аппаратном уровне (например, вся обёртка сетевых протоколов, те же фаерволы, имеют правила в духе "пропускать только UDP, TCP" пакеты; для примера можно вспомнить, как это используется в NAT).
| |
− |
| |
− | == Источники информации ==
| |
− | * [https://compscicenter.ru/courses/comp-networks/2012-autumn/classes/717/ Лекция А. Масальских {{---}} Транспортный уровень. Введение. TCP. UDP. SCTP]
| |
− | * [http://www.oracle.com/technetwork/articles/javase/index-139946.html SCTP в Java (примеры кода)]
| |
− | * [https://tools.ietf.org/html/rfc4960 RFC 4960 {{---}} SCTP]
| |