astelm/telemt

Fork 0

mirror of https://github.com/telemt/telemt.git synced 2026-11-01 21:31:58 +03:00

Files

T

Alexey 9ee8f99413 Added Timeline Draft about Ping-Pong Timings

2026-10-31 12:57:06 +03:00

34 KiB

Raw Blame History

Ping в списке прокси: RPC Ping/Pong и задержки WEB

English | Русский | Deutsch

Наблюдаемые 1000–1500 мс для WEB против 50–150 мс для Classic/DD/EE могут относиться к измерениям с разными границами. В Android локальный сокет WEB-проверки становится готов раньше, чем обязательно готов удалённый WEB-поток. Оставшееся открытие потока и работа транспорта могут попасть в показанный результат. Код не задаёт фиксированный секундный штраф для каждого успешного WEB-ping.

Эти числа предоставлены оператором и не воспроизведены при подготовке документа. Анализ исходников подтверждает механизмы, но не устанавливает причину задержки в конкретном развёртывании.

Клиенты и измерения

Проверено 2026-10-31 по DrKLO Android 3de37c8cfb039452be7398909461da6288babf15 и Telegram iOS 279f89e4d4f63f17227bf877dc3d8990f22ecd58. Установленные релизы и форки могут отличаться.

Измерение	Что охватывает	Поведение WEB
Ping в списке прокси Android	Зашифрованный MTProto `TL_ping` / `TL_pong` через проверяемый прокси	Отдельный WEB-транспорт проверки, затем нативная проверка через локальный сокет.
Ping в списке прокси iOS	Проверка связности `req_pq` / `resPQ`; отсчёт от `connectionOpened`	Записи `.web` исключены из проверки; неактивный WEB-прокси отображается как непроверенный.
ICMP ping	IP echo до выбранного хоста с учётом маршрутизации и политики ICMP	Не измеряет прикладную пересылку и Telegram DC.
WEB transport `FRAME_PING` / `FRAME_PONG` или WebSocket keepalive	Жизнеспособность транспорта/сессии	Это не отображаемый Android результат MTProto.
Telemt ME RPC Ping/Pong	Один путь от Telemt до ME, включая локальную очередь writer и планирование flush	Не включает клиент, WebView и публичный TLS-фронтенд.

Источники: точка входа Android, нативные запросы, фильтр iOS, проверка iOS, интерфейс iOS. Поэтому формулу WEB-ping Android нельзя переносить на WEB-строку текущего iOS.

Android показывает последний результат проверки без медианы или EMA и пропускает новую проверку, если предыдущая была менее двух минут назад. У подключённого прокси тоже может отображаться сохранённый результат: это не непрерывное измерение RTT активной сессии. WEB-проверка создаёт собственный транспорт, а не использует напрямую активный транспорт приложения. См. обновление списка и WEB-транспорт.

Где Android запускает и останавливает таймер

Для Classic/DD/EE нативный callback готовности приходит после удалённого TCP-соединения и необходимой подготовки транспорта прокси, включая EE FakeTLS. Обработка запроса обновляет временную метку перед отправкой или повторной отправкой проверки. Поэтому обычный успешный замер исключает это начальное установление транспорта, но включает последующую пересылку и обратный путь. См. готовность сокета и обработку запросов.

Для WEB запуск моста, начальная HTTPS-загрузка, HELLO/WELCOME и дополнительные 500 мс ожидания предшествуют native_checkProxy; эти 500 мс не прибавляются к показанному ping. WELCOME подтверждает WEB-сессию, а не готовность потока до Telegram DC. Затем нативная проверка подключается к 127.0.0.1: готовность этого сокета не ждёт завершения удалённого OPEN. Java accept/OPEN и обновление нативной временной метки могут выполняться в разном порядке. Учитывается только работа, оставшаяся внутри интервала измерения. См. порядок проверки, локальный сокет и WELCOME, создание серверной сессии и обработку потока.

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

sequenceDiagram
    participant C as Android native checker
    participant P as Classic/DD/EE proxy
    participant D as Telegram DC
    C->>P: DNS / TCP / proxy transport setup
    Note over C,P: Remote transport ready, measurement timestamp refreshed
    C->>P: Encrypted TL_ping
    P->>D: Relay
    D->>P: TL_pong
    P->>C: Relay
    Note over C: Display elapsed time from latest request timestamp

sequenceDiagram
    participant C as Android native checker
    participant B as Local socket / Java / WebView
    participant T as TLS frontend / Telemt
    participant D as Telegram DC
    B->>T: Bridge load, HELLO / session creation
    T->>B: WELCOME
    Note over B: Wait 500 ms before native_checkProxy
    C->>B: Connect to 127.0.0.1
    Note over C,B: Local socket ready, measurement timestamp refreshed
    Note over B,T: OPEN may race with the native timestamp update
    C->>B: MTProxy header and encrypted TL_ping
    B->>T: OPEN / DATA over selected carrier
    T->>D: Stream setup and relay via Direct / ME
    D->>T: TL_pong
    T->>B: Downlink DATA
    B->>C: Local socket delivery
    Note over C: Display elapsed time from latest request timestamp

TL_pong завершает замер относительно последней временной метки запроса. Принудительная обработка или повторная отправка могут обновить её: результат не обязательно равен полному времени неудачной попытки с повторами. Проверка использует существующий ключ авторизации DC; полный обмен для создания нового ключа MTProto не является обязательной частью каждой проверки.

Вклад TLS

Публичное TLS-соединение завершается в NGINX, HAProxy или Caddy. Telemt получает обычный HTTP/1.1 на приватном listener. Внешний HTTP/2 и внутренний HTTP/1.1 — разные соединения; версии протокола на этих участках могут различаться. EE FakeTLS — маскирующий транспорт MTProxy, а не браузерное HTTPS-соединение с проверкой сертификата. WEB переносит plain/DD MTProxy; EE не является форматом секрета WEB. См. руководство WEB.

Для нового соединения без потерь обычный TCP-handshake занимает примерно один RTT между клиентом и фронтендом. Полный TLS 1.3 handshake обычно добавляет один RTT, полный TLS 1.2 — два. Это оценка обменов протокола без DNS, обработки, проверки сертификата, планирования и повторной передачи, а не измеренный бюджет задержки WEB. Возобновление TLS-сессии может изменить обмен. См. TLS 1.3 и TLS 1.2.

Начальный TLS для загрузки моста обычно происходит до измерения Android. Дополнительные HTTP-соединения или WebSocket Upgrade могут оказаться внутри него; повторное использование соединений нужно подтверждать трассировкой. Постоянное HTTPS-соединение и установленный WebSocket не выполняют новый TLS-handshake для каждого ping. cache: 'no-store' управляет кешированием, а не повторным использованием TCP/TLS. Для объяснения и диагностики не требуется отключать проверку сертификатов или включать TLS 0-RTT. См. постоянные HTTP-соединения и запросы моста.

Где WEB добавляет работу относительно обычного MTProxy

На схеме разделены этапы до запуска таймера Android и работа, которая может попасть в показанный результат. Базовый вариант — Classic/DD поверх TCP. Для EE FakeTLS относится к подготовке нативного транспорта. Размеры блоков и длины стрелок не обозначают длительность.

