| 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'е 😄
| | |
| |
| |
| |
| |
| |
| 6.17, Аноним (17), 11:35, 17/03/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
В смысле - гугль и гугль? Ну да, перешли. Им же важнее сэкономить копейку, а не чтоб у тебя было плавное воспроизведение и еще остался канал параллельно что-то другое делать.
А вот зачем другие идиоты изо всех сил пытаются следовать - это действительно вызывает небольшое недоумение. Небольшое, потому что на то и идиоты. Несть числа им.
| | |
| |
| 7.28, Аноним (28), 14:25, 17/03/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
Земляне из всех сил пытаются себя уговорить, что весь этот так называемый рост и есть прогресс и развитие, типа "Не стой, замёрзнешь". Наверное. Их же никто не похвалил за этот путь. Но и не поругал. Вселенной сходить по-большому и жидкому на потерянную Землю. 😁
PS "Жопа есть, а слова такого нет" )
| | |
|
|
|
|
|
| |
| 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.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 +/– |
 С точки зрения сетевого архитектора - безусловно. Разные задачи требуют разных решений, сравнивать их можно так же, как мультиварку и хлебопечку.
С точки зрения админа - да, но не совсем. Разный геморрой в настройке и поддержании сетей. Разные возможности по развёртыванию на клиентском оборудовании, в т.ч. и старом маршрутизирующем, которое оптимизировано для себя может ходить по овпн, но не в курсе про вайргард. Разные сценарии, но задача одна - сделать туннель из пункта А в пункт Б.
С точки зрения просто админа локалхоста с опеннета - уже нет, они одинаковые. Они создают туннель до некоторого уже готового сервера и вся разница сводится к чисто внешним признакам черного ящика: что быстрее и что проще настраивается.
| | |
|
|
|
