The OpenNET Project / Index page

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



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

Оглавление

Протокол HTTP/3.0 получил статус предложенного стандарта, opennews (ok), 07-Июн-22, (0) [смотреть все]

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


82. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 16:12 
>  Всё это совершенные мелочи по сравнению с проблемами tcp.

Ограничения TCP известны и изучены. CUBIC/Reno и все эти SACK, ECN, гибридный старт годами отлажены и отполированы. А придуманный, пускай даже и в Google, BBR оказался переусложнённым и ничем не выдающимся с функциональной стороны. Зато с кучей новых проблем...

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

164. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от lockywolf (ok), 08-Июн-22, 09:43 
Отлажены, отполированы, но не работают.

И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока, они всегда будут что-нибудь портить.

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

166. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 09:48 
> И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока,
> они всегда будут что-нибудь портить.

Простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам? Просто интересуюсь, как вы представляете их работу.

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

185. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 08-Июн-22, 19:49 
>простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам?
> Просто интересуюсь, как вы представляете их работу.

Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по дороге с большой вероятностью дропает коннект.

Не говоря уже о том, что когда коннект выглядит нетипично на DPI, его приоритизируют ниже.

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

187. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 20:26 
> Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по
> дороге с большой вероятностью дропает коннект.

Мне вот тут интересно стало, а что такое в твоём понимании TCP window scaling?

> Не говоря уже о том, что когда коннект выглядит нетипично на DPI,
> его приоритизируют ниже.

Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще режут на первом же хопе.

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

190. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 04:08 
> Мне вот тут интересно стало, а что такое в твоём понимании TCP
> window scaling?

Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.


> Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении
> значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще
> режут на первом же хопе.

Детали работы DPI не публикуются. Эмпирически приоритизация очень хорошо заметна. Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.

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

191. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:25 
> Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.

Очень глубокое понимание работы протокола. Кстати, именно поэтому кол-во ACK'ов не совпадает с кол-вом пакетов, но на каждый пакет есть ACK! Представть, если бы в потоке в несколько десятков гигабит надо было тут же на каждый пакет отсылать ACK. Интересная бы производительность у протокола тогда была. Вот такая вот, на первый взгляд, противоречивая фигня. Вообще попробуй разобрать любую сессию в Wireshark ради примера. Сейчас многое изменилось со времён оригинального TCP и от учебника и википедии отличается )))

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

193. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:36 
> которую файрволы по дороге переписывают так, как им заблагорассудится

Нет в абсолютно подавляющем большинстве.

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

195. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 08:49 
>> которую файрволы по дороге переписывают так, как им заблагорассудится
> Нет в абсолютно подавляющем большинстве.

Sweet summer child. Всё, что можно переписать, переписывается. Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.

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

196. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 09:53 
> Sweet summer child. Всё, что можно переписать, переписывается.

А кроме как языком доказать сможешь? Ну, начнём с того же TCP window scaling (раз уж его упомянули). Я просто к чему это говорю, просто эта вещь ломает работу канала. Я даже и бородатый баг с разбором проблемы среди разработчиков ядра могу привести алаверды на доказательство твоего тезиса.

> Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.

Что там кроме payload защифровано, сказочник? Там та же логика управления каналом, что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят имена идентичные — CUBIC/Reno/BBR :)

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

202. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 09-Июн-22, 12:15 
> Что там кроме payload защифровано, сказочник? Там та же логика управления каналом,
> что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят
> имена идентичные — CUBIC/Reno/BBR :)

21.1.1.4.  Parameter Negotiation

   The entire handshake is cryptographically protected, with the Initial
   packets being encrypted with per-version keys and the Handshake and
   later packets being encrypted with keys derived from the TLS key
   exchange.  Further, parameter negotiation is folded into the TLS
   transcript and thus provides the same integrity guarantees as
   ordinary TLS negotiation.  An attacker can observe the client's
   transport parameters (as long as it knows the version-specific salt)
   but cannot observe the server's transport parameters and cannot
   influence parameter negotiation.

   Connection IDs are unencrypted but integrity protected in all
   packets.

   This version of QUIC does not incorporate a version negotiation
   mechanism; implementations of incompatible versions will simply fail
   to establish a connection.


https://datatracker.ietf.org/doc/rfc9000/

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

211. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 20:03 
На этом разговор и закончим, мне всё ясно.
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

192. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:30 
> Детали работы DPI не публикуются.

На этом можно было бы и закончить гадать...

> Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.

А вы уверены, что софт, торчащий на тех портах, не генерирует задержку банально, которую вы упорно измеряете? И дело совершенно не в DPI, а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH 😄

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

194. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 08:46 
>> Детали работы DPI не публикуются.
> На этом можно было бы и закончить гадать...

Можете закончить, а мне нужно данные передавать.


>> А вы уверены, что софт, торчащий на тех портах, не генерирует задержку
> банально, которую вы упорно измеряете? И дело совершенно не в DPI,
> а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH
> 😄

Я уверен, потому что я измерял задержку до RST заблокированных портов


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

197. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 09:57 
> Я уверен, потому что я измерял задержку до RST заблокированных портов

Жду однострочник, с нетерпением.

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

198. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 09-Июн-22, 11:44 
>> Я уверен, потому что я измерял задержку до RST заблокированных портов
> Жду однострочник, с нетерпением.

Однострочники называются nping и hping3.

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

201. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 12:05 
я так и знал 😆
Ответить | Правка | Наверх | Cообщить модератору

203. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 12:16 
> я так и знал 😆

И что ты знал, болтун? Какая разница, чем слать пакеты?

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

259. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:12 
> Однострочники называются nping и hping3.

Хорошие, кстати, однострочники если хочется потыкать пакеты палочкой в нестандартном виде.

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

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

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




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

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