Компания Cloudflare открыла исходные тексты проекта Quiche (https://docs.quic.tech/quiche/), в рамках которого подготовлена реализация протокола QUIC, написанная на языке Rust и соответствующая 17 черновому варианту спецификации, находящейся в процессе стандартизации (https://www.opennet.ru/opennews/art.shtml?num=49594) в IETF. Код открыт (https://github.com/cloudflare/quiche) под лицензий BSD. Примечательно, что реализация QUIC от компании Google также развивается под именем QUICHE (https://quiche.googlesource.com/quiche/).Реализация предоставляет API для обработки пакетов QUIC и управлния состоянием соединения. В текущем виде поддерживается согласование версий, TLS 1.3 (на базе BoringSSL), Stream API, управление потоком, оценка потери пакетов, контроль перегрузки (congestion control), обновление ключей, однонаправленные потоки, 0-RTT, сброс состояния и миграция соединений.
Кроме того, проектом Quinn (https://github.com/djc/quinn) отдельно развивается ещё одна реализация QUIC на языке Rust. Код поставляется под лицензией Apache 2.0. По функциональности Quinn также нацелен на повторение 17 черновика спецификации, но пока по возможностям отстаёт от реализации Cloudflare. Например, пока не поддерживается 0-RTT и передача HTTP поверх QUIC (HTTP/3). Слой шифрования реализован при помощи rust-библиотек rustls (https://github.com/ctz/rustls) и ring (https://github.com/briansmith/ring). Подготовлены экспериментальные варианты сервера и клиента для QUIC.Напомним, что протокол QUIC (https://www.chromium.org/quic/) (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. Рассматриваемый протокол уже интегрирован в серверную инфраструктуру Google, входит в состав Chrome, запланирован (https://www.opennet.ru/opennews/art.shtml?num=48312) для включения в Firefox и активно применяется для обслуживания запросов клиентов на серверах Google.
Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...) QUIC:
- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);- Контроль за целостностью потока, предотвращающий потерю пакетов;
- Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);
- Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;- Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.- Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
- Отсутствие проблем с блокировкой очереди TCP;
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;- Возможность подключения расширенных механизмов контроля перегрузки соединения;
- Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
- Заметный прирост (http://web.cs.wpi.edu/~claypool/ms/quic/quic-thesis.pdf) производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
URL: https://news.ycombinator.com/item?id=19016466
Новость: https://www.opennet.ru/opennews/art.shtml?num=50061
Я бы побоялся сувать ржавчину в продакшен. У знакомого изза его испоьзования ядро начало тихо сегфолтится.
Использования где? В ядре?
Rust как бы безопасный язык, решение задач, подобных QUIC, ему самое то.
"безопасный" растаман?))) нет ни одного безопасного языка. есть безопасное его применение.
Безопасный в плане работы с памятью. Разумеется можно развести демагогию на этот счет
Условно безопасный и только в плане динамического выделения памяти, без всяких гарантий безопасности при её нехватке. Для ответственных систем Rust безопасности не добавляет, ибо в них не выделяют память динамически.
Безопасного применения не существует в принципе.
> Rust как бы безопасный язык
> как быВ чём же его отличие от безопасного?
Безопасный язык не тьюринг-полный, поскольку не позволяет выстрелить в себе в ногу. При этом растаманы уверены, что их раст безопасный.
> Я бы побоялся сувать ржавчину в продакшен.всем по%#й. Современный "продакшн" состоит из кривых и гнилых костылей чуть более чем полностью. Одним больше, подумать только.
> У знакомого изза его испоьзования ядро начало тихо сегфолтится.а потом еще и брат умер?
>> У знакомого изза его испоьзования ядро начало тихо сегфолтится.
> а потом еще и брат умер?а в итоге потерялись исходники.
А ты, прости, кто такой? Чьих будешь?
Сначала лилякс на раст перепеши потом говори про свои корки из-под ядра.
Потратьте время, поучите раст. Даже если вам не понравится, вы так больше говорить не будете.Прелесть раста в том, что в нём сложный процесс написания кода. То есть, вы часть ошибок ловите еще до этапа компиляции. То есть, вы вынуждены больше думать наперёд и в итоге получаете меньше проблем.
Например вы пишите на кое-чём другом, Потом тестировщик, к примеру, ловит null-pointer exception. Он тратит время на заведение бага. Потом вы тратите время на починку бага. Потом снова он тратит время на перепроверку... как обычно в общем.
А тут null-значения просто нет. И таких фишек много.
Да-да, такой офигенный язык, что в нем банальный doubly linked list без unsafe-а сделать невоможно.
Ну так в неофигенных языках ничего без unsafe-а сделать невоможно.
unsafe позволяет локализовать небезопасную работу с памятью. Подавляющая часть кода будет safe и будет работать с готовыми оттестированными контейнерами и алгоритмами.
Истину глаголете. Грепнул свой игрушечный проект компилятора на 3578 строк кода (без учёта комментов и пустых строк) - нашёл 4 unsafe однострочника, один из которых - вызов libc::isatty(). Аналог на C++ пишется так:// unsafe {
... // 7000 строк кода, потому что pattern matching и прочий сахар - для слабаков
// }Потом нихера не работает, проходимся GDB и Valgrind'ом по проекту и находим 20 тупых багов, 7 хитрых, а оставшиеся 2 очень хитрых находим только через две бессонные недели, после чего идём к психотерапевту и две недели пьём феназепам.
Smart pointers в C++ полностью эквивалентны Rust-овским боксам/рефкаунтам.
> Ну так в неофигенных языках ничего без unsafe-а сделать невоможно.Эмм, в той же Жабе ConcurrentLinkedQueue без всяких unsafe, всё на атомиках.
Всё прекрасно возможно:https://bluss.github.io/ixlist/target/doc/ixlist/struct.List...
> Всё прекрасно возможно:
> https://bluss.github.io/ixlist/target/doc/ixlist/struct.List...List is a doubly linked list stored in one contiguous allocation.
O(1) insert and remove both at front and back.
O(1) insert anywhere if you have a cursor to that position.Ого. Да. Это прекрасно.
https://bluss.github.io/ixlist/target/doc/src/ixlist/lib.rs....
> https://bluss.github.io/ixlist/target/doc/src/ixlist/lib.rs....синтаксис жесть. даже плюсы намного читабельнее.
говно ваш код, если вы нул поинтер пустили на stagingа по-хорошему будь девы не криворукие, то qa макаки бы вымерли
> говно ваш кодНет - ты.
> говно ваш код, если вы нул поинтер пустили на stagingПардон, а где его собственно ловить, если не на стейджинге? Стейджинг собственно на то и нужен, чтобы отлавливать такие вот гадости перед отправкой на прод. =)
Пришли разработчики к филину и говорят:
— в наших программах бывают нуль-поинтеры, как их избежать?
Задумался филин, после чего изрёк:
— станьте Александреску!
Разработчики возразили:
— но тогда наши исходники смогут прочесть только Кнут, Моррис и Пратт.
Разозлился филин:
— я не тактик, я стратег!
Сделал моё утро! =)
Два чаю этому анониму!!
Три чая!
>> говно ваш код, если вы нул поинтер пустили на staging
> Пардон, а где его собственно ловить, если не на стейджинге? Стейджинг собственно
> на то и нужен, чтобы отлавливать такие вот гадости перед отправкой
> на прод. =)Локально дружище, локально, во время development ))
На стейджинге надо ловить совсем другие баги, например race condition, deadlock.
Явно не нул поинтер.. это дно как по мне.Но это явно не песня про афте-курсников "стань программистом за 3 недели".
Как бы то, куда катится индустрия и акутуальное качество кода обсуждать можно бесконечно.
> Локально дружище, локально, ...А еще лучше писать без ошибок, предусмотрев все требования, которые будут натягивать на Ваш проект как сову на глобус через пару лет
> Локально дружище, локально, во время development ))
> На стейджинге надо ловить совсем другие баги, например race condition, deadlock.
> Явно не нул поинтер.. это дно как по мне.Лично я думаю, дружище, ты чего-то передёргиваешь. Попробуй стейджинг хорошенько фаззингом побить -- у тебя не то, что null pointer, у тебя и более глупые вещи обнаружатся. =)
На то он, собственно, и стейдж! )))
>> Локально дружище, локально, во время development ))
>> На стейджинге надо ловить совсем другие баги, например race condition, deadlock.
>> Явно не нул поинтер.. это дно как по мне.
> Лично я думаю, дружище, ты чего-то передёргиваешь. Попробуй стейджинг хорошенько фаззингом
> побить -- у тебя не то, что null pointer, у тебя
> и более глупые вещи обнаружатся. =)Не-не.. избавьте, нет у нас таких проблем.
> На то он, собственно, и стейдж! )))
Тут каждому своё, я лишь сказал как это на мой взгляд должно быть.
> поучите растРискну предположить, что он пытался, но каждый раз когда он заканчивал его изучать, на сайте мозиллы уже лежала новая несовместимая версия. Пусть они СНАЧАЛА закончат этот язык, ТОГДА мы посмотрим, стоит ли он изучения. А то выкатили какую-то постоянно меняющуюся альфу и предлагают при разработке софта скрестить пальцы и надеяться, что через два года не придётся переписывать 75% системы.
P.S. Хотя, при всей язвительности моего комментария, сама новость позитивная. Наконец-то на расте вышло что-то кроме домашних поделок изучающих его студентов, переписок нормальных, сишных софтин или куска от движка браузера, созданного самим разработчиками раста.
Посмотри rfc, двоечник. Ну и не делаей проектов на найтли, если собираешься релизиться послезавтра.
Чё, Rust уже Proposed Standard? Номер RFC в студию!
А где RFC других языков программирования? Лол.
RFC невсегда но вот ISO/IEC 30170:2012
Откуда вы это взяли-то? Может по началу так и было, но сейчас раст уже достаточно стабилен и ничего подобного не происходит.
"Достаточно стабилен" c базовой функциональностью вроде генератора случайных чисел в крейтах с версиями 0.x.
И это они ещё не пробовали реализовать на расте серьёзный GUI, что может потребовать добавления в язык поддержки полноценного ООП.
На Rust идеально ложатся новые data-oriented подходы к UI, ООП — небезопасный, лапшеобразный прошлый век
>Прелесть раста в том, что в нём сложный процесс написания кода. То есть, вы часть ошибок ловите еще до этапа компиляции. То есть, вы вынуждены больше думать наперёд и в итоге получаете меньше проблем.писал я на этой вашей ржавчине. Действительно, там где в сях приходится внимательно курить документацию или (в большинстве случаев) исходники в попытках понять, насколько это потокобезопасно, в ржавчине ты тупо видишь Send+Sync и все.
Однако, если увлекаться итераторами, динамическими диспетчеризациями и всякими функциональными штуками, то на выхлопе ты получишь в 2 раза больше ассемблерных инструкций, чем в сях. И оптимизировать это нифига не просто. Т.ч. в любом случае все сводится к тому, насколько ты хороший программист и понимаешь, что делаешь.
Но если браузер на ржавчене, что бы и протокол на ней не написать?P.S. Что мне нравится в картинках описывающий протокол, это та уверенность авторов, что клиенту в принципе не надо ничего от сервера и все пакеты будут только в одном направлении. Вот зачем они так рисуют?
они работают в факинбуке, а там действительно клиенту ничего не надо от сервера - он подставляет рот, в который большим напором заливаются помои.Что именно - выбирает не клиент.
Скорее всего у вашего знакомого AMD вместо процессора. Это известная проблема, от которой AMD продолжает морозиться...
Если так, то о каком продакшене вообще можно говорить?
Шикарно. Вангую внедрение i2p будет HTTP/4, т.к. повсеместные блокировки и нарушение сетевого нейтралитета - бич современного интернета.
А мне нравится http/3. Просто тем что udp. Впнки по udp шустрее бегают. Прятать проще. Сразу скажу что бы не ныли самодержавцы, не только в этой стране, не только от властей.
И IPTV по udp работает значительно стабильнее...
IPTV - особый случай. Во-первых, потерять данные там вполне норм, посыплется картинка, ну и ладно. Во-вторых, UDP позволяет использовать мультикаст. В-третьих, дело скорее не в транспортном протоколе, а в том, что провайдер настроил QoS для собственного IPTV.
Утилизация сети TCP значительно падает при даже единичных по потерях пакетов. Поэтому на TCP любая мелкая нестабильность проявляется в виде длительной задержки воспроизведения.
Google применили QUIC в youtube именно для решения этой проблемы в первую очередь.
Очень зависит о congestion protocol. Как бы не bic единым.
Стабильнее и удобнее для хомяка когда иптв идёт юникастом по хттп.
хомяк все равно не видит разницы - даже если терять ему каждый пятый кадр, главное, чтоб софт в вумном телевизоре к этому был приучен.так что не парься, гони по udp.
Я то как раз гоню по хттп и не парюсь в тем как оно через роутер пройдёт, как это телеку скормить и как оно там по вафле ходит.
Как только заработает более или менее массово, я думаю, внедрят это в тор и сетевые задержки сети резко уменьшатся. В тор эффект будет поболее всяких ютубов...
Оборот гуглотрафика в разы уступает тору? Инфа 100%?
оборот всего интернета в несколько раз уступает тору. но куда тебе, хомяку, пытаться это осознать
Сильное заявление. Интересно, сколько секунд потребуется тытрубе и нетфликсу, чтобы сгенерировать годовой трафик школотора?
Секунд? Переоценили тор)
В тор.. rtfm.
Т упрт?
Если синтетических задержек не будет, построить ±точную карту сети тор будет делом секунд для организации, держащей больше половины relay или exit нод.
Не смотря на предупреждения на позапрошлом ccc, авторы тора внесли изменения, касающиеся latency и request rate в код onion router. Обратные пачти были накачены буквально на днях. Видать, основным спонсорам проекта эта функциональность более не нужна.
Cloudflare как всегда "радует". Протокол ещё не зарелизился, а они уже реализацию выкладывают. Буквально нет ещё финальной спецификации. То, что есть сейчас может ещё измениться. И может пойти в разрез с реализацией.Но им не впервой. Шифрование доменов в TLS тоже только в черновике, а они уже реализацию выкатили. Зачем, спрашивается, бежать впереди паровоза?
норм, потом найдут архитектурные дыры и выпустят QUICv6и все мы будем один хрен жрать кактус
У нас много свободных ресурсов, за день до релиза стандарта мы уже напишем все.
> Cloudflare как всегда "радует". Протокол ещё не зарелизился, а они уже реализацию выкладывают.А протокол-то кто по-вашему пишет? Собственно, сначала драфт, потом реализация, затем стандарт. Это норма.
Cloudflare - новый гугл, вытаскивают самые модные-свежие технологии в продакшн.
HTTP2, Brotli, TLS1.2, acme/letsencrypt - CF давал возможность пощупать их раньше, чем они появлялись в nginx/haproxy/etc в релизах.
Через этих парней идет огромный поток http-трафика, почему бы не щупать на них новые технологии?
Теперь вот TLS1.3.P.S. За один только 1.1.1.1 уже можно им быть благодарным, он существенно лучше гугловых 8.8.8.8/8.8.4.4 даже в самых удаленных точках интернета.
> Теперь вот TLS1.3.Простите, заговариваюсь. Теперь вот QUIC, он же - потенциальный HTTP/3.
А уж за 1.1(1.0.0.1) вообще памятник всем сотрудникам, очень удобный для пинга адрес.
> Cloudflare - новый гугл, вытаскивают самые модные-свежие технологии в продакшн.
> HTTP2, Brotli, TLS1.2, acme/letsencrypt - CF давал возможность пощупать их раньше, чем
> они появлялись в nginx/haproxy/etc в релизах.
> Через этих парней идет огромный поток http-трафика, почему бы не щупать на
> них новые технологии?
> Теперь вот TLS1.3.
> P.S. За один только 1.1.1.1 уже можно им быть благодарным, он существенно
> лучше гугловых 8.8.8.8/8.8.4.4 даже в самых удаленных точках интернета.К LE и к Brotli они не имели отношения.
Я тебе раскрою секрет: никто в здравом уме не будет сначала писать спецификацию, и только затем создавать реализацию. Надо быть самоуверенным на уровне Даннига-Крюгера, для того, чтобы пытаться таким образом создавать реализации. Прежде чем утверждать драфты спецификации, надо провести полевые испытания её, а это невозможно без реализации. То есть сначала реализация, затем спецификация -- это гораздо более надёжный подход.Хотя в реальности делается несколько иначе: драфты спецификации и реализации развиваются параллельно. Это позволяет найти косяки в спецификации на ранних этапах, и в то же время даёт возможность видеть целостную картину, то есть видеть, что примерно получится в итоге.
И решение клаудфара выкатить реализацию в паблик -- это решение свалить задачи тестирования драфта спецификации на широкие массы заинтересованных. Если есть реализация, то что мешает мне поднять тестовый сервак и посмотреть, как вообще это работает. Увидеть косяки и пойти задать вопрос "что за...". Широкие массы могут придумать гораздо большее количество юзкейсов, чем разрабы спецификации, они могут начать использовать реализацию за границами применимости, и может оказаться, что спецификацию/реализацию несложно пофиксить с тем, чтобы расширить границы применимости. То есть это очень продуманное решение.
Но есть ещё один нюанс: когда будет выпущен и утверждён финальный вариант спецификации, у клаудфара уже будет реализация, которая была широко оттестирована, может быть даже не только на тестовых серверах, но и на вполне себе рабочих.
> Зачем, спрашивается, бежать впереди паровоза?ты не понял, чувак - они и есть этот самый паровоз. Финальные спецификации потом под них же и напишут - при их непосредственном участии. Так как им будет удобно.
Очередная порция вранья от гугла.1. низкий ртт и препуш нужен только дудлу и ещё паре рекламных сетей, так они смогут повысить показы рекламы, а то хомяк может свалить раньше, а то и вовсе у него в днс домены с рекламой заблочены а тут ему сервер сам всё что "надо" отправит раньше, чем будет обращение к днс.
2. контроль перегрузки - так тцп имеет историю огромную и там оно тоже достаточно вылизано, в том числе и дудлом.
3. попытка проскочить мимо шейперов, которые умеют тцп и не умеют квик
4. а какой зоопарк будет в софте: ведь каждая софтинка которой нужен этот убогий протокол должна где то найти либу с ним или притащить с сбой
5. из за крипты повышенная нагрузка на проц даже там где крипта не впёрлась ни разу
6. браузер по тцп может и рожает пачку соединений, и хотя это несколько дольше, но в итоге данные передаются быстрее, а сравнивать с одним соединением не корректно
Иван, зайдите в отдел кадров, вам надо получить пилюлей за разглашение NDA
> 1. низкий ртт и препуш нужен только дудлу и ещё паре рекламных сетей, так они смогут повысить показы рекламы, а то хомяк может свалить раньше, а то и вовсе у него в днс домены с рекламой заблочены а тут ему сервер сам всё что "надо" отправит раньше, чем будет обращение к днс.Бред. В какой это галактике юзер уходит через 100-200мс после начала загрузки и не успевает увидеть рекламу?
С чего это пропадает возможность игнорить то, что отправил сервер через пуши, если он отправил говно? И серверный пуш уже есть в http/2 пару лет (а до этого был в spdy гугла), где ты видел абьюз для рекламы и невозможность заблочить?
И зачем вообще мучаться с целым новым протоколом, когда гуглу можно просто в хроме запретить сторонние блокировщики, внедрить свой и блокировать неправильную рекламу, оставляя правильную? Что он собственно и делает прямо сейчас, без всякого QUIC. Не надо путать тёплое с мягким.> 2. контроль перегрузки - так тцп имеет историю огромную и там оно тоже достаточно вылизано, в том числе и дудлом.
Вылизан там костыль. Огромная история там костылей. За 30 лет так и не вылизали нормально проблемы.
> 4. а какой зоопарк будет в софте: ведь каждая софтинка которой нужен этот убогий протокол должна где то найти либу с ним или притащить с сбой
Ага, ведь лучше ждать когда в ядра, ОСи и железо поддержка придёт. Может увидим использование протокола через 20 лет. Или не увидим даже тогда, как вышло с SCTP.
Расклад таков, что либо ты со стороны софта внедряешь новый транспортный протокол, либо ты никак не внедряешь. Не говоря уже о том, что в интернете могут существовать только TCP, UDP и надстройки над UDP. Что-то иное вообще невозможно никак внедрить.> 5. из за крипты повышенная нагрузка на проц даже там где крипта не впёрлась ни разу
Никого не волнует, что тебе где-то не нужно шифрование. Оно будет везде. И без QUIC, и с ним, не в нём дело. А в том, что шифровать только важное нельзя, ибо это будет палить важность данных. Шифровать надо всё, даже котиков, чтобы трафик котиков и чудовищных тайн выглядел одинаковым. Эта задача давно в процессе и почти выполнена без QUIC, а недовольные могут пройти в свой уголок интернета.
> 6. браузер по тцп может и рожает пачку соединений, и хотя это несколько дольше, но в итоге данные передаются быстрее, а сравнивать с одним соединением не корректно
> 3. попытка проскочить мимо шейперов, которые умеют тцп и не умеют квикИ почему же быстрее? Неужели твой tcp так обманывает шейперы, прямо как ты обвинял quic в 3 пункте? Ведь физический провод от одного узла до другого по сути один в некий момент времени, в случае tcp. Ответь мне, почему пачка tcp соединений по физическому проводу быстрее, чем одно tcp соединение по тому же проводу?
> мучаться с целым новым протоколом, когда гуглу можно просто в хроме запретить сторонние блокировщики, внедрить свой и блокировать неправильную рекламуEnforced. Done. Ожидайте в следующем релизе.
1. Больше чем уверен что в хроме такой возможности не будет.
Уходит-не уходит, на всяких сотовых задержка может быть и больше, а так же у людей далеко за уралом тоже.
Тут же вопрос в том, что раньше для всяких счётчиков-рекламы нужно было отдельный конект а теперь всё убрали одного, и придётся ждать загрузки полезного вместе с рекламой.2. тцп вполне приемлим. А вот хождение поверх юдп - костыль.
4. Лучше вообще не связываться с этой поделкой.
6. Потому что окно передачи больше, а коррекция ошибок независимая, но это про реальный интернет а не про локалку. Хотя в локалке тоже не все СС могут выжать даже сотку.
> Тут же вопрос в том, что раньше для всяких счётчиков-рекламы нужно было отдельный конект а теперь всё убрали одного, и придётся ждать загрузки полезного вместе с рекламой.Убрали до одного уже в spdy и http/2. Вот только все равно грузят рекламу с другого домена в 90-95% случаев. Потому что с first-party грузить дораха. И рекламщики не хотят отдавать это на совесть сайтам, как тогда проверять загрузки, заходы и клики? Верить тому что говорят админы сайтов и платить им по этим цифрам? Так разоришься, а они не лохи. Так что только сами. Стоит понимать как вообще все это работает.
И вообще-то не в этом дело. Даже если соединение одно, внутри него есть потоки, а в них запросы и ответы уже. И эти запросы видны webRequest, который прекрасно блочит, пока его не убьют в браузерных API (но это совсем другая история, не связанная с транспортными протоколами вообще). И если ты митмишь сам себя, то тоже увидишь их.
А суть в server push. Который опять же уже с spdy и http/2. Но пока я не видел ни единого абьюза для проталкивания мусора с невозможностью заблочить, а пора уже.
Гуглю никто не мешает с одного домена слать и рекламу, для них это оптимизация как соединений так и денег клиента.
Деньги клиента тут оптимизируются потому что можно рекламу всунуть в пуш, а уж что там браузер с ней сделает - пофик, за показ уплочено, данные зосланы.
> Деньги клиента тут оптимизируются потому что можно рекламу всунуть в пуш, а уж что там браузер с ней сделает - пофик, за показ уплочено, данные зосланы.И кто за это платить будет? Ты стал бы? Можно ещё отправлять рекламу в /dev/null и получать деньги. Пойду разбогатею.
Важно как раз то, что браузер сделает и что юзер увидит. Никого не волнует, что реклама прошла по проводам, если перед мордой юзера не появилась. Показа нет, денег нет.
Вруби логику рекламщиков, представь себя на их месте, этого достаточно для понимания базовых принципов.
Те кто платил раньше, всё равно им деваться некуда и доказать что либо трудно.
Если что по новостям недавно писали что накрыли крупный ботнет который скликивал рекламу на внушительные суммы, много лет, думаю он такой не один.
Ещё есть какие то дополнения которые рекламу из браузера как раз скрывают а не блокируют.
слюший, да, мы их "накрывали" в день по десять штук. Большая часть накрывалась антифродом сама, мы даже и не узнавали об их существовании, но случались шибкоумные, которые приходилось таки додавливать руками. Еще и, нипаверишь, деньги как правило возвращали рекламодателям.> Ещё есть какие то дополнения которые рекламу из браузера как раз скрывают а не блокируют.
это враждебное дополненине давным-давно зобанено всеми, включая палевную луну.
>Ага, ведь лучше ждать когда в ядра, ОСи и железо поддержка придёт. Может увидим использование протокола через 20 лет. Или не увидим даже тогда, как вышло с SCTP.А надо было думать когда ipv6 мутили, а не об воображаемом интернете умных вещей
Вот и получилось что из фич там только PMTUD сделали обязательным в угоду гавнопровайдерам, которые и так дропали вместо положенной фрагментации
> а какой зоопарк будет в софтене будет, Ваня, никакого зоопарка. Будет единственно-верный браузер - и неработающие, для слепых, которым все равно большая часть нового современного интернета противопоказана.
А весь "софт" будет на эш...лектроне, пардон, опечатался, г-н майор.
> браузер по тцп может и рожает пачку соединений, и хотя это несколько дольше
это _сильно_ дольше в случае ненужно-tls. И дает лишнюю нагрузку на кастрюли гугля - ему все эти соединения каждое отдельно обрабатывать, включая корректное закрытие с TIME_WAIT. Поэтому запихаем все в одно, да и соединением это не будет, будет udp.
Попутно откроем окно в мир флада, traffic amplifying и многих других интересных вещей, о которых хруст и пишущие на нем макаки еще не в курсе, а гуглю - начхать (а клаудфлерь на этом еще и заработает). С "bc.googleusercontent.сom" вон уже прет явно проксированный траффик - кто-то нашел в нем очередную полезную дыру, жаловаться - понятное дело, можно в спортлото. Не будет же, в самом деле, гугль чинить свой безопастный код на безопастном расте, если его абъюзят в ущерб альтернативам гуглю?!
Крипта вперлась вообще везде, времена такие
(s/вперлась/необходима/)
Так ничего же не изменилось за последние 20 лет, зачем крипта в каждой щели нужна?
Побольше "любопытных" лиц стало
Аналитика уровня опеннет. Папуасы, вы смешные.
Ждем offload UDP/QUIC 200G в Mellanox и SolarFlare.
Для IPTV шифрование не нужно...
IPTV вообще не нужно так-то.
Зачем вам ретроградские IPTV штучки? Когда всем хипстеры из вашей сферы ушли в OTT (Over the Top TV)
Те, кто деньги платить будет, просят поток, не готовы они к твоему ОТТ.
Стабильный OTT не на много дешевле классического IPTV от провайдера. QUIC, возможно, всё изменит, посмотрим.
квика там нет и не будет.
Правда? А youtube Вам ни о чем не говорит?
А сетевое проксирующие оборудование с поддержкой этого QUIC есть? Бампинг сессии кто-нибудь может делать с разбором того что бегает в сессии?
Я даже не знаю, что в заголовке этой новости ужаснее: CloudFlare, QUIC или Rust
"а по-моему они одинаковые".
> ...на языке RustОни что упоролись!?
Подобное только на С пишется!
И на node.js напишем! :)
+1024
Райдуся, что не на Electron :) А вообще, Rust - отличный выбор.
> Подобное только на С пишется!Для того, чтобы ни у кого не возникало желание читать исходники и баги с бекдорами там жили годами? Просто в 2019 году в условиях существования более приятных языков (и я не про раст) даже открывать исходники на си не хочется.
да, только пихон, только игого!(жаль что их исходники на самом деле вообще никто и никогда не открывает - ну, кроме дыроискателей, конечно, тем не лень, они этим заработают)
Не холивара ради, а посвящения для. Что по вашему более приятный язык?
Cloudflare - редкостные уроды, которые долбятся в зад Гууглу. Т.е. на каждый говносайтик, который автор учудил пустить через Cloudflare, выводится капча ГУГЛА и посетителей заставляют считать светофорчики, преходы, палить автомобили, велосипеды... Мало того, что минут по 5-20 невозможно на сайт зайти - так еще и занимаешься грязной работой для гугла. Не удивлюсь если скоро на картинках будет "найдите и отметьте всех престуников в толпе"...
Вы перекладываете ответственность. В ситуации виноват именно администратор сайта, пускающий трафик через Cloudflare, и, более того, по бесплатному тарифу.
неправда, не на каждый. Э...простите, не так: не _каждому_.Вам, поскольку вы лазите через тор - да, именно так.
Сидящим за мультипроксями и слишком толстыми натами - когда как. Но у них (в отличие от вас) есть козырный ход - если из гуглоакаунта вообще не выходить (или использовать правильный гуглобраузер, который все делает за вас) - капча сводится к квадратику куда надо ткнуть галочку, никаких лишних вопросов. Все для вашего удобства и безопасТносте!
(я верно излагаю, г-н майор?)
Включи себе уже кнопкой origin домен от cloudflare https://blog.cloudflare.com/cloudflare-onion-service/
Я обычно закрываю сразу же, как только вижу эту капчу. Если хотя бы 50% пользователей будут делать так же - придётся менять бизнес-модель :)
поступаю аналогично, просто ухожу на другой сайт, клаудфларь - пособник пиндосской гэбни
Ты там не болтай, давай вижи.
Глубокая мысль. Жаль поймут не только лишь все.
В настройках отключается. Это антиддос.
Какая гадость этот ваш Cloudflare. И ведь как на зло, часть сайтов на нём повязана.