<?xml version="1.0" encoding="koi8-r"?>
<rss version="0.91">
<channel>
    <title>OpenForum RSS: Протокол HTTP/3.0 получил статус предложенного стандарта</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html</link>
    <description>Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола HTTP/3.0 и опубликовал связанные с ним спецификации под идентификаторами  RFC 9114 (протокол) и RFC 9204 (технология сжатие заголовков QPACK для HTTP/3). Спецификация HTTP/3.0 получила статус &quot;Предложенного стандарта&quot;, после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний. Одновременно опубликованы обновлённые варианты спецификаций для протоколов HTTP/1.1 (RFC 9112) и HTTP/2.0 (RFC 9113), а также...&lt;br&gt;&lt;br&gt;Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57309&lt;br&gt;</description>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (pofigist)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#325</link>
    <pubDate>Mon, 27 Jun 2022 13:58:50 GMT</pubDate>
    <description>Cisco ASA же&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (zuzzz)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#324</link>
    <pubDate>Wed, 22 Jun 2022 12:28:43 GMT</pubDate>
    <description>Что бы было разнообразие) У каждого браузера свои стандарты и фичи&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (timur.davletshin)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#323</link>
    <pubDate>Thu, 16 Jun 2022 11:04:58 GMT</pubDate>
    <description>https://legacy.netdevconf.info/2.1/papers/compare-tcp-highway-netdev-4-final.pdf &amp;#8212; не читай вывод, смотри на графики. Исследование твоего BBR в дикой природе. Как разница?&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (Онаним)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#322</link>
    <pubDate>Mon, 13 Jun 2022 06:26:17 GMT</pubDate>
    <description>Ну, мы сами писали на средних курсах :D Под винду правда.&lt;br&gt;А так - возможно оно и было, я особо не изучал, но адреса DNS-серверов китайские. Длинные псевдо-имена в сторону неких доменов, в ответ тоже неразборчивые TXT.&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (timur.davletshin)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#321</link>
    <pubDate>Mon, 13 Jun 2022 00:41:13 GMT</pubDate>
    <description>&amp;gt; А что там и где &quot;бросили&quot; я не знаю.&lt;br&gt;&lt;br&gt;Google его не использует. Он использует некую модифицированную версию (погугли &quot;The Great Internet TCP Congestion Control Census&quot;), отличающуюся заметно от той, что скормили в ядро Linux. Стриминговые сервисы используют Cubic или Reno+RACK, Youtube какую-то модифицированную версию BBR (но не BBRv2), даже на остальных сервисах (не серверах доставки видео) Google использует Cubic.&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (timur.davletshin)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#320</link>
    <pubDate>Mon, 13 Jun 2022 00:29:53 GMT</pubDate>
    <description>&amp;gt; Путем ОТПРАВКИ запроса.&lt;br&gt;&lt;br&gt;И сколько там запрос GET занимает? В запросном канале ВСЕ алгоритмы ведут себя одинаково, они даже не уходят ни разу в потолок. Твой BBR не сможет задетектить рост RTT, а классический Cubic/Reno не получит первого дропа. Оговариваюсь про классический, т.к. сейчас везде (в Linux/Android хотя бы) уже гибридный старт, который сделал из Cubic аналог твоего BBR на начальном этапе или этапе slow start... там меряются RTT &quot;паровозиков&quot; из пакетов. Если же у тебя лежит канал, то обработка этого события ведётся по а) непревышению таймаута соединения (который НЕ ЗАВИСИТ от алгоритма congestion control&apos;а; б) алгоритм сбросит тебя в режим slow start и перезапросит выборочно потерянные пакеты, если включен SACK (включен по умолчанию у всех).&lt;br&gt;&lt;br&gt;Никакого другого варианта просто нет. Ты банально демонстрируешь непонимание того, как работает сетевой стек.&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (timur.davletshin)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#319</link>
    <pubDate>Mon, 13 Jun 2022 00:19:49 GMT</pubDate>
    <description>&amp;gt; Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.&lt;br&gt;&lt;br&gt;Проблемы масдая не в кубике, а в том, что там отключены tcp timestamp&apos;ы (уточни, так ли это в последних версиях) и джиттер может привести его в состояние повышенного дропа пакетов. Но timestamp&apos;ы и там включаются лёгким движением мыши.&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (timur.davletshin)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#318</link>
    <pubDate>Mon, 13 Jun 2022 00:15:07 GMT</pubDate>
    <description>&amp;gt; Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния.&lt;br&gt;&lt;br&gt;Есть такая вещь в параметрах модуля backoff_factor (у реализации BSD она иначе зовётся), попробуй её понастраивать. Можешь начать со значения 1.&lt;br&gt;</description>
</item>

<item>
    <title>Протокол HTTP/3.0 получил статус предложенного стандарта (timur.davletshin)</title>
    <link>https://www.opennet.ru/openforum/vsluhforumID3/127706.html#317</link>
    <pubDate>Mon, 13 Jun 2022 00:12:26 GMT</pubDate>
    <description>&amp;gt; Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.&lt;br&gt;&lt;br&gt;Чем публикация тестов Google лучше? Оно даже по критериям академичности не прокатывает.&lt;br&gt;</description>
</item>

</channel>
</rss>
