- PVSM.RU - https://www.pvsm.ru -
Недавно разработчики Telegram выложили исходные тексты прокси-сервера, работающего по протоколу MTProto. На хабре вышли статьи об особенностях его сборки [1] и перепаковке докер-контейнера с ним [2]. Официальный прокси сервер, написанный на С, удивляет объемом кода — примерно 23 тысячи строк. Одновременно с этим, а иногда и чуть раньше, вышло несколько альтернативных реализаций, но ни одна из них не поддерживала возможность рекламы своего канала.
В данной статье хотелось бы, во-первых, рассказать о малоизвестных особенностях протокола общения прокси-сервера с внешними серверами и, во-вторых, рассказать о собственной разработке — реализации прокси-сервера на Python, которая только что достигла релиза и доступна всем желающим под свободной лицензией MIT.
Фуф, надеюсь не утомил техническими деталями. Теперь должно быть понятно, почему во многих альтернативных прокси нет поддержки рекламы — они передают сообщения напрямую серверам телеграма, минуя middle-proxy. Получается значительно проще. Во второй части статьи описывается первая неофициальная реализация прокси сервера, которая работает через middle-proxy. В данный момент в свободном доступе можно найти три таких реализации: официальную, на Erlang и эту.
Изначально прокси-сервер писался для того, чтобы понять особенности протокола и был развитием другого проекта — асинхронного сокс-прокси, написанного, в свою очередь, чтобы «потрогать» async/await в Питоне.
Постепенно у проекта появились пользователи, которые завалили вопросами, баг-репортами и фич-реквестами. После доработок проект вошёл в стадию бета-тестирования и стабилизации, которая длилась примерно неделю и задействовала пять серверов разных конфигураций.
Перед тем как рассказать о фичах, которых пока нет у официального прокси сервера, но есть у альтернативного (и умолчать о функциях, которые есть у официального и нет у альтернативного), расскажу о вещи, которая у многих первой приходит в голову при упоминании слова Python.
Для тестирования производительности использовалась виртуальная машина в облаке минимальной конфигурации: 1 CPU, 1024MB RAM.
На синтетических тестах прокси сервер оказался способен передавать порядка 240мегабит/сек или 3000 сообщений/сек. При использовании альтернативной реализации event-loop'а на С, которая называется uvloop, а также при использовании интерпретатора PyPy данные производительности получаются иные (все измерения — в секунду):
При тестировании на реальных пользователях оказалось, что такого сервера хватает, чтобы с комфортом обслуживать 4 000 пользователей или 8 000 при использовании PyPy.Большим сюрпризом оказалось то, что как бы не рекламировался тестовый сервер в русскоязычных каналах, все равно 89% пользователей были из Ирана (возможно, для других стран количество одновременно обслуживаемых пользователей будет отличаться). Выглядит это так:
Я поспрашивал нескольких администраторов других серверов — у них ситуация такая же. Возможно, это связано с тем, что на территории России телеграм хорошо работает без прокси-серверов. В Иране тестовые сервера блокировались для населения спустя несколько часов после создания.
Нагрузка на сервер при 2 000 пользователях. Чётко виден момент блокировки сервера для граждан Ирана.
Таким образом производительность CPU не является узким местом на тестируемом узле. При 10 000 клиентах, скорее всего, закончится память.
Одновременное использование нескольких ядер CPU не реализовано (привет, GIL).
Работа по протоколу IPv6.
Прокси-сервер без дополнительной настройки умеет использовать IPv6 для исходящих соединений. Соединения по IPv6 не блокируются на территории России (пока).
Режим работы без middle-proxy
Если реклама канала не нужна, прокси автоматически соединяется напрямую с серверами телеграма, минуя middle-proxy. Это быстрее и надёжнее.
Так же, реализован опциональный "быстрый режим", когда сообщения от сервера Телеграма до прокси и от прокси до клиента шифруются одним и тем же ключём. Таким образом прокси не нужно перешифровывать сообщения — он отправляет их как есть. На безопасность это не должно влиять т.к. в любом случае у администратора прокси-сервера нет доступа к сообщениям пользователей.
Автообновление списка middle-proxy и секрета раз в сутки.
Официальный прокси сервер для обновления списка middle-proxy рекомендует рестартовать docker-контейнер раз в сутки, что сбрасывает все соединения. Новые соединения могут не установиться если, например, в стране заблокировали сервер. Питоновская версия периодически ходит на сайт и обновляет список.
Многоплатформенность
Поддерживаются любые платформы, на которых запускается Python. Получалось запустить его даже на iPad, правда, внешние входящие соединения блокировались устройством. Отдельно поддерживается Windows, для меня стало сюрпризом как много людей запускают прокси под данной ОС. Хотя под Windows можно запустить и официальный клиент, если использовать технологии виртуализации или докер.
Возможность простого запуска без докера.
Если (вдруг) есть те, кто не любят докер, прокси может быть запущен и без него. Нужно указать минимум два параметра в файле конфигурации: порт и секрет, также можно задать опциональный рекламный тег, затем выполнить команду: python3 mtprotoproxy.py. Правда, в таком случае придётся думать над автозапуском в ОС, например писать unit-file для systemd. Ещё нужно будет установить pycrypto или pycryptodome, без него будет работать, но очень медленно.
В случае с докером контейнер можно пересобрать командой docker-compose up --build.
Ограничение скорости скачивания больших файлов.
При скачивании больших файлов можно, на уровне TCP, «просить» middle-proxy или сервер Телеграма посылать данные медленнее. Сейчас это сделано с помощью установки маленького значения буфера приёма, что дополнительно экономит память сервера.
Потоковая передача сообщений.
Сейчас, все известные прокси-серверы, работающие с middle-proxy, сначала считывают от клиента сообщение и только потом его передают. Размер одного сообщения может достигать 1МБ. Требуется память на его хранение и немного увеличивается задержка передачи. Можно передавать данные потоково. Это усложнит код, но сократит потребление памяти в худшем случае.
Изменение длины пакетов для обхода фильтра по длине пакета [6].
Не успело попасть в релиз.
Другие реализации MTProto-прокси с поддержкой рекламы каналов:
Благодарности
seriyps [11] — за помощь с тестированием на реальных пользователях
shifttstas [12] — за советы по докеру
forst [13](github) — за идею и реализацию работы по IPv6
p1ratrulezzz [14](github) — за советы и за статью про проект
freekzy [15](github) — за патч бага с утечкой дескрипторов
Автор: alexbers
Источник [16]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/python/283001
Ссылки в тексте:
[1] особенностях его сборки: https://habr.com/company/vds/blog/412783/
[2] перепаковке докер-контейнера с ним: https://habr.com/post/413881/
[3] core.telegram.org/getProxyConfig: https://core.telegram.org/getProxyConfig
[4] core.telegram.org/getProxyConfigV6: https://core.telegram.org/getProxyConfigV6
[5] core.telegram.org/getProxySecret: https://core.telegram.org/getProxySecret
[6] фильтра по длине пакета: https://habr.com/post/414099/
[7] github.com/alexbers/mtprotoproxy.git;: https://github.com/alexbers/mtprotoproxy.git;
[8] Официальная: https://github.com/TelegramMessenger/MTProxy
[9] На Erlang: https://github.com/seriyps/mtproto_proxy
[10] На Python: https://github.com/alexbers/mtprotoproxy
[11] seriyps: https://habr.com/users/seriyps/
[12] shifttstas: https://habr.com/users/shifttstas/
[13] forst: https://habr.com/users/forst/
[14] p1ratrulezzz: https://habr.com/users/p1ratrulezzz/
[15] freekzy: https://habr.com/users/freekzy/
[16] Источник: https://habr.com/post/414139/?utm_campaign=414139
Нажмите здесь для печати.