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

"HTTP поверх протокола QUIC будет стандартизирован как HTTP/3 "	+1 +/–
Сообщение от opennews (??), 12-Ноя-18, 08:52
Дэниел Cтенберг (Daniel Stenberg), автор утилиты cURL, входящий в рабочие группы IETF, развивающие протоколы HTTP и QUIC, сообщил (https://daniel.haxx.se/blog/2018/11/11/http-3/) об утверждении решения по продвижению протокола HTTP-over-QUIC в качестве будущего стандарта HTTP/3. Выбор имени для HTTP-over-QUIC вызвал большую дискуссию. Вначале рассматривалась возможность использования для стандартизации связки HTTP-over-QUIC имён HQ, QUIC/2, HTTP/QUIC и HTTP/2-encrypted-over-UDP, но в конце концов разработчики согласились с предложением (https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...) использовать имя HTTP/3, которое позволит сохранить привычную семантику. Стандартизация QUIC в IETF разделена на два уровня: определение транспортного протокола QUIC и надстройки для обеспечения работы HTTP поверх QUIC. Связанные с HTTP части отныне будут рассматриваться как HTTP/3. Для транспортного протокола ситуация пока не однозначна, так как развиваемый в IETF протокол и вариант протокола от Google отличаются в некоторых деталях, неформально версию от IETF в сообществе именуют  iQUIC, а вариант Google - gQUIC. После завершения стандартизации и синхронизации реализации компанией Google ожидается оставление за протоколом имени 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.me/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://daniel.haxx.se/blog/2018/11/11/http-3/ Новость: https://www.opennet.me/opennews/art.shtml?num=49594
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+78 +/–
Сообщение от Аноним (1), 12-Ноя-18, 08:52
>Заметный прирост производительности и пропускной способности в 2018 году это как-то непривычно звучит, ведь сейчас в моде наплевательское отношение к производительности
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от eRIC (ok), 12-Ноя-18, 08:53
	> в 2018 году это как-то непривычно звучит, ведь сейчас в моде наплевательское > отношение к производительности +1
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	11. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+8 +/–
	Сообщение от _hide_ (ok), 12-Ноя-18, 09:07
	При такой переусложненности протокола все плюсы нивелируют, особенно если учесть, какими методами достигается такое увеличение. DDOS будет на ура класть сервера просто по трафику.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 09:11
	Ну вот да, тот же concern. Во-первых оно декриптит перед обработкой, уже плохо. Очень плохо. Во-вторых, скорее всего будут дыры на спуфнуть сеанс, получив amplification attack. Ну не доверяю я протоколам без предварительного affix'инга соединения, чего уж там.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	51. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
	Сообщение от rshadow (ok), 12-Ноя-18, 11:44
	Есть надежда что все эти протоколы станут как например веб-фреймворки: HTTP 1.1 must have, а все остальное по выбору.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	86. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 14:30
	И не надейтесь. Эта штука решает совершенно реальную проблему - то, что TCP отвратительно приспособлен к радиоканалам с их постоянными потерями и постоянно меняющейся пропускной способностью. При этом сейчас большая часть доступа в веб идёт с мобил. Поэтому как только оно хоть как-то стабилизируется - на него побегут все, кто хочет хороший user experience. Опять же, скорее всего для приложений оно будет совершенно прозрачным и в настройке потребует тупо включить модуль в веб-сервере (если есть https, на который, к счатью, уже в основном загнали даже тормозов), так что проблем с adoption я бы не ждал. Сложность под капотом - проблема писателей либ, и разработчиков серверов и браузеров, но этим всем деваться будет некуда в любом случае.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	94. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от RomanCh (ok), 12-Ноя-18, 15:05
	> если есть https, на который, к счатью, уже в основном загнали даже тормозов А в чём тут простите "счастье"? Я понимаю когда речь идёт о конфиденциальных данных, коммерческой тайне и т.п. Но когда несчастных публично доступных без авторизации котиков, фоточки из зомбосетяшек и видео  начинают шифровать - это где и в чём тут счастье? Например, включение SSL на отдающем видеосервисе требует примерно вдвое больше проца чем без него. Известным образом растёт и энергопотребление. Не сложно догадаться что со стороны клиента так же растёт потребность в проце и энергопотреблении (привет вашим мо[гб]ильным причандалам). И где счастье? В технологии ради технологии? Или выражаете мнение маркетанов и радеющих за повышение продаж оборудования?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	96. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от пох (?), 12-Ноя-18, 15:09
	> Но когда несчастных публично доступных без авторизации котиков, фоточки из зомбосетяшек и видео > начинают шифровать - это где и в чём тут счастье? очень просто - у гугля есть и будут на это мощности. А если у тебя не хватит - тем лучше для гугля. Именно ради этого (ну и других плюшек, типа уже свершившегося тотального контроля всего шифрования, кроме "зеленых" сертификатов за сотни долларов) и работали. И нынешняя поделка тоже ради того же - а мобилкам, вопреки распрекрасным фантазиям, скорее поплохеет, чем полегчает - товарищ просто не в курсе, как работают современные сети. А гуглю, опять же, наплевать - его траффик в любом случае пролезет, он позаботится.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	98. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от RomanCh (ok), 12-Ноя-18, 15:13
	> у гугля есть и будут на это мощности. А если у тебя не хватит - тем лучше для гугля. Блин, ну зачем срываешь покровы раньше времени! Я-то это прекрасно понимаю, т.к. на прошлой работе как раз проходили через эти грабли - необходимость массового апгрейда отдающих видео серверов, только потому что "теперь модно шифрование". При этом для пользователя решительно ничего не поменялось, только тормозить больше стало. Очевидно что для гуголя это хорошая методика придушения множества мелких локальных конкурентов. Но мне таки интересен ответ товарища что видит в этом "счастье".
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	108. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 16:07
	Много в чём. В даном случае имелось в виду то, что необходимое для QUIC шифрование уже есть. Но если уж вам так хочется: 1) защита от дурака и от ошибок - не надо решать (обычно не угадывая), что надо прятать, что нет и это, в  общем-то, самое важное. Особенно с учётом эволюции требований к защите данных и самого веб-софта. Добавили функцию на сайт - и оказалось, что есть то, что надо защищать - и то, переделывать, ломать урлы и т.п. ? Не, оно делаемо, но это лишние затраты. 2) пользователь не путается - тут безопасно, тут нет. Что может и от исков избавить иногда. 3) защита (с дополнительными усилиями, но HTTPS - необходимая часть) от вмешательства провайдера в трафик. 3) усложняется масштабная слежка - на нешифрованном потоке по ключам что угодно ловить можно, и как минимум на текст ресурсов не так уж много надо, а потом уже можно целенаправленно лупить. Тот же Эшелон вспомниаем - с шифрованием подобное сделать тоже можно, но выйдет сильно дороже и не у всех 4) сложнее выделить конфиденциальные данные и прочую коммерческую тайну - поток на всё одинаковый. С аппаратным шифрованием нагрузки на пользовательской стороне очень малы, на сервере - вполне подъёмны, я бы сказал. И, кстати, оглянитесь - нешифрованных котиков нигде особо и нет, везде пользователь залогинен, его сессию надо защищать, потому что обычно хотят не только смотреть, но и лайкать, комментировать и т.д.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	115. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–4 +/–
	Сообщение от RomanCh (ok), 12-Ноя-18, 16:29
	> необходимое для QUIC шифрование уже есть. Ага, при этом ненужное примерно в 90%+ случаев. > 1) защита от дурака и от ошибок - не надо решать ... Не, оно делаемо, но это лишние затраты. Ага, ну конечно, с массовым переходом на SSL все дураки разбежались. Прям бегут, и падают, встают и снова бегут! Буквально какое-то разбегание дураков в вечно расширяющейся bullshit web вселенной. То-то 8 Гб памяти на ноуте уже мало стало. Ну т.е. вы фактически голосуете за экстенсивные решения вместо продуманных архитектурных. Т.е. вместо того что бы думать, мы лучше купим ещё пачку серверов. Это по -взрослому- рыночному, это понятно. Правда шарик и ресурсы на нём не бесконечны, но кого же это волнует, и вообще это совсем другая история. > 2) пользователь не путается - тут безопасно, тут нет. Ага, теперь просто взлом пользователя перешёл на другой уровень - через фишинг, скупку популярных аддонов и прохачивание популярных библиотек которые так любят разработчики которым слишком дорого думать. > 3) защита (с дополнительными усилиями, но HTTPS - необходимая часть) от вмешательства провайдера в трафик. Этот вопрос вообще не тем методом нужно решать. И так-ли много пострадавших от этого вмешательства? А если сравнить это с количеством пострадавших от тормозов что порождаются технологиями ради технологий? > 3) усложняется масштабная слежка - на нешифрованном потоке по ключам что угодно > ловить можно, и как минимум на текст ресурсов не так уж > много надо, а потом уже можно целенаправленно лупить. Кому ёлки палки нужны ваши котики и покупка кружевных трусиков на алиэкспрессе?.. > 4) сложнее выделить конфиденциальные данные и прочую коммерческую тайну - поток на > всё одинаковый. Ахаха, гугл у нас получается на охране конфиденциальных данных! А ещё скажите что он противостоит эшелону! Очень жирно, очень! > С аппаратным шифрованием нагрузки на пользовательской стороне очень малы, на сервере - > вполне подъёмны, я бы сказал. Это всё слова в воздух и разговоры в пользу богатых. А я вам сказал что значит "подъёмно" на практике. Увеличение в 2 раза мощности по процам при том же наборе услуг с серверной стороны. Т.е. вместо того что бы тратить ресурсы на улучшение существующего функционала и разработку нового, ресурсы тратятся на более эффективное нагревание воздуха. По клиентам нет релевантной выборки, но очевидно что небесконечный аккумулятор на могильных устройствах это тоже обязательно чувствует, особо прожёвывая толстый видеотрафик. Для гугла - конечно подъёмно и выгодно. Для локальных конкурентов - уже очень сложно. Для пользователя... А куда ему деваться? > И, кстати, оглянитесь - нешифрованных котиков нигде особо и нет, Я про это и говорю. Зашифровали то что шифровать в принципе не надо, вместо того что бы разработать стандартизированную архитектуру прозрачно отделяющую данные которые действительно нужно шифровать, от данных которые можно (и нужно) не шифровать. > везде пользователь залогинен, его сессию надо защищать, > потому что обычно хотят не только смотреть, но и лайкать, комментировать > и т.д. О ужас! Ваши комментарии под котиками прочитает сосед-какир Вася, научившийся делать отравление arp-кэша на бородатом неуправляемом оборудовании местечкового провайдинга? Непередаваемый кошмар!
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	186. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (186), 13-Ноя-18, 14:22
	> О ужас! Ваши комментарии под котиками прочитает сосед-какир Вася, научившийся делать отравление arp-кэша на бородатом неуправляемом оборудовании местечкового провайдинга? Непередаваемый кошмар! Ладно если только прочитает, а вот если подсунет вам вместо котиков майнер — будет не очень приятно.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	216. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от SysA (?), 14-Ноя-18, 19:37
	К вашему сведению: "...покупка кружевных трусиков на алиэкспрессе" требует передачи финансовой информации, а это много кого заинтересует!.. ;) А если "сосед-какир Вася" может прочитать комменты, то и сможет перехватить логин/пароль на сессию, а потом писать всякий бред от твоего имени. Так что все не так однозначно...
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	221. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от RomanCh (ok), 15-Ноя-18, 14:03
	> К вашему сведению: "...покупка кружевных трусиков на алиэкспрессе" требует передачи финансовой > информации, а это много кого заинтересует!.. ;) Вот для этого и нужна нормально продуманная архитектура в которой мухи от котлет разделены однозначно и удобно для вышележащих уровней. Но нет, вместо этого мы просто завернём мух и котлет в один газетный кулёк и будем пытаться его пересылать Почтой России. > А если "сосед-какир Вася" может прочитать комменты, то и сможет перехватить логин/пароль > на сессию, а потом писать всякий бред от твоего имени. Туда же. И отдельно хочется отметить что с повсеместным SSL конечно этого не происходит. Победили так победили проблему, ага.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	121. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (121), 12-Ноя-18, 17:38
	>3) усложняется масштабная слежка - ... > выйдет сильно дороже и не у всех Это ключевая, если не единственная, причина тотального перхода на https.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	215. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (215), 14-Ноя-18, 15:45
	Основанное на доверие корневых серверов, самому то не смешно?
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	223. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от нах (?), 15-Ноя-18, 14:36
	да нет, он все правильно написал, просто вы не поняли - ключевое слово там "не у всех". то есть у гугля - выйдет, товарищ майор просто купит, а вот если ты решишь проследить за гуглем - у тебя не должно получиться, даже при том что вторая сторона выполняется прямо на твоем компьютере в виде распрекрасного гуглокода.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	127. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (127), 12-Ноя-18, 18:06
	Рядом с публично доступными без авторизации котиками может быть домашнее ню, предназначенное для строго ограниченного круга лиц, например.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	222. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от RomanCh (ok), 15-Ноя-18, 14:09
	> Рядом с публично доступными без авторизации котиками может быть домашнее ню, предназначенное > для строго ограниченного круга лиц, например. Которое отлично утекает в сеть и с этим вашим хвалёным SSL. Регулярные скандалы-интриги-расследования о жизни богатых и знаменитых вместе с выкладыванием их фото и почтовой переписки нам как бы намекают. А *ваши* домашние ню-фото с ню-котиками в интригующих позах не оказались в паблике не потому что они в SSL, а потому что просто ни к чёрту никому не нужны. Они там не оказались бы скорее всего даже если бы вы им поставили открытый доступ. И вообще, глупо надеяться на то что шифрование трафика как-то спасёт вас от этого, если нет шифрования на стороне пользователя и складывания на сервер уже шифрованных блобов. Но ведь этого нигде нет, потому что все ваши фоточки (включая те что с ню) очень нужны для разного рода интересных операций, ну например для проектов типа findface. Я бы больше об этом думал на вашем месте, нежели о какире Васе. Так что явно не с той стороны лечение проблемы ожидаете.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	228. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (-), 19-Ноя-18, 00:05
	> без авторизации котиков, фоточки из зомбосетяшек и видео  начинают шифровать > - это где и в чём тут счастье? Ну вот смотри, мобильный пров например врезал знакомому юзеру свой контент. И мало того - он подвернулся под руку. Юзер кликнул. И попал на 300 рублей, между прочим. Ну вот чтобы такого не было - сам понимаешь, давать кому попало влезать в траф явно лишнее. Есть сервер и есть юзер. Третий лишний. > Например, включение SSL на отдающем видеосервисе требует примерно вдвое больше проца > чем без него. Однако проц там один черт не озадачен как правило. Да и крипто шустрое сейчас есть, тот же poly1305-chacha и прочие 25519. Они даже на фигне с тетрадную клеточку прилично работают. А уж на одноплатнике, десктопе или тем более приличном сервере. > Известным образом растёт и энергопотребление. Не сложно догадаться что со стороны > клиента так же растёт потребность в проце и энергопотреблении Одна врезка рекламы гамнюками обошлась юзеру как 2-недельный счет за электричество. Еще вопросы?
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	232. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от RomanCh (ok), 19-Ноя-18, 13:09
	> Ну вот смотри, мобильный пров например врезал знакомому юзеру свой контент. Ещё раз - для этого существуют другие методы решения. Юридические. Или смена провайдера. А лох - он всегда будет стрижен, с ssl или без. Будто от повсеместного внедрения ssl количество стриженных лохов в интернете изменилось, ну конечно. > Однако проц там один черт не озадачен как правило. Да и крипто > шустрое сейчас есть, тот же poly1305-chacha и прочие 25519. Вы когда-нибудь пробовали отдавать 500-1000 Гбит/с видео внешним пользователям? Вот когда попробуете, тогда узнаете как там "проц не озадачен" и как удобно (и недорого, ага) прикручивать криптопроцессоры к существующим системам. Когда зачастую требуется ещё и всякое старое УГ в шифровании поддерживать потому что "иначе юзеры отпадут". > Одна врезка рекламы гамнюками обошлась юзеру как 2-недельный счет за электричество. Еще вопросы? А вот знаю бывают случаи, когда люди из дома выходят и их штукатуркой убивает отпавшей со стены! Так что давайте все в шлемах Рысь-Т ходить! Первое. Давайте не будем строить правила на исключениях, иначе так можно слишком далеко зайти. Второе. Даже если рассматривать ваш исключительный случай, то электричества больше от того не потребилось (лох был стрижен, наоборот глядишь меньше потратит в итоге).  В ситуации же с SSL, если вы немного напряжёте мозги, то поймёте что постоянный жор батарейки у всех внезапно сказывается на глобальном энергопотреблении, на требуемой мощности аккумуляторов (иначе ваш пальцетык через полчаса сядет), на требуемой мощности процессора в сервере а потому - потребляемой мощности всего ЦОД. И тут внезапно ещё можно вспомнить что процесс производства аккумов не так дёшев, а их утилизация - так и вовсе сложная история. И это всё во-первых закладывается в итоговую цену для потребителя (отказаться от которой он не может даже если ему всё это не надо), а во-вторых в очумительный перерасход ресурсов на шарике, забивание ресурсов для сброса отходов, мусорно-экологическую катастрофу и глобальное потепление. Но любители пальцетыков традиционно не задумываются о подобных мелочах. Им бы три-в-ряд погонять сейчас, и парочку фоточек в зомбосетяшках побезопасней выложить.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	233. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (-), 19-Ноя-18, 17:33
	> Ещё раз - для этого существуют другие методы решения. Юридические. Это не работает. Каждого гамнюка не построишь. Так же как не поймаешь и не накажешь каждого кулхацкера с кали-линуксом и снифером. Поэтому приходится выбирать решения которые реально а не номинально работают. К тому же юзер в половине случаев еще и твердо уверен что это был контент страницы, выдвигая претензии сайту. Ведь он зашел на сайт - и попал. Значит виноват сайт. В этом месте владельцы серверов начинают решать что отдуваться за чужие косяки чуть ли не в судебном порядке им не очень надо - и начинают хотеть чего-то такого. Технари тоже понимают что безобразие надо рубить на корню - и в целом отрасль двигает в этом направлении. Есть проблема, с ней махаются. Не по паспорту, а по морде. > Или смена провайдера. И на что менять мобилочных провов, если они ВСЕ так делать норовят? Да и не-мобилочные порой так развлекаются. А если в какой-то географии пров монополист - то чего? Еще и переехать заодно? Вариант, конечно, но - не для всех. Поэтому толпа народа будет вопить что админ сайта жулик и урод - врезает на сайте картинки по 300 рублей. Оно вледельцу сайта надо? > А лох - он всегда будет стрижен, с ssl или без. Однако усложнить это тем кто борзеет сверх всякой меры все же можно. Да и пароли в кафешках все же перестанет собирать оптом всего лишь примитивным запуском снифера по наглому, чтоли. > Вы когда-нибудь пробовали отдавать 500-1000 Гбит/с видео внешним пользователям? В таком масштабе это не 1 сервер делает. Так по нормальному - это небольшой CDN, чтоли. И у него неозадаченных процов явно будет. А, да, это у нормальных людей еще и по глобусу раскидано в несколько мест. > Вот когда попробуете, тогда узнаете как там "проц не озадачен" и как удобно > (и недорого, ага) прикручивать криптопроцессоры к существующим системам. Сейчас серверные процессоры такие что выделить несколько ядер под chacha - не больно какая проблема. А чего еще им делать на сервере грузящем данные? > Когда зачастую требуется ещё и всякое старое УГ в шифровании поддерживать потому что > "иначе юзеры отпадут". Отлично, экономистов на спичках пытающихся перепихнуть свою экономию ценой проблем у других надо с рынка гнать цаными тряпками и такой же метлой. Потому что потом рядом с вашим видео ISP врезает свою картинку. Ценой 300 рублей, бл. На это у них ресурсов почему-то хватает, в отличие от вас. Так что вы или найдете ресурсы, или на ваше место придет более вменяемый сервис, который больше на стороне юзерей чем вы. Как-то так. > штукатуркой убивает отпавшей со стены! Так что давайте все в шлемах > Рысь-Т ходить! Ну как бы если штукатурка начнет падать раз в 20 минут на всех кто из дома высунул нос - мы таки поневоле полюбим каски. Так же как после энного количества задавленных мы полюбили ПДД. Ну так вот, количество "задавленных" перевалило критический предел. Возник спрос на пересмотр этой ситуации. > Первое. Давайте не будем строить правила на исключениях, иначе так можно слишком далеко зайти. Это к сожалению не исключения а вообще каждый первый мобильный пров. И каждый третий проводной. > Второе. Даже если рассматривать ваш исключительный случай, то электричества больше от того > не потребилось (лох был стрижен, наоборот глядишь меньше потратит в итоге). У лоха с мобилочного счета за 1 присест улетело больше чем он за 2 недели за вообще все электричество в доме платил, это больно и быстро и при таких фактах все положат на ваш бубнеж про экономию. А вы или предоставите юзеру сервис где его не обжуливают, или вместо вас будет другой сервис. Все просто. > то поймёте что постоянный жор батарейки у всех внезапно сказывается на > глобальном энергопотреблении, на требуемой мощности аккумуляторов (иначе ваш пальцетык > через полчаса сядет), на требуемой мощности процессора в сервере а потому > - потребляемой мощности всего ЦОД. Соблюдение пдд требует работы толпы народа, уйму краски, денег и вообще. Безобразие, конечно, но если б не было проблем - с ними бы и не боролись. > И это всё во-первых закладывается в итоговую цену для потребителя (отказаться от > которой он не может даже если ему всё это не надо), Что значит не может? Его пинками гонят в магазин? На сайт? В банк? Кто это такой наглый? > а во-вторых в очумительный перерасход ресурсов на шарике, Да я и говорю - краску на дорожную разметку тоже жалко. Но вот отказаться от нее мы как-то не готовы, потому что иначе начинается апокалиптец.
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	241. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Анонн (?), 19-Ноя-18, 18:19
	>>> мобильный пров например врезал знакомому юзеру свой контент. >> Ещё раз - для этого существуют другие методы решения. Юридические. > Это не работает. Каждого гамнюка не построишь. Вот именно из-за такого подхода это и не работает (как врочем и "мне то че - это ж лохов стригут, а я не лох! Гы гы.") Вообще, есть такое эмпирическое правило: "социальные проблемы реново решаются сугубо техническим путем". И если пров может безнаказанно врезать в ваш трафик что-то свое, чтобы в наглую кинуть вас же на деньги, то чисто техническая затычка поможет только пока действует принцип неуловимого Джо. Потом просто придумают что-то новенькое.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	250. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от RomanCh (ok), 19-Ноя-18, 19:40
	> Вот именно из-за такого подхода это и не работает (как врочем и > "мне то че - это ж лохов стригут, а я не лох! Гы гы.") В общем да. Другое дело что сейчас даже если ты знаешь что ты не лох, то помочь "лохам" даже при большом желании ты не можешь, ибо на это нужны сильно более мощные ресурсы чем доступны одному, или даже нескольким людям. Более того, могу ещё сказать что если ты где-то не лох, то в другом месте обязательно будешь "лохом" (невозможно быть спецом по всему), и существующая система (я про везде, а не про РФ) обязательно этим воспользуется и стриганёт по полной. > Вообще, есть такое эмпирическое правило: "социальные проблемы реново решаются сугубо техническим путем". > И если пров может безнаказанно врезать в ваш трафик что-то свое, чтобы > в наглую кинуть вас же на деньги, то чисто техническая затычка поможет только пока действует принцип неуловимого Джо. Потом просто придумают что-то новенькое. Или просто это будет уже не пров, а какой-нибудь любитель майнинга в браузере, держатель ботнета, фишер и т.п. Для конечного пользователя будет только хуже, т.к. пров хоть рядом и с ним посудиться в принципе можно рискнуть, особо если набрать группу пострадавших. А с перечисленными мною персоналиям и им подобными - ищи ветра в поле. Но до большого любителя шифрования чего попало это похоже не хочет доходить. Возможно это какое-то религиозное учение, ну типа там свидетели гуголя и т.п. Хотя хочется верить в лучшее - то что это всего-лишь (пока что!) недостаточно широкий кругозор.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	252. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 29-Ноя-18, 21:43
	> Вот именно из-за такого подхода это и не работает Очень интенесно, как на практике мог бы работать например отлов каждого кулхацкера с кали-линуксом? А таки строительство подземных и надземных переходов сокращает число задавленных. При том не только когда кто-то на красный специально пер, но и когда у кого-то тормоза отказали. Если машины и люди не пересекаются, так безопаснее во всех случаях. Ну вот и с врезками и снифежом трафика - аналогично. > Вообще, есть такое эмпирическое правило: "социальные проблемы реново решаются сугубо > техническим путем". Оно как бы да, но бывает еще и так что технические проблемы и решения постепенно меняют и общество. Например, ПДД потребовался и прочие техосмотры. Чтобы с одной стороны не ездили черти как, а с другой было поменьше тех у кого тормоза отказали просто потому что их 20 лет никто не обслуживал, оказывается. > поможет только пока действует принцип неуловимого Джо. Потом просто придумают что-то новенькое. Придумать что-то новенькое для врезки в шифрованый трафик потребует прорыв в области криптографии. И если вдруг это работать перестанет - криптографы мигом переиграют это. При том юзерам браузер обновить - бесплатно, а ISP железо сменить - куча денег. Софтом в такие потоки данных они конечно же врезаться не смогут, производительности не хватит. В этом месте на стороне технарей и время и деньги.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	249. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от RomanCh (ok), 19-Ноя-18, 19:30
	> Это не работает. Каждого гамнюка не построишь. Так же как не поймаешь и не накажешь каждого кулхацкера с кали-линуксом и снифером. Что не работает, смена провайдера? Тады ой, совсем дело плохо. И да, давайте уж статистику по врезкам которой вы так размахиваете. А много-ли вы мне можете привести случаев как кулхацкеры наснифали что-то сколь-нибудь значимое? И да, тут мало сниффера, тут надо чуть-чуть больше мозгов приложить, что бы хотя бы по L2 сегменту соседа обмануть. А уж если вспомнить что ща повсеместно внедряются железки которые подобное фильтруют на раз, то это очередная отсылка к исключениям. Ещё раз - давайте не будем играть в дурную игру построения правил на исключениях. > выдвигая претензии сайту А почему не к производителю пальцетыка своего? Ведь он его включил, потыкал там пальчиком, и попал! Значит виноват пальцетык и тот кто его произвёл. Логично? Логично! От такой пуленепробиваемой логики вообще нет защиты, окромя как хорошего общего образования, но боюсь что в ближайшие десятилетия мы его не увидим. И да, ставлю на то что "в половине случаев" высосано вами из пальцев т.к. никакой статистики по проблеме у вас конечно нет. > Технари тоже понимают что безобразие надо рубить на корню - и в целом отрасль двигает в этом направлении. В направлении газенвагена? Судя по её "достижениям" последних лет - в общем-то да. И если она туда свалится, то будет прям совсем прекрасно. Вы кроме говорения воздуха в воздух можете привести какую-то адекватную статистику? Ну типа "вот ввели везде SSL" и лохов стали реже стрич? В жёстких циферях с пруфлинками. А я вам могу с уверенностью заявить потребление аппаратных ресурсов на бессмысленное шифрование публичного контента вырастает примерно в 2 раза по сравнению с передачей нешифрованного. > А если в какой-то географии пров монополист - то чего? Например поругаться с ним. Я ругался. И вы знаете - помогает. Просто не надо лечить диарею затычкой. > Однако усложнить это тем кто борзеет сверх всякой меры все же можно. Это бессмысленная борьба щита и меча которая будет вечной с примерно одинаковым выхлопом всё время. > Да и пароли в кафешках все же перестанет собирать оптом всего лишь примитивным запуском снифера по наглому, чтоли. Во-первых в РФ уже практически везде шифрованный wi-fi (криптостойкость пароля конечно отложим пока в сторонку). Но во-вторых, тут вы выронили мою главную мысль и включили методику спора под названием "соломенное чучело". Моя исходная посылка - нужна прозрачная для пользователя и максимально понятная для разработчика архитектура в которой чувствительные данные будут уходить шифрованными, остальные - нет. Нужно отделять мух от котлет. И это можно разработать, это можно внедрить. Но нет, мы лучше на всякий случай всё зашифруем и плевать на долгосрочный результат. И да, если боитесь врезок, то и html странички тоже можно в конце концов шифровать, это не так страшно как бессмысленное потоковое шифрование видео и картинок. В которые к тому же достаточно сложно делать врезки, о подобном ещё не слыхал. > В таком масштабе это не 1 сервер делает. Так по нормальному - это небольшой CDN, чтоли. И у него неозадаченных процов явно будет. А, да, это у нормальных людей еще и по глобусу раскидано в несколько мест. Ну т.е. вы никогда не видели как десятки серверов имеющих на борту от 30ти железных ядер (х2 если с включенным HT) встают в полку по процу. Понятно. И кстати совершенно непонятно как меняет ситуацию географическое разнесение серверов. В разных широтах по разному проц нагружается от шифрования? Интересные подробности. Мой опыт говорит что они встают в проц так же как и остальные. У вас другие данные? > Отлично, экономистов на спичках пытающихся перепихнуть свою экономию ценой пр Во, включились разговоры в пользу богатых. Про это собственно уже выше обсуждалось, можете перечитать. Вам невдомёк что подобный апгрейд раз-раз и без прорблем могут сделать в основном только большие конторы типа гуголя, удавливая тем самым всех остальных. В результате мы имеем всё более широкие монополии с соответствующим выхлопом результата (про полминуты загрузки гмейла не я тут придумал). И что самое "прекрасное" - конечный пользователь вместо улучшения функционала сервиса получает тот же сервис, но более тормозящий (нужно шифровать) и без улучшения функционала (деньги вместо разработки потрачены на закупку нового железа). Вот это я понимаю - настоящее счастье! > Ну как бы если штукатурка начнет падать раз в 20 минут А у вас таки есть статистика пострадавших? Давайте цифры в студию что-ли, а то беспредметная болтовня. > Так же как после энного количества задавленных мы полюбили ПДД. Отличный пример кстати! Согласно официальной статистике в РФ в ДТП гибнет один человек примерно раз в 20-30 минут. И логичней было бы на самом деле перевести большинство перевозок грузов на Ж/Д, а пассажиров - на комфортабельный современный общественный транспорт. Гибели сократились бы просто на порядки. И затраты ресурсов кстати тоже. Но эта система, она уродская с ног до головы и везде решает проблемы типа "диарея" затычкой в соответствующее место. С SSL ровно то же самое. Очередная затычка в виде более строгих ПДД, никак не решающая общего архитектурного уродства. > Его пинками гонят в магазин? Да нет же. Но вы идёте в магазин и покупаете необоснованно (для вас) дорогой девайс потому что других просто практически не выпускают. Ведь "всем надо шифровать котиков". А про дорожную краску, я надесюсь вы поняли выше. Учитесь думать чуть-чуть более широко и смотреть чуть-чуть более в корень проблемы. На этом, нуф сейд, как говорится.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	253. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (253), 29-Ноя-18, 23:45
	> Что не работает, смена провайдера? Иди скажи это другим знакомым, из села, у которых 2 едва ловящихся oпcoca и фига - весь ассортимент. > И да, давайте уж статистику по врезкам которой вы так размахиваете. Я что, справочная? Лично мне достаточно 1 прецедента у знакомых который дошел до меня. > А много-ли вы мне можете привести случаев как кулхацкеры наснифали что-то сколь-нибудь значимое? Логины-пароли на все что можно - ходовой товар на черных рынках. > И да, тут мало сниффера, тут надо чуть-чуть больше мозгов приложить, А чтоб включить monitor mode вафли и загрести пакетов? > что бы хотя бы по L2 сегменту соседа обмануть. Вы там в каком веке? > А уж если вспомнить что ща повсеместно внедряются железки которые подобное фильтруют на раз В вафле например эфир доступен всем на равных основаниях. > то это очередная отсылка к исключениям. Хорошее исключение - 90% хомячков. В пределах мкада - достаточно в метро спуститься. И можно крупнооптовой лопатой, так что если у ресурса не было шифрования... > Ещё раз - давайте не будем играть в дурную игру построения правил на исключениях. Исключение по состоянию на 2018 год это проводные сети с оборудованием защищенным от L2 атак. > А почему не к производителю пальцетыка своего? Ведь он его включил, потыкал > там пальчиком, и попал! Ну как бы вот вы это и доносите до легионов хомяков. Мне же воевать с ними неохота. > Значит виноват пальцетык и тот кто его произвёл. Логично? Логично! Логично. И иногда даже слышны гневные вопли. Просто дотянуться до них сложнее, а кто на виду - с солидными юридическими отделами. > В жёстких циферях с пруфлинками. Оно мне надо? Я могу просто посмотреть вокруг и посмотреть насколько ваши заявочки применимы к тому что я вижу. > А я вам могу с уверенностью заявить потребление аппаратных ресурсов на бессмысленное > шифрование публичного контента Оно таки не бессмысленное, когда под видом вашего ресурса какой-то пупкин засевший на вон той вафле (или даже железках ISP) начинает в траф врезать черт знает что, тырить пароли, собирать хрен знает какое досье и проч. Поэтому им и занимаются. > не надо лечить диарею затычкой. Предлагается уделаться поуши и пойти отстирываться? :) > Это бессмысленная борьба щита и меча которая будет вечной с примерно одинаковым > выхлопом всё время. Сдача со стороны щита = невозбранное отрезание голов всем вообще. Не годится. > Во-первых в РФ уже практически везде шифрованный wi-fi В публичных местах он либо не шифрованый либо ключ всем известен. > (криптостойкость пароля конечно отложим пока в сторонку). Конечно. Спустимся в московское метро. А там открытая вафля и миллионы хомяков. Так что если у ресурса не было шифрования... это хреновый, никуда не годный ресурс. А ключ на вафлю ставить - либо его все будут знать, либо 0 пользователей останется, перенастраивать вайельную сеть на каждую сессию в своем девайсе никто не будет. > архитектура в которой чувствительные данные будут уходить шифрованными, остальные - нет. А тут надо понимать что чувствительное с точки зрения хакера совсем не то же что и с точки зрения хмыря который ресурсы своих тазиков экономит. Владелец тазика пытается сэкономить копье любой ценой. И в этом месте его интересы против интересов юзеров, которых в результате трахнут хакеры, а то и сами ISP. > Но нет, мы лучше на всякий случай всё зашифруем и плевать на долгосрочный результат. Это достаточно радикально изводит целые большие классы атак. Например попытки внедрять левый JS код делающий фиг знает что. И хрен его знает какой там где архитект и посчитал ли он это критичным. А хакеры этим попользуются. > конце концов шифровать, это не так страшно как бессмысленное потоковое шифрование > видео и картинок. И чего помешает прову (или хакеру) подменять внаглую контент на свой, интересно? В половине случаев еще и какой-нибудь инклюд в HTML пролезет как "типа видео", главное чтобы хаксорский сервак инициативу перехватил и отлупил правильно. Насколько там архитект готов к обороту что его юзерей беспринципно подоят все - вопрос. > от 30ти железных ядер (х2 если с включенным HT) встают в > полку по процу. Понятно. Если сервер грузящий видео вдруг кладет в полку все 30 ядер - вероятно, он что-то делает не так. Хотя возможно что вы из тех психов, которые пытаются собрать 1 мегажелезку, в наивной надежде что она одна удержит на себе весь мир, конечно. Но это хреново работает, по совсем другим причинам. И горе вашей клиентуре если они еще не поняли куда таких архитектов слать надо, вместе с их творениями. > И кстати совершенно непонятно как меняет ситуацию географическое разнесение серверов. Там заодно люди в адекват приходят и перестают пытаться обслужить полпланеты одной мегажелезкой, начиная оптимизировать по цена/результат. После чего они почему-то резко перестают хвастаться мегаконфигурациями с странными проблемами. > В разных широтах по разному проц нагружается от шифрования? Нет, просто железо начинают выбирать по совсем иным критериям, так что по процу часто избыток, а по io ... сети как-то исторически развиваются намного медленнее чем CPU и даже RAM. Это по состоянию на сейчас - самое слабое звено. > так же как и остальные. У вас другие данные? Если чувак из гугли говорит что основной их гемор и затраты с сетями - получается что так. > Во, включились разговоры в пользу богатых. Работа должна быть сделана качественно. Не можете - вон с рынка. А насколько это будет дорого или дешево - ваши проблемы уже. Изыскивайте способы или проваливайте с рынка. Если хомяков при заходе на ваш сайт имеет хакер или isp - это таки халтурка уже по состоянию дел на сейчас. > функционала (деньги вместо разработки потрачены на закупку нового железа). > Вот это я понимаю - настоящее счастье! Как бы если хомяку врежут платный контент или стырят пароли - приходит НЕсчастье. И на месте хомяка логично выбирать сервисы где это исключено. > А у вас таки есть статистика пострадавших? У меня есть пострадавшие, на которых штукатурка упала. Поэтому я теперь серьезнее отношусь к каскам, а также состоянию фасадов зданий, прикидывая откуда может быть сюрприз. > Давайте цифры в студию что-ли, а то беспредметная болтовня. Статистику перевозок московского метро можно в вике посмотреть... > человек примерно раз в 20-30 минут. И логичней было бы на > самом деле перевести большинство перевозок грузов на Ж/Д, Так и представляю себе рельсы прямо к дому. Да даже подъездные пути к супермаркету. До ближайшей станции 30+ минут пехом. На автомобиле - не более 5. В общем разного масштаба штуки. ЖД для масштабных вещей и дальних дистанций скорее. Подвиды типа метро/легких вариантов частично улучшают, но - частично. К каждому дому пути и станцию не построишь, а полчаса пехать до станции, даже метрошной, все же долговато. И кстати для понимания - можете сунуться в московское метро в 6 утра в центр из какого-нибудь Выхино. Или в 6 вечера - из центра в том же направлении. Оно по некоторым направлениям на пределе даже с автоматикой близкой к границам разумного по соображениям этой самой безопасности, чтоб у поездов тормозной интервал был БЕЗ въезда в предыдущий поезд. Метро УЖЕ поезда гоняет почти вплотную с вот такими интервалами. И даже так не успевает развозить. Строить новые ветки - смотрим сколько это стоит, какие сроки, все такое. Построить вторую ветку в ту же сторону, не через цать лет а завтра, или через пару лет накрайняк - полбюджета города уйдет. А если не под землей - грохочущий под окнами поезд мало удовольствия. Да и не настолько дешевле, в городе ЖД тянуть гимор. Даже по эстакаде гимор. Ну вот с МЦК схалтурили немного, использовав существующие пути. Получилось неплохо, но вот как замена авто оно ну совсем ни о чем, платформы порой черти-где т.к. не строились под нужды города как таковые. Так что экономия вышла с последствиями. В общем замена совершенно не эквивалентная. > а пассажиров - на комфортабельный современный общественный транспорт. Уровень комфорта можно заценить в 6 утра, на станции Выхино, в центр :). Впрочем можно в 6-8 утра и в питерское метро вылезти. Тоже комфортабельно, я проверял. > Гибели сократились бы просто на порядки. А вам не приходило в голову что люди готовы немного рискнуть чтобы не давиться в вагоне как бочки в селедке? При том оно так в час пик вот так даже на линиях с нормальной автоматикой, держащей минимально безопасные тормозные интервалы между поездами. Построить параллельную линию для разгрузки - дико дорого и долго. > Но эта система, она уродская с ног до головы и везде решает > проблемы типа "диарея" затычкой в соответствующее место. У железных дорог масштабы совсем не персонализированные, так что даже разгрузить жрат в супермаркет - проблема. А чтоб домой попасть без гемора - и вообще. И вообще, примеры успешного внедрения легких городских ЖД по всему глобусу - достаточно малочисленны и авто они все же не заменяют, и даже не пытаются. > С SSL ровно то же самое. Очередная затычка в виде более строгих ПДД Скорее в виде аналога поездной системы блокировки, жмущая на тормоз вместо водилы если он прет на красный. > дорогой девайс потому что других просто практически не выпускают. Как бы там основная цена сейчас не из-за шифрования а потому что яванитармазит!!111 и прочие электроны. Поэтому без 4 ядер и 4 гиг оперативы - уже не человек. На фоне этих лагучих монстрил потребление ресурсов шифрованием никто и близко не заметит. Там все же компактный сишный код, зачастую с асм оптимизацией, что по сравнению с jit и прочими скриптанутыми монстрами - ни в какое сравнение. > Ведь "всем надо шифровать котиков". Если все приходит к тому что иначе котики становятся по 300 рублей с лоха, а с аккаунта начинает лететь спам - тогда увы. И поездам системы управления движением, упраздняющие проезды на красный придется поставить. > А про дорожную краску, я надесюсь вы поняли выше. Вы так говорите, как будто рельсы бесплатные. А, следующий шаг - сказать что из дома вообще не надо высоываться. Тогда можно и без рельсов обойтись. И смертей будет еще меньше. Формально это конечно так. А реально... эээ... ну его нафиг жизнь уровня средневековья.
	Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

	15. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+27 +/–
	Сообщение от mumu (ok), 12-Ноя-18, 09:26
	Когда за недостаток производительности платить им самим (server-side), они очень охотно её оптимизируют. Это для client-side можно пихать всякие жабаскрипт и грузить gmail по пол минуты после этого, рассказывая как это круто, модно, молодёжно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	40. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Клыкастый (ok), 12-Ноя-18, 11:02
	для тех, кому не нужно модно-стильно-молодёжно есть олдскульные почтовые клиенты и IMAP, так что не так страшен gmail...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	44. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+4 +/–
	Сообщение от Аноним (44), 12-Ноя-18, 11:13
	Ты ещё UUCP вспомни. Всё ещё длящееся существование почтовых клиентов никак не отменяет того факта, что большинство веб-морд откровенно тормознутые на пустом месте.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	50. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Клыкастый (ok), 12-Ноя-18, 11:43
	> Ты ещё UUCP вспомни. Всё ещё длящееся существование почтовых клиентов никак не Опеннет - форум контрастов. Одновременно жалуются на модное молодёжное и отрицают немодное, работающее. > отменяет того факта, что большинство веб-морд откровенно тормознутые на пустом месте. в случае с gmail таки есть выбор
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	70. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (70), 12-Ноя-18, 13:23
	>в случае с gmail таки есть выбор   довольно мнимый. Да, IMAP там формально есть. Но например уведомления по IMAP IDLE приходят с хорошей задержкой, а то и вообще не приходят, пока не откроешь веб-интерфейс. При этом официальный клиент под андроид работает как часы. Я уверен, что это сделано намеренно.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	85. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 14:24
	ась? У меня всё нормально приходит, секунды, как и положено. Веб-морда неделями/месяцами не открывается. А вот SeaMonkey/K-9 используются постоянно. Может, что-то с настройками всё же?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	123. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (123), 12-Ноя-18, 17:50
	Зачем вообще уведомления? Это же почта, а не мессенджер, ее главное преимущество как раз в том, что ее читаешь когда захотел, а не когда написали.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	126. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (126), 12-Ноя-18, 17:58
	>>в случае с gmail таки есть выбор > довольно мнимый. Да, IMAP там формально есть. Но например уведомления по IMAP > IDLE приходят с хорошей задержкой, а то и вообще не приходят, > пока не откроешь веб-интерфейс. При этом официальный клиент под андроид работает > как часы. Я уверен, что это сделано намеренно. Я вообще на гмыле POP3 использую, никаких проблем
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	137. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (123), 12-Ноя-18, 18:33
	Пожалуйста, не используйте gmail, не надо помогать корпорации монополизировать последнее еще независимое и децентрализованное и при этом массово используемое средство коммуникации.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	171. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Ноя-18, 00:33
	> Пожалуйста, не используйте gmail, не надо помогать корпорации монополизировать последнее > еще независимое и децентрализованное и при этом массово используемое средство коммуникации. Поздно, чувак. Сегодня хорошим тоном стало иметь на визитке личное гугломыло.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	185. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (185), 13-Ноя-18, 13:51
	Вы попали в плохую компанию. К счастью, не везде почта на гуглу считается более лучшим тоном, нежели почта у старика Винера или на Яндексе.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	254. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Клыкастый (ok), 30-Ноя-18, 10:59
	> Поздно, чувак. Сегодня хорошим тоном стало иметь на визитке личное гугломыло. А свой домен и "вам-не-пофиг-что-там-под-капотом" уже неактуально?
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	255. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от КГБ СССР (?), 30-Ноя-18, 12:03
	Вот уже несколько лет актуальнее иметь «красивое имя» на Пейсбуке, Вконтагте и прочих таких оазисах прекрасного. Ну не ходит никто на стендалоны, пора уж смириться. Даже к реальным знаменитостям не ходят.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

	256. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Клыкастый (ok), 30-Ноя-18, 12:30
	> Вот уже несколько лет актуальнее иметь «красивое имя» на Пейсбуке, Вконтагте > и прочих таких оазисах прекрасного. > Ну не ходит никто на стендалоны, пора уж смириться. Даже к реальным > знаменитостям не ходят. мы всё ещё о почте?
	Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

	257. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от КГБ СССР (?), 30-Ноя-18, 13:58
	> мы всё ещё о почте? И о почте тоже. Свой домен в большинстве случаев иметь нынче незачем, на твой сайт всё равно никто не пойдёт. Да и почту не спросят, а сразу запишут смартфоном в Пейсбук, Телеграм, Вайбер и Всосапп. Если же вдруг нечаянно спросят о почте, то почта на Гмыле — признак прогрессивности. Нулевые денежные затраты. Продай себя за трафик — и будь свободен и современен!
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	49. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (49), 12-Ноя-18, 11:40
	> грузить gmail по пол минуты после этого, рассказывая как это круто, модно, молодёжно Gmail таки как раз застрял на гугле либах от 2009 года. Оттуда такой дикий размер и тормоза. Был же недавно разбор, что там за дикие костыли под капотом. Походу, уже никогда не перепишут на что-то легковесное.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	81. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Попугай Кеша (?), 12-Ноя-18, 14:17
	На что переписывать? На Angular, API которого они меняют быстрее, чем выходит новый Chrome? Или на React от Facebook? Да они его люто ненавидят.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	101. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
	Сообщение от zzz (??), 12-Ноя-18, 15:30
	Да ну бросьте вы. Windows поддерживает обратную совместимость без всяких тормозов, и никто не говорит "Ну вы знаете, нам же в десяточке надо обеспечивать совместимость с 2000, XP, 7, поэтому десяточка в пять раз тормознее XP". Если бы гугл хотел сделать интерфейс легким - при его возможностях это было бы сделало буквально за месяц со всеми регрессиями и обкатками. Равно как и твиттер, который сейчас на горстку 280-символьных сообщений грузит тонны яваскрипта, что при прокрутке дальше 40-ого твита всё начинает жутко лагать. Фейсбук туда же, попробуй прокрути ленту - после десятого скрина страница будет еле ворочаться. Всё можно было бы сделать лайтовее, просто им это - не надо.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	61. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Nemton (?), 12-Ноя-18, 12:44
	Они скорее больше за сервера свои беспокоятся, чтобы на них нагрузка уменьшалась
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	77. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+9 +/–
	Сообщение от MrClon (ok), 12-Ноя-18, 13:47
	>в 2018 году это как-то непривычно звучит, ведь сейчас в моде наплевательское отношение к производительности Не беспокойтесь, по этому лёгкому и быстрому протоколу клиенты будут ломиться на медленные бекэнды чтобы скачать тяжелый фронтенд
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	122. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (122), 12-Ноя-18, 17:42
	Это пять. В точку.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	103. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 12-Ноя-18, 15:40
	Угу. И особенно радует "Для видеосервисов, таких как YouTube". Сначало был нормальноый дизайн, который быстро загружался, а сейчас сделали тормознутое г. После этого надо придывать новые стандарты, чтобы это всё бысто работало.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	105. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 12-Ноя-18, 15:42
	придывать = придумывать
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	140. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (126), 12-Ноя-18, 20:07
	> Угу. И особенно радует "Для видеосервисов, таких как YouTube". Сначало был нормальноый > дизайн, который быстро загружался, а сейчас сделали тормознутое г. После этого > надо придывать новые стандарты, чтобы это всё бысто работало. Не тупи, это про загрузку самого видео, вся остальная мишура потребляет считаные проценты от трафика
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

2. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
Сообщение от eRIC (ok), 12-Ноя-18, 08:52
HTTP/3 помимо новых фич, должно также нести решения проблем первой и второй версии
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+9 +/–
	Сообщение от Аноним (6), 12-Ноя-18, 08:58
	> HTTP/3 помимо новых фич, должно также нести решения проблем первой и второй версии Исправления доводят через обновление RFC, а не смену версии протокола. Например, HTTP/1.1 актуализирован в RFC 7230, который заменил старый RFC 2616.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	129. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–2 +/–
	Сообщение от eRIC (ok), 12-Ноя-18, 18:20
	> Исправления доводят через обновление RFC, а не смену версии протокола. Например, HTTP/1.1 > актуализирован в RFC 7230, который заменил старый RFC 2616. итог то один для всех принытых RFCшок, которые в итоге дадут версию 3ю по счету HTTP
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

3. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
Сообщение от Аноним (3), 12-Ноя-18, 08:52
Здорово, что для оптимизации работы, нет убеждений как преград. Возможно всё!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
Сообщение от Аноним (5), 12-Ноя-18, 08:56
И это вместо того, чтобы делать tcp/2? )))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (6), 12-Ноя-18, 09:01
	Уже в SCTP попробовали, не получилось. Лучше уж поверх UDP.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	24. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от daemntux (?), 12-Ноя-18, 10:00
	SCTP нужен для мобильной телефони, он не предназначен для коротких сессий, так как handshake занимает 4 шага. Да и фишки типа multihouming в web не актуальны. А если делать tcp 2.0 то будут проблемы у существующих маршрутизаторов и FW. Так что лучше в UDP засунуть
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	45. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (49), 12-Ноя-18, 11:32
	Не лучше, в Linux Kernel у UPD Datagram намного дороже CPU-cost, чем у TCP. Да и в целом QUIC плохо работает на каналах с packet reordering (аки мобилки). В общем, гугль пропихивает сугубо академический проект, сильно оторванный от реальности (прям как это было со SPDY). Внедрение будет болезненным.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	102. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от zzz (??), 12-Ноя-18, 15:34
	Ну уж не академический, всё-таки гугл его гонял в практическом плане. Вот только выгоды от этого видятся только что гуглу, который ради 10% снижения нагрузки на свои сервера навязывает свои инициативы всему миру.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	239. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:16
	> Не лучше, в Linux Kernel у UPD Datagram намного дороже CPU-cost Вот заодно и оптимизируют как раз. Не было бы счастья, да несчастье помогло...
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	27. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+5 +/–
	Сообщение от КГБ СССР (?), 12-Ноя-18, 10:07
	Потому что суть этой «инновации» в превращении Интернета в Гуглонет. Гугль аж из трусов выпрыгивает, чтобы перетянуть на себя «протокольную» часть. Переделать старые RFC им не под силу — так они изо всех сил продвигают «прогрессивные инновации». Мир бы стал намного лучше и чище, если б на Гугль упала ядреная бомба или хотя бы метеорит.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	30. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 10:16
	IETF уже здорово лоханулась с академическим IPv6, есть подозрение, что QUIC - что-то около.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	33. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+3 +/–
	Сообщение от пох (?), 12-Ноя-18, 10:46
	quic - гораздо хуже чем даже ipv6 - потому что за ним стоит тупая махина гугля, который и пропихнет его в качестве единственного стандарта, потому что _им_ так удобнее. А чиновники ietf небрезгливы и деньги берут где дают, им очень-очень хочется кушать.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	43. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от КГБ СССР (?), 12-Ноя-18, 11:13
	> quic - гораздо хуже чем даже ipv6 - потому что за ним > стоит тупая махина гугля, который и пропихнет его в качестве единственного > стандарта, потому что _им_ так удобнее. > А чиновники ietf небрезгливы и деньги берут где дают, им очень-очень хочется > кушать. Мы стоим на пороге большого шухера. И самое мерзкое в этом то, что некому воспрепятствовать Копрорации Бобра. Измельчал народец, а частью помер, а кого и просто купили.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	240. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:18
	> Мы стоим на пороге большого шухера. И самое мерзкое в этом то, что > некому воспрепятствовать Копрорации Бобра. Измельчал народец, а частью помер, а кого > и просто купили. С инженерной точки зрения гугл по своему прекрасен - они эффективны и работают на результат, вместо академических рассусоливаний десятилетиями. Им реально надо чтобы сети работали, гоняли траф и проч. И это надо отнюдь не только им.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	246. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Анонн (?), 19-Ноя-18, 18:44
	> С инженерной точки зрения гугл по своему прекрасен - они эффективны и > работают на результат, вместо академических рассусоливаний десятилетиями. Им реально надо чтобы сети работали, гоняли траф и проч. И это надо > отнюдь не только им. Но делают они только то и (обычно) только так, как нужно только им. Что в реальности для всех не-гуглей может означать замену одной кучи граблей на другую, в новом, хайтековом дизайне.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	264. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (264), 03-Дек-18, 09:03
	> Но делают они только то и (обычно) только так, как нужно только им. Было бы странно если бы они делали как это надо кому-то еще. > Что в реальности для всех не-гуглей может означать замену одной кучи граблей > на другую, в новом, хайтековом дизайне. А может и не означать. Какие у них задачи принципиально отличные от гугловских в этом контексте?
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	47. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Анонимос (?), 12-Ноя-18, 11:37
	У тебя есть уникальная возможность предложить альтернативу гугловскому протоколу и войти в анналы
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	72. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (72), 12-Ноя-18, 13:23
	Ви так говорите, как будто между собой соревнуются два стартапа, расположенных в соседних подвалах.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	242. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:20
	> Ви так говорите, как будто между собой соревнуются два стартапа, расположенных в > соседних подвалах. Если его протокол будет лучше работать - гугл таки им воспользуется, пожалуй. При условии что это можно будет внедрить в разумные сроки и более-менее везде, разумеется. Если там надо новый ядерный драйвер например, как с SCTP - ну тогда вы и будете убеждать майкрософт с его долей на десктопе это сделать. А не сможете - грош цена вашему протоколу, соответственно, поскольку он в реальном мире с тем что там реально водится дескать не работает.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	56. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (56), 12-Ноя-18, 12:24
	> пропихнет его в качестве единственного стандарта, потому что _им_ так удобнее. Полно rfc которые не взлетели или устарели и не используются. Посмотрим, если у quic будут проблемы его просто не будут использовать никто кроме google и ему придётся дорабатывать протокол или отказаться от него в итоге.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	93. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от пох (?), 12-Ноя-18, 15:04
	> Полно rfc которые не взлетели или устарели и не используются. это потому, что написать rfc и добыть ему официальный номерок может любой дятел. А вот заставить всех плясать под свою дудку может только гугль. Ну и еще мордокнига и амазон, отчасти. > Посмотрим, если у quic будут проблемы его просто не будут использовать никто кроме google а никакого другого интернета тоже не будет.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	69. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (69), 12-Ноя-18, 13:17
	Просто сделают ipv8, нормально обратно совместимый с v4, и не переусложнённый настолько, что настройку домашнего роутера человек с высшим техническим образованием без нескольких часов чтения манулов осилить не может. Ну как с UTF16/32 и UTF8. Без нормального обратно-совместимого UTF8 юникод никому нафиг не падал нигде, кроме как внутри потрохов винды, куда UTF16 был запихнут как раз из академических и оторванных от реальности соображений.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	95. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от пох (?), 12-Ноя-18, 15:06
	не сделают. Некому уже сделать. Скорее сделают оверусложненный v10, который будет управляться контроллерами с искусственным интеллектом и вообще не поддаваться ни конфигурированию, ни траблшутингу. Правильный контроллер выпустят правильные ребята, разумеется.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	234. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 17:44
	> Скорее сделают оверусложненный v10, который будет управляться контроллерами с искусственным > интеллектом и вообще не поддаваться ни конфигурированию, ни траблшутингу. Хорошие сети - повсеместны, неубиваемы и конфигурируются сами. Сюрприз. Так должно быть - и так будет. Слышал когда-нибудь про концепцию "умной пыли"? К этому все придет. Это путь семейства технологий. Он не может быть остановлен. Те кто попытается - нагреют сами себя, а технологии все-равно придут.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	172. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от macfaq (?), 13-Ноя-18, 00:33
	> Просто сделают ipv8, нормально обратно совместимый с v4, и не переусложнённый настолько, > что настройку домашнего роутера человек с высшим техническим образованием без нескольких > часов чтения манулов осилить не может. Сложно понять, к чему тут протокол IP. Домашний роутер и человек без технического образования настроить может, причём без нескольких часов чтения мануалов. Сложно, но можно.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	173. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (173), 13-Ноя-18, 02:45
	IPv6 решает проблему нехватки адресов, хотя бы.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	178. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (12), 13-Ноя-18, 09:05
	Попутно ломая всё остальное. Квик тоже решает проблему отсутствия мультипоточности и 0-RTT в TCP...
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	198. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от пох (?), 13-Ноя-18, 16:55
	> IPv6 решает проблему нехватки адресов, хотя бы. высосанную из пальца, замечу вам, проблему. 1. "каждому холодильнику" не то что не нужен - а приходится принимать отдельные меры чтобы НЕ был доступен из интернета отдельный адрес. 2. блоков A и B понараздавали кому попало, а отобрать - не смотря на повторяемые мантры "это не ваши адреса, это наши адреса" - оказалась кишка тонка. В результате - огромные блоки ныне мертвого нортеля и сана достались "кому надо", да и ibm использует свои вовсе не для того, для чего ей их выдавали. и даже при всем при этом - адресов пока хватает и они за последние годы подешевели чуть ли не вдвое, когда кончилась песня "щас-щас последние разберут и вообще не купите", а идиоты, нахапавшие впрок, получили счета от регистри за обслуживание провалов, чтоб не сильно проваливались.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	203. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (12), 13-Ноя-18, 20:44
	Нормальное решение лежало на поверхности: у каждого ISP есть своя ASN32. Добавить это префиксом к IP-адресу, и всё - каждый ISP имеет своё адресное пространство IPv4. А возможно не одно. И роутинг сильно упрощается - не надо смотреть сами блоки адресов, достаточно префикса ASN. Да, модификация всего оборудования для новой версии протокола также бы понадобилась. И шлюзовать v4 в v4asn также пришлось бы по первости. Но вот в качестве базы был бы взят весь имеющийся и прекрасно работающий стек, модификации коснулись бы только адресации. Косяков типа тотальнейшего звездеца с автоконфигурацией и ND было бы гораздо меньше.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	204. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 20:48
	"роутинг сильно упрощается" - читать как "глобальный роутинг сильно упрощается". IPv6 наступает на те же грабли распухания таблицы маршрутов. Естественно, возможность смотреть на более длинный префикс при роутинге осталась бы, но в 99% случаев не применялась.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	209. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от пох (?), 13-Ноя-18, 22:07
	> "роутинг сильно упрощается" - читать как "глобальный роутинг сильно упрощается". память нынче дешевая, это тоже далеко не главная проблема. ты бы вот видел, какой в v6 ipsec...
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	210. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 22:46
	Да он везде такой, хоть в в6, хоть в в4 ) Просто в в6 академики опять постарались с комбайнёрством. --- Тут не совсем память. CAM/hash с приличной ассоциативностью не так дёшева, как кажется. В один такт уместить выборку префиксов v6 особо не получается - слишком много логики, а полувыборка или хэш мало того, что требуют минимум два такта, так ещё и в разы объём этой памяти увеличивают. В IPv6, который ни жив ни мёртв, сейчас уже 60к маршрутов, с ростом этой таблички оно нормально подзабьёт CAM даже на девятитонниках с трайдентами, в которых всего 128к v6 маршрутов. Тайфуны прожуют, конечно.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	212. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 22:52
	> ты бы вот видел, какой в v6 ipsec... Самое охеренное - это v6 over PPP. Которому мало просто LCP для делегации, ещё и отдельный автоконф в каждый стык подавай. Идиотия 80 lvl. Цискобрасы вообще IPv4 и IPv6 в совместный полисер запихать не дают, тоже тема :D Из-за этого дать юзеру v6 плюсом к v4 - это де факто удвоить максимум полосы, если порт позволит.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	238. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:06
	> Самое охеренное - это v6 over PPP. > Идиотия 80 lvl. Да, заниматься PPP в 2018 году - это именно оно самое. Иррелевантно к IPv6 и прочее. Это протокол из эпохи диалапа. Под диалапные реалии. Диалап вымер как мамонты, даже сотовые модемы уже во многом отучились от него - потому что когда LTE лупит под 100 Мбит - все начинает упираться в обработку PPP...
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	208. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от пох (?), 13-Ноя-18, 22:06
	> Нормальное решение лежало на поверхности да много их было, нормальных идей (включая банально отобрать и переделить эти самые A и B, хватило бы всем, кроме китайцев, и еще бы осталось на следующие лет 100, учитывая околонулевое количество желающих использовать эти A по исходному назначению - для внутренней сети). но победило японское хентайное угребище, еще и изначально спроектированное со словами "nat не нужен, прозрачная трансляция 624 и наоборот ненужно, каждому холодильнику по адресу привязанному к маку, прайваси ненужно, multihomed lir'ов 4096 should be enough for all". Любого из перечисленных пунктов вменяемым людям хватило бы, чтоб пинком под зад отправить проект в помойку, где ему самое место. Но кто сказал, что в ietf вменяемые? Наоборот, самых бесполезных именно туда и пристроили. > Косяков типа тотальнейшего звездеца с автоконфигурацией и ND было бы гораздо меньше. это они как раз считали не косяком, а величайшим достижением. "dhcp ненужен!" потом оказалось, как обычно, что RA и назначение адресов - далеко не единственная задача dhcp и даже не самая главная (и давным-давно решенная в ipv4 - для тех недосетей где этого достаточно). что опять же говорит нам о квалификации и вообще близости к реальному миру тех, кто это понапроектировал.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	211. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 22:50
	Я бы не сказал, что оно хентайное, потому что самый мерзкий хентай с понями и радугой гораздо кавайнее чем IPv6. Но вот да - невменозом отдаёт только в путь. Попытались одновременно с адресацией перекомбайнить весь стек. Итог печален.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	236. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 17:59
	> но победило японское хентайное угребище, еще и изначально спроектированное со словами "nat > не нужен, прозрачная трансляция 624 и наоборот ненужно, И это были очень правильные слова. Нат всего лишь куча костылей. > каждому холодильнику по адресу Протоколы семейства TCP/IP изначально так и задуманы. То что какие-то похи все извратили - они не Vint Cerf и им это с рук не сойдет, даже не надейтесь. > привязанному к маку, прайваси ненужно, В линухе сие настраивается. Можно и не привязывать к MAC. Да и вообще, нормальные провы минимум /64 выдают, и как именно его распределить - в общем локальные проблемы, к маку особо не привязанные. Хотя конечно бывают жадины которые жмутся, экономя 128 битов. Которые все ж не 32. > Любого из перечисленных пунктов вменяемым людям хватило бы, чтоб пинком под зад > отправить проект в помойку, где ему самое место. Ну как бы проблема есть, сейчас уже даже хостинги, даже виртуалочные, начинают зажимать уникальные IPv4 порой, предпочитая всякий левый портфорвард и прочие извраты. Которые сильно все усложняют. > не единственная задача dhcp и даже не самая главная (и давным-давно > решенная в ipv4 - для тех недосетей где этого достаточно). В ipv4 оно так чудно решено было что потом шелскрипты от рута аж выполняются. В ipv6 конечно есть бестолковости, но на фоне v4 это шаг вперед. > что опять же говорит нам о квалификации и вообще близости к реальному > миру тех, кто это понапроектировал. Так желающих и могущих сделать это лучше - не нашлось. На опеннете трындеть бесполезно. Если б вы в IETF трындели, вас может даже кто и услышал. Но нет, цепляться за v4 когда ip-enabled устройств на планете уже более 2^32 - это не решение. И дефицит v4 таки уже начал продавливать v6 в массы.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	235. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 17:50
	> 1. "каждому холодильнику" не то что не нужен - а приходится принимать > отдельные меры чтобы НЕ был доступен из интернета отдельный адрес. И в результате приходится или сдаваться в рабство облачному сервису хрен знает кого, решающему эту проблему, или - увы - порулить холодильником и выключить свет сидючи в поезде уже не получается. А вот это - хреново. Задумано не так. > 2. блоков A и B понараздавали кому попало, а отобрать - не В мире уже больше устройств чем айпишников - мобилы уже у каждого первого почти, одно это миллиарды устройств. А когда толпень юзерей за натом - просто за гранью зла. Когда 1 кызел наспамит с прововского ната, а потом половина прова курит бамбук в результате. Получая левые претензии и напрягая толпы сапортов. Кому оно такое надо?
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	71. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (71), 12-Ноя-18, 13:23
	В гугле на полном серьезе проводятся (или по крайней мере проводились в 2011 году) учения по восстановлению работы после попадания метеорита в датацентр.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	237. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:03
	> В гугле на полном серьезе проводятся (или по крайней мере проводились в > 2011 году) учения по восстановлению работы после попадания метеорита в датацентр. Инфраструктура гугля по состоянию на сейчас просто не заметит попадание метеорита. И пользователи не заметят. Станет работать чуть медленнее, юзеры перетекут на сервера вокруг. В распределенной структурке чуть просядет уровень избыточности на время, но это будет далеко от уровня при котором юзеры заметят потери данных. Нет, ну мониторинг конечно обнаружит проблемы, спецы отправятся чинить или деплоить новые серваки в других местах, чтобы восстановить общую мощность инфраструктуры. Но это в обычном рабочем режиме, без авралов как у некоторых других.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	196. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Zulu (?), 13-Ноя-18, 16:06
	Да. На самом деле именно это сказано где-то в начале rationale: по-хорошему, надо бы tcp v2, но его ж пока внедришь, так что идем другим путем, через огороды.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	229. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 00:09
	> И это вместо того, чтобы делать tcp/2? ))) А ты убеди майкрософт внедрить его потом. Желательно не через 20 лет. В случае UDP это не требуется - программы все могут сделать сами. Собственно из-за таких якорей с их совместимостью и получается облом. Ну вон у линуксоидов есть планировщики пакетов которые лучше на беспроводке работают. Но толпе юзеров винды от этого не легче, ютуб у них как лагал так и лагает.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+4 +/–
Сообщение от Аноним (12), 12-Ноя-18, 08:59
UDP и 0-RTT - это хорошо. Можно невозбранно спуфить IP и флудить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 09:04
	Упреждая "ааа оно тама всё зачичено разрабатывалась прафесианалами с учотом": оно, я так понимаю, сначала пытается декриптить фрейм, потом уже обрабатывает. Декрипт - операция далеко не бесплатная, соответственно задача по перегрузке CPU флудом слегка упрощается. В худшем случае - ещё предстоит обнаружить в этом счастье amplification attack.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	25. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
	Сообщение от Аноним (25), 12-Ноя-18, 10:01
	Ну так когда оно пойдёт в массы у процессоров будут специализированные блоки, которые позволят декриптить фрэймы с минимальными затратами ресурсов.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	29. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 10:11
	Догадайтесь, почему нет :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	76. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (76), 12-Ноя-18, 13:31
	Поддержка AES уже есть в современных более или менее CPU. В моем проекте гигабит зашифрованного трафика(aes_128_ctr) поверх SCTP, пролетает со свистом на одном ядре.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	91. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Stax (ok), 12-Ноя-18, 14:58
	Неудивительно, даже десктопный проц может > 7 гигагабит (по бенчу openssl speed -evp aes-128-ctr) на одном ядре )
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	100. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Акакжев (?), 12-Ноя-18, 15:23
	> В моем проекте гигабит зашифрованного трафика(aes_128_ctr) поверх SCTP, пролетает со свистом на одном ядре. А какой звук у предшествующей (зашифровыванию) фазы "расширение ключа"?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	113. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (76), 12-Ноя-18, 16:25
	aes-128-ctr представляет из себя симметричное шифрование, по этому получение расширенного ключа используется как при шифровании так и при де шифровании. Следовательно шифруется и дешифруется оно с одинаковым звуком - со свистом. Вабще не уверен точно, но по идее расширение ключа должно быть тоже реализовано аппаратно на CPU с поддержкой AES, иначе в чем смысл иметь только частичное аппаратное ускорение алгоритма. Даже если это не так, то алгоритм расширения ключа, на первый взгляд, выглядит так как будто можно задействовать векторные регистры для его ускорения, в итоге все равно будет очень быстро.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	176. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Акакжев (?), 13-Ноя-18, 07:14
	> в чем смысл > иметь только частичное аппаратное ускорение алгоритма. В типичном сценарии (шифрование потока данных) расширение ключа выполняется 1 раз на (допустим) 1000 блоков и на суммарное время обработки влияет пренебрежительно мало. Ускорили узкое место. Если же ключ расширять перед обработкой единственного блока, то отношение временных затрат на каждую фазу меняется кардинально. > Даже если это не так, > то алгоритм расширения ключа, на первый взгляд, выглядит так как будто > можно задействовать векторные регистры для его ускорения, в итоге все равно > будет очень быстро. Когда занимался вопросом, имел на руках и тесты, и их результаты. Ныне интерес праздный и схалявничать не удалось.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	141. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:35
	Брутфорс ключа малой длины на миллионе-другом нод в итоге будет не менее свистящ. А большой ключ будет куда менее :) Вся криптография держится именно на (относительно) низкой производительности вычислений.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	165. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от анон (?), 12-Ноя-18, 23:18
	не вычислений, а поиске ключа для дешифровки. Сами алгоритмы шифрования/дешифровки при наличии апаратного ускорения очень, ОЧЕНЬ шустрые.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	189. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (76), 13-Ноя-18, 14:52
	Ничего не мешает менять ключ периодически, скажем, каждую минуту.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	247. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:44
	> именно на (относительно) низкой производительности вычислений. Современное крипто держится на большом количестве вариантов перебора. Даже если вы проверяете ключ за 1 такт процессора, а процессор очень крутой, потребляющий порядка планковских величин энергии на этот такт (мечта майнеров, в общем, близкая к теоретическим пределам), перебрать 2^256 ключей у вас просто не хватит энергии в доступной вам части вселенной. И атака провалится. Кстати, в этой формулировке время операций не фигурирует, это вообще не важно :). Если вы изведете существенный кусок вселенной с нулевым результатом в тепло - тем хуже для вас.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	110. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (110), 12-Ноя-18, 16:14
	> Декрипт - операция далеко не бесплатная Симметричная криптография очень даже дешева. Хоть и не бесплатна, конечно. Ассимметричная, например TLS handshaking - довольно дорога.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	142. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:36
	Ну тоже не дешёва, но сравнительно да.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	230. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 00:10
	> Ассимметричная, например TLS handshaking - довольно дорога. После появления эллиптики ваши данные протухли. Главное DJB использовать, а не АНБшные бэкдоры :)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	265. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от InuYasha (?), 03-Дек-18, 12:55
	эллиптика и есть бэкдоры. сами ОНБЭ от них поспешили избавиться
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	191. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Zulu (?), 13-Ноя-18, 15:54
	CPU usage это действительно самый большой concern в данный момент. Практически, это обходится ограничением использования QUIC -- запрос идет на HTTP, и если сервер считает что игра стоит свеч, в ответе есть хедер "а вот у нас тут еще квика немножко есть". Стопроцентная замена HTTP/1.1 на HTTP/QUIC вроде пока никем не планируется.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	231. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 00:12
	Однако многие сайты на HTTP/2 уже перешли. Правда 1.1 для совместимости все же оставили.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	34. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от пох (?), 12-Ноя-18, 10:48
	ты же понимаешь, что спуфить и флудить будут не сервера гугля (которым в общем-то пофигу, у них во-первых хватит мощностей, во-вторых нафиг они не сдались) а (от их имени) хосты клиентов и, может, еще серверки побежавших впереди паровоза обезьянок, срочно переведших их на новые-модные технологии - чем быстрее те лопнут и клиент перейдет в гуглооблачка, тем лучше для гуглового бизнеса. А клиентов вообще никому не жалко.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	164. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:17
	Конечно понимаю ) Об чём и речь. С другой стороны и серверам гугля придётся как придётся - новый гмейл у них - образчик черепашьей походки.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	201. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Sw00p akaJerom (?), 13-Ноя-18, 18:07
	а спама сколько от них лезет?
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

10. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Chupaka (?), 12-Ноя-18, 09:06
А что такое повторная буферизация?..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 09:13
	Полагаю, что имеется в виду рестарт буферизации потока из-за опустошения буфера или срыва соединения.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

14. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
Сообщение от Аноним (14), 12-Ноя-18, 09:19
HTTP поделить на 3?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+3 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 09:28
	HTTP/0 было бы нормальным названием. От "0-RTT".
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	41. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+5 +/–
	Сообщение от Клыкастый (ok), 12-Ноя-18, 11:05
	"HTTP на троих". я считаю это очень ёмкая трактовка, желающие обязательно заметят аллюзии, не одну и не две :-)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от anonymous (??), 12-Ноя-18, 09:37
И все как-то забывают, что в QUICK практически нет отладочной информации (незашифрованной), которая позволит диагностировать проблемы на транспортных узлах.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 09:42
	Предполагается, что транспорт в содержимое сообщения вообще не вмешивается. С одной стороны - это хорошо, меньше будет всяких мерзких проксей, врезальщиков рекламы и прочей радости. С другой стороны - ISP клиентов с "у меня что-то сайт медленно работает" начнут рекомендовать это отключить.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от anonymous (??), 12-Ноя-18, 09:49
	> Предполагается, что транспорт в содержимое сообщения вообще не вмешивается. Можно было бы просто подписывать, а не шифровать.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 09:51
	Подписка не спасёт например от попыток поанализировать flow control для некой приоритизации.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	23. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от anonymous (??), 12-Ноя-18, 09:58
	> поанализировать flow control для некой приоритизации. И чем это плохо? Когда все равны, хреновый трафик забьет все остальное. Гуглу положить на флоу практически на всем пути, и их красивые картинки только для идеальных условий. А бодаться на практике с этим поделием придется провайдерам.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	28. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 10:07
	Да было уже - начали TCP Options анализировать. Теперь этот механизм вообще использовать сложно, потому что оборудование в ответ на таковые ведёт себя неизвестным образом.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	128. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от имя (?), 12-Ноя-18, 18:20
	>И чем это плохо? Когда все равны, хреновый трафик забьет все остальное. man net neutrality
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	183. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (72), 13-Ноя-18, 12:59
	Который сейчас активно отменяется, угу.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	38. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+4 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 10:58
	Ну пусть порекомендуют отключить гугл или хром, угу. Прогнутся, никуда они не денутся. Их дело - молча работать трубой
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	143. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:38
	Гугл и хром никто рекомендовать отключить не будет. А вот сделать так, чтобы квик фолбэчился до TCP - запросто.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	83. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Попугай Кеша (?), 12-Ноя-18, 14:21
	Тогда разрабы задумаются над оптимизацией. Что хорошо
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

19. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Аноним (12), 12-Ноя-18, 09:45
Ну вот вижу, чего реально не хватает TCP из всего, что в квике предлагается. Конкретно не хватает multistream, возможности одновременно трансмитить несколько потоков так, чтобы потеря пакета не приводила к останову трансмита всех потоков. 0-RTT в баню, как минимум трёхзвенка должна быть. Всё остальное реализуется и поверх TCP прекрасно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	73. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+3 +/–
	Сообщение от Аноним (72), 12-Ноя-18, 13:25
	Вы только что переизобрели sctp.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	163. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:13
	Если из SCTP выкинуть всё, кроме TCP-лайк и мультистриминга - то да. Иначе опять академический оверблоатед оверинжениред шит, который юзать себе дороже.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	192. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Zulu (?), 13-Ноя-18, 15:55
	Трехзвенка очень медленна. Все хотят browser apps as responsive as local apps, так что доли секунд задержки мешают.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	197. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Торговец людьми (?), 13-Ноя-18, 16:35
	Кто заставляет устанавливать соединение на каждый чих?
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	266. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 11-Дек-18, 23:18
	> Кто заставляет устанавливать соединение на каждый чих? TCP/IP бонусом хреново относится к большим задержкам и выпадениям пакетов. Это заставляет чертыхаться юзеров беспроводки.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	205. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 20:50
	Если мы имеем субстримы - трёхзвенка выполняется один раз наовердочихуахуа стримов.
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

22. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
Сообщение от Аноним (22), 12-Ноя-18, 09:54
А http там какой предполагается будет? Текстовый - теплый ламповый или уже бинарный как в http/2?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	75. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+4 +/–
	Сообщение от Аноним (72), 12-Ноя-18, 13:27
	Разумеется бинарный, с минимумом отладочной информации и к тому же зашифрованный.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

26. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
Сообщение от Аноним (12), 12-Ноя-18, 10:06
Самые интересные графики в разделе ""прирост" производительности" находятся в разделе 4.5, на странице 40. Там показан QUIC в условиях конкуренции с TCP на искуственно задерьмовленом канале связи, при микс-тесте до гугл драйва, а не при сферическом одном-двух условиях в вакууме. Если кратко, то это счастье ещё дорабатывать и дорабатывать - TCP оно при таких показателях не альтернатива вообще.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–2 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 10:52
	мир уходит на радиоканалы, где процентов 20 потеоь - запросто, причём каналы эти со своими свойствами ещё и меняются. Суть как раз в том, чтобы это на поганом канале работало, причём без явно заметных пользователю тормозов. В этом плане хорошо уже то, что оно не tcp и его обновление не прибито к апдейтам оси и прошивок провайдерских маршрутизаторов, из-за чего buffer bloat тот же победить не могут.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	58. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от anonymous (??), 12-Ноя-18, 12:30
	Это где такой дepьмовый мир ?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 12:43
	Сюрприз - везде. И то, что интернет стал доступен постоянно и отовсюду я бы дерьмовым не назвал.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	97. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от пох (?), 12-Ноя-18, 15:12
	"везде" за 20% потерь вешают на той же осине, к которой ты ниточками прикрутил свой "радиоканал".
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	109. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 16:13
	Когда я прихожу в кафе (и не важно, их вайфай хреновый или они в подвале, экранирующем 3G) меня как клиента абсолютно не интересует, кого и где надо вешать. Ровно то же самое  - в быстро движущемся автомобиле, в толпе, где сота не справляется и так далее, и тому подобное. Поэтому надо не вы...ться, а уметь вменяемо работать на каналах с непредсказуемо меняющимися потерями.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	118. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–5 +/–
	Сообщение от пох (?), 12-Ноя-18, 17:15
	просто подключись к точке в соседнем кафе, если эта тормозит. А, ты в РФ? А-а-а... ну так тут еще и паспорт спросят... в лучшем случае. > Ровно то же самое  - в быстро движущемся автомобиле, в толпе, где сота не справляется если "не справляется" полоса базовой станции - не хотелось бы тебя огорчать, но будет примерно как с mtp. То есть и у тебя работать не будет нихрена, и еще и другим пользователям ты будешь мешать. А был бы нормальный tcp - в нем есть нормальные технологии, позволяющие делить канал, пока в принципе есть что делить. И да, надо не вы...ся, и не думать что ты умнее инженеров, построивших ту сеть, которой мы все пользуемся сейчас. А то может внезапно оказаться очень неудобно. Впрочем, опять же, это не к гуглю, если ему станет неудобно - сети просто переделают так чтоб ему было удобно. А никакого другого http (а в будущем и никакого другого интернета) у вас не будет.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	125. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 17:53
	Я, в РФ? Смеётесь, что ли? Чего ради у всех будет валиться? Ничего не мешает реализовать любую алгоритмику,  включая ту, что есть в TCP. Но скорее будет нечно более подходящее - все получат неполные куски и будут пытаться что-то с этим делать (отправка нас интересует в десятую очередь - мобильные устройства - это о потреблении контента). И с шансами сможет сделать хоть что-то. Если не совсем тупа реализация - будут просить ретрансмит не на каждый пакет, использовать то, что получили и так далее. Да блин, даже просто возможность отдать веб-приложению сообщение "у нас потери пакетов, реагируй" дорогого стоит. В общем, я не спорю, что оно костыльно (как любой монолит, который на иерархию уровней клал), но ровно по тем же причинам и плюсы свои имеет. В TCP  я не получу пакет пока не придут предшествующие ему, со всеми ретрансмитами. При мультиплексировании загрузки кучи ресурсов в одно соединение - не самая лучшая идея. При TCP  я не смогу использовать восстановление в видео, которое нынче по HTTP летит. А в кастомном протоколе - запросто. Что до инженеров... фишка-то в именно в том, что TCP проектировался для одних условий, а используется совсем в других. Борьба с buffer bloat - это, конечно, часть попыток это дело поправить, но, как ни крути, один протокол на уровне операционки как-то хреновато подгоняется под конкретные задачи, и апдейтить реализации несподручно. А тут - новый хром прилетает с любой нужной частотой, и дело в шляпе.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	130. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (127), 12-Ноя-18, 18:20
	> В TCP  я не получу пакет пока не придут предшествующие ему, со всеми ретрансмитами. В этом случае претензии надо предъявлять не протоколу TCP, а тем, кто слишком вольно обращается с TCP window.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	131. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от пох (?), 12-Ноя-18, 18:21
	> Что до инженеров... фишка-то в именно в том, что TCP проектировался для одних условий, а > используется совсем в других. так он - работает, по сей день. В этом вот самом миллионе разных задач. Потому что вообще-то хорошие инженеры были. > тут - новый хром прилетает с любой нужной частотой, и дело в шляпе. Ну да, так и будет - один браузер, один сайт (домены первое время будут разные, но это будет один и тот же гугль. О том, собственно, и речь.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	139. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (139), 12-Ноя-18, 20:02
	это да. у меня даже на локалхосте мои поделки через tcp общаются, и при желании на разные хосты разнести можно. зачемательная штука. в гулаге бы ничегоо такого в жизни не придумали :)
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	245. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (245), 19-Ноя-18, 18:38
	> просто подключись к точке в соседнем кафе, если эта тормозит. > А, ты в РФ? А-а-а... ну так тут еще и паспорт спросят... > в лучшем случае. А что, пох что-то придумал с тем чтобы радиоволны всегда заполняли пространство равномерно, без минимумов и даже не было всяких замираний при движении, multi-path с деструктивной интерференцией и проч? Дайте ему тогда нобелевку, без вариантов. Нет, если это требует при сдвиге на 3 сантиметра на другую точку прыгать - ему тогда ИГнобелевку, измеряемую в единицах пропорциональных 3.14.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	162. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:09
	При 10% потерь уже и TCP не работает. От слова совсем. Квику же будет совсем хреново.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	244. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (245), 19-Ноя-18, 18:35
	> При 10% потерь уже и TCP не работает. От слова совсем. Если планировщик поменять, на какой-нибудь CDG, BBR и т.п. - он и при 30% кое-как живет. Но да, кое-как - и это рецепт ну совсем не для юзеров винды. В линухе попытались изобразить хоть какое-то подобие планировщиков дружественных к беспроводным соединениям - и это лучше чем то что было до них. > Квику же будет совсем хреново. Квику будет просто похрен, он просядет на 10-20%, если нормально сделать. А гугл может себе это позволить даже.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	79. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (79), 12-Ноя-18, 13:54
	за мкадом
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	84. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+6 +/–
	Сообщение от Аноним (84), 12-Ноя-18, 14:24
	> за мкадом Байки. За мкадом качество радиоканалов не играет особой роли, потому что никак не влияет на почтовых голубей и дымовые сигналы.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	243. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (245), 19-Ноя-18, 18:32
	> Это где такой дepьмовый мир ? Это вокруг нас - там где беспроводной интернет. Радиоволны, видите ли капризнаая штука, подверженная куче интересных проблем. Поэтому линк априори нестабилен. TCP же профукав несколько пакетов или словив таймаут думает что сеть перегружена и начинает скорость душить. С понятным результатом - линк на раз дохнет до скорости диалапа. Хотя это было какое-нибудь кратковременное замирание сигнала на самом деле, например. Длина волны допустим вайфая 2.4ГГц - около 13 сантиметров. Подвинув девайс на четверть дистанции (жалкие 3 с копейками см) можно радикально изменить условия, попав из максимума волны в минимум, где излучения вообще нет. И, конечно же, связь при этом может и не умрет совсем (поймать минимум настолько идеально еще уметь надо) но определенные проблемы с застреванием данных начнутся. А когда юзер немного шелохнется, они так же резко и внезапно пропадут. Но до TCP это будет доходить следующие добрых полчаса. За которые у юзера кончится буфер видео и он увидит знакомую картинку...
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	144. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:39
	Суть графика в том, что на реальном канале плюс имитированные 2% потерь и большой RTT TCP передавливает QUIC только в путь, а тот вообще не трепыхается. Такие дела.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

31. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Ivan_83 (ok), 12-Ноя-18, 10:36
Сомнительно чтобы в квик получилось разработать алгоритмы контроля перегрузки лучше чем в тцп. Хождение поверх юдп - огромный костыль.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+4 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 10:57
	проблема в том, что для тсп новые алгоритмы (которые есть, и лучше подходят для нынешних сетей) надо засунуть в ось и во все железки на пути. Поэтому и поверх UDP - чтобы нижние уровни не трогать, а сделать всё в приложении. Костыль, но иначе внедрять надо будет годами, как тот же ipv6. А тут - ждать никого не надо.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	46. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (46), 12-Ноя-18, 11:34
	> и во все железки на пути Это еще зачем? Контроль перегрузок и сетевой планировщик (вы там выше писали про buffer bloat) - это не одно и то же.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	63. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 12:47
	проблемы были и там и там, насколько я помню
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	59. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Pofigist (?), 12-Ноя-18, 12:30
	Если верить https://ru.wikipedia.org/wiki/Список_протоколов,_инкапсулируемых_в_IP то номера с 143-го по 252й свободны. Бери и используй, а не городи костыли over UDP.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	62. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 12:45
	и тебя порежет первый же параноик, рубящий неизвестные протоколы
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	134. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (127), 12-Ноя-18, 18:24
	А тебе жалко, что некоторое число одминов-параноиков окажется на бирже труда?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	224. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от нах (?), 15-Ноя-18, 14:37
	если бы их за это увольняли... а то ж даже темную устраивают редко.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	258. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 01-Дек-18, 16:14
	> А тебе жалко, что некоторое число одминов-параноиков окажется на бирже труда? А как тебе идея что первым окажется твой домашний роутер, грохнувший неизвестный на момент его выпуска протокол? И так у еще 90% хомяков, например. Вот гугл подумал и решил что протокол который не будет работать в большинстве типовых конфигураций им не надо. SCTP уже есть один такой, нафига нам еще одну такую неведому зверушку?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	74. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (71), 12-Ноя-18, 13:26
	И ты не пролезешь через первый же NAT. За NAT'ом существуют только TCP и UDP.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	107. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Ivan_83 (ok), 12-Ноя-18, 16:00
	Нет, это по другому работает. gre через нат ходит, но если нат не имеет хелпера/не знает его то только один юзер сможет подключится к одному целевому серверу, ибо нат не в состоянии различить кому нужно переслать ответ. С другой стороны у нас IPv6 уже почти настал, там такой проблемы нет.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	124. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (71), 12-Ноя-18, 17:52
	Ну это только в хороших линуксах NAT пытается пропустить через себя протоколы, для которых нет хелпера. А в железяках этой логики нет, и хелперы просто не существуют, так как производитель поленился их собрать или реализовать в своем ASIC'е.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	135. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–4 +/–
	Сообщение от пох (?), 12-Ноя-18, 18:29
	наоборот, только в бестолковом линуксе лезут внутрь протокола, не умея толком его разобрать (посмотрите в исходники conntrack_gre и ужаснитесь) в железяках эта логика есть, потому что она, на самом деле, _ничем_ не отличается от той же логики для tcp - тоже надо поменять некоторые байты где-то в начале пакета и сохранить соответствие исходные-поменяные. И большинство железяк вполне способны (как и линукс без убогого хелпера) пропустить через себя gre. Но ровно один на пару внешний адрес - свой адрес (своих может быть далеко не один, поэтому в определенных пределах эта схема даже позволяет нескольким юзерам работать с одним и тем же протоколом отличным от единственно-верных). Многие при этом - умеют и правильно натить правильно приготовленный gre, равно как esp и многие другие протоколы, потому что их производители, внезапно, значительно меньшие идиоты чем линуксовые мартышки. а никакой сверхзадачи добавить подобную фичу, если ты уже добавил _точно_такую_же_ для tcp - нет в природе. summer student вполне осилит. Если правильно замотивировать.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	148. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:45
	QUIC NAT-agnostic, прекрасно пролезет. Даже без мыла.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	149. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:46
	А, я просмотрел, что это о кастомном IP-протоколе, звиняйте. С кастомным номером протокола - не пролезет.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	248. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 18:49
	> то номера с 143-го по 252й свободны. Бери и используй, а > не городи костыли over UDP. После чего 1) Потребуется замена большей части домашних (и не только) роутеров и натов. 2) Умник пойдет убеждать MS это заимплементить. 3) А потом еще и доказывать юзерам что они должны завтра купить новую винду и большинство мобильных устройств. Иначе эфекта будет мало и улучшений не наступит.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	106. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Ivan_83 (ok), 12-Ноя-18, 15:57
	Так если нет в ОС значит отцы не допустили, а раз не допустили значит ненужное.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	132. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от имя (?), 12-Ноя-18, 18:22
	ах, этот сладкий запах костылей...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	145. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:40
	Ничего в железо по пути засовывать не надо, если оно функционирует ниже L4 конечно. Контроль перегрузки - end-to-end, ну и немножко ECN, который один ксер почти никто не умеет.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

32. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–2 +/–
Сообщение от vitalif (ok), 12-Ноя-18, 10:41
Я что-то не пойму, а спиди все? Уже закопали? Как с социальными сетями у гугла что ли будет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+6 +/–
	Сообщение от nobody (??), 12-Ноя-18, 10:56
	SPDY уже стал HTTP/2
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	52. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–5 +/–
	Сообщение от vitalif (ok), 12-Ноя-18, 11:54
	Понятно что стал, но его-то ещё внедрить не внедрили массово, а тут уже кролик квики какой-то
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	133. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от имя (?), 12-Ноя-18, 18:23
	с чего бы это? https://w3techs.com/technologies/details/ce-http2/all/all
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	42. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–4 +/–
	Сообщение от Pofigist (?), 12-Ноя-18, 11:05
	Спиди закопали еще года 3 тому назад - в пользу HTTP/2
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	48. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+5 +/–
	Сообщение от Аноним (49), 12-Ноя-18, 11:37
	HTTP/2 и есть SPDY последней редакции. С добрым утром.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	55. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Pofigist (?), 12-Ноя-18, 12:19
	Не совсем - курите доки.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

39. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Аноним (39), 12-Ноя-18, 10:58
Видеотрансляции, например iptv edemtv, сейчас приходится организовывать через http CDN, которые tcp. UPD CDN нет. QUIC улучшить ситуацию со стабильностью вещания?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	82. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от твой лучший друг (?), 12-Ноя-18, 14:17
	как бы да. якобы не подвержен проблеме быстрых каналов с большим пингом.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	193. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Zulu (?), 13-Ноя-18, 15:57
	akamai. И да, QUIC среди прочего нацелен на стриминг.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

53. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–8 +/–
Сообщение от Spoofing (?), 12-Ноя-18, 12:01
чота всё ускоряют, оптимизируют, а firefox начиная с 50+ версии стало мало 2гб оперативы и чем дальше тем хуже.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+5 +/–
	Сообщение от хрю (?), 12-Ноя-18, 12:15
	>чота всё ускоряют, оптимизируют, а firefox начиная с 50+ версии стало мало 2гб оперативы и чем дальше тем хуже. Так для того и оптимизируют, что можно было ещё больше фуфла засунуть.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	152. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (152), 12-Ноя-18, 21:15
	В смысле 2? Мне 8 не хватает
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	226. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Олег (??), 17-Ноя-18, 16:21
	>чота всё ускоряют, оптимизируют, а firefox начиная с 50+ версии стало мало 2гб оперативы и чем дальше тем хуже. Блин, я думал это только у меня такая фигня :-). Ваще, вэб идёт куда-то не туда. Когда-то браузер был приложением запущенным в дополнение к остальному, теперь это фигня требует к себе особого внимания, кучу оперативы, хороший проц и видюху уже несилует. Что за...
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

57. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–5 +/–
Сообщение от Gemorroj (ok), 12-Ноя-18, 12:27
жесть какая-то. оно гарантирует доставку? оно корректирует пакеты в очереди? судя по тому что оно поверх udp - нет? и оно имеет такое же ограниченное применение как и udp?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+3 +/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 12:49
	гарантирует и корректирует - когда надо и самостоятельно
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	67. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (67), 12-Ноя-18, 13:02
	Ты погоди, не пройдёт и 10 лет, как выяснится, что µTP тоже был пилотным проектом гугля.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	153. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–2 +/–
	Сообщение от Аноним (152), 12-Ноя-18, 21:17
	Вот и набежало людей, которые нифига не зная как работают сетевые приложения, суют своё авторитетное мнение
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	217. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от FSA (??), 14-Ноя-18, 23:39
	> судя по тому что оно поверх udp - нет? Никто не запрещает слать пакеты по UDP и контролировать их доставку самостоятельно. Если ты используешь TCP, то нет смысла с этим заморачиваться, но платой за это является, например, необходимость ожидать установки соединения. У меня вот другой вопрос. А как это хозяйство будет взаимодействовать с NAT? Провайдеры не торопятся давать полноценный IPv6, а закон о блокировках просто убьёт маршрутизаторы провайдеров на гигантские таблицы блокировок. Так что NAT - суровая реальность от которой не уйти. А там нужно как-то согласовывать доставку ответных UDP пакетов клиенту.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

68. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Аноним (49), 12-Ноя-18, 13:08
> нет, не буду спешить, подожду HTTP/3 © arisu (ok), 22:54, 09/02/2015 https://www.opennet.me/openforum/vsluhforumID3/101446.html#3
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

78. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–2 +/–
Сообщение от EuPhobos (ok), 12-Ноя-18, 13:47
> Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%. Отлично, кто-то в локалке врубит YouTube-чик, а у кого то из-за этого начнёт заикаться SIP телефония. Что за де6илы.. Были такие умники, которые решили torrent-ы по UDP гонять, ничем хорошим не кончилось. Каждый протокол создан под свою конкретную работу, а тут делают костыльный велосипед с треугольными колёсами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	87. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+5 +/–
	Сообщение от Аноним84701 (ok), 12-Ноя-18, 14:31
	> Отлично, кто-то в локалке врубит YouTube-чик, а у кого то из-за этого начнёт заикаться SIP телефония. Так гуглу  от чужой SIP телефонии ни жарко, ни холодно. В отличие от шустрости собственного, монетизируемого сервиса.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	111. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Crazy Alex (ok), 12-Ноя-18, 16:14
	давно оно на том же порту бегает? нет? Ну тогда можно разделить и QoS в помощь
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	179. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (179), 13-Ноя-18, 09:30
	А что там с КОСом для удп на аппаратном уровне железок?
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	117. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Anon772 (?), 12-Ноя-18, 16:56
	Вы понимаете  в чем была проблема с торрентами + UDP ? Проблема была у говнопровайдеров с софт роутерами. Там от пакет рейта - цпу улетало в небеса и начинались лаги. У нормальных провайдеров с железными брасами это все было вообще похер - ASIC нормальных BRASов молотили аппаратно свои миллионы пакетов в секунду и в ус не дули.... Тоже самое и с домашними роутерами... Так что не нужно мешать все в кучу. Реально пока проблема с UDP только в DDOS, и подменой адреса источника и последующая амплификация (потому что до сих пор многие говнопровайдеры не проверяют на доступе src адреса, с которых посылают в мир трафик от своих хомяков, хотя, казалось бы - пару строчек конфига ACL - разрешать только свои сетки или типа ip source validation...
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	119. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от пох (?), 12-Ноя-18, 17:16
	> Вы понимаете  в чем была проблема с торрентами + UDP ? мы - понимаем, вы - явно нет. Читали в газетке комсомольская правда.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	120. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Anon772 (?), 12-Ноя-18, 17:20
	Просветите, нас, господин хороший...
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	166. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:24
	Я так это, на минуточку секрет открою: большинство априори железных свитчей на деле далеко не line rate. Большим pps их можно забить только в путь. А уж если где-то асимметричный свитчинг, то при плотном потоке, не умеющем себя попиливать, и вообще прелесть. UtP с тех пора слегка поддоработали.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	167. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:27
	3850 - распи(*)арен, только в путь. Нон-блокинг, 480 гбит, все дела. С пары десяток в гиги без всяких флоу контролов аутпут дропы только в путь, приходится очереди выкручивать, но и это не особо помогает. Буфер мелковат.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	168. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:28
	Причём аутпут дропы не там, куда больше гига слиться попыталось, а рандомно пачками по всем интерфейсам при просадке буферов одного из. Вот вам и "нон-блокинг".
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	187. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от нах (?), 13-Ноя-18, 14:33
	> Большим pps их можно забить только в путь. там не в больших pps (не в одних только pps) была реальная проблема. (а от большого у клиента его собственная мыльница лопается первой) проблема была в том, что если у тебя на самом деле плохой канал - забитый выше "оптимальных" 75% или с потерями - эта хрень и другим работать не давала, и самой себе мешала - потому что не имела понятия о том, как это делать грамотно (в смысле, ее авторы - решившие осчастливить мир, нифига не разбираясь в технологии), в результате только усугубляя проблему (выключаешь такому дурачку эту глупость - и у него,ну надо же, рейт поднялся, и другим полегчало). > UtP с тех пора слегка поддоработали. это потому что провайдеры _массово_ начали паттерн-матчингом (вот это - действительно на cpu делается, и ничего - справлялись ;-) ронять его на пол, с prob 90% ("а чо, оно ж декларировано что подстраивается под потери - вот и пусть подстроится"). А первое время гордые авторы никого слушать не хотели, и гордо кукарекали что у них все правильно, это у вас каналы неправильные и вы ничего настраивать не умеете. когда их софтину начали массово заменять древними версиями или аналогами без вредной технологии (потому что пользователь своими глазами видел, что стало хуже, а не лучше) - им все же пришлось слушать умных людей. От гугля - не надейтесь. Его и на пол ронять не будут, и слушать гугль никого не умеет, надежно изолировавшись от внешнего мира.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	206. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 20:52
	Yes. Именно потому, что его блочить начали - они заливали как унылые софтбрасы, так и просто свитчи :( А когда заливается фабрика свитча - грабли имеют все на нём и даже за ним (если кольцо).
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	207. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 13-Ноя-18, 20:54
	Ну и нет - если квик будет в сети хамить, то и дропать придётся. Потому что терять полтора хомячка с "умяня квика нет срочносделайте" проще, чем корпората, которому этот квик до фонаря.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	225. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от пох (?), 15-Ноя-18, 14:44
	он дропнется только вместе с юзерами. Нет, корпорату не до фонаря - ему тоже надо гугледоксы и даже, представь себе, ютупчик - по другому он до своих дорогих клиентов не достучится, будь он хоть циской, хоть ibm :-( это с торрентами прокатывало "никто ж не пожалуется" (поскольку пожаловаться - признать что ты любитель вареза, а то и чего погорячее).
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	227. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Олег (??), 17-Ноя-18, 16:27
	>У нормальных провайдеров с железными брасами это все было вообще похер - ASIC нормальных BRASов молотили аппаратно свои миллионы пакетов в секунду и в ус не дули.... Что за бред ты несёшь? ASIC божественен что ли и у него нет естественных ограничений его возможностей? Какая нафиг разница проц или asic, если приходит больше пакетов, чем может переварить железка по своим параметрам? Плюс, проблема не в этом была, а, как написали, в том, что нет у udp congestion control.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	267. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (267), 11-Дек-18, 23:22
	> Какая нафиг разница проц или asic, если приходит больше пакетов, чем может > переварить железка по своим параметрам? Для ASIC считается хорошим тоном работать с wire speed. Даже мелкими пакетами. Иначе зачем за него вообще платить? С ограничениями по параметрам и CPU может, он ширпотребнее а потому при прочих равных дешевле. А смысл ASIC - в том что он эффективен в своей задаче. Ценой узкой специализации.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	161. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:06
	Для этого есть QoS и ToS. Свой VoIP в приоритет, DNS и NTP чуть пониже с рейтлимитом, ну ещё там пару протоколов, а всё остальное в бест-эффорт, если не в полисинг. И пусть ***ца как хочет.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	259. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 01-Дек-18, 16:18
	> Отлично, кто-то в локалке врубит YouTube-чик, а у кого то из-за этого > начнёт заикаться SIP телефония. Если ты хотел делать приоретизацию трафика на основе одного только факта что это udp - ты делал что-то крепко не так. > Были такие умники, которые решили torrent-ы по UDP гонять, ничем хорошим не кончилось. Да вообще-то юзерам стало довольно хорошо. А всяким козлам с недороутерами на фряхе конечно начальство дало по чайнику и правильно сделало. А кто не сделал - будет у такого прова меньше юзерей, делов то. Ничего личного, это бизнес.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

88. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Аноним (88), 12-Ноя-18, 14:41
200-300мс это я так понял на 2/3G сетях, а  на 4G там уже наверно 30-70мс, А вообще посмотрел лису и хром, в хроме оно быстрее. (Но там 15-30мс) а вот 200-300мс на мобиле вполне себе заметны
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	262. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от ползкрокодил (?), 01-Дек-18, 21:18
	На GPRS/EDGE аж несколько секунд, ибо один раунд занимает полсекунды-секунду. Ходить на HTTPS-сайты из полноценного браузера (не Opera Mini какой-нибудь) — боль. Одна только инициализация соединения несколько секунд, и не всегда срабатывает, а ещё чтобы скачать все ресурсы (браузеры-то не качалки, в докачку не умеют, если что-то оборвётся при подгрузке всех десятков link/script/img/video/etc), да причём успешно — в запущенных случаях надо не один час, если вообще получится загрузить, ибо макаки вхардкоживают таймауты. Несколько часов для одной страницы!
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

89. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
Сообщение от Alex (??), 12-Ноя-18, 14:52
>по сути QUIC предоставляет возможность использования TLS поверх UDP Я глупый думал что это называется DTLS и от QUIС никак не зависит
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	146. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:42
	Неа. DTLS - это стандарт де-факто, который к сожалению очень херово справляется с потерями. А квик - он квик и есть.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

90. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–6 +/–
Сообщение от Онаним (?), 12-Ноя-18, 14:55
> Выбор имени для HTTP-over-QUIC вызвал большую дискуссию. Вначале рассматривалась возможность использования для стандартизации связки HTTP-over-QUIC имён HQ, QUIC/2, HTTP/QUIC и HTTP/2-encrypted-over-UDP, но в конце концов разработчики согласились с предложением использовать имя HTTP/3, которое позволит сохранить привычную семантику. Зачем вообще там этот слэш дурацкий? Почему HTTP/2 и HTTP/3, а не HTTP 2 и HTTP 3 просто? Почему вот это не вызывает дискуссий? Такое ощущение, что эти названия придумывают маркетологи для юзеров (будто их касается какой там протокол), а не инженеры для программистов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	92. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+3 +/–
	Сообщение от Stax (ok), 12-Ноя-18, 15:03
	Все претензии к инженерам, которые изобрели HTTP/0.9 и HTTP/1.0, не? А они изначально решили разделять тег и версию через слэш. Тк пробел это разделитель тэгов. Примеры из RFC 1996 года:        User-Agent: CERN-LineMode/2.15 libwww/2.17b3        Server: Apache/0.8.4 Хотя собственно версии через слэш появились до RFC, еще в стандарте 1992 года: https://www.w3.org/Protocols/HTTP/Request.html
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	156. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (152), 12-Ноя-18, 21:23
	Зачем вообще эти комментаторы, которым всё равно ни жарко, ни холодно от этого
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

136. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
Сообщение от Аноним (127), 12-Ноя-18, 18:31
И всё это гугл городит ради своего драного ютуба.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	138. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Stax (ok), 12-Ноя-18, 18:52
	Вроде показывали статистику, по которой "драный ютуб" это что-то типа 80% глобального интернет-трафика, не?
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	147. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 20:43
	Есть мысль, что если выпилить ютюб из интернетов, можно здорово на роутерах сэкономить.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	154. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (152), 12-Ноя-18, 21:21
	Есть мысль, что вы не понимаете, как работает интернет и что роутер нужен для всего трафика. Выпиливайтесь на здоровье
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	158. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (158), 12-Ноя-18, 22:48
	т.е. если глобализация и централизованный масс-хостинг общего назначения - то и гавкнуть на него из глубины будки нельзя? нюансов хватает
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	160. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 12-Ноя-18, 23:04
	Есть мысль, что если выпилить столько (бессмысленного) трафика, роутерам полегчает с запасом лет так на 10-15.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	190. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Stax (ok), 13-Ноя-18, 15:14
	Любопытства ради, сколько вы в жизни видели роутеров (любые примеры подойдут - домашние, корпоративные, провайдерские, магистральные), которым было тяжело обрабатывать трафик? Именно чтобы сам роутер "напрягался" форвардить пакетики (в плане процессора или еще там чего), а не каналы в любую сторону от этого роутера.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	199. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним другой (?), 13-Ноя-18, 17:18
	home и small business устройствам в user-friendly средах всегда плохело, не рассчитаны они на анлимит соединений с каждого узла (n-соединений хром, 2*n коннектов уторрент в обе стороны, скайп, всякие безумные и2п и прочая), а ведь еще полезную нагрузку нести, с админ-вахтером немного легчает - пакеты обрабатываются проще, очереди короче, в таких средах даже корпоративное устройство в 10 раз дороже в тяжелых условиях, это очевидно.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	200. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Stax (ok), 13-Ноя-18, 17:32
	> home и small business устройствам в user-friendly средах всегда плохело, не рассчитаны > они на анлимит соединений с каждого узла (n-соединений хром, 2*n коннектов > уторрент в обе стороны, скайп, всякие безумные и2п и прочая), а > ведь еще полезную нагрузку нести, с админ-вахтером немного легчает - пакеты > обрабатываются проще, очереди короче, в таких средах даже корпоративное устройство в > 10 раз дороже в тяжелых условиях, это очевидно. Ни разу не очевидно. Количество соединений, ВНЕЗАПНО, не связано с трафиком, и есть там ютуб или нет - никак не влияет на нагрузку на таблицу NAT, к примеру. Убрав ютуб, можно убрать большой процент трафика из интернета, а вот общее количество соединений изменится минимально.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	202. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним другой (?), 13-Ноя-18, 18:08
	согласен, не претендую (но переключать контекст threads/events processing с полезного на бесполезное бессмысленно), поскольку с текстом люди работать разучились, то без ютуб они уже не настроят ни онлайн-игры, ни виртуальные сети, ни увидят захватывающие трейлеры и т.д., но это конечно слишком мягкий контекст-анализ, без вздергивания 16+ и прочих бесполезных узлов.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	219. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (12), 15-Ноя-18, 01:27
	Ты не понял саму суть исходного посыла: если мы апгрейдим канал с 40г до 100г допустим - нам минимум придётся поменять линейную плату. Минимум. Если этих 100г портов окажется больше 4 - придётся ещё и RSP поменять с 880 на что-то повыше. А если плотные карты с кучей 100г - то ещё и SFC добавить придётся. А в маленькое 10U шасси много SFC с линейками не поставишь - придётся и шасси поменять. Такие апгрейды роутеров - это охеренные деньги. И что такое "канал" для тебя? Для меня это оптика или оптический бандл, в который можно запихнуть и 10, и 40, и 100, а возможно и больше, в зависимости от типа модуля в роутере. --- Что же до "загибающегося оборудования" - да тоже сколько угодно. Возьми старенький клиентский 1841, дай клиенту медяху на 100 мбит - лично узреешь. Из больших - ASR1000 бывает весь вдоль и поперёк оверсабскрайбленный только в путь. Из дерьма - загибающихся софтовых 7200 - по горло видел в своё время. Свитчи, загибающиеся из-за маленьких буферов - постоянно вижу.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	195. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (39), 13-Ноя-18, 16:05
	Не только. На нестабильном соединении, в том числе даже без потерь пакетов, а только постоянно меняющейся пропускной способности, TCP ведет себя очень плохо. Считайте QUIC позволит выжимать максимум из любых каналов.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	220. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (12), 15-Ноя-18, 01:32
	На последних графиках документа видно, что на нестабильном соединении по сравнению с TCP квики фирменно отсасывает. Так что то, что рекламный посыл принят - понятно, но матчасть посмотреть надо было.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	260. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (-), 01-Дек-18, 16:20
	> На последних графиках документа видно, что на нестабильном соединении по сравнению с > TCP квики фирменно отсасывает. Так что то, что рекламный посыл принят > - понятно, но матчасть посмотреть надо было. Логику quic можно тюнить, в том числе и со стороны приложения. А с TCP в этом плане болт, особенно - в винде. И если в лине гугл еще сделал свой BBR на такие случаи, то вот юзерам виндов с этого ничего не перепадает...
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

151. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
Сообщение от Аноним (151), 12-Ноя-18, 21:07
Очередное ненужно из-за которого все браузеры выпущенные до часа Ч превратятся в тыкву?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	155. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (152), 12-Ноя-18, 21:22
	Как там IE6? Netscape navigator? Arachne? doslynx?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	159. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (158), 12-Ноя-18, 22:55
	отличные браузеры, хранители скреп, в пижонском links-win32 даже скроллинг юникода лагает
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	218. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от FSA (??), 14-Ноя-18, 23:43
	С IE6 всё плохо. Недавно надо было старую софтину запустить. Поставил Windows XP на виртуалке и не смог утилитой для скачивания браузера IE6 скачать ни Chrome, ни Firefox, ни даже Opera. Соединение просто обрывается.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	157. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–3 +/–
	Сообщение от Аноним (157), 12-Ноя-18, 22:17
	Вот уже хотя бы ради превращения в тыкву неподдерживаемого старья оно и нужно.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	184. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+2 +/–
	Сообщение от Аноним (72), 13-Ноя-18, 13:01
	Ты уже скопил ежегодеую тущу баксов на обновление до последнего ойфона, или как лоx с предпоследним ходишь?
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	169. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (169), 12-Ноя-18, 23:49
	Это как не нужное, очень даже нужное чтобы заставить покупать заново электронный хлам.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	170. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–2 +/–
	Сообщение от Аноним (158), 13-Ноя-18, 00:33
	оборудование из soho перейдёт в нижние эшелоны, вчера кто-то выкинул элт из окна высотки, кто-то без связи выкручивается, не слышал жалоб что кого-то принуждают менять социальный статус, даже совместимость встречается
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

174. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от Аноним (174), 13-Ноя-18, 04:40
На кой хрен нам ускорение на 0.5мс, если gmail "весит" больше 4мб, делает 181 запросов и отрисовывается за 20+ секунд?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	175. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (174), 13-Ноя-18, 04:41
	И да, установка ublock и подобных дает самый большой прирост в загрузке веб-страниц, никакие твики протокола никогда с ним не сравнятся.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	177. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (158), 13-Ноя-18, 09:04
	на client-side 0,5мс не имеет значения, а остальные в содержимое страницы не лезут
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	182. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (39), 13-Ноя-18, 12:54
	Это проблема HTML. Можно было бы использовать решения, которые компилируется в единое промежуточное представление (байткод), например QML, но тогда сразу найдутся пользователи, которые хотят видеть исходники.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	251. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Аноним (251), 21-Ноя-18, 02:11
	Gmail нужна поддержка IE6. А тебе нет, вот и мучайся. Пока есть статистика с большим процентом IE6 его поддержку будут полифилом тащить.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	263. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от ползкрокодил (?), 01-Дек-18, 21:23
	Зато ukr.net, сволочи, взяли и выкинули поддержку Opera Mini, у которая аж пару процентов рынка. И принудительный SSL для SMTP ввели, что с телефона со старыми сертификатами уже почту не поотправлять с сохранением в их исходящих. Пришлось Roundcube ставить. А у гугла тем временем даже ютуб в 3GP по RTSP работает до сих пор.
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	268. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+1 +/–
	Сообщение от Аноним (267), 11-Дек-18, 23:24
	> Зато ukr.net, сволочи, взяли и выкинули поддержку Opera Mini, у которая аж > пару процентов рынка. И принудительный SSL для SMTP ввели, Видимо они таки устали от спама рассылаемого хакерами через спертые у всяких ламеров пароли.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	271. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от ползкрокодил (?), 26-Ноя-19, 21:27
	>> Зато ukr.net, сволочи, взяли и выкинули поддержку Opera Mini, у которая аж >> пару процентов рынка. И принудительный SSL для SMTP ввели, > Видимо они таки устали от спама рассылаемого хакерами через спертые у всяких > ламеров пароли. А хакеры-то тут при чём? Им и поныне ничто не мешает на SMTP-сервере авторизоваться по спёртым логину и паролю.
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

180. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+4 +/–
Сообщение от Аноним (180), 13-Ноя-18, 10:02
Очередные стандартизированные стандарты от Гугла? Спасибо, обойдёмся. Они там что-то накостылят тяп-ляп под свои нужны, а потом всем остальным навязывают... А то я вот на https://m.opennet.ru/ захожу и даже не знаю теперь а по стандарту ли это m. или нет... или вообще на помойку опеннету уже пора как безвозвратно устаревшему?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	181. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	–1 +/–
	Сообщение от Аноним (158), 13-Ноя-18, 10:28
	бигдата физический уровень не трогают и броузеры форкать не запрещают, это навязанные аллюзии про помойку, не надо вытеснять ее за рамки сознания, иначе вас вытеснит мусор
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	188. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от гугль (?), 13-Ноя-18, 14:39
	> Спасибо, обойдёмся. куда вы денетесь? Это ж новый стандарт, вся промышленность срочно перейдет на него. А если попадется страница в старом - сперва будем выводить большое-красное-окно-полное-неведомой-херни, без кнопки "продолжить". Потом, со временем - просто невменяемое сообщение что "с сайтом что-то не так, обратитесь к его владельцам". история с ненужно-https с ненужно-сертификатами из единственно-верного CA вас ничему, смотрим, не научила?
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	194. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
	Сообщение от Zulu (?), 13-Ноя-18, 16:01
	От IETF, на самом деле. Гугловская имплементация несколько отличается.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

269. "HTTP поверх протокола QUIC будет стандартизирован как HTTP/3..."	+/–
Сообщение от qsdg (ok), 03-Янв-19, 23:11
Слушайце, так если всё так просто, и возможно сделать за 0ms, то почему стазу никто до этого не догадался? Зачем было городить изначально весь этот ваш TCP и SSL с кучей roundtrip-ов поверх, если можно было и без этого?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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