From b144075b73fa99a392a9b14b7b8409ec5864bfb9 Mon Sep 17 00:00:00 2001 From: Alexey <247128645+axkurcom@users.noreply.github.com> Date: Sat, 31 Oct 2026 13:03:19 +0300 Subject: [PATCH] Timeline as Diagram --- docs/WEB/PROXY_PING.de.md | 32 ++++++++++++++++++++++++-------- docs/WEB/PROXY_PING.en.md | 32 ++++++++++++++++++++++++-------- docs/WEB/PROXY_PING.ru.md | 32 ++++++++++++++++++++++++-------- 3 files changed, 72 insertions(+), 24 deletions(-) diff --git a/docs/WEB/PROXY_PING.de.md b/docs/WEB/PROXY_PING.de.md index 254645e..f44eb97 100644 --- a/docs/WEB/PROXY_PING.de.md +++ b/docs/WEB/PROXY_PING.de.md @@ -119,17 +119,33 @@ Die sichtbare Differenz kann somit verbleibenden WEB-Streamaufbau, zusätzliche In diesem Beispiel benötigt natives MTProxy 40 ms Vorbereitung für TCP. Die WEB-Vorbereitung dauert 750 ms: 50 ms Client-/Bridge-Start + 40 ms TCP + 40 ms TLS + 120 ms HTTP-Austausch für Bridge und Sitzung + 500 ms Wartezeit des Android-Checkers. Hier werden aufeinanderfolgende Dauern angenommen; reale Phasen können überlappen. Das anfängliche TLS und die 500 ms Wartezeit liegen außerhalb des angezeigten Pings. -Die Skala beginnt beim **letzten Anfragezeitstempel** der jeweiligen Prüfung, nicht beim App-Start oder ersten Verbindungsversuch. Ein Zeichen entspricht 20 ms. Die drei Zeilen sind getrennte Szenarien, keine gleichzeitigen Anfragen: +Die Darstellung beginnt beim **letzten Anfragezeitstempel** der jeweiligen Prüfung, nicht beim App-Start oder ersten Verbindungsversuch. Die horizontale Achse zeigt Sekunden mit Millisekundengenauigkeit (0.200 = 200 ms). Die Balkenbreite ist proportional zur Dauer. Jeder Abschnitt ist ein separates Szenario; seine Phasen folgen aufeinander und laufen nicht parallel. Die anfängliche Vorbereitung liegt außerhalb der Darstellung. -```text - 0 200 400 600 800 1000 1200 ms - |---------|---------|---------|---------|---------|---------| -Classic/DD RRRRR 100 ms -WEB UURRRRRDDD 200 ms -WEB + retry FF..................................................UURRRRRDDD 1240 ms +```mermaid +%%{init: {"theme": "neutral", "gantt": {"leftPadding": 200, "rightPadding": 100, "barHeight": 24, "barGap": 8, "fontSize": 14, "sectionFontSize": 14}}}%% +gantt + dateFormat x + axisFormat %S.%L + tickInterval 200millisecond + todayMarker off + title Angezeigter Ping - Beispielmodell + accTitle: Angezeigter Ping - Beispielmodell + accDescr: Sekunden seit Anfragezeitstempel, Beschriftungen in Millisekunden + section Classic/DD - 100 ms + R 100 ms :n_r, 0, 100ms + section WEB ohne Fehler - 200 ms + U 40 ms :w_u, 0, 40ms + R 100 ms :w_r, after w_u, 100ms + D 60 ms :w_d, after w_r, 60ms + section WEB mit Retry - 1240 ms + F 40 ms :crit, f_u, 0, 40ms + Warten 1000 ms :crit, retry_wait, after f_u, 1000ms + U 40 ms :retry_u, after retry_wait, 40ms + R 100 ms :retry_r, after retry_u, 100ms + D 60 ms :retry_d, after retry_r, 60ms ``` -Die folgenden Dauern beziehen sich auf ganze Folgen gleicher Zeichen, nicht auf einzelne Zeichen: `R` = 100 ms grundlegende MTProxy-Relay-/Netzwerk-/DC-Arbeit für Anfrage und Antwort. `U` = 40 ms zusätzliche WEB-Uplink-/OPEN-/Client-Arbeit. `D` = 60 ms zusätzliche WEB-Downlink-/Zustellarbeit. `F` = 40 ms für einen fehlgeschlagenen Upload-Versuch. `.` = 1000 ms Wartezeit gemäß `Retry-After: 1`. `U` und `D` sind beispielhafte Zusatzkosten gegenüber `R`, keine erneute Anrechnung des gesamten Netzwerk-RTT. Die ACK/Commit-Freigabe wird nur berücksichtigt, soweit sie die Zustellung tatsächlich verzögert. +Dauer der einzelnen Phasen: `R` = 100 ms grundlegende MTProxy-Relay-/Netzwerk-/DC-Arbeit für Anfrage und Antwort. `U` = 40 ms zusätzliche WEB-Uplink-/OPEN-/Client-Arbeit. `D` = 60 ms zusätzliche WEB-Downlink-/Zustellarbeit. `F` = 40 ms für einen fehlgeschlagenen Upload-Versuch. `Warten` = 1000 ms Wartezeit gemäß `Retry-After: 1`. `U` und `D` sind beispielhafte Zusatzkosten gegenüber `R`, keine erneute Anrechnung des gesamten Netzwerk-RTT. Die ACK/Commit-Freigabe wird nur berücksichtigt, soweit sie die Zustellung tatsächlich verzögert. | Szenario | Vor dem Ping-Timer | Angezeigter Ping | Gesamtdauer der Prüfung im Modell | | --- | --- | --- | --- | diff --git a/docs/WEB/PROXY_PING.en.md b/docs/WEB/PROXY_PING.en.md index 261e570..d6775d8 100644 --- a/docs/WEB/PROXY_PING.en.md +++ b/docs/WEB/PROXY_PING.en.md @@ -119,17 +119,33 @@ Thus the visible difference can include remaining WEB stream setup, additional c For this example, native preparation takes 40 ms for TCP. WEB preparation takes 750 ms: 50 ms client/bridge startup + 40 ms TCP + 40 ms TLS + 120 ms HTTP bridge/session exchange + the Android checker's 500 ms wait. These are chosen serial durations for this example; real stages can overlap. The initial TLS and the 500 ms wait are outside the displayed ping. -The following scale starts at each checker's **latest request timestamp**, not at app launch or the first connection attempt. One character represents 20 ms. The three rows are separate scenarios, not concurrent requests: +The diagram starts at each checker's **latest request timestamp**, not at app launch or the first connection attempt. The horizontal axis shows seconds with millisecond precision (0.200 = 200 ms). Bar widths are proportional to duration. Each section is a separate scenario; its stages are successive, not parallel. Initial preparation remains outside the diagram. -```text - 0 200 400 600 800 1000 1200 ms - |---------|---------|---------|---------|---------|---------| -Classic/DD RRRRR 100 ms -WEB UURRRRRDDD 200 ms -WEB + retry FF..................................................UURRRRRDDD 1240 ms +```mermaid +%%{init: {"theme": "neutral", "gantt": {"leftPadding": 200, "rightPadding": 100, "barHeight": 24, "barGap": 8, "fontSize": 14, "sectionFontSize": 14}}}%% +gantt + dateFormat x + axisFormat %S.%L + tickInterval 200millisecond + todayMarker off + title Displayed ping - illustrative model + accTitle: Displayed ping - illustrative model + accDescr: Seconds from the request timestamp, labels show milliseconds + section Classic/DD - 100 ms + R 100 ms :n_r, 0, 100ms + section WEB without errors - 200 ms + U 40 ms :w_u, 0, 40ms + R 100 ms :w_r, after w_u, 100ms + D 60 ms :w_d, after w_r, 60ms + section WEB with retry - 1240 ms + F 40 ms :crit, f_u, 0, 40ms + Wait 1000 ms :crit, retry_wait, after f_u, 1000ms + U 40 ms :retry_u, after retry_wait, 40ms + R 100 ms :retry_r, after retry_u, 100ms + D 60 ms :retry_d, after retry_r, 60ms ``` -The following durations refer to whole runs of symbols, not individual characters: `R` = 100 ms of baseline MTProxy relay/network/DC request-response work. `U` = 40 ms of additional WEB uplink/OPEN/client work. `D` = 60 ms of additional WEB downlink/delivery work. `F` = 40 ms spent on one failed upload attempt. `.` = the 1000 ms wait requested by `Retry-After: 1`. `U` and `D` are illustrative incremental costs beyond `R`, not a second count of the full network round trip. ACK/commit gating is included only insofar as it actually delays delivery. +Stage durations: `R` = 100 ms of baseline MTProxy relay/network/DC request-response work. `U` = 40 ms of additional WEB uplink/OPEN/client work. `D` = 60 ms of additional WEB downlink/delivery work. `F` = 40 ms spent on one failed upload attempt. `Wait` = the 1000 ms wait requested by `Retry-After: 1`. `U` and `D` are illustrative incremental costs beyond `R`, not a second count of the full network round trip. ACK/commit gating is included only insofar as it actually delays delivery. | Scenario | Before ping timer | Displayed ping | Total check time in this model | | --- | --- | --- | --- | diff --git a/docs/WEB/PROXY_PING.ru.md b/docs/WEB/PROXY_PING.ru.md index a076e3b..00e4e86 100644 --- a/docs/WEB/PROXY_PING.ru.md +++ b/docs/WEB/PROXY_PING.ru.md @@ -119,17 +119,33 @@ flowchart LR В этом примере подготовка обычного MTProxy занимает 40 мс на TCP. Подготовка WEB занимает 750 мс: 50 мс на запуск клиента/моста + 40 мс TCP + 40 мс TLS + 120 мс HTTP-обмена загрузки моста/создания сессии + 500 мс ожидания Android checker. Здесь выбраны последовательные длительности; в действительности этапы могут перекрываться. Начальный TLS и ожидание 500 мс находятся вне отображаемого ping. -Шкала ниже начинается с **последней временной метки запроса** каждой проверки, а не с запуска приложения или первой попытки соединения. Один символ соответствует 20 мс. Три строки — отдельные сценарии, а не одновременные запросы: +Диаграмма начинается с **последней временной метки запроса** каждой проверки, а не с запуска приложения или первой попытки соединения. Горизонтальная ось показывает секунды с точностью до миллисекунд (0.200 = 200 мс). Ширина полос пропорциональна длительности. Каждая секция — отдельный сценарий; его этапы выполняются последовательно, а не параллельно. Начальная подготовка остаётся за пределами диаграммы. -```text - 0 200 400 600 800 1000 1200 мс - |---------|---------|---------|---------|---------|---------| -Classic/DD RRRRR 100 мс -WEB UURRRRRDDD 200 мс -WEB + retry FF..................................................UURRRRRDDD 1240 мс +```mermaid +%%{init: {"theme": "neutral", "gantt": {"leftPadding": 200, "rightPadding": 100, "barHeight": 24, "barGap": 8, "fontSize": 14, "sectionFontSize": 14}}}%% +gantt + dateFormat x + axisFormat %S.%L + tickInterval 200millisecond + todayMarker off + title Отображаемый ping - условная модель + accTitle: Отображаемый ping - условная модель + accDescr: Секунды от метки запроса, подписи этапов в миллисекундах + section Classic/DD - 100 мс + R 100 мс :n_r, 0, 100ms + section WEB без ошибок - 200 мс + U 40 мс :w_u, 0, 40ms + R 100 мс :w_r, after w_u, 100ms + D 60 мс :w_d, after w_r, 60ms + section WEB с повтором - 1240 мс + F 40 мс :crit, f_u, 0, 40ms + Ожидание 1000 мс :crit, retry_wait, after f_u, 1000ms + U 40 мс :retry_u, after retry_wait, 40ms + R 100 мс :retry_r, after retry_u, 100ms + D 60 мс :retry_d, after retry_r, 60ms ``` -Далее указаны длительности целых участков из одинаковых символов, а не одного символа: `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 учитывается лишь в той мере, в какой оно действительно задержало доставку. +Длительности этапов: `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 | Полное время проверки в модели | | --- | --- | --- | --- |