mirror of
https://github.com/telemt/telemt.git
synced 2026-11-01 13:21:58 +03:00
Added Timeline Draft about Ping-Pong Timings
This commit is contained in:
@@ -113,6 +113,34 @@ flowchart LR
|
||||
|
||||
Таким образом, в видимую разницу могут войти оставшееся открытие 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 мс. Три строки — отдельные сценарии, а не одновременные запросы:
|
||||
|
||||
```text
|
||||
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 и другие источники задержки
|
||||
|
||||
| Фактор | Влияние и подтверждение |
|
||||
|
||||
Reference in New Issue
Block a user