В дерево исходных текстов проекта Chromium без каких-либо предварительный анонсов интегрирован (https://chromium.googlesource.com/chromium/src/net/+/master/.../) код с реализацией нового протокола QUIC. Предварительный (https://plus.google.com/u/0/100132233764003563318/posts/b36w...) анализ опубликованного кода показал, что QUIC представляет собой оптимизированный вариант протокола UDP с интегрированной поддержкой передачи данных в зашифрованном виде и с поддержкой сессиий.
Протокол активируется при запуске Chrome с использованием опции "--enable-quic", также упоминается опция "--origin-port-to-force-quic-on=80". Тем не менее протестировать работу протокола пока не с чем, так как неизвестно ни одного сервера QUIC. Спецификации протокола пока не опубликованы публично.URL: https://plus.google.com/u/0/100132233764003563318/posts/b36w...
Новость: http://www.opennet.me/opennews/art.shtml?num=36180
Ни дня без нового велосипеда! //новый слоган Гугл и Ко.
Что хромиуму новый протокол, то хрому троян.
В дерево исходных текстов проекта Chromium вероломно без объявления войны интегрирован код с реализацией нового протокола QUIC.
В дерево исходных текстов проекта Chromium бесплатно без смс интегрирован код с реализацией нового протокола QUIC.
пропущено: ... без регистрации ...чтите классику, чтите
Эх вы... Они же вам сюрприз сделать хотели :-)
> Эх вы... Они же вам сюрприз сделать хотели :-)Они уже сделали - внедрив DRM в свою ось. Не надо нам больше сюрпризов от гугеля.
Вы как дети с этим DRM. Ну а как авторам зарабатывать за авторский контент? Дарить его чтоли? Одно дело код, технология и наука - шаринг чего просто необходим. А шарить или дарить остальные вещи - дело каждого домовладельца. Вообще этот DRM это именно медиа. То есть единственная возможность запустить полноценные интернет-кинотеатры/театры/концерты. На снятие фильма тратят миллионы $ это и ЗП актеров и все все все. И один кинотеатр это не все сборы. А может я хочу премьеру дома посмотреть в хорошем качестве, без тупых каментов рядом и с возможностью поставить на паузу. Но я не могу этого сделать за деньги сравнимые с ценой билета и опасения прокатчиков без полноценного DRM я полностью понимаю.
это личные проблемы «прокатчиков» и прочих. я лично не понимаю, с какого испугу они собираются решать свои проблемы за мой счёт, при этом требуя с меня денег. если решают проблемы за мой счёт — тогда мне и платят; я так кумекаю. ну, или вот ты мне плати: это ж ты хочешь «дома посмотреть», и из-за тебя всякое DRMо сочиняют.
За какой твой счёт? Кто тебя заставляет смотреть фильмы с DRM и платить деньги?
> За какой твой счёт?за обычный мой счёт. когда я захочу вдруг купить фильму и огребу за свои же деньги DRMо с блобом в нагрузку. сони вон вообще под видом защиты трояна раздавала. а это не подвальная контора. как я могу быть уверен, что проприетарные DRM-блобы не содержат троянов?
> Эх вы… Они же вам сюрприз сделать хотели :-)«Про спичку мы пошутили, мы радость хотели доставить вам!» (ц)
Лучше бы штатно SCTP поддержали.. И грамматический словарь нормальный наконец сделали!
Делают даже автоматическое исправление ошибок для школоло...
> Лучше бы штатно SCTP поддержали.. И грамматический словарь нормальный наконец сделали!Сделают даже так, что сайты будут нужные загружаться, как только ты подойдёшь. А про тексты вообще будет сказка, просто думаешь и всё у Google.
> Сделают даже так, что сайты будут нужные загружаться, как только ты подойдёшь./soft ironic Допущения будто я подошел что-либо загружать или отгружать, с помощью сайтов, с помощью нужных сайтов, сбудутся только при определенном уровне выработки условных рефлексов, мотивации действий отображаемым контентом, обострении склерозных проявлений, общим ментальным подавлением, тогда да, сказка станет явью.
а пока лишь модификация транспортного протокола, что для пользователя контента прозрачно.
>определенном уровне выработки условных рефлексовНе беспокойтесь, скоро они у вас выработаются.
да запросто, при наличии камеры, должном развитии технологии распознавания образов и прочем ИИ - подошел на улице к рекламной панели в рваных кроссовках или джинсах - тебя сразу оценили и выдали рекламу на кроссовки или джинсы, подошел не в рваных - определили что за фирмА одежки, прикинули что ты, возможно, фанат адидаса и у тебя не последние их модели - выдали страничку с самыми современными фасончиками. А если ты сопливишь и чихаешь - то сразу реклама на какой-нибудь грипколд. А если подошел в лаптях и с мешком и как глубокий таежный житель вертишь головой и широко раскрываешь глаза и варежку - отправят на ближайший базар - кедровые орехи, что в тайге набил, продавать.
> Лучше бы штатно SCTP поддержали.. И грамматический словарь нормальный наконец сделали!Кстати, отказывается есть такой реквест! https://code.google.com/p/chromium/issues/detail?id=222724
Ставим звёздочку для поддержки.
Чем же так повинился курилка TCP, что все его бросаются переизобретать? Сначала uTP, теперь QUIC
- Тем что слоупочно разгоняется.
- Тем что congestion control у него не фонтан.
- Тем что path mtu discovery работает ужасно.
- Тем что при сколь-нибудь заметных потерях пакетов он дичайше теряет в скорости.
> - Тем что слоупочно разгоняется.Зависит от congestion control
> - Тем что congestion control у него не фонтан.
Зависит от алгоритма. А их много, и есть очень крутые.
> - Тем что path mtu discovery работает ужасно.
Нормально работает. В чём проблема?
> - Тем что при сколь-нибудь заметных потерях пакетов он дичайше теряет в скорости.
Зависит от congestion control
Так и запишем - ты не не осилил подучить матчасть и сменить алгоритм CC.
К сведению, любой "новый" протокол потребует точно такого же алгоритма congestion control.
> Зависит от congestion controlRight, но в среднем по больнице оно вот так. Вспомним про например виндузоидов, да?
> Зависит от алгоритма. А их много, и есть очень крутые.
Есть, но в среднем по больнице, особенно у виндузятников - то еще болото.
>> - Тем что path mtu discovery работает ужасно.
> Нормально работает. В чём проблема?В том что в половине случаев оно не отрабатывает и разработчики сетевых приложений как только не изгаляются по этому поводу.
>> - Тем что при сколь-нибудь заметных потерях пакетов он дичайше теряет в скорости.
> Зависит от congestion control(см. выше)
> Так и запишем - ты не не осилил подучить матчасть и сменить алгоритм CC.
Ну, иди, смени в винде хомякам алгоритм CC, если такой резвый? А ты уже смог убедить MS включить твой крутой алгоритм в их унылую винду?
> К сведению, любой "новый" протокол потребует точно такого же алгоритма congestion control.
Вот только когда оно на application level - разработчики таки могут вовремя воткнуть "крутой алгоритм". А ждать пока в виндах это в ядре появится можно вплоть до момента когда на горе свистнет рак. А для гугли это все-таки заметный % от инсталляционной базы.
Только когда более крутой алгоритм есть только в хроме, а всё остальное (читай IE) тупит - плюшки достаются хрому. Так что гугл вообще ни разу не заинтересован в улучшении реализации TCP в винде.Конкурентная борьба это.
> Только когда более крутой алгоритм есть только в хроме, а всё остальное
> (читай IE) тупит - плюшки достаются хрому.Ну так это по заслугам. Ускорение внедрения алгоритма. В целом - это хорошо: удачные алгоритмы получают путевку в жизнь быстрее. Без ожидания пока редмондские индусы раздуплятся.
> Так что гугл вообще ни разу не заинтересован в улучшении реализации TCP в винде.
Правильно, в этом по идее должны быть заинтересованы MS, но они в последнее время заинтересованы только в тупом впаривании. Чтобы как можно меньше кодить и как можно дороже всучить. По поводу чего винда откровенно стагнирует, а "инновации" на поверку оказываются притянутым за уши маркетинговым булшитом.
> Конкурентная борьба это.
От конкуренции клиенты только выигрывают. И если честно, я думаю что если ишак вылетит с рынка - вебдевелы будут жутко рады этому факту. Потому что самый геморный браузер из всех и самый тормозной в плане внедрежа новых фич. И каждая версия требует персонального внимания. Так что если он наконец издохнет, всем будет сильно проще.
Вы так говорите, будто если у Google даже и был бы такой интерес, то Microsoft-у было бы какое-то до этого дело.
>Ну, иди, смени в винде хомякам алгоритм CC, если такой резвый? А ты уже смог убедить MS включить твой крутой алгоритм в их унылую винду?А нас - рать!
1) Их проблемы.
2) Ну, иди, воткни в винду хомякам новый протокол .... и дальше по тексту.
вот то этому - моя первая фраза. Пусть жрут кактус.
> А нас - рать!Напоминает анекдот про войну чукч и китайцев
- А давайте воевать?
- Ну, давайте!
- Вас сколько?
- 10 человек!
- А нас - миллиард!
- Тц-тц-тц! Где ж мы столько хоронить то будем?!> 1) Их проблемы.
Я думаю что гугл несколько иного мнения на этот счет. Ну как бы они вероятно не готовы потерять такую порцию клиентуры или делать суперпротоколы при том что такая масса клиентов не сможет им пользоваться. Ну вот это видимо и порождает велосипедостроительство. Уповать на то что все популярные операционки оперативно внесут новый протокол в ядро не приходится, увы. А в апликухе гугл может внести его когда сочтет нужным.
> 2) Ну, иди, воткни в винду хомякам новый протокол .... и дальше по тексту.
А я то что? Вот гугель и воткнет, судя по всему. И это будет в разы быстрее чем ждать пока MS раздуплится это в ядре родить.
> вот то этому - моя первая фраза. Пусть жрут кактус.
Ну как бы at the end of day у бизнес-хренов засчитывается фактический результат, а не крутота концепций. Непонимание этого момента отправило на тот свет немало неплохих по дизайну проектов.
> А я то что? Вот гугель и воткнет, судя по всему. И
> это будет в разы быстрее чем ждать пока MS раздуплится это
> в ядре родить.И будет оно только у хромобоев, только в их убогом хроме. Что изменится?
а что, есть решения, которые одновременно и congestion хорошо определяют, и задержкам и потерям пакетов нечуствительны?
1. TCP очень резко изменяет размер скользящего окна при congestion.
2. TCP "по-своему" понимает понятие flow: то есть, если я по каким-то своим причинам шарашу пакетами по 100 байт, и транзитный маршрутизатор, скажем, пропихнёт десятый пакет в первую очередь, тогда принимающий хост обязан накопить все IP-пакеты, пока не будет получена правильная последовательность TCP SeqNum.
В Real-Time это просто неприемлемо.
3. SYN Flood.
> 1. TCP очень резко изменяет размер скользящего окна при congestion.Зависит, опять таки, от алгоритма.
> 2. TCP "по-своему" понимает понятие flow: то есть, если я по каким-то
> своим причинам шарашу пакетами по 100 байт, и транзитный маршрутизатор, скажем,
> пропихнёт десятый пакет в первую очередь, тогда принимающий хост обязан накопить
> все IP-пакеты, пока не будет получена правильная последовательность TCP SeqNum.
> В Real-Time это просто неприемлемо.А вот тут уже полная некомпетенция. TCP - это поток данных, что, по-твоему, должен сделать принимающий хост кроме как накопить все пакеты? Уж не вернуть в userspace кусок данных хрен знает откуда поломав нафиг всё? А для realtime никто TCP и не использует.
> 3. SYN Flood.
Это не TCP-специфичная проблема. Любой поточно-ориентированный протокол её будет иметь, и для всех она одинаково решается, как давно решена для TCP.
> Ну и FIN-WAIT-2 Problem, как же я забыл-то... ;)
Что ты считаешь тут проблемой?
> Чем же так повинился курилка TCP, что все его бросаются переизобретать?Ну и FIN-WAIT-2 Problem, как же я забыл-то... ;)
Гуглы делают делают свой интернет
Давно уже.
Они сейчас еще начнут широкополосным доступом торговать.
А чего, интересная заявка:1) от скорости гуглосервисов сейчас зависят почти все
2) делается специализированный оптимизированный по самое немогу протокол для взаимоедйствия со своими сервисами
3) спецификацияне даётся
4) новый протокол реализуется на своих сервисах, в хроме/хромоси. Естественно, для пользователя всё выглядит как HTTP или HTTPS
5) PROFIT - с точки зрения хомяка "интернет не тормозит" только в хроме. А переносить реализацию этой штуки к себе MS будет три жизни - там могут быть весьма нехилые услилия по реверсу спецификаций, да и в любом случае они скоростью не отличаются.Но лично меня такой сценарий как-то не радует.
> там могут быть весьма нехилые услилия по реверсу спецификаций, да и в любом случае они скоростью не отличаются.Учитывая что это гугл, то спецификации как и реализация будут открытыми. Но вы правы
>переносить реализацию этой штуки к себе MS будет три жизни
Вот и я о том же. Точнее, спецификация может быть просто неполной или не соответствующей реальному положению вещей - грубо говоря, её реализация будет давать копеечные улучения, а гугловская- реальные.
>[оверквотинг удален]
> 2) делается специализированный оптимизированный по самое немогу протокол для взаимоедйствия
> со своими сервисами
> 3) спецификацияне даётся
> 4) новый протокол реализуется на своих сервисах, в хроме/хромоси. Естественно, для пользователя
> всё выглядит как HTTP или HTTPS
> 5) PROFIT - с точки зрения хомяка "интернет не тормозит" только в
> хроме. А переносить реализацию этой штуки к себе MS будет три
> жизни - там могут быть весьма нехилые услилия по реверсу спецификаций,
> да и в любом случае они скоростью не отличаются.
> Но лично меня такой сценарий как-то не радует.Неужели не радует только зависимость от гуглосервисов?
Может какие другие радости в жизни имеются?Скоко вопросов, то!?!?!? Можно посылать!
Что сказать-то хотел?
> А чего, интересная заявка:так великолепно же! гуглотушканчики собираются в гуглозагоны с гуглохромом — и там сидят. мне нравится.
И хромиумотушканчики, и всякие мелкие яндекс/мейлру-тушканчики, а вскоре и оперотушканчики. Chrome - это новый современный IE6 со всеми вытекающими минусами. Но... как будто это плохо.
ура, они изобретут TCP 2.0!
> ура, они изобретут TCP 2.0!больше похоже на ТСР 0.2
интересно как этот QUIC по сравнению с SCTP?Что лучше / вкуснее для пользователей и серверных приложений.
Я конечно лох и что-то не понимаю, но ... какое отношение протокол-замена ТСР имеет к браузеру? Что, браузер нынче работает на OSI уровне 3 (т.е. напрямую с IP)? Мне всегда казалось, что ТСР-стек - это часть ОС.$ man socket:
...
int socket(int domain, int type, int protocol);
type ... SOCK_STREAM, SOCK_DGRAM ...Если браузер работает с транспортным уровнем (а не с прикладными а-ля HTTP[S]?), то либо это уже epic fail by design, либо это заявка на ОС.
Ну а в настоящее время пусть хоть физический уровень в свой хром впиливают, если на иных серверах (кроме гугловых) нет поддержки в ОС (ибо с трудом верится, что это чюдо запилят в веб-серверах!), то хрена лысого увидит ихний хром, а не какой-там квик.
Нувот на базе SOCK_DGRAM и сделано, всё, что выше - да, сами реализовали, у них ресурсов на это хватает.И поинтересуйтесь как-нибудь, какой процент сайтов использует гугловские сервисы - начиная с туого храналища скриптов и гуглоаналитики. Сюрпрайз - если гугловские сервисы будут в конкретном браузере работать явно шустрее то для пользователя это будет выглядеть как более быстрый интернет целиком. Так что куча хомяков в результате резво перелезет на хром.
> на базе SOCK_DGRAM... QUIC представляет собой оптимизированный вариант протокола UDP ...
Т.е. *вместо* UDP, а не поверх. А это подразумевает новый тип сокета. А сокеты - часть ТСР-стека. А ТСР-стек - часть ОС. А значит... ну вы понели.
> какой процент сайтов использует гугловские сервисыкакой процент сайтов использует их настолько, чтобы от этого зависела скорость всего сайта?
> если гугловские сервисы будут в конкретном браузере работать явно шустреес чего? Возможно, при прямом соединении с сервером гугля разница и будет. А во всех остальных случаях скорость передачи данных от протокола зависит не более чем никак.
> ... QUIC представляет собой оптимизированный вариант протокола UDP ...вообще-то нет. это человек то ли не разобрался, то ли неверно выразился. оно больше похоже на продвинутый аналог ENet.
Очередной проприетарный протокол. Видимо расчитывали порадовать индивидумов покормивших медведя после рюмки водки.
Зачем велосипеды?
Есть же готовый SCTP
Эра IPv6 до сих пор ещё не восторжествовала и большинство пользователей сидят за провайдерским NAT. И готов этот NAT натить протокол SCTP ?
Ну так в будущем в ChromeOS и запилят или забьют на реализацию