В экспериментальные сборки Chrome Canary добавлена поддержка протокола HTTP/3, реализующего надстройку для обеспечения работы HTTP поверх протокола QUIC. Непосредственно протокол QUIC был добавлен в браузер пять лет назад и с тез пор используется для оптимизации работы с сервисами Google. HTTP/3 стандартизирует использование QUIC в качестве транспорта для HTTP...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51526
«Отсутствие проблем с блокировкой очереди TCP» — то есть если клиент не успевает обрабатывать данные с сервера, то это проблемы клиента? Или что?
HOL
Я правильно понимаю - если я сервисами гугла не пользуюсь, то нaxpeн мне не нужОн этот ваш хттп3?
На данный момент да. Более того, очевидные преимущества протокол дает только при нестабильном канале. Это либо мобильный интернет, либо связь на большие расстояния через большое количество узлов.
Не совсем так, в рамках одной TCP сессии могут передаваться данные разных потоков, для примера представьте, что данные первого потока передавались в сегментах 1 и 2, а данные второго потока в сегментах 3 и 4. Сервер направил четыре эти сегмента последовательно, но клиент получил только сегменты 1, 3 и 4. Теперь, пока не будет получен сегмент 2, обработка сегментов 3 и 4 будет не возможна, значит второй поток будет заблокирован, пока не будет обработан первый. Это и имеется ввиду в данном случае, с точки зрения TCP это единственно верное решение, поскольку не каких механизмов для разделения сегментом внутри одной TCP сессии нет. Есть SCTP в котором реализован механизм идентификации потоков внутри одного соединения, что избавляет от описанной выше проблемы, но Google решил создать QUIC.
> Заметный прирост производительности и пропускной способности, по сравнению с TCP.Только вот в ядре Linux у UDP diagram до сих пор высокий cpu-cost. Серверам нехило так поплохеет.
*datagram
простите за опечатку
Это только в пахомии сервера работают для серверов. Во всем остальном мире сервера работают для людей, т.е. клиентов сервиса. Так что если клиентам похорошеет чуть более чем поплохеет серверам - это стоит того.
во всем мире - может и работают. Только вот в гугле "клиентом сервиса" является NSA и прочие интересные ребята. А вы являетесь дойной коровой. И вас будут - доить.Я уверен, проблему с большей загрузкой cpu для отдачи udp с лихвой перекрывает меньшая нагрузка на инфраструктуру гугля за счет пропихивания этого udp в узкие каналы на клиентах. А что у них при этом дохнет телефония, отваливаются сетевые шары и тормозит почта - гугля совершенно не колышет.
Пьяный что ли? С каких это пор udp стал затратнее tcp?
Да. И это главная причина, почему у нас сейчас QUIC деплойнут для ~5% пользователей. Дорого.
Если бы так было, то щас бы linux лежал бы на помойке и работал бы на серверах. Я не понимаю, какого хрена в вашем понимании у UDP, накладных расходов для процессора больше, чем у TCP? Кажется вы профан, который написал это от балды на волне хейта всего нового. Вы наверное не в курсе, что у UPD нет целостности данных, нет коррекции ошибок, нет "рукопожатий", он не устанавливает соединение и не проверяет готовности получателя, он просто отсылает пакет по адресу, и т.д. Отсутствие этих вещей у UDP, по сравнению с TCP, делает его более быстрым и менее затратным. Наобарот, UDP по дефолту даёт меньшую нагрузку на процессор, чем TCP.
> Если бы так было, то щас бы linux лежал бы на помойке и работал бы на серверах.Да ты похоже умнее гугля и всех его профессоров. Они то глупые уже несколько лет стек udp переписывали под этот квик, а тут ты пришел и объяснил как надо.
Пдфка с описанием и результатами гуглится по словам Optimizing UDP for content delivery.
Иди расскажи им какой он был быстрый, менее затратный и прочее.
угумс. TCP - 2800 Mcycle/sec, UDP - 2801 Mcycle/sec
для тебя специально переведу: УДП протокол на 0.036% потребляет больше цпу при траспортировке.
там ни граммулечки сказано, про установку соединения и обработку ошибок.
То есть ты наконец нашел документацию прочёл её и....ни хера не понял. Смотреть TCP tso - 618. Это то что уже было в ядре. А к удп стеку они прикручивали точно таки же методы работы.
Иди дальше пдфку изучай.
Шо ты тут рассказываешь? Тут изначально про TSO разговора не было.
Да я самого начала не сомневался что у тебя дислексия ярко выраженная.
> Они то глупые уже несколько лет стек udp переписывали под этот квик, а тут ты пришел и объяснил как надо.Где тут про tso не упоминаем и не говорим?
Поднимемся вверх, может там что мы про tso и не будем обсуждать?
> Только вот в ядре Linux у UDP diagram до сих пор высокий cpu-cost. Серверам нехило так поплохеет.Опять никакого запрета на обсуждение tso и реальный отзыв о стоимости udp. И ниже мой комментарий про большие затраты и допиливание гуглом стека udp специально под квик.
PS. В прошлый раз ты несолько дней потратил на поиск в гугле и чтение одной таблички. Как видим ты и её прочесть не смог. Ну выводы то осилишь прочесть и понять? Или тоже перевести?
Taken together, segmentation offload, zerocopy and pacing
can considerably decrease cycle cost of serving content over
UDP to make it approximate the efficiency of TCP, which
has long had these features. UDP GSO shows a compara-
ble gain to TCP GSO, near 2x. Smooth delivery with pacing
lowers cpu overhead compared to userspace pacing and im-
proves goodput by lowering drops. Zerocopy further avoids
overhead from copying, 13% in the example workload. Full
application results are still out, but we are confident that these
improvements allow us to serve content with QUIC at consid-
erably lower cycle overhead using a standard UDP datapath,
compared to the earlier privileged packet socket based stack.
Вот на словах все хорошо. И безопастно и быстро. Если бы это кто то другой, а не гугл бы разробатывал я бы поверил. А так прям жопой чую как зонд где то там припрятан.
> прям жопой чую как зонд где то там припрятан.И давно это у вас?
С чего вы взяли, что припрятан?
Он не припрятан. Он извлечён и примкнут, и Гугл с этим зондом наперевес идет в атаку по всем фронтам.
Зачем вообще использовать зонды от Google? Уже лет 5 как перешел на Duckduckgo и не жалею, поиск хорош.
https://SearX.me наше всё (буквально, включая ваших уток).
Ошибка! Движки не могут получить результаты.google (unexpected crash: CAPTCHA required)
Пожалуйста, попробуйте позже или воспользуйтесь другим сервером searx.
выключи в настройках этот зонд и включи ддг, тогда searx станет удобной обвязкой с линками на веб архив и прокси. А для определенных сайтов будет ещё показывать количество сидеров, личеров и магнет-ссылку
Какой зонд?
google.com
гугл не требует капчу на менее популярных инстансах
https://github.com/asciimoo/searx/wiki/Searx-instances
и правда годнота, только в мобильный хромиум фиг добавишь его по дефолту
> А так прям жопой чую как зонд где то там припрятан.Правильно чуете, именно там он и припрятан.
С чего вы взяли? Мы ничего не прячем, эонд установлен надежно и имеет 10 см ручку для удобства использования!
А лучше бы иногда мозгами думать а не чувствовать задним местом. Я ни в коем случае не пытаюсь обелить G, они все же компания которая работает ради прибыли, но у них в патентах и открытых проектах много весьма годных вещей которыми успешно пользуется весь Интернет.
> компания которая работает ради прибыли,все компании работают ради прибыли, но не у всех прибыль - от 0% кредитцев спецслужбистов.
Некоторые ее получают, делая то, что людям на самом деле нужно, а не то что удалось им впихнуть.> но у них в патентах и
> открытых проектах много весьма годных вещей которыми успешно пользуется весь Интернет./мну задумался, что это могут быть за годные вещи (кроме хромога, которым, конечно, пользуется, поскольку выбора нет, но вовсе не потому что гугель сделал что-то хорошее) - и как-то надолго завис... Скорее приходят на ум многочисленные прожекты, которыми гугель пользует весь интернет.
lustre, патчи ext2, повсеместное просовывание ненужноv6, quick для уничтожения чужих браузеров ("чисто случайно чуть-чуть отличающийся от опубликованных стандартов, но мы уже исправили, через пять лет, когда конкурентов уже вообще не осталось") - либо не отдано в опен, либо так отдано что нахрен не надо, либо вообще надо одному гуглю...
> quick для уничтожения чужих браузеров ("чисто случайно чуть-чуть отличающийся от опубликованных стандартов, но мы уже исправили, через пять лет, когда конкурентов уже вообще не осталось")Стопудово. И будут лепить отмазы в духе того, как они мозиллу динамили - "ой, ашыбка, фсьо, фикс уже фпроде, ну на самом деле нет, но почти-почти" и так месяцами. А когда пофиксят - всегда можно выкатить новую версию..
Грустно всё это.
> Заметный прирост производительности и пропускной
> способности, по сравнению с TCP.угу, его ж лохи изобретали - вот щас гугель всем покажет как надо.
(подозреваю все банальное просто, как и со всеми udp-поделками - прекрасный прирост производительности за счет засирания канала аккуратно работающим клиентам. Забудьте о сохранении фоток на сетевой диск, пока смотрите порнуху с ютуба. Вы ж все равно однозадачны, типичный гуглоюзверь. Кончите, оботрете - потом фотки вашей пьянки будете сохранять.)
> Кончите, оботрете - потом фотки вашей пьянки будете сохранятьТо есть ты зря время не теряешь и диваешь одним выстрелом зразу два зверя?))
То есть ты зря время не теряешь и убиваешь одним выстрелом зразу два зверя?))
Fix: То есть ты зря время не теряешь и убиваешь одним выстрелом зразу двух зайцев?))
Первого ставим как глушитель и глушим второго
> его ж лохи изобреталиКогда в DARPA его изобретали, заботились о том, чтобы депеша из штаба полка в штаб дивизии дошла в целости и сохранности. а то, что миллиарды хомячков будут видосики на Ютубе смотреть - это тогда никому в голову не приходило.
Новые времена - новые задачи, новые инструменты.> прирост производительности за счет засирания канала аккуратно работающим клиентам
Про uTP в своё время то же самое говорили. И ничо, не умерли. Есть, правда, "нюанс" - финансовые возможности Гугла, Нетфлиха, Клаудфлары и кому там оно ещё будет нужно, немножко более другие, нежели у полулегальных торрент-помоек, у них наверняка найдётся чем простимулировать провайдеров и производителей железа прописать правильный QoS. Впрочем, пока живём, а там посмотрим.
> Когда в DARPA его изобретали, заботились о том, чтобы депеша из штаба
> полка в штаб дивизии дошла в целости и сохранности. а то,у твоей почты, к примеру, есть какие-то другие задачи? Или вон у поста на опеннете?
> что миллиарды хомячков будут видосики на Ютубе смотреть - это тогдатебе принадлежит ютруп? Тогда какое это к тебе имеет отношение?
> Новые времена - новые задачи, новые инструменты.
только это не твои задачи и не твои инструменты. В этом, собственно, и принципиальное отличие от арпанета - который взлетел только потому, что решал задачи тех кто его поднимали у себя.
> Про uTP в своё время то же самое говорили. И ничо, не
и сейчас говорим. И ничего, дропаем 90% (а кто и все сто), не паримся - любители обмазаться модным-современным и невменяйки - не являются платежеспособными клиентами (а иногда даже и благодарны - "у прошлого-то прова как запустишь торрент - веб не браузился, а у этого - браузится, наверное, у него канал лучше!"). А кто-то просто сдает их полиции. У умных выключен.
С ютрупом так не получится - поэтому пострадают вменяемые клиенты. За свои же деньги. Ну ок, улыбаемся и машем.
> полулегальных торрент-помоек, у них наверняка найдётся чем простимулировать провайдеров
> и производителей железа прописать правильный QoS. Впрочем, пока живём, а тамим не надо - их пользователи простимулируют.
А те, кому нахрен не сдалось - никуда не денутся, тоже заплатят.
Просто интернет у них будет работать немножечко хуже. А у тех у кого "интернет - это гугель" - ничего, в общем-то, в лучшую сторону тоже не изменится. Зато вредных полулегальных гадов, не желающих сдаваться самим и сдавать своих пользователей гуглефлари - в очередной раз прищемят. Их бы вот совсем от интернета отрезать, но пока у гугляфлари еще нет твердой уверенности, что получится. Но это уже ненадолго.
Если б ты чуть меньше надрачивал на свою гениальность и почитал rationale, понял бы зачем оно надо.
Горгулья называет это HTTP/3?
LOL. Я лучше на HTTP/2 останусь.
> Горгулья называет это HTTP/3?весь мир его называет http/3, поскольку мы просто купили ietf.
> LOL. Я лучше на HTTP/2 останусь.
тоже неплохо, напомним, кто его придумал и зачем. (чьи на самом деле проблемы он решает - а кому, наоборот, создает)
А я останусь на HTTP/1.0 мне там удобно запросы делать и ответы получать прям в консоли из кода на Си обычным wget, а все эти приблуды вроде видео уже давно идут по UDP от провайдера по multicast.
Иронично, конечно, до чего дошло развитие Интернета. Чтобы "сократить задержки" надо возвращаться к TDM и эмулировать его поведение поверх коммутации пакетов. Хотя стойте, где-то это уже было, ах, ну да, RTP.Ой, а ведь и для вебсокетов тут и там используются STUN/TURN/ICE. Что же это такое выходит WWW превращается в VoIP?
> --quic-version=h3-23
как бы намекает...
SCTP же. Просто заставить M$ запилить его поддержку в винде гуглу слабо, вот и навелосипедили что-то похожее поверх UDP.
Мне казалось, что венда тут не главное, главное поддержка вообще во всем L4 оборудовании.
>... главное поддержка вообще во всем L4 оборудовании.не, там вpoде чycтвительность к наличию NAT в силу много-хоминга
... ну и к качеству "головы прокси" между креслом и кодом;
тут насмотришься на код банальных сетевых TCP/UDP сервисов - волосы на ногтях начинают шевелиться
>Просто заставить M$ запилить его поддержку в винде гуглу слабо- это половина вопpoса, при желании могли бы пpoдaвить через куpaтopoфф
- вторая половина, это наличие гвоно-роутеров в норах абонентов - вот это слабо, поменять за свой счет(шмyгля) - "Значит так… Убивать аборигенов нехорошо, да? Но больше всего на свете акционеры боятся не шумихи в прессе, а дыр в финансовых отчётах" (L)пошли наиболее простым путем, эти бизнюки засрут UDP, как до этого зaгaдили..
Это ж прямо было сказано: продавить изменения в ядра всех ОС а потом заставить всех проапдейтить железки, которые десять лет жужжат без человеческого внимания невозможно. Поэтому будем ваять в юзерленде.
Эм, а в чём вы видите в HTTP/3 эмуляцию Time Devision Multiplexing?
> Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентовХехе. Когда MAC адресов показалось мало для создания сетей, придумали IP адреса. Потом появились мобильные хосты, которые мигрируют из одной подсетки в другую, и начался баттхёрт. И вот наконец у нас третья часть адреса -- идентификатор соединения, которая позволит прыгать по подсеткам сохраняя соединение, без всех этих костылей у опсосов, типа маршрутизации всего трафика через единый выходной узел.
Но проблема с отклонением реальности от идеальной модели OSI лишь усугубляется. Теперь маршрутизация выносится сетевого уровня на сессионный. Даже не на транспортный. Лол.
По-хорошему, давно пора было бы выпилить ipv4, перейти на ipv6, и следующим этапом запилить ipv8, чтобы маршрутизацию маршрутизировать на сетевом уровне. Но как всегда бизнесу и инженерам наплевать на архитектурно правильные и теоретически обоснованные пути, они будут костылями подпирать, пока не рухнет.
нормуль всё в ip4.
IP v6 -оверинжиниринг явный.
mac - вообще не причём и в разных медиа может быть разный
> нормуль всё в ip4.Да, конечно. И необходимость запиливать (в дополнение к MAC, IP и порту) ещё и идентификатор сессии, ради машршрутизации -- это самая отличная демонстрация тому. Ваши слова -- это явное проявление синдрома утёнка, того что высоколобые учёные называют импринтингом: ваш выводок не видел ничего кроме ipv4 и не едал ничего слаще редьки, и поэтому вы считаете, что ipv4 сделан как надо, а редька сладкая. Я очень рекомендую вам найти какие-нибудь способы преодолевать синдром утёнка, и вывести эти способы на уровень автоматического навыка (да, тут проскакивает ассоциация с Волдемортом из HPMoR[1][2]), иначе вы так и будете считать, что всё что есть хорошо и лучше быть не может, и вы никогда не сможешь сделать из-за этого ничего нового, что было бы лучше, чем то что есть. Вы даже не сможете улучшить старое, в лучшем случае вы сможете подпереть это старое новыми костылями. Да и то не факт: чтобы подпирать костылями, надо сначала признать проблему проблемой достойной решения, а запущенный синдром утёнка препятствовует этому.
> IP v6 -оверинжиниринг явный.
> mac - вообще не причём и в разных медиа может быть разныйНе причём? Или при чём? Я поискал и нашёл вам для повышения образованности статью[3]. Там разбирается история костылестроения в сетях ipv4, которая привнесла те костыли, которые вы считаете нормой, просто потому что вас учили тому, что так надо. И там же разбираются некоторые проблемы с ipv4. Из которых проблема нехватки адресного пространства -- лишь одна из минорных проблем.
Я по диагонали эту статью прочитал, поэтому обещать не буду, но, по-моему, она описывает даже почему ipv6 это ещё не оверинжиниринг: ipv6 не решит всех проблем.
Почитайте обязательно, если с английским туго, читайте через гуглотранслейт. Иначе слово "инженеры" в вашем поле для ника так и будет трёхбуквенной надписью на заборе, за которым злая собака. То есть надписью совершенно не соответствующей действительности.
Вас учили тому, что IPv4 -- это хорошо и прельстиво, но и теперь вы защищая ipv4 вы защищаете честь дедов, разработавших ipv4. Но вас учили не деды, а лохи педальные, которые не разрабатывали ipv4, они в лучшем случае справились понять, как ipv4 работает. Вас учили люди, которые точно так же жертвы синдрома утёнка. И защищая IPv4 вы защищаете их честь, а не честь дедов разработавших IPv4. Чтобы не попадать в такую ситуацию в будущем -- всегда уделяй время исследованию истории технологии и выяснению того, почему технология создана именно такой, почему было принято то или иное архитектурное или техническое решение, какие ещё варианты были и почему они были отвергнуты. Тогда твоё восприятие технологии будет гораздо ближе к восприятию создателей технологии, чем в том случае, если ты просто начитаешься текстов с заголовками "best practices" и решишь, что на этом образование закончено.
[1] http://www.hpmor.com/
[2] https://hpmor.ru/
[3] https://apenwarr.ca/log/20170810
да ты офигел
тут панимаешли люди сидят на триджы переписанном унипсе от дедов неосиляторов мультикса
всем довольны и восхваляют его и пророчат вендокапец
Переходить надо на ipv12, а лучше - сразу на ipv16 или даже (чего мелочиться) ipv256.
> Переходить надо на ipv12, а лучше - сразу на ipv16 или даже
> (чего мелочиться) ipv256.Сразу не получится. Теоретически можно было бы, но практически Internet огромен, чтобы изменить его требуются зиллионы человеко-часов. Интернет распределён, в том смысле что нет единой организации, которая владела бы всей инфраструктурой, и могла бы организовать быстрый (то есть за несколько месяцов) переход на другие технологии. Поэтому переход надо выполнять пошагово, так чтобы следующая итерация развития технологий могла бы сосуществовать с предыдущей. И поэтому _сразу_ на ipv256 не удастся, не удастся даже сразу на ipv8.
>а лучше - сразу на ipv16 или даже (чего мелочиться) ipv256Под номер версии IP отведено всего 4 бита.
UDP это хорошо. DNSCrypt UDP даже с заблокированным мобильным интернетом работает, например.
> UDP это хорошо. DNSCrypt UDP даже с заблокированным мобильным интернетом работает, например.это не ваша заслуга, это наша недоработка.
Как только мусорного udp-траффика станет заметное количество - youtube у вас работать будет (он с cdn коробки прямо в нашей стойке работает) а эта хрень - вообще перестанет.
Да какого черта? Только недавно HTTP/2 пропихнули, а теперь тройка. Что ж им все неймется-то заменять работающие вещи. HTTP 1 был прекрасен и всегда будет в наших сердцах
HTTP/«3» это обманка.
Да хрен с ними, пусть чего угодно пропихивают. На фронтендах для желающих можно прикрутить. А на бекенде как был HTTP/1.1 + Connection: close, так и останется.
А сервера то с HTTP/3 есть, или только у гугля?
H2O 2.3.0-devel должен уже работать. По-крайней мере вот здесь работает https://h2o.examp1e.net/
Akamai, Cloudflare CDNs предлагают. Если у вас один сервер, то вам HTTP/3 вообоще ни к чему.
Действительно, что это я о себе возомнил. "Официальные" стандарты решил использовать для работы и изучения. А оказывается оно мне ни-к-че-му. Понимаю:
У кого нет миллиарда серверов - пусть идут в ж@пу(с)
> Действительно, что это я о себе возомнил. "Официальные" стандарты решил использовать для
> работы и изучения. А оказывается оно мне ни-к-че-му. Понимаю:
> У кого нет миллиарда серверов - пусть идут в ж@пу(с)Достаточно просто не использовать. Есть огромное множество стандартов, которые вы не используете, и ничего.
Но удерживать от похода в ж@пу никто никого не будет, конечно.
Нет я понимаю, глядя за кого топишь, - ты на подсосе у корпов. Но мог на опеннете такой камингаут не делать. А отсылка к полонскому была сделана не случайно. Он тоже подобное кричал и чем всё кончилось? Это намек таким как ты, чем всё может обернуться.> Есть огромное множество стандартов, которые вы не используете, и ничего.
Всё что было признано стандартом по рфсшно-иетефовским методичкам, до недавнего времени, имело реализацию. Хоть вагон реализаций на выбор. Хочешь платные, хочешь бесплатные. Теперь их просто не будет насколько я наблюдаю, только у корпорасов в аренду.
Так, шапочки из фольги это не ко мне. Да и кто такой Полонский, я понятия не имею.
Какое прекрасное нагуглилось пока искал по этой теме документацию и обсуждения https://habr.com/ru/company/qrator/blog/416633/
Фееричный подход. Даже комментировать нечего. Там просто состояние всей ит-индустрии описано.
Угу. Абырвалг, agile, признание Америки, ещё парочку...
А ведь если по чесноку, то вся продукция гугла — конченный мусор. Начиная с наглухо зацензуренного поисковика, заканчивая хушей ОС всех времён и народов, ведроидом.
Как раз таки поисковик и ведроид - хороши. Всё остальное - отстой.
Что там хорошего? Поисковик за последние несколько лет испортился. Ведроид - по откручивали всё что можно и некоторые фичи для пользователей искоренили.
> Поисковик за последние несколько лет испортилсяЧем он испортился-то? Очень неплохо ищет то, что надо, гораздо лучше ряда альтернатив типа уткошлёпа и херандекса.
Всем вообще-то испортился. У нескольких коллег спросил - такого же мнения придерживаются. Ту информацию что раньше гуглилась на первой, максимум второй странице, теперь совсем не видно. Ключевые слова те же, поисковик тот же - ссылки нужной нет. Смешно, но яндекс уже такой же по поиску если не лучше. И яндекс не зассал снизу ссылку поместить - поискать на гугле.
Всегда найдется кучка маргиналов из многомилионной аудитории самого популярного сервиса, которые будут постоянно ныть, что всё испортилось, но при этом не давая конкретики. Напиши им отзыв, что у коллег плохо ищет цп, тут не сайт поддержки.
Мамка то не заругает что ты с взрослыми дядьками в интернете общаешься? Ну вот судя по твоей идее искать ЦП в гугле уровень развития виден.
>> Поисковик за последние несколько лет испортилсялет 7 - все еще "несколько", ога
> Чем он испортился-то? Очень неплохо ищет то, что надо, гораздо лучше ряда
тем что предпочел использовать данные слежки для угадава что подсунуть пользователю. А когда их не хватает - подсовывает какую-то чушь, хуже утки.
сидя за натом с тысячей совершенно далеких от it хомячков и с параноидально настроенным браузером - периодически получаю просто пустую страницу на банальный запрос.
впрочем, утка _тоже_ давно уже явно использует пусть и обезличенные результаты слежки, а не улучшает алгоритмы ранжирования - зачем, проще просто пробросить запрос хернядексу.
> Чем он испортился-то? Очень неплохо ищет то, что надо, гораздо лучше ряда
> альтернатив типа уткошлёпа и херандекса.Плюсы-минусы, кавычки в запросах – часто просто игнорируются.
Так же заметен был "улучшайзинг", когда стали вместо "найдено 0" или "столько-то результатов по этому запросу - возможно вы имели в виду <видоизмененный запрос от гугла, нужно жмякнуть ссылку>" стали сразу подсовывать результат "альтернативного" запроса-предложения от самого гугла (того самого "возможно вы имели в виду").И теперь, сц*ко, невозможно отличить "0 результатов" по точному запросу, от выдачи "возможно вы искали вот это".
Причем, есть подозрение, что срабатывает вот эта вот "умная выдача альтернативы" и при количестве найденного немного > 0. При этом забивая эти точные результаты поиска куда-то на пятую-десятую страницу общего. Зато теперь по запросу выдается сразу много всего, поиск улучшили , уррраа!Ну и по мелочи - фильтры без JS вообще уже никакие не выставить, фильтация по дате и языку становятся все более бесполезной, поиск по коду (удобнейшая штука: https://web.archive.org/web/20101112131244/http://www.google... ) так и не починили после 2011 (ну да, туда же рекламу продукта особо не впихнуть) ...
> решающей проблемы с большим временем установки и согласования соединений в TCPТакая проблема только в головах гугловцев.
> и устраняющей задержки при потере пакетов в процессе передачи данных
Опять враки.
Лучше бы запилили какое то расширение для TLS чтобы повторные соединения могли приходить уже без согласования.
Получилось бы ровно тоже самое но без кучи ненужного кода, и сразу в ядре.
Что-то вроде такого:RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
«2.2. Resumption and Pre-Shared Key (PSK)
Although TLS PSKs can be established out of band, PSKs can also be established in a previous connection and then used to establish a new connection ("session resumption" or "resuming" with a PSK). Once a handshake has completed, the server can send the client a PSK identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1). The client can then use that PSK identity in future handshakes to negotiate the use of the associated PSK. If the server accepts the PSK, then the security context of the new connection is cryptographically tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
PSKs can be used with (EC)DHE key exchange in order to provide forward secrecy in combination with shared keys, or can be used alone, at the cost of losing forward secrecy for the application data.»
Или вы имеете ввиду что-то другое?
Так tls 1.3 - 0-RTT (early_data) - именно про это !
> Что-то вроде такого:
> RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
> «2.2. Resumption and Pre-Shared Key (PSK)
> Или вы имеете ввиду что-то другое?Да, видимо что то такое.
Что вообще практически убивает все преимущества HTTP2.
Краткое содержание новости: гугель добавил протокол, разработанный гугелем, в браузер, тоже разработанный гугелем.
> Краткое содержание новости: гугель добавил протокол, разработанный гугелем, в браузер,
> тоже разработанный гугелем.для решения проблем во внутренних процессах - гугля.
А nginx пока ни QUICK, ни HTTP/3 не умеет... Кому нужен протокол, для которого нет ни одного нормального фронтенд-сервера?
What’s Coming in NGINX 1.17Development has also started on support for QUIC and HTTP/3 – the next significant update to the transport protocols that will deliver websites, applications, and APIs. This is a significant undertaking, but likely to arrive during the NGINX 1.17 development cycle.
Ну пусть пытаются, чё. Скорость с которой гугл может выкатывать новые версии quic-http/3 для пользователей очень большая. Что там делать то - обновил всем броузер, обновил свои сервачки и всё. У других компаний просто нет возможности повторения текущего "стандарта". А после обкатывания они в ietf всё примут, конечно. Только кроме гугля и нескольких приближенных компаний остальным ловить нечего.
Выгоды HTTP/3 в более быстром прохождении last mile. Если у вас один сервер (10 серверов, 100 серверов), то он вам вообще не нужен. Он нужен CDN-ам.
> А nginx пока ни QUICK, ни HTTP/3 не умеет...Nginx разрабатывался не для этого.
Пускай назовут ЭТО gHTTP и тогда пофиг какая версия -- никто не будет за ними гоняться,
> Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.Forward Error Correction, насколько я знаю, так и остались красивой идеей, которая не работает (в QUIC/HTTP3) и сейчас отключена.
Суть такова. Если, например, теряется один пакет из 10-ти, то можно передавать 11 пакетов и восстанавливать потерянный. Однако, восстановить его можно будет только получив все 11 (точнее 10, т.к. один потеряли), но пакеты из начала передачи проще восстановить передав их повторно (так информацию получится прочитать быстрее, ибо не нужно ждать все 11 пакетов, чтобы восстановить 2-й, например). Если передавать пакеты коррекции чаще, то повышается трафик. Однако, гораздо чаще случается потеря нескольких пакетов подряд (щас большая часть трафика идет по радио: WiFi, мобилки) и тогда FEC еще хуже работает. Потому что нужно читать данные с минимальной задержкой и не сильно увеличивать трафик. И тут проще быстро обнаружить потерю (ACK, NACK) и передать повторно, чем ждать всю пачку пакетов.
Теорию довольно хорошо описывают мейлрушники, разработавшие свой велосипед на тех же принципах (там довольно подробно описаны разные варианты восстановления потерянных пакетов и почему FEC не работает, точнее другие варианты лучше):
С сервером отдачи трафика ладно, не больно надо. А вот прокси для этого HTTP/3 уже есть у кого-нибудь в решениях? На что смотреть организациям для выпускания сотрудников в интернет?
Нету. Почитай спецификацию, там много заморочек заточенных под мобильных пользователей, у которых меняется адрес, а пересогласовывать соединение не хочется, и у которых возможны потери. Офис это другое.Не смотри на HTTP/3 как на замену HTTP/1(.1), он скорее призван его дополнять.
https://habr.com/ru/company/qrator/blog/416633/ Это песец. Гугл принимает стандарты строго под себя.
> https://habr.com/ru/company/qrator/blog/416633/ Это песец. Гугл принимает стандарты
> строго под себя.в статье 2018 год и, например, упоминается, что QUIC плох для вайфая и мобильного инета, а в этой новости упоминается что как раз хорош для вайфая и мобильного
видимо за это время сильно переписали протокол и, вероятно, статья стала (частично) не актуальной
Вы статью-то внимательно прочитали? А соседние, по экспериментам других людей с udp? Да, там всё хорошо и быстро только в идеальном мире. В реальных условиях в куче ситуаций работает хуже чем "окаменевший" tcp. Это результаты реальных измерений, а не методички от гугля. А в данный момент просто смирились и никто ничего не тестирует. Пользуются рекламными проспектами и рассказывают - ну гугл то не будет врать, в новости же написано. Кто вам наивным реальные данные то покажет, хех? Вот такие вещи практически не встречаются https://www.cisco.com/c/dam/en_us/solutions/industries/docs/... . Сейчас просто заказывают сторонним фирмам исследование и они выдают три листочка с словами вай-как-хорошо-стало. Круговое накидалово.
>> https://habr.com/ru/company/qrator/blog/416633/ Это песец. Гугл принимает стандарты
>> строго под себя.
> в статье 2018 год и, например, упоминается, что QUIC плох для вайфая
> и мобильного инета, а в этой новости упоминается что как разну так эту новость - мы писали. А ту - какие-то инженеры какого-то вшивого qrator. Надо, кстати, подкрутить поиск, чтоб они вообще никем и никогда не находились, а то ишь, умные...
Все правильно - хорош, для НАС. А пользователя того вайфайя и тем более его оператора нам не жалко вот совсем.
А как браузер понимает, что нужно именно по udp подключаться? Сначал по udp пытается, а потом по tcp? Разве это не будет к дополнительным задержкам при подключении к 99% сайтов?
Браузер заходит по https, как обычно, и в ответ получает в заголовке информацию, что он также доступен через QUIC. Открой в браузере пустую вкладку, зайди в инструменты отладки и открой google.com. После редиректов увидишь при подключении по https в заголовке ответа:alt-svc: quic=":443"; ma=2592000; v="46,43,39"
Дальше браузер сам решает оставаться ему на https или переключаться на QUIC (HTTP/3).
Если хочется больше деталей - то ищи сам (статьи или читай спецификацию).