Добрый день, форумчане!Требуется ваша помощь в таком вопросе:
Ассиметрия 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.
Буду благодарен за советы.
Пробовали сделать аналогичные тесты с сервером на третьей площадке?
Направление трафика уточните. iperf по умолчанию меряет исходящий трафик.
Была подобная ситуация, в результате разборов на стороне российской площадки корректировали маршрут.
> Пробовали сделать аналогичные тесты с сервером на третьей площадке?
> Направление трафика уточните. iperf по умолчанию меряет исходящий трафик.
> Была подобная ситуация, в результате разборов на стороне российской площадки корректировали
> маршрут.не пробовали, т.к. не нашли где-то рядом работающий публичный iperf сервер, который мог бы дать 1Гбит/с.
Да, вы правы, iperf измеряет исход, но также ключ -R позволяет инициировать генерацию трафика на удаленной стороне. Использовали этот метод.
По поводу маршрутов.
Наш провайдер менял трассу и давал канал через разных апстримов, но ситуация не менялась.
Но сказать с уверенностью, что всегда обратная трасса была такой же не могу.
> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.Возможно, какой-нибудь СОРМ работает.
Что значит "поток"?
Какой тест у iperf3? TCP? А на UDP что видно?Если UDP не будет зажат, то есть вариант с WireGuard.
>> (А -> 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Мбит/с.Вы имеете ввиду построить туннель и проверять в нем?
> UDP показывает много потерь в обе стороны.
> Но ведь в одну сторону по TCP я получаю 900Мбит/с.Ну, вот тебе и ответ. Потеря пакета уменьшает размер окна TCP. В одну сторону пакеты теряются чаще, потому и перекос. Гоняй тест UDP и тычь провайдера палкой, потерь не должно быть.
>> UDP показывает много потерь в обе стороны.
>> Но ведь в одну сторону по TCP я получаю 900Мбит/с.
> Ну, вот тебе и ответ. Потеря пакета уменьшает размер окна TCP. В
> одну сторону пакеты теряются чаще, потому и перекос. Гоняй тест UDP
> и тычь провайдера палкой, потерь не должно быть.Вы правы, но я что-то затупил и не дописал.
ICMP потери не показывает.
Даже при -i 0.01 -s 1024 не увеличиваются задержки, пакеты не выпадают.
Вот этим ситуация и странная.
UDP потери показывает на bandwidth > 70Мбит/с. До ~70 проблем нет.
Между мной и провайдером ни здесь ни там потерь и задержек нет.
Между мной и провайдером и там и там iperf показывает полный канал.
Между core маршрутизаторами провайдеров также iperf показывает полный канал в 1Гбит/с.Попробуем еще UDP погонять и сравнить результаты без потерь для UDP и максимальные для TCP.
Мммм через РТК не ходит случаем?
> Мммм через РТК не ходит случаем?расшифруйте, пожалуйста.
> расшифруйте, пожалуйста.ростелеком
>> расшифруйте, пожалуйста.
> ростелекомНет)
> Нет)трейс покажи
> Вот этим ситуация и странная.
> UDP потери показывает на bandwidth > 70Мбит/с. До ~70 проблем нет.Формально зацепись за этот параметр, чтобы прессовать провайдера. А с xyя ли? Что это ещё за дискриминация в нарушение RFC?
>> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
>> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.
> Возможно, какой-нибудь СОРМ работает.
> Что значит "поток"?
> Какой тест у iperf3? TCP? А на UDP что видно?
> Если UDP не будет зажат, то есть вариант с WireGuard.Сорм получает данные по port-mirroring что никак не должно влиять.