The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Компания Cloudflare открыла код реализации протокола QUIC на..., opennews (?), 30-Янв-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


42. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +2 +/
Сообщение от Аноним (42), 31-Янв-19, 04:33 
> 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 соединение по тому же проводу?

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

46. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +1 +/
Сообщение от Аноним (43), 31-Янв-19, 05:00 
> мучаться с целым новым протоколом, когда гуглу можно просто в хроме запретить сторонние блокировщики, внедрить свой и блокировать неправильную рекламу

Enforced. Done. Ожидайте в следующем релизе.

Ответить | Правка | Наверх | Cообщить модератору

71. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +/
Сообщение от Ivan_83 (ok), 31-Янв-19, 11:38 
1. Больше чем уверен что в хроме такой возможности не будет.
Уходит-не уходит, на всяких сотовых задержка может быть и больше, а так же у людей далеко за уралом тоже.
Тут же вопрос в том, что раньше для всяких счётчиков-рекламы нужно было отдельный конект а теперь всё убрали одного, и придётся ждать загрузки полезного вместе с рекламой.

2. тцп вполне приемлим. А вот хождение поверх юдп - костыль.

4. Лучше вообще не связываться с этой поделкой.

6. Потому что окно передачи больше, а коррекция ошибок независимая, но это про реальный интернет а не про локалку. Хотя в локалке тоже не все СС могут выжать даже сотку.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

87. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +/
Сообщение от Аноним (42), 31-Янв-19, 14:53 
> Тут же вопрос в том, что раньше для всяких счётчиков-рекламы нужно было отдельный конект а теперь всё убрали одного, и придётся ждать загрузки полезного вместе с рекламой.

Убрали до одного уже в spdy и http/2. Вот только все равно грузят рекламу с другого домена в 90-95% случаев. Потому что с first-party грузить дораха. И рекламщики не хотят отдавать это на совесть сайтам, как тогда проверять загрузки, заходы и клики? Верить тому что говорят админы сайтов и платить им по этим цифрам? Так разоришься, а они не лохи. Так что только сами. Стоит понимать как вообще все это работает.
И вообще-то не в этом дело. Даже если соединение одно, внутри него есть потоки, а в них запросы и ответы уже. И эти запросы видны webRequest, который прекрасно блочит, пока его не убьют в браузерных API (но это совсем другая история, не связанная с транспортными протоколами вообще). И если ты митмишь сам себя, то тоже увидишь их.
А суть в server push. Который опять же уже с spdy и http/2. Но пока я не видел ни единого абьюза для проталкивания мусора с невозможностью заблочить, а пора уже.

Ответить | Правка | Наверх | Cообщить модератору

91. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +/
Сообщение от Ivan_83 (ok), 31-Янв-19, 17:02 
Гуглю никто не мешает с одного домена слать и рекламу, для них это оптимизация как соединений так и денег клиента.
Деньги клиента тут оптимизируются потому что можно рекламу всунуть в пуш, а уж что там браузер с ней сделает - пофик, за показ уплочено, данные зосланы.
Ответить | Правка | Наверх | Cообщить модератору

113. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +/
Сообщение от Аноним (113), 01-Фев-19, 10:38 
> Деньги клиента тут оптимизируются потому что можно рекламу всунуть в пуш, а уж что там браузер с ней сделает - пофик, за показ уплочено, данные зосланы.

И кто за это платить будет? Ты стал бы? Можно ещё отправлять рекламу в /dev/null и получать деньги. Пойду разбогатею.
Важно как раз то, что браузер сделает и что юзер увидит. Никого не волнует, что реклама прошла по проводам, если перед мордой юзера не появилась. Показа нет, денег нет.
Вруби логику рекламщиков, представь себя на их месте, этого достаточно для понимания базовых принципов.

Ответить | Правка | Наверх | Cообщить модератору

116. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +/
Сообщение от Ivan_83 (ok), 01-Фев-19, 20:08 
Те кто платил раньше, всё равно им деваться некуда и доказать что либо трудно.
Если что по новостям недавно писали что накрыли крупный ботнет который скликивал рекламу на внушительные суммы, много лет, думаю он такой не один.
Ещё есть какие то дополнения которые рекламу из браузера как раз скрывают а не блокируют.
Ответить | Правка | Наверх | Cообщить модератору

119. "Компания Cloudflare открыла код реализации протокола QUIC на..."  +/
Сообщение от пох (?), 02-Фев-19, 17:10 
слюший, да, мы их "накрывали" в день по десять штук. Большая часть накрывалась антифродом сама, мы даже и не узнавали об их существовании, но случались шибкоумные, которые приходилось таки додавливать руками. Еще и, нипаверишь, деньги как правило возвращали рекламодателям.

> Ещё есть какие то дополнения которые рекламу из браузера как раз скрывают а не блокируют.

это враждебное дополненине давным-давно зобанено всеми, включая палевную луну.


Ответить | Правка | Наверх | Cообщить модератору

115. "Компания Cloudflare открыла код реализации протокола QUIC на..."  –1 +/
Сообщение от Аноним (115), 01-Фев-19, 14:14 
>Ага, ведь лучше ждать когда в ядра, ОСи и железо поддержка придёт. Может увидим использование протокола через 20 лет. Или не увидим даже тогда, как вышло с SCTP.

А надо было думать когда ipv6 мутили, а не об воображаемом интернете умных вещей
Вот и получилось что из фич там только PMTUD сделали обязательным в угоду гавнопровайдерам, которые и так дропали вместо положенной фрагментации

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру