Как измерить обход блокировок: восемь механизмов, которые не сработали ни разу

Когда речь заходит о механизмах обхода блокировок, большинство разработчиков полагаются на логику и тесты, но реальность часто оказывается сложнее. В этой статье мы разберем, как команда мессенджера RCQ с открытым кодом и сквозным шифрованием встроила в приложение обход блокировок, а затем потратила двое суток на измерение уже написанных механизмов. Результат оказался неожиданным: из восьми механизмов ни один не сработал так, как ожидалось. Мы расскажем, какие ошибки были допущены, как их выявили и какие уроки можно извлечь для собственных проектов.

Почему измерение стало необходимостью

Разработчики RCQ создавали мессенджер для регионов, где интернет-цензура ограничивает доступ к обычным коммуникационным сервисам. Приложение использует сквозное шифрование и собственные протоколы для обхода блокировок, что делает его востребованным среди пользователей, которым важно сохранить приватность и доступность. Обход блокировок встроен в клиент, чтобы пользователь не думал о настройках: внутри работает sing-box, пул релеев, подписанный конфиг со списком релеев и запасной путь через CDN. Всё это писалось месяцами, но ни разу не измерялось. Команда верила, что механизмы работают, но не имела доказательств. В начале августа они решили исправить это, потратив двое суток на сбор статистики и анализ поведения каждого механизма.

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

Восемь механизмов, которые не сработали

Один из самых ярких примеров — механизм, который должен был срабатывать при блокировке основного соединения. Он был построен и задеплоен, но за всё время наблюдений не выполнился ни разу. Причина — неверная логика: механизм проверял доступность только одного сервера, а не всех, и в итоге никогда не переключался на резерв. Это классическая ошибка, когда разработчик предполагает, что проверка одного сервера достаточно, но в реальности блокировка может затронуть только часть серверов, и механизм остаётся в неведении.

Другой механизм, запасной путь через CDN, срабатывал, но только в 15% случаев, и то не тогда, когда ожидалось, а при определённых условиях, которые не были предусмотрены изначально. Это показывает, что даже работающий механизм может вести себя непредсказуемо, если не учесть все сценарии. Третий механизм, связанный с выбором релеев, не учитывал, что некоторые релеи могут быть недоступны, и выбирал их случайно, что приводило к частым сбоям. Измерения помогли выявить эти проблемы и исправить их.

Как это работает: технические детали

Для тех, кто не знаком с технической стороной, объясним: обход блокировок в RCQ работает так. Приложение пытается установить соединение с основным сервером. Если это не удаётся, оно переключается на резервные релеи, список которых подписан и защищён от подделки. Если и это не помогает, используется запасной путь через CDN, который маскирует трафик под обычный HTTP-запрос. Каждый из этих механизмов должен был срабатывать автоматически, но из-за ошибок в логике они не работали.

Для измерения команда использовала несколько инструментов. Во-первых, они добавили в приложение логирование событий, связанных с обходом блокировок. Во-вторых, настроили агрегацию логов на сервере и дашборд для визуализации. В-третьих, использовали скрипты для автоматического анализа данных. Один из ключевых выводов — важность измерения даже тех механизмов, которые кажутся простыми. Например, механизм проверки доступности сервера использовал TCP-подключение с таймаутом в 10 секунд, но в реальности при блокировке таймаут мог быть больше, и механизм считал сервер недоступным, хотя он работал. Измерения показали, что нужно увеличить таймаут и проверять несколько серверов одновременно.

Какие ошибки были допущены и как их исправить

Ошибки, выявленные в ходе измерений, можно разделить на несколько категорий. Во-первых, недостаточная проверка доступности серверов: механизм проверял только один сервер, что приводило к ложным срабатываниям. Во-вторых, неверные таймауты: слишком короткие таймауты заставляли механизм считать сервер недоступным, хотя он работал. В-третьих, отсутствие учёта региональных особенностей: блокировки могут быть разными в разных странах, и механизм не адаптировался к этому. В-четвёртых, недостаточное логирование: без детальных логов невозможно было понять, почему механизм не срабатывает.

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

Какие уроки можно извлечь разработчикам

Эта история важна не только для пользователей RCQ, но и для всех разработчиков, которые работают с механизмами отказоустойчивости: ретраи, фолбэки, аварийные переключения, резервные каналы доставки. Приёмы, описанные в статье, применимы к любому коду, который включается редко и по чужому расписанию. Главный урок: не верьте в то, что механизм работает, пока не измерите его в реальных условиях. Особенно это актуально для проектов в России и СНГ, где интернет-цензура активно развивается, и обход блокировок становится критически важным.

Для пользователей RCQ это означает, что приложение станет надёжнее: теперь обход блокировок будет работать так, как задумано, а не случайно. Для разработчиков — урок: любой механизм, который должен срабатывать редко, нужно измерять. Восемь из восьми механизмов обхода блокировок не работали так, как ожидалось, и только измерения помогли это выявить. Если вы разрабатываете подобные системы, не полагайтесь на интуицию — добавьте инструменты для измерения и следите за реальным поведением. Это сэкономит вам месяцы работы и нервы пользователей.

Что будет дальше: планы команды RCQ

Команда RCQ уже исправила выявленные ошибки и планирует продолжить измерения на постоянной основе. Они хотят добавить автоматические уведомления о сбоях и настроить мониторинг в реальном времени. В ближайших планах — увеличить пул релеев и улучшить алгоритм выбора, чтобы уменьшить задержки. Эксперты считают, что подобные подходы станут стандартом для приложений, работающих в условиях цензуры. Измерение — это не роскошь, а необходимость, если вы хотите, чтобы ваш продукт действительно работал.

Итог: почему измерение критически важно

Главный вывод из истории RCQ: любой механизм, который должен срабатывать редко, нужно измерять. Восемь из восьми механизмов обхода блокировок не работали так, как ожидалось, и только измерения помогли это выявить. Если вы разрабатываете подобные системы, не полагайтесь на интуицию — добавьте инструменты для измерения и следите за реальным поведением. Это сэкономит вам месяцы работы и нервы пользователей. Теперь, когда вы знаете, как избежать подобных ошибок, вы можете применить эти принципы в своих проектах и сделать их надёжнее.