astelm/telemt
1
0
Fork 0
mirror of https://github.com/telemt/telemt.git synced 2026-11-01 21:31:58 +03:00
Code Issues Packages Projects Releases Wiki Activity

Timeline as Diagram

Browse Source
This commit is contained in:
Alexey
2026-10-31 13:03:19 +03:00
parent 9ee8f99413
commit b144075b73
3 changed files with 72 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/WEB/PROXY_PING.de.md
+24 -8
View File
@@ -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. 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 ```mermaid
0 200 400 600 800 1000 1200 ms %%{init: {"theme": "neutral", "gantt": {"leftPadding": 200, "rightPadding": 100, "barHeight": 24, "barGap": 8, "fontSize": 14, "sectionFontSize": 14}}}%%
|---------|---------|---------|---------|---------|---------| gantt
Classic/DD RRRRR 100 ms dateFormat x
WEB UURRRRRDDD 200 ms axisFormat %S.%L
WEB + retry FF..................................................UURRRRRDDD 1240 ms 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 | | Szenario | Vor dem Ping-Timer | Angezeigter Ping | Gesamtdauer der Prüfung im Modell |
| --- | --- | --- | --- | | --- | --- | --- | --- |
docs/WEB/PROXY_PING.en.md
+24 -8
View File
@@ -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. 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 ```mermaid
0 200 400 600 800 1000 1200 ms %%{init: {"theme": "neutral", "gantt": {"leftPadding": 200, "rightPadding": 100, "barHeight": 24, "barGap": 8, "fontSize": 14, "sectionFontSize": 14}}}%%
|---------|---------|---------|---------|---------|---------| gantt
Classic/DD RRRRR 100 ms dateFormat x
WEB UURRRRRDDD 200 ms axisFormat %S.%L
WEB + retry FF..................................................UURRRRRDDD 1240 ms 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 | | Scenario | Before ping timer | Displayed ping | Total check time in this model |
| --- | --- | --- | --- | | --- | --- | --- | --- |
docs/WEB/PROXY_PING.ru.md
+24 -8
View File
@@ -119,17 +119,33 @@ flowchart LR
В этом примере подготовка обычного MTProxy занимает 40 мс на TCP. Подготовка WEB занимает 750 мс: 50 мс на запуск клиента/моста + 40 мс TCP + 40 мс TLS + 120 мс HTTP-обмена загрузки моста/создания сессии + 500 мс ожидания Android checker. Здесь выбраны последовательные длительности; в действительности этапы могут перекрываться. Начальный TLS и ожидание 500 мс находятся вне отображаемого ping. В этом примере подготовка обычного MTProxy занимает 40 мс на TCP. Подготовка WEB занимает 750 мс: 50 мс на запуск клиента/моста + 40 мс TCP + 40 мс TLS + 120 мс HTTP-обмена загрузки моста/создания сессии + 500 мс ожидания Android checker. Здесь выбраны последовательные длительности; в действительности этапы могут перекрываться. Начальный TLS и ожидание 500 мс находятся вне отображаемого ping.
Шкала ниже начинается с **последней временной метки запроса** каждой проверки, а не с запуска приложения или первой попытки соединения. Один символ соответствует 20 мс. Три строки — отдельные сценарии, а не одновременные запросы: Диаграмма начинается с **последней временной метки запроса** каждой проверки, а не с запуска приложения или первой попытки соединения. Горизонтальная ось показывает секунды с точностью до миллисекунд (0.200 = 200 мс). Ширина полос пропорциональна длительности. Каждая секция — отдельный сценарий; его этапы выполняются последовательно, а не параллельно. Начальная подготовка остаётся за пределами диаграммы.
```text ```mermaid
0 200 400 600 800 1000 1200 мс %%{init: {"theme": "neutral", "gantt": {"leftPadding": 200, "rightPadding": 100, "barHeight": 24, "barGap": 8, "fontSize": 14, "sectionFontSize": 14}}}%%
|---------|---------|---------|---------|---------|---------| gantt
Classic/DD RRRRR 100 мс dateFormat x
WEB UURRRRRDDD 200 мс axisFormat %S.%L
WEB + retry FF..................................................UURRRRRDDD 1240 мс 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 | Полное время проверки в модели | | Сценарий | До таймера ping | Отображаемый ping | Полное время проверки в модели |
| --- | --- | --- | --- | | --- | --- | --- | --- |