← Cloudflare Realtime / realtime / turn

Часто задаваемые вопросы

Цены на Cloudflare TURN рассчитываются на основе объема данных, передаваемых от периферийной сети Cloudflare к TURN-клиенту, как описано в RFC 8656 Figure 1 ↗. Это означает данные, передаваемые от сервера TURN клиенту TURN, и включает весь трафик, в том числе накладные расходы TURN, после успешной аутентификации.

Стоимость службы Cloudflare Realtime TURN составляет $0.05 за ГБ использованных данных.

Служба STUN Cloudflare по адресу stun.cloudflare.com бесплатен и не ограничен.

Действует бесплатный тариф на 1000 ГБ, после которого начинается тарификация. Стоимость Cloudflare Realtime отображается в счёте Cloudflare отдельной строкой, покрывающей и SFU, и TURN.

За трафик между Cloudflare Realtime TURN и Cloudflare Realtime SFU или Cloudflare Stream (WHIP/WHEP) плата не взимается.

---
title: Cloudflare Realtime TURN pricing
---
flowchart LR
    Client[TURN Client]
    Server[TURN Server]

    Client -->|"Ingress (free)"| Server
    Server -->|"Egress (charged)"| Client

    Server <-->|Not part of billing| PeerA[Peer A]

Ознакомьтесь с Cloudflare сертификаты и материалы о соответствии требованиям ↗ и обратитесь к своему менеджеру по работе с корпоративными клиентами Cloudflare.

Cloudflare Realtime TURN поддерживает FIPS 140-3 при использовании шифрования, например TURN через TLS. Сам TURN никак не контролирует шифрование данных, проходящих через уровень данных TURN. Для сквозного шифрования ретранслируемых медиаданных или данных шифрование должен обеспечивать вышестоящий уровень (например, DTLS, если TURN используется с WebRTC).

TURN-сервер Cloudflare Realtime работает на глобальная сеть Cloudflare ↗ - постоянно растущая глобальная сеть из тысяч серверов, размещённых в сотнях точек присутствия по всему миру, за заметным исключением сети Cloudflare China Network.

Служба Cloudflare Realtime TURN не отличается по производительности или набору функций между тарифами Enterprise и самостоятельного обслуживания, однако для тех, кто использует enterprise планы ↗ получит приоритетную поддержку, предсказуемую тарификацию по фиксированной ставке и гарантии SLA.

Cloudflare China Network не участвует в обслуживании трафика Realtime, а TURN-трафик из Китая будет подключаться к точкам присутствия Cloudflare за пределами Китая.

Данные об использовании TURN появляются в аналитике через 30 секунд.

Когда Cloudflare Realtime TURN используется вместе с WebRTC, Cloudflare не имеет доступа к содержимому ретранслируемых медиаданных. Это происходит потому, что WebRTC использует шифрование Datagram Transport Layer Security (DTLS) для всех медиапотоков, которое шифрует данные сквозным образом между взаимодействующими пирами ещё до того, как они достигают TURN-сервера. В результате Cloudflare только ретранслирует зашифрованные пакеты и не может расшифровать или просмотреть содержимое медиаданных, включая аудио, видео и информацию из канала данных.

С точки зрения конфиденциальности данных единственная информация, которую Cloudflare обрабатывает для работы службы TURN, это метаданные, необходимые для установления и поддержания ретранслируемого соединения. Сюда входят IP-адреса клиентов TURN, номера портов и информация о времени сессии. У Cloudflare нет доступа к какой-либо информации, позволяющей идентифицировать личность, содержащейся в самих зашифрованных медиапотоках.

Эта архитектура обеспечивает сохранение сквозного шифрования между участниками для медиатрафика, ретранслируемого через Cloudflare Realtime TURN: Cloudflare выступает исключительно посредником при ретрансляции и не имеет доступа к зашифрованному содержимому.

протокол TURN, RFC 8656 ↗, не описывает шифрование за пределами протоколов обёртки, таких как TURN через TLS. При использовании TURN вместе с WebRTC шифрование данных выполняется на уровне WebRTC.

Выделения Cloudflare Realtime TURN закрепляются за ближайшим доступным дата-центром Cloudflare к TURN-клиенту благодаря anycast-маршрутизации. Если обе стороны соединения используют Cloudflare Realtime TURN, Cloudflare может управлять маршрутизацией и по возможности направлять пакеты TURN через магистральную сеть Cloudflare.

TURN и SFU решают разные задачи и часто используются вместе.

Используйте TURN, если у вас есть point-to-point соединение между двумя пирами и нужно обойти NAT или брандмауэры. Оба пира обмениваются медиа напрямую через ретранслятор, без какой-либо обработки медиа на стороне сервера.

Используйте SFU, если вам нужен fan-out, то есть ситуация, когда один издатель отправляет медиа многим подписчикам или несколько издателей обмениваются медиа в группе. SFU пересылает выбранные медиапотоки между участниками и поддерживает такие функции, как simulcast и выбор трека на стороне подписчика.

Если ваш сценарий использования предполагает связь один на один, например канал телеуправления между оператором и удаленным устройством, обычно достаточно одного TURN. Добавление SFU для такой топологии избыточно усложняет систему.

Нет. Cloudflare Realtime TURN и SFU работают на одном и том же парке машин в глобальной сети Cloudflare и используют общий путь передачи данных. Заметного снижения задержки или пропускной способности при выборе одного варианта вместо другого не возникает.

Выбор должен определяться топологией, а не производительностью:

• Используйте TURN для ретрансляции point-to-point.
• Используйте SFU, если вам нужны fan-out, групповые звонки или избирательная пересылка треков.

Не обязательно. Когда оба узла передают трафик через Cloudflare Realtime TURN, трафик между двумя edge Cloudflare может проходить по магистральной сети Cloudflare, а значит, Cloudflare контролирует весь путь от начала до конца. Если TURN использует только один из узлов, второй участок проходит через публичный интернет, и задержка с потерей пакетов зависят от канала связи между этим узлом и ближайшим дата-центром Cloudflare.

Более стабильное улучшение от использования TURN на обеих сторонах заключается в надёжности и поведении при потере пакетов, а не в исходной задержке. Задержка магистральной сети обычно ниже, чем в публичном интернете, но величина улучшения задержки зависит от географии. Снижение потери пакетов, как правило, более предсказуемо.

Да. Cloudflare Realtime TURN хорошо подходит для телеуправления роботами, удаленного управления транспортом и задач управления флотом, где требуются двусторонние каналы передачи медиа или данных с низкой задержкой между оператором и удаленным устройством.

Для телеуправления обычно используется TURN в режиме «точка-точка»: один конец соединения находится в сети оператора, а другой на сотовом или проводном канале робота. WebRTC и DTLS обеспечивают сквозное шифрование медиапотока, а Cloudflare Realtime TURN отвечает за обход NAT и ретрансляцию между двумя эндпойнтами. Когда оба эндпойнта подключаются через TURN, трафик между edge Cloudflare может передаваться по магистральной сети Cloudflare, что улучшает показатели потери пакетов на протяжённых линиях связи.

Для рабочих нагрузок, где телеметрию или видеопоток с камеры робота нужно рассылать нескольким подписчикам одновременно (например, оператору, супервайзеру и панели управления парком), в дополнение к TURN можно использовать Cloudflare Realtime SFU. Также стоит рассмотреть реализацию Media over QUIC (MoQ) от Cloudflare для телеметрии и телеуправления, если вы контролируете оба конца соединения: она даёт более явный контроль над надёжностью и поведением при повторных передачах, чем WebRTC.

Cloudflare Realtime TURN удобен для ИТ-администраторов со строгими брандмауэрами, поскольку в отличие от других провайдеров требует добавить в allowlist совсем немного IP-адресов. Необходимо добавить в allowlist адреса как IPv6, так и IPv4.

Добавьте следующие IP-адреса в allowlist:

• 2a06:98c1:3200::1/128
• 2606:4700:48::1/128
• 141.101.90.1/32
• 162.159.207.1/32

Мы не рекомендуем так поступать, но понимаем, что существует очень небольшой круг случаев, когда может быть полезно жёстко задать IP-адреса. В этом случае необходимо настроить оповещения, которые отслеживают изменения в ответе DNS от turn.cloudflare.com (записи A и AAAA) и обновить жестко заданные IP-адреса соответствующим образом в течение 14 дней после изменения DNS. Учтите, что такой DNS-ответ может содержать несколько IP-адресов. Кроме того, необходимо настроить переход на DNS-запрос на случай проблем с подключением по жестко заданному IP-адресу. Cloudflare стремится сохранять неизменным IP-адрес службы TURN, но не может это гарантировать, если это отдельно не оговорено в вашем корпоративном договоре. Подробнее о статических IP-адресах, гарантиях и других договоренностях уточняйте у команды по работе с корпоративными аккаунтами.

Служба TURN по адресу turn.cloudflare.com также отвечает на запросы привязки («STUN-запросы»).

Функция генерации учётных данных Cloudflare Realtime возвращает JSON-структуру, похожую на истёкший черновик RFC «draft-uberti-behave-turn-rest-00» ↗, но не включает значение TTL. Если вам нужен ответ именно в таком формате, вы можете преобразовать JSON, полученный от эндпойнта генерации учётных данных Cloudflare Realtime, в нужный формат на своём backend-сервере или в Cloudflare Workers.

В UDP потеря пакетов является обычным явлением и может изредка происходить даже при надёжных соединениях. Однако если вы наблюдаете систематическую потерю пакетов, учтите следующее:

• Отправляете или получаете данные с высокой скоростью (>50-100 Мбит/с) от одного клиента TURN? Возможно, Realtime TURN отбрасывает пакеты, сигнализируя о необходимости снизить скорость.
• Отправляете или получаете большие объёмы данных очень маленькими пакетами (высокая скорость пакетов > 5-10kpps) от одного клиента TURN? Возможно, Cloudflare Realtime отбрасывает пакеты.
• Отправляете пакеты на новые уникальные адреса с высокой скоростью, напоминающей сканирование портов ↗ поведение?

Чёткого ограничения на выдачу учётных данных не установлено. Начните с 500 учётных данных в секунду и увеличивайте нагрузку линейно. Убедитесь, что вы используете более 50% выданных учётных данных.

Вы можете задать срок действия учётных данных на срок до 48 часов вперёд. Если вам нужно, чтобы ваше выделение TURN действовало дольше, вам потребуется обновить ↗ учетные данные TURN.

Да. Cloudflare Realtime доступен по IPv4 и IPv6 для связи между TURN Client и TURN сервером, однако он не выдает адреса ретрансляции в IPv6, как описано в RFC 6156 ↗.

Нет. Realtime TURN не учитывает REQUESTED-ADDRESS-FAMILY STUN-атрибут, если он указан, приведёт к выдаче только IPv4-адресов.

Нет. Realtime не реализует RFC6062 ↗ и не будет учитывать REQUESTED-TRANSPORT STUN-атрибут.

Cloudflare Realtime отклоняет запросы CreatePermission и ChannelBind, если указаны приватные диапазоны IP-адресов (например, loopback-адреса, link local unicast- или multicast-блоки) либо IP-адреса, входящие в BYOIP используются.

Если вы являетесь клиентом Cloudflare BYOIP и хотите подключить свои диапазоны BYOIP через Realtime TURN, обратитесь за дополнительной информацией к своему менеджеру по работе с клиентами.

Максимальная продолжительность выделения TURN не ограничена. Согласно RFC 8656 Section 3.2 ↗, после выделения ретранслируемого транспортного адреса клиент должен поддерживать это выделение активным. Для этого клиент периодически отправляет серверу запрос Refresh. Запрос Refresh должен быть аутентифицирован с помощью действительных учётных данных TURN. Максимальный срок действия учётных данных составляет 48 часов. Если требуется более длительное выделение, новые учётные данные необходимо создавать не реже одного раза в 48 часов.

Хотя это случается нечасто, в отдельных сценариях выделение TURN может нарушаться. Причиной может быть обслуживание Cloudflare-сервера, отвечающего за выделение, либо изменения топологии интернет-сети, из-за которых пакеты TURN попадают в другой дата-центр Cloudflare. Какой бы ни была причина, Перезапуск ICE ↗ поддержка со стороны клиентов настоятельно рекомендуется.

Cloudflare Realtime немедленно прекращает тарификацию и учет использования для аналитики. После небольшой задержки соединение будет разорвано.