Сегодня мы рады представить новую версию сервера Centrifugo — Centrifugo v4. Релиз выводит Centrifugo на новый уровень с точки зрения эффективности клиентского протокола, простоты фоллбеков для WebSocket, экосистемы клиентских SDK и модели безопасности каналов. Также релиз включает в себя экспериментальную поддержку HTTP/3 и WebTransport.

Если вы никогда раньше не слышали о Centrifugo, это масштабируемый сервер обмена сообщениями в реальном времени с открытым исходным кодом, написанный на языке Go. Centrifugo может мгновенно доставлять сообщения онлайн-пользователям приложения, подключенным через поддерживаемые транспорты (WebSocket, HTTP-streaming, SSE/EventSource, GRPC, SockJS, и теперь WebTransport). Centrifugo имеет концепцию канала — так что это PUB/SUB сервер.

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

Несколько официальных клиентских SDK для разработки в браузере и для мобильных устройств поддерживают двунаправленный протокол. Кроме того, Centrifugo поддерживает однонаправленный подход для простых случаев использования без необходимости использовать SDK.

Документация доступна на сайте проекта.

Воспоминания о Centrifugo v3

Начнем с того, что немного оглянемся назад. Релиз Centrifugo v3 состоялся в прошлом году. Он содержал большой список улучшений — например, поддержку однонаправленных транспортов (EventSource, HTTP-streaming и GRPC), поддержку GRPC для прокси событий до бекенда, возможность итерироваться по истории сообщений в канале, более быстрый протокол JSON, сверх-эффективная, но экспериментальная реализация движка на основе Tarantool для масштабирования подключений и другое.

В течение жизненного цикла Centrifugo v3 мы добавили еще больше оптимизаций протокола JSON и представили режим гранулярного прокси. Экспериментальный движок Tarantool также претерпел некоторые изменения.

Но Centrifugo v3 не содержал ничего... скажем так, революционного. Революционного для самого Centrifugo, сообщества проекта или даже всей open-source экосистемы обмена сообщениями в реальном времени.

Сейчас у нас есть ощущение, что вместе с новым релизом мы привносим инновации в экосистему. Давайте посмотрим на основные нововведения нового релиза v4.

Унификация клиентских SDK

Самая сложная часть проекта Centrifugo — это не сам сервер. Клиентские SDK (software development kit, https://ru.wikipedia.org/wiki/SDK – прим. переводчика) — самая сложная часть экосистемы. Мы стараемся приурочивать дополнительные улучшения SDK к каждому большому релизу сервера. Но на этот раз SDK являются центральным элементом релиза v4.

Centrifugo использует двунаправленный асинхронный протокол между клиентом и сервером. Поверх этого протокола SDK предоставляют запрос-ответ через асинхронное соединение, логику переподключений, управление подписками и их мультиплексирование, обработку таймаутов и ошибок, пинг-понг для поиска "отвалившихся" соединений, обновление токенов и т. д. Некоторые из этих вещей не так уж и тривиальны в реализации. И должны быть реализованы на разных языках программирования. Как вы, возможно, знаете, у нас есть официальные клиентские SDK для Javascript, Dart, Swift, Java и Go.

При реализации одного и того же протокола и одних и тех же функций все SDK вели себя немного по-разному. Это было результатом отсутствия спецификации SDK. Без строгой спецификации SDK было трудно документировать API, трудно объяснить точные детали поведения SDK. То, что мы делали ранее в документации Centrifugo, — указывали пользователям на конкретный репозиторий SDK на Github для поиска деталей поведения.

Самое классное в Centrifugo v4 — SDK API следующего поколения. Теперь у нас есть спецификация API клиентских SDK. Это источник правды о поведении клиентских библиотек, которые стараются точно следовать спецификации.

Новый SDK API является результатом нескольких итераций и размышлений о возможных состояниях, переходах, механизме обновления токенов и т. д. Пользователи в нашей группе Telegram могут помнить, как все начиналось:

И после нескольких итераций эти прототипы превратились в работающие механизмы с четко определенным поведением:

Несколько вещей, которые были пересмотрены с нуля:

Состояния клиента, переходы, события
Состояния подписки, переходы, события
Поведение при обновлении токена подключения и токена подписки
Поведение пинг-понга (подробности см. ниже)
Логика повторной подписки (теперь SDK могут повторно подписаться с backoff-алгоритмом)
Обработка ошибок
Унифицированное поведение backoff (на основе full-jitter подхода)

Теперь у нас есть разделение между временными и постоянными ошибками протокола — это позволяет нам обрабатывать внутренние ошибки сервера подписки на уровне SDK, делая подписки более устойчивыми, с автоматическими повторными подписками и гарантией, что сбои отдельных подписок не повлияют на все соединение.

Механика, описанная в спецификации клиентского SDK API, теперь реализована во всех наших официальных SDK. Пакеты SDK теперь поддерживают все основные функции клиентского протокола, существующие на данный момент. Мы считаем, что это большой шаг вперед для экосистемы и сообщества Centrifugo.

Современная эмуляция WebSocket в JavaScript

В наши дни WebSocket поддерживается почти везде. Но есть случай, который, как мы считаем, является последним, препятствующим подключению пользователей через WebSocket — корпоративные прокси. С корневым сертификатом, установленным на компьютерах сотрудников, эти прокси-серверы могут блокировать трафик WebSocket, даже если он упакован в слой TLS. Это очень раздражает, и часто разработчики вообще не поддерживают подключение клиентов из таких «сломанных» сред.

До версии 4 пользователи Centrifugo могли использовать полифилл-библиотеку SockJS, чтобы решить проблему выше.

SockJS — отличное программное обеспечение — стабильное и проверенное на практике. Он до сих пор используется некоторыми крупными игроками в области обмена сообщениями в реальном времени в качестве фоллбек-транспорта для WebSocket.

Но SockJS — это дополнительная зависимость на фронтенде с пачкой устаревших транспортов, и его будущее туманно.

SockJS сопряжен с заметными накладными расходами — это дополнительный оверхед в протоколе, потребляет больше оперативной памяти на каждое соединение на стороне сервера (по крайней мере, при использовании библиотеки SockJS-Go — единственной готовой опции для реализации сервера SockJS на языке Go в наши дни). При использовании SockJS пользователи Centrifugo теряли возможность использовать наш основной транспорт WebSocket, поскольку SockJS использует собственную реализацию WebSocket на стороне сервера.

SockJS не поддерживает передачу бинарных данных — с ним можно использовать только формат JSON. Как вы знаете, наш основной транспорт WebSocket отлично работает с бинарными данными в случае использования формата Protobuf. Таким образом, с SockJS у нас не было запасного варианта для WebSocket, поддерживающего передачу двоичных данных.

И, наконец, если вы хотите использовать SockJS с распределенным бэкендом, вы должны включить поддержку sticky сессий на уровне балансировщика нагрузки. Таким образом, вы можете направлять запросы от клиента к серверу на правильный серверный узел — тот, который поддерживает постоянное однонаправленное HTTP-соединение.

Мы долго танцевали вокруг идеи заменить SockJS. Но только сейчас мы готовы предоставить ему свою альтернативу — встречайте собственный слой двунаправленной эмуляции Centrifugo. Он основан на двух дополнительных транспортах:

HTTP-стриминг (с использованием современного ReadableStream API в Javascript, поддерживает передачу бинарного Protobuf и JSON).
EventSource (Server-Sent Events, SSE) — хотя это немного более старый боец и работает только с JSON, транспорт EventSource нравится многим разработчикам и может обеспечить запасной вариант в более старых браузерах, в которых нет ReadableStream API, поэтому мы также используем его в двунаправленной эмуляции.

Поэтому, когда используется HTTP-fallback, у вас всегда есть постоянное соединение в направлении "сервер -> клиент". Запросы в направлении "клиент -> сервер" являются обычными HTTP-запросами — аналогично тому, как работает SockJS. Но! Наша двунаправленная эмуляция не требует sticky сессий — Centrifugo может проксировать запросы от клиента к серверу на правильный узел в кластере. Наличие sticky сессий — это оптимизация в двунаправленной эмуляции Centrifugo, а не требование. Мы считаем, что это меняет правила игры для наших пользователей — не нужно беспокоиться о правильной балансировке нагрузки, тем более что в 95% случаев или даже больше пользователи смогут подключиться с помощью транспорта WebSocket.

Вот упрощенная схема того, как это работает:

Двунаправленная эмуляция сейчас поддерживается только в Javascript SDK (centrifuge-js). Мы считаем, что наибольший смысл в ней есть для браузеров. Если мы обнаружим случаи использования, в которых другие SDK могут извлечь выгоду из транспорта на основе HTTP, мы можем расширить их позже.

Давайте рассмотрим пример использования этой функции со стороны Javascript. Чтобы использовать запасные транспорты, все, что вам нужно сделать, это настроить список желаемых транспортов и адресов подключения:

const transports = [
    {
        transport: 'websocket',
        endpoint: 'wss://your_centrifugo.com/connection/websocket'
    },
    {
        transport: 'http_stream',
        endpoint: 'https://your_centrifugo.com/connection/http_stream'
    },
    {
        transport: 'sse',
        endpoint: 'https://your_centrifugo.com/connection/sse'
    }
];
const centrifuge = new Centrifuge(transports);
centrifuge.connect()

Почему не один базовый адрес

Мы используем явные адреса для транспорта в приведенном выше примере из-за того, что адреса можно настроить отдельно в Centrifugo — нет единой точки входа для всех транспортов. Как в Socket.IO или SockJS, когда разработчик может указать клиенту только базовый адрес. В случае с Centrifugo мы запрашиваем у пользователя SDK явную конфигурацию транспорта/адреса подключения.

Кстати, несколько преимуществ HTTP-транспорта перед WebSocket:

Сессии могут автоматически мультиплексироваться (объединяться) в одном соединении в браузере, когда сервер работает по протоколу HTTP/2 или HTTP/3, в то время как в браузерах WebSocket открывает отдельное соединение на каждой вкладке.
Улучшенная поддержка сжатия данных (может быть включена на уровне балансировщика нагрузки).
Для работы с WebSocket требуется дополнительная конфигурация в некоторых балансировщиках нагрузки (например, Nginx).

SockJS по-прежнему поддерживается Centrifugo и centrifuge-js, но теперь он в статусе DEPRECATED.

Отсутствие вложенности в клиентском протоколе

Изменился не только API клиентских SDK, но и формат сообщений протокола Centrifugo. Новый формат более удобочитаем (в случае JSON, конечно), имеет более компактный размер сообщения пинга (подробнее об этом ниже).

Протокол клиента теперь совместим с кодированием/декодированием за один проход. Ранее протокол Centrifugo имел многоуровневую структуру, и нам приходилось кодировать некоторые сообщения, прежде чем добавлять их к сообщению верхнего уровня. Или декодировать два или три раза, чтобы развернуть сообщение. Чтобы достичь хорошей производительности при кодировании и декодировании сообщений клиентского протокола, Centrifugo приходилось использовать различные методы оптимизации, такие как пулы буферов, пулы слайсов байт.

Реструктурировав формат сообщения, мы смогли избежать вложенности, что позволило немного повысить производительность кодирования/декодирования без дополнительных ухищрений и оптимизаций.

Мы также немного упростили документацию клиентского протокола.

Переработанный ПИНГ-ПОНГ

На практике во многих случаях (при работе с постоянными соединениями, такими как WebSocket) PING и PONG являются наиболее распространенными типами сообщений, передаваемых между клиентом и сервером. Ваше приложение может иметь много одновременных подключений, но только некоторые из них получают полезные данные. Но в то же время нам все равно нужно отправлять пинги и отвечать понгами в рамках каждого соединения. Таким образом, оптимизация ping-pong процесса может значительно сократить использование сервером ресурсов CPU.

Одна из оптимизаций в v4 связана с пересмотренным поведением PING-PONG механизма. Предыдущие версии Centrifugo и SDK отправляли ping-запросы и ожидали pong-ответ как в направлении "клиент-> сервер", так и в направлении "сервер -> клиент" (для транспорта WebSocket). Это позволяло обнаружить "отвалившиеся" соединения как на стороне клиента, так и на стороне сервера.

В Centrifugo v4 мы отправляем ping только от сервера к клиенту и ожидаем pong от клиента. На стороне клиента у нас есть таймер, который срабатывает, если не было пинга с сервера в течение настроенного времени, поэтому у нас все еще есть способ обнаруживать закрытые соединения на клиентской стороне.

Отправка пингов только в одном направлении приводит к уменьшению количества пинг-понг сообщений в 2 раза — и это должно быть действительно заметно для инсталляций Centrifugo с тысячами одновременных подключений. В наших экспериментах с 10 000 подключений использование CPU сервера снижалось на 30% по сравнению с Centrifugo v3.

Пинги и понги — это теперь сообщения протокола Центрифуги. Ping — это просто пустой асинхронный пуш с сервера — например, в случае JSON это 2-байтовое сообщение: {}. Pong — это пустая команда от клиента, также {} в случае JSON. Вынос ping-pong на уровень протокола Центрифуги в том числе позволил унифицировать формат пингов для всех наших однонаправленных транспортов (WebSocket, EventSource, HTTP-streaming, GRPC).

Еще одно улучшение заключается в том, что Centrifugo теперь рандомизирует время отправки первого пинга клиенту (но не дольше настроенного интервала пинга). Это позволяет распределять пинг-понг во времени, обеспечивая более плавный профиль CPU, особенно после сценария массового переподключения пользователей.

Безопасные пространства имен каналов по умолчанию

Безопасность данных и конфиденциальность в современном мире важнее, чем когда-либо. И по мере того, как сервер Centrifugo становится все более популярным и широко используемым, потребность в "безопасности по умолчанию" (secure by default) только возрастает.

Раньше по умолчанию аутентифицированные клиенты могли подписаться на все каналы в пространстве имен (кроме приватных каналов, которые теперь пересмотрены — см. подробности ниже). Можно было использовать опцию "protected": true, чтобы сделать пространство имен защищенным, но мы не уверены, что все так делали. Это дополнительная настройка и дополнительные знания о том, как работает Centrifugo.

Кроме того, мы столкнулись с распространенной путаницей среди пользователей: если подписки диктовались JWT токеном, многие пользователи ожидали, что клиент не сможет подписаться на эти каналы самостоятельно используя клиентские подписки. Но без включенной опции "protected" это было не так.

В Centrifugo v4 по умолчанию невозможно подписаться на канал в пространстве имен. Пространство имен должно быть настроено так, чтобы разрешить подписку от клиентов, или должна использоваться авторизация с помощью токена. Существует множество новых параметров пространства имен для настройки поведения. Также появилась возможность указать регулярное выражение для каналов в пространстве имен.

Новые имена параметров каналов лучше отражают назначение параметра. Например, сравните "publish": true и "allow_publish_for_client": true. Второй вариант обеспечивает лучшее понимание эффекта после включения.

Centrifugo теперь более строго проверяет имя канала. Разрешены только символы ASCII — это уже упоминалось в документах ранее, но на самом деле не применялось. Сейчас мы это исправляем.

Мы понимаем, что эти изменения усложнят работу с Centrifugo, особенно когда все, что вам нужно, — это публичный доступ ко всем каналам, не слишком беспокоясь о правах. Это все еще возможно, но теперь намерение должно быть явно выражено в конфиге.

Ознакомьтесь с обновленной документацией о каналах и пространствах имен. Наше руководство по переходу на версию 4 содержит автоматический конвертер параметров пространства имен каналов.

Переработана концепция приватного канала

Приватный канал — это специальный канал, начинающийся с $, на который нельзя было подписаться без JWT. До v4 наличие известного префикса позволяло нам различать общедоступные каналы и приватные каналы. Но поскольку пространства имен теперь по умолчанию не являются общедоступными, это различие не имеет большого значения.

Это означает 2 вещи:

теперь можно подписаться на любой канал, имея действующий JWT (не только те, которые начинаются с $).
на каналы, начинающиеся с $, можно подписаться только с JWT, даже если они принадлежат к пространству имен, в котором подписка разрешена для всех клиентов. Это сделано ради безопасного перехода с v3 на v4.

Еще одно заметное изменение в подписке JWT — поле (claim) "client" теперь DEPRECATED. Больше нет необходимости помещать его в токен подписки. Centrifugo поддерживает его только для обратной совместимости, но в будущих релизах он будет полностью удален.

Причина, по которой мы удаляем claim clientиз токена подписки на самом деле интересна. Из-за того, что claim client был обязательной частью токена, приложения могли столкнуться с ситуацией, когда во время сценария массового повторного подключения ( скажем, миллион соединений переподключаются одновременно) может быть сгенерировано много запросов на новые токены подписки, поскольку токен подписки должен содержать идентификатор клиента, сгенерированный Centrifugo для нового подключения. Из-за этого серверной части приложения могло быть необычно сложно справиться с нагрузкой. С JWT для подключения у нас не было такой проблемы — соединения могли просто повторно использовать предыдущий токен для повторного подключения к Centrifugo.

Теперь токен подписки ведет себя так же, как токен подключения, поэтому мы получаем масштабируемое решение и для подписок на основе токенов.

Более того, это изменение открыло путь к другому важному улучшению...

Оптимистичные подписки

Улучшение, о котором мы только что упомянули, называется оптимистичными подписками. Если кто-то из вас знаком с протоколом QUIC, то оптимистичные подписки чем-то похожи на функцию 0-RTT в QUIC. Идея проста — мы можем включить команды подписки в первый фрейм, отправляемый на сервер.

Раньше мы отправляли подписки только после получения от сервера успешного ответа на команду Connect. Но с новыми изменениями в поведении токенов кажется логичным помещать команды подписки в начальный фрейм подключения. Тем более, что протокол Centrifugo всегда поддерживал отправку нескольких команд в одном фрейме. Даже подписки, использующие JWT, теперь могут быть включены в начальный фрейм во время процесса подключения, поскольку теперь можно использовать начальный токен (или повторно использовать предыдущий токен пока его время жизни не истекло).

Преимущество потрясающее — в большинстве сценариев мы экономим один RTT задержки при подключении к Centrifugo и подписке на каналы (что на самом деле является наиболее распространенным способом использования Centrifugo). Хотя это не заметно на localhost, это очень важно в реальной жизни. В конце концов, это меньше системных вызовов (syscalls) для сервера, что приводит к меньшему использованию CPU.

Оптимистичные подписки также отлично подходят для двунаправленной эмуляции с HTTP, поскольку они позволяют избежать длинного пути проксирования запроса к правильному узлу Centrifugo при подключении.

Оптимистичные подписки реализованы только в centrifuge-js. В какой-то момент мы планируем распространить эту важную оптимизацию на все остальные клиентские SDK.

Channel capabilities

Функция Channel capabilities появилась как часть Centrifugo PRO. Изначально мы стремились сделать его частью open-source версии. Но отсутствие отзывов об этой функции заставило нас задуматься, действительно ли она нужна. Поэтому добавление ее в PRO, где у нас еще есть место для оценки идеи, казалось более безопасным решением на данный момент.

Centrifugo позволяет настраивать разрешения канала на уровне пространства имен. При создании новой функции реального времени рекомендуется создать для нее новое пространство имен и настроить разрешения. Но для достижения лучшего контроля прав теперь можно использовать channel capabilities.

Функция channel capabilities предоставляет возможность устанавливать права в рамках отдельного соединения или подписки на отдельный канал.

Например, в JWT подключения разработчики могут установить что-то вроде:

{
    "caps": [
        {
            "channels": ["news", "user_42"],
            "allow": ["sub"]
        }
    ]
}

И это сообщает Centrifugo, что соединение может подписываться на каналы "news" или "user_42" в любое время, пока соединение активно. Centrifugo также поддерживает wildcard и регулярные выражения для указания соответствий прав и каналов.

JWT подписки на канал также может предоставлять права в рамках канала, поэтому права можно контролировать в рамках отдельной подписки. Например. возможность публиковать и использовать API истории вызовов может быть выражена с помощью поля "allow" в JWT подписки:

{
    "allow": ["pub", "hst"]
}

Подробнее об этом механизме читайте в главе Channel capabilities.

Улучшенный API соединений

Еще одним дополнением к Centrifugo PRO является улучшенный API соединений. Раньше мы могли возвращать только все подключения от определенного пользователя.

API теперь поддерживает фильтрацию всех соединений: по идентификатору пользователя, по подписному каналу, по дополнительной метаинформации, прикрепленной к соединению.

Фильтрация работает по идентификатору пользователя или с помощью выражений CEL (Common Expression Language). Выражения CEL обеспечивают удобный для разработчиков, быстрый и безопасный (поскольку они не являются полными по Тьюрингу) способ проверки некоторых условий. Они используются в сервисах Google (например, Firebase), в конфигурации Envoy RBAC и т. д. Если вы никогда не видели ранее — посмотрите, классный проект. Мы также оцениваем, как использовать выражения CEL для динамической и эффективной проверки разрешений канала, но эта история пока на начальном этапе.

Результат вызова API connections содержит больше полезной информации: список активных каналов клиента, информацию о токенах, используемых для подключения и подписки, метаинформацию, прикрепленную к соединению.

Оптимизированный движок Redis

Еще одна история, которая на данный момент попала в PRO-версию, — это оптимизированный движок Redis. Оптимизированная версия аллоцирует меньше памяти (таким образом, вы можете ожидать снижения потребления CPU для узла Centrifugo) и поддерживает sharded PUB/SUB в Redis Cluster (представленный недавно как часть Redis v7). Вы можете прочитать подробнее в документации – Оптимизированный движок Redis.

Клиент Javascript перенесен на TypeScript

Ни для кого не секрет, что centrifuge-js — самый популярный SDK в экосистеме Centrifugo. Мы проявили немного заботы о нем — и centrifuge-js теперь полностью написан на Typescript ❤️

Это было долгожданное улучшение, и оно, наконец, произошло! Весь публичный API строго типизирован. Круто то, что даже события EventEmitter и обработчики событий подлежат проверке типов - это должно радикально упростить и ускорить разработку, а также уменьшить вероятность ошибок.

Экспериментальная поддержка HTTP/3

Centrifugo v4 имеет экспериментальную поддержку HTTP/3. После включения TLS и установки параметра "http3": true все HTTP-обработчики на внешнем порту будут обслуживаться сервером HTTP/3 на основе библиотеки lucas-clemente/quic-go.

Стоит отметить, что WebSocket по-прежнему будет использовать HTTP/1.1 для своего Upgrade запроса (кстати, существует интересный проект IETF о установке WebSocket соединения с помощью HTTP/3. Но HTTP-streaming и EventSource должны прекрасно работать с HTTP/3.

HTTP/3 в настоящее время не работает с нашим ACME TLS, т. е. вам необходимо явно указать пути к файлам сертификатов и ключей как описано здесь.

Экспериментальная поддержка WebTransport

Наличие HTTP/3 на борту позволило нам сделать еще одну вещь. Некоторые из вас могут помнить пост Эксперименты с QUIC и WebTransport, опубликованный ранее в нашем блоге. С тех пор мы танцевали вокруг идеи добавить WebTransport в Centrifugo. Спецификация WebTransport IETF все еще является черновиком, она сильно изменилась с момента нашей первой публикации в блоге. Но объект WebTransport уже является частью Chrome (начиная с v97), и кажется, что все очень близко к выпуску.

Поэтому мы добавили экспериментальную поддержку WebTransport в Centrifugo v4. Это стало возможным с помощью библиотеки marten-seemann/webtransport-go.

Чтобы использовать WebTransport, вам необходимо запустить экспериментальный сервер HTTP/3 и обработчик WebTransport параметром "webtransport": true в конфигурации. Затем вы можете подключиться к этой конечной точке, используя centrifuge-js. Например, давайте включим WebTransport и будем использовать WebSocket в качестве запасного варианта:

const transports = [
    {
        transport: 'webtransport',
        endpoint: 'https://your_centrifugo.com/connection/webtransport'
    },
    {
        transport: 'websocket',
        endpoint: 'wss://your_centrifugo.com/connection/websocket'
    }
];
const centrifuge = new Centrifuge(transports);
centrifuge.connect()

Обратите внимание, что здесь мы используем безопасные схемы протоколов — https:// и wss://. В то время как в случае с WebSocket вы можете выбрать соединение без TLS, в HTTP/3 и, в частности, с WebTransport соединение без TLS просто не поддерживается спецификацией.

В случае с Centrifugo мы используем двунаправленный поток с надежной доставкой (bidirectional reliable stream) в WebTransport для передачи протокола Центрифуги между клиентом и сервером. Поддерживаются форматы JSON и Protobuf. В некоторых случаях есть некоторые проблемы с правильной передачей совета по отключению, в остальном все уже работает.

Очевидно, что из-за ограниченной поддержки WebTransport в браузерах на данный момент, возможных критических изменений в спецификации WebTransport, мы пока не можем рекомендовать его для использования в "продакшене". В какой-то момент в будущем WebTransport может стать разумной альтернативой WebSocket, сейчас мы более уверены, что Centrifugo сможет обеспечить его поддержку надлежащим образом.

Руководство по миграции

Руководство по миграции содержит шаги по обновлению вашего Centrifugo сервера с версии 3 до версии 4. Несмотря на то, что версия 4 содержит множество изменений, вы можете перейти на Centrifugo v4 без изменения кода на стороне клиента. А затем, после обновления сервера, постепенно обновлять клиентскую часть до последней версии стека.

Заключение

Подводя итог, вот некоторые преимущества Centrifugo v4:

унифицированный опыт работы c SDK для всех платформ;
оптимизированный протокол, который в целом быстрее, компактнее и более удобочитаем в случае JSON, обеспечивает более устойчивое поведение для подписок;
пересмотренная модель безопасности пространства имен каналов, более детальный контроль прав;
более эффективное и гибкое использование токенов (JWT) подписки;
улучшенное время до подписки — благодаря оптимистичным подпискам и возможности предварительно создавать токены подписки (поскольку claim "client" больше не требуется);
возможность использовать более эффективную эмуляцию WebSocket в браузере, не беспокоясь о sticky сессиях (до тех пор пока вы не хотите оптимизировать инфраструктуру системы).

Вот и все. Мы начинаем эпоху Centrifugo v4, и, без сомнения, она будет потрясающей.

P.S. Оригинал статьи в конце содержит благодарности, ссылки на используемые медиа-материалы, а также приглашение в сообщества проекта в Telegram и Discord. Я решил не тащить это на Хабр, посмотрите в оригинале, если вдруг любопытно – прим. переводчика.

Релиз Centrifugo v4 – маленькая революция