Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, придал (http://www.ietf.org/mail-archive/web/ietf-announce/current/m...) спецификации HTTP/2.0 статус "Предложенного стандарта", а также приступил к формированию отдельных RFC для протокола HTTP/2.0 (https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/) и формата сжатия заголовков HPACK (https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-c.../). Работу над RFC планируется завершить через 6-8 недель.
Следующей стадией станет придание RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний. Следует отметить, что в настоящее время на стадии чернового стандарта находятся большинство протоколов сети, и лишь единицы после многих лет существования достигают наивысшего статуса - стандарт Интернета (статус стандарта получили (http://www.apps.ietf.org/rfc/stdlist.html) около 70 RFC).
Основной задачей создания HTTP/2.0 является повышение эффективности использования сетевых ресурсов и снижение задержек при соединении и обмене данными между клиентом и сервером, в условиях изменившихся современных реалий, при которых для загрузки сайта требуется отправить множество отдельных запросов, связанных с получением CSS, файлов JavaScript и картинок. Протокол HTTP/1.1, в силу конвейерной передачи данных и высоких накладных расходов на отдачу ресурсов небольшого размера, не может обеспечить должную эффективность и вынуждает устанавливать несколько одновременных TCP-соединений к серверу. В основу HTTP/2.0 положен протокол SPDY (http://www.opennet.me/opennews/art.shtml?num=33638), разработанный компанией Google и позволяющий ускорить загрузку сайтов на 15-50%.
Основные особенности (http://daniel.haxx.se/http2/) (PDF (https://github.com/vlet/http2-explained/blob/master/http2.ru...)) HTTP/2.0:
- Применение бинарного протокола передачи данных;
- Мультиплексирование и распараллеливание потоков в рамках одного TCP-соединения;
- Сжатие HTTP-заголовков;
- Приоритизация потоков;
- Средства для согласования расширений между клиентом и сервером;
- Поддержка технологии Server push;
URL: https://www.mnot.net/blog/2015/02/18/http2
Новость: http://www.opennet.me/opennews/art.shtml?num=41684
> единицы после многих лет существования достигают наивысшего статуса - стандарт ИнтернетаВ IETF сидят слоупоки, так и запишем.
"сидят" они у себя, а не в каком-то специальном здании IETF. Участвовать в обсуждении может любой, поэтому слоупоком Вы называете себя самого. Берите и предлагайте.
Занятно, из крупных веб серверов его поддерживает внезапно только IIS.
Вы сильно ошибаетесь. Если МС что-то назвал HTTP2 - это значит, что они сами придумали своё решение, просто название придумали. Так же как и окна, SQL сервер и т.п.
У тебя есть конкретная информация или диваноаналитикуешь?
Дочитать до конца статьи например
>> Серверные реализации пока ограничиваются OpenLiteSpeed, H2O, nghttp2 и некоторыми библиотеками
Бред, проверять сторонние источники - хорошая привычка.
так лучше? https://github.com/http2/http2-spec/wiki/Implementations
плюс в nginx, как я понимаю, можно через mod_spdy прикрутить
Тем более не в том положении MS со своим IIS, чтоб в сфере web серверов пропихивать свой уникальный протокол такого базисного уровня - их просто на три буквы пошлют.
А как же всем нужный и полезный ASP?
Ну ты сравнил тёплое с мокрым. HTTP - это базовая вещь, которая используется в том числе и в ASP
У тебя браузер не знает что такое ASP - ему до лампочки, хоть там микрософт какой-нибудь XY.NET придумает. А HTTP - это основа взаимодействия браузера.
http://blogs.msdn.com/b/ie/archive/2014/10/08/http-2-the-lon...> We’ve been working hard to help develop this new, efficient and compatible standard as part of the IETF HTTPbis Working Group.
Да, статьи на Опеннете тоже могут писать люди, которые не в теме.
> Why is Internet Explorer leading with HTTP/2 implementation?Этапять
> Да, статьи на Опеннете тоже могут писать люди, которые не в теме.Ещё люди незлопамятные, но хорошо помнящие предыдущие случаи, а потому не торопящиеся верить всему, что ляпнут на msdn -- в отличие от http://wiki.opennet.ru/MSSP
> http://wiki.opennet.ru/MSSPВыделенные ключевые слова, агрессивный стиль статьи... Это, батенька, пропаганда.
Это, батенька, майкрософт со своими обезьяно-клоунами давно надоел.
> Выделенные ключевые слова, агрессивный стиль статьи... Это, батенька, пропаганда.Это, дружок, противодействие сектантской пропаганде.
Агрессия была бы (и то уже ответная), если б было предложено отправлять таких "студентов-партнёров" на принудительные работы на свежем воздухе, а представительство некрософта приравнять к посольству штатов (и призывать бенгазировать). Что-то ничего подобного не наблюдаю.
> Это, дружок, противодействие сектантской пропаганде.А Вы, надо полагать, благородный рыцарь в сверкающих доспехах
Скажите, какую задачу Вы пытаетесь таким образом решить? Может, я Вас неправильно понял?
>> Это, дружок, противодействие сектантской пропаганде.
> А Вы, надо полагать, благородный рыцарь в сверкающих доспехахА я, надо полагать, не первый уж год заранее предупреждаю о различных ГРАБЛЯХ.
>> http://wiki.opennet.ru/MSSP
> Скажите, какую задачу Вы пытаетесь таким образом решить? Может, я Вас неправильно понял?Предупреждение посетителей о замеченной злонамеренной активности особого вида; я не знаю, как Вы меня поняли.
> А я, надо полагать, не первый уж год заранее предупреждаю о различных ГРАБЛЯХ.Странные у Вас предупреждения. В моём представлении предупреждение должно выгляжеть набором ссылок на всякого рода лажу со стороны MS, но никак не этим: http://wiki.opennet.ru/MSSP:
> у Шигорина как организатора и участника различных конференций есть подтверждения этому
https://psv4.vk.me/c538405/u42242102/docs/bd4af22bcefc/gde_p...
>> А я, надо полагать, не первый уж год заранее предупреждаю о различных ГРАБЛЯХ.
> В моём представленииВот и реализовывайте своё представление, представьте его на критику публики и пусть люди, которые тоже отличаются, посмотрят, что ценнее -- выводы из многолетних наблюдений, в т.ч. в глубоком офлайне, или "набор ссылок" (каковые бывают полезны, но что-то мне подсказывает, что с той самой статьёй на asymco тягаться не будете).
http://wiki.opennet.ru/?title=MicroSoft_Student_Partners&act...Молодец. Сам написал статью, и тут же приводишь её в доказательство своих же слов.
> Сам написал статью, и тут же приводишь её в доказательство своих же слов.Эта статья -- кэш того, что ранее вызревало в обсуждениях.
Я не настолько кнопколюбив, как User294, чтоб повторять _каждый_ раз в новых цветистых выражениях. И не настолько туп, чтобы считать возможным ссылаться на свои слова как на доказательство (если бы делал так -- уж всяко бы хватило ума писать статью от левого ника; другое дело, что такого не практикую, в отличие от некоторых из замеченных некростудентов).
А вот Вы как минимум наивны...
PS: особенно злоупотребляя доступом к сети на рабочем месте у нашего партнёра, да.
Почему - в доказательство? Это же просто макрос, чтобы не повторять одно и то же.
Ну пусть хоть в чём-то хорошем Микрософт будет первым.
Хотя, насколько я понял, другие серверы поддерживают SPDY, который с HTTP/2 настолько близкий родственник, что достаточно лишь модули переименовать:)
А когда это релиз серверной 10-ки был?
Внезапно, но у ноды тоже есть http2 модуль.
Слишком перегруженный протокол. Можно было проще.
Ну так предложи своё вИдение комитету IETF, сделай мир лучше
> например, когда сервер считает, что после определённого запроса обязательно будут затребованы другие данные, он может отправить эти данные не дожидаясь фактического запросаЗашёл на страницу дистрибутива, а тебе BD сразу закачивается, по 3g. Удобно ;-)
А реклама! Реклама-то! Сервер обязательно будет считать, что раз уж пользователь запросил страницу, то он без сомнения желает закачать себе тонны рекламы.
Ну так отбивать стоимость разработки новых стандартов чем-то надо. А если ставишь адблок - ты враг прогрессивного человечества.
> ...то он без сомнения желает закачать себе тонны рекламы.Причём с повышенным приоритетом! (раз эти приоритеты придуманы)
Ох, чую будет куча скандалов с этим 2.0 и его благополучно похерят в пользу намного более простого варианта.
что-то они там мутят, это точно
чего стоят хотя бы баталии насчет обязательного шифрования, главное, лоббируют эту идею больше всего представители от основных браузеров, им что, так тяжело шифрующую прослойку отключить?
Почитайте как работают Ad-block или uBlock
хотите сказать, что они сначала закачивают, а потом режут? или к чему ваш коммент?
99% рекламы - на отдельных доменах и обслуживаются отдельными серверами. Как резали её адблоки так и будут резать.
Рекламу обычно отдаёт что-то совсем другое - рекламная сеть, отдельная система и т.д. Чтобы она тянулась с того же сервераЭ что и основной контент - это, вообще-то, экзотика.
> Зашёл на страницу дистрибутива, а тебе BD сразу закачиваетсяЭто и сейчас есть. Сообщение со ссылкой на пример удалили.
1) A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
the number of responses that can be concurrently pushed by a server.
Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
server push by preventing the server from creating the necessary
streams. This does not prohibit a server from sending PUSH_PROMISE
frames; clients need to reset any promised streams that are not
wanted.2) If the client determines, for any reason, that it does not wish to
receive the pushed response from the server, or if the server takes
too long to begin sending the promised response, the client can send
an RST_STREAM frame, using either the CANCEL or REFUSED_STREAM codes,
and referencing the pushed stream's identifier.
> Применение бинарного протокола, оперирующего передачей бинарных кадров.т.е. можно без сериализации chr(0-32)
Короче, HTTP2 - очередная диверсия от копирастов, типа OOXML или UEFI, только в веб-сфере:
перегруженная и запутанная спецификация, которую Microsoft IIS будет соблюдать на 105% и этим самым вендер-лочить.
Пффф, сколько там рыночная доли Microsoft IIS? 13.2% http://w3techs.com/technologies/details/ws-microsoftiis/all/all
И какой она станет, если MSFT начнет что-то там вендорлочить? Им то как-раз наоборот выгодно к релизу серверной 10-ки выкатить сверкающию референсную поддержку HTTP/2.0 заявить и исполнить, чтобы в маркетинговом буллшите хвалиться, что они первые в Enterprise Level OS это сделали.
systemd для веба
Ровно наоборот. Протокол, решающий реальные проблемы, сдизайненный с участием тучи народа и вообще никак не затрагивающий никого, кроме http-слоя сервера и браузера, Практически идеальный переход на новую технологию.
> Практически идеальный переход на новую технологию.…которая нахрен не нужна.
>> Практически идеальный переход на новую технологию.
> …которая нахрен не нужна.А вот для таких клёвых парней и девчёнок как ты в аду уже заготовлены специальные котлы, в которых грешники сидят на модемных линках 14400/NONE за NAT'ами в подсети 10.0.0.0/8 и страдают.
страдают от того, что вокруг ни одного хипстера, срать некому. ужасные страдания!
Как минимум, оно убьёт кучу костылей - от уродливой хрени под названием "спрайты", когда для экономии коннекшнов 100500 картинок лепятся в одну, до горы хостов, на которые раскидываются запросы чтобы обойти ограничение по коннекшнам.А так - ускоряет что-то там - и хорошо. Приоритеты, опять же... хотя поглядим, кто как этим будет пользоваться.
> Как минимум, оно убьёт кучу костылей - от уродливой хрени под названием
> "спрайты", когда для экономии коннекшнов 100500 картинок лепятся в одну, до
> горы хостов, на которые раскидываются запросы чтобы обойти ограничение по коннекшнам.нет, оно просто маскирует жопорукость «создателей» сайтов, вот и всё.
спрайты, кстати — вполне нормальная техника. а вот 100500 мелкокартиночек — это идиотизм.
> А так - ускоряет что-то там - и хорошо. Приоритеты, опять же...
> хотя поглядим, кто как этим будет пользоваться.вот и добрались до ключевого: нафиг не нужно. HTTP — вполне нормальный протокол. простой в понимании, простой в реализации, выполняющий то, что от него нужно. но, конечно, если начать пихать невпихуемое — то он как-то не очень хорошо работает. но это не потому, что HTTP весь такой старый, а потому, что новомодный уеб — бесполезное жирное дерьмо.
А что такого плохого в мелких картиночках? С понятными именами, возможностью тянуть когда надо, возможно, разными типами, в конце концов? А вот спрайты - совершенное изврашение и со стороны разработки сайта, и когда хочешь руками чужую страницу подправить или, упаси боже, вообще себе картиночку сохранить.Насчет убогости новомодного веба - согласен, но так как он никуда пропадать не собирается, лучше бы его убогость подкручивать помаленьку. Адекватный протокол - один из элементов.
> А что такого плохого в мелких картиночках?а зачем они вообще нужны? буквы передаются не так.
> Насчет убогости новомодного веба - согласен, но так как он никуда пропадать
> не собирается, лучше бы его убогость подкручивать помаленьку. Адекватный протокол -
> один из элементов.нет, костылепротокол, призваный скрывать криворукость и костыльность уебостроителей не помогает *ничему*. он делает именно то, что я написал: скрывает криворукость, приучая к мысли, что веб — это вот то вот хипстероговно, что мы повсеместно наблюдаем.
Картиночки - оформительствовать, чтобы визуально быстро на странице сориентироваться можно было. Кнопочки всякие - раз уж они есть, то пусть будут человечески сделаны.Ну вот прикинь - веб это нынче именно это вот хипстероговно. Я слабо представляю ситуацию, когда он откатился бы к гипертекстовому хранилищу статической инфы. А вот что он может стать менее архитектурно кривым с текущим контентом и запросами пользователей (да и пофиг на них) - некоторая надежда есть. Ну там - GUI-тулкиты вменяемые, контент, не перемешанный с оформлением, какие-то стандартные способы всё это машинно обрабатывать и т.д. В принципе, сейчас с этим лучше, чем лет пять назад.
> Картиночки - оформительствовать, чтобы визуально быстро на странице сориентироваться
> можно было.это же как ублюдочно надо делать страницы, чтобы без помощи картиночек там и ориентироваться было трудно? впрочем, я знаю, чуть ли не на каждом сайте сейчас можно посмотреть.
> Кнопочки всякие - раз уж они есть, то пусть будут человечески сделаны.
да. с надписью. хотя о чём это я… чтение — слишком сложная задача для современного человека, наскальные рисунки лучше.
> Ну вот прикинь - веб это нынче именно это вот хипстероговно.
и? я говорю, что оно не нужно вместе с новым протоколом. надежды никакой нет, defective by design.
> Как минимум, оно убьёт кучу костылей - от уродливой хрени под названием
> "спрайты", когда для экономии коннекшнов 100500 картинок лепятся в одну, до
> горы хостов, на которые раскидываются запросы чтобы обойти ограничение по коннекшнам.Открой для себя CDN. И удивись.
> А так - ускоряет что-то там - и хорошо. Приоритеты, опять же...
> хотя поглядим, кто как этим будет пользоваться.На HTTPS уже поглядели.
Сказали ж тебе - есть реализации на высокоуровневых языках. Так что кому надо - реализовали. А что у разработчиков ngix, apache и прочих хватит квалификации - я как-то не сомневаюсь.
Тем более, что spdy в Nginx есть уже давно. :)
> Тем более, что spdy в Nginx есть уже давно. :)Угу, вечная бета нджинкс.....
Открыл пдфку и вижу:Содержимое:
1.История
1.1.Автор
1.2.Помогите!
Скорее бы в nginx добавили поддержку этого протокола.
зачем?
> зачем?Как минимум, чтобы пощупать, не?
Бинарный http, это конечно хорошо, но когда мы увидим бинарный css, html, javascript?
> Бинарный http, это конечно хорошо, но когда мы увидим бинарный css, html,
> javascript?компиляция сайтов в бинарные блоки — это было бы слишком некостыльное решение. если ты внимательно посмотришь на уеб, то увидишь, что популярны там решения исключительно костыльные и мегакостыльные.
Вам шашечки или ехать? Content-Encoding: gzip, js и css minifying недостаточно бинарны?
> Вам шашечки или ехать? Content-Encoding: gzip, js и css minifying недостаточно бинарны?О! См. на один коммент выше!
Дело не только в узколобом решении "сожмём вот этот конкретный запрос", но и вообще в инфраструктуре. Бинарные куски страницы можно было бы собирать в пакеты, которые можно загружать опционально. Скажем, структура страницы - pkg1, контент страницы (текст) - pkg2, стили и скрипты, глобальные по сайту - pkg3. Тогда мы имеем только ТРИ запроса. Причём pkg3 даже не придётся запрашивать повторно, а его содержимое более эффективно сожмётся за счёт избыточности и схожести файлов стилей/скриптов.
Так что да, gzip НЕ ДОСТАТОЧНО.
> Бинарные куски страницы можно было бы собирать
> в пакеты, которые можно загружать опционально.HTTP/3.0 поверх libsolv?..
> Бинарный http, это конечно хорошо, но когда мы увидим бинарный css, html,
> javascript?Да давно уже изобрели! Называется .NET+WPF :) Там тебе и стили, и разметка, и программы... Одно не понимаю - какого чёрта MS ждала 12 лет, чтобы стать многоплатформенной.
