The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Представлен SSH3, вариант протокола SSH, использующий HTTP/3, opennews (?), 17-Дек-23, (0) [смотреть все]

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


29. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"  +2 +/
Сообщение от Аноним (26), 17-Дек-23, 13:39 
Ты "почти" всё правильно понимаешь.

Контроль потока на уровне ядра ОС был вынужденной мерой, когда хотелось просто открыть сокет и писать данные с помощью С write().

Это неплохо работало как переходная мера, когда большая часть подключений была десктоп-десктоп или десктоп-сервер, по надёжным каналам с маленькой задержкой.

Сейчас мир другой, и "прозрачная" (но дырявая) TCP абстракция "надёжного сокета" перестала отвечать реальности.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

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

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

Естественно, при этом радость от QUIC не очень велика, хотя уже приятно, что можно выставлять некоторые флаги самому.
Что больше радует -- это что можно установить изначальное соединение "по tcp2", вести "сигнальный канал" с сохранением надёжности (но медленно), но параллельно открыть DATAGRAM-канал, и по нему уже слать данные с собственной коррекцией ошибок (или без неё). А для внешнего наблюдателя это всё равно будет всего-навсего "зашифрованный UDP поток".

Почему так было не сделано "давно"? Не знаю, я тогда не жил, но тогда казалось, что "правильная абстракция" -- это "номер протокола IP". В /etc/protocols куча всяких древних стандартов перечисленно. В каком-то смысле это казалось логичным -- ведь если какая-нибудь "фича" реализовывалась на уровне "системных протоколов", как, например, ipsec, то она "автоматом" распространялась на все протоколы уровнями выше, независимо от того, был там контроль доставки, или не было, были порты, или не было.

Ответить | Правка | Наверх | Cообщить модератору

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

62. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"  +/
Сообщение от Аноним (26), 17-Дек-23, 17:30 
Тебе никто не мешает так сделать. Вернее, сейчас вообще так и делается, только без всякого Диффи-Хеллмана.

Есть websocket. Подключаешься по https к https://webservice.com/service-name/, service-name пробрасывает websocket, и по этому websocket пиши что хочешь, он шифрован TLS-ом.

Ответить | Правка | Наверх | Cообщить модератору

51. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"  +2 +/
Сообщение от Ivan_83 (ok), 17-Дек-23, 16:08 
Вы себе и близко не представляете что такое современный TCP.

Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.
5 строчек в приложении, 8кб скомпиленый бинарник и оно уже работает. Извращенцы даже из баш скриптов научились этим напрямую пользоватся.

Что бы вы там в юзерспейсе не нагородили оно всегда будет жрать больше ресурсов и работать лучше не станет.

Задержки при старте - ну это такое, сильно на любителя. У TCP для этого тоже есть много разного.
Единственно что реально получилось улучшить это DTLS за счёт прибивания на гвозди размеров пакетов и выраснивания по размеру блоков алгоримов шифрования.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

64. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"  +1 +/
Сообщение от Аноним (26), 17-Дек-23, 17:36 
>Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.

Невозможно "оптимально" реализовать работу TCP на канале с потерями 80%. А мобильные каналы и замусоренный wifi так и выглядят. Просто невозможно и всё. Не существует "надёжного" канала, который будет работать нормально на таких потерях, потому что не существует единого способа определить, надо ли пакет ретрансмитить или дропать, без знания контекста приложения. Если ваш поток -- видео, например, с камеры наблюдения, вы можете пренебречь потерями, заполняя видео старыми кадрами, и ничего не потеряете. Если вам нужно передавать ssh, вы очень не хотите терять никаких команд, даже если пинг вырастет до 15 секунд. Операционная система этого не знает, и знать никогда не будет. Контроль потерь должен осуществляться на самом высоком уровне стека, по сути, на прокладке между креслом и монитором. Готов юзер терпеть потери, или нет.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

2. Не сидят, не нужно сочинять. С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет.

3. Вам хочется - вы и прогайте. )

4. Покажите примеры за пределами гугла где это используется.

Ответить | Правка | Наверх | Cообщить модератору

179. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"  +/
Сообщение от Аноним (26), 18-Дек-23, 13:06 
>С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет.

Видите, как мало вы знаете о мире. К сожалению, сидят-сидят.

DNS комфортно и не работает (тем более что ещё и фильтруется) поэтому китайские приложения обновляются раз в неделю, заодно таская с собой кэш dns.

Quic не в последнюю очередь как раз и сделан Google чтобы (а) обходить блокировки КНР, (б) сервить контент с серверов в Гонконге и США через полтора полудохлых канала, намертво перегруженных с потерями.

Ответить | Правка | Наверх | Cообщить модератору

189. "Представлен SSH3, вариант протокола SSH, использующий HTTP/3"  +/
Сообщение от timur.davletshin (ok), 18-Дек-23, 15:53 
> сервить контент с серверов в Гонконге и США через полтора полудохлых канала, намертво перегруженных с потерями.

Угомонись уже. Никак этот твой QUIC не поможет в борьбе с потерями, т.к. в серверных реализациях New Reno и Cubic почти что у всех. Более того, в QUIC отдаётся Гуглом далеко не весь контент даже на страничке YouTube, для которого якобы и делался. Попробуй уже включить мозг и поразмыслить, почему HTML Google отдавать предпочитает по HTTP/2... Более того, всякие там ТВ, как правило (Самсунги там всякие, ЛыЖи и прочая) юзают исключительно HTTP/2 и, OMG, HTTP 1.1.

Ответить | Правка | Наверх | Cообщить модератору

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

Примеры софта будут?

Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

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

Ахаха нет. DPDK не просто так появился.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

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

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

Ага. Потому что тот стек, что есть в линуксе, он даже близко не оптимальный.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Далеко не только. Там есть MASQUE extension, DATAGRAM extension.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру