1.4, timur.davletshin (ok), 09:06, 17/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Мне больше всего нравятся нелогичности в трендах.
Ну, вроде как из-за переключения контекста ядра OpenVPN медленнее, чем реализации на уровне ядра. ОК, одни написали Wireguard, другие написали OpenVPN kernel accelerator. Вроде как счастье, мир и процветание.
Но в пользовательских протоколах обратный тренд и все массово (доля HTTP/S трафика выше, чем все VPN) ломанулись в обратную сторону и перешли на HTTP/2 over UDP (aka HTTP/3) и получили более громоздкие реализации в пространстве пользователя, подверженные джиттеру и "затупам" userspace'а. Я просто напомню, что сначала предпосылкой было внедрение более агрессивных протоколов congestion control'а вроде BBR, но эта идея провалилась и подавляющее большинство реализацию использует условно старые CUBIC и RENO. Да, быстрое внедрение новых алгоритмов управления потоком может быть важно для сервисов доставки контента, которые всё это и затевали (привет, Гугл). Но это модификации только на стороне сервера и внедрение ядерной реализации для них настолько же трудоёмко, как и внедрение userspace'ной, пользователю менять ничего не нужно, исходящий трафик на Ютубе минимален. В результате получили новый протокол, который на 20-30% тупее TCP и представляет собой реализацию старого в пользовательском пространстве. Я уже не говорю о большом количестве проблем в реализациях. Начиная от кол-ва проблем в nginx и до "приколюх" вроде падения скорости в 3-5 раз у пользовательской реализации Firefox.
Ну а в остальном да, прогресс. Прогресс на уровне очередного цикла оквадрачивания/скругления круглых/квадратных кнопочек в Android'е 😄
| |
|
2.5, Аноним (5), 09:57, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
На "HTTP3" перешёл кто-то, кроме мегакорпов? Это же их игрушка. В частности Гугла.
| |
|
3.7, timur.davletshin (ok), 10:07, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> На "HTTP3" перешёл кто-то, кроме мегакорпов? Это же их игрушка. В частности Гугла.
Ну, для начала, они составляют 9/10 трафика, а во-вторых и обычные сайты переходят тоже, что вызывает недоумение.
| |
|
4.10, keydon (ok), 10:44, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Мегакорпы тоже не перешли. Никто не знает как с этим жить. Если что и работает то чисто с учетом небольшого трафика с возможностью отключения/фэллбека на другой протокол в случае ддоса.
| |
|
5.13, timur.davletshin (ok), 10:55, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Мегакорпы тоже не перешли.
Крупнейшие видео-сервисы перешли. У меня статистика в пользу UDP на роутере уже больше года как превышает TCP. В ряде академических работ разбирается то, что, например, Google использует в Youtube какую-то свою реализацию Congestion Control'а, которая отличается от BBRv1 и от ещё недоработанного BBRv2 — https://www.comp.nus.edu.sg/~ayush/images/sigmetrics2020-gordon.pdf (там в основном про TCP, но есть и разбор про Google Quic и его особенности).
| |
|
6.17, Аноним (17), 11:35, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
В смысле - гугль и гугль? Ну да, перешли. Им же важнее сэкономить копейку, а не чтоб у тебя было плавное воспроизведение и еще остался канал параллельно что-то другое делать.
А вот зачем другие идиоты изо всех сил пытаются следовать - это действительно вызывает небольшое недоумение. Небольшое, потому что на то и идиоты. Несть числа им.
| |
|
7.18, timur.davletshin (ok), 11:38, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
А нетфликсы всякие не считаются? Про гугл я не понял, т.к. проблема там не в буферизации, это вообще отдельная история. Я про то, что пользовательские реализации создают бОльшую нагрузку на систему, чем ядерные. Именно за это OpenVPN и критикуют. Но в главном сетевом протоколе HTTPS тренд совершенно обратный.
| |
7.28, Аноним (28), 14:25, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Земляне из всех сил пытаются себя уговорить, что весь этот так называемый рост и есть прогресс и развитие, типа "Не стой, замёрзнешь". Наверное. Их же никто не похвалил за этот путь. Но и не поругал. Вселенной сходить по-большому и жидкому на потерянную Землю. 😁
PS "Жопа есть, а слова такого нет" )
| |
|
|
|
|
|
2.8, Аноним (8), 10:19, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
>BBR runs purely on the sender and does not require changes to the protocol, receiver, or network, | |
|
3.9, timur.davletshin (ok), 10:41, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> BBR runs purely on the sender and does not require changes to the protocol, receiver, or network
Перечитай мой пост ещё раз. Я об это прямо написал. Я так же написал, что реальные пользовательские реализации отказались от него в пользу уже классических Reno/CUBIC (RFC тоже). У оригинального BBR есть проблемы к "честностью" и неадекватная работа с ECN. Кроме того, BBR есть и в ядерной реализации для TCP. Его зачем-то многие стали использовать (стадный инстинкт айтишников?) после пары статей во всяких Medium с заголовками типа "Как ускорить TCP на 100%". Описанные проблемы есть у обеих реализаций. Кроме того, у CUBIC уже достаточно давно появился включенный по умолчанию режим гибридного старта, что де-факто сделало его гибридным алгоритмом, а не packet-loss-based.
P.S. Гибридные протоколы хороши, но на "длинных трубах", в локальных запросах они позорно сливают в дефолтном своём состоянии. BBR на локальном Wi-Fi сольёт CUBIC'у на 30-50%. Есть, например, CDG (две реализации, родная из FreeBSD и значительно расширенная тем же hybrid start реализация из Linux), который примерно на такой же процент сливает на локальном уровне, но его можно настроить, доведя уровень агрессивности до сопоставимого уровня. С BBR это не представляется возможным.
Вообще, все эти игрища протоколами плохи, т.к. они полируются годами и внедряться должны повсеместно. Иначе это чревато проблемами с "честностью", когда одни соединения будут глушиться из-за конкуренции с более агрессивными протоколами.
| |
|
2.29, Фняк (?), 14:48, 17/03/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
«Логичность» подразумевает наличие какого-то гранд-плана, какой-то общей идеи, которой решение или соответствует или нет. В жизни этого нет. Есть множество акторов, которое занимаются тем что им в данный момент важнее/интересно
| |
|
3.38, timur.davletshin (ok), 08:56, 18/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Логичность подразумевает единый алгоритм принятия решений в схожих ситуациях. За "гранд-планами" в другое место.
| |
|
2.49, Аноним (49), 09:50, 19/03/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не, ну надо же о каких-то успехах манажорам докладывать.
Как говорил наш Ильич в небезывестном анедоте- "имитировать движение!".
| |
|
|
2.2, Жироватт (ok), 09:00, 17/03/2022 [^] [^^] [^^^] [ответить]
| +4 +/– |
Чем грузины. Проще в развертывании, более зрелая технология сама по себе, есть поддержка даже на утюгах. В отличие от хипстерского вайргарда.
| |
|
|
|
5.50, Аноним (49), 09:51, 19/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
специально для Вас- я администрирую openvpn сервер около 18 лет.
| |
|
6.52, Аноним (14), 10:31, 20/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
И к чему этот "невероятный" срок? Он должен сказать о каком-то профиссионализме или показать статусность?
| |
|
|
|
3.20, Аноним (20), 12:32, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
>Проще в развертывании
Чего? Особенно, замороченность на X509 "проще".
| |
3.43, Аноним (43), 15:15, 18/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Упоролся или ты живешь в альтернативной реальности? Где это есть OpenVPN где нет Wireguard?
| |
|
2.6, Abyss777 (?), 09:58, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Они разные, для разных целей.
Когда нужно тоннели точка-точка создавать на разном оборудовании wireguard больше подойдет ИМХО.
OpenVPN больше подходит для подключения многих клиентов к одному серверу. Сертификат сервера залил и всё. Клиенты сами там в CA себе получают и подключаются... Ну или Логины/пароли в radius или ldap ходить проверять.
А с wireguard надо со всех еще открытый ключ собрать, в конфиг прописать, конфиг перечитать...
wireguard стоит с ipsec сравнивать, вот тут точно он проще чем ipsec
А, ну и OpenVPN умеет пушить маршруты
| |
|
3.22, Жироватт (ok), 12:51, 17/03/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
С точки зрения сетевого архитектора - безусловно. Разные задачи требуют разных решений, сравнивать их можно так же, как мультиварку и хлебопечку.
С точки зрения админа - да, но не совсем. Разный геморрой в настройке и поддержании сетей. Разные возможности по развёртыванию на клиентском оборудовании, в т.ч. и старом маршрутизирующем, которое оптимизировано для себя может ходить по овпн, но не в курсе про вайргард. Разные сценарии, но задача одна - сделать туннель из пункта А в пункт Б.
С точки зрения просто админа локалхоста с опеннета - уже нет, они одинаковые. Они создают туннель до некоторого уже готового сервера и вся разница сводится к чисто внешним признакам черного ящика: что быстрее и что проще настраивается.
| |
|
|
|
4.23, Аноним (23), 13:00, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
А зачем сервер прятать за NAT?
Уверен что через port-forwarding openvpn заведется, хотя я не проверял... (Не представляю зачем это может понадобится)
| |
|
5.24, Аноним (24), 13:13, 17/03/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если домашнюю машинку хочется сделать видимой извне - не получится, все провайдеры сейчас держат юзером за натом. Если, конечно, не покупать белый ип.
| |
|
6.27, Сталин Жив (?), 14:18, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Далеко не все. В моем городе из более двух десятков провайдеров только 1 держит клиентов за нат. Хотя нат для простого обывателя скорее плюс – меньше головной боли с безопасностью.
| |
|
7.32, Sadok (ok), 19:27, 17/03/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Открываем учебник для первого класса "Сеть для самых маленьких" и вдумчиво читаем главу "Почему NAT не файрвол"
| |
|
6.31, Аноним (8), 19:21, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
В моей деревне до сих пор бесплатно айпишники выдают. И, судя по заявлениям прова, выдавать будут ещё не одно десятилетие. Так что насчёт всех ты перегнул.
| |
|
7.34, keydon (ok), 21:44, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Что же это за провайдер? У всех российских проблемы с айпишниками в принципе. А корпы готовы платить за них солидную денежку.
| |
|
|
|
4.25, keydon (ok), 14:02, 17/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Когда клиент за NATом только.
А других вариантов и нет. Централизованные приложухи без белого (или серого в некоторых вариантах ната с ручным пробивом) ip сервера не работают в принципе.
| |
|
|
|
1.30, Аноним (30), 18:15, 17/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> отовые бинарные пакеты формируются для Debian, Ubuntu, CentOS, RHEL и Windows
Последние 3 лишние
| |
1.35, Аноним (35), 00:12, 18/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> готовые бинарные пакеты формируются
Где формируются? Чет там не видно или это про apt ?
| |
|