The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Ассиметрия трафика, !*! maxnetstat, 10-Мрт-20, 20:52  [смотреть все]
Добрый день, форумчане!

Требуется ваша помощь в таком вопросе:
Ассиметрия TCP трафика на вход и исход.

Дано:
1. Сервер в России (Сервер А)
На сервер дается канал 1Гбит/с без каких-либо ограничений.
Установлен Debian 9.

2. Удаленный сервер в Германии на площадке у крупного провайдера (Сервер B).
На сервер дается канал 1Гбит/с без каких-либо ограничений.
ОС Linux, дистрибутив и версия ядра неизвестна.

Трасса между серверами в обе стороны одинакова.

Требуется:
Получить между серверами А и B максимально возможный канал связи по ширине.


(А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
(B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.

Если использовать несколько потоков (около 20), то канал (B -> A) можно загрузить до 500 Мбит/с,
в один же поток в пиках до 70 Мбит/с.
Кроме того, первые несколько порций данных передавались со скоростью выше 100Мбит/с, затем скорость падала.


С обеих сторон менялись сервера (помогали провайдеры), использовались и сервера с подключением 10 Гбит/с, и обычные ПК. Во всех случаях результат был одинаковым, как описан выше.

Внутри сети провайдера в Германии и России с помощью iperf получали между серверами симметричные 900Мбит/с.

На мой взгляд проблема выглядит либо как работа шейпера, либо проблема с очередями или размером TCP окна со стороны сервера в России.
Но, непонятно, как в этом случае получали почти полный  1Гбит/с между нашим сервером и сервером провайдера.

Пробовали настраивать размер очереди на сетевом интерфейсе, увеличивали размер TCP окна - совершенно безрезультатно. Единственный "результат" получили, когда запретили динамически увеличивать окно  - получили на канале 15 Мбит/с вместо уже привычных 50.


Буду благодарен за советы.


  • Ассиметрия трафика, !*! Ann None, 22:24 , 10-Мрт-20 (1)
    Пробовали сделать аналогичные тесты с сервером на третьей площадке?
    Направление трафика уточните. iperf по умолчанию меряет исходящий трафик.
    Была подобная ситуация, в результате разборов на стороне российской площадки корректировали маршрут.
    • Ассиметрия трафика, !*! maxnetstat, 01:22 , 11-Мрт-20 (2)
      > Пробовали сделать аналогичные тесты с сервером на третьей площадке?
      > Направление трафика уточните. iperf по умолчанию меряет исходящий трафик.
      > Была подобная ситуация, в результате разборов на стороне российской площадки корректировали
      > маршрут.

      не пробовали, т.к. не нашли где-то рядом работающий публичный iperf сервер, который мог бы дать 1Гбит/с.

      Да, вы правы, iperf измеряет исход, но также ключ -R позволяет инициировать генерацию трафика на удаленной стороне. Использовали этот метод.
      По поводу маршрутов.
      Наш провайдер менял трассу и давал канал через разных апстримов, но ситуация не менялась.
      Но сказать с уверенностью, что всегда обратная трасса была такой же не могу.

  • Ассиметрия трафика, !*! ACCA, 02:05 , 11-Мрт-20 (3)
    > (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
    > (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.

    Возможно, какой-нибудь СОРМ работает.

    Что значит "поток"?
    Какой тест у iperf3? TCP? А на UDP что видно?

    Если UDP не будет зажат, то есть вариант с WireGuard.

    • Ассиметрия трафика, !*! maxnetstat, 11:42 , 11-Мрт-20 (4)
      >> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
      >> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.
      > Возможно, какой-нибудь СОРМ работает.
      > Что значит "поток"?
      > Какой тест у iperf3? TCP? А на UDP что видно?
      > Если UDP не будет зажат, то есть вариант с WireGuard.

      Имею ввиду одну TCP сессию. Параметр -P позволяет запускать несколько потоков.
      -P, --parallel n
      number of parallel client streams to run

      По умолчанию TCP.
      UDP показывает много потерь в обе стороны.
      Но ведь в одну сторону по TCP я получаю 900Мбит/с.

      Вы имеете ввиду построить туннель и проверять в нем?

      • Ассиметрия трафика, !*! ACCA, 02:52 , 12-Мрт-20 (5)
        > UDP показывает много потерь в обе стороны.
        > Но ведь в одну сторону по TCP я получаю 900Мбит/с.

        Ну, вот тебе и ответ. Потеря пакета уменьшает размер окна TCP. В одну сторону пакеты теряются чаще, потому и перекос. Гоняй тест UDP и тычь провайдера палкой, потерь не должно быть.

    • Ассиметрия трафика, !*! Garri, 11:48 , 13-Мрт-20 (13)
      >> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
      >> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.
      > Возможно, какой-нибудь СОРМ работает.
      > Что значит "поток"?
      > Какой тест у iperf3? TCP? А на UDP что видно?
      > Если UDP не будет зажат, то есть вариант с WireGuard.

      Сорм получает данные по port-mirroring что никак не должно влиять.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру