Sctp link fault что это
Улучшаем жизнь пользователей с IPv6 и SCTP
От переводчика: я не нашел на хабре подходящего «низкоуровневого сетевого» блога и сначала даже сомневался, стоит ли делать данный перевод. Но всё-таки, все мы с вами разработчики (надеюсь, хотя бы большинство), и описываемая в статье проблема с IPv6 сейчас актуальна, как никогда. До сих пор я вынужден отказываться от любимого русского зеркала Debian (ftp.chg.ru), по причине того, что слишком передовое зеркало отлично работает по IPv6, а мой провайдер выдаёт IPv6 адреса, но IPv6 трафик не роутит, да. В общем, я связался с Оле Якобсеном (Ole J. Jacobsen), главным редактором The Internet Protocol Journal, и с его благословения публикую эту статью. Поехали.
Чтобы быть успешными, новые технологии должны приносить радость пользователям. В процессе поиска лучшего способа внедрить технологию как правило придумывают, исследуют, пробуют и отбрасывают несколько подходов. Данная статья рассматривает два таких подхода для IPv6 и протокола передачи с управлением потоком (Stream Control Transmission Protocol, SCTP)[10].
Современные браузеры, веб-серверы и операционные системы поддерживают IPv4 и IPv6. IPv6 также поддерживается несколькими крупных контент-провайдерами, включая Google, NetFlix и Facebook. Однако их контент нельзя назвать широко доступным через IPv6 из-за конфликта между технологией IPv6 и бизнес-реалиями.
Подключение в веб-браузерах и операционных системах включает в себя выполнение DNS-запросов к AAAA (IPv6 — прим. пер.) и A (IPv4 — прим. пер.) записям, а затем попытки последовательно соединиться с результирующими IPv6 и IPv4 адресами. Если путь по IPv6 недоступен (или медленный), соединение может сожрать много времени, прежде чем программа начнёт пробовать традиционный IPv4. Процесс будет особенно мучителен на среднестатистических веб-сайтах, запрашивающих объекты с различных узлов — каждая проблема IPv6 вызовет задержку. В сочетании операционной системы с браузером, если IPv6 недоступен, задержка может вылиться в тормоза от 20 секунд до нескольких минут[2]. Типичный поток сообщений от TCP-клиента показан на рисунке 1. Очевидно, что подобная задержка неприемлема для пользователей, которые спасаются от торможения, отключая у себя поддержку IPv6 протокола[3] или избегая поддерживающих IPv6 сайтов.
Рисунок 1: поведение обычного веб-браузера
Проблема «сломанных» IPv6 сетей распространена достаточно широко[6]. Предоставление контента — это бизнес, как прямой (например, воспроизведение потокового видео), так и непрямой (продажа рекламных показов). Если пользователи испытывают лаги, просматривая поддерживающий IPv6 контент (по технологическим причинам, указанным выше), у них сразу появляется отличный стимул посещать другие сайты. Этот сценарий означает упущенную прибыль и категорически не подходит для бизнеса. Учитывая то, что все потребители сегодняшнего интернета могут достичь контента через IPv4, включать IPv6 — большой бизнес-риск, так как некоторые потребители обязательно от этого пострадают. Крупные контент-провайдеры в течение некоторого времени изучали ситуацию и в итоге опубликовали результаты [7], показывающие, что количество отказов IPv6 слишком большое, чтобы включать IPv6 AAAA для их контента.
IPv6 проблемы вызваны несколькими причинами. Это новая технология, и качество сети IPv6 всё ещё не находится на том же уровне, что и для IPv4, из-за точечных тоннелей, неуправляемых тоннелей[11] (как правило, 6to4) и неправильно настроенных файрволов, кроме того, отказы отдельных роутеров и соединений также весьма легко вызывают отказы IPv6. Множество приложений продолжают поддерживать только IPv4, сетевые администраторы полагаются на то, что двухстековое оборудование прозрачно переключится на IPv4 во время отказов IPv6.
Однако, такие переключения не бывают прозрачными для пользователей — они занимают множество секунд или даже минут! Чтобы избежать этих проблем, у контент-провайдеров есть только один выход — не отдавать свои AAAA записи тем, у кого IPv6 соединение может оказаться поломанным или медленным.
Чтобы обойти эту проблему, в Google создали белый список DNS-серверов, которым они будут предоставлять свои AAAA записи[8]. Тем не менее, в своём текущем воплощении ведение белого списка DNS масштабируется плохо, так как сначала интернет-провайдер должен доказать своё хорошее IPv6-соединение с гуглом, после чего гугл внесёт в белый список DNS-серверы провайдера. Проблема масштабируемости заключается в том, что в мире, вообще говоря, существуют тысячи интернет-провайдеров, и ведение белого списка превращается в утомительный ручной труд, как для провайдеров, так и для Google. Помимо этого, если каждый контент-провайдер введет белый список DNS, каждому интернет-провайдеру придётся работать сразу с несколькими контент-провайдерами, чтобы обеспечить выгодность развернутой среди их пользователей IPv6-сети! Поэтому контент-провайдеры начали работать совместно, чтобы утвердить требования для внесения в белый список DNS и создать некий общий сервис для автоматизации данного процесса[5].
В дополнение к этому, внесение в белый список DNS еще не гарантирует работающую (или быструю) IPv6 сеть, так как между хорошей IPv6 связностью и наличием AAAA-записей на DNS-сервере пользовательского интернет-провайдера нет прямой связи. Даже с наилучшим замыслом и дизайном сети, всё равно будут возникать случаи, когда доступен только один путь — либо IPv4, либо IPv6 — в то время, как второй вид транспорта недоступен. Результатом будут чрезмерные задержки для клиентов, поддерживающих IPv4 либо оба стека, в зависимости от того, какого рода поломка случилась.
Данная ситуация вносит свой вклад в пользовательское ощущение того, что интернет или конкретный сайт «упали». Пользователь предпочтёт ходить на другой сайт, вероятно, уже никогда не возвращаясь на «упавший».
Счастливые глазки
Прим. пер.: в оригинале употребляется «happy eyeballs» что буквально переводится как «счастливые глазные яблоки», но в западном телекоме «eyeballs» обычно означает «пользователи интернет».
Данную проблему решает другой подход. Вместо того чтобы неспешно пытаться установить соединение по IPv6, а затем по IPv4, приложение делает одновременные попытки установить соединение сразу через IPv4 и IPv6.
Одновременные попытки соединения потребляют немного большую часть канала и удваивают число попыток соединения с сервером. Чтобы уменьшить ненужный трафик, также используется кэш, в котором хранится история удачных и провальных попыток соединения через IPv4/6. Мы называем данный подход: «Счастливые глазки»[1], так как именно глазки (пользователи) более счастливы — их компьютер мгновенно отображает содержимое, хотя скорость работы сети и уменьшается (рисунок 2).
Рисунок 2: Двухстековый браузер, реализующий «Счастливые глазки»
Очевидно, посылка TCP SYN через IPv6 и IPv4 удваивает число попыток соединения, сделанных клиентом. Этот избыток соединений может быть уменьшен путём запоминания приложением, какой протокол использовался при предыдущем соединении — IPv6 или IPv4, — и использования этой информации при последующих попытках. Возможное усложнение данного кэша зависит от памяти (или диска), но даже простое кэширование может быть весьма эффективным. При подключении к новой сети (3G, различным Wi-Fi сетям или физическому Ethernet) можно определить связность этой сети и при необходимости очистить кэш попыток, частично или полностью.
Таким образом, удвоение числа попыток соединения случается только при подключении к новой сети. В этом случае начальная попытка соединения будет происходить с задержкой, в силу того что IPv6 (или IPv4) будет пробоваться в первую очередь. В любом случае, если IPv6 (или IPv4) маршрут недоступен, значительных заметных пользователю тормозов не будет. Цель «Счастливых глазок» — сохранить IPv6 включенным, при этом спасая пользователей от его падений — так, чтобы посещение сайтов с IPv6 не вызывало тормозов.
При таком подходе пользователи постепенно мигрируют с IPv4 на IPv6, при необходимости мгновенно возвращаясь к использованию IPv4. Данное решение демонстрирует значительное улучшение по сравнению с существующими веб-браузерами. Препятствием же для этой идеи является то, что ее необходимо воплощать в каждом отдельном приложении. Хотя обновление браузеров — это дополнительный тяжкий труд, существует всего пять основных браузеров[9], а кроме того, браузеры получают мгновенную выгоду от таких активных попыток подключения. Кроме того браузеры всё равно часто обновляют во имя быстрых движков JavaScript и других новых фич.
Еще одной идеей определения работоспособности IPv6 является посылка ping-ов или других простых запросов к какому-нибудь IPv6 ресурсу в интернете и отключение IPv6, если ресурс не ответил. Этот подход служит препятствием для внутреннего IPv6 трафика предприятий (который может ходить вполне успешно, в то время как доступа в IPv6-интернет не имеется), а также отключение IPv6 сломает IPv6 возможности, внедренные в операционную систему (например, DirectAccess в Windows или Back to My Mac в Mac OS X). Преимуществом же является то, что если IPv6 отключен, ни одно приложение уже не пострадает от его падения и задержек, связанных с переключением на IPv4.
Новый транспорт — SCTP
Вдобавок к проблеме выбора протокола сетевого уровня схожая задача существует и на транспортном уровне. Возможно, это для кого-то будет сюрпризом, но помимо TCP существует еще один транспортный протокол — протокол передачи с управлением потоком (SCTP). SCTP предоставляет существенные преимущества по сравнению с TCP и был спроектирован с учётом тех проблем, с которыми приходилось сталкиваться при реализации и внедрении TCP[4].
В отличие от IPv6 и IPv4, для которых имеются различные DNS записи (AAAA и A), у нас нет специальной записи, показывающей, что приложению можно или нужно использовать другой транспортный протокол. Но даже если бы мы могли обозначить поддержку SCTP в DNS, где-то в ходе следования маршрута SCTP может блокироваться, снижая полезность данной DNS-записи. Маршрут также может быть заблокирован NAT’ом или файрволлом, ожидающими исключительно TCP или UDP.
«Счастливые глазки» также описывают методику, при которой клиент может одновременно пробовать подключаться, используя и TCP, и SCTP. При необходимости данные попытки делаются приложением, и приложению надлежит выбрать транспорт, который ответил быстрее, и закэшировать эту информацию для уменьшения флуда во время последующих попыток подключения к данному серверу. Сценарий подключения показан на рисунке 3.
Рисунок 3: Клиент, реализующий «Счастливые глазки» для выбора между TCP и SCTP
Комбинируя выбор IPv6/IPv4 с выбором SCTP/TCP, веб-браузер, запущенный на компьютере, подключенном к новой двухстековой сети, посылает четыре пакета: IPv4 TCP SYN, IPv6 TCP SYN, IPv4 SCTP INIT и IPv6 SCTP INIT. Основываясь на ответах, браузер решает, какой транспортный протокол и адресное пространство (IPv6 или IPv4) предпочесть и отбрасывает остальные подключения. Как описано ранее, информация о соединении кэшируется для последующего использования, чтобы снизить потребляемую ширину канала и серверные ресурсы.
Заключение
Новые технологии, направленные на улучшение жизни пользователей, будут успешными только в случае, если оправдают ожидания — улучшат эту самую жизнь. Так как многие компании извлекают всю свою прибыль, работая в интернете, любое ухудшение сервиса означает упущенную прибыль. Поэтому развертывание новой технологии не должно негативно сказываться на впечатлении пользователя. Данная статья описывает один из механизмов, которые могут использоваться разработчиками, чтобы избежать негативной реакции ваших пользователей.
Ссылки
amer/PEL/poc/pdf/NatarajanPhDdissertation.pdf
[5] Carolyn Duffy Marsan, «Google, Microsoft, Netflix in talks to create shared list of IPv6 users,» Network World, March 2010: http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html
[6] Tore Anderson, «IPv6 brokenness experiment, November results,» November 2009: http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html
[7] Igor Gashinsky, «IPv6 & recursive resolvers: How do we make the transition less painful?» March 2010: http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf
[8] «Access Google services over IPv6»: http://www.google.com/intl/en/ipv6
[9] «Usage share of web browsers»: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[10] R. Stewart, Ed., «Stream Control Transmission Protocol,» RFC 4960, September 2007.
[11] Gunter Van de Velde, Ole Troan, and Tim Chown, «Non-Managed IPv6 Tunnels considered Harmful,» July 2009: http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels
Финал от переводчика
Прошу простить меня за моё косноязычие, накладывающееся на чрезмерно научный стиль статьи. Надеюсь, вам было интересно. А теперь минутка обязательной информации:
Простейшее решение «проблемы промежуточных устройств»: организация работы SCTP поверх UDP в ядре Linux
Возможность организации работы SCTP поверх UDP (известная ещё как инкапсуляция SCTP-пакетов в UDP-пакеты) определена в RFC 6951 и реализована в пространстве ядра Linux начиная с версии ядра 5.11.0. Поддержку этой возможности планируется включить в Red Hat Enterprise Linux (RHEL) 8.5.0 и 9.0.
В этом материале даётся краткий обзор организации работы SCTP поверх UDP в ядре Linux.
Зачем нужна организация работы SCTP поверх UDP?
В вышеупомянутом RFC 6951 выделены две основные причины необходимости организации работы SCTP поверх UDP:
Как работает инкапсуляция SCTP-пакетов в UDP-пакеты?
Если в нашем распоряжении имеется возможность организации работы SCTP поверх UDP, то оказывается, что SCTP-пакеты инкапсулируются в UDP-пакеты. Реализация этого механизма создана с использованием набора API для работы с UDP-туннелями. Эти API уже использовались для организации работы протоколов VXLAN, GENEVE и TIPC.
Обратите внимание на то, что протокол SCTP принимает во внимание UDP-заголовок при нахождении точки фрагментации данных.
Как пользоваться реализацией SCTP поверх UDP?
С точки зрения использования описываемого здесь механизма в программах, можно сказать, что тут нет никакой разницы с тем, что было раньше. А именно, можно применять все стандартные возможности SCTP, в новых условиях доступны и все прежние API. Старые приложения будут работать правильно без необходимости внесения в них изменений или их перекомпиляции. Единственно — нужно правильно настроить UDP-порт (локальный порт, который прослушивает система, или порт src ) и точку инкапсуляции (порт, который прослушивает удалённая система, или порт dest ). Для конкретного сетевого пространства имён сделать это можно с помощью утилиты sysctl :
Можно, в качестве альтернативы, использовать команду setsockopt и настроить порт инкапсуляции для отдельного сокета (socket), для того, что в SCTP принято называть «ассоциацией» (association), или для транспортного механизма (transport):
На стороне сервера обычно нет нужды специально настраивать порт инкапсуляции. Подробнее об этом мы поговорим в следующем разделе.
Порт инкапсуляции UDP
Концепция порта инкапсуляции UDP отличается большой гибкостью. На стороне отправителя данных глобальный порт инкапсуляции демонстрирует лишь значение, задаваемое по умолчанию:
Итоги
Если вы пользуетесь SCTP, если вам нравятся возможности этого протокола, вроде поддержки множественной адресации (Multihoming), многопоточности (Multi-streaming) и разрешения на потерю некоторых пакетов (Partial Reliability), но вы сталкиваетесь с «проблемами промежуточных устройств», теперь вы можете прибегнуть к возможностям ядра Linux, которые дают нам самый простой способ эти проблемы обойти.
Русские Блоги
Подробное объяснение протокола SCTP
каталог
Условия, связанные с SCTP
Адрес передачи определяется IP-адресом, типом протокола транспортного уровня и номером порта транспортного уровня. Поскольку SCTP загружается и передается по IP, адрес передачи SCTP определяется по IP-адресу плюс номер порта SCTP. Номер порта SCTP используется SCTP для идентификации пользователей по тому же адресу, а номер порта TCP является концепцией. Например, IP-адрес 10.105.28.92 и номер порта 1024 SCTP идентифицируют адрес передачи, в то время как 10.105.28.93 и 1024 идентифицируют другой адрес передачи. Аналогично, 10.105.28.92 и номер порта 1023 также идентифицируют другой адрес передачи.
2. Хост и конечная точка
Хост (ХоST) Хост оснащен одним или несколькими IP-адресами, что является типичным физическим объектом.
Конечная точка (конечная точка SCTP)
Адрес передачи (IP-адрес + номер порта SCTP) однозначно определяет конечную точку. Конечная точка может быть определена несколькими адресами передачи, но для одной и той же конечной точки назначения IP-адреса в этих адресах передачи могут быть настроены на несколько адресов, но должен использоваться один и тот же порт SCTP.
3. Сцепление и поток
4. Путь (основной путь)
Если в качестве адреса назначения для конечной точки можно использовать несколько адресов назначения, конечная точка SCTP является многоадресной. Если конечная точка, отправившая пакет SCTP, принадлежит узлу с множественной адресацией, если адрес назначения и адрес источника определены, путь, возвращаемый блоком ответных данных, и интерфейс, через который отправляется пакет данных, могут лучше контролироваться. Две конечные точки SCTP одной связи SCTP могут быть настроены с несколькими IP-адресами, так что между двумя конечными точками одной связи может быть несколько путей. Это многоадресная адресация связи SCTP. Многоадресный характер связи SCTP является самой большой разницей между SCTP и TCP.
Рисунок 1 SCTP двойная адресация
Две конечные точки определяют связь, которая включает 4 пути (Path0, Path1, Path2 и Path3). В соответствии с конфигурацией данных, метод выбора этих 4 каналов может быть определен, как показано на рисунке 2. На рисунке определены 4 пути, и предпочтительным путем является Path0: Path0: локальный адрес передачи 1 (10.11.23.14: 2905) отправляет пакеты SCTP на адрес удаленной передачи 1 (10.11.23.16: 2904).
Path1: Локальный адрес передачи 1 (10.11.23.14: 2905) отправляет пакет SCTP на адрес удаленной передачи 2 (10.11.23.17: 2904).
Path2: Локальный адрес передачи 2 (10.11.23.15: 2905) отправляет пакет SCTP на адрес удаленной передачи 1 (10.11.23.16: 2904).
Path3: Локальный адрес передачи 2 (10.11.23.15: 2905) отправляет пакет SCTP на адрес удаленной передачи 2 (10.11.23.17: 2904).
Принцип работы протокола SCTP, отправленного конечной точкой, заключается в том, что пакет SCTP, отправленный конечной точкой по адресу A, отправляется равноправной конечной точке по предпочтительному пути. При сбое основного пути SCTP может автоматически переключаться на другие пути резервного копирования, предпочтительно переключать адрес передачи противоположной конечной точки и снова переключать адрес передачи локальной конечной точки.
SCTP определяет сообщения сердцебиения (Heart Beat). Когда канал находится в режиме ожидания, локальный пользователь SCTP требует, чтобы SCTP сгенерировал соответствующее сообщение тактового импульса и отправил его в конечную точку однорангового узла через канал, а конечная точка однорангового узла должна немедленно отправить обратно соответствующее сообщение подтверждения тактового импульса. Этот механизм используется для точного измерения задержки петли RTTTIя), и может контролировать доступность соединения в любое время и поддерживать активное состояние связи SCTP.
Рисунок 2 Конфигурация данных для определения способа выбора канала
Порядковый номер передачи (TSN) Порядковый номер передачи (SCTP) использует механизм TSN для получения подтверждения передачи данных. Связанный конец выделяет 32-битный порядковый номер на основе начального TSN для каждого блока данных, отправленного концом, чтобы подтвердить конец, когда он его получает. TSN поддерживается на основе связи.
Порядковый номер потока (SSN)
SCTP назначает 16-битный SSN каждому блоку данных, отправляемому локальным концом в этом потоке, чтобы обеспечить последовательную доставку в потоке. Когда связь установлена, SSN во всех потоках начинается с 0. Когда SSN достигает 65535, следующий SSN равен 0. Распределение TSN и SSN не зависит друг от друга.
6. Окно перегрузки CWND (Окно перегрузки)
SCTP также является протоколом скользящего окна. Окно перегрузки поддерживается для каждого адреса назначения и будет настроено в соответствии с условиями сети. Когда длина неподтвержденного сообщения адреса получателя превышает его CWND, конечная точка прекращает отправку данных на этот адрес.
7. Окно получения RWND (Окно получения)
RWND используется для описания размера буфера приема связанного однорангового узла. Во время установления соединения обе стороны будут обмениваться своим первоначальным RWND. RWND изменится немедленно согласно передаче данных и проверке. Размер RWND ограничивает размер данных, которые может отправлять SCTP. Когда RWND равно 0, SCTP также может отправлять дейтаграмму, чтобы узнать об изменении буфера другой стороны через сообщение подтверждения, пока не будет достигнут предел CWND.
8. Блок управления коробкой передач (TCB)
Функция SCTP
Как показано на рисунке, функции SCTP в основном включают в себя: установление и закрытие соединения, доставку последовательности сообщений в потоке, сегментацию пользовательских данных, подтверждение и предотвращение перегрузки, связывание блоков сообщений, достоверность пакетов и управление трактом.
Рисунок SCTP функциональная схема
1. Установка и закрытие сцепления
2. Отправьте сообщение заказа в потоке
SCTP обеспечивает последовательную доставку дейтаграмм. Последовательно доставленные дейтаграммы должны доставляться в «потоке». Поток является краеугольным камнем последовательной доставки. Через потоковую передачу SCTP разделяет подтверждение данных и упорядоченную доставку передачи на два разных механизма. SCTP использует механизм TSN для реализации подтверждающей передачи данных и использует номер потока и SSN (порядковый номер потока) для осуществления упорядоченной доставки данных. Когда SSN данных, полученных SCTP, является непрерывным, SCTP может отправлять данные пользователям SCTP, не дожидаясь, пока номер TSN данных будет продолжать передаваться пользователям SCTP.
Когда один поток заблокирован, следующее ожидаемое сообщение пользователя SCTP может быть отправлено из другого потока. SCTP также предоставляет непоследовательные услуги доставки.Полученные пользовательские сообщения могут быть немедленно доставлены пользователям SCTP таким образом без необходимости гарантировать порядок приема.
3. Сегментация пользовательских данных
SCTP обнаруживает максимальное значение PMTU (Path Maximum TransmissiON Unit) на пути передачи, чтобы упаковать большие фрагменты пользовательских данных на уровне SCTP, избегая многократной фрагментации и повторной сборки на уровне IP, что может снизить нагрузку на данные уровня IP.
На отправляющей стороне SCTP может фрагментировать большие пользовательские дейтаграммы, чтобы гарантировать, что дейтаграммы SCTP подходят для максимальной единицы передачи (MTU), когда они доставляются на нижние уровни.
На принимающей стороне SCTP повторно собирает фрагменты в полные пользовательские дейтаграммы, которые затем доставляются пользователям SCTP.
4. Подтвердите и избегайте заторов
SCTP последовательно присваивает порядковый номер передачи (TSN) данным (пользовательские дейтаграммы с сегментированными или неэкранированными данными) перед отправкой на нижний уровень.
TSN и SSN (порядковый номер потока) не зависят друг от друга. TSN используется для обеспечения надежности передачи, а SSN используется для обеспечения последовательной доставки сообщений в потоке.
TSN и SSN функционально разделяют надежную доставку и последовательную доставку. Принимающая сторона подтверждает все полученные TSN, даже если некоторые из них не были получены.
Функция повторной передачи пакета отвечает за проверку TSN, а также за устранение перегрузки.
5. Привязка блока сообщений
Если пользовательские данные с очень короткой длиной переносятся с большим заголовком сообщения SCTP, его эффективность передачи будет очень низкой, поэтому SCTP связывает несколько пользовательских данных в сообщении SCTP для передачи, чтобы улучшить использование полосы пропускания.
Пакеты SCTP состоят из общего заголовка пакета и одного или нескольких информационных блоков. Информационные блоки могут быть пользовательскими данными или управляющей информацией SCTP.
Пользователи SCTP могут дополнительно использовать функцию объединения, чтобы решить, следует ли объединять несколько пользовательских дейтаграмм в один пакет SCTP.
Чтобы повысить эффективность, во время перегрузки / повторной передачи функция объединения может все еще выполняться, даже если пользователь запретил объединение.
6, срок действия группировки
Корректность пакета является краеугольным камнем SCTP для обеспечения безошибочной передачи. Общий заголовок пакета SCTP-пакета содержит проверочный тег (VerificATIon Tag) и необязательную 32-битную контрольную сумму (Checksum). Значение проверочной метки выбирается обоими концами соединения, когда соединение инициируется. Если в принятом пакете нет ожидаемого значения тега аутентификации, принимающая сторона отбросит пакет, чтобы предотвратить атаки и недопустимые пакеты SCTP. Контрольный код устанавливается отправителем пакета SCTP для обеспечения дополнительной защиты во избежание ошибок данных, вызванных сетью. Принимающая сторона отбрасывает SCTP-пакеты, содержащие недействительные контрольные коды.
7. Управление доступом
Пользователь SCTP на передающей стороне может использовать набор адресов передачи в качестве пункта назначения пакета SCTP. Функция управления SCTP может выбирать адрес передачи назначения для каждого отправленного пакета SCTP на основании инструкций пользователя SCTP и состояния достижимости текущего квалифицированного набора назначения. Когда другой пакетный трафик не может полностью указать достижимость, функция управления каналом может контролировать достижимость определенного адреса назначения посредством сообщений пульса, а когда достижимость адреса передачи любого однорангового узла изменяется, она отправляет сообщение в SCTP. Пользователь предоставляет инструкции. Функция канала также используется, чтобы сообщить квалифицированный локальный адрес передачи, установленный одноранговому узлу, когда соединение установлено, и сообщить адрес передачи, возвращенный от однорангового узла, локальному пользователю SCTP. Когда связь установлена, предпочтительный путь определяется для каждой конечной точки SCTP, которая используется для отправки пакетов SCTP при нормальных обстоятельствах.
На принимающей стороне функция управления каналом используется для проверки наличия связи входящего пакета SCTP перед обработкой пакета SCTP.
SCTP основной процесс сигнализации
1 Создание муфты и процесс доставки
Конечная точка SCTP A инициирует установление соединения и отправляет пользовательское сообщение конечной точке B, затем конечная точка B отправляет два пользовательских сообщения A. (Предположим, что эти сообщения не связаны и не фрагментированы). Процесс сигнализации показан на рисунке 1.
Рисунок 1. Схема взаимодействия сообщений процесса установления связи
(1) Конечная точка A создает структуру данных TCB (блок управления передачей) для описания соединения, которое должно быть инициировано (содержит основную информацию о соединении), а затем отправляет блок данных INIT в конечную точку B. Блок данных INIT в основном включает в себя следующие параметры:
Количество выходных потоков (ОС): максимальное количество исходящих потоков, ожидаемое этой конечной точкой.
Количество входных потоков (MIS): максимальное количество входящих потоков, разрешенное в этой конечной точке.
(2) После получения сообщения INIT конечная точка B немедленно отвечает блоком данных INIT ACK. Блок данных INIT ACK должен иметь следующие параметры:
IP-адрес получателя: укажите исходный IP-адрес блока данных INIT.
Инициировать тег: установите значение Tag_B.
State COOKIE (СОСТОЯНИЕ COOKIE): Создать TCB на основе базовой информации о соединении, но этот TCB является временным TCB. После того, как TCB сгенерирован, необходимая информация (включая временную метку, сгенерированную COOKIE, время жизни COOKIE) и локальный ключ вычисляются в 32-битный MAC-код дайджеста по алгоритму, описанному в RFC2401 (этот расчет необратим) ). Необходимая информация и MAC объединяются в параметр STATE COOKIE.
Эта конечная точка отправляет адрес.
Максимальное количество входящих потоков.
Максимальное количество исходящих потоков.
(3) После получения ACK INIT конечная точка A сначала останавливает INIT.таймер
Выйдите из состояния COOKIE-WAIT, затем отправьте блок данных COOKIE ECHO и верните параметр STATE COOKIE в блок данных INIT ACK. Наконец, конечная точка A начинает COOKIEтаймерИ войдите в состояние COOKIE-ECHOED.
(4) После получения блока данных COOKIE ECHO конечная точка B выполняет проверку COOKIE. Часть TCB в STATE COOKIE и локальный ключ вычисляются в соответствии с алгоритмом MAC RFC2401, и результирующий MAC сравнивается с MAC, переносимым в STATE COOKIE. Если оно отличается, откажитесь от этого сообщения, если оно одинаковое, выньте метку времени детали TCB и сравните ее с текущим временем, чтобы увидеть, превысило ли время время существования COOKIE. Если это так, откажитесь и от этого. В противном случае установите соединение с клеммой A на основании информации в TCB. Конечная точка B переводит состояние в ESTABLISHED и отправляет блок данных COOKIE ACK. Конечная точка B отправляет уведомление SCOMMUNCIATION UP пользователям SCTP.
(5) Конечная точка A отправляет блок данных DATA в конечную точку B, чтобы запустить таймер T3-RTS. Блок данных DATA должен иметь следующие параметры:
TSN: начальный TSN блока данных DATA.
Идентификатор потока (Идентификатор потока): пользовательские данные принадлежат потоку, при условии, что идентификатор потока равен 0.
Порядковый номер потока (порядковый номер потока): порядковый номер пользовательских данных в потоке. Поле составляет от 0 до 65535.
Пользовательские данные (User Data): несет данные пользователя.
(6) После получения блока данных DATA конечная точка B возвращает блок данных SACK. Блок данных SACK должен иметь следующие параметры:
Совокупный TSN Ack: Совокупный TSN Ack: начальный TSN конечной точки A.
Gap Ack Block: Это значение равно 0. После получения блока данных SACK конечная точка A останавливает таймер T3-RTX.
(7) Конечная точка B отправляет первый блок данных DATA в конечную точку A. Блок данных DATA должен иметь следующие параметры:
TSN: конечная точка B отправляет начальный TSN блока данных DATA.
Идентификатор потока (Идентификатор потока): пользовательские данные принадлежат потоку, при условии, что идентификатор потока равен 0.
Порядковый номер потока (порядковый номер потока): порядковый номер пользовательских данных в потоке. Предположим, что код последовательности потока равен 0.
Пользовательские данные (User Data): несет данные пользователя.
(8) Конечная точка B отправляет второй блок данных DATA в конечную точку A. Блок данных DATA должен иметь следующие параметры:
TSN: конечная точка B отправляет начальный TSN + 1 блока данных DATA.
Идентификатор потока (Идентификатор потока): пользовательские данные принадлежат потоку, при условии, что идентификатор потока равен 0.
Порядковый номер потока (порядковый номер потока): порядковый номер пользовательских данных в потоке. В это время код последовательности потока равен 1.
Пользовательские данные (User Data): несет данные пользователя.
(9) После получения блока данных DATA конечная точка A возвращает блок данных SACK. Блок данных SACK должен иметь следующие параметры:
Совокупный TSN Ack: Совокупный TSN Ack: начальный TSN конечной точки B.
Gap Ack Block: Это значение равно 0.
2 Процесс закрытия муфты
Когда конечная точка выходит из службы, она должна прекратить соединение. Для остановки муфты используются две процедуры: процедура подвески муфты (аварийное отключение) и обычная процедура выключения муфты. Приостановка муфты (аварийное отключение) может быть выполнена в течение любого неполного периода: оба конца муфты отбрасывают данные и не подают их на противоположный конец. Этот метод не учитывает безопасность данных. Этап завершения соединения является относительно простым: инициирующая конечная точка отправляет блок данных ABORT в конечную точку однорангового узла, отправленный пакет SCTP должен быть заполнен проверочной меткой конечной точки однорангового узла, и никакие данные DATA не связаны в блоке данных ABORT, принимающая конечная точка получает ABORT После блока данных проверьте тег подтверждения. Если тег проверки совпадает с локальным тегом проверки, принимающая конечная точка очищает соединение из записи и сообщает об остановке соединения пользователю SCTP.
Нормальное отключение связывания: когда любая конечная точка выполняет обычную процедуру выключения, оба конца связывания прекращают принимать новые данные от своих пользователей SCTP, а при отправке или получении блоков данных SHUTDOWN отправляют данные в пакете. Для пользователей SCTP. Закрытие соединения может обеспечить отправку и подтверждение неотправленных неподтвержденных данных, отправленных с обоих концов, до прекращения соединения.
Рисунок 2 Диаграмма взаимодействия связывания нормально закрытого сообщения
Обычная процедура закрытия соединения выглядит следующим образом:
(1) Пользователь SCTP, который инициирует отключение конечной точки A, отправляет запрос причины ВЫКЛЮЧЕНИЯ в SCTP. Соединение SCTP переходит из УСТАНОВЛЕННОГО состояния в состояние ОТКЛЮЧЕНИЯ. В этом состоянии SCTP не принимает никаких запросов на передачу данных от пользователей SCTP по этому соединению. В то же время дождитесь, пока конечная точка A отправит все неподтвержденные данные, которые будут подтверждены конечной точкой B. Когда вся конечная точка A отправляет непроверенные данные для подтверждения, она отправляет блок данных SHUTDOWN конечной точке B. Конечная точка A запускает таймер отключения T2 и переходит в состояние ОТКЛЮЧЕНО. Целью запуска таймера выключения T2 является ожидание блока данных SHUTDOWN-ACK, отправленного обратно конечной точкой B. Если время таймера истекло, конечная точка A должна повторно отправить блок данных SHUTDOWN.
(2) После получения сообщения SHUTDOWN конечная точка B переходит в состояние SHOUTDOWN-RECEIVED, больше не принимает новые данные от пользователей SCTP и проверяет накопительное поле TSN ACK блока данных, чтобы убедиться, что все незавершенные блоки данных DATA были Отправитель ОТКЛЮЧЕНИЯ получает. Когда все непереданные данные и неподтвержденные данные, отправленные конечной точкой B, отправлены и подтверждены, отправляется блок данных SHUTDOWN ACK, запускается локальный таймер T2-SHUTDOWN и вводится состояние SHUTDOWN-ACK-SENT. Если таймер истекает, конечная точка B повторно передает блок данных SHUTDOWN ACK.
(3) После получения сообщения SHUTDOWN ACK конечная точка A останавливает таймер выключения T2 и отправляет блок данных SHUTDOWN COMPLETE в конечную точку B и очищает все записи соединения. После получения блока данных SHUTDOWN COMPLETE конечная точка B проверяет, находится ли она в состоянии SHUTDOWN-ACK-SENT. Если он не находится в этом состоянии, блок данных отбрасывается, если конечная точка находится в состоянии SHUTDOWN-ACK-SENT, конечная точка B останавливает таймер выключения T2 и очищает все связанные записи, чтобы войти в состояние ЗАКРЫТО.