- PVSM.RU - https://www.pvsm.ru -
В этом материале даётся краткий обзор организации работы SCTP поверх UDP в ядре Linux.
В вышеупомянутом RFC 6951 выделены две основные причины необходимости организации работы SCTP поверх UDP:
Первая причина связана с решением «проблем промежуточных устройств». Эти проблемы доставили тем, кто пользуется SCTP, много неприятностей и встали на пути у широкого использования SCTP. В основе второй причины лежит потребность в наличии механизма, который позволяет разработчикам приложений пользовательского уровня создавать собственные реализации SCTP, основанные на UDP.
Если в нашем распоряжении имеется возможность организации работы SCTP поверх UDP, то оказывается, что SCTP-пакеты инкапсулируются в UDP-пакеты. Реализация этого механизма создана с использованием набора API для работы с UDP-туннелями. Эти API уже использовались для организации работы протоколов VXLAN, GENEVE и TIPC.
Ядро, для того чтобы иметь возможность получать инкапсулированные пакеты, прослушивает особый UDP-порт на всех локальных интерфейсах. По умолчанию используется порт 9899
. Этот порт, кроме того, играет роль порта src
для UDP-пакетов, отправляемых хостом. Вполне логично то, что порт dest
системы, с которой ведётся обмен данными, должен быть портом, который прослушивает эта система. В качестве его номера тоже, по умолчанию, используется 9899
. Адреса портов src
и dest
, связанные с SCTP-механизмами, используются и в IP-заголовках:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP(v6)-заголовок (адреса, связанные с SCTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP-заголовок (src: 9899, dest: 9899) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Общий заголовок SCTP (SCTP-порты) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Блок SCTP #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Блок SCTP #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Обратите внимание на то, что протокол SCTP принимает во внимание UDP-заголовок при нахождении точки фрагментации данных.
С точки зрения использования описываемого здесь механизма в программах, можно сказать, что тут нет никакой разницы с тем, что было раньше. А именно, можно применять все стандартные возможности SCTP, в новых условиях доступны и все прежние API. Старые приложения будут работать правильно без необходимости внесения в них изменений или их перекомпиляции. Единственно — нужно правильно настроить UDP-порт (локальный порт, который прослушивает система, или порт src
) и точку инкапсуляции (порт, который прослушивает удалённая система, или порт dest
). Для конкретного сетевого пространства имён сделать это можно с помощью утилиты sysctl
:
# sysctl -w net.sctp.encap_port=9899
# sysctl -w net.sctp.udp_port=9899
Можно, в качестве альтернативы, использовать команду setsockopt
и настроить порт инкапсуляции для отдельного сокета (socket), для того, что в SCTP принято называть «ассоциацией» (association), или для транспортного механизма (transport):
setsockopt(SCTP_REMOTE_UDP_ENCAPS_PORT, port);
На стороне сервера обычно нет нужды специально настраивать порт инкапсуляции. Подробнее об этом мы поговорим в следующем разделе.
Концепция порта инкапсуляции UDP отличается большой гибкостью. На стороне отправителя данных глобальный порт инкапсуляции демонстрирует лишь значение, задаваемое по умолчанию:
На стороне получателя данных порт инкапсуляции обычно задавать не нужно:
INIT
. Другие такие пакеты, в которых указан другой UDP-порт src
, после этого будут отбрасываться.Если вы пользуетесь SCTP, если вам нравятся возможности этого протокола, вроде поддержки множественной адресации (Multihoming), многопоточности (Multi-streaming) и разрешения на потерю некоторых пакетов (Partial Reliability), но вы сталкиваетесь с «проблемами промежуточных устройств», теперь вы можете прибегнуть к возможностям ядра Linux, которые дают нам самый простой способ эти проблемы обойти.
Применяете ли вы SCTP?
Автор:
ru_vds
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/367601
Ссылки в тексте:
[1] RFC 6951: https://datatracker.ietf.org/doc/html/rfc6951
[2] Red Hat Enterprise Linux: https://developers.redhat.com/products/rhel/overview
[3] Image: https://habr.com/ru/company/ruvds/blog/575344/
[4] этом: https://datatracker.ietf.org/doc/html/rfc6951#ref-BEHAVE
[5] этом: https://datatracker.ietf.org/doc/html/rfc6951#ref-NATSUPP
[6] Источник: https://habr.com/ru/post/575344/?utm_source=habrahabr&utm_medium=rss&utm_campaign=575344
Нажмите здесь для печати.