flowchart LR
    subgraph N["Обычный MTProxy: Classic/DD"]
        direction TB
        N0["До измерения<br/>DNS + TCP + подготовка нативного транспорта"] --> N1["Удалённый транспорт готов<br/>Временная метка запроса обновлена"]
        N1 --> N2["Запрос и ответ MTProxy<br/>Оставшаяся подготовка relay, сеть, очереди, Telegram DC"] --> N3["Получен TL_pong<br/>Отображаемый замер завершён"]
    end
    subgraph W["WEB: MTProxy внутри HTTPS или WebSocket"]
        direction TB
        W0["До измерения<br/>DNS + TCP + настоящий TLS<br/>HTTP-мост + HELLO/WELCOME + 500 мс"] --> W1["Локальный сокет готов<br/>Временная метка запроса обновлена"]
        W1 --> W2["Дополнительная работа клиента<br/>Очереди Java / WebView / JavaScript<br/>Удалённый OPEN ещё может быть не завершён"] --> W3["Работа транспорта на отправке<br/>HTTP upload или кадр WebSocket<br/>Обработка фронтендом и возможная буферизация"]
        W3 --> W4["Внутренний запрос и ответ MTProxy<br/>Оставшаяся подготовка relay, сеть, очереди, Telegram DC"] --> W5["Работа транспорта на приёме<br/>HTTP poll или кадр WebSocket<br/>Ожидание ACK/commit и очереди доставки в native"]
        W5 --> W6["Получен TL_pong<br/>Отображаемый замер завершён"]
        X["Только если нужно ещё одно соединение<br/>TCP + TLS, возможный WebSocket Upgrade<br/>При переиспользовании нет handshake на каждый ping"] -.-> W3
        X -.-> W5
        R["Только при ошибках или перегрузке<br/>Повторы и backoff<br/>Retry-After: 1 может добавить около секунды"] -.-> W3
        R -.-> W5
    end
    classDef preparation fill:#eeeeee,stroke:#666666,color:#111111
    classDef boundary fill:#dbeafe,stroke:#2563eb,color:#111111
    classDef shared fill:#dcfce7,stroke:#15803d,color:#111111
    classDef extra fill:#ffedd5,stroke:#c2410c,color:#111111
    class N0,W0 preparation
    class N1,N3,W1,W6 boundary
    class N2,W4 shared
    class W2,W3,W5,X,R extra

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

При повторном использовании транспорта условные затраты на TCP/TLS/Upgrade исчезают, но остаются формирование кадров, обработка HTTP или WebSocket и очереди клиента. HTTP может совмещать отправку и приём: каждый запрос не обязательно добавляет целый RTT. Polling пробуждается при появлении данных, а буферизация фронтенда зависит от развёртывания. Потери, перегрузка сети и подготовка upstream могут задерживать и обычный MTProxy.

Таким образом, в видимую разницу могут войти оставшееся открытие WEB-потока, дополнительные соединения, обработка транспорта, планирование и подтверждённые повторы. Это не фиксированная надбавка TLS и не арифметическая сумма блоков. Начальный настоящий TLS намеренно показан до таймера Android: он влияет на полное время проверки, но обычно не на отображаемый замер. Отдельный транспорт проверки также означает, что активное соединение приложения не гарантирует прогретую проверку в списке прокси.

Ориентировочная временная шкала

Поясняющая модель, а не бенчмарк и не норматив задержки. Числа подобраны, чтобы показать сложение этапов. Они не восстанавливают наблюдавшиеся 1000–1500 мс. Условия примера: DNS уже закеширован, RTT от клиента до фронтенда — 40 мс, TCP-соединение новое, при необходимости выполняется полный TLS 1.3 handshake, ключ авторизации DC уже есть, потерь и сброса нативной временной метки запроса нет. Базовый вариант — Classic/DD. Для EE собственная подготовка FakeTLS добавляется до нативного таймера.

В этом примере подготовка обычного MTProxy занимает 40 мс на TCP. Подготовка WEB занимает 750 мс: 50 мс на запуск клиента/моста + 40 мс TCP + 40 мс TLS + 120 мс HTTP-обмена загрузки моста/создания сессии + 500 мс ожидания Android checker. Здесь выбраны последовательные длительности; в действительности этапы могут перекрываться. Начальный TLS и ожидание 500 мс находятся вне отображаемого ping.

Шкала ниже начинается с последней временной метки запроса каждой проверки, а не с запуска приложения или первой попытки соединения. Один символ соответствует 20 мс. Три строки — отдельные сценарии, а не одновременные запросы:

                0         200       400       600       800       1000      1200 мс
                |---------|---------|---------|---------|---------|---------|
Classic/DD      RRRRR                                                             100 мс
WEB             UURRRRRDDD                                                        200 мс
WEB + retry     FF..................................................UURRRRRDDD    1240 мс

Далее указаны длительности целых участков из одинаковых символов, а не одного символа: R = 100 мс базовой работы MTProxy relay/сети/DC для запроса и ответа. U = 40 мс дополнительной работы WEB на отправке/OPEN/клиенте. D = 60 мс дополнительной работы WEB на приёме и доставке. F = 40 мс одной неудачной попытки upload. . = 1000 мс ожидания по Retry-After: 1. U и D — условные дополнительные затраты сверх R, а не повторный учёт полного сетевого RTT. Ожидание ACK/commit учитывается лишь в той мере, в какой оно действительно задержало доставку.

Сценарий	До таймера ping	Отображаемый ping	Полное время проверки в модели
Classic/DD	40 мс	100 мс	140 мс
WEB без ошибок	750 мс	40 + 100 + 60 = 200 мс	950 мс
WEB с одной неудачной загрузкой и одним ожиданием повтора	750 мс	40 + 1000 + 40 + 100 + 60 = 1240 мс	1990 мс

Ещё одно TCP + TLS 1.3 соединение, открытое внутри замера, могло бы добавить здесь около 80 мс при полностью последовательном выполнении: замер 200 мс превратился бы в 280 мс. При переиспользовании соединения затраты на этот дополнительный handshake равны нулю. Замена начального полного TLS 1.3 handshake на TLS 1.2 при этих условиях добавляет примерно 40 мс к подготовке, а не к показанному ping. В примерах не учтены обработка TLS, возобновление сессии и потери пакетов.

Строка с 1240 мс показывает один возможный механизм секундного результата — повтор, подтверждённый HTTP-трассировкой. Она не доказывает, что исходное наблюдение вызвано повторами. Если такого повтора нет, нужно найти другие фактические задержки: очереди, буферизацию фронтенда, открытие соединений или работу upstream. Не подставляйте таймауты вместо пауз и не переносите перекрывающиеся этапы в эту последовательную модель без проверки.

HTTP, WebSocket и другие источники задержки

Фактор	Влияние и подтверждение
HTTP uplink	Генерируемый мост предлагает `X-Telemt-Up-Window: 4`; сервер принимает 1–4, при отсутствии согласования используется 1. Окно 1 ждёт ACK перед следующей загрузкой, окно 4 допускает ограниченный параллелизм. Не весь HTTP работает по схеме «отправить и ждать». См. согласование и обработчик сессии.
Первый downlink	`/down` может запускаться одновременно с `/up`; обязательного дополнительного последовательного ACK RTT нет. Первичная доставка в нативный клиент ждёт первого корректного upload ACK/commit. Кадры доставляются по мере поступления. См. conveyor и downlink.
Long polling	`long_poll_secs=25` ограничивает ожидание при отсутствии данных. Готовые данные немедленно будят poll. Промежутки между запросами и занятые слоты соединений браузера всё же могут задержать доставку. См. серверный polling.
Общие ресурсы транспорта	`https` использует общую очередь загрузки; `https-lanes` разделяет логические линии. WebSocket после Upgrade передаёт кадры без POST на каждый кадр; `websocket-lanes` разделяет сокеты. Сеть, flow control и ресурсы WebView остаются общими. HTTP/2 мультиплексирует потоки, но не устраняет все задержки от перегрузки и flow control. См. HTTP/2 и руководство по транспортам.
Буферизация фронтенда	Буферизация запросов/ответов или отсутствие поддержки streaming/Upgrade могут задерживать короткие сообщения. Сверьте настройки с существующим примером NGINX, сохраняя маршрутизацию, аутентификацию и лимиты.
Планирование клиента	Java accept/read, UI dispatch, WebView/JavaScript и возврат в нативный код добавляют очереди. Нагрузка CPU, энергосбережение и смена мобильной сети могут усиливать задержки.
Пересылка и сеть	Могут учитываться оставшийся admission потока, внутренний MTProxy-handshake, подключение Direct или регистрация ME, ответ Telegram, потери/повторная передача и очереди. Готовая WEB-сессия не доказывает готовность upstream.
Ошибки и повторы	Telemt может вернуть `503` с `Retry-After: 1`. Мост учитывает его; для других повторов backoff начинается с 250 мс и удваивается до 2000 мс плюс jitter примерно до 25%, в пределах бюджета повторов. Повторяемые HTTP-статусы включают 408/429/502/503/504. Прежде чем объяснять секундную ступень этим механизмом, нужно увидеть события в трассировке. См. ответы и повторы.

Дедлайны не являются обязательными паузами. Стандартные 10 с для запроса моста, 90 с бюджета повторов, 30 с ожидания первого байта потока и 10 с handshake потока нельзя складывать в обычный ping. carrier_probe_coalesce_ms=0 отключает соответствующую дополнительную задержку объединения проб. Дедлайны переключения транспорта относятся к неудачным попыткам, а не к каждому успешному обмену. См. значения по умолчанию.

Условно WEB-замер включает оставшуюся подготовку + передачу через транспорт и сеть + очереди + ответ Telegram + задержки повторов, попавшие внутрь таймера. Этапы перекрываются; складывать все таймауты или назначать отдельный RTT каждому HTTP endpoint некорректно. Готовый транспорт может сократить подготовку, но Android проверяет прокси через отдельный транспорт. WebSocket не всегда быстрее; используйте только поддерживаемые клиентом транспорты. Для совместимости с текущим iOS используется https.

Диагностика с сохранением защит

Запишите клиент/сборку, версию Android WebView, транспорт, публичный endpoint, семейство IP, сеть, маршрут Direct/ME, DC и нагрузку. Сравнивайте при одинаковых условиях. Учитывайте двухминутное кеширование Android: повторное чтение интерфейса не означает новый замер.
Разделяйте три эксперимента: новую проверку в списке прокси; новый логический поток на готовом транспорте; прикладной RPC в установленной MTProto-сессии. Последние два требуют подходящих средств измерения в клиенте и не предоставляются автоматически списком прокси. Собирайте отдельные замеры и распределения, а не сравнивайте единичный холодный замер с прогретым.
Используйте аутентифицированный GET /web-status и существующие настройки [web.debug]: capture_timings=true, capture_frames=true, body_capture="metadata". Включите ограниченный сбор по руководству диагностики WEB, затем восстановите предыдущее состояние. Payload, capabilities и секреты для этой задачи не нужны.
Сопоставьте создание сессии, выбор/commit/ошибку транспорта, stream_admitted, stream_first_byte, handshake_succeeded, OPEN/DATA, HTTP-статусы и повторы. relay_started предшествует работе с upstream и не означает готовность DC. GET /v1/runtime/web/status и GET /v1/runtime/web/sessions дают контекст ёмкости и давления очередей, а не сквозной RTT.
request_body_us, response_ready_us и response_body_us — смещения от входа в обработчик. Это не независимые длительности для сложения и не моменты отправки в сеть или TCP ACK от другой стороны. Сравнивайте смещения там, где они записаны и имеют подходящий смысл. См. определения timing-полей.
Добавьте измерения соединений/TLS/запросов фронтенда и временные метки клиента, чтобы найти задержку вне Telemt. Проверьте повторное использование соединений, согласованный HTTP, буферизацию и Upgrade. Sideband-события запуска моста/HELLO не дают полную временную шкалу клиента. Для сравнения разных хостов синхронизируйте часы либо используйте локальные длительности.
При ME сопоставьте существующий trace ME RTT sample (rtt_ms, ema_ms, base_ms, degraded). Метка ставится до очереди writer/flush; EMA состоит из 80% прежнего значения и 20% нового замера. Планирование keepalive до этой метки не учитывается. Низкий ME RTT при высоком Android ping указывает на работу вне измеренного участка ME, но не определяет конкретную причину. См. writer и reader.

Примеры интерпретации: быстрая обработка Telemt при поздней доставке клиенту направляет проверку к фронтенду, сети и очередям клиента; 503 вместе с Retry-After: 1 подтверждает задержку повтора; длительная работа upstream требует изучения Direct/ME. Ни один из признаков сам по себе не доказывает, что 1000–1500 мс вызваны криптографией TLS. При сборе данных сохраняйте совместимость, проверку сертификатов, лимиты admission и backpressure.

Границы подтверждения

Документ описывает изученные исходники, а не сквозной тест на устройствах. Ссылки Android/iOS закрепляют указанные ревизии; ссылки Telemt ведут к сопровождающей документ реализации рабочего дерева, включая локальные WEB-изменения, и не утверждают идентичность всех опубликованных пакетов. Документация не меняет клиент, сервер, таймауты или настройки безопасности.

34 KiB Raw Blame History Unescape Escape