Доступен первый официальный выпуск экспериментальной реализации сервера и клиента для протокола SSH3, оформленного в форме надстройки над протоколом HTTP/3, использующей QUIC (на базе UDP) и TLS 1.3 для установки защищённого канала связи и механизмы HTTP для аутентификации пользователей. Проект разрабатывает Франсуа Мишель (François Michel), аспирант Лувенского католического университета (Бельгия), при участии Оливье Бонавентуры (Olivier Bonaventure), профессора того же университета, известного разработкой подсистемы Multipath TCP и кода сегментной маршрутизации IPv6 для ядра Linux, а также соавтора 10 RFC и черновиков более 60 сетевых спецификаций. Код эталонной реализации клиента и сервера написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60300
Я правильно понимаю, что теперь нужен будет правильный сертификат, подписанный правильной конторой?
Нет, можно использовать RSA и EdDSA/ed25519 ключи от SSH или самоподписанные сертификаты X.509.
А кто запрещает использовать корпоративный центр сертификации или самоподписанные сертификаты?
Гуглу заплатишь чтоб твой карпаративнй центр добавили в список доверенных?
Иль ты Сбербанк и народ вынужден изучать процедуру добавления твагхо центра в каждый браузер?
Какой браузер? Тут используется HTTP/3 для установления SSH-сессии, вместо браузера будет SSH3 клиент, это же SSH. Никакого браузера в этой связке не будет, а значит и добавление центра сертификации в браузер, для использования SSH3, не актуально совсем.
И что то в воздухе мне подсказывает что хоть ftp:// из браузеров выпилили, ssh3:// - скорее всего впилят.
Вы понимаете!
> из браузеров выпилили,
> ssh3:// - скорее всего впилятА каком смысле впилят?
При запросе в браузере "ресурса" ssh3:// браузер будет внутри себя открывать "чёрный терминал"? 😃
Ну а чего такого то?
Полно же плагов чтоб обычный ssh из браузера юзать...
Идеального нет, но с той или иной степенью костыльности юзать можно прямо сейчас.
зачем можно серверный локалхост пробрасывать, многие утилиты web-морду на локальном хосте без аутификации крутятся, приходится -L опцию ssh юзать, давно хочу в браузерах подобную фишку.
> зачем можно серверный локалхост пробрасывать,
> многие утилиты web-морду на локальном хосте
> без аутификации крутятся,
> приходится -L опцию ssh юзать, давно хочу в
> браузерах подобную фишку.Не очень сильно понял.
Приведи примерчики простые.
Новость изучай, тут SSH3 как HTTPS сервер.
>народ вынужденНу так свобода кого надо свобода. Или ты думал что сертификаты это про удобство и безопасность, а не про контроль?
Ой да ладно. Нихрена не изучал. После того, как мне там какой-то пeдик в техподдержке на мои ссылки на законы стал тупо монотонно с издевкой повторять то что сказал до этого, пошел в офис, с болшьшим скандалом потребовал удалить все данные. Еще периодически скандалил на работе, когда начинали квакать, что неудобно мне переводить в банк незарплатного проекта, и уже XX лет вопросы зеленого филиала кащенки меня не касаются. Еще потрясяюще наблюдать недоумевающие рожи во всяких такси и шиномонтажах с возгласами 'как это у вас нет зеленый дурдом онлайн'.
Наёмный работник имеет право требовать от работодателя соблюдения прав работника.
Работодатель имеет право не заключить с таким работником контракт после завершения срока действия контракта предыдущего.
Ну так пусть тогда работодатель находит работника, который и сбер юзает, только тупой он будет, за примерами долго ходить не надо - все нормальные из госконтор разбежались, там как раз такие дебилы и сидят.
> А кто запрещает использовать корпоративный центр
> сертификации или самоподписанные сертификаты?А зачем тут вообще заговорили про сертификаты?
Без них этот SSH теперь работать не будет уж? 😲
Так вообще и старый тоже не работал, только они сначала были dsa потом rsa сейчас ed
> Так вообще и старый тоже не работал,
> только они сначала были dsa
> потом rsa сейчас edА старый не работал как, если я к своим хостам через SSH подключаюсь без всяких сертификатов?
https://en.m.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate...
Правильно, иначе любой впалит, что твой "веб-серер" ненастоящий.
Да, верно. Все мы знаем как отображаются самопописанные сертификаты. Конец вебу настал
Даже такое неправильное отображение самоподписанного серта лучше его отсутвия совсем.
> Даже такое неправильное отображение самоподписанного серта лучше его отсутвия совсем.Самоподписной может дядя хацкер подсунуть, один xpeн вы забиваете на проверку
А кто тебе мешал раньше использовать самоподписанные?
старО
https://github.com/moul/quicssh (POC 4 years ago)
Да, но это не то. Это прокси QUIC->SSH, сам он не умеет ssh вообще, передает все sshd. Это прямо там на картинке показано.А в топике именно SSH овер QUIC. Правда совсем сырой прототип, который они сами не рекомендуют использовать пока.
Скорее стоило упомянуть вот это:
Workgroup:Internet Engineering Task Force
Internet-Draft:draft-bider-ssh-quic-01
Published:7 July 2020
Intended Status:Informational
Expires:8 January 2021
Author: d. bider Bitvise LimitedНо автор так и не реализовал ничего кроме этого драфта.
В общем, ломают совместимость непонятно ради чего
Ради лидерства HTTP/3. Уже вытеснили Java Applet, Silverlight, Flash своим HTML/5,
а теперь дело и до сокетов обычных и протоколов дошло.Вообще надо этот консорцим немного поразогнать!!!
Расскажите пожалуйста как демоны SSH3 и, например, nginx решают между собой вопрос о том, кому принадлежит порт 443.
Принадлежит тому, кто раньше запустился
В идеале через роутинг в nginx:myhost.lan/porn
myhost.lan/ssh
HAPROXY + SNI?
В своём nginx несколькими строчками делаешь реверс прокси и запросы на "https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae" перенаправляются на демон ssh, который висит на другом порту.
Так это и сейчас можно сделать. Зачем городить QUIC?
А как, можешь поделиться?
https://www.nginx.com/blog/running-non-ssl-protocols-over-ss.../
Я пользуюсь, кстати.
Вопрос был в том, как уместить http сервис на одном порту вместе с nginx, а не зачем это нужно.
С другой стороны, не всем нужен nginx на сервере. Короче, если кто-то что-то пилит, значит, как минимум, ему это нужно. Если тебе не надо - проходи мимо.
И если^W когда вдруг наступят проблемы с работой nginx, то я потеряю не только веб-сервис, но еще и шелл на сервере? Отличный план!
Ну, чтобы уронить nginx это надо сильно постараться. Во-вторых, нормальный хостинг обычно предоставляет возможность зайти на сервак через свой терминал в панели управления даже в случаях если sshd упал.
Когда у меня вдруг упал/мисконфигнулся nginx, меньше всего хочется заниматься залезанием в систему через serial console или ikvm, пока сервис лежит.
Да всё решаемо. Можно запилить сервис, который открывает доступ к SSH напрямую, когда через nginx нет доступа.
Если рассматривать все варианты, то у тебя и ssh демон может упасть. Что ты будешь делать?
А на счёт nginx - используй две штуки. Один - для реверс прокси, второй - для вебсервисов. Тогда твои кривые веб-сервисы не будут ронять реверс проксю.
> у тебя и ssh демон может упасть. Что ты будешь делать?подключусь по ssh2!
> Если рассматривать все варианты, то у тебя и ssh демон может упасть. Что ты будешь делать?Разумеется, может. Но только вот обычно не вместе с веб-сервером, отдающим сайт, когда этот самый ssh больше всего нужен для того, чтобы зайти и починить проблему.
> А на счёт nginx - используй две штуки. Один - для реверс прокси, второй - для вебсервисов. Тогда твои кривые веб-сервисы не будут ронять реверс проксю.
И зачем городить такую конструкцию, когда можно вместо второго nginx-а + ssh3 просто поднять openssh (которые и так из коробки везде есть) и горя не знать?
вдруг даже дети не появляются, им предшествует бурное времяпровождение. только в случае с nginx есть бекап и саппорт. а с детьми - только аборт...
> бурное времяпровождениеТы, видимо, никогда с продакшеном дел не имел, и уж, тем более, не разбирался с каскадными отказами.
> только в случае с nginx есть бекап
Ага, упал ssh3 - откатываемся из бэкапа. С переустановкой системы, видимо.
> саппорт
Саппорт чего? Облака, dedi-хостера или, вообще, датацентра, в котором ты клетку арендовал, что ли? Ты сам саппортишь свои системы, и за тебя проблемы никто решать не будет.
ALPN, вестимо.
Например вот так https://habr.com/ru/articles/412779/
Тебе всё наврали, аноним. TLS termination для http3 пока не стандартизирован.Поэтому если у кого и работает, то благодаря грязным трюкам.
Это просто: nginx примет соединение и дальше через proxy protocol отдаст куда надо.
У меня так на 443 порту висит сайт, жаббер сервер, стун и опенссш уже сейчас.
Они не все proxy protocol могут, поэтому кто не может не видит реального IP клиента.
443 нужен только если ты хочешь маскироваться под валидный HTTP никто не мешает использовать тот же 22 напрямую без нжинксов.
Никто кроме поехавших безопасников в компании.
Кто первый встал, того и тапки
Кто обязывает демона SSH3 на 443 порту держать, есть много других портов, с виду косящих под web-сервер.
Для шифрования канала связи в SSH3 задействован протокол TLS 1.3, а для аутентификации могут использовать классические методы на базе паролей и открытых ключей (RSA и EdDSA/ed25519). Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеров
нинужно такое нам, а пароли можно запретить и заменить на аутенфикацию по ключу, конечно остаются вопросы постквантовой криптографии, но они более глобальны
Теперь ssh гоняем по UDP, а давайте вообще отменим TCP и всё будем гонять по UDP, зачем нам приоритеты трафика, какие-то там sip-звонилки, онлайн игрушки, правильно я понимаю?
QUIC это тот же TCP, просто вся логика на уровне выше, что позволяет сделать кучу кейсов, которых не было при проектировании TCP, из коробки.
Вася это Петя, просто имя другое.
Для этого надо на стороне клиента установить софт... что в общем случае не очень сильно проще установки tcp_supper_algo.ko. QUIC пока что ничего такого не умеет, что было обещано изначально в категории "преимущества перед TCP" (сколько реализаций умеют multipath?). По факту юзаем, но на производительности серверов тех же он сказался негативно. По факту вынесли алгоритм, требующий фиксированного времени отклика (практически реального времени), в пространство пользователя. Я напомню, что основная критика в адрес OpenVPN, который делает то же самое управление потоком и шифрование поверх UDP, заключалась в том, что он реализован в пространстве пользователя и поэтому медленный. Я запутался. Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?
>Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?Потому что openvpn не знает, что он передаёт, и потому не может дропать фреймы, а браузер знает, что он передаёт видео.
> Для этого надо на стороне клиента установить софт... что в общем случае не очень сильно проще установки tcp_supper_algo.ko.Чтобы сходить в интернет через tls тебе нужен openssl, ca-certificates и еще куча срани. Так что ничего особо нового тут не появилось.
>QUIC пока что ничего такого не умеет, что было обещано изначально в категории "преимущества перед TCP" (сколько реализаций умеют multipath?).
Все rfc-compliant.
> Я запутался. Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?
Не вижу проблемы затолкать quic в ядро. Это будет как sctp, тока на этот раз его кто-то поддержит.
Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы.
> Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы.Роутеры и коммутаторы тоже ходят в интернет, там тоже есть целый ворох библиотек и сертификаты.
Я не понимаю что ты пытаешься доказать. Что положить сишную либу размером в пару килобайт это проблема? Нет, это не проблема. Нигде, даже в embedded.
Разупорись, какие пару килобайт? Вы давно размер бинарников этих ваших lib*ssl.so видели? Сертификаты обновлять нужно. Плюс, маленький секрет, есть масса крупных сетей, в которых нет выхода в Интернеты по соображениям безопасности.
> Разупорись, какие пару килобайт? Вы давно размер бинарников этих ваших lib*ssl.so видели?
> Сертификаты обновлять нужно. Плюс, маленький секрет, есть масса крупных сетей, в
> которых нет выхода в Интернеты по соображениям безопасности.Ну не суй эту библиотеку туда, где не нужен выход в интернет :D
> Ну не суй эту библиотеку туда, где не нужен выход в интернет
> :DБудто я все прошивки сам делаю и OpenWrt уже готов для работы с трафиком небольшого провайдера.
>> Ну не суй эту библиотеку туда, где не нужен выход в интернет
>> :D
> Будто я все прошивки сам делаю и OpenWrt уже готов для работы
> с трафиком небольшого провайдера.Тогда чего ты переживаешь? Мейнтейнеры все положат.
> ... мейнтейнеры все положат.Если бы они туда ложЫли, то я бы не переживал.
Я пытаюсь сказать что TLS, рабочая инфраструктура сертификатов и даже правильно выставленное время не очень то и нужны много где, учитывая что есть более простые и более легковесные решения.И это, вы попробуйте в 8мб флеша собрать OpenWRT с этим всем, потому что там задолбались и выкинули все такие устройства :)
> Я пытаюсь сказать что TLS, рабочая инфраструктура сертификатов и даже правильно выставленное
> время не очень то и нужны много где, учитывая что есть
> более простые и более легковесные решения.
> И это, вы попробуйте в 8мб флеша собрать OpenWRT с этим всем,
> потому что там задолбались и выкинули все такие устройства :)Ну вот OpenWRT:
# du -sh /usr/lib/libssl.so.1.1
524.0K /usr/lib/libssl.so.1.1
Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcongestion control и как его применять?
> Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcongestion control и как его применять?Его нет на уровне UDP, это вынесено на уровень самого QUIC. А дальше открываешь rfc и вперед.
Дальше следующий вопрос возникает. Как мне ограничения сделать и разные congestion control на разный трафик? Именно как мне угодно на сервере, клиенте, промежуточном оборудовании? Можно пальчиком показать что трафик обновлений пускаем только на свободную полосу в данный момент, воип максимум быстро пропускаем, а оставшийся хттп не критичен к задержкам и его просто надо доставлять.
Я не настоящий сварщик, но можешь попробовать примерно так:Во-первых, пускаешь процессы в нужной net_prio cgroup.
Это должно правильно приоритизировать пакеты "локально".Во-вторых, пускаешь процессы в правильной net_cls cgroup, и через nftables выставляешь нужным процессам правильный DSCP код, и на свитчах-роутерах говоришь, каким flow с каким dscp выдавать больший приоритет.
Поскольку quic шифрован, нельзя выдать разный приоритет разным quic flow, поэтому нужно будет открывать разный flow на разные приоритеты, но по идее, это не проблема.
В смысле, разным connect, а не разным flow, конечно.
Кто как хочет, так и ... скачет. У всех свой велосипед придуман. За основу обычно берут стандартные Reno и Cubic. Только у bittorrent обычно LEDBAT (поправьте, если ошибся набором букв), а у VoIP вообще оригинальный велосипед.
> а давайте вообще отменим TCP и всё будем гонять по UDPА давайте. Все к этому и идет.
> зачем нам приоритеты трафика, какие-то там sip-звонилки, онлайн игрушки, правильно я понимаю
Неправильно. Никто не мешает настроить приоритеты для различных UDP-потоков.
> Неправильно. Никто не мешает настроить приоритеты для различных UDP-потоков.И как будешь различать "UDP-потоки" ? По IP ?
По source порту.
> sip-звонилкиГолосовой трафик и так по UDP ходит. А по стандарту можно и SIP over UDP настраивать.
Ты "почти" всё правильно понимаешь.Контроль потока на уровне ядра ОС был вынужденной мерой, когда хотелось просто открыть сокет и писать данные с помощью С write().
Это неплохо работало как переходная мера, когда большая часть подключений была десктоп-десктоп или десктоп-сервер, по надёжным каналам с маленькой задержкой.
Сейчас мир другой, и "прозрачная" (но дырявая) TCP абстракция "надёжного сокета" перестала отвечать реальности.
Спрошу тебя как эксперта по TCP. Почему TCP (или его преемник) не реализован просто как надстройка над UDP? Ну то есть вот есть IP, UDP к нему добавляет порты. TCP к IP добавляет порты + машину состояний + поля для синхронизации машин состояний приёмника и передатчика. Таким образом получается, что функциональность TCP есть надмножество функциональности UDP. Перепроектирование TCP поверх UDP (назовём его TCP/UDP) позволит выбирать, где обрабатывать TCP/UDP-соединения, в юзерспейсе или в ядре. Структура пакета почти та же, только без портов, за которые уже UDP-слой отвечает. Какой именно протокол слушается на порту - определяется открытым сокетом. Открывается TCP/UDP сокет - он ведёт себя как TCP, открывается UDP-сокет - машину состояний реализует сам процесс. Поскольку это UDP, то никаких особых привилегий, как для отправки сырых IP пакетов, процессу не нужно.
QUIC по большому счёту и является перепроектированием TCP поверх UDP. Если его "наивно" использовать, то там все те же параметры, что и для контроля потока TCP и используются, и даже те же самые алгоритмы контроля congestion: cubic, bbr.
И за порты там UDP и отвечает. В этом смысле система "практически" обратно совместима, с точки зрения "открыть сокет и писать". Собственно, библиотека QUIC не зря называется ngTCP2.Естественно, при этом радость от QUIC не очень велика, хотя уже приятно, что можно выставлять некоторые флаги самому.
Что больше радует -- это что можно установить изначальное соединение "по tcp2", вести "сигнальный канал" с сохранением надёжности (но медленно), но параллельно открыть DATAGRAM-канал, и по нему уже слать данные с собственной коррекцией ошибок (или без неё). А для внешнего наблюдателя это всё равно будет всего-навсего "зашифрованный UDP поток".Почему так было не сделано "давно"? Не знаю, я тогда не жил, но тогда казалось, что "правильная абстракция" -- это "номер протокола IP". В /etc/protocols куча всяких древних стандартов перечисленно. В каком-то смысле это казалось логичным -- ведь если какая-нибудь "фича" реализовывалась на уровне "системных протоколов", как, например, ipsec, то она "автоматом" распространялась на все протоколы уровнями выше, независимо от того, был там контроль доставки, или не было, были порты, или не было.
Также спрошу, почему-бы не сделать TLS без портов вообще, раз только 443 используется. Вместо порта выбирать сервис по ключу через Diffie-Hellman. Ну в server hello сервер может анонсировать, какие у него есть сервисы. Клиент выполняет диффи-хэллмана, выведенный ключ хэширует той же функцией, что и в сертификате, после чего от хэша берёт остаток от деления на (количество сервисов + 1). Остаток даёт номер сервиса. Если номер сервиса не тот, что нужен - повторить. Сервер делает то же самое с выведенным ключом. Только без брутфорса.
Тебе никто не мешает так сделать. Вернее, сейчас вообще так и делается, только без всякого Диффи-Хеллмана.Есть websocket. Подключаешься по https к https://webservice.com/service-name/, service-name пробрасывает websocket, и по этому websocket пиши что хочешь, он шифрован TLS-ом.
Вы себе и близко не представляете что такое современный TCP.Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.
5 строчек в приложении, 8кб скомпиленый бинарник и оно уже работает. Извращенцы даже из баш скриптов научились этим напрямую пользоватся.Что бы вы там в юзерспейсе не нагородили оно всегда будет жрать больше ресурсов и работать лучше не станет.
Задержки при старте - ну это такое, сильно на любителя. У TCP для этого тоже есть много разного.
Единственно что реально получилось улучшить это DTLS за счёт прибивания на гвозди размеров пакетов и выраснивания по размеру блоков алгоримов шифрования.
>Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.Невозможно "оптимально" реализовать работу TCP на канале с потерями 80%. А мобильные каналы и замусоренный wifi так и выглядят. Просто невозможно и всё. Не существует "надёжного" канала, который будет работать нормально на таких потерях, потому что не существует единого способа определить, надо ли пакет ретрансмитить или дропать, без знания контекста приложения. Если ваш поток -- видео, например, с камеры наблюдения, вы можете пренебречь потерями, заполняя видео старыми кадрами, и ничего не потеряете. Если вам нужно передавать ssh, вы очень не хотите терять никаких команд, даже если пинг вырастет до 15 секунд. Операционная система этого не знает, и знать никогда не будет. Контроль потерь должен осуществляться на самом высоком уровне стека, по сути, на прокладке между креслом и монитором. Готов юзер терпеть потери, или нет.
1. каналы у которых 80% - не рабочие, в принципе.
2. в дикой природе это скорее исключение
3. есть всякие RTSP/RTMP для видео и звука, и даже HLS делает примерно тоже самое по TCP.
4. Приложений с описанной вами логикой работы по UDP я что то не видел :)
1. Вы считаете, что нерабочие, и ничего не делаете, а другие люди пишут quic.
2. Миллиарды людей сидят через каналы с десятками процентов потерь, но хотят смотреть тикток.
3. Есть, но хочется открывать единственный сокет, и всё передавать через единственное соединение, не разводя зоопарк протоколов. A HLS такая, ну, кривоватая штука.
4. Откуда вы знаете? Если у вас канал нормальный, скорее всего, вам и не требуется quic, и софт его никогда не включает.
1. quic написан гуглом ровно для того чтобы пихать рекламу потребителям, и не важно посмотрят они её или нет, главное что деньги гугл за показ спишет.2. Не сидят, не нужно сочинять. С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет.
3. Вам хочется - вы и прогайте. )
4. Покажите примеры за пределами гугла где это используется.
>С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет.Видите, как мало вы знаете о мире. К сожалению, сидят-сидят.
DNS комфортно и не работает (тем более что ещё и фильтруется) поэтому китайские приложения обновляются раз в неделю, заодно таская с собой кэш dns.
Quic не в последнюю очередь как раз и сделан Google чтобы (а) обходить блокировки КНР, (б) сервить контент с серверов в Гонконге и США через полтора полудохлых канала, намертво перегруженных с потерями.
> сервить контент с серверов в Гонконге и США через полтора полудохлых канала, намертво перегруженных с потерями.Угомонись уже. Никак этот твой QUIC не поможет в борьбе с потерями, т.к. в серверных реализациях New Reno и Cubic почти что у всех. Более того, в QUIC отдаётся Гуглом далеко не весь контент даже на страничке YouTube, для которого якобы и делался. Попробуй уже включить мозг и поразмыслить, почему HTML Google отдавать предпочитает по HTTP/2... Более того, всякие там ТВ, как правило (Самсунги там всякие, ЛыЖи и прочая) юзают исключительно HTTP/2 и, OMG, HTTP 1.1.
Я вижу у вас какой то свой мирок с плохим инетом и последней надеждой на чудо-гуглаг.Примеры софта будут?
> Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.Ахаха нет. DPDK не просто так появился.
DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать углы чтобы получить нужную производительность.
> DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать
> углы чтобы получить нужную производительность.Ага. Потому что тот стек, что есть в линуксе, он даже близко не оптимальный.
Есть ещё сетевухи с аппаратным(не совсем) TCP и tls, что неплохо разгружает ОС в определённых задачах.
Всегда будет нужно только открыть сокет и писать аналогом write независимо от того, какой мир. Потому что это просто и удобно и большего в приложении не нужно. Кроме того сокетный интерфейс предоставляет кучу ядерных оптимизаций. Когда QUIC взлеит, то и его завернут в обыкновенный сокетный интерфейс. QUIC в конце концов точно такой же надёжный TCP сокет. Реализация находится в юзер спейсе через UDP вовсе не потмоу, что появилось какое-то волшебное управление потоком, а только лишь из-за экспериментального состояния самого протокола и желания побыстрей начать его использовать. Финальная ядерная версия для всех скорее всего будет уже не на UDP, UDP здесь от ~нищеты.
>QUIC в конце концов точно такой же надёжный TCP сокет.Далеко не только. Там есть MASQUE extension, DATAGRAM extension.
Ещё хуже. Теперь всё гоняем по http. Через один порт. Смысл в остальных портах продолжает падать.Технологии куда-то не туда свернули...
А куда ты денешься? Хоть туда, хоть не туда.
UDP применяется из-за шифрования (а не размера пакета и подтверждения как можно подумать). Вы и так можете подтвердить приём пакета отправив обратно другой пакет. Вероятнее всего новое оборудование будет отличать разные типы новых протоколов, так-что у таких пользователей с приоритетом трафика ничего не будет. А на старом, оставляете HTTP/TCP более приоритетным и все будет норм с приоритетом http я лично думаю что долгое время.
А TCP шифровать низя?)
А зачем? Вы по моему не понимаете разницу между TCP и UDP раз задаёте такой простой вопрос.Читаем обычную, даже не специализированную, википедию: https://ru.wikipedia.org/wiki/TCP
Механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым (в отличие от UDP) целостность передаваемых данных и уведомление отправителя о результатах передачи. Когда осуществляется передача от компьютера к компьютеру через Интернет, TCP работает на верхнем уровне между двумя конечными системами, например, браузером и веб-сервером. TCP осуществляет надёжную передачу потока байтов от одного процесса к другому.Ну и если очень надо, там дописано что для прозрачного шифрования данных предлагается использовать расширение tcpcrypt.
Забыл дописать про UDP: https://ru.wikipedia.org/wiki/UDPUDP использует простую модель передачи, без явных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных.
т.е. UDP не обеспечивает надёжность и целостность передачи данных. Вы один запрос делаете в одну сторону и асинхронно обратно другой запрос UDP получите в другую. В отличии от TCP, который сделает внутри тоже самое, только одним запросом обеспечит надежность. И вот UDP в этом плане выигрывает в скорости, но проигрывает в надёжности. Так вот надёжность добавляет шифрование, т.к. прячет данные от мониторинга и MITM, если вы не владелец (американского) реестра сертификатов.
Ну или проще - вам предлагают кастрюлю с американской лапшой вместо крутых яиц из которых могут вырваться птицы гордо воспарив над интернетом, порождая свои идеи. Вы бы хоть пообсуждали необходимость создания локального реестра сертификаций, если настолько неспособны программировать и создавать железо.
Так это вы написали: "UDP применяется из-за шифрования" вот и поясните что не так с TCP в этом плане.
Всё у вас смешалось, кони, люди...Давайте по пунктам:
1) В сетях Ethernet по умолчанию не работает Flow Control
Ну то есть как, он работает... Проблема в том, что он требует:
- Active Queue Management на стороне всех устройств одновременно, не только коммутаторов, но и сетевых карточек.
- Реализацию ETS (IEEE 802.1Qaz) на всей цепочке
- Реализацию PFC (IEEE 802.1Qbb) на всей цепочке
- Реализацию QCN (IEEE 802.1Qau) на всей цепочке
- Алгоритмы Random Early Detection на очередях
И это всё появилось спустя долгие годы проб, ошибок и коллапсов сетей. TCP при этом развивался отдельно и изобретал свой Flow Control на более высоком уровне.
Современный Flow Control и TCP никак не связаны.2) TCP часто используется не по назначению
TCP - это протокол для потоковой передачи данных сквозь широкополосную сеть с большими задержками. Не всякому приложению нужны потоки, не все готовы мириться с непредсказуемыми задержками. Но его используют повсеместно, потому что в нем есть сравнительно простое и рабочее решению по управлению потоком передачи данных (см п.1, там всё сложно, а старые Pause-фреймы вообще не работали никогда вне LAN).
Вот несколько примеров, когда TCP вреден:
- RTC, обмен данными в реальном времени и постоянные дропы и ретрансмиты TCP - вещи не совместимые
- RPC, удаленный вызов процедур порождает огромное количество соединений в которых служебных данных больше чем полезных. Если нет потока, то TCP мешает и лишний раз грузит ядро ОС глупым разбором заголовков.
Если у вас там потоковая проливка через ESB между базами данных, то да - TCP прекрасное решение.3) TCP постоянно теряет пакеты, это норма
Проблема в том, что люди почему-то не понимают, что TCP не просто может восстановить потерянные данные в потоке, а то что на самом деле он растит пропускную способность пока не начнутся потери и потом её снижает на основании получения запроса на Retransmit. По умолчанию он так управляет потоком. TCP сейчас использует CUBIC для контролирования пропускной способности и очередную вариацию slow start чтобы начать соединение.1+2+3: В реальности сейчас у нас есть TCP, который используется как попало, где попало и в общем случае экспоненциально растит скорость потока, пока не начнутся потери, и потом снижает скорость. Вот только если у тебя радио-сеть (с большими потерями), то TCP в ней работает особенно плохо. Он не способен подгадать Transmission Rate. Он считает, что раз потери - значит перегрузка. А бывает так, что потери - проблема с уровнем сигнала.
Есть например такой протокол RTP, который всё это учитывает и который реализован поверх UDP. За управление потоком RTP отвечает протокол RTCP, который в свежих версиях стандарта разрешили даже муксить в один порт. Причем телефония исторически работает через UDP.
То же самое с RoCEv2 (RDMA поверх UDP), которая учитывает все возможные варианты Flow Control из п.1 и дополнительно умеет реализовать собственные, если Flow Control не настроен в Lossless.C RDMA, была попытка (iWarp) сделать это привычным способом поверх TCP... да сплыла. В Ethernet-сетях победил RoCEv2, работающий поверх UDP. Как бы старательно не пытались настроить iWarp в современных реалиях всё что нужно сделать для снижения задержек и стабилизации его работы - бороться с TCP/IP стеком ОС и оптимизациями всех коммутаторов и роутеров на цепочке соединения. Хуже него только NVMe-over-TCP но это каким нужно быть бараном, чтобы в реальности пробрасывать так диски... Нормальную сетевку, которая всё это умеет можно взять за $100.
Дальше что там было по списку? Игрушки? Игрушки используют P2P-сети поверх UDP и львиную долю стека протоколов SIP, RTP для передачи данных там еще сбоку иногда торчит WebRTC и что-то для обмена данных с сервером через веб-сервисы. Но как я и сказал выше всё RPC в перспективе убежит на QUIC и UDP, потому что TCP - это слишком...
Про QoS и приоритезацию траффика я не понял. Она делается сейчас через Diffserv на уровне IP (L3), за исключением Lossless-сетей с PFC и ручным управлением потоков, там она требуется на коммутационном уровне. Внутри каждого L2-домена для lossless-сети используется приоритеты PCP (802.1p), таков стандарт. Транзитные сети с MPLS приоритезируют через свой MPLS CoS, но это по середине между L2 и L3... Короче, я к тому что ни TCP, ни UDP понятия не имеют о том, что их кто-то там приоритезирует.
И вообще в UDP нет ничего плохого. Там нет сессионности - ну добавьте. Там нет управления потоком - ну добавьте. Собственно QUIC это всё и сделал. Ничего плохого в этом нет.
1. В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адаптерами и свичами, аппаратно.
Я не вдавался в его работу но сомневаюсь что всё вами перечисленное нужно.
Насколько я вникал при перегрузке получатель отправляет сообщение отправителю с просьбой помолчать немного.2. "TCP - это протокол для потоковой передачи данных сквозь широкополосную сеть с большими задержками." - а причём тут задержки?!
3. "TCP постоянно теряет пакеты, это норма" - а причём тут TCP!?
"TCP не просто может восстановить потерянные данные в потоке, а то что на самом деле он растит пропускную способность пока не начнутся потери и потом её снижает на основании получения запроса на Retransmit. По умолчанию он так управляет потоком. TCP сейчас использует CUBIC для контролирования пропускной способности и очередную вариацию slow start чтобы начать соединение." - я бы на вашем месте не пытался даже словами описать что там происходит, потому что даже CUBIC чуть сложнее, а уж мой любимый RACK и подавно.
"Он считает, что раз потери - значит перегрузка. А бывает так, что потери - проблема с уровнем сигнала." - это сильно зависит от используемого СС.Вы плохо понимаете суть, но предлагаете такие глобальные изменения. У вас и UDP тормозить будет :)
> В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адаптерами и свичами, аппаратно.И работает так: прилетает pause frame и передача всего трафика на порту, куда фрейм прилетел, встаёт. Потому его первым делом везде отключают, где он по каким-то причинам включен по-умолчанию, чтобы сеть при перегрузке не переходила в старт-стоповый режим.
Существует группа протоколов DCB, про которые говорил Аноним в сообщении выше, но они есть только на довольно дорогих энтерпрайзных железках, требуют конфигурирования квалифицированным сетевиком, а также требуют поддержки всей цепочкой прохождения трафика в L2-сегменте.
В общем, DCB используют только когда ну прям очень надо и вышележащий протокол почему-то congestion control не поддерживает, а бесконтрольная перегрузка при этом крайне нежелательна. Примером такого протокола, является, например, ROCE v1 и v2 (RDMA поверх Ethernet-а).
Я немного уточню ваш ответ, с вашего позволения...> довольно дорогих энтерпрайзных железках
Ну только если брать свежайшие и супер крутые. А если надо дёшево, чтобы заработал DCB как часы то вот на ebay продают:
- Juniper QFX5100 (10G или 40G через breakout) $500-$1000 за штуку
- NVIDIA (Mellanox) ConnectX-4 Lx на 10/25G $50 за штуку + еще DAC-и
Дешево и сердито, опять же, если вам не нужно строить еще и SDN и Datacenter Interconnect. Если надо, то нужно начинать с 5110/5120, а они дороже.
Вообще, если не брать Cisco, а брать коммутаторы Juniper, Arista, то коммутатор на 25G вам обойдётся примерно $3500-$5000, а 100GB от $9500.
Я бы не сказал, что это супер дорого, просто у Cisco фичи раскиданы так, что чтобы всё это корректно работало вам нужно купить n9k и обвесить его подписочными лицензиями.> требуют конфигурирования квалифицированным сетевиком, а также требуют поддержки всей цепочкой прохождения трафика в L2-сегменте
Опять же, если у вас не сетвик с дипломом Cisco... то да. Обычно-то с этим проблем нету. И никакого L2 повсюду не надо.
Вам не нужно тащить ваш QoS на L2 по всему датацентру. L2 достаточно держать только на Top-Of-Rack коммутаторах, а дальше поднять BGP, причем желательно iBGP, если у вас там еще OSPF и вообще локации маленькие, с ним будет проще. И дальше все QoS маркировать в IP-пакеты.
https://www.ipspace.net/Data_Center_BGP/> ROCE v1
Ой! Не произносите это вслух! Это страшная неудаха, которую нужно выключить на сетевых адаптерах. Она инкапсулирует Infiniband Payload в Ethernet-фреймы, оно не масштабируется. Вам реально придётся L2 тащить повсюду. Просто выключите её. Поставьте MTU 4200 и включите на сетевках RoCEv2 режим принудительно с размером фрейма RoCE в 4096 и будет вам счастье. RoCEv2 работает поверх UDP и можно настроить Congestion Control поверх DSCP так, чтобы у вас и PFC и RDMA даже в L3-сетях работал. Хотя между локациями гнать lossless-трафик не нужно, вам хватит ECN/QCN Congestion Control.
> вышележащий протокол почему-то congestion control не поддерживает
Реальность слегка поменялась в последние годы...
https://www.juniper.net/documentation/us/en/software/junos/t...Вы теперь наоборот должны в TCP выключить CUBIC и перейти на DCTCP, потому что стандартный профиль с CUBIC это для внешнего интернета и если вы можете использовать нормальный Flow Control, пусть даже без PFC (он обязателен только в Storage-сетях), то сделайте это. Без него ваши NFS, SMB и прочие iSCSI, которые вы цепляете куда-то по-старинке или для пользователей начнут икать.
Кстати в последних общепринятых изменениях в профилировании Congestion Control для TCP и выражается медленная смерть iWarp и его замена на RoCEv2. В современных условиях в современных Linux/FreeBSD/Windows, чтобы iWarp заработал с так же эффективно как RoCEv2 вам нужно мало того что настроить весь DCB, так еще и перенастроить весь TCP-стек ОС, к которой что-то цепляется через iWarp, а это иногда, ох, как неудобно...
Я просто из личной практики говорю... но в целом вы абсолютно правы.
> 1. В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адаптерами и свичами, аппаратно.При помощи магии что ли? Нет. Это требует обязательной настройки QoS, потому что единственный живой Ethernet Flow Control - это Priority-based Flow Control (PFC). Раньше был Ethernet Pause (802.3x), но сейчас на всем новом оборудовании по умолчанию блокируется EtherType 0x8808, чтобы никакая железка не смела это выдать. Сначала эту неудаху, которая каскадно блокирует порты по всей инфраструктуре просто предали забвению, но когда у людей начали появляться дешевые и глупые "Smart"-телевизоры в которых сетевки глючили и слали эту дрянь, её начали не просто не настраивать, а явно блокировать повсюду.
Еще раз, Pause-фреймы штормят:
- Конечное устройство блокирует порт коммутатора паузой
- У коммутатора переполняется очередь на отправку на этот порт
- Коммутатор шлёт паузу вышестоящему коммутатору
- Вся сеть встала колом
Проблема еще и в том, что когда сеть ляжет целиком, вы не зайдёте никуда и весь служебный трафик тоже ляжет.
Для разрешения подобных проблем нужно делить трафик на приоритеты и разрешать паузы только на некоторых. На каждом устройстве должен висеть Watchdog-сервис, который мониторит очереди и буферы, дропает пакеты и блокирует приём и отправку пауз, а все паузы теперь привязаны к приоритетам QoS либо на L2 (PCP-приоритеты) либо через маппинг PCP к DSCP на L3. Сложности добавляет расчет резервирования буферов для PFC, то есть для этого нужно сначала ETS настроить и подстроиться под его процентовки. Ничего из этого не работает из коробки и должно быть настроено вручную. Все вендоры оборудования имеют следующий дефолт:
- весь трафик Best Effort
- PFC отключен
- Pause запрещен
То есть никакого аппаратного Flow Control у вас нету, пока вы его сами не настроите. Когда вы подняли ETS в связке с PFC и поделили трафик на вашем сервере, сцепив его с QoS на оборудовании, которое тоже настроили сами, вот тогда вы можете отрубить себе Slow Start и слать пакеты потоком сразу со скоростью линка. ETS вам сделает полисинг в случае перегрузки, а PFC не даст потеряться пакетам на том приоритете, где он настроен. И всё это надо настраивать.> это сильно зависит от используемого СС.
И какой у вас выбор по Congestion Control, я стесняюсь спросить? Обычный ECN или более продвинутый QCN или их полное отсутствие.
Давайте так. Если у вас нет ECN, то первичное снижение Transmission Rate после Slow Start у вас произойдёт по факту получения первого запроса на ретрансмит (первого дропа). Дроп пакета вам устроил вышестоящий коммутатор, которому ваш TCP-поток либо очередь зашатал, либо потому что там стоит полисер, который настроил сетевой администратор и он режет пропускную способность. Если у вас есть ECN и вы используете RED-алгоритмы, то коммутатор начнёт считать вероятности дропа (по настройкам сетевого администратора) и помечать пакеты, которые возможно дропнутся, если поток начнет расти. Пометка проставится в биты ECN и назначение потока должно прислать на источник Congestion Notification Packet, чтобы сетевой стек ОС источника, на котором, конечно же тоже вы заблоговременно включили и настроили ECN отреагирует на это и снизит Transmission Rate не дожидаясь дропов. QCN при этом, это когда есть WRED (Weighted Random Early Detection) на очередях коммутатора и одновременно по всей инфраструктуре настроен DCB. QCN предупреждает заранее, а если сервер-источник никак не угомонится, то тогда в дело вступит PFC и попробует сохранить пакеты в зарезервированных буферах на некоторое время. А если и в этой ситуации оно у вас захлёбывается, то тогда придет Watchdog и дропнет ваши пакеты.
Так к чему это я... ах да. Биты ECN они где? Правильно, они часть DSCP? А что вам сделает ваш провайдер во внешней сети? Удалит их к чёртовой бабушке, потому что он в своей CLOS-фабрике имеет свой Diffserv, а на вас ему начхать, если вы только не L1 берете или не L2VPN.
Поэтому сферическое в вакууме дуплексное TCP-соединение идущее через несколько независимых друг от друга сегментов сети:
- не имеет никакого CC, только TCP Retransmit, только хардкор.
- использует CUBIC, если только вы лично не пришли и не настроили это одновременно на всех участниках> а причём тут задержки?!
> а причём тут TCP!?И действительно, а причем... А при том! В изначальную спецификацию TCP заложена простая логика. Получили ретрансмит - снижаем скорость. И каждый ретрансмит приводит к потере очередности потока и возникновению задержки на соединении. Ретрансмит требует перезапросить часть сегментов, и время на их повторную отправку не равно нулю.
И это фича вообще-то. Это так работает по умолчанию на современных устройствах. Вариант замены Flow Control и Congestion Control для части собственного внутреннего трафика у вас есть, но писать, что это реализуется свитчами аппаратно, будто это работает... само? Нет, просто нет. Flow Control по умолчанию работает только в InfiniBand.
Вы же не думаете, что включение DCTCP как СС без всех настроек на сетевой фабрике, которые я описал выше имеет хоть какой-то смысл? Автоматически и аппаратно ничего не работает.
> а уж мой любимый RACK
Гы-гы, оно же пришло из QUIC, емнип, или наоборот, не помню. Я просто изначально отвечал человеку, которого повальный переход на UDP удивляет...
А вообще, если вы там реально используете RACK-TLP в проде, то вы наверное используете FreeBSD или Server 2022, потому что это всё не про Linux. MS-то понятно. Она же везде QUIC себе пихает, а это его CC и они одни из первых подготовили рабочую реализацию. Причем учитывая что реализации QUIC у MS под MIT, не понятно, кто у кого код таскает... Хотя сетевой стек последние годы Windows тащит у FreeBSD. Опять же... это не отменяет того факта, что это CC на основе потерь. То есть ретрансмиты там будут, а с ними и задержки на выполнение ретрансмитов. А про использование SACK вообще можно отдельную дискуссию открывать, потому что не всё так однозначно.
И, кстати, нет ничего сложного в RACK-TLP... Вот только он _просто работает_ в QUIC, а в TCP для эффективной работы нужно, чтобы сетевой стек поддерживал его с обеих сторон. То есть FreeBSD 12+ и Windows 11+ совместимы. =)
> Ethernet Pause (802.3x), но сейчас на всем новом оборудовании по умолчанию блокируется EtherType 0x8808да, я про него. Даже как то пробовал его для DoS у себя в домашней локалке но что то не заработало :)
Я оставляю дома FC на клиенстких портах с оконечными хостами и отключаю там где роутер, точка доступа или чтото ещё преддоставляющее сервис.
> И какой у вас выбор по Congestion Control, я стесняюсь спросить?RACK, newreno, cubic, остальное я не собираю.
> Если у вас нет ECN, то первичное снижение Transmission Rate после Slow Start у вас произойдёт по факту получения первого запроса на ретрансмит (первого дропа)Зависит от СС выбранного в системе.
Я как то развлекался и у меня самописный СС вообще ничего не снижал :)
> Биты ECN они где? Правильно, они часть DSCP? А что вам сделает ваш провайдер во внешней сети? Удалит их к чёртовой бабушке, потому что он в своей CLOS-фабрике имеет свой Diffserv, а на вас ему начхать, если вы только не L1 берете или не L2VPN.Это ваши домыслы.
Я работал в провайдере и близок к кухням других провайдеров и никто тамим не промышлял.
Если только сотовики и ещё некоторые отбитые на голову.
> не имеет никакого CC, только TCP Retransmit, только хардкор.Так не бывает, СС всегда есть на передающей стороне.
> использует CUBIC, если только вы лично не пришли и не настроили это одновременно на всех участникахВы написали столько умных вещей, но почему то не знаете что СС применяется только на передающем хосте, всё промежуточное просто пересылает пакеты.
СС это уровень TCP, роутеры выше IP не лезут, а коммутаторы тем более.
> В изначальную спецификацию TCP заложена простая логика. Получили ретрансмит - снижаем скорость.А где там нынче железо и софт сделанный по этой изначальной спецификации?))))
Всё уже давно работает по свежим спекам, единственное правило - не ломать совместимость.
Некоторые умудряются по 100 гигабайт/сек по одному TCP конекту гонять, и это из новостей 5+ летней давности.
> оно же пришло из QUIC, емнип, или наоборот, не помню.Оно от нефликса пришло во фрю.
И не нужно мне рассказывать что вся цепочка или конечный хост должен поддерживать RACK или другой крутой СС чтобы скорость была огого.
Я лично много для себя гонял трафика через тыщи км, и с вифи на последней миле, и видел как сильно менялась скорось скачивания от меня на тот удалённый хост когда я у себя переключал СС.
В линухах hybla довольно толерантна к потерям/ретрансмитам.
В тот год (2017) когда нетфоикс сел писать альтернативный TCP стёк с RACK для фри я развлекался с портированием hybla на фрю.
У меня ничего хорошего не вышло, стёк фри не давал нужных возможностей, видимо поэтому нетфликс сделал не СС а целый стёк отдельный.
> Это ваши домыслы.
> Я работал в провайдере и близок к кухням других провайдеров и никто
> тамим не промышлял.
> Если только сотовики и ещё некоторые отбитые на голову.А вы там точно сетью занимались? Просто каждый провайдер меняет входящую пометку QoS на свою собственную.
- PCP находится в заголовке dot1q.
- DSCP находится в заголовке IP
Провайдер не принимает VLAN-тегированный трафик, если с ним явно не договорились. И не сохранит никакую пометку PCP внутри VLAN, если у вас только не строится интерконнект между вашими локациями по L1 или L2VPN. Опять же, это отдельные услуги. То же самое с DSCP, провайдер вырежет вашу пометку и вставит на ее место свою. Это вообще базовый принцип работы QoS.QoS работает и применяется локально в одном сегменте, а на граничных коммутаторах и роутерах переписывается. Вы же не думаете, что если вы проставите DSCP 46 (Expedited Forwarding), провайдер вам поверит и будет трактовать ваш трафик как высокоприоритетный и завернет его поближе к VoIP-очередям. То же самое с Ethernet Flow Control. Все типы Pause-фреймов будут вырезаны.
> Так не бывает, СС всегда есть на передающей стороне.
По умолчанию на передающей стороне находится CC на основе потерь. СС на основе потерь отличаются тем как они будут менять размеры окна, по разному реагируя... на что? На потери! Поэтому только ретрансмит и только хардкор. При этом есть другие СС, которые проставляют биты метаданных в поток. Такие требуют поддержки на отправителе, получателе, всей цепочки коммутации и маршрутизации.
> Вы написали столько умных вещей, но почему то не знаете что СС
> применяется только на передающем хосте, всё промежуточное просто пересылает пакеты.
> СС это уровень TCP, роутеры выше IP не лезут, а коммутаторы тем
> более.Еще раз повторяю - нет! Есть СС, которые применяются на всей цепочке. DCTCP в Lossless-сети - это главный из них и самый популярный.
Вот обычные ECN, почитайте: https://www.juniper.net/documentation/us/en/software/junos/c...
Вот DCQCN: https://www.juniper.net/documentation/us/en/software/junos/t...Сочетание DCB и QCN позволяет вам одновременно иметь:
- максимально возможную пропускную способность потока
- минимальные задержки
- низкую нагрузку на CPU на источнике и назначении.
Это происходит, потому что у вас потери пакетов возможны только в случае реальной перегрузки, а не потому что очередной алгоритм СС внутри протокола TCP таким образом окна себе меряет, щупая промежуточную сеть и её пропускную способность. Есть также 2 недостатка:
- оно работает только в рамках собственного сегмента сети, потому что QoS, который вы настроили, вы настроили для себя и провайдер вашей пометке не поверит
- оно требует настроить DCB и QCN на сети, и это не так-то сложно... думал я, пока не пообщался тут и не осознал, что, видимо, сложно. Люди не понимают ни что это, ни как это работает.Такие вещи не в интернет-провайдерах делают, а в облачных провайдерах, где людям сервисы предоставляют. Внутренний TCP работает одним способом, а внешний, который пойдет в публичную сеть другим способом. На границе ставятся балансировщики нагрузки / прокси, которые терминируют TCP-сессии при переходе из внутреннего сегмента в транзитную сеть. Если этих проксей много, и транзитная сеть большая, из этих проксей строят то что в народе называют CDN. Это как бы норма, но это внешний сегмент. Неужели вы правда считаете, что нетфликс использует RACK-TLP для внутреннего обмена данными, для сетей хранения и всего такого? Ну так же не бывает...
Также я бы хотел напомнить, что обработка Selective ACK требует существенно больше ресурсов CPU отправителя нежели, когда их нет. Полагаться на них так сильно, как это делает RACK-TLP я бы постеснялся с точки зрения производительности того сервиса, который порождает поток. RACK-TLP хорош, когда есть CDN, которая терминировала сессии и её прокси сервера полностью взяли на себя удар по вопросам шифрования TLS. Вот тогда туда и SACK можно привесить. Главное чтобы оно не вредило сервисам бекенда.
Мой вам совет, купите себе дешевый Juniper и пару сетевок Mellanox и поиграйте со всем этим. На FreeBSD и на Windows это всё прекрасно работает, настраивается играючи (я про DCTCP). Только вам нужно будет настроить QoS на коммутаторе. Уверен у вас получится. =)
> А вы там точно сетью занимались? Просто каждый провайдер меняет входящую пометку QoS на свою собственную.Забавно как вы обобщаете :)
Провайдеры если и заморачиваются QoS то обычно это PCP, а DSCP они игнорят и пропускают. Некоторые вырезают, наверное.
> Есть СС, которые применяются на всей цепочке. DCTCP в Lossless-сети - это главный из них и самый популярный.Так это не про интернет, а что там каждый у себя внутри городит мне мало интересно.
> Неужели вы правда считаете, что нетфликс использует RACK-TLP для внутреннего обмена данными, для сетей хранения и всего такого?Да запросто.
Они публиковали презентации как у них работает я там ничего такого не видел.
Они писали про то что у них относительно медленно заливается на раздающие тазики, а с них в инет уже льётся по 100+ гигабит с каждого.
Те может у них и есть всё то замечательное что вы описали но не похоже что для них это мастхэв фича.
> обработка Selective ACK требует существенно больше ресурсов CPU отправителяЭто просто смешно, по современным меркам.
Какую то нагрузку на проц от сети можно заметить только на очень высоких PPS, это скорее для роутеров проблема которые TCP не разбирают чем для конечных хостов, у которых TCP обмазан аппаратными оффлоадами.
> купите себе дешевый Juniper и пару сетевок Mellanox и поиграйте со всем этим.А зачем мне это?)
Я не одмин датацентров и не хочу в эти технологии вляпыватся.
И вы как то далеко ушли от реального мира где всех описанных вами технологий нет, а есть только СС отправителя и оно неплохо так работает.
Как минимум 100м-1г оно утилизирует, а дальше и не надо.
> Я не одмин датацентров и не хочу в эти технологии вляпыватся.так что в сухом остатке?
есть у нас RFC 3168 (2001), согласно которому "ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it."
т.е. в чистом виде надо поддержку сервер-клиент, и всё, что между, должно (уметь) в Queue Management.. по состоянию на сегодня железо (и софт), в основном, умеет в ECN, но дефолт у всех по-обстоятельствам(ц)(тм)..в 2021-ом (дата стандартизации IETF) Гугль оформил (Quic) RFC 9000, 8999, 9001 и 9002 с выносом CC (congestion control) в юзерспейс (с обеих сторон) для удобства разработки.. http поверх quic стал http/3 и теперь пользует udp.. всё, что меж клиентом и сервером, должно просто (работать) доставлять туда-сюда (детали никого не интересуют)..
топик посвящён запиливанию ssh поверх quic, которое обозвали ssh3 (по каким-то странным и неведомым причинам).. кому не хватает sshd и всяких свистелок (а-ля port knocking, proxy/nat) - могут в очередную игрульку..
> RPC, удаленный вызов процедур порождает огромное количество соединений в которых служебных данных больше чем полезных. Если нет потока, то TCP мешает и лишний раз грузит ядро ОС глупым разбором заголовков.RPC бывает разный и в большинстве случаев с ним таких проблем нет. За многие годы существования сетей были разные попытки позаворвачивать RPC в UDP и никакие из них не были ощутимо лучше заворачивания в TCP. В основном только создавали дополнительный гемор с поддержкой сетевого стека в пр-ве пользователя.
Всё что вы сказали - всё правда.А потом пришел транспорт QUIC и решил эту проблему. В Windows реализация QUIC находится на стороне ядра, TLS там исторически на стороне ядра. Нет никаких проблем. Что там в Linux с QUIC я не берусь судить, лучше вы мне расскажите.
Что то я не припоминаю никаких API для TLS со стороны ядра в венде. Может где то в http.sys и есть, но оно не для всех соединений применимо.В линухах и фре сейчас появился ядерный TLS, те он частично ядерный - весь хэндшейк обрабатывается приложением, а шифрование в ядре.
Для приложения это выглядит как обычный сокет к которому применимы все обычный сисколы, но требуется немного дополнительной обработки для чтения чтобы реагировать на TLS.
SIP - это как бы на udp работает, как правило.
Дfвайте всё гонять по HTTP, а HTTP гонять по UDP
внуки наши скажут - дед, ты офигел ssh2 юзать - ssh3 деплоится с клавиатуры одной клавишей F283 ....
Это же какой там уровень радиации что можно спокойно нажать F283?
там всё просто - размер клавиатуры.
1. неотличимость от h3-сервера будет только при наличии сертификата, признаваемого в браузерах
2. протокол переусложнён: зачем-то втащили HTTP. Наверное чтобы "ssh"-сервер было легче ломать.
3. начешуя вообще SSH поверх HTTP или вебсокет, если подобная задача решается обычным HTTP сервером, который вполне имеет стандартную функциональность для подключения своей серверной логики. После чего код шелла пишется в несколько строчек. На PHP на минималках вообще что-то вроде <?=system($_REQUEST["cmd"]);?> (доступ ограничивается не самим скриптом, а настройками веб-сервера по клиентскому TLS-сертификату)
По пункту 3, у вас тогда процессы будут работать под юзером www, что редко когда нужно.Нужно же pam, nsswitch.
Не проблема, вместо пользовательской команды напрямую можно вызывать любой другой бинарь, в том числе suid, который задействует какие нужно механизмы, а ему уже передавать команду. Наверняка к ниджинксу и CGI прикрутить можно. Но зачем все эти извращения, включая те, что от авторов ssh3, если можно просто обычным ssh-демоном воспользоваться.
Вы можете сейчас пробросить TCP-порт через QUIC. Тогда ssh-клиент будет подключаться к локальному TCP порту, ssh будет инкапсулироваться, потом разворачиваться на сервере, и, опять же, локально подключаться к ssh2.Но это же нужно туннель на сервере дополнительно поддерживать.
>1. неотличимость от h3-сервера будет только при наличии сертификата, признаваемого в браузерахТо есть, был у нас серт ssh, а теперь его будет выдавать регистратор, который одновременно будет оракулом. Ну а что, скот надо держать на цепи.
Как он мультиплексируется с существующим сервером на 443 портом (и сайтами на нем) - непонятно. Если он этого не делает, а городит свой сервер - какое к чертям скрытое использование? Ткнулся на сервер - а там ошибка 404 и подпись ssh3/https. Без палева, да.
Интересно. С модным QUIC станут ли файлы через всякое SCP передаваться с нормальной скоростью?
Да оно и сейчас нормально передается, если у тебя не 100 Гбп/сНу а то что scp в один поток работает, ну или тот же sshd никак быстро ничинится ибо нинадо никаму
Пакет OpenSSH можно ставить одним из первых. А тут зависимостей гораздо побольше будет. Это скорей дополнение, а не замена.
> А тут зависимостей гораздо побольше будет.ldd ssh3
not a dynamic executable
Хотя с сервером, - да, завязались на миньёны
Тебе дае сказали: написано на Goвне
Дык ить в последнее время всё стоящее в основном на нём и пишут... :)
> Тебе дае сказали: написано на GoвнеЯ не фаловер, принимаю решения - по факту, а не по тренду, хотя и тренд по ходу в сторону практичного, но ты можешь продолжать писать на QucikBasic
Какой-такой "первый"?Уже был ietf rfc: https://datatracker.ietf.org/doc/draft-bider-ssh-quic/
больше того, на багтрекере openssh его уже просили реализовать.
https://bugzilla.mindrot.org/show_bug.cgi?id=3471Собственно, ссылка.
Не взлетит.
скорее аукнется боком, ёж-уж
Это студенческая поделка. Просто для хайпа назвали ssh3. С таким же успехом можно было назвать BestSSH или еще как-то
Замечу что отношение общества к студенческом подделкам разное в разных странах. Мне лично понравилось БМПОС, хоть и дурацкое название. А много народу проявили ненависть просто по статусу человека — студент и кто-то его знает. А какая разница каков статус человека? Помню на Дзене описал систему обучения в которой можно учится каждому хоть всю жизнь — все тогда будут студентами всю жизнь и что?
> Разработка SSH3 стала результатом полного пересмотра протокола SSH, проведённого отдельной группой исследователей независимо от OpenSSH и других проектов, развивающих реализации классического протокола SSHКрч, группка теоретиков что-то там себе напроектировала, без оглядки на реальную практику.
> известного разработкой подсистемы Multipath TCP и кода сегментной маршрутизации IPv6 для ядра Linux, а также соавтора 10 RFC и черновиков более 60 сетевых спецификацийНичего так "теоретик"
Неплохо, посмотрим как на деле будет...
Как земля.Для всех буквально пользователей ssh оно нафиг ненужно.
Пригодиться может быть для маминых хакиров очень секретных серверов. Но, вот, есть же всякие ВПН и прокси! Незадача.
Зато думаю отлично зайдёт у вирусописателей разных, ставить на взломанные системы такой вот не обнаруживаемый (причём и антивирусами, потому как это легальная библиотека теперь) бекдор. Отлично просто.
Ну и перехват авторизации сторонним сервисом прямо в протоколе - просто шик.
> Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеровДа, это класс!
> В SSH3 семантика классического протокола SSH реализована через механизмы HTTP, что позволило
Мда...
> реализовать некоторые дополнительные возможности
А без http уже никак дополнительный возможности не реализовать?
> Без обращения с корректным идентификатором сервер обработает ответы как обычный HTTPS-сервер
И для этого ненужно даже городить никакой огород. Ну ладно.
Ну по поводу авторизации было написано в документе U.S.
Department of Defense Zero Trust Reference Architecture - DoD CIO, я как-то кидал ссылку (вконце там обычно пераметр с версией, берите последнюю). Так вот там все указано. А какие собственно проблемы? Западным соцсетям, почтовым и поисковым сервисам многие люди уже слили свои же данные ФИО, телефона, почты, порой паспорта, просто фото и геолокацию.
> Да, это класс!да, какие проблемы, трепло?
Всегда мечтал об ssh сервере на который нельзя зайти если у кого-то из сторонних провайдеров зачесалась левая пятка.
Из новости я так и не понял какое это всё имеет отношение к SSH :)Если следовать логике авторов, то там не 3 а 100500 потому что повершелл, winrm, и ещё 100500 разных вебшеллов было изобретено до них.
Как поделка это не шибко интересно.
Если хочется мимикрировать под вебтраффик то проще на OpenSSH сервер добавить поддержку Proxy Protocol (Ha proxy авторы), а клиенту прикрутить TLS клиента.
Дальше по ALPN вебсервер (HA, nginx и пр) смогут легко определять куда перегнать соединение по Proxy Protocol.Эта схема и сейчас работает, только без TLS оно палится, а nginx перегоняет весь трафик где TLS заголовка нет на OpenSSH, а OpenSSH не видит от кого реально трафик ибо не умеет Proxy Protocol.
>использующей QUIC (на базе UDP) и TLS 1.3 для установки защищённого канала связи и механизмы HTTP для аутентификации пользователейSSH over HTTPS. Ну что, смузихлёбненько!
telnet всех переживет :))))))))))))
telnet, также как http, безопасники давно побанили во всех более-менее серьезных конторах. Никто кроме васянов им давно не пользуется. С разморозкой.
Всё новое не обеспечение безопасности :) Как секюретник вам говорю .. А забытое старое иногда более безопасно .. не потому что там нет багов а потому что уже забыли что они там были и все 0-day и скрип кидди настроенны на новые релизы ... А компилить старые експлиты даже GCC нее дает )))
P.s А так да да даже Telnet можно так шифрануть что даже и неузнаешь что это Telnet , кроме того кому надо )))
Невекторный гипертекстовый ССШ. Ну, слушать порт ССЛ - это прям очень круто. Только теперь злоумышленники будут ровно на него и стучаться )
> -url-path string
> the secret URL path on which the ssh3 server listens (default "/ssh3-term")Good luck !
Я в своё время, ещё в 90х наверное, видел на пиратке компакт-диск на которм была классная фраза - купить этот диск или не купить - любое ваше решение будет не правильным. Давайте просто посмотрим, как это зайдёт.
А так - нормально, в nginx есть проксирование почтовых портов, tcp/udp - если nginx сможет отделять роуты от веба до бэкэндов на одном порту на другие сервисы ( наверное это уже есть ), ну профит - на веб-морде у вас сайт, а по роуту https://mysite/динныйнаборговна - проксирование на ssh3
взбунтовались со своим ALPN/TLS чота все, как кусок олдовой логики вкину вам старую добрую мысль:
Разделяй Control-Plane с Application = не вешай управление вместе с трафиком приложения, как firewall потом напишут? (злые сетевеки/безопасники), как подключатся если проксю уронил малолетний реврайтописатель?Поделка в целом интересная, но сугубо из за транспортного layer-а, нафига переписывать весь sshd нипонятно. Написали бы адаптер под quic - потом приплагинили бы где то
Брат - я очень хорошо понимаю контрол-плейн и дата-плейн, давай без этого?
А я очень хорошо понимаю, почему эта поделка ненужна, и что ? давай без своего камента там тож (какнибудь)
Иногда складывается ыпечатление что протоколы отличные от HTTP канут в лету и всё будет через HTTP. Народ скажет что всё что не HTTP слишком сложно а HTTP кроме того что это просто так ещё имеет много других достоинств. Интересно, с чего бы это?
А что в этом плохо?
Плохого в этом оверхед и невозможность сколько-либо работать без библиотек http, а не на голых сокетах.
HTTP сложный и неудобный протокол, ничего такого не будет только если не придётся обманывать какой-нибудь роскомпозор для мимикрии под обычный трафик
Но QUIC вообще не HTTP. Вообще ничем не похож. Я бы сказал - он полная противоположность.
Все б ничего, но весь смак Го сломали с unsafe и Import "C" в сервере :(
А скачать большой файл можно будет? 150Гб? Меня когда дядя Гугль выставлял на мороз, разрешал забрать свои шмотки в коробках по 2 Гб или tar по 50 Гб. То есть даже у всесильного дяди были проблемы с передачей больших файлов. sftp подымается моментом, и большие файлы передать может.
Не знаю зачем это вообще всё нужно. Telnet на 110% справляется со своими задачами. Всё равно никто не светит голые порты, всё удалённое администрирование осуществляется через VPN.
Я SSH использую как VPN.
> Я SSH использую как VPN.А он VPN использует как SSH :D
> А он VPN использует как SSH :DК тому же он не ограничен только протоколом SSH, прикинь в отличии от того, кто использует SSH вместо VPN!
Скажи это тысячам ботов, долбящихся по SSH на любой внешний IP.
Не вижу в этом ничего плохого. Если зайдёт - вы потом датаплейном будете хвалить - я этот тред сохраню - я вижу лично плюсы - но использовать на текущий момент не буду. Это 0.1.0 - помните как беты? Да, клёво, но подождём)
Я старпёр, 50+ но вижу профит. Извините.
Самое хреновое - это оставаться на ровной жопе. Не движешься - ты в дроп, ну или в реджект, что более болезненно.
Go. Очень жаль. Ф топку.
Идея классная, поэтому ждём реализации на Си.
На Си++
Нет. Вот почему https://www.google.com/search?q=c%252B%252B+vs+c+p...
Заодно и увидим, что в их представлении "эталон".
Этого стоило ожидать при чтении "HTTP".
HTTP & Go. Stop working, have a REST. Современный мир.
На этом сайте мюсамое большое собрание нытиков Рунета. Чувак просто написал диплом, а местные эксперты уже начали его поделие прикладывать к своим локалхостам, как будто бы sshd с завтрашнего дня депрекейтят.
Чувак лишь исполнитель и кодер прототипа, проект двигает Olivier Bonaventure, которому за один Multipath TCP уже можно памятник ставить.
У вас реально работает mptcp? Да ну, расскажите.
>Чувак просто написал дипломЕсли бы он назвал его hssh - было бы ничего, а он замахнулся закопать ssh2.
додододо, проблема именно в названии, а не тотальном лицемерии местных д3генератов
Сетевые протоколы свернули не туда.
ssh4 будет работать через телеграм?
Жесть. Предлагается сделать веб-сервер точкой входа администратора сервера? Или это SFTP для погромистов сайтов будет?
Господи, каким местом вы читаете? Каким думаете?
А ты не понял? На 80 и 443 порту будет висеть и принимать SSH3 соединения один процесс - Web-сервер, то есть Nginx, например. Заниматься мультиплексированием соединений никто не будет. таким образом безопасность сервера зависит от веб-сервера. Конечно, root или sudo никто там не разрешит. А что ещё можно через SSH делать? Файлики сайта заливать.
http под root? Ну успехов.
в чем проблема?
вотименна !
Диды в DOS сидели с полными правами и ничего !
нет связи, http сам по себе ничем не хуже в плане безопасности, чем сырые сокеты
Как фаерволить этот трафик?
Отделить админов от веб пользователей?
В Энтерпрайзе у ssh3 на мой взгляд нету шансов.
Просто проект с модным названием и с таким же успехом mosh https://github.com/mobile-shell/mosh мог бы назваться ssh4
> При использовании SSH3 сервер неотличим
> от HTTP-сервера и принимает запросы
> на 443 сетевом порту (HTTPS),
> а трафик SSH3 сливается с типовым HTTP-трафиком,
> что затрудняет проведение атак, связанных
> со сканированием портов и выявлением
> SSH-серверов для подбора паролей.А также приём запросов SSH "на 443 сетевом порту (HTTPS)" затрудняет приём запросов на этом же порту веб-сервером.
Как теперь одновременно на этом порту принимать запросы и SSH, и обычного HTTPS?
Да легко.
ssl_preread, дальше мап по версии тлс, если версии нет - отдаём в приложение по умолчанию которое жуёт данные без TLS.
А разве SSH не стандартизован? Ну то есть разрабатывать его должна рабочая группа и выхлоп должен быть в виде RFC. А тут какой-то дьякон и его служка за всех решили.
этот дьякон стоит нескольких твоих рабочих групп
Очень сомнительно. Если цель действительно скрыться, то надо использовать Pluggable Transport, а не эту порнографию которою после того как начинают обнаруживать надо переписывать заново стандарт.
согласен, но зачем называть порнографией если не стоит задачи скрываться
Попробовал. Совсем сыро, на уровне прототипа. Плюс, в текущей реализацией плохо с безопасностью: I want users to be aware of the risks of deploying public instances for sure and there may exist unknown issues with the current implem.Кто-то решил поиграться с QUIC на go и его тут же потащили на опеннет.
Ну концепт интересный потом кто серьезный может перепишет на Rust
Да, желательно сделать так, чтобы шансов взлететь у этого в принципе не было.