Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Представлен SSH3, вариант протокола SSH, использующий HTTP/3, opennews (?), 17-Дек-23, (0) [смотреть все] Я правильно понимаю, что теперь нужен будет правильный сертификат, подписанный , anonymos (?), 11:55 , 17-Дек-23, (1) –1 // Нет, можно использовать RSA и EdDSA ed25519 ключи от SSH или самоподписанные се, Аноним (2), 11:58 , 17-Дек-23, (2) +11 А кто запрещает использовать корпоративный центр сертификации или самоподписанны, анон (?), 12:03 , 17-Дек-23, (3) +9 // Гуглу заплатишь чтоб твой карпаративнй центр добавили в список доверенных Иль ты, pavlinux (ok), 17:28 , 17-Дек-23, (61) –21 // Какой браузер Тут используется HTTP 3 для установления SSH-сессии, вместо брауз, lucentcode (ok), 17:41 , 17-Дек-23, (65) +9 И что то в воздухе мне подсказывает что хоть ftp из браузеров выпилили, ssh3 , _ (??), 23:03 , 17-Дек-23, (103) Вы понимаете , Аноним (126), 04:27 , 18-Дек-23, (126) А каком смысле впилят При запросе в браузере ресурса ssh3 браузер будет вну, rvs2016 (ok), 16:18 , 18-Дек-23, (192) –1 Ну а чего такого то Полно же плагов чтоб обычный ssh из браузера юзать Идеаль, _ (??), 01:06 , 19-Дек-23, (208) зачем можно серверный локалхост пробрасывать, многие утилиты web-морду на локаль, swarus (ok), 12:54 , 21-Дек-23, (224) Не очень сильно понял Приведи примерчики простые , rvs2016 (ok), 14:38 , 21-Дек-23, (225) Новость изучай, тут SSH3 как HTTPS сервер , pavlinux (ok), 18:02 , 22-Дек-23, (231) Ну так свобода кого надо свобода Или ты думал что сертификаты это про удобство , Тот_Самый_Анонимус_ (?), 21:11 , 17-Дек-23, (88) –6 Ой да ладно Нихрена не изучал После того, как мне там какой-то пeдик в техподд, Аллах (?), 23:29 , 17-Дек-23, (104) +8 Наёмный работник имеет право требовать от работодателя соблюдения прав работника, rvs2016 (ok), 16:22 , 18-Дек-23, (193) Ну так пусть тогда работодатель находит работника, который и сбер юзает, только , ivan1986 (?), 16:16 , 19-Дек-23, (217) А зачем тут вообще заговорили про сертификаты Без них этот SSH теперь работать н, rvs2016 (ok), 16:15 , 18-Дек-23, (191) // Так вообще и старый тоже не работал, только они сначала были dsa потом rsa сейча, ivan1986 (?), 16:18 , 19-Дек-23, (218) А старый не работал как, если я к своим хостам через SSH подключаюсь без всяких , rvs2016 (ok), 16:25 , 19-Дек-23, (219) https en m wikibooks org wiki OpenSSH Cookbook Certificate-based_Authenticatio, Sem (??), 07:00 , 23-Дек-23, (233) Правильно, иначе любой впалит, что твой веб-серер ненастоящий , Аноним (31), 13:42 , 17-Дек-23, (31) +3 Да, верно Все мы знаем как отображаются самопописанные сертификаты Конец вебу , Аноним (40), 15:18 , 17-Дек-23, (40) // Даже такое неправильное отображение самоподписанного серта лучше его отсутвия со, BSDSHNIK (?), 17:03 , 17-Дек-23, (57) +1 // Самоподписной может дядя хацкер подсунуть, один xpeн вы забиваете на проверку , pavlinux (ok), 17:31 , 17-Дек-23, (63) А кто тебе мешал раньше использовать самоподписанные , Пряник (?), 09:37 , 18-Дек-23, (143) старОhttps github com moul quicssh POC 4 years ago , Аноним (4), 12:04 , 17-Дек-23, (4) +4 // Да, но это не то Это прокси QUIC- SSH, сам он не умеет ssh вообще, передает все, Sem (??), 20:54 , 21-Дек-23, (228) // Скорее стоило упомянуть вот это Workgroup Internet Engineering Task ForceInterne, Sem (??), 21:02 , 21-Дек-23, (229) В общем, ломают совместимость непонятно ради чего, Аноним (5), 12:04 , 17-Дек-23, (5) –8 // Ради лидерства HTTP 3 Уже вытеснили Java Applet, Silverlight, Flash своим HTML , Аноним (204), 22:39 , 18-Дек-23, (204) Расскажите пожалуйста как демоны SSH3 и, например, nginx решают между собой вопр, Аноним (6), 12:07 , 17-Дек-23, (6) // Принадлежит тому, кто раньше запустился, Аноним (8), 12:12 , 17-Дек-23, (8) +17 В идеале через роутинг в nginx myhost lan pornmyhost lan ssh, Ананимус (?), 12:18 , 17-Дек-23, (11) +5 HAPROXY SNI , Аноним (13), 12:21 , 17-Дек-23, (13) +3 В своём nginx несколькими строчками делаешь реверс прокси и запросы на https , Аноним (18), 12:30 , 17-Дек-23, (18) +4 // Так это и сейчас можно сделать Зачем городить QUIC , Admino (ok), 19:02 , 17-Дек-23, (71) –2 // А как, можешь поделиться , scriptkiddis (?), 20:24 , 17-Дек-23, (84) +1 https www nginx com blog running-non-ssl-protocols-over-ssl-port-nginx-1-15-2 , BrainFucker (ok), 22:58 , 17-Дек-23, (101) +1 Вопрос был в том, как уместить http сервис на одном порту вместе с nginx, а не з, Абывыгда (ok), 11:31 , 18-Дек-23, (167) И если W когда вдруг наступят проблемы с работой nginx, то я потеряю не только в, Аноним (93), 21:50 , 17-Дек-23, (93) +10 // Ну, чтобы уронить nginx это надо сильно постараться Во-вторых, нормальный хости, BrainFucker (ok), 23:01 , 17-Дек-23, (102) –2 Когда у меня вдруг упал мисконфигнулся nginx, меньше всего хочется заниматься за, Аноним (93), 04:24 , 19-Дек-23, (211) Да всё решаемо Можно запилить сервис, который открывает доступ к SSH напрямую, , BrainFucker (ok), 05:11 , 19-Дек-23, (214) Если рассматривать все варианты, то у тебя и ssh демон может упасть Что ты буде, Аноним (18), 11:14 , 18-Дек-23, (161) подключусь по ssh2 , hshhhhh (ok), 12:15 , 18-Дек-23, (170) +1 Разумеется, может Но только вот обычно не вместе с веб-сервером, отдающим сайт,, Аноним (93), 04:26 , 19-Дек-23, (212) вдруг даже дети не появляются, им предшествует бурное времяпровождение только в, Петрович69 (?), 03:02 , 19-Дек-23, (210) Ты, видимо, никогда с продакшеном дел не имел, и уж, тем более, не разбирался с , Аноним (93), 04:31 , 19-Дек-23, (213) ALPN, вестимо , Аноним (19), 12:32 , 17-Дек-23, (19) Например вот так https habr com ru articles 412779 , Аноним (22), 13:05 , 17-Дек-23, (22) Тебе всё наврали, аноним TLS termination для http3 пока не стандартизирован Поэ, Аноним (26), 13:23 , 17-Дек-23, (26) Это просто nginx примет соединение и дальше через proxy protocol отдаст куда на, Ivan_83 (ok), 15:50 , 17-Дек-23, (47) +1 443 нужен только если ты хочешь маскироваться под валидный HTTP никто не мешает , BSDSHNIK (?), 17:05 , 17-Дек-23, (58) // Никто кроме поехавших безопасников в компании , scriptkiddis (?), 20:26 , 17-Дек-23, (85) +1 Кто первый встал, того и тапки, Neon (??), 03:29 , 18-Дек-23, (123) Кто обязывает демона SSH3 на 443 порту держать, есть много других портов, с виду, Alexander Gaiduk (?), 22:20 , 26-Дек-23, (238) Для шифрования канала связи в SSH3 задействован протокол TLS 1 3, а для аутентиф, penetrator (?), 12:11 , 17-Дек-23, (7) Теперь ssh гоняем по UDP, а давайте вообще отменим TCP и всё будем гонять по UDP, EuPhobos (ok), 12:17 , 17-Дек-23, (10) –6   // QUIC это тот же TCP, просто вся логика на уровне выше, что позволяет сделать куч, Ананимус (?), 12:20 , 17-Дек-23, (12) +9   // Вася это Петя, просто имя другое , Ivan_83 (ok), 15:51 , 17-Дек-23, (48) +2   Для этого надо на стороне клиента установить софт что в общем случае не очень, timur.davletshin (ok), 19:29 , 17-Дек-23, (76) +1   // Потому что openvpn не знает, что он передаёт, и потому не может дропать фреймы, , Аноним (26), 20:07 , 17-Дек-23, (81) –1   Чтобы сходить в интернет через tls тебе нужен openssl, ca-certificates и еще ку, Ананимус (?), 00:31 , 18-Дек-23, (109)   Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие , Ivan_83 (ok), 01:20 , 18-Дек-23, (116)   Роутеры и коммутаторы тоже ходят в интернет, там тоже есть целый ворох библиотек, Ананимус (?), 09:20 , 18-Дек-23, (138)   Разупорись, какие пару килобайт Вы давно размер бинарников этих ваших lib ssl s, timur.davletshin (ok), 09:44 , 18-Дек-23, (146)   Ну не суй эту библиотеку туда, где не нужен выход в интернет D, Ананимус (?), 12:38 , 18-Дек-23, (176)   Будто я все прошивки сам делаю и OpenWrt уже готов для работы с трафиком небольш, timur.davletshin (ok), 12:59 , 18-Дек-23, (178)   Тогда чего ты переживаешь Мейнтейнеры все положат , Ананимус (?), 13:45 , 18-Дек-23, (183) –1   Если бы они туда ложЫли, то я бы не переживал , timur.davletshin (ok), 14:35 , 18-Дек-23, (186)   Я пытаюсь сказать что TLS, рабочая инфраструктура сертификатов и даже правильно , Ivan_83 (ok), 12:33 , 18-Дек-23, (173)   Ну вот OpenWRT du -sh usr lib libssl so 1 1524 0K usr lib libssl so 1 1, Ананимус (?), 12:38 , 18-Дек-23, (175)   Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcon, Аноним (100), 22:15 , 17-Дек-23, (100)   // Его нет на уровне UDP, это вынесено на уровень самого QUIC А дальше открываешь , Ананимус (?), 00:27 , 18-Дек-23, (108)   Дальше следующий вопрос возникает Как мне ограничения сделать и разные congesti, Аноним (100), 01:39 , 18-Дек-23, (117) +1   Я не настоящий сварщик, но можешь попробовать примерно так Во-первых, пускаешь п, Аноним (26), 05:38 , 18-Дек-23, (129)   В смысле, разным connect, а не разным flow, конечно , Аноним (26), 08:12 , 18-Дек-23, (134)   Кто как хочет, так и скачет У всех свой велосипед придуман За основу обычн, timur.davletshin (ok), 09:46 , 18-Дек-23, (147)   А давайте Все к этому и идет Неправильно Никто не мешает настроить приоритеты , Аноним (15), 12:24 , 17-Дек-23, (15) +3   // И как будешь различать UDP-потоки По IP , 1 (??), 10:18 , 18-Дек-23, (152)   // По source порту , Аноним (26), 11:26 , 18-Дек-23, (165)   Голосовой трафик и так по UDP ходит А по стандарту можно и SIP over UDP настраи, Анонус (?), 13:04 , 17-Дек-23, (21) +2   Ты почти всё правильно понимаешь Контроль потока на уровне ядра ОС был вынужде, Аноним (26), 13:39 , 17-Дек-23, (29) +2   // Спрошу тебя как эксперта по TCP Почему TCP или его преемник не реализован про, Аноним (37), 14:56 , 17-Дек-23, (37)   // QUIC по большому счёту и является перепроектированием TCP поверх UDP Если его , Аноним (26), 17:25 , 17-Дек-23, (60)   Также спрошу, почему-бы не сделать TLS без портов вообще, раз только 443 использ, Аноним (39), 15:09 , 17-Дек-23, (39)   // Тебе никто не мешает так сделать Вернее, сейчас вообще так и делается, только б, Аноним (26), 17:30 , 17-Дек-23, (62)   Вы себе и близко не представляете что такое современный TCP Обработка TCP в ядре, Ivan_83 (ok), 16:08 , 17-Дек-23, (51) +2   // Невозможно оптимально реализовать работу TCP на канале с потерями 80 А мобил, Аноним (26), 17:36 , 17-Дек-23, (64) +1   1 каналы у которых 80 - не рабочие, в принципе 2 в дикой природе это скорее и, Ivan_83 (ok), 21:23 , 17-Дек-23, (89) +2   1 Вы считаете, что нерабочие, и ничего не делаете, а другие люди пишут quic 2 , Аноним (26), 03:59 , 18-Дек-23, (124)   1 quic написан гуглом ровно для того чтобы пихать рекламу потребителям, и не ва, Ivan_83 (ok), 12:38 , 18-Дек-23, (174) –1   Видите, как мало вы знаете о мире К сожалению, сидят-сидят DNS комфортно и не , Аноним (26), 13:06 , 18-Дек-23, (179)   Угомонись уже Никак этот твой QUIC не поможет в борьбе с потерями, т к в серве, timur.davletshin (ok), 15:53 , 18-Дек-23, (189)   Я вижу у вас какой то свой мирок с плохим инетом и последней надеждой на чудо-гу, Ivan_83 (ok), 00:55 , 19-Дек-23, (205)   Ахаха нет DPDK не просто так появился , Ананимус (?), 00:43 , 18-Дек-23, (112)   DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать углы ч, Ivan_83 (ok), 00:59 , 19-Дек-23, (206)   Ага Потому что тот стек, что есть в линуксе, он даже близко не оптимальный , Ананимус (?), 21:18 , 19-Дек-23, (222)   Есть ещё сетевухи с аппаратным не совсем TCP и tls, что неплохо разгружает ОС в, Аноньимъ (ok), 03:25 , 18-Дек-23, (121)   Всегда будет нужно только открыть сокет и писать аналогом write независимо от то, all_glory_to_the_hypnotoad (ok), 05:02 , 18-Дек-23, (127)   // Далеко не только Там есть MASQUE extension, DATAGRAM extension , Аноним (26), 06:05 , 18-Дек-23, (131)   Ещё хуже Теперь всё гоняем по http Через один порт Смысл в остальных портах п, pda (ok), 15:23 , 17-Дек-23, (41) –1   // А куда ты денешься Хоть туда, хоть не туда , Аналоговнет (?), 15:36 , 17-Дек-23, (43)   UDP применяется из-за шифрования а не размера пакета и подтверждения как можно , Аноним (40), 15:34 , 17-Дек-23, (42)   // А TCP шифровать низя , Ivan_83 (ok), 16:10 , 17-Дек-23, (52) +1   // А зачем Вы по моему не понимаете разницу между TCP и UDP раз задаёте такой прос, Аноним (67), 18:16 , 17-Дек-23, (67) –1   Забыл дописать про UDP https ru wikipedia org wiki UDPUDP использует простую , Аноним (67), 18:41 , 17-Дек-23, (69) –2   Ну или проще - вам предлагают кастрюлю с американской лапшой вместо крутых яиц и, Аноним (67), 18:47 , 17-Дек-23, (70) –2   Так это вы написали UDP применяется из-за шифрования вот и поясните что не та, Ivan_83 (ok), 21:25 , 17-Дек-23, (90) +6   Всё у вас смешалось, кони, люди Давайте по пунктам 1 В сетях Ethernet по умол, Аноним (79), 20:02 , 17-Дек-23, (79) +2   // 1 В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адапт, Ivan_83 (ok), 21:36 , 17-Дек-23, (91) +1   // И работает так прилетает pause frame и передача всего трафика на порту, куда фр, Аноним (93), 22:06 , 17-Дек-23, (99)   Я немного уточню ваш ответ, с вашего позволения Ну только если брать свежайшие, Аноним (79), 23:39 , 17-Дек-23, (105) +2   При помощи магии что ли Нет Это требует обязательной настройки QoS, потому что, Аноним (79), 01:11 , 18-Дек-23, (115)   да, я про него Даже как то пробовал его для DoS у себя в домашней локалке но чт, Ivan_83 (ok), 01:46 , 18-Дек-23, (118) –1   А вы там точно сетью занимались Просто каждый провайдер меняет входящую пометку, Аноним (79), 11:37 , 18-Дек-23, (168)   Забавно как вы обобщаете Провайдеры если и заморачиваются QoS то обычно это PC, Ivan_83 (ok), 12:30 , 18-Дек-23, (172)   так что в сухом остатке есть у нас RFC 3168 2001 , согласно которому ECN allow, крокодил мимо.. (?), 14:52 , 18-Дек-23, (187)   RPC бывает разный и в большинстве случаев с ним таких проблем нет За многие год, all_glory_to_the_hypnotoad (ok), 05:19 , 18-Дек-23, (128)   // Всё что вы сказали - всё правда А потом пришел транспорт QUIC и решил эту пробле, Аноним (79), 12:09 , 18-Дек-23, (169)   Что то я не припоминаю никаких API для TLS со стороны ядра в венде Может где то, Ivan_83 (ok), 12:43 , 18-Дек-23, (177)   SIP - это как бы на udp работает, как правило , Аноним (82), 20:10 , 17-Дек-23, (82)   Дfвайте всё гонять по HTTP, а HTTP гонять по UDP, Tishka17 (?), 23:52 , 17-Дек-23, (107) –1   внуки наши скажут - дед, ты офигел ssh2 юзать - ssh3 деплоится с клавиатуры одно, cloudchief (ok), 12:24 , 17-Дек-23, (14) +6 // Это же какой там уровень радиации что можно спокойно нажать F283 , Аноним (68), 18:33 , 17-Дек-23, (68) +2 // там всё просто - размер клавиатуры , cloudchief (ok), 19:21 , 17-Дек-23, (74) 1 неотличимость от h3-сервера будет только при наличии сертификата, признаваемо, Аноним (16), 12:26 , 17-Дек-23, (16) +3 // По пункту 3, у вас тогда процессы будут работать под юзером www, что редко когда, Аноним (26), 13:41 , 17-Дек-23, (30) +1 // Не проблема, вместо пользовательской команды напрямую можно вызывать любой друго, Аноним (32), 13:52 , 17-Дек-23, (32) // Вы можете сейчас пробросить TCP-порт через QUIC Тогда ssh-клиент будет подключа, Аноним (26), 17:47 , 17-Дек-23, (66) То есть, был у нас серт ssh, а теперь его будет выдавать регистратор, который од, Аноним (-), 09:32 , 18-Дек-23, (142) –3 Как он мультиплексируется с существующим сервером на 443 портом и сайтами на не, Аноним (17), 12:29 , 17-Дек-23, (17) Интересно С модным QUIC станут ли файлы через всякое SCP передаваться с нормаль, Аноним (22), 13:07 , 17-Дек-23, (23) // Да оно и сейчас нормально передается, если у тебя не 100 Гбп сНу а то что scp в , Anononononon (?), 20:52 , 17-Дек-23, (86) Пакет OpenSSH можно ставить одним из первых А тут зависимостей гораздо побольше, Аноним (24), 13:10 , 17-Дек-23, (24) // ldd ssh3 not a dynamic executable, OpenEcho (?), 19:20 , 17-Дек-23, (73) –1 // Хотя с сервером, - да, завязались на миньёны, OpenEcho (?), 20:20 , 17-Дек-23, (83) Тебе дае сказали написано на Goвне, Аноним (203), 22:05 , 18-Дек-23, (203) // Дык ить в последнее время всё стоящее в основном на нём и пишут , _ (??), 01:42 , 19-Дек-23, (209) +1 Я не фаловер, принимаю решения - по факту, а не по тренду, хотя и тренд по ходу , OpenEcho (?), 07:10 , 22-Дек-23, (230) Какой-такой первый Уже был ietf rfc https datatracker ietf org doc draft-bi, Аноним (26), 13:31 , 17-Дек-23, (27) // https bugzilla mindrot org show_bug cgi id 3471Собственно, ссылка , Аноним (26), 13:32 , 17-Дек-23, (28) Не взлетит , An (??), 14:20 , 17-Дек-23, (33) // скорее аукнется боком, ёж-уж, Sw00p aka Jerom (?), 14:55 , 17-Дек-23, (35) Скрыто модератором, Аноним (34), 14:47 , 17-Дек-23, (34) –1 // Скрыто модератором, Аналоговнет (?), 15:42 , 17-Дек-23, (44) Крч, группка теоретиков что-то там себе напроектировала, без оглядки на реальную, Аноним (36), 14:56 , 17-Дек-23, (36) +1 // Ничего так теоретик , Второй из Кукуева (?), 09:28 , 19-Дек-23, (216) Неплохо, посмотрим как на деле будет , svsd_val (ok), 14:57 , 17-Дек-23, (38) // Как земля Для всех буквально пользователей ssh оно нафиг ненужно Пригодиться мож, Аноньимъ (ok), 15:47 , 17-Дек-23, (46) –2 Да, это класс Мда А без http уже никак дополнительный возможности не реализова, Аноньимъ (ok), 15:44 , 17-Дек-23, (45) // Ну по поводу авторизации было написано в документе U S Department of Defense Ze, Аноним (49), 15:56 , 17-Дек-23, (49) –2 да, какие проблемы, трепло , Аноним (151), 10:15 , 18-Дек-23, (151) +2 // Всегда мечтал об ssh сервере на который нельзя зайти если у кого-то из сторонних, anonymous (??), 16:43 , 18-Дек-23, (194) –2 Из новости я так и не понял какое это всё имеет отношение к SSH Если следовать, Ivan_83 (ok), 15:57 , 17-Дек-23, (50) SSH over HTTPS Ну что, смузихлёбненько , Аноним (54), 16:26 , 17-Дек-23, (54) +1 telnet всех переживет , microsat (?), 16:51 , 17-Дек-23, (55) +1 // telnet, также как http, безопасники давно побанили во всех более-менее серьезных, Аноним (198), 17:30 , 18-Дек-23, (198) // Всё новое не обеспечение безопасности Как секюретник вам говорю А забытое , microsat (?), 19:11 , 19-Дек-23, (220) Невекторный гипертекстовый ССШ Ну, слушать порт ССЛ - это прям очень круто Тол, InuYasha (??), 19:16 , 17-Дек-23, (72) // Good luck , OpenEcho (?), 19:30 , 17-Дек-23, (77) Я в своё время, ещё в 90х наверное, видел на пиратке компакт-диск на которм была, cloudchief (ok), 19:26 , 17-Дек-23, (75) // взбунтовались со своим ALPN TLS чота все, как кусок олдовой логики вкину вам ста, Anononononon (?), 21:00 , 17-Дек-23, (87) // Брат - я очень хорошо понимаю контрол-плейн и дата-плейн, давай без этого , cloudchief (ok), 00:40 , 18-Дек-23, (110) // А я очень хорошо понимаю, почему эта поделка ненужна, и что давай без своего к, Anononononon (?), 15:12 , 18-Дек-23, (188) Иногда складывается ыпечатление что протоколы отличные от HTTP канут в лету и вс, Аноним (78), 19:51 , 17-Дек-23, (78) +1 // А что в этом плохо , cloudchief (ok), 00:41 , 18-Дек-23, (111) // Плохого в этом оверхед и невозможность сколько-либо работать без библиотек http,, Аноним (-), 09:29 , 18-Дек-23, (141) HTTP сложный и неудобный протокол, ничего такого не будет только если не придётс, all_glory_to_the_hypnotoad (ok), 05:41 , 18-Дек-23, (130) +2 Но QUIC вообще не HTTP Вообще ничем не похож Я бы сказал - он полная противопо, Sem (??), 07:07 , 23-Дек-23, (234) Все б ничего, но весь смак Го сломали с unsafe и Import C в сервере , OpenEcho (?), 20:06 , 17-Дек-23, (80) +1 А скачать большой файл можно будет 150Гб Меня когда дядя Гугль выставлял на мо, Аноним (94), 21:56 , 17-Дек-23, (94) +1 Не знаю зачем это вообще всё нужно Telnet на 110 справляется со своими задачам, Аноним (95), 21:58 , 17-Дек-23, (95) +2 // Я SSH использую как VPN , Ivan_83 (ok), 01:48 , 18-Дек-23, (119) // А он VPN использует как SSH D, InuYasha (??), 11:15 , 18-Дек-23, (163) // Скрыто модератором, Аноним (-), 05:17 , 19-Дек-23, (215) Скажи это тысячам ботов, долбящихся по SSH на любой внешний IP , Пряник (?), 09:40 , 18-Дек-23, (145) Не вижу в этом ничего плохого Если зайдёт - вы потом датаплейном будете хвалит, cloudchief (ok), 00:45 , 18-Дек-23, (113) –1 Самое хреновое - это оставаться на ровной жопе Не движешься - ты в дроп, ну или, cloudchief (ok), 00:51 , 18-Дек-23, (114) Go Очень жаль Ф топку Идея классная, поэтому ждём реализации на Си , Имя Моё (?), 02:57 , 18-Дек-23, (120) +2 // На Си , Аноним (26), 04:21 , 18-Дек-23, (125) // Нет Вот почему https www google com search q c 252B 252B vs c performance, Имя Моё (?), 19:21 , 18-Дек-23, (199) –1 Заодно и увидим, что в их представлении эталон , Пряник (?), 09:38 , 18-Дек-23, (144) Этого стоило ожидать при чтении HTTP HTTP Go Stop working, have a REST Сов, InuYasha (??), 11:17 , 18-Дек-23, (164) На этом сайте мюсамое большое собрание нытиков Рунета Чувак просто написал дипл, Анонимщик (?), 06:08 , 18-Дек-23, (132) +2 // Чувак лишь исполнитель и кодер прототипа, проект двигает Olivier Bonaventure, ко, Аноним (2), 07:56 , 18-Дек-23, (133) // У вас реально работает mptcp Да ну, расскажите , Аноним (26), 08:16 , 18-Дек-23, (135) +1 Если бы он назвал его hssh - было бы ничего, а он замахнулся закопать ssh2 , Аноним (-), 09:28 , 18-Дек-23, (140) –3 // додододо, проблема именно в названии, а не тотальном лицемерии местных д3генерат, Аноним (151), 10:24 , 18-Дек-23, (154) +6 Сетевые протоколы свернули не туда , Аноним (136), 09:04 , 18-Дек-23, (136) –2 Скрыто модератором, Аноним (-), 09:27 , 18-Дек-23, (139) +1 Жесть Предлагается сделать веб-сервер точкой входа администратора сервера Или , Пряник (?), 09:53 , 18-Дек-23, (148) // Господи, каким местом вы читаете Каким думаете , Sem (??), 07:11 , 23-Дек-23, (235) // А ты не понял На 80 и 443 порту будет висеть и принимать SSH3 соединения один п, Пряник (?), 11:59 , 25-Дек-23, (236) http под root Ну успехов , nox. (?), 10:09 , 18-Дек-23, (149) –1 // в чем проблема , Аноним (160), 10:44 , 18-Дек-23, (160) +1 // вотименна Диды в DOS сидели с полными правами и ничего , 1 (??), 11:29 , 18-Дек-23, (166) –2 // нет связи, http сам по себе ничем не хуже в плане безопасности, чем сырые сокеты, Аноним (181), 13:12 , 18-Дек-23, (181) +2 Как фаерволить этот трафик Отделить админов от веб пользователей В Энтерпрайзе, Дмитрий (??), 08:49 , 20-Дек-23, (223) Просто проект с модным названием и с таким же успехом mosh https github com mo, keydon (ok), 10:33 , 18-Дек-23, (155) +1 А также приём запросов SSH на 443 сетевом порту HTTPS затрудняет приём запро, rvs2016 (ok), 16:11 , 18-Дек-23, (190) // Да легко ssl_preread, дальше мап по версии тлс, если версии нет - отдаём в прило, Ivan_83 (ok), 01:06 , 19-Дек-23, (207) А разве SSH не стандартизован Ну то есть разрабатывать его должна рабочая групп, Аноним (198), 17:21 , 18-Дек-23, (196) // этот дьякон стоит нескольких твоих рабочих групп, Аноним (202), 20:45 , 18-Дек-23, (202) –1 Очень сомнительно Если цель действительно скрыться, то надо использовать Plugga, uis (??), 20:39 , 19-Дек-23, (221) // согласен, но зачем называть порнографией если не стоит задачи скрываться, swarus (ok), 14:50 , 21-Дек-23, (226) Попробовал Совсем сыро, на уровне прототипа Плюс, в текущей реализацией плохо , Sem (??), 20:33 , 21-Дек-23, (227) +2 // Ну концепт интересный потом кто серьезный может перепишет на Rust, Аноним (232), 03:36 , 23-Дек-23, (232) // Да, желательно сделать так, чтобы шансов взлететь у этого в принципе не было , Аноним (237), 20:53 , 26-Дек-23, (237) 1,4,5,6,7,10,14,16,17,23,24,27,33,36,38,45,50,54,55,72,75,78,80,94,95,113,114,120,132,136,148,149,155,190,196,221,227

Сообщения

[Сортировка по времени | RSS]

10. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–6 +/–
Сообщение от EuPhobos (ok), 17-Дек-23, 12:17
Теперь ssh гоняем по UDP, а давайте вообще отменим TCP и всё будем гонять по UDP, зачем нам приоритеты трафика, какие-то там sip-звонилки, онлайн игрушки, правильно я понимаю?
Ответить | Правка | Наверх | Cообщить модератору

	12. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+9 +/–
	Сообщение от Ананимус (?), 17-Дек-23, 12:20
	QUIC это тот же TCP, просто вся логика на уровне выше, что позволяет сделать кучу кейсов, которых не было при проектировании TCP, из коробки.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Ivan_83 (ok), 17-Дек-23, 15:51
	Вася это Петя, просто имя другое.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+1 +/–
	Сообщение от timur.davletshin (ok), 17-Дек-23, 19:29
	Для этого надо на стороне клиента установить софт... что в общем случае не очень сильно проще установки tcp_supper_algo.ko. QUIC пока что ничего такого не умеет, что было обещано изначально в категории "преимущества перед TCP" (сколько реализаций умеют multipath?). По факту юзаем, но на производительности серверов тех же он сказался негативно. По факту вынесли алгоритм, требующий фиксированного времени отклика (практически реального времени), в пространство пользователя. Я напомню, что основная критика в адрес OpenVPN, который делает то же самое управление потоком и шифрование поверх UDP, заключалась в том, что он реализован в пространстве пользователя и поэтому медленный. Я запутался. Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	81. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от Аноним (26), 17-Дек-23, 20:07
	>Помогите, почему в одном случае вынос в ядро является благом, а во втором злом? Потому что openvpn не знает, что он передаёт, и потому не может дропать фреймы, а браузер знает, что он передаёт видео.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 18-Дек-23, 00:31
	> Для этого надо на стороне клиента установить софт... что в общем случае не очень сильно проще установки tcp_supper_algo.ko. Чтобы сходить в интернет через tls тебе нужен  openssl, ca-certificates и еще куча срани. Так что ничего особо нового тут не появилось. >QUIC пока что ничего такого не умеет, что было обещано изначально в категории "преимущества перед TCP" (сколько реализаций умеют multipath?). Все rfc-compliant. > Я запутался. Помогите, почему в одном случае вынос в ядро является благом, а во втором злом? Не вижу проблемы затолкать quic в ядро. Это будет как sctp, тока на этот раз его кто-то поддержит.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	116. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ivan_83 (ok), 18-Дек-23, 01:20
	Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 18-Дек-23, 09:20
	> Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы. Роутеры и коммутаторы тоже ходят в интернет, там тоже есть целый ворох библиотек и сертификаты. Я не понимаю что ты пытаешься доказать. Что положить сишную либу размером в пару килобайт это проблема? Нет, это не проблема. Нигде, даже в embedded.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от timur.davletshin (ok), 18-Дек-23, 09:44
	Разупорись, какие пару килобайт? Вы давно размер бинарников этих ваших lib*ssl.so видели? Сертификаты обновлять нужно. Плюс, маленький секрет, есть масса крупных сетей, в которых нет выхода в Интернеты по соображениям безопасности.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 18-Дек-23, 12:38
	> Разупорись, какие пару килобайт? Вы давно размер бинарников этих ваших lib*ssl.so видели? > Сертификаты обновлять нужно. Плюс, маленький секрет, есть масса крупных сетей, в > которых нет выхода в Интернеты по соображениям безопасности. Ну не суй эту библиотеку туда, где не нужен выход в интернет :D
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от timur.davletshin (ok), 18-Дек-23, 12:59
	> Ну не суй эту библиотеку туда, где не нужен выход в интернет > :D Будто я все прошивки сам делаю и OpenWrt уже готов для работы с трафиком небольшого провайдера.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от Ананимус (?), 18-Дек-23, 13:45
	>> Ну не суй эту библиотеку туда, где не нужен выход в интернет >> :D > Будто я все прошивки сам делаю и OpenWrt уже готов для работы > с трафиком небольшого провайдера. Тогда чего ты переживаешь? Мейнтейнеры все положат.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от timur.davletshin (ok), 18-Дек-23, 14:35
	> ... мейнтейнеры все положат. Если бы они туда ложЫли, то я бы не переживал.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ivan_83 (ok), 18-Дек-23, 12:33
	Я пытаюсь сказать что TLS, рабочая инфраструктура сертификатов и даже правильно выставленное время не очень то и нужны много где, учитывая что есть более простые и более легковесные решения. И это, вы попробуйте в 8мб флеша собрать OpenWRT с этим всем, потому что там задолбались и выкинули все такие устройства :)
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	175. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 18-Дек-23, 12:38
	> Я пытаюсь сказать что TLS, рабочая инфраструктура сертификатов и даже правильно выставленное > время не очень то и нужны много где, учитывая что есть > более простые и более легковесные решения. > И это, вы попробуйте в 8мб флеша собрать OpenWRT с этим всем, > потому что там задолбались и выкинули все такие устройства :) Ну вот OpenWRT: # du -sh /usr/lib/libssl.so.1.1 524.0K    /usr/lib/libssl.so.1.1
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (100), 17-Дек-23, 22:15
	Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcongestion control и как его применять?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	108. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 18-Дек-23, 00:27
	> Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcongestion control и как его применять? Его нет на уровне UDP, это вынесено на уровень самого QUIC. А дальше открываешь rfc и вперед.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+1 +/–
	Сообщение от Аноним (100), 18-Дек-23, 01:39
	Дальше следующий вопрос возникает. Как мне ограничения сделать и разные congestion control на разный трафик? Именно как мне угодно на сервере, клиенте, промежуточном оборудовании? Можно пальчиком показать что трафик обновлений пускаем только на свободную полосу в данный момент, воип максимум быстро пропускаем, а оставшийся хттп не критичен к задержкам и его просто надо доставлять.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 18-Дек-23, 05:38
	Я не настоящий сварщик, но можешь попробовать примерно так: Во-первых, пускаешь процессы в нужной net_prio cgroup. Это должно правильно приоритизировать пакеты "локально". Во-вторых, пускаешь процессы в правильной net_cls cgroup, и через nftables выставляешь нужным процессам правильный DSCP код, и на свитчах-роутерах говоришь, каким flow с каким dscp выдавать больший приоритет. Поскольку quic шифрован, нельзя выдать разный приоритет разным quic flow, поэтому нужно будет открывать разный flow на разные приоритеты, но по идее, это не проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 18-Дек-23, 08:12
	В смысле, разным connect, а не разным flow, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от timur.davletshin (ok), 18-Дек-23, 09:46
	Кто как хочет, так и ... скачет. У всех свой велосипед придуман. За основу обычно берут стандартные Reno и Cubic. Только у bittorrent обычно LEDBAT (поправьте, если ошибся набором букв), а у VoIP вообще оригинальный велосипед.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	15. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+3 +/–
	Сообщение от Аноним (15), 17-Дек-23, 12:24
	> а давайте вообще отменим TCP и всё будем гонять по UDP А давайте. Все к этому и идет. > зачем нам приоритеты трафика, какие-то там sip-звонилки, онлайн игрушки, правильно я понимаю Неправильно. Никто не мешает настроить приоритеты для различных UDP-потоков.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	152. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от 1 (??), 18-Дек-23, 10:18
	> Неправильно. Никто не мешает настроить приоритеты для различных UDP-потоков. И как будешь различать "UDP-потоки" ? По IP ?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 18-Дек-23, 11:26
	По source порту.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Анонус (?), 17-Дек-23, 13:04
	> sip-звонилки Голосовой трафик и так по UDP ходит. А по стандарту можно и SIP over UDP настраивать.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	29. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Аноним (26), 17-Дек-23, 13:39
	Ты "почти" всё правильно понимаешь. Контроль потока на уровне ядра ОС был вынужденной мерой, когда хотелось просто открыть сокет и писать данные с помощью С write(). Это неплохо работало как переходная мера, когда большая часть подключений была десктоп-десктоп или десктоп-сервер, по надёжным каналам с маленькой задержкой. Сейчас мир другой, и "прозрачная" (но дырявая) TCP абстракция "надёжного сокета" перестала отвечать реальности.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	37. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (37), 17-Дек-23, 14:56
	Спрошу тебя как эксперта по TCP. Почему TCP (или его преемник) не реализован просто как надстройка над UDP? Ну то есть вот есть IP, UDP к нему добавляет порты. TCP к IP добавляет порты + машину состояний + поля для синхронизации машин состояний приёмника и передатчика. Таким образом получается, что функциональность TCP есть надмножество функциональности UDP. Перепроектирование TCP поверх UDP (назовём его TCP/UDP) позволит выбирать, где обрабатывать TCP/UDP-соединения, в юзерспейсе или в ядре. Структура пакета почти та же, только без портов, за которые уже UDP-слой отвечает. Какой именно протокол слушается на порту - определяется открытым сокетом. Открывается TCP/UDP сокет - он ведёт себя как TCP, открывается UDP-сокет - машину состояний реализует сам процесс. Поскольку это UDP, то никаких особых привилегий, как для отправки сырых IP пакетов, процессу не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 17-Дек-23, 17:25
	QUIC по большому счёту и является перепроектированием TCP поверх UDP. Если его "наивно" использовать, то там все те же параметры, что и для контроля потока TCP и используются, и даже те же самые алгоритмы контроля congestion: cubic, bbr. И за порты там UDP и отвечает. В этом смысле система "практически" обратно совместима, с точки зрения "открыть сокет и писать". Собственно, библиотека QUIC не зря называется ngTCP2. Естественно, при этом радость от QUIC не очень велика, хотя уже приятно, что можно выставлять некоторые флаги самому. Что больше радует -- это что можно установить изначальное соединение "по tcp2", вести "сигнальный канал" с сохранением надёжности (но медленно), но параллельно открыть DATAGRAM-канал, и по нему уже слать данные с собственной коррекцией ошибок (или без неё). А для внешнего наблюдателя это всё равно будет всего-навсего "зашифрованный UDP поток". Почему так было не сделано "давно"? Не знаю, я тогда не жил, но тогда казалось, что "правильная абстракция" -- это "номер протокола IP". В /etc/protocols куча всяких древних стандартов перечисленно. В каком-то смысле это казалось логичным -- ведь если какая-нибудь "фича" реализовывалась на уровне "системных протоколов", как, например, ipsec, то она "автоматом" распространялась на все протоколы уровнями выше, независимо от того, был там контроль доставки, или не было, были порты, или не было.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (39), 17-Дек-23, 15:09
	Также спрошу, почему-бы не сделать TLS без портов вообще, раз только 443 используется. Вместо порта выбирать сервис по ключу через Diffie-Hellman. Ну в server hello сервер может анонсировать, какие у него есть сервисы. Клиент выполняет диффи-хэллмана, выведенный ключ хэширует той же функцией, что и в сертификате, после чего от хэша берёт остаток от деления на (количество сервисов + 1). Остаток даёт номер сервиса. Если номер сервиса не тот, что нужен - повторить. Сервер делает то же самое с выведенным ключом. Только без брутфорса.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	62. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 17-Дек-23, 17:30
	Тебе никто не мешает так сделать. Вернее, сейчас вообще так и делается, только без всякого Диффи-Хеллмана. Есть websocket. Подключаешься по https к https://webservice.com/service-name/, service-name пробрасывает websocket, и по этому websocket пиши что хочешь, он шифрован TLS-ом.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Ivan_83 (ok), 17-Дек-23, 16:08
	Вы себе и близко не представляете что такое современный TCP. Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально. 5 строчек в приложении, 8кб скомпиленый бинарник и оно уже работает. Извращенцы даже из баш скриптов научились этим напрямую пользоватся. Что бы вы там в юзерспейсе не нагородили оно всегда будет жрать больше ресурсов и работать лучше не станет. Задержки при старте - ну это такое, сильно на любителя. У TCP для этого тоже есть много разного. Единственно что реально получилось улучшить это DTLS за счёт прибивания на гвозди размеров пакетов и выраснивания по размеру блоков алгоримов шифрования.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	64. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+1 +/–
	Сообщение от Аноним (26), 17-Дек-23, 17:36
	>Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально. Невозможно "оптимально" реализовать работу TCP на канале с потерями 80%. А мобильные каналы и замусоренный wifi так и выглядят. Просто невозможно и всё. Не существует "надёжного" канала, который будет работать нормально на таких потерях, потому что не существует единого способа определить, надо ли пакет ретрансмитить или дропать, без знания контекста приложения. Если ваш поток -- видео, например, с камеры наблюдения, вы можете пренебречь потерями, заполняя видео старыми кадрами, и ничего не потеряете. Если вам нужно передавать ssh, вы очень не хотите терять никаких команд, даже если пинг вырастет до 15 секунд. Операционная система этого не знает, и знать никогда не будет. Контроль потерь должен осуществляться на самом высоком уровне стека, по сути, на прокладке между креслом и монитором. Готов юзер терпеть потери, или нет.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Ivan_83 (ok), 17-Дек-23, 21:23
	1. каналы у которых 80% - не рабочие, в принципе. 2. в дикой природе это скорее исключение 3. есть всякие RTSP/RTMP для видео и звука, и даже HLS делает примерно тоже самое по TCP. 4. Приложений с описанной вами логикой работы по UDP я что то не видел :)
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 18-Дек-23, 03:59
	1. Вы считаете, что нерабочие, и ничего не делаете, а другие люди пишут quic. 2. Миллиарды людей сидят через каналы с десятками процентов потерь, но хотят смотреть тикток. 3. Есть, но хочется открывать единственный сокет, и всё передавать через единственное соединение, не разводя зоопарк протоколов. A HLS такая, ну, кривоватая штука. 4. Откуда вы знаете? Если у вас канал нормальный, скорее всего, вам и не требуется quic, и софт его никогда не включает.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от Ivan_83 (ok), 18-Дек-23, 12:38
	1. quic написан гуглом ровно для того чтобы пихать рекламу потребителям, и не важно посмотрят они её или нет, главное что деньги гугл за показ спишет. 2. Не сидят, не нужно сочинять. С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет. 3. Вам хочется - вы и прогайте. ) 4. Покажите примеры за пределами гугла где это используется.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 18-Дек-23, 13:06
	>С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет. Видите, как мало вы знаете о мире. К сожалению, сидят-сидят. DNS комфортно и не работает (тем более что ещё и фильтруется) поэтому китайские приложения обновляются раз в неделю, заодно таская с собой кэш dns. Quic не в последнюю очередь как раз и сделан Google чтобы (а) обходить блокировки КНР, (б) сервить контент с серверов в Гонконге и США через полтора полудохлых канала, намертво перегруженных с потерями.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от timur.davletshin (ok), 18-Дек-23, 15:53
	> сервить контент с серверов в Гонконге и США через полтора полудохлых канала, намертво перегруженных с потерями. Угомонись уже. Никак этот твой QUIC не поможет в борьбе с потерями, т.к. в серверных реализациях New Reno и Cubic почти что у всех. Более того, в QUIC отдаётся Гуглом далеко не весь контент даже на страничке YouTube, для которого якобы и делался. Попробуй уже включить мозг и поразмыслить, почему HTML Google отдавать предпочитает по HTTP/2... Более того, всякие там ТВ, как правило (Самсунги там всякие, ЛыЖи и прочая) юзают исключительно HTTP/2 и, OMG, HTTP 1.1.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ivan_83 (ok), 19-Дек-23, 00:55
	Я вижу у вас какой то свой мирок с плохим инетом и последней надеждой на чудо-гуглаг. Примеры софта будут?
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	112. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 18-Дек-23, 00:43
	> Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально. Ахаха нет. DPDK не просто так появился.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	206. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ivan_83 (ok), 19-Дек-23, 00:59
	DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать углы чтобы получить нужную производительность.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ананимус (?), 19-Дек-23, 21:18
	> DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать > углы чтобы получить нужную производительность. Ага. Потому что тот стек, что есть в линуксе, он даже близко не оптимальный.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноньимъ (ok), 18-Дек-23, 03:25
	Есть ещё сетевухи с аппаратным(не совсем) TCP и tls, что неплохо разгружает ОС в определённых задачах.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	127. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 18-Дек-23, 05:02
	Всегда будет нужно только открыть сокет и писать аналогом write независимо от того, какой мир. Потому что это просто и удобно и большего в приложении не нужно. Кроме того сокетный интерфейс предоставляет кучу ядерных оптимизаций. Когда QUIC взлеит, то и его завернут в обыкновенный сокетный интерфейс. QUIC в конце концов точно такой же надёжный TCP сокет. Реализация находится в юзер спейсе через UDP вовсе не потмоу, что появилось какое-то волшебное управление потоком, а только лишь из-за экспериментального состояния самого протокола и желания побыстрей начать его использовать. Финальная ядерная версия для всех скорее всего будет уже не на UDP, UDP здесь от ~нищеты.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	131. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (26), 18-Дек-23, 06:05
	>QUIC в конце концов точно такой же надёжный TCP сокет. Далеко не только. Там есть MASQUE extension, DATAGRAM extension.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от pda (ok), 17-Дек-23, 15:23
	Ещё хуже. Теперь всё гоняем по http. Через один порт. Смысл в остальных портах продолжает падать. Технологии куда-то не туда свернули...
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	43. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аналоговнет (?), 17-Дек-23, 15:36
	А куда ты денешься? Хоть туда, хоть не туда.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (40), 17-Дек-23, 15:34
	UDP применяется из-за шифрования (а не размера пакета и подтверждения как можно подумать). Вы и так можете подтвердить приём пакета отправив обратно другой пакет. Вероятнее всего новое оборудование будет отличать разные типы новых протоколов, так-что у таких пользователей с приоритетом трафика ничего не будет. А на старом, оставляете HTTP/TCP более приоритетным и все будет норм с приоритетом http я лично думаю что долгое время.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	52. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+1 +/–
	Сообщение от Ivan_83 (ok), 17-Дек-23, 16:10
	А TCP шифровать низя?)
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от Аноним (67), 17-Дек-23, 18:16
	А зачем? Вы по моему не понимаете разницу между TCP и UDP раз задаёте такой простой вопрос. Читаем обычную, даже не специализированную, википедию: https://ru.wikipedia.org/wiki/TCP Механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым (в отличие от UDP) целостность передаваемых данных и уведомление отправителя о результатах передачи. Когда осуществляется передача от компьютера к компьютеру через Интернет, TCP работает на верхнем уровне между двумя конечными системами, например, браузером и веб-сервером. TCP осуществляет надёжную передачу потока байтов от одного процесса к другому. Ну и если очень надо, там дописано что для прозрачного шифрования данных предлагается использовать расширение tcpcrypt.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–2 +/–
	Сообщение от Аноним (67), 17-Дек-23, 18:41
	Забыл дописать про UDP: https://ru.wikipedia.org/wiki/UDP UDP использует простую модель передачи, без явных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных. т.е. UDP не обеспечивает надёжность и целостность передачи данных. Вы один запрос делаете в одну сторону и асинхронно обратно другой запрос UDP получите в другую. В отличии от TCP, который сделает внутри тоже самое, только одним запросом обеспечит надежность. И вот UDP в этом плане выигрывает в скорости, но проигрывает в надёжности. Так вот надёжность добавляет шифрование, т.к. прячет данные от мониторинга и MITM, если вы не владелец (американского) реестра сертификатов.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–2 +/–
	Сообщение от Аноним (67), 17-Дек-23, 18:47
	Ну или проще - вам предлагают кастрюлю с американской лапшой вместо крутых яиц из которых могут вырваться птицы гордо воспарив над интернетом, порождая свои идеи. Вы бы хоть пообсуждали необходимость создания локального реестра сертификаций, если настолько неспособны программировать и создавать железо.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+6 +/–
	Сообщение от Ivan_83 (ok), 17-Дек-23, 21:25
	Так это вы написали: "UDP применяется из-за шифрования" вот и поясните что не так с TCP в этом плане.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	79. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Аноним (79), 17-Дек-23, 20:02
	Всё у вас смешалось, кони, люди... Давайте по пунктам: 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 это всё и сделал. Ничего плохого в этом нет.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	91. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+1 +/–
	Сообщение от Ivan_83 (ok), 17-Дек-23, 21:36
	1. В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адаптерами и свичами, аппаратно. Я не вдавался в его работу но сомневаюсь что всё вами перечисленное нужно. Насколько я вникал при перегрузке получатель отправляет сообщение отправителю с просьбой помолчать немного. 2. "TCP - это протокол для потоковой передачи данных сквозь широкополосную сеть с большими задержками." - а причём тут задержки?! 3. "TCP постоянно теряет пакеты, это норма" - а причём тут TCP!? "TCP не просто может восстановить потерянные данные в потоке, а то что на самом деле он растит пропускную способность пока не начнутся потери и потом её снижает на основании получения запроса на Retransmit. По умолчанию он так управляет потоком. TCP сейчас использует CUBIC для контролирования пропускной способности и очередную вариацию slow start чтобы начать соединение." - я бы на вашем месте не пытался даже словами описать что там происходит, потому что даже CUBIC чуть сложнее, а уж мой любимый RACK и подавно. "Он считает, что раз потери - значит перегрузка. А бывает так, что потери - проблема с уровнем сигнала." - это сильно зависит от используемого СС. Вы плохо понимаете суть, но предлагаете такие глобальные изменения. У вас и UDP тормозить будет :)
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (93), 17-Дек-23, 22:06
	> В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адаптерами и свичами, аппаратно. И работает так: прилетает pause frame и передача всего трафика на порту, куда фрейм прилетел, встаёт. Потому его первым делом везде отключают, где он по каким-то причинам включен по-умолчанию, чтобы сеть при перегрузке не переходила в старт-стоповый режим. Существует группа протоколов DCB, про которые говорил Аноним в сообщении выше, но они есть только на довольно дорогих энтерпрайзных железках, требуют конфигурирования квалифицированным сетевиком, а также требуют поддержки всей цепочкой прохождения трафика в L2-сегменте. В общем, DCB используют только когда ну прям очень надо и вышележащий протокол почему-то congestion control не поддерживает, а бесконтрольная перегрузка при этом крайне нежелательна. Примером такого протокола, является, например, ROCE v1 и v2 (RDMA поверх Ethernet-а).
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+2 +/–
	Сообщение от Аноним (79), 17-Дек-23, 23:39
	Я немного уточню ваш ответ, с вашего позволения... > довольно дорогих энтерпрайзных железках Ну только если брать свежайшие и супер крутые. А если надо дёшево, чтобы заработал 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, а это иногда, ох, как неудобно... Я просто из личной практики говорю... но в целом вы абсолютно правы.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (79), 18-Дек-23, 01:11
	> 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+ совместимы. =)
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	118. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от Ivan_83 (ok), 18-Дек-23, 01:46
	> 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 на фрю. У меня ничего хорошего не вышло, стёк фри не давал нужных возможностей, видимо поэтому нетфликс сделал не СС а целый стёк отдельный.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (79), 18-Дек-23, 11:37
	> Это ваши домыслы. > Я работал в провайдере и близок к кухням других провайдеров и никто > тамим не промышлял. > Если только сотовики и ещё некоторые отбитые на голову. А вы там точно сетью занимались? Просто каждый провайдер меняет входящую пометку 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 на коммутаторе. Уверен у вас получится. =)
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ivan_83 (ok), 18-Дек-23, 12:30
	> А вы там точно сетью занимались? Просто каждый провайдер меняет входящую пометку QoS на свою собственную. Забавно как вы обобщаете :) Провайдеры если и заморачиваются QoS то обычно это PCP, а DSCP они игнорят и пропускают. Некоторые вырезают, наверное. > Есть СС, которые применяются на всей цепочке. DCTCP в Lossless-сети - это главный из них и самый популярный. Так это не про интернет, а что там каждый у себя внутри городит мне мало интересно. > Неужели вы правда считаете, что нетфликс использует RACK-TLP для внутреннего обмена данными, для сетей хранения и всего такого? Да запросто. Они публиковали презентации как у них работает я там ничего такого не видел. Они писали про то что у них относительно медленно заливается на раздающие тазики, а с них в инет уже льётся по 100+ гигабит с каждого. Те может у них и есть всё то замечательное что вы описали но не похоже что для них это мастхэв фича. > обработка Selective ACK требует существенно больше ресурсов CPU отправителя Это просто смешно, по современным меркам. Какую то нагрузку на проц от сети можно заметить только на очень высоких PPS, это скорее для роутеров проблема которые TCP не разбирают чем для конечных хостов, у которых TCP обмазан аппаратными оффлоадами. > купите себе дешевый Juniper и пару сетевок Mellanox и поиграйте со всем этим. А зачем мне это?) Я не одмин датацентров и не хочу в эти технологии вляпыватся. И вы как то далеко ушли от реального мира где всех описанных вами технологий нет, а есть только СС отправителя и оно неплохо так работает. Как минимум 100м-1г оно утилизирует, а дальше и не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от крокодил мимо.. (?), 18-Дек-23, 14:52
	> Я не одмин датацентров и не хочу в эти технологии вляпыватся. так что в сухом остатке? есть у нас 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) - могут в очередную игрульку..
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 18-Дек-23, 05:19
	> RPC, удаленный вызов процедур порождает огромное количество соединений в которых служебных данных больше чем полезных. Если нет потока, то TCP мешает и лишний раз грузит ядро ОС глупым разбором заголовков. RPC бывает разный и в большинстве случаев с ним таких проблем нет. За многие годы существования сетей были разные попытки позаворвачивать RPC в UDP и никакие из них не были ощутимо лучше заворачивания в TCP. В основном только создавали дополнительный гемор с поддержкой сетевого стека в  пр-ве пользователя.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	169. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (79), 18-Дек-23, 12:09
	Всё что вы сказали - всё правда. А потом пришел транспорт QUIC и решил эту проблему. В Windows реализация QUIC находится на стороне ядра, TLS там исторически на стороне ядра. Нет никаких проблем. Что там в Linux с QUIC я не берусь судить, лучше вы мне расскажите.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Ivan_83 (ok), 18-Дек-23, 12:43
	Что то я не припоминаю никаких API для TLS со стороны ядра в венде. Может где то в http.sys и есть, но оно не для всех соединений применимо. В линухах и фре сейчас появился ядерный TLS, те он частично ядерный - весь хэндшейк обрабатывается приложением, а  шифрование в ядре. Для приложения это выглядит как обычный сокет к которому применимы все обычный сисколы, но требуется немного дополнительной обработки для чтения чтобы реагировать на TLS.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
	Сообщение от Аноним (82), 17-Дек-23, 20:10
	SIP - это как бы на udp работает, как правило.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	107. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	–1 +/–
	Сообщение от Tishka17 (?), 17-Дек-23, 23:52
	Дfвайте всё гонять по HTTP, а HTTP гонять по UDP
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема