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

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

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

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

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

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

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

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

HTTP/3

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

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

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

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

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

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

https://habr.com/ru/company/qrator/blog/416633/

Кушайте на здоровье.

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

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

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

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

HTTP/3

Как это запустить на апаче?

Как это запустить на апаче?

https://http3-explained.haxx.se/en/proc-status.html Пока никак.

Если реально нужно, будет в nginx 1.17.

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

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

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

FTP уже все.

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

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

Доклады всё же интересней слушать: https://www.youtube.com/watch?v=6G2v5ni4VP0

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

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

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

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

Выкидывать 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.

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

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

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

tcp и udp ... оба уже давно заоптимизированы в ядре, и не в одном

Автор curl считает иначе.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ненужно это ваше HTTP 3. Есть HTTP 1.1, нормальный формат и не надо портить его.

Но очень хочется :)

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

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

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

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

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

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

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

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

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

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

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

Это как?

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

Это как?

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

Спасибо, хорошая фича.

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

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

будет в nginx 1.17

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

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

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

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

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

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

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

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

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

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

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

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

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

В чистом виде уже, похоже, нигде. А жаль, кстати.

Сам сайт dataforge — мысль интересная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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