- C++ 95.8%
- Python 1.9%
- Objective-C++ 0.7%
- CMake 0.6%
- CSS 0.2%
- Other 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
loop-uh
c8120a7a6d
All checks were successful
Desktop source guards / guards (push) Successful in 8s
Every MTProto session through a WEB proxy is a stream on a single
carrier whose relay keeps one FIFO per direction. Bulk media and
uploads filled that FIFO, every session's own 4-8s receive timer then
fired at once, and the reconnects piled new OPENs behind the same
backlog.
- Uplink: a scheduler serves interactive streams first, download
requests next and uploads round-robin in 64 KiB frames, with at most
1 MiB of upload bytes uncredited by the relay (one bounded batch in
front of a chat request); a burst guard keeps uploads from starving.
- Downlink: download streams keep only a share of a 2 MiB credit budget
(256 KiB..1 MiB each) instead of the full 4 MiB window, so media waits
in the backend's TCP buffers rather than in front of chat replies.
- Liveness: a WEB session asks the carrier before dropping its stream.
It waits while its request is still queued or the downlink is busy,
fails when the pipe is quiet for 8s after delivery, busy for 30s, or
after 64s total. A carrier with bytes outstanding and no relay
progress for 20s is recovered once, for all streams.
- A WEB session opens one stream instead of racing identical ones, and
a -404 on a WEB stream reconnects first; only a second -404 before any
reply decrypts destroys the temporary key.
- Uploads and downloads use at most two sessions per DC through a WEB
proxy, and slow upload parts are no longer cancelled and moved.
- web_carrier diagnostics report carrier state, stalls, per-class
stream and queue counts, credit and throughput every 10s of activity.
The policy lives in web_proxy_flow.{h,cpp} and is covered by the new
test_web_proxy_flow target and a source guard.
|
||
| .forgejo | ||
| .grok | ||
| cmake@5e21e7ac35 | ||
| docs | ||
| lib/xdg | ||
| snap | ||
| Telegram | ||
| tools | ||
| .clang-tidy | ||
| .devcontainer.json | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| changelog.txt | ||
| CMakeLists.txt | ||
| GROK.md | ||
| LEGAL | ||
| LICENSE | ||
| README.md | ||
ZaStoGram Desktop
ZaStoGram — форк Telegram Desktop, заточенный под работу в сетях с DPI‑цензурой и под приватность. Цель проекта: чтобы клиент уверенно подключался там, где обычный Telegram режут, маскировал трафик под обычный браузерный HTTPS и не терял переписку (удалённые сообщения, истории, правки).
Это неофициальная сборка. Она основана на исходниках официального клиента и сохраняет весь его функционал, добавляя сверху сетевой стелс, WSS‑транспорт и набор приватных функций.
⚠️ Используйте на свой риск. Проект не связан с Telegram FZ‑LLC. Базовый код — под GPLv3 с OpenSSL‑исключением (см. раздел «Лицензия»).
Чем отличается от обычного Telegram Desktop
| Область | Что добавлено |
|---|---|
| Обход DPI | FakeTLS‑стелс: профили ClientHello, правдоподобные повторные TLS‑подключения через поддельные билеты возобновления, маскировка старта, фрагментация ClientHello, варьирование размера TLS‑записей, пейсинг трафика, разнос попыток подключения |
| Надёжность | Классифицированный loop‑backoff переподключения (cap 8 c), деприоритизация «залипших» endpoint'ов (cooldown) |
| Транспорт | Встроенный WSS (MTProto поверх WebSocket к web‑релею Telegram) |
| Прокси | Обязательный прокси (force‑proxy) + дефолтный локальный SOCKS5 127.0.0.1:1353 |
| Приватность | Сохранение удалённых сообщений и историй (stories), скачивание любых (даже защищённых) историй, история правок сообщений |
| Скорость подключения | Убраны две клиентские задержки, найденные измерением: очередь дозвонов (было до 8 с ожидания на поздних сокетах) и невыключенный алгоритм Нейгла |
| Производительность | Ограничение числа потоков софт‑декодера видео, троттлинг под нагрузкой |
| UX | Список прокси больше не устраивает «шквал» проверок при открытии |
| Бренд | Имя и иконка ZaStoGram |
🛡️ Обход DPI — стелс MTProxy
Когда задан MTProxy (FakeTLS), клиент маскирует подключение под настоящий браузерный TLS‑хэндшейк. Всё настраивается тумблерами в окне прокси (Настройки → Продвинутые → Тип соединения → список прокси).
- Профиль ClientHello — ClientHello воспроизводит форму реального браузера/приложения:
Auto (Yandex),Auto‑rotate,Firefox,Firefox Android,Yandex,Android OkHttp. ПрофилиChrome ModernиAndroid Chromeостались в таблице, но больше не отправляются: измерением найдено, что фильтрующая сеть отвергает именно их — 3 попытки из 12 против 12 из 12 у остальных, на одном релее в одни минуты. Выбранный вручную отключённый профиль автоматически заменяется на рабочий. - Маскировка старта (startup‑cover) — первые записи разбиваются и подаются так, чтобы начало сессии не выделялось характерным паттерном.
- Фрагментация ClientHello — ClientHello дробится при отправке, чтобы DPI было сложнее собрать и распознать его целиком.
- Варьирование размера TLS‑записей — размеры записей не фиксированы, что ломает сигнатуры по длине.
- Пейсинг трафика — межзаписевые задержки на старте сглаживают «взрывной» профиль (без удушения уже установленного потока).
- Разнос попыток подключения — попытки к нескольким endpoint'ам стартуют со сдвигом, а не пачкой. Сдвиг намеренно небольшой (50 мс): измерение показало, что релеи спокойно принимают два десятка одновременных рукопожатий, а большой разнос стоил секунд на старте — подробности в разделе про задержку.
- Правдоподобные повторные TLS‑подключения — первый ClientHello к узлу и имени назначения идёт без PSK, как обычный «холодный» заход браузера. После успешного fakeTLS‑хэндшейка клиент держит небольшой локальный пул поддельных билетов возобновления с ограниченным временем жизни и при повторных подключениях отправляет один из них с нормальным возрастом. Это убирает подозрительный паттерн «каждый параллельный сокет приносит новый случайный PSK» и делает повторные подключения похожими на обычный браузерный HTTPS. Эти билеты нужны только для маскировки, не используются для шифрования MTProto и не сохраняются на диск.
Надёжность подключения
- Loop‑backoff — классифицированные таймауты переповтора, привязанные к прокси, с верхней границей, чтобы не зацикливаться на мёртвом узле и не спамить коннектами.
- Endpoint cooldown — endpoint, который только что отвалился, временно понижается в приоритете (а не выбрасывается), чтобы клиент пробовал живые маршруты, не теряя резервные.
🌐 WSS‑транспорт
Встроенный MTProto‑over‑WebSocket (чистая реализация на QSslSocket + RFC 6455): настоящий TLS → HTTP‑upgrade (GET /apiws) → бинарные WS‑фреймы, внутри которых идёт обфусцированный MTProto‑поток. Подключается к официальным web‑релеям Telegram (kws2/kws4.web.telegram.org) для DC2/DC4.
Включается тумблером «Route via WSS (web, DC2/DC4 only)». Полезен там, где прямой TCP к DC блокируется, но веб‑Telegram работает. Может ходить как напрямую, так и через заданный SOCKS‑прокси.
Альтернатива встроенному WSS — внешний локальный прокси (telegram_proxy из zapret‑набора) на 127.0.0.1:1353, к которому клиент подключается по SOCKS5 (см. ниже).
🔌 Прокси: обязательный + дефолтный
- Force‑proxy — без выбранного прокси клиент не выходит в сеть; «щит» соединения виден всегда. Исключение — включённый режим WSS (он сам является методом обхода). Это страховка от случайного прямого подключения в опасной сети.
- Дефолтный SOCKS5
127.0.0.1:1353— добавляется в список один раз (если такого ещё нет; существующие прокси не перетираются). Это endpoint внешнего сервисаtelegram_proxy: схемаtdesktop → SOCKS5 1353 → telegram_proxy → WSS/FakeTLS → Telegram.
🔒 Приватность
Клиент‑сайд функции, которые сохраняют данные локально (по умолчанию включены):
- Сохранение удалённых сообщений — когда сервер присылает «удалить», сообщение не уничтожается локально, а остаётся (помечается как удалённое отправителем). Переписка не пропадает.
- Сохранение историй (stories) — локальный снэпшот историй с восстановлением при старте; истории не исчезают по истечении срока.
- Скачивание любых историй — медиа истории сохраняется на диск даже для защищённых от пересылки (noforwards) и чужих историй, без Premium (снят клиентский гейт canDownload).
- История правок — при редактировании сообщения предыдущие версии (текст + время) сохраняются, чтобы видеть, что было изменено.
Это локальные функции: они не влияют на сервер и не нарушают шифрование. Хранение части данных может быть только в памяти до перезапуска (персистентность отдельных частей — в развитии).
⚡ Производительность
- Decoder policy — централизованное ограничение числа потоков софтверного видео‑декодера и троттлинг запуска декодеров под нагрузкой, чтобы тяжёлые медиа не «съедали» CPU и не плодили лишние декодеры.
Задержка подключения: что было измерено и убрано
Жалобу «через прокси медленно, пинг большой» обычно списывают на сеть. Мы разложили её на слои и померили с двух машин — на сети с фильтрацией и без неё:
| слой | что это | типичные значения |
|---|---|---|
| TCP | до релея | 11–70 мс |
| FakeTLS | релей отвечает сам | 9–71 мс |
| resPQ | релей → Telegram → релей | 55–94 мс суммарно |
Оказалось, что фильтрация к задержке не добавляет ничего: на одном и том же релее сеть с блокировками и сеть без них дали 17/55 мс против 11/56 мс. Секунды создавал сам клиент, и нашлось два источника.
- Очередь дозвонов. Попытки к одному релею разносились на 250 мс, а холодный старт открывает десятки сокетов — поздние ждали своей очереди секундами (в логе
tcp_msдоходил до 8666 мс при сетевом round trip 17 мс). Разнос вводился ради маскировки, но измерение показало, что цена ему не соответствует: 24 дозвона вообще без разноса дошли до Telegram все 24, вся пачка за 170 мс, тогда как через очередь те же 24 стоили около шести секунд. Разнос снижен до 50 мс — этого хватает, чтобы соединения приходили различимо, а не одним мгновением. Рост разноса при неудачах не тронут: именно он защищает релей, который действительно не тянет пачку. - Алгоритм Нейгла.
TCP_NODELAYне выставлялся ни на одном сокете. Нейгл придерживает короткую запись, пока не подтверждена предыдущая, а MTProto устроен ровно так: короткий запрос, затем ожидание. Тонкость, из‑за которой это легко сделать вхолостую: Qt применяет опции сокета через движок, который появляется только после установления соединения, поэтому выставлять их надо в обработчикеconnected, а не в конструкторе.
Обе правки закрыты тестами, которые держат числа рядом с константой — чтобы следующий, кто захочет вернуть разнос, спорил с измерением, а не с догадкой.
Как выбирать релей по скорости. Сравнивать надо не пинг до релея, а сумму: путь до него плюс путь от него до дата‑центра Telegram. Релей с отличным пингом, но далёкий от Telegram, на практике медленнее скромного, стоящего рядом с ним — в наших замерах два релея различались вдвое по суммарному времени именно из‑за этого.
🧰 Спокойная архитектура прокси
- Список прокси не запускает проверку всех строк при открытии окна — это убирает «шквал» одновременных тестовых коннектов. Строки по умолчанию в состоянии Unknown; проверка запускается вручную по пункту Check Status.
🗺️ Roadmap (запланировано, ещё не реализовано)
- Глобальный лимитер MTProxy‑handshakes — в текущем Desktop каждый аккаунт держит свой
MTP::Instanceсо своей DC‑сессией (разные auth keys, msg_id/seqno, salt), поэтому «один общий поток» для всех аккаунтов сделать нельзя без серверной поддержки. Вместо этого планируется безопасный лимитер: общий cap на число одновременных MTProxy‑handshakes между аккаунтами + jitter/backoff + очередь; снижение числа активных проверок ротации (10 → 1–2); кэширование статусов прокси; единый gate для всехStartProxyCheckи рабочих handshakes. Это сгладит всплеск подключений, не душа уже установленный трафик. - UI приватности — видимая метка «удалено» на сохранённых сообщениях и просмотрщик истории правок (контекст‑меню).
🏗️ Сборка и проверки
- Forgejo Actions выполняет быстрые проверки исходников из
.forgejo/workflows/source-guards.ymlна изолированном Linux Runner. - Тяжёлая Windows-сборка выполняется локальным публикатором на выделенной Windows-машине, после чего проверенные
.exe, ZIP и файлы автообновления загружаются в Forgejo Releases. - Единый список обязательных исходных проверок хранится в
Telegram/SourceFiles/tests/release_guards.txt; его используют и Forgejo Actions, и локальный Windows-публикатор. - Инструкции по ручной сборке официального клиента (применимы и здесь) — в
docs/.
Базовый клиент собирается стандартным тулчейном Telegram Desktop. Артефакты пре‑релиза переименовываются в
ZaStoGram-<arch>.exe.
📥 Установка
Скачайте ZaStoGram-x64.exe (или x64_x86 для 32‑бит) из раздела Releases (пре‑релиз dev-N). Это сборка из исходников этого репозитория. Для работы дефолтного прокси 127.0.0.1:1353 нужен запущенный внешний сервис telegram_proxy, либо включите встроенный WSS‑транспорт.
📄 Лицензия
Проект основан на Telegram Desktop и распространяется под GPLv3 с OpenSSL‑исключением — тот же текст лицензии, что и у апстрима, см. LICENSE и LEGAL.
ZaStoGram — независимый форк; товарные знаки Telegram принадлежат их владельцам.