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

"Представлен SSH3, вариант протокола SSH, использующий HTTP/3"	+/–
Сообщение от opennews (?), 17-Дек-23, 11:55
Доступен первый официальный выпуск экспериментальной реализации сервера и клиента для протокола 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.ru/opennews/art.shtml?num=60300
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от anonymos (?), 17-Дек-23, 11:55	–1 +/–
Я правильно понимаю, что теперь нужен  будет правильный сертификат, подписанный правильной конторой?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #31, #40, #143

2. Сообщение от Аноним (2), 17-Дек-23, 11:58	+11 +/–
Нет, можно использовать RSA  и EdDSA/ed25519 ключи от SSH или самоподписанные сертификаты  X.509.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от анон (?), 17-Дек-23, 12:03	+9 +/–
А кто запрещает использовать корпоративный центр сертификации или самоподписанные сертификаты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #61, #191

4. Сообщение от Аноним (4), 17-Дек-23, 12:04	+4 +/–
старО https://github.com/moul/quicssh (POC 4 years ago)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #228

5. Сообщение от Аноним (5), 17-Дек-23, 12:04	–8 +/–
В общем, ломают совместимость непонятно ради чего
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #204

6. Сообщение от Аноним (6), 17-Дек-23, 12:07	+/–
Расскажите пожалуйста как демоны SSH3 и, например, nginx решают между собой вопрос о том, кому принадлежит порт 443.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #11, #13, #18, #19, #22, #26, #47, #58, #123, #238

7. Сообщение от penetrator (?), 17-Дек-23, 12:11	+/–
Для шифрования канала связи в SSH3 задействован протокол TLS 1.3, а для аутентификации могут использовать классические методы на базе паролей и открытых ключей (RSA и EdDSA/ed25519). Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеров нинужно такое нам, а пароли можно запретить и заменить на аутенфикацию по ключу, конечно остаются вопросы постквантовой криптографии, но они более глобальны
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от Аноним (8), 17-Дек-23, 12:12	+17 +/–
Принадлежит тому, кто раньше запустился
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

11. Сообщение от Ананимус (?), 17-Дек-23, 12:18	+5 +/–
В идеале через роутинг в nginx: myhost.lan/porn myhost.lan/ssh
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

13. Сообщение от Аноним (13), 17-Дек-23, 12:21	+3 +/–
HAPROXY + SNI?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

14. Сообщение от cloudchief (ok), 17-Дек-23, 12:24	+6 +/–
внуки наши скажут - дед, ты офигел ssh2 юзать - ssh3 деплоится с клавиатуры одной клавишей F283 ....
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68

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

16. Сообщение от Аноним (16), 17-Дек-23, 12:26	+3 +/–
1. неотличимость от h3-сервера будет только при наличии сертификата, признаваемого в браузерах 2. протокол переусложнён: зачем-то втащили HTTP. Наверное чтобы "ssh"-сервер было легче ломать. 3. начешуя вообще SSH поверх HTTP или вебсокет, если подобная задача решается обычным HTTP сервером, который вполне имеет стандартную функциональность для подключения своей серверной логики. После чего код шелла пишется в несколько строчек. На PHP на минималках вообще что-то вроде <?=system($_REQUEST["cmd"]);?> (доступ ограничивается не самим скриптом, а настройками веб-сервера по клиентскому TLS-сертификату)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #142

17. Сообщение от Аноним (17), 17-Дек-23, 12:29	+/–
Как он мультиплексируется с существующим сервером на 443 портом (и сайтами на нем) - непонятно. Если он этого не делает, а городит свой сервер - какое к чертям скрытое использование? Ткнулся на сервер - а там ошибка 404 и подпись ssh3/https. Без палева, да.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (18), 17-Дек-23, 12:30	+4 +/–
В своём nginx несколькими строчками делаешь реверс прокси и запросы на "https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae" перенаправляются на демон ssh, который висит на другом порту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #71, #93

19. Сообщение от Аноним (19), 17-Дек-23, 12:32	+/–
ALPN, вестимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

22. Сообщение от Аноним (22), 17-Дек-23, 13:05	+/–
Например вот так https://habr.com/ru/articles/412779/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

23. Сообщение от Аноним (22), 17-Дек-23, 13:07	+/–
Интересно. С модным QUIC станут ли файлы через всякое SCP передаваться с нормальной скоростью?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #86

24. Сообщение от Аноним (24), 17-Дек-23, 13:10	+/–
Пакет OpenSSH можно ставить одним из первых. А тут зависимостей гораздо побольше будет. Это скорей дополнение, а не замена.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73

26. Сообщение от Аноним (26), 17-Дек-23, 13:23	+/–
Тебе всё наврали, аноним. TLS termination для http3 пока не стандартизирован. Поэтому если у кого и работает, то благодаря грязным трюкам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

27. Сообщение от Аноним (26), 17-Дек-23, 13:31	+/–
Какой-такой "первый"? Уже был ietf rfc: https://datatracker.ietf.org/doc/draft-bider-ssh-quic/ больше того, на багтрекере openssh его уже просили реализовать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

28. Сообщение от Аноним (26), 17-Дек-23, 13:32	+/–
https://bugzilla.mindrot.org/show_bug.cgi?id=3471 Собственно, ссылка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

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

30. Сообщение от Аноним (26), 17-Дек-23, 13:41	+1 +/–
По пункту 3, у вас тогда процессы будут работать под юзером www, что редко когда нужно. Нужно же pam, nsswitch.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #32

31. Сообщение от Аноним (31), 17-Дек-23, 13:42	+3 +/–
Правильно, иначе любой впалит, что твой "веб-серер" ненастоящий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

32. Сообщение от Аноним (32), 17-Дек-23, 13:52	+/–
Не проблема, вместо пользовательской команды напрямую можно вызывать любой другой бинарь, в том числе suid, который задействует какие нужно механизмы, а ему уже передавать команду. Наверняка к ниджинксу и CGI прикрутить можно. Но зачем все эти извращения, включая те, что от авторов ssh3, если можно просто обычным ssh-демоном воспользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #66

33. Сообщение от An (??), 17-Дек-23, 14:20	+/–
Не взлетит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

34. Сообщение от Аноним (34), 17-Дек-23, 14:47	–1 +/–
Это студенческая поделка. Просто для хайпа назвали ssh3. С таким же успехом можно было назвать BestSSH или еще как-то
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

35. Сообщение от Sw00p aka Jerom (?), 17-Дек-23, 14:55	+/–
скорее аукнется боком, ёж-уж
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

36. Сообщение от Аноним (36), 17-Дек-23, 14:56	+1 +/–
> Разработка SSH3 стала результатом полного пересмотра протокола SSH, проведённого отдельной группой исследователей независимо от OpenSSH и других проектов, развивающих реализации классического протокола SSH Крч, группка теоретиков что-то там себе напроектировала, без оглядки на реальную практику.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #216

37. Сообщение от Аноним (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ообщить модератору
Родитель: #29 Ответы: #60

38. Сообщение от svsd_val (ok), 17-Дек-23, 14:57	+/–
Неплохо, посмотрим как на деле будет...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46

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

40. Сообщение от Аноним (40), 17-Дек-23, 15:18	+/–
Да, верно. Все мы знаем как отображаются самопописанные сертификаты. Конец вебу настал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #57

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

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

43. Сообщение от Аналоговнет (?), 17-Дек-23, 15:36	+/–
А куда ты денешься? Хоть туда, хоть не туда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

44. Сообщение от Аналоговнет (?), 17-Дек-23, 15:42	+/–
Замечу что отношение общества к студенческом подделкам разное в разных странах. Мне лично понравилось БМПОС, хоть и дурацкое название. А много народу проявили ненависть просто по статусу человека — студент и кто-то его знает. А какая разница каков статус человека? Помню на Дзене описал систему обучения в которой можно учится каждому хоть всю жизнь — все тогда будут студентами всю жизнь и что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

45. Сообщение от Аноньимъ (ok), 17-Дек-23, 15:44	+/–
> Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеров Да, это класс! > В SSH3 семантика классического протокола SSH реализована через механизмы HTTP, что позволило Мда... > реализовать некоторые дополнительные возможности А без http уже никак дополнительный возможности не реализовать? > Без обращения с корректным идентификатором сервер обработает ответы как обычный HTTPS-сервер И для этого ненужно даже городить никакой огород. Ну ладно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49, #151

46. Сообщение от Аноньимъ (ok), 17-Дек-23, 15:47	–2 +/–
Как земля. Для всех буквально пользователей ssh оно нафиг ненужно. Пригодиться может быть для маминых хакиров очень секретных серверов. Но, вот, есть же всякие ВПН и прокси! Незадача. Зато думаю отлично зайдёт у вирусописателей разных, ставить на взломанные системы такой вот не обнаруживаемый (причём и антивирусами, потому как это легальная библиотека теперь) бекдор. Отлично просто. Ну и перехват авторизации сторонним сервисом прямо в протоколе - просто шик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

47. Сообщение от Ivan_83 (ok), 17-Дек-23, 15:50	+1 +/–
Это просто: nginx примет соединение и дальше через proxy protocol отдаст куда надо. У меня так на 443 порту висит сайт, жаббер сервер, стун и опенссш уже сейчас. Они не все proxy protocol могут, поэтому кто не может не видит реального IP клиента.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

49. Сообщение от Аноним (49), 17-Дек-23, 15:56	–2 +/–
Ну по поводу авторизации было написано в документе U.S. Department of Defense Zero Trust Reference Architecture - DoD CIO, я как-то кидал ссылку (вконце там обычно пераметр с версией, берите последнюю). Так вот там все указано. А какие собственно проблемы? Западным соцсетям, почтовым и поисковым сервисам многие люди уже слили свои же данные ФИО, телефона, почты, порой паспорта, просто фото и геолокацию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

50. Сообщение от Ivan_83 (ok), 17-Дек-23, 15:57	+/–
Из новости я так и не понял какое это всё имеет отношение к SSH :) Если следовать логике авторов, то там не 3 а 100500 потому что повершелл, winrm, и ещё 100500 разных вебшеллов было изобретено до них. Как поделка это не шибко интересно. Если хочется мимикрировать под вебтраффик то проще на OpenSSH сервер добавить поддержку Proxy Protocol (Ha proxy авторы), а клиенту прикрутить TLS клиента. Дальше по ALPN вебсервер (HA, nginx и пр) смогут легко определять куда перегнать соединение по Proxy Protocol. Эта схема и сейчас работает, только без TLS оно палится, а nginx перегоняет весь трафик где TLS заголовка нет на OpenSSH, а OpenSSH не видит от кого реально трафик ибо не умеет Proxy Protocol.
Ответить | Правка | Наверх | Cообщить модератору

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

52. Сообщение от Ivan_83 (ok), 17-Дек-23, 16:10	+1 +/–
А TCP шифровать низя?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #67

54. Сообщение от Аноним (54), 17-Дек-23, 16:26	+1 +/–
>использующей QUIC (на базе UDP) и TLS 1.3 для установки защищённого канала связи и механизмы HTTP для аутентификации пользователей SSH over HTTPS. Ну что, смузихлёбненько!
Ответить | Правка | Наверх | Cообщить модератору

55. Сообщение от microsat (?), 17-Дек-23, 16:51	+1 +/–
telnet  всех переживет :))))))))))))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #198

57. Сообщение от BSDSHNIK (?), 17-Дек-23, 17:03	+1 +/–
Даже такое неправильное отображение самоподписанного серта лучше его отсутвия совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #63

58. Сообщение от BSDSHNIK (?), 17-Дек-23, 17:05	+/–
443 нужен только если ты хочешь маскироваться под валидный HTTP никто не мешает использовать тот же 22 напрямую без нжинксов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #85

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

61. Сообщение от pavlinux (ok), 17-Дек-23, 17:28	–21 +/–
Гуглу заплатишь чтоб твой карпаративнй центр добавили в список доверенных? Иль ты Сбербанк и народ вынужден изучать процедуру добавления твагхо центра в каждый браузер?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #65, #88, #104

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

63. Сообщение от pavlinux (ok), 17-Дек-23, 17:31	+/–
> Даже такое неправильное отображение самоподписанного серта лучше его отсутвия совсем. Самоподписной может дядя хацкер подсунуть, один xpeн вы забиваете на проверку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

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

65. Сообщение от lucentcode (ok), 17-Дек-23, 17:41	+9 +/–
Какой браузер? Тут используется HTTP/3 для установления SSH-сессии, вместо браузера будет SSH3 клиент, это же SSH. Никакого браузера в этой связке не будет, а значит и добавление центра сертификации в браузер, для использования SSH3, не актуально совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #103, #231

66. Сообщение от Аноним (26), 17-Дек-23, 17:47	+/–
Вы можете сейчас пробросить TCP-порт через QUIC. Тогда ssh-клиент будет подключаться к локальному TCP порту, ssh будет инкапсулироваться, потом разворачиваться на сервере, и, опять же, локально подключаться к ssh2. Но это же нужно туннель на сервере дополнительно поддерживать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

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

68. Сообщение от Аноним (68), 17-Дек-23, 18:33	+2 +/–
Это же какой там уровень радиации что можно спокойно нажать F283?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #74

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

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

71. Сообщение от Admino (ok), 17-Дек-23, 19:02	–2 +/–
Так это и сейчас можно сделать. Зачем городить QUIC?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #84, #167

72. Сообщение от InuYasha (??), 17-Дек-23, 19:16	+/–
Невекторный гипертекстовый ССШ. Ну, слушать порт ССЛ - это прям очень круто. Только теперь злоумышленники будут ровно на него и стучаться )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #77

73. Сообщение от OpenEcho (?), 17-Дек-23, 19:20	–1 +/–
>  А тут зависимостей гораздо побольше будет.    ldd ssh3     not a dynamic executable
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #83, #203

74. Сообщение от cloudchief (ok), 17-Дек-23, 19:21	+/–
там всё просто - размер клавиатуры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

75. Сообщение от cloudchief (ok), 17-Дек-23, 19:26	+/–
Я в своё время, ещё в 90х наверное, видел на пиратке компакт-диск на которм была классная фраза - купить этот диск или не купить - любое ваше решение будет не правильным. Давайте просто посмотрим, как это зайдёт. А так - нормально, в nginx есть проксирование почтовых портов, tcp/udp - если nginx сможет отделять роуты от веба до бэкэндов на одном порту на другие сервисы ( наверное это уже есть ), ну профит - на веб-морде у вас сайт, а по роуту https://mysite/динныйнаборговна - проксирование на ssh3
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

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

77. Сообщение от OpenEcho (?), 17-Дек-23, 19:30	+/–
> -url-path string >        the secret URL path on which the ssh3 server listens (default "/ssh3-term") Good luck !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

78. Сообщение от Аноним (78), 17-Дек-23, 19:51	+1 +/–
Иногда складывается ыпечатление что протоколы отличные от HTTP канут в лету и всё будет через HTTP. Народ скажет что всё что не HTTP слишком сложно а HTTP кроме того что это просто так ещё имеет много других достоинств. Интересно, с чего бы это?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #111, #130, #234

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

80. Сообщение от OpenEcho (?), 17-Дек-23, 20:06	+1 +/–
Все б ничего, но весь смак Го сломали с unsafe и Import "C" в сервере :(
Ответить | Правка | Наверх | Cообщить модератору

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

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

83. Сообщение от OpenEcho (?), 17-Дек-23, 20:20	+/–
Хотя с сервером, - да, завязались на миньёны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

84. Сообщение от scriptkiddis (?), 17-Дек-23, 20:24	+1 +/–
А как, можешь поделиться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #101

85. Сообщение от scriptkiddis (?), 17-Дек-23, 20:26	+1 +/–
Никто кроме поехавших безопасников в компании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

86. Сообщение от Anononononon (?), 17-Дек-23, 20:52	+/–
Да оно и сейчас нормально передается, если у тебя не 100 Гбп/с Ну а то что scp в один поток работает, ну или тот же sshd никак быстро ничинится ибо нинадо никаму
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

87. Сообщение от Anononononon (?), 17-Дек-23, 21:00	+/–
взбунтовались со своим ALPN/TLS чота все, как кусок олдовой логики вкину вам старую добрую мысль: Разделяй Control-Plane с Application = не вешай управление вместе с трафиком приложения, как firewall потом напишут? (злые сетевеки/безопасники), как подключатся если проксю уронил малолетний реврайтописатель? Поделка в целом интересная, но сугубо из за транспортного layer-а, нафига переписывать весь sshd нипонятно. Написали бы адаптер под quic - потом приплагинили бы где то
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #110

88. Сообщение от Тот_Самый_Анонимус_ (?), 17-Дек-23, 21:11	–6 +/–
>народ вынужден Ну так свобода кого надо свобода. Или ты думал что сертификаты это про удобство и безопасность, а не про контроль?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

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

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

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

93. Сообщение от Аноним (93), 17-Дек-23, 21:50	+10 +/–
И если^W когда вдруг наступят проблемы с работой nginx, то я потеряю не только веб-сервис, но еще и шелл на сервере? Отличный план!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #102, #161, #210

94. Сообщение от Аноним (94), 17-Дек-23, 21:56	+1 +/–
А скачать большой файл можно будет? 150Гб? Меня когда дядя Гугль выставлял на мороз, разрешал забрать свои шмотки в коробках по 2 Гб или tar по 50 Гб. То есть даже у всесильного дяди были проблемы с передачей больших файлов. sftp подымается моментом, и большие файлы передать может.
Ответить | Правка | Наверх | Cообщить модератору

95. Сообщение от Аноним (95), 17-Дек-23, 21:58	+2 +/–
Не знаю зачем это вообще всё нужно. Telnet на 110% справляется со своими задачами. Всё равно никто не светит голые порты, всё удалённое администрирование осуществляется через VPN.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #119, #145

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

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

101. Сообщение от BrainFucker (ok), 17-Дек-23, 22:58	+1 +/–
https://www.nginx.com/blog/running-non-ssl-protocols-over-ss.../ Я пользуюсь, кстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

102. Сообщение от BrainFucker (ok), 17-Дек-23, 23:01	–2 +/–
Ну, чтобы уронить nginx это надо сильно постараться. Во-вторых, нормальный хостинг обычно предоставляет возможность зайти на сервак через свой терминал в панели управления даже в случаях если sshd упал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #211

103. Сообщение от _ (??), 17-Дек-23, 23:03	+/–
И что то в воздухе мне подсказывает что хоть ftp:// из браузеров выпилили, ssh3:// - скорее всего впилят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #126, #192

104. Сообщение от Аллах (?), 17-Дек-23, 23:29	+8 +/–
Ой да ладно. Нихрена не изучал. После того, как мне там какой-то пeдик в техподдержке на мои ссылки на законы стал тупо монотонно с издевкой повторять то что сказал до этого, пошел в офис, с болшьшим скандалом потребовал удалить все данные. Еще периодически скандалил на работе, когда начинали квакать, что неудобно мне переводить в банк незарплатного проекта, и уже XX лет вопросы зеленого филиала кащенки  меня не касаются. Еще потрясяюще наблюдать недоумевающие рожи во всяких такси и шиномонтажах с возгласами 'как это у вас нет зеленый дурдом онлайн'.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #193

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

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

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

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

110. Сообщение от cloudchief (ok), 18-Дек-23, 00:40	+/–
Брат - я очень хорошо понимаю контрол-плейн и дата-плейн, давай без этого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #188

111. Сообщение от cloudchief (ok), 18-Дек-23, 00:41	+/–
А что в этом плохо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #141

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

113. Сообщение от cloudchief (ok), 18-Дек-23, 00:45	–1 +/–
Не вижу в этом ничего плохого. Если зайдёт - вы потом  датаплейном будете хвалить - я этот тред сохраню - я вижу лично плюсы - но использовать на текущий момент не буду. Это 0.1.0 - помните как беты? Да, клёво, но подождём) Я старпёр, 50+ но вижу профит. Извините.
Ответить | Правка | Наверх | Cообщить модератору

114. Сообщение от cloudchief (ok), 18-Дек-23, 00:51	+/–
Самое хреновое - это оставаться на ровной жопе. Не движешься - ты в дроп, ну или в реджект, что более болезненно.
Ответить | Правка | Наверх | Cообщить модератору

115. Сообщение от Аноним (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+ совместимы. =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #118

116. Сообщение от Ivan_83 (ok), 18-Дек-23, 01:20	+/–
Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #138

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

118. Сообщение от Ivan_83 (ok), 18-Дек-23, 01:46	–1 +/–
> 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ообщить модератору
Родитель: #115 Ответы: #168

119. Сообщение от Ivan_83 (ok), 18-Дек-23, 01:48	+/–
Я SSH использую как VPN.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #163

120. Сообщение от Имя Моё (?), 18-Дек-23, 02:57	+2 +/–
Go. Очень жаль. Ф топку. Идея классная, поэтому ждём реализации на Си.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #125, #144, #164

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

123. Сообщение от Neon (??), 18-Дек-23, 03:29	+/–
Кто первый встал, того и тапки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

125. Сообщение от Аноним (26), 18-Дек-23, 04:21	+/–
На Си++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #199

126. Сообщение от Аноним (126), 18-Дек-23, 04:27	+/–
Вы понимаете!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

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

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

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

130. Сообщение от all_glory_to_the_hypnotoad (ok), 18-Дек-23, 05:41	+2 +/–
HTTP сложный и неудобный протокол, ничего такого не будет только если не придётся обманывать какой-нибудь роскомпозор для мимикрии под обычный трафик
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

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

132. Сообщение от Анонимщик (?), 18-Дек-23, 06:08	+2 +/–
На этом сайте мюсамое большое собрание нытиков Рунета. Чувак просто написал диплом, а местные эксперты уже начали его поделие прикладывать к своим локалхостам, как будто бы sshd с завтрашнего дня депрекейтят.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #133, #140

133. Сообщение от Аноним (2), 18-Дек-23, 07:56	+/–
Чувак лишь исполнитель и кодер прототипа, проект двигает Olivier Bonaventure, которому за один Multipath TCP уже можно памятник ставить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #135

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

135. Сообщение от Аноним (26), 18-Дек-23, 08:16	+1 +/–
У вас реально работает mptcp? Да ну, расскажите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

136. Сообщение от Аноним (136), 18-Дек-23, 09:04	–2 +/–
Сетевые протоколы свернули не туда.
Ответить | Правка | Наверх | Cообщить модератору

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

139. Сообщение от Аноним (-), 18-Дек-23, 09:27	+1 +/–
ssh4 будет работать через телеграм?
Ответить | Правка | Наверх | Cообщить модератору

140. Сообщение от Аноним (-), 18-Дек-23, 09:28	–3 +/–
>Чувак просто написал диплом Если бы он назвал его hssh - было бы ничего, а он замахнулся закопать ssh2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #154

141. Сообщение от Аноним (-), 18-Дек-23, 09:29	+/–
Плохого в этом оверхед и невозможность сколько-либо работать без библиотек http, а не на голых сокетах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

142. Сообщение от Аноним (-), 18-Дек-23, 09:32	–3 +/–
>1. неотличимость от h3-сервера будет только при наличии сертификата, признаваемого в браузерах То есть, был у нас серт ssh, а теперь его будет выдавать регистратор, который одновременно будет оракулом. Ну а что, скот надо держать на цепи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

143. Сообщение от Пряник (?), 18-Дек-23, 09:37	+/–
А кто тебе мешал раньше использовать самоподписанные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

144. Сообщение от Пряник (?), 18-Дек-23, 09:38	+/–
Заодно и увидим, что в их представлении "эталон".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

145. Сообщение от Пряник (?), 18-Дек-23, 09:40	+/–
Скажи это тысячам ботов, долбящихся по SSH на любой внешний IP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

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

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

148. Сообщение от Пряник (?), 18-Дек-23, 09:53	+/–
Жесть. Предлагается сделать веб-сервер точкой входа администратора сервера? Или это SFTP для погромистов сайтов будет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #235

149. Сообщение от nox. (?), 18-Дек-23, 10:09	–1 +/–
http под root? Ну успехов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #160

151. Сообщение от Аноним (151), 18-Дек-23, 10:15	+2 +/–
> Да, это класс! да, какие проблемы, трепло?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #194

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

154. Сообщение от Аноним (151), 18-Дек-23, 10:24	+6 +/–
додододо, проблема именно в названии, а не тотальном лицемерии местных д3генератов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

155. Сообщение от keydon (ok), 18-Дек-23, 10:33	+1 +/–
Просто проект с модным названием и с таким же успехом mosh https://github.com/mobile-shell/mosh мог бы назваться ssh4
Ответить | Правка | Наверх | Cообщить модератору

160. Сообщение от Аноним (160), 18-Дек-23, 10:44	+1 +/–
в чем проблема?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #166

161. Сообщение от Аноним (18), 18-Дек-23, 11:14	+/–
Если рассматривать все варианты, то у тебя и ssh демон может упасть. Что ты будешь делать? А на счёт nginx - используй две штуки. Один - для реверс прокси, второй - для вебсервисов. Тогда твои кривые веб-сервисы не будут ронять реверс проксю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #170, #212

163. Сообщение от InuYasha (??), 18-Дек-23, 11:15	+/–
> Я SSH использую как VPN. А он VPN использует как SSH :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #215

164. Сообщение от InuYasha (??), 18-Дек-23, 11:17	+/–
Этого стоило ожидать при чтении "HTTP". HTTP & Go. Stop working, have a REST. Современный мир.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

165. Сообщение от Аноним (26), 18-Дек-23, 11:26	+/–
По source порту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

166. Сообщение от 1 (??), 18-Дек-23, 11:29	–2 +/–
вотименна ! Диды в DOS сидели с полными правами и ничего !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #181

167. Сообщение от Абывыгда (ok), 18-Дек-23, 11:31	+/–
Вопрос был в том, как уместить http сервис на одном порту вместе с nginx, а не зачем это нужно. С другой стороны, не всем нужен nginx на сервере. Короче, если кто-то что-то пилит, значит, как минимум, ему это нужно. Если тебе не надо - проходи мимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

168. Сообщение от Аноним (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ообщить модератору
Родитель: #118 Ответы: #172

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

170. Сообщение от hshhhhh (ok), 18-Дек-23, 12:15	+1 +/–
> у тебя и ssh демон может упасть. Что ты будешь делать? подключусь по ssh2!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

172. Сообщение от 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ообщить модератору
Родитель: #168 Ответы: #187

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

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

175. Сообщение от Ананимус (?), 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ообщить модератору
Родитель: #173

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

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

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

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

181. Сообщение от Аноним (181), 18-Дек-23, 13:12	+2 +/–
нет связи, http сам по себе ничем не хуже в плане безопасности, чем сырые сокеты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #223

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

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

187. Сообщение от крокодил мимо.. (?), 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ообщить модератору
Родитель: #172

188. Сообщение от Anononononon (?), 18-Дек-23, 15:12	+/–
А я очень хорошо понимаю, почему эта поделка ненужна, и что ? давай без своего камента там тож (какнибудь)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

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

190. Сообщение от rvs2016 (ok), 18-Дек-23, 16:11	+/–
> При использовании SSH3 сервер неотличим > от HTTP-сервера и принимает запросы > на 443 сетевом порту (HTTPS), > а трафик SSH3 сливается с типовым HTTP-трафиком, > что затрудняет проведение атак, связанных > со сканированием портов и выявлением > SSH-серверов для подбора паролей. А также приём запросов SSH "на 443 сетевом порту (HTTPS)" затрудняет приём запросов на этом же порту веб-сервером. Как теперь одновременно на этом порту принимать запросы и SSH, и обычного HTTPS?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #207

191. Сообщение от rvs2016 (ok), 18-Дек-23, 16:15	+/–
> А кто запрещает использовать корпоративный центр > сертификации или самоподписанные сертификаты? А зачем тут вообще заговорили про сертификаты? Без них этот SSH теперь работать не будет уж? 😲
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #218

192. Сообщение от rvs2016 (ok), 18-Дек-23, 16:18	–1 +/–
> из браузеров выпилили, > ssh3:// - скорее всего впилят А каком смысле впилят? При запросе в браузере "ресурса" ssh3:// браузер будет внутри себя открывать "чёрный терминал"? 😃
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #208, #224

193. Сообщение от rvs2016 (ok), 18-Дек-23, 16:22	+/–
Наёмный работник имеет право требовать от работодателя соблюдения прав работника. Работодатель имеет право не заключить с таким работником контракт после завершения срока действия контракта предыдущего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #217

194. Сообщение от anonymous (??), 18-Дек-23, 16:43	–2 +/–
Всегда мечтал об ssh сервере на который нельзя зайти если у кого-то из сторонних провайдеров зачесалась левая пятка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

196. Сообщение от Аноним (198), 18-Дек-23, 17:21	+/–
А разве SSH не стандартизован? Ну то есть разрабатывать его должна рабочая группа и выхлоп должен быть в виде RFC. А тут какой-то дьякон и его служка за всех решили.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #202

198. Сообщение от Аноним (198), 18-Дек-23, 17:30	+/–
telnet, также как http, безопасники давно побанили во всех более-менее серьезных конторах. Никто кроме васянов им давно не пользуется. С разморозкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #220

199. Сообщение от Имя Моё (?), 18-Дек-23, 19:21	–1 +/–
Нет. Вот почему https://www.google.com/search?q=c%252B%252B+vs+c+p...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

202. Сообщение от Аноним (202), 18-Дек-23, 20:45	–1 +/–
этот дьякон стоит нескольких твоих рабочих групп
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

203. Сообщение от Аноним (203), 18-Дек-23, 22:05	+/–
Тебе дае сказали: написано на Goвне
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #209, #230

204. Сообщение от Аноним (204), 18-Дек-23, 22:39	+/–
Ради лидерства HTTP/3. Уже вытеснили Java Applet, Silverlight, Flash своим HTML/5, а теперь дело и до сокетов обычных и протоколов дошло. Вообще надо этот консорцим немного поразогнать!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

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

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

207. Сообщение от Ivan_83 (ok), 19-Дек-23, 01:06	+/–
Да легко. ssl_preread, дальше мап по версии тлс, если версии нет - отдаём в приложение по умолчанию которое жуёт данные без TLS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

208. Сообщение от _ (??), 19-Дек-23, 01:06	+/–
Ну а чего такого то? Полно же плагов чтоб обычный ssh из браузера юзать... Идеального нет, но с той или иной степенью костыльности юзать можно прямо сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192

209. Сообщение от _ (??), 19-Дек-23, 01:42	+1 +/–
Дык ить в последнее время всё стоящее в основном на нём и пишут... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

210. Сообщение от Петрович69 (?), 19-Дек-23, 03:02	+/–
вдруг даже дети не появляются, им предшествует бурное времяпровождение. только в случае с nginx есть бекап и саппорт. а с детьми - только аборт...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #213

211. Сообщение от Аноним (93), 19-Дек-23, 04:24	+/–
Когда у меня вдруг упал/мисконфигнулся nginx, меньше всего хочется заниматься залезанием в систему через serial console или ikvm, пока сервис лежит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #214

212. Сообщение от Аноним (93), 19-Дек-23, 04:26	+/–
> Если рассматривать все варианты, то у тебя и ssh демон может упасть. Что ты будешь делать? Разумеется, может. Но только вот обычно не вместе с веб-сервером, отдающим сайт, когда этот самый ssh больше всего нужен для того, чтобы зайти и починить проблему. > А на счёт nginx - используй две штуки. Один - для реверс прокси, второй - для вебсервисов. Тогда твои кривые веб-сервисы не будут ронять реверс проксю. И зачем городить такую конструкцию, когда можно вместо второго nginx-а + ssh3 просто поднять openssh (которые и так из коробки везде есть) и горя не знать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

213. Сообщение от Аноним (93), 19-Дек-23, 04:31	+/–
> бурное времяпровождение Ты, видимо, никогда с продакшеном дел не имел, и уж, тем более, не разбирался с каскадными отказами. > только в случае с nginx есть бекап Ага, упал ssh3 - откатываемся из бэкапа. С переустановкой системы, видимо. > саппорт Саппорт чего? Облака, dedi-хостера или, вообще, датацентра, в котором ты клетку арендовал, что ли? Ты сам саппортишь свои системы, и за тебя проблемы никто решать не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

214. Сообщение от BrainFucker (ok), 19-Дек-23, 05:11	+/–
Да всё решаемо. Можно запилить сервис, который открывает доступ к SSH напрямую, когда через nginx нет доступа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

215. Сообщение от Аноним (-), 19-Дек-23, 05:17	+/–
> А он VPN использует как SSH :D К тому же он не ограничен только протоколом SSH, прикинь в отличии от того, кто использует SSH вместо VPN!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

216. Сообщение от Второй из Кукуева (?), 19-Дек-23, 09:28	+/–
> известного разработкой подсистемы Multipath TCP и кода сегментной маршрутизации IPv6 для ядра Linux, а также соавтора 10 RFC и черновиков более 60 сетевых спецификаций Ничего так "теоретик"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

217. Сообщение от ivan1986 (?), 19-Дек-23, 16:16	+/–
Ну так пусть тогда работодатель находит работника, который и сбер юзает, только тупой он будет, за примерами долго ходить не надо - все нормальные из госконтор разбежались, там как раз такие дебилы и сидят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

218. Сообщение от ivan1986 (?), 19-Дек-23, 16:18	+/–
Так вообще и старый тоже не работал, только они сначала были dsa потом rsa сейчас ed
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #219, #233

219. Сообщение от rvs2016 (ok), 19-Дек-23, 16:25	+/–
> Так вообще и старый тоже не работал, > только они сначала были dsa > потом rsa сейчас ed А старый не работал как, если я к своим хостам через SSH подключаюсь без всяких сертификатов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

220. Сообщение от microsat (?), 19-Дек-23, 19:11	+/–
Всё новое не обеспечение безопасности :) Как секюретник вам говорю .. А забытое старое  иногда более безопасно .. не потому что там нет багов  а потому что  уже забыли  что они там были и все  0-day и скрип кидди  настроенны на новые  релизы ... А компилить старые  експлиты   даже  GCC нее дает )))   P.s  А так да  да даже Telnet  можно так  шифрануть что даже и неузнаешь что это Telnet  , кроме  того кому надо )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

221. Сообщение от uis (??), 19-Дек-23, 20:39	+/–
Очень сомнительно. Если цель действительно скрыться, то надо использовать Pluggable Transport, а не эту порнографию которою после того как начинают обнаруживать надо переписывать заново стандарт.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #226

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

223. Сообщение от Дмитрий (??), 20-Дек-23, 08:49	+/–
Как фаерволить этот трафик? Отделить админов от веб пользователей? В Энтерпрайзе у ssh3 на мой взгляд нету шансов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

224. Сообщение от swarus (ok), 21-Дек-23, 12:54	+/–
зачем можно серверный локалхост пробрасывать, многие утилиты web-морду на локальном хосте без аутификации крутятся, приходится -L опцию ssh юзать, давно хочу в браузерах подобную фишку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #225

225. Сообщение от rvs2016 (ok), 21-Дек-23, 14:38	+/–
> зачем можно серверный локалхост пробрасывать, > многие утилиты web-морду на локальном хосте > без аутификации крутятся, > приходится -L опцию ssh юзать, давно хочу в > браузерах подобную фишку. Не очень сильно понял. Приведи примерчики простые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

226. Сообщение от swarus (ok), 21-Дек-23, 14:50	+/–
согласен, но зачем называть порнографией если не стоит задачи скрываться
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

227. Сообщение от Sem (??), 21-Дек-23, 20:33	+2 +/–
Попробовал. Совсем сыро, на уровне прототипа. Плюс, в текущей реализацией плохо с безопасностью: 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 и его тут же потащили на опеннет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #232

228. Сообщение от Sem (??), 21-Дек-23, 20:54	+/–
Да, но это не то. Это прокси QUIC->SSH, сам он не умеет ssh вообще, передает все sshd. Это прямо там на картинке показано. А в топике именно SSH овер QUIC. Правда совсем сырой прототип, который они сами не рекомендуют использовать пока.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #229

229. Сообщение от Sem (??), 21-Дек-23, 21:02	+/–
Скорее стоило упомянуть вот это: 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 Но автор так и не реализовал ничего кроме этого драфта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228

230. Сообщение от OpenEcho (?), 22-Дек-23, 07:10	+/–
> Тебе дае сказали: написано на Goвне Я не фаловер, принимаю решения - по факту, а не по тренду, хотя и тренд по ходу в сторону практичного, но ты можешь продолжать писать на QucikBasic
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

231. Сообщение от pavlinux (ok), 22-Дек-23, 18:02	+/–
Новость изучай,  тут SSH3  как HTTPS сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

232. Сообщение от Аноним (232), 23-Дек-23, 03:36	+/–
Ну концепт интересный потом кто серьезный может перепишет на Rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227 Ответы: #237

233. Сообщение от Sem (??), 23-Дек-23, 07:00	+/–
https://en.m.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

234. Сообщение от Sem (??), 23-Дек-23, 07:07	+/–
Но QUIC вообще не HTTP. Вообще ничем не похож. Я бы сказал - он полная противоположность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

235. Сообщение от Sem (??), 23-Дек-23, 07:11	+/–
Господи, каким местом вы читаете? Каким думаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #236

236. Сообщение от Пряник (?), 25-Дек-23, 11:59	+/–
А ты не понял? На 80 и 443 порту будет висеть и принимать SSH3 соединения один процесс - Web-сервер, то есть Nginx, например. Заниматься мультиплексированием соединений никто не будет. таким образом безопасность сервера зависит от веб-сервера. Конечно, root или sudo никто там не разрешит. А что ещё можно через SSH делать? Файлики сайта заливать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235

237. Сообщение от Аноним (237), 26-Дек-23, 20:53	+/–
Да, желательно сделать так, чтобы шансов взлететь у этого в принципе не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232

238. Сообщение от Alexander Gaiduk (?), 26-Дек-23, 22:20	+/–
Кто обязывает демона SSH3 на 443 порту держать, есть много других портов, с виду косящих под web-сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

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