Различия

Показаны различия между двумя версиями страницы.

--- dpi:qoe_analytics:qoe_gui:dashboard [2025/11/01 09:32] – elena.krasnobryzh
+++ dpi:qoe_analytics:qoe_gui:dashboard [2025/11/01 09:40] (текущий) – elena.krasnobryzh
@@ Строка 58: / Строка 58: @@
   - В пункте //Сбор статистики UPLINK LOAD RATE// выбрать //Включено//
 После выполненных действий нажать кнопку //Сохранить// в верхней части экрана.\\
-{{dpi:qoe:use_cases:uplink_settings.png?1100 |}}
+{{:dpi:qoe_analytics:qoe_gui:dashboard:uplink_settings.png?1100 |}}
 === Внешний вид ===
@@ Строка 65: / Строка 65: @@
 На боковой панели можно настроить (1) и удалить (2) каждый виджет. \\
-{{dpi:qoe:use_cases:widget_panel.png?300|}} \\
+{{:dpi:qoe_analytics:qoe_gui:dashboard:widget_panel.png?300|}} \\
 В окне настройки виджета (1) можно изменить имя виджета на английском и русском языках (3) и его видимость (4). \\
-{{dpi:qoe:use_cases:widget_setup_1.png?300|}} \\
+{{:dpi:qoe_analytics:qoe_gui:dashboard:widget_setup_1.png?300|}} \\
 В верхней части экрана можно выбрать, за какой период будет отображаться трафик (5), выбрать источник данных (6). \\
-{{dpi:qoe:use_cases:widget_setup_2.png?600|}} \\
+{{:dpi:qoe_analytics:qoe_gui:dashboard:widget_setup_2.png?600|}} \\
 Для каждого протокола в его плитке отображается:
@@ Строка 80: / Строка 80: @@
   - 4-7 баллов — удовлетворительно, кривая желтого цвета
   - 8-10 баллов — плохо, кривая красного цвета
-  * **Кривая** изменения оценки здоровья протокола (12). Кривая показывает, сколько раз менялась оценка протокола на выбранный период времени и не было ли плохих оценок. \\ {{dpi:qoe:use_cases:widget_estimate.png?350|}}
+  * **Кривая** изменения оценки здоровья протокола (12). Кривая показывает, сколько раз менялась оценка протокола на выбранный период времени и не было ли плохих оценок. \\ {{:dpi:qoe_analytics:qoe_gui:dashboard:widget_estimate.png?350|}}
 === Настройка протоколов в виджете ===
 При наведении на виджет в его верхнем правом углу появится значок ☰. Нажав на него, можно перейти в настройки, либо удалить виджет.
-{{dpi:qoe:use_cases:widget_protocols_setup.png?200|}}
+{{:dpi:qoe_analytics:qoe_gui:dashboard:widget_protocols_setup.png?200|}}
 При нажатии на пункт //Настройки// откроется форма настройки. Здесь представлен список протоколов (1), их количество — от 1 до 10. Чтобы отображать больше 10 протоколов, можно добавить на дашборд несколько виджетов. Например, можно сделать несколько тематических виджетов — на мессенджеры и соцсети, стримы и прочее, в каждом до 10 протоколов.
@@ Строка 99: / Строка 99: @@
 Рекомендованные значения влияния дельты объема трафика на оценку протокола (в %) и показателей RTT определяются разработчиком и передаются оператору, который далее настраивает их исходя из особенностей своей сети.
-{{dpi:qoe:use_cases:widget_setup_form.png?400|}}
+{{:dpi:qoe_analytics:qoe_gui:dashboard:widget_setup_form.png?400|}}
 === Что делать в случае проблемы ===
@@ Строка 122: / Строка 122: @@
 == RTT от абонента до DPI ==
-{{ :dpi:dpi_components:dpiui:rtt_from.jpg?1000 |}}
+{{ :dpi:qoe_analytics:qoe_gui:dashboard:rtt_from.jpg?1000 |}}
 == RTT к абоненту - от сервера до DPI (в случае если завершение было инициировано со стороны клиента) ==
-{{ :dpi:qoe:use_cases:rtt_to.jpg?1000 |}}
+{{ :dpi:qoe_analytics:qoe_gui:dashboard:rtt_to.jpg?1000 |}}
 ==Особенности протокола TCP и расчет RTT==
@@ Строка 132: / Строка 132: @@
 == RTT от клиента до DPI для некоторых flow равен нулю ==
-{{ :dpi:dpi_components:dpiui:rtt_no_ack.jpg?1000 |}}
+{{ :dpi:qoe_analytics:qoe_gui:dashboard:rtt_no_ack.jpg?1000 |}}
 В случае, если DPI не получил ACK от клиента на отправленный SYN/ACK.
 Подобная ситуация может случиться по нескольким причинам, например, клиент разорвал соединение физически, либо прислал RST.
@@ Строка 138: / Строка 138: @@
 == RTT для некоторых flow принимают очень большие значения (десятки секунд) ==
-{{ :dpi:dpi_components:dpiui:rtt_zero.jpg?1000 |}}
+{{ :dpi:qoe_analytics:qoe_gui:dashboard:rtt_zero.jpg?1000 |}}
 Например, такая ситуация может возникнуть в случае TCP HALF CLOSED CONNECTION (наполовину закрытый TCP), когда один из участников соединения прекращает передачу данных, однако все еще может получать данные от удаленной стороны. В таком случае, передающая сторона может послать FYN/ACK только после завершения передачи данных, в следствии чего, значение RTT значительно возрастет.
@@ Строка 146: / Строка 146: @@
   - Процент ретрансмитов, когда трафик от абонета
   - Процент ретрансмитов, когда трафик к абонету
-{{ :dpi:dpi_components:dpiui:tcp-retransmission.jpg?900 |}}
+{{ :dpi:qoe_analytics:qoe_gui:dashboard:tcp-retransmission.jpg?900 |}}
 Виды перезапросов:
   * TCP Retransmission – классический тип повторной передачи пакетов. Отправитель пакета, не получив подтверждения получения от адресата по истечении таймера retransmission timer, отправляет пакет повторно автоматически, предполагая, что он потерян по пути следования. Значение таймера подстраивается гибко и зависит от кругового времени передачи по сети для конкретного канал связи. Как он рассчитывается можно узнать в RFC6298 Computing TCP's Retransmission Timer.
   * TCP Fast Retransmission – отправитель отправляет повторно данные немедленно после предположения, что отправленные пакеты потеряны, не дожидаясь истечения времени по таймеру (ransmission timer). Обычно триггером для этого является получение нескольких подряд (обычно три) дублированных подтверждений получения с одним и тем же порядковым номером.Например, отправитель передал пакет с порядковым номером 1 и получил подтверждение – порядковый номер плюс 1, т.е. 2. Отправитель понимает, что от него ждут следующий пакет с номером два. Предположим, что следующие два пакета потерялись и получатель получает данные с порядковым номером 4. Получатель повторно отправляет подтверждение с номером 2. Получив пакет с номером 5, отправитель все равно отправляет подтверждение с номером 2. Отправитель видит три дублированных подтверждения, предполагает, что пакеты 2, 3 были потеряны и шлет их заново, не дожидаясь таймера.
   * Spurious Retransmission – этот тип повторной передачи появился в версии 1.12 сниффера Wireshark и означает, что отправитель повторно отправляет пакеты, на которые получатель уже отправил подтверждение.

Различия

Что вы хотели найти?