LINUX.ORG.RU
ФорумAdmin

В одну из сторон не насыщается канал при международном соединении, хотя в другую насыщается

 


0

1

Есть российская локация с каналом 80Mdown/20Mup и немецкая с каналом 50Mdown/12Mup. Между ними часто случаются VPN/ssh/rsync и прочее-прочее. Сколько смотрел traceroute, трафик между двумя локациями проходит через CITYTELECOM-AS.

Видные по последнему листингу и резюмированные ниже странности с передачей данных аналогично отражаются и в point to point соединениях по iperf/rsync, но проиллюстрирую на speedtest, чтобы не мутила взгляд асимметричность каналов на местах.

Звоним из немецкой локации на близкий к ней Speedtest-сервер:

$ speedtest

   Speedtest by Ookla

      Server: Contabo - Dusseldorf (id: 35154)
         ISP: Versatel Deutschland
Idle Latency:    12.12 ms   (jitter: 0.65ms, low: 11.76ms, high: 12.72ms)
    Download:    57.91 Mbps (data used: 43.2 MB)
                116.85 ms   (jitter: 35.73ms, low: 15.00ms, high: 241.24ms)
      Upload:    10.36 Mbps (data used: 5.4 MB)
                 44.16 ms   (jitter: 3.77ms, low: 10.86ms, high: 105.69ms)
 Packet Loss:     0.0%

Звоним из немецкой локации на близкий к российской локации Speedtest-сервер:

$ speedtest -s 4548

   Speedtest by Ookla

      Server: Vermont-IT - Korolev (id: 4548)
         ISP: Versatel Deutschland
Idle Latency:    49.20 ms   (jitter: 0.27ms, low: 48.69ms, high: 49.54ms)
    Download:    56.13 Mbps (data used: 71.2 MB)
                175.09 ms   (jitter: 52.87ms, low: 47.63ms, high: 273.87ms)
      Upload:    10.27 Mbps (data used: 9.3 MB)
                117.21 ms   (jitter: 31.97ms, low: 58.16ms, high: 189.96ms)
 Packet Loss: Not available.

Звоним из российской локации на близкий к ней Speedtest-сервер:

# speedtest

   Speedtest by Ookla

      Server: Vermont-IT - Korolev (id: 4548)
         ISP: Vermont-IT Limited Liability Company
Idle Latency:     1.07 ms   (jitter: 0.17ms, low: 0.91ms, high: 1.22ms)
    Download:    76.55 Mbps (data used: 55.1 MB)
                  5.46 ms   (jitter: 26.40ms, low: 1.26ms, high: 429.19ms)
      Upload:    21.05 Mbps (data used: 12.5 MB)
                 17.86 ms   (jitter: 35.02ms, low: 1.02ms, high: 361.73ms)
 Packet Loss: Not available.

Звоним из российской локации на близкий к немецкой локации Speedtest-сервер:

# speedtest -s 35154

   Speedtest by Ookla

      Server: Contabo - Dusseldorf (id: 35154)
         ISP: Vermont-IT Limited Liability Company
Idle Latency:    37.60 ms   (jitter: 0.34ms, low: 37.46ms, high: 37.96ms)
    Download:    11.87 Mbps (data used: 12.0 MB)
                 37.64 ms   (jitter: 3.82ms, low: 37.30ms, high: 318.72ms)
      Upload:     4.28 Mbps (data used: 6.9 MB)
                 47.03 ms   (jitter: 26.58ms, low: 37.22ms, high: 406.14ms)
 Packet Loss:     0.0%

Резюмирую: немецкий клиент при соединении с российским Speedtest-сервером насыщает свой канал, а вот российский клиент при соединении с немецким Speedtest-сервером (и тут можно пробовать любой немецкий сервер) не насыщает свой канал.

Кто виноват и можно ли с этим что-то сделать?

★★★★★

Последнее исправление: eugrus (всего исправлений: 3)

Что такое «насыщает» я не понял, но у вас:
1. асимитричные каналы.
2. маршруты могут быть разными.

anc ★★★★★
()

Железка, на которой крутится DPI, не тянет?

greenman ★★★★★
()
Ответ на: комментарий от anc

ТС про то, что скорость, демонстрируемая в speedtest, существенно меньше обещанного канала в Инет (в случае если с РФ работать с сервером в неметчине).

mky ★★★★★
()
Ответ на: комментарий от anc

Ну. И немецкая показывает 57.91/10.36 и 56.13/10.27 для трафика внутри Германии и для трафика в Россию. Это близко к 60/12, то есть насыщается в терминах ТС.

А Российская показывает 76.55/21.05 для трафика внутри России, что соответствует каналу и 11.87/4.28 для трафика в Дюссельдорф, что не нравится ТСу.

mky ★★★★★
()
Ответ на: комментарий от eugrus

Никак не могу понять: какая связь между тарифами у двух разных хостеров и скростью передачи данных между ними? :)

Хостеры могут что-то гарантировать в пределах своей сети или сввоей AS.

Да, теоретически хотелось бы видеть 20/12, но это планка сверху.

iperf3 более правильная мерилка. На гитхабе где-то был список публичных iperf-серверов, так что можно сравнить.

В iperf3 можно попробовать запустить одновременно несколько соединений. Может оказаться так, что одним соединением тебе не удается полностью использовать ёмкость канала.

vel ★★★★★
()
Ответ на: комментарий от eugrus

Возможно ты найдёшь место где трафик пережат. Определишь владельца. Но что ты будешь делать дальше? У тебя с ними нет никаких договоров.

С тобой, как с частным лицом/клиентом хостера они не будут ни о чём говорить.

Если у хостеров есть свои AS с несколькими каналами наружу, то теоретически, они могут анонсировать некоторые свои сети через другой канал, но для этого им нужен существенный повод.

вручную проложить маршрут

Ты, как клиент, можешь сделать это только организовав vpn в обход этих тормозных сетей.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от eugrus

Теоретически возможно. На практике для этого придется постоянно следить за тем как сейчас выглядят маршруты (и прямой и обратный), а также купить серверы в альтернативных промежуточных локациях и переключать маршруты через них используя их как опорные точки (да, впн). Судя о том что речь идет о канале в 50 мбит, этим никто заниматься не будет.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

А чего-то вроде proxychains, только чтобы направить трафик на произвольную автономную систему не бывает / не может быть? Или для такого нужно быть самому автономной системой?

Или наоборот: можно ли с моей стороны заблокировать прохождение соединения через тормозную AS?

eugrus ★★★★★
() автор топика
Последнее исправление: eugrus (всего исправлений: 2)

питоновый speedtest еще тот враль...

попробуйте iperf3 проверить


и net.ipv4.tcp_congestion_control = bbr
поставьте, если там что-то типа cubic

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

Это не питоновый speedtest - iperf показывает, что всё печаль, но это и по rsync видно.

eugrus ★★★★★
() автор топика
Ответ на: комментарий от Sylvia

Есть ли риск, что если сделать sysctl -w net.ipv4.tcp_congestion_control=bbr на удалённой машине, сеть у неё целиком отвалится?

eugrus ★★★★★
() автор топика
Ответ на: комментарий от eugrus

Я не сетевик, но наивно кажется, что повлиять ты можешь только на направление трафика в AS с которыми у тебя есть непосредственные физические стыки (либо какие-то особые договоренности), иначе не было бы пиринговых войн.

slowpony ★★★★★
()
Ответ на: комментарий от eugrus

практически нет, но новые алгоритмы congestion будут использовать только новые соединения.

Sylvia ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.