LINUX.ORG.RU
ФорумAdmin

OpenVPN в 5 раз медленнее обычного соединения

 ,


1

3

Есть один debian buster в офисе, на котором установлен openvpn, порт openvpn’а проброшен из офиса. Так же как и порт 5201 для iperf3. Подключаюсь я из последней убунты 19.04. Офис и домашний комп в одном городе, так что мы практически в одной локалке.

Конфиг openvpn:

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key
dh dh2048.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"

keepalive 10 120

cipher AES-256-CBC

user nobody
group nogroup

persist-key
persist-tun
status openvpn-status.log
verb 4
explicit-exit-notify 1
status /tmp/openvpn-status.log

iperf3 до проброшенного порта с iperf3

user@E420:~$ iperf3 -c *.*.*.*
Connecting to host *.*.*.*, port 5201
[  5] local 192.168.1.109 port 33874 connected to *.*.*.* port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.8 MBytes  98.7 Mbits/sec    0    128 KBytes       
[  5]   1.00-2.00   sec  11.3 MBytes  95.1 Mbits/sec    0    150 KBytes       
[  5]   2.00-3.00   sec  11.5 MBytes  96.6 Mbits/sec    0    171 KBytes       
[  5]   3.00-4.00   sec  11.4 MBytes  95.6 Mbits/sec    0    180 KBytes       
[  5]   4.00-5.00   sec  11.2 MBytes  93.5 Mbits/sec    0    188 KBytes       
[  5]   5.00-6.00   sec  11.5 MBytes  96.1 Mbits/sec    0    188 KBytes       
[  5]   6.00-7.00   sec  11.4 MBytes  95.6 Mbits/sec    0    188 KBytes       
[  5]   7.00-8.00   sec  11.9 MBytes  99.7 Mbits/sec    0    277 KBytes       
[  5]   8.00-9.00   sec  11.0 MBytes  92.5 Mbits/sec    0    277 KBytes       
[  5]   9.00-10.00  sec  11.6 MBytes  97.1 Mbits/sec    0    277 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   115 MBytes  96.1 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   113 MBytes  94.8 Mbits/sec                  receiver

Теперь до того же компа через openvpn:

user@E420:~$ iperf3 -c 192.168.0.17
Connecting to host 192.168.0.17, port 5201
[  5] local 10.8.0.6 port 58546 connected to 192.168.0.17 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.99 MBytes  25.1 Mbits/sec    1   1.33 KBytes       
[  5]   1.00-2.00   sec  2.74 MBytes  22.9 Mbits/sec  133   1.33 KBytes       
[  5]   2.00-3.00   sec  2.49 MBytes  20.9 Mbits/sec   69   1.33 KBytes       
[  5]   3.00-4.00   sec  2.74 MBytes  22.9 Mbits/sec  144   1.33 KBytes       
[  5]   4.00-5.00   sec  2.55 MBytes  21.4 Mbits/sec  160   1.33 KBytes       
[  5]   5.00-6.00   sec  2.49 MBytes  20.9 Mbits/sec  158   1.33 KBytes       
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.33 KBytes       
[  5]   7.00-8.00   sec  2.74 MBytes  23.0 Mbits/sec  158   1.33 KBytes       
[  5]   8.00-9.00   sec  2.55 MBytes  21.4 Mbits/sec  160   1.33 KBytes       
[  5]   9.00-10.00  sec  2.49 MBytes  20.9 Mbits/sec  158   1.33 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  23.8 MBytes  19.9 Mbits/sec  1142             sender
[  5]   0.00-10.00  sec  23.8 MBytes  19.9 Mbits/sec                  receiver

Даже решил протестить l2tp который был уже настроен в офисе, и даже он оказывается немного быстрее:

Connecting to host 192.168.0.17, port 5201
[  5] local 192.168.10.1 port 47734 connected to 192.168.0.17 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.27 MBytes  35.8 Mbits/sec    8   38.5 KBytes       
[  5]   1.00-2.00   sec  4.07 MBytes  34.2 Mbits/sec    8   31.9 KBytes       
[  5]   2.00-3.01   sec  4.28 MBytes  35.7 Mbits/sec   10   41.2 KBytes       
[  5]   3.01-4.00   sec  4.17 MBytes  35.2 Mbits/sec    6   38.5 KBytes       
[  5]   4.00-5.00   sec  4.19 MBytes  35.1 Mbits/sec    8   33.2 KBytes       
[  5]   5.00-6.00   sec  4.17 MBytes  35.0 Mbits/sec    5   31.9 KBytes       
[  5]   6.00-7.00   sec  4.13 MBytes  34.6 Mbits/sec    5   34.5 KBytes       
[  5]   7.00-8.00   sec  4.25 MBytes  35.7 Mbits/sec    7   34.5 KBytes       
[  5]   8.00-9.00   sec  4.25 MBytes  35.7 Mbits/sec    5   31.9 KBytes       
[  5]   9.00-10.00  sec  4.16 MBytes  34.9 Mbits/sec    7   30.5 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  41.9 MBytes  35.2 Mbits/sec   69             sender
[  5]   0.00-10.00  sec  41.9 MBytes  35.1 Mbits/sec                  receiver

Пробовал все трюки из https://serverfault.com/a/927729/535800 с увеличением буферов системы, с отрубанием шифрования, и кучу всего ещё - эффект просто нулевой. Будто я конфиги от другой системы правил. Даже хуже не становится. Есть какие-то идеи?

Провайдер может шейпить туннельный трафик, не рассматривали вариант?
Посмотрите на нагрузку cpu при тестах. Если она высокая, вероятно, процессор не справляется с потоком. Попробуйте понизить уровень шифрования.
Попробуйте прогнать iperf по udp, с параметром -u на клиенте и сервере, посмотрите на результат.

В целом со всеми накладками, 25.1 Mbits/sec через городскую сеть - неплохой результат для туннеля с шифрованием.

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

Да у вас и l2tp совсем-совсем не айс. Традиционно два варианта либо ваше оконечное оборудование виновато, либо меж провайдерское ограничение.

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

Провайдер может шейпить туннельный трафик, не рассматривали вариант?

Ну я пробовал через 443 порт работать, ускорение не наблюдалось. Разве это не помогло бы?

Если она высокая, вероятно, процессор не справляется с потоком

Пробовал как понижать шифрование до 128 бит, так и отрубать его вообще с обоих сторон (cipher none) с выключенным negotiation, и всё-равно ничего. Нагрузка процов очень низкая с обоих сторон даже с врубленным шифрованием.

Попробуйте прогнать iperf по udp, с параметром -u на клиенте и сервере, посмотрите на результат. Без впн (в впн тунеле на самом деле такие же результаты):

user@E420:~$ iperf3 -c *.*.*.* -u
Connecting to host *.*.*.*, port 5201
[  5] local 192.168.1.109 port 38846 connected to *.*.*.* port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   1.00-2.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   2.00-3.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   3.00-4.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   4.00-5.00   sec   127 KBytes  1.04 Mbits/sec  89  
[  5]   5.00-6.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   6.00-7.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   7.00-8.00   sec   128 KBytes  1.05 Mbits/sec  90  
[  5]   8.00-9.00   sec   127 KBytes  1.04 Mbits/sec  89  
[  5]   9.00-10.00  sec   128 KBytes  1.05 Mbits/sec  90  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/898 (0%)  sender
[  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.065 ms  0/898 (0%)  receiver
olologin
() автор топика

мне тоже интересно поему

Shulman
()
Ответ на: комментарий от olologin

Ну я пробовал через 443 порт работать

Дело не в смене порта, а в детекции такого трафика. Проверьте детекцию OVPN трафика, например, тут: http://witch.valdikss.org.ru/ , попробуйте добиться отсутствия детекции. Посмотрите на результат.

Пробовал как понижать шифрование до 128 бит, так и отрубать его вообще с обоих сторон (cipher none) с выключенным negotiation, и всё-равно ничего.

Похоже, вот оно. У меня с отключенным шифрованием прирост есть. Попробуйте другой вид туннеля, или замаскируйте от провайдера OVPN

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

В целом со всеми накладками, 25.1 Mbits/sec через городскую сеть - неплохой результат для туннеля с шифрованием.

Это сейчас опять была «8-битная шутка»? У меня больше улетает на другой континент.

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

Да, возможно дело в детекции. Коллега вместо ovpn начал пробрасывать через ssh порт для работы из дома, и скорость оставалась около 90 мегабит.

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

Ради интереса попробуйте сменить порт 1194 на какой-то высокий рандомный типа 33557, и разные протоколы как udp так и tcp. Но скорее udp заработать должен. Если нет, то прову голову можно отрывать от такого прова бежать.

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

Не вижу причин, по которым бы в сети 100мбит/сек скорость OVPN была бы больше 50мбит

Сотка с двух сторон. Расстояние между точками больше двух тысяч км. (через н-стран)
1. Реальный ip

 ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  83.7 MBytes  70.2 Mbits/sec                  sender
[  5]   0.00-10.00  sec  83.2 MBytes  69.8 Mbits/sec                  receiver

2. Через ovpn cipher AES-256-CBC
[  5]   0.00-10.00  sec  82.2 MBytes  68.9 Mbits/sec                  sender
[  5]   0.00-10.00  sec  81.8 MBytes  68.6 Mbits/sec                  receiver

И где тут 50мбит ?

Это в гигабитной сети

Вот тут да, согласен полностью, гигабит-два-три и т.д. есть хитросделанные схемы для достижения высоких скоростей и на ovpn. Но не вижу смысла в таком достижении. Для этого есть другие инструменты.

Однако обратите внимание у ТС как на ovpn несоразмерная просадка так и на l2tp

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

Ладно, я пока поборюсь с детекшеном

Если не секрет, это где(в какой стране) такое завезли?

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

сколько мс задержка между хостами?

Не понял вопроса, поясните.

Провайдеры, разумеется, не домашние?

Один домашний l2tp пчелы. Вторая сторона не домашняя, но и не ДЦ. Обычный местячковый.

ЗЫ Сейчас под рукой нет что бы пруф запостить, но ДС <-> Амстер DO 90Мегабит(+-немного) скорость и при ovpn выдает, это на самом дешманском дроплете.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)

L2TP over IPSec или без тестировали?

С MTU на туннельных интрефейсах, как обстоят дела? Я имею ввиду на устройстве которое ваши данные инкапсулирует в L2TP или OVPN туннель.

IP фрагментация/дефрагментация может очень значительно снижать итоговую производительность, ввиду необходимости ожидания получения всех отдельных IP фрагментов, их сборки и только после этого передачи далее по стеку.

Не знаю, как там дела обстоят с OVPN, но в случае L2TP в PPP options tunnel MTU/MRU можно задавать в конфиге.

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

Не знаю, как там дела обстоят с OVPN, но в случае L2TP в PPP options tunnel MTU/MRU можно задавать в конфиге.

У ovpn тоже mtu «можно задавать в конфиге» :)

Но ваша мысль насчет mtu и в частности фрагментации весьма и весьма может иметь место. Поддерживаю!

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

Я так и думал, что вряд ли в OVPN нет такой настройки, но поскольку я не знаком с теорией его работы, то решил точно не утверждать этого. :)

P/S/ Часто сетевые инежеры и системные администраторы надеятся на Path MTU Discovery, что он сделает всю грязную работу по определению MTU на пути между узлами, но увы, PMTUD Blackhole не такая уж и редкость. А для UDP PMTU вообще не определён, как факт, да и реализация последнего для TCP не во всех ОС обязательно имеется или активирована. А классический IP PMTU опирается на факт, что узел имеющий MTU mismatch направит ICMP с сообщением об этом, а доставка ICMP, как известно не гарантирована.

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

Я так и думал, что вряд ли в OVPN нет такой настройки, но поскольку я не знаком с теорией его работы, то решил точно не утверждать этого. :)

У ovpn даже есть «плюшка» в виде параметра «mtu-test», соединились, подождали получили в логе результат, его можно прописать в конфиг :) Это что бы самому ручками не подбирать :)

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

Не плохо, вот это реально удобно может быть, когда нам нужно получить минимальный transport overhead от снижения MTU и повышения из-за этого накладных расходов на передачу большего количества заголовков для того же объёма полезных данных.:)

ZANSWER
()

Короче протестил ща ssh тунель - 90 мегабит. Завернул openvpn в ssh тунель - 90 мегабит. Поднял второй openvpn сервер с tcp протоколом (и это единственное отличие в настройках) - 90 мегабит.

Похоже провайдер просто режет любой udp трафик.

Хз даже что делать, основное использование этого впн-а - RDP, как я понимаю оно TCP, TCP через TCP это что-то стрёмное.

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

Зачем вам гадать, осуществляет ваш провайдер шейпинг UDP датаграм или нет, просто запустите iperf3 в режиме тестирования UDP и протестируйте.

Только запускайте его не через туннели, а напрямую.

Пример команды на клиенте:

iperf -c 198.51.100.5 -u -b 1000m

Пример команды на сервере:

iperf -c 198.51.100.5 -u

Важно помнить, что IPERF ограничивает в случае UDP по умолчанию полосу до 1 Mbit/s в секунду, поэтому нужен ключ -b 1000m, для разблокировки этого ограничения.

ZANSWER
()
Последнее исправление: ZANSWER (всего исправлений: 3)
Ответ на: комментарий от olologin

TCP over TCP может в ряде ситуаций приводить к возникновению так называемого эффекта TCP Meltdown, простыми словами это означает, что соединение фактически будет парализовано и скорость упадёт до минимально возможных значений, какие только могут быть, до 0.

Если выяснится, что ваш провайдер действительно осуществляет shaping UDP datagram, в таком случае в Linux у вас есть возможность перейти на GRE или IPIP туннели, не говоря уже о том, что ESP (IPSec) протокол не предоставляет информацию о PDU находящемся внутри и кроме случая с NAT-T он инкапсулируется напрямую в IP протокол.

ZANSWER
()
Ответ на: комментарий от ZANSWER
user@E420:~$ iperf3 -c *.*.*.* -u -b 1000m
Connecting to host *.*.*.*, port 5201
[  5] local 192.168.1.109 port 41446 connected to *.*.*.* port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  11.4 MBytes  95.3 Mbits/sec  8161  
[  5]   1.00-2.00   sec  11.2 MBytes  94.2 Mbits/sec  8068  
[  5]   2.00-3.00   sec  11.3 MBytes  94.4 Mbits/sec  8086  
[  5]   3.00-4.00   sec  11.2 MBytes  94.2 Mbits/sec  8065  
[  5]   4.00-5.00   sec  11.3 MBytes  94.9 Mbits/sec  8121  
[  5]   5.00-6.00   sec  11.4 MBytes  95.5 Mbits/sec  8173  
[  5]   6.00-7.00   sec  11.3 MBytes  95.0 Mbits/sec  8132  
[  5]   7.00-8.00   sec  11.4 MBytes  95.1 Mbits/sec  8156  
[  5]   8.00-9.00   sec  11.4 MBytes  95.8 Mbits/sec  8190  
[  5]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec  8139  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   113 MBytes  94.9 Mbits/sec  0.000 ms  0/81291 (0%)  sender
[  5]   0.00-10.00  sec  27.8 MBytes  23.4 Mbits/sec  0.031 ms  59156/79155 (75%)  receiver

Хмм, значит всё-таки openvpn только шейпится?

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

Вы же сами провели тестирование OVPN через TCP и получили результат близкий к raw speed канала без OVPN. Можно конечно представить, что Ваш провайдер склонен к избирательному шейпингу только при определённых условиях, но какая ему от этого польза?

OVPN через UDP не чем принципиально не отличается от OVPN через TCP, я хочу подчеркнуть, что именно OVPN, а не работа транспортных протоколов, TCP и UDP, диаметрально противоопложны по архитектуре друг к другу.

Я рекомендую вам начать с того, чтобы указать в опциях вашего OVPN туннеля mtu в районе скажем 1400 байт, просто для теста, это safe value для MTU.

При этом при тестировании с помощью iperf вы должны помнить, что он использует значение буферов по умолчанию равное 1470 байт для UDP и 8000 байт для TCP.

То есть даже указав значение MTU для OVPN туннеля в 1400 байт UDP datagram будут подвергаться фрагментации, силами OVPN, чтобы избежать этого укажите ключ -l 1370 байт (IP 20 + UDP 8). В случае TCP он должен автоматически определять значение MSS на основе MTU OVPN интерфейса, но для надёжности я бы дополнительно указал ключ -M 1360 байт (IP 20 + TCP 20).

OVPN mtu = 1400
iperf tcp = -M 1360
iperf udp = -l 1370

P/S/ Как то так примерно я вижу ваш тестовый стенд, если у кого из коллег возникнет желание что-то добавить или поправить мне где-то я всегда открыт для критики. :)

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

Я вот всё-таки немного не понимаю. Допустим iperf3 мне говорит что приём udp в офисе порезан, причём именно приём. Так как reverse тест в udp режиме (офис->дом) говорит что скорость sender/receiver ~90 мегабит.

Так вот, почему тогда при тесте через openvpn udp тоннель оказывается что iperf3 tcp тест офис->дом ограничен 25 мегабитами? В udp ведь это направление не порезано.

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

Хз даже что делать, основное использование этого впн-а - RDP, как я понимаю оно TCP, TCP через TCP это что-то стрёмное.

Однозначно нет. Миллионы мух с вами не согласятся :) Инкапсуляция только добавит overhead, но не супер убийственный. Итого у вас два варианта или иметь прова или оставить tcp.

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

Из дома до офиса, напрямую без впн. в reverse режиме из офиса до дома обе скорости (sender/reciever) будут 90 мегабит.

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

local 192.168.1.109

Надеюсь я правильно понимаю. Это домашний комп, который идет через какой-то nat? У домашнего подключения нет белого статика?

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

Вам режут или исходящий udp (дом) или входящий udp (офис). А может и «по дороге». Если готовы бодаться с провами. То сначала, все тоже самое что и из дома проверяем через других провов. Если результат одинаков виноват пров офиса имеем ему мозг.
upd и не исключено что «ваш домашний роутер» тому виной. Попробуйте напрямую через прова подключить кабель.

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

Нет, проблема не в домашнем прове, уже проверил. До франции неплохая скорость. С офисного прова не могу проверить, вообще пакеты до этого iperf3 сервера не идут.

user@E420:~$ iperf3 -c ping.online.net -u -b 1000m
Connecting to host ping.online.net, port 5201
[  5] local 192.168.1.109 port 39539 connected to 62.210.18.40 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  11.5 MBytes  96.1 Mbits/sec  8298  
[  5]   1.00-2.00   sec  11.4 MBytes  95.6 Mbits/sec  8250  
[  5]   2.00-3.00   sec  11.2 MBytes  93.7 Mbits/sec  8085  
[  5]   3.00-4.00   sec  11.4 MBytes  95.5 Mbits/sec  8241  
[  5]   4.00-5.00   sec  11.4 MBytes  95.5 Mbits/sec  8254  
[  5]   5.00-6.00   sec  11.4 MBytes  95.7 Mbits/sec  8255  
[  5]   6.00-7.00   sec  11.4 MBytes  95.7 Mbits/sec  8256  
[  5]   7.00-8.00   sec  11.4 MBytes  95.4 Mbits/sec  8233  
[  5]   8.00-9.00   sec  11.4 MBytes  95.4 Mbits/sec  8238  
[  5]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec  8210  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   114 MBytes  95.4 Mbits/sec  0.000 ms  0/82320 (0%)  sender
[  5]   0.00-10.00  sec   113 MBytes  95.1 Mbits/sec  0.061 ms  146/82268 (0.18%)  receiver

iperf Done.
user@E420:~$ iperf3 -c ping.online.net -u -b 1000m -R
Connecting to host ping.online.net, port 5201
Reverse mode, remote host ping.online.net is sending
[  5] local 192.168.1.109 port 60407 connected to 62.210.18.40 port 5201
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  9.47 MBytes  79.4 Mbits/sec  0.182 ms  77138/83993 (92%)  
[  5]   1.00-2.00   sec  9.54 MBytes  80.0 Mbits/sec  0.190 ms  80667/87576 (92%)  
[  5]   2.00-3.00   sec  9.47 MBytes  79.4 Mbits/sec  0.112 ms  72436/79294 (91%)  
[  5]   3.00-4.00   sec  10.0 MBytes  83.9 Mbits/sec  0.114 ms  82649/89893 (92%)  
[  5]   4.00-5.00   sec  9.74 MBytes  81.7 Mbits/sec  0.102 ms  75880/82933 (91%)  
[  5]   5.00-6.00   sec  9.45 MBytes  79.3 Mbits/sec  0.113 ms  80583/87426 (92%)  
[  5]   6.00-7.00   sec  9.24 MBytes  77.5 Mbits/sec  0.111 ms  78383/85073 (92%)  
[  5]   7.00-8.00   sec  9.29 MBytes  78.0 Mbits/sec  0.095 ms  80935/87666 (92%)  
[  5]   8.00-9.00   sec  9.25 MBytes  77.6 Mbits/sec  0.112 ms  78820/85519 (92%)  
[  5]   9.00-10.00  sec  9.00 MBytes  75.5 Mbits/sec  0.165 ms  79340/85855 (92%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.18 GBytes  1.01 Gbits/sec  0.000 ms  0/855228 (0%)  sender
[  5]   0.00-10.00  sec  94.5 MBytes  79.2 Mbits/sec  0.165 ms  786831/855228 (92%)  receiver

iperf Done
olologin
() автор топика
Ответ на: комментарий от olologin

Понял, это некий сервис. Я-то предпочитаю свои «личные» в разных местах расположенные. А больше неоткуда проверить?

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

Ох, с TCP всё сложно, когда дело касается итоговой пропускной способности. Конкретно в случае ассиметричных каналов будет иметь место следующая проблема.

As defined in [9], the normalized bandwidth ratio, k, between the downstream and upstream paths is the ratio of the raw band- widths divided by the ratio of the packet sizes used in the two directions. For example, for a 10 Mbps downstream channel and a 100 Kbps upstream channel, the raw bandwidth ratio is 100. With 1000-byte data packets and 40-byte acks, the ratio of the packet sizes is 25. So, k is 100/25 = 4.

The ratio, k, holds the key to the behavior of TCP in an asymmetric network setting. If the receiver transmits more than one ACK every k data packets, the upstream bottleneck link will get saturated before the downstream one does. This will force the sender to clock out data more slowly than optimal, thus decreasing throughput.

If the upstream bottleneck remains congested for a sustained length of time, the corresponding buffer will fill up causing ACKs to be dropped. On average, only one ACK will get through for every k data packets transmitted by the sender, which can degrade performance in several ways. First, the sender could burst out k packets at a time, which increases the chance of data packet loss, especially when k is large. Second, since conventional TCP senders base congestion window growth on counting the number of ACKs and not on how much data is actually acknowledged, infrequent ACKs result in slower growth of the congestion window. Finally, the loss of (the now infrequent) ACKs elsewhere in the network could cause long idle periods while the sender waits for subsequent ACKs to arrive.

ZANSWER
()
Ответ на: комментарий от olologin

Завернул openvpn в ssh тунель - 90 мегабит.

Забавно. А у меня openvpn заметно медленнее. И я себе ничего нигде не режу.

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

У него NAT, стало быть IPSec NAT-T будет использовать ESP over UDP инкапсуляцию, с тем же результатом, что и сейчас.

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