Комментарии 12
В целом, quic идёт в тренде браузеров - усложнять стандарты до тех пор, пока не останется один-единственный клиент, который это всё способен поддерживать; и стоимость его реализации будет так высока, что никто больше никогда не создаст ещё одну реализацию.
В стандартах www мы это уже видим - браузеры вымирают, не выдержав конкуренции. IE ушёл, опера ушла. FF ещё держится, но в целом, webkit сжирает всё. И это плохо, потому что тогда решения о том, каким будет интернет, начинают принадлежать банде с максимальной скоростью коммитов. Death by thousands MRs, так сказать.
Вот то же самое и с транспортом пытаются сделать. И это плохо, потому что чем шире и сложнее спецификация, тем хуже относительная компетенция у разработчиков.
HTTP/1.0 можно реализовать на коленке, один запрос = одно подключение, пишешь заголовки и тело, читаешь ответ и тело. Код простой и однопоточный. Может написать даже джун.
HTTP/1.1 можно реализовать немного подумав, ведь теперь одно подключение = несколько запросов подряд, заголовков стало больше, правил и исключений больше. Реализация все еще может быть тупой и однопоточной. По причине сложности и нуансов появились атаки типа HTTP Request Smuggling и другие. По причине того что обычным разработчикам не интересно читать 100 страниц документации, у нас теперь нельзя послать GET запрос с телом в большинстве HTTP клиентов, хотя стандарт не запрещает.
HTTP/2.0 добавил мультиплексинг потоков, HD-сжатие заголовков и стейт машины на подключение и потоки каждого запроса. Теперь для реализации уже нужно писать асинхронный код, трекать стейт машины, реализовывать алгоритмы сжатия. Для реализации нужен человек с опытом, вариантов наделать ошибок много.
HTTP/3.0 читал бегло, думать о реализации страшно т.к. надо еще читать и понять DTLS.
Причем HTTP/2.0 еще с натяжкой можно называть развитием технологии и решением общих проблем доставки контента на уровне приложений, то HTTP/3.0 это решение узкого круга проблеем одного игрока - Гугла. Как их протокол протолкнули как стандарт - хз. HTTP/2.0 еще не массово внедрен (46%) и не вышел на плато, что бы его заменять. Если кто-то знает обоснование для третьей версии, то пожалуйста скиньте ссылку или процитируйте.
Видимо не только Гугла, раз ВКонтакте перешел на QUIC
Если кто-то знает обоснование для третьей версии
Предполагаю так: прогресс со стороны компаний-гигантов идёт настолько быстро, что простые сисадмины и разработчики просто не успевают внедрить на свои сервера текущий http2, как уже начали внедрять http3.
Как по мне это совершенно нормально. Вот если бы уходило бы по 20 лет на создание протокола, вот тогда бы бы странно.
Ой, не кладите вместе ipv6 и quic. IPv6 вобрал в себя столько улучшений по сравнению с ipv4, что после какого-никакого опыта работы с ipv6, возврат в волшебный мир бушующих бродкастных arp'ов звучит как кошмар. Причём, если пытаться описать ipv4 с позиции ipv6, то там дичь на дичи. Например, как узнать IP-адрес маршрутизатора в сети? Отправить бродкаст (!) на всю сеть, в ответ на которую придёт NACK, после чего опять нужно отправить запрос, и может быть, в финале придёт ACK и мы узнаем... Свой ip адрес. А шлюз - это позднее расширение, вовсе не обязательное.
Как общаться, если нет DHCP? ЛИбо никак, либо ждать чёрти сколько и пытаться прихватизировать адрес из малюсенькой сетки с огромными шансами на коллизию и нулевой discoverability (предсказать link-local узла в ipv4 невозможно). Как узнать, какие узлы есть в сети? Бродкаст! Как напомнить о своём существовании коммутатору? Бродкаст! Да ещё и не на IP уровне, а чёрти на каком протоколе. 100.500 - валидный ip адрес!
Это мы ещё не тронули нежный вопрос NAT'а и совершенно не покрытого стандартами multihoming'а.
Вы привыкли к ipv4, и вам не хочется переучиваться. А пользы от ipv6 очень много на всех слоях, буквально, куда не ткни, улучшение.
на cloudflare в 1 клик включается без каких либо настроек в твоем коде.
Я был невероятно удивлен скорости
На практике было очень сложно перейти на одно соединение, потому что многие страницы были разделены между именами хостов и даже серверами (например,
img1.example.comиimg2.example.com).
А нужно ли прям переходить на одно соединение? Иметь три-четыре соединения вместо одного - не такие уж большие накладные расходы, если у вас не десятки тысяч мелких запросов в секунду.
Так что всем советовали отменить шардинг между серверами и по максимуму собрать ресурсы на одном сервере. У HTTP/2 даже была функция объединения соединений
Ага, а потом окзалось, что на нестабильных соединениях HTTP/2 медленнее, чем HTTP/1 из-за того, что потери пакетов блочат всё соединение (с чем и призван бороться HTTP/3), но у HTTP/1 их как минимум шесть :)
файловые запросы до сих пор обходятся не так дёшево, как все изначально ждали от HTTP/2. Наконец, если не встраивать ресурсы, это увеличивает задержку, потому что файлы нужно запрашивать.
Вот да, мне кажется, не все это понимают. Как ни крути, а самый эффективный способ - загрузить всё, что нужно, за один раз.
Мы видели, что система была очень сложной, часто ее неправильно использовали и реализовывали на практике
Согласен, это - большой недостаток HTTP/2 :(
В целом, лучше не использовать server push для загрузки веб-страниц, разве что вы точно знаете, что делаете. Но и тогда большого преимущества вы не получите.
И тут согласен. И получается интересная ситуация - сначала о приоритезации и сервер-пушах HTTP/2 изо всех щелей вылезали крайне хвалебные статьи, а потом бац и оказалось, что от них проблем больше, чем пользы. Поэтому я сейчас уже скептически смотрю к нововведениям, преподносимым как преимущества в HTTP/3. Как минимум, 0-RTT выглядит сомнительно из-за проблем с безопасностью. И кажется немного неправильным, что ради небольшого преимущества в нестабильных сетях, HTTP/3 более ресурсоёмок в плане шифрования, и это работает впустую в стабильных сетях. Но, конечно, это не означает, что надо стоять на месте.
Интересная статья, спасибо.
Вау, спасибо Вам за такую полезную и о-очень полную статью, Полина!)
Всё очень подробно с мельчайшими деталями и пояснениями к ним. Теперь мы знаем, что появился HTTP/3!
Очевидно, что QUIC — это транспортный протокол нового поколения, который будет использоваться ещё очень много лет.
Ну вот с "очевидно" я бы не торопился. Очевидно, что его пиарят (Гугл), очевидно, что юзабельных реализаций в веб-серверах - что-то кот наплакал. В браузерах, внезапно, тоже требуются порой танцы для включения.
Итого, "из коробки" в сервере не включить, у клиента будет ли востребовано - не понятно. По сетям зажатие UDP у иного транзитного оператора может подкинуть свинью совершенно легко.
В общем, если поиграться - то ок, а для работающих сайтов можно и не морочиться. Пока что не морочиться.
HTTP/3: развёртывание HTTP/3 на практике. Часть 3