LINUX.ORG.RU

curl 7.66.0: параллелизм и HTTP/3

 , , ,


3

4

11 сентября вышла новая версия curl — простой CLI утилиты и библиотеки для получения и отправки данных по сети. Нововведения:

  • Экспериментальная поддержка HTTP3 (по умолчанию отключена, требует пересборки с quiche или ngtcp2+nghttp3)
  • Доработки авторизации через SASL
  • Параллельная передача данных (ключ -Z)
  • Обработка заголовка Retry-After
  • Замена curl_multi_wait() на curl_multi_poll(), что должно предотвратить подвисание при ожидании.
  • Исправления багов: от утечек памяти и падений, до поддержки Plan 9.

Ранее разработчик curl Дениел Стэнберг (Daniel Stenberg) выложил пояснения в блоге и 2,5-часовой видеообзор, зачем нужен HTTP/3, и как его использовать. Вкратце — вместо протокола TCP используется UDP с шифрованием TLS. Пока по HTTP/3 работают такие вещи, как: доступ по IPv4 и IPv6, все доступные фичи DNS, обработка заголовков, куки. Не сделаны запросы с большим телом, распараллеливание, тесты.

Проекты на GitHub

>>> Чейнджлог

Ответ на: комментарий от sT331h0rs3

А где-то в реальных проектах HTTP/3 и QUIC уже применяются?

Спецификации только-только устаканились. Или даже вот-вот устаканятся. В Хром на днях добавили: http://www.opennet.ru/opennews/art.shtml?num=51526, https://twitter.com/programmingart/status/1174775953316294658 Саму спецификацию QUIC ещё дорабатывают, хотя Гугл ею пользуется уже несколько лет для своих служб. Есть несколько серверов для тестирования, и пока на этом всё.

Могу ошибаться, я пользователь curl, но за QUIC не слежу.

question4 ★★★★★
() автор топика
Ответ на: комментарий от sT331h0rs3

В сервисах гугла уже давно QUIC, для тех кто поддерживает. У CloudFlare можно включить опционально в настройках для любого из твоих доменов. Так что да, используется, при чем учитывая Гугл и поддержку Хромом QUIC'а уже несколько лет очень широко используется, миллиардом-другим человек.

anonymous
()

HTTP/3. Не волнуйтесь – быстрее веб не станет. Это вообще нужно-то для высоконагруженных серверов типа Гугла.

kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_

Это — гонка. Кто раньше продемонстрирует поддержку HTTP/3. Учитывая, что курл используется для отладки и рипанья сайтов, ему поддержка важна.

question4 ★★★★★
() автор топика
Последнее исправление: question4 (всего исправлений: 1)
Ответ на: комментарий от kostyarin_

Это вообще нужно-то для высоконагруженных серверов типа Гугла

Нагрузка на сервера наоборот увеличится:

Google’s Sigcomm QUIC paper shows a 2x CPU increase going from TCP to QUIC.

https://mailarchive.ietf.org/arch/msg/quic/zrpIJlaXhqmK4ogSdzA0ao64TH4

Судя по всему, расчет в том, чтобы пусть даже увеличением расходов процессорного времени на фронтах заработать больше денюшек на клиентах на плохих каналах (читай - мобильных пользователях).

araks ★★
()
Ответ на: комментарий от Deleted

Еще недавно пилили под названием QUIC и только предполагалось, что оно станет HTTP/3. После того как Google и IETF свои драфты выровняли протокола на днях Google заявил о начале поддержки уже именно HTTP/3 в Хромой Канарейке.

anonymous
()
Ответ на: комментарий от Deleted

Офигеть, я даже и не знал что новую версию уже во всю пилят.

Это не новая версия, это новый udp транспорт для http/2.

atrus ★★★★★
()

http 2 оказался фейлом, но гугл не угомонился...

anonymous
()
Ответ на: комментарий от araks

Нагрузка на сервера наоборот увеличится:

Они надеются, что когда UDP станет мэйнстримом, оптимизируют соответствующие части ядра. Пока — да, вдвое.

question4 ★★★★★
() автор топика

Выкидывать TCP уже давно нужно было. Вопрос был только в том, кто это сделает раньше, и по какой причине. Хвала Гуглу.

FTP уже все.

TCP (HTTP) на очереди.

Закопаем SMTP - и мир станет идеальным.

windows10 ★★★★★
()

а что с spdy который они почему-то называли http/2? всё, отменяется, все свободны?

anonymous
()
Ответ на: комментарий от question4

когда UDP станет мэйнстримом

никогда. вернее в твоём понимании никогда, а так udp вообще-то уже лет 20 мейнстрим. просто tcp и udp - это два протокола для разных вещей и оба уже давно заоптимизированы в ядре, и не в одном.

судя по описанию, вангану, что и udp будут «заменять». имхо если их что-то не устраивает в хттп, то им надо хттп дорабатывать, а не велосипедить свои костыли. но вообще ждём http/28 в хром 152, да, сгораем от нетерпения.

anonymous
()
Ответ на: комментарий от windows10

Выкидывать TCP уже давно нужно было. Вопрос был только в том, кто это сделает раньше, и по какой причине. Хвала Гуглу.

Кому нужно? Хорошая абстракция для гарантированной доставки пакетов по ненадежному каналу и максимального вижимания пропускной способности канала. Клиенту и серверу без TCP придется за этим следить самостоятельно.

FTP уже все.

Где это FTP всё? В браузерах? Файловые менеджеры в него умеют поголовно. Есть консольный клиент. Есть несколько реализаций серверов. Удобен в использовании, прост в реализации. Лучше поддерживает докачку.

TCP (HTTP) на очереди.

TCP - транспорт не только для HTTP, но и для ssh, telnet, whois, DNS (внезапно, не только UDP), POP3, SMTP, IMAP, SQL, UUCP, Internet Printing Protocol, Jabber, LDAP, X Window, DHCP, Radius, Pulse Audio (тут, честно говоря, непонятно, почему не UDP или не оба)...

И это я еще выбирал известное и используемое за пределами сурового энтерпрайза и домов ветеранов computer science.

Закопаем SMTP - и мир станет идеальным.

Предлагаю пойти дальше и построить северный и южный мосты со специальными версиями Electron. Доступ к памяти - через HTTP, доступ к дискам - через HTTP, PCIe - через HTTP.

Bagrov ★★★★★
()
Ответ на: комментарий от anonymous

Спасибо огроменное. Глубоко задумался о смысле жизни. (Ну и о жертвах современного образования, дорвавшихся до создания протоколов и теперь уверенно катящих цивилизацию вспять.)

dimgel ★★★★★
()
Ответ на: комментарий от Bagrov

Доступ к памяти - через HTTP

пожалуйста в формате json. к доказали современные системные инженеры (вышедшие из веб-программистов, вроде Ле Поттеринга), это одинакого хорошо читаемый людьми и эффективный для машинного парсинга формат.

crypt ★★★★★
()
Ответ на: комментарий от anonymous

а что с spdy который они почему-то называли http/2? всё, отменяется, все свободны?

Всё никак не взлетит. Значит, нужно двигаться дальше.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

ты наверное через udp отправляешь то, что надо отправлять через tcp, а через tcp отправляешь то, что надо через udp, вот у тебя и не работает нормально ни одно, ни другое. не ты первый, не ты последний. клизму через рот ещё попробуй поставить, может понравится.

ну в общем всё идёт к разработке собственных костылей, чего тут гадать. ещё взяли моду называть http/2, tcp/2, udp/2. да-да, верим. пусть сначала выкатят открытую реализацию в ядра линукса и всех бсд, потом посмотрим, что они там выстрадали.

anonymous
()
Ответ на: комментарий от anonymous

ты наверное через udp отправляешь то

Перечитай тему или сходи по ссылке: https://http3-explained.haxx.se/en/proc-status.html

Отправляю не я, а Гугл с Фейсбуком. И да, ядра не рассчитаны на такое применение UDP. А TCP вообще не используется. Но я уверен, что Фейсбук сможет преодолеть созданные трудности.

пусть сначала выкатят открытую реализацию

Реализаций несколько штук. Несовместимых между собой. Пока юзерспейсных. Так как стандарт недавно стабилизировали, в следующей версии ядра может появиться и что-нибудь ядерное.

question4 ★★★★★
() автор топика
Ответ на: комментарий от crypt

пожалуйста в формате json.

Можно JSON. Осталось написать первоапрельский RFC.

к доказали современные системные инженеры (вышедшие из веб-программистов, вроде Ле Поттеринга), это одинакого хорошо читаемый людьми и эффективный для машинного парсинга формат.

Всё правильно, шины - текстовые, логи - бинарные.

Bagrov ★★★★★
()
Ответ на: комментарий от question4

И да, ядра не рассчитаны на такое применение UDP

На какое применение рассчитан UDP в ядре?

surefire ★★★
()
Ответ на: комментарий от Bagrov

Хорошая абстракция для гарантированной доставки пакетов

TCP - плохая абстракция для доставки пакетов. Она относительно хороша для 1го потока байтов. Что более-менее приемлемо для работы в терминале(хотя длинные escape-последовательности и многобайтовые кодировки заставляют сомневаться) и протоколов типа FTP(если отправлять файл как последовательность байт, чего никто уже не делает ибо TLS, а там уже совсем не stream).

TCP - транспорт не только для

Суровая правда в том, что наличие в верхнем протоколе поля «размер пакета» или эскаплённых символов – явный признак борьбы с функциями поточного транспорта. И оно есть как минимум в большинстве перечисленных.

Получается, TCP изрядно отстал от решаемых с его помощью задач. А человечество не заметило, и, несмотря на растаявший снег, продолжает грузить пайлоад в сани.

DonkeyHot ★★★★★
()
Ответ на: комментарий от question4

в следующей версии ядра может появиться и что-нибудь ядерное.

Вроде бы QUIC изначально задумывался для работы в userspace потому, что так его проще обновлять. А пока выкатят поддержку в ядре, выйдёт ещё пара стандартов, и придётся опять работать в userspace.

ma1uta ★★★
()

Современный IT всё больше напоминает цирк, в котором стаи бешеных макак пытаются переорать друг друга. Вот, что бывает, когда разработкой стандартов занимаются не кадемики, а быдло из корпораций.

anonymous
()
Ответ на: комментарий от anonymous

Параллельная передача данных (ключ -Z)

Это как?

Если я правильно понял, несколько URL-ов одновременно. С самого начала можно было указывать несколько URL (и ключей -O/-o) для последовательной обработки, а теперь их можно будет обрабатывать параллельно.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

это всё уже было в так называемом http/2. вы знаете, это пионерство и постоянные технологические фейлы действительно сильно вредят прогрессу. сколько человеческого труда потрачено впустую. я сам не занимался поддержкой http/2, но я знаю людей которые занимались. я считаю, что надо всех этих деятелей из гугеля и пейсбука заставить доделывать http/2. пусть делают http/2.1, http/2.2 и так пока не доделают.

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

anonymous
()
Ответ на: комментарий от question4

будет в nginx 1.17

Так сейчас он, получается, ни на чём не реализован? Или простым людям всё же можно его как-то поднять у себя?

beaver
()
Ответ на: комментарий от ma1uta

Вроде бы QUIC изначально задумывался для работы в userspace потому, что так его проще обновлять.

есть две разновидности подобных личностей: одни делают веб-сервер в ядре, другие делают tcp/ip в юзерспейсе. что характерно, и те и другие одинаково страдают и героически преодолевают эпические проблемы которые сами себе придумали.

ну гугел - богатая компания, наверное может себе позволить, а с компаниями победнее всё немного сложнее.

anonymous
()

HTTP/3 Не нужно. И даже очень плохо.

Обоснуй: после Столлмана окончательно стало ясно, что мир скатывается в сраное^W новый тоталитаризм. И анонимность резко повышает свою важность. Если бы Столлман высказался анонимно, его бы не турнули.

А тор, как известно, не работает через UDP. Раньше это доставляло проблем всякий раз, когда для регистрации где-либо нужно было (в качестве простейшей опции) использовать voip (который UDP-based), но если такие же проблемы будут для http вместо voip, это будет катастрофа.

anonymous
()
Ответ на: комментарий от anonymous

А тор, как известно, не работает через UDP.

Для тех, кто не в теме, можешь пояснить, почему не работает и почему не может начать работать?

beaver
()
Ответ на: комментарий от beaver

Для тех, кто не в теме, можешь пояснить, почему не работает и почему не может начать работать?

Я не разобрался в этом до конца, но из того, что разобрался, предварительные причины две: 1. Авторы тора стали ламерами прежде чем успели это допилить (примерно тогда же, когда выкинули прекрасное Vidalia и вкрутили абсолютно нерабочий, аццки корёжащий терминал, arm, не говоря уже о том, что делают теперь) 2. Очень высокие накладные расходы: согласование соединения происходит в несколько последовательных этапов, и если в случае tcp это нужно делать 1 раз за соединение, то в случае udp протокол не предполагает, что пакеты образуют «соединение», поэтому пришлось бы, для обеспечения общности, делать 1 раз для каждого пакета.

anonymous
()

Есть смысл пробовать KCP вместо QUIC или им пользуются 2 калеки и функционала там меньше?

q0tw4 ★★★★
()
Ответ на: комментарий от Mike_RM

Где сейчас можно встретить UUCP?

Если я соглашусь, что нигде, это как-то поменяет смысл всего остального?

Bagrov ★★★★★
()
Ответ на: комментарий от beaver

Так сейчас он, получается, ни на чём не реализован? Или простым людям всё же можно его как-то поднять у себя?

Есть демонстрационные сервера для тестирования клиентов. Есть тестовая версия nginx 1.17.2, где должен уже быть.

P.S. Есть мозилловские клиент и сервер на расте: https://github.com/mozilla/neqo/

question4 ★★★★★
() автор топика
Последнее исправление: question4 (всего исправлений: 1)
Ответ на: комментарий от DonkeyHot

Извини, но ЯННП. Возможно, мне просто не хватает знаний.

Когда-то изучал, как TCP устанавливает соединение, контролирует доставку и выжимает максимально доступную скорость. Мне решения понравились, недостатков тогда не заметил. Впечатление осталось, детали позабыты.

Что плохо, например, в двух потоках? То, что они начинают конкурировать между собой? Возможно.

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

Про размер пакета в прикладных протоколах и эскейп-последовательности тоже не понял. Мне всегда казалось, что TCP всё равно, что у него там в теле, а экранирование - результат ограничений конкретного протокола или формата данных.

Bagrov ★★★★★
()
Ответ на: комментарий от Bagrov

это уже не байт-стрим?

Именно. Это всего лишь «можно туда затолкать».

Но туда можно затолкать всё, а стоит ли? Пример: диски хранят данные блоками. Сеть передаёт пакетами. Выше уровнем – клиенты с серверами обмениваются запросами/ответами. и пр*3. (почти)Никому не нужен этот байт. Есть тут ниша байт-стрима? Конечно – 1 есть общий делитель всех размеров. Однако это же и самый бесполезный ответ на вопрос «как делить».

TCP всё равно, что у него там в теле

Да, но программе - не всё равно. Отсутствие понятия «пакет данных»(который придёт весь или не придёт вообще), требует от той лишних действий. Представь, что твой терминал вывел полученное из сети \033чтото и соединение рухнуло. Байтовому терминалу было бы всё равно. А настоящему придётся искать «reset», или ждать пока он случайно наткнётся на что-то завершающее последовательность. Или программе придётся знать, что можно и что нелься печатать, повторяя ф-ии терминальной прошивки.

экранирование - результат ограничений конкретного протокола

Точнее – результат «байт-стрим»-подхода в любых непобайтовых применениях. TCP просто не исправляет допущенное «архитектурное решение».

Думаю, когда-то т.н. «системных программистов» не хватало нарисовать адекватный пакетный интерфейс, и они выгрузили проблемы на верхний уровень. А это не есть правильно – проблема общая и неспецифичная, ниже решение – всем лучше.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

Спасибо, теперь более-менее ясно с основаниями для оценки. Хотя, для полного понимания надо выучить какое-нибудь низкоуровневое программирование, хотя бы Си.

Скажи, если бы юниксовые пайпы были двоичными, как в винде, а не символьными, это бы как-то улучшило производительность в современном мире?

Bagrov ★★★★★
()
Ответ на: комментарий от Mike_RM
# apt-cache search uucp
extsmail - enables the robust sending of e-mail to external commands
rmail - MTA->UUCP remote mail handler
tua - The UUCP Analyzer
cu - call up another system
uucp - Unix to Unix Copy Program
uucp-lmtp - LMTP to UUCP gateway
uucpsend - Alternative Frontend for UUCP Batching with INN
praseodim ★★★★★
()
Последнее исправление: praseodim (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.