Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернет, завершил (http://www.ietf.org/mail-archive/web/ietf-announce/current/m... формирование RFC для протокола HTTP/2.0 и опубликовал (https://www.rfc-editor.org/info/rfc7540) связанную с ним спецификацию как RFC 7540 (http://www.rfc-editor.org/rfc/rfc7540.txt). RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.
В основу HTTP/2.0 положен протокол SPDY (http://www.opennet.ru/opennews/art.shtml?num=33638), разработанный компанией Google и позволяющий ускорить загрузку сайтов на 15-50%. HTTP/2.0 решает задачи повышения эффективности использования сетевых ресурсов и снижения задержек при соединении и обмене данными между клиентом и сервером, в условиях изменившихся современных реалий, при которых для загрузки сайта требуется отправить множество отдельных запросов (в среднем около 100), связанных с получением CSS, файлов JavaScript и картинок. Протокол HTTP/1.1, в силу блокировок при конвейерной передаче данных и высоких накладных расходов на отдачу ресурсов небольшого размера, не может обеспечить должную эффективность и вынуждает устанавливать несколько одновременных TCP-соединений к серверу.Основные особенности (http://daniel.haxx.se/http2/) (PDF (https://github.com/vlet/http2-explained/blob/master/http2.ru... HTTP/2.0:
- Применение бинарного протокола, оперирующего передачей бинарных кадров. Каждый кадр имеет заголовок с информацией о типе, размере, опциях и идентификаторе потока. Кадры с типом DATA используются для передачи данных, HEADERS - HTTP-заголовков, RST_STREAM - для досрочного прерывания отправки данных;
- Мультиплексирование и распараллеливание потоков в рамках одного TCP-соединения. Пакеты разных потоков смешиваются и, в отличие от конвейерной передачи HTTP/1.1, не ожидают окончания отправки запроса. Поддержка эффективной двунаправленной передачи данных. Возможность мультиплексирования при обращении к разным хостам, что позволяет дополнительно ускорить одновременную загрузку web-контента с разных сайтов (в SPDY мультиплексирование поддерживается только для одного хоста);
- Возможность установки приоритетов и зависимостей для потоков, что позволяет выделить наиболее важные потоки, которые нужно выполнить в первую очередь, а также определить зависимость одного потока от другого;
- Сжатие HTTP-заголовков. В том числе поддерживается устранение дубликатов заголовков и Cookie, повторяющихся для серии запросов к одному сайту. Допускается определение отдельных заголовков не подлежащих сжатию;
- Низкая чувствительность к задержкам;- Средства для согласования протокола между клиентом и сервером, позволяющие выбрать HTTP/1.1, HTTP/2.0 и другие протоколы: сервер предоставляет список поддерживаемых протоколов, которые может выбрать клиент. Для шифрованных соединений параметры TLS согласовываются при помощи протокола APLN, при котором клиент сообщает список поддерживаемых опций, а сервер выбирает наиболее оптимальный для себя вариант;
- Обеспечение высокого уровня совместимости с HTTP/1.1: сохранены заголовки, схема URI, коды состояния и методы (GET, POST и т.п.). Обеспечена возможность создания прокси для доступа клиентов HTTP/1.1 к серверам HTTP/2.0;- Возможность установки шифрованных (HTTPS) и не шифрованных соединений (HTTP). Шифрование осуществляется с использованием TLS 1.2 или более новой версии. Несмотря на то, что спецификация допускает создание нешифрованных соединений, разработчики Firefox и Chrome намерены обеспечить работу HTTP/2.0 только поверх TLS;
- Поддержка технологии Server push (https://ru.wikipedia.org/wiki/%D0%A2%D0%... для передачи данных от сервера к клиенту (например, когда сервер считает, что после определённого запроса обязательно будут затребованы другие данные, он может отправить эти данные не дожидаясь фактического запроса);
- Поддержка HTTP/2.0 уже реализована в браузерах Firefox 36+, Chrome (требуется сборка с "--enable-spdy4") и IE 11. Серверные реализации пока ограничиваются (https://github.com/http2/http2-spec/wiki/Implementations)&nb... (http://open.litespeedtech.com/), H2O (https://github.com/kazuho/h2o), nghttp2 (https://nghttp2.org/) и некоторыми библиотеками на высокоуровневых языках.
Дополнительно можно обратить внимание на публикацию (http://www.rfc-editor.org/pipermail/rfc-dist/2015-May/004288... 7539 (https://www.rfc-editor.org/info/rfc7539), стандартизующий потоковый шифр ChaCha20 (http://cr.yp.to/chacha.html) и алгоритм аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), разработанные Дэниэлом Бернштейном (Daniel J. Bernstein (http://cr.yp.to/djb.html)), Таней Лэндж
(Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация который позволяет добиться фиксированного времени выполнения без задействования специальной аппаратной поддержки. В настоящее время данные алгоритмы включены в состав OpenSSH и составляют встроенный набор шифров, используемых при сборке без OpenSSL.
URL: http://www.ietf.org/mail-archive/web/ietf-announce/current/m...
Новость: http://www.opennet.ru/opennews/art.shtml?num=42236
Заживём!
если только не будет происходить как с переходом на ipv6, сколько лет переходят, но никак не перейдут.
> если только не будет происходить как с переходом на ipv6, сколько лет
> переходят, но никак не перейдут.
> если только не будет происходить как с переходом на ipv6,
> сколько лет переходят, но никак не перейдут.ipv6 придуман не для перехода на него, а только для создания процесса перехода. Завершать же переход на него по задумке и не требуется. :-)
Cool!
Благодарю тех, кто тут рассказывал в коментах о Берштейне.
> множество отдельных запросов (в среднем около 100), связанных с получением CSS, файлов JavaScriptНормальные CMS и при 1.1 умели перед отдачей упихнуть все js в один файл и все css в один файл, ещё и минимизировать их по возможности. А CMS'кам, написанным левой ногой школьниками для школьников никакой http/2.0 не поможет.
Ога, давайте паковать все в 1 поток пыхами и бидонами, а не быстрым сишным сервисом. Как раз спрос на сервера увеличится, стоядерные процы будут востребованы.
Вы оба не правы.Первый неправ потому что всё намного сложнее чем запихать все в один js (т.к. это по сути нужно делать динамически)
Второй неправ потому что все можно сделать AOT.
Например webpack решает одну из проблем которую решает http/2.
> Второй неправ потому что все можно сделать AOT.Можно. Но сложно. И через джеппу.
> Например webpack решает одну из проблем которую решает http/2.
ИМХО, наиболее логично - кешировать динамику в статику везде где можно, а потом отдавать это по мультиплексированному протоколу.
Ты не понял, иди почитай насколько крут и умен webpack
http://frontender.info/packing-the-web-like-a-boss/
> Ты не понял, иди почитай насколько крут и умен webpack
> http://frontender.info/packing-the-web-like-a-boss/Крутые и умные костыли к дефективному протоколу - это так замечательно, что прямо слов нет. Одни междометия. Но теперь подобное костылестроение останется в прошлом. И это хорошо и правильно.
> т.к. это по сути нужно делать динамическиЭкономия на спичках. Cache-Сontrol + HEAD в любом случае будут жрать меньше и по трафику и по задержке, чем эта пляска на костылях.
Плакать от таких "умных" хочется.
Как будто HTTP/2.0-сервер не может быть реализован на бидоне.
более того один из ранних прототипов реализован на нём
> более того один из ранних прототипов реализован на нёмВот для чего-то такого бидон и годится. Для полурабочих макетов-прототипов программ.
Почему в будующем времени? При мне упоминался 120 ядерный сервер, гоняющий RubyOnRails :)
(это не камень в огород Ruby и Rails, - думаю php с питоном не намного меньше бы требовали)
> Нормальные CMS и при 1.1 умели перед отдачей упихнуть все js в
> один файл и все css в один файл, ещё и минимизировать
> их по возможности.А пихнуть все картинки/иконки в один файл они умели? А грамотно разъяснить браузеру как с этим работать?
2.0 позволяет за единый запрос получить множество не связанных данных. 1.1 - только с костылями и то не всегда.
а веб-сокеты - вообще Полностью лишены оверхэда http и что?
вместо этого - все еще пилят костыли к бородатому http.
мораль?
>> множество отдельных запросов (в среднем около 100), связанных с получением CSS, файлов JavaScript
> Нормальные CMS и при 1.1 умели перед отдачей упихнуть все js в
> один файл и все css в один файл, ещё и минимизировать
> их по возможности. А CMS'кам, написанным левой ногой школьниками для школьников
> никакой http/2.0 не поможет.Ну там "прелести" не только в оптимизации отдачи контента. Там ещё двунаправленные потоки, возможность ответа без завершения приёма запроса и т.п. В общем как с ipv6, перлом6 и прочими такими странностями народ будет долго присматриваться к этому 2-му хттп перед тем, как переходить на него.
Бинарный протокол передачи гипер-текста.
Они серьезно думают что это взлетит?
Там только хедеры и служебная информация бинарная. Нормально, огромное число протоколов так работают.
Telnet'ом уже веб-сервер не проверишь, но это не так уж и важно.
> Telnet'ом уже веб-сервер не проверишь,Ну как бы удачи тебе телнетом изобразить HTTP/1.1 с пайплайнингом, chunked-encoding, gzip и прочим. А то что телнетом кой-как можно пискнуть на уровне HTTP/1.0 - ну, можно. Только на нормального клиента мало похоже.
Ну и что, а никто не думает, что завтра этот http-сервер портируют на arm, а после завтра впихнут в роутер какой-нибудь, а потом надо будет сидеть и тупить - разбирая причину неадекватной работы, существует огромный пласт полупромышленного оборудования, которое управляется только по http, мне вот довелось поручкаться с железякой которая хотела клиентом только ишака, никакие хромы, мозилы, оперы и даже curl'ы и wget'ы не авторизовывала она. Скажете случай 1 на миллион, ну да, конечно оборудование все проходит самую тчательную сертификацию и на рынок попадают, только проверенные партии, ага.
Кагбэ, сервера и броузеры давно умеют в gzip, а это уже далеко не текст, даже если в нём текстовый контент.
> Кагбэ, сервера и броузеры давно умеют в gzip, а это уже далеко
> не текст, даже если в нём текстовый контент.ну если в запросе сказать гзип, то да, а если нет, то нет
> Бинарный протокол передачи гипер-текста.
> Они серьезно думают что это взлетит?А чё. До конца 90-х годах программы компилировали перед их запуском. А потом разленились. Пора старые добрые идеи возвращать и в html - пока не скомпилируешь кучу html-файлов (или cgi-скриптов), нечего отдавать их в доступ. В-)
Бинарные логи -> бинарные протоколы -> бинарное мышление
А если серьезно, то как же потом его отлаживать-то?
> А если серьезно, то как же потом его отлаживать-то?Так же как и все остальное. Браузером, сниффером, логами сервера. А как ты TCP/IP под HTTP с его бинарными полями в заголовках пользуешься? И фреймы эзернета что-то не текстовые.
Http-пакеты, в отличии от остальных бывает приходится собирать вручную, на том же php, python, JS; а низкоуровневые протоколы и отлаживают люди, занимающиеся разработкой сетевых стеков, драйверов, коммутационного оборудования и т.д.И, на текущий момент http-пакеты запросто парсит лиса в средствах web-разработки, bugzilla, liveHTTPheader и прочие-прочие. Соответстввенно и дебажится это все нормально, а вот ковыряться в hex-кодах что-то совсем нет желания, да еще и тянуть себе wireshark.
Ну так вали в дворники, делов-то.
> Ну так вали в дворники, делов-то.Эк ты батхерта то у бидонистов-пэхапэшников вызвал. Прямо любо-дорого смотреть.
А с чего бы средства вебразработки и сёрфинга которые используют эти протоколы внезапно разучатся их разбирать?
Да теперь не так просто самому на простом сокете построить http запрос, но так нафига оно не сведущему если реализаций http уже уйма бери и пользуйся. curl тот же.
Там всё распарсят за тебя и при желании предоставят в подходящем виде.
Или хочется собственный велосипед? Ну так тогда повышай уровень умений и знаний чего уж тут.
> Соответстввенно и дебажится это все нормально, а вот ковыряться в hex-кодах что-то совсем нет желания, да еще и тянуть себе wireshark.Вот такие-же точно гении изобрели когда-то SIP. А потом другие гении от маркетулохии этот геморрой продвинули (h323 им сложно было), и неизвестно как теперь от этого счастья избавиться, потому-что SIP стек уже стал тяжелее чем h323, а взаимоисключающих костылей там все больше и больше.
Но заголовки да, глазами видно. Только нафестивалено там так что из-за системы костылей в стандарте даже в распарсеном логе без бутылки и записывания всего на бумажку или специальных парсеров которые "в теме" разобраться невозможно.
Пускай протокол будет бинарным, но расширяемым и понятным. Чем видно глазами но один хрен китайская грамота.
Только нпсчёт SIP vs H.233 не надо - оба хуже по нынешним меркам.
> Http-пакеты, в отличии от остальных бывает приходится собирать вручную,Теперь кульcисопские художества с мегасерверами на пидoне будут встречаться пореже. И это хорошо.
> php, python, JS; а низкоуровневые протоколы и отлаживают люди, занимающиеся разработкой
> сетевых стеков, драйверов, коммутационного оборудования и т.д.Ну вот питонистам и пыхaпэшникам вообще нeфиг заниматься написанием HTTP серверов, не их епaрхия. Это для вышеупомянутых работа. Тогда получается хорошо. Как в H2O, Nginx, etc. А когда единственое "достоинство" самопального сервера "зато на бидончике" - это не достоинство вовсе, а просто неуемный велосипедизм.
> И, на текущий момент http-пакеты запросто парсит лиса в средствах web-разработки,
Так лиса и HTTP2 распарсит скорее всего. А куда оно денется, если оно понимать это намерено?
> liveHTTPheader и прочие-прочие. Соответстввенно и дебажится это все нормально, а вот
> ковызяться в hex-кодах что-то совсем нет желания, да еще и тянуть себе wireshark.А это уже твои сложности. И уж ты извини, но никто не пишет голыми руками HTTP хидеры. Хотя-бы потому что pipelined http 1.1 запросы, с chunked-encoding ответом, пожатым в гзип ты врялди скроишь руками и еще более врядли распарсишь на глаз. Хотя, конечно, может ты в уме деревья хаффмана строить умеешь, кто там там тебя знает...
> запросы, с chunked-encoding ответом, пожатым в гзип ты врялди скроишь руками
> и еще более врядли распарсишь на глаз. Хотя, конечно, может ты
> в уме деревья хаффмана строить умеешь, кто там там тебя знает...для *запроса* это не нужно, потому что у deflate есть BTYPE 00 aka uncompressed.
правда, '\0' в телнете всё равно вводить задолбаешься.
> Http-пакеты, в отличии от остальных бывает приходится собирать вручную, на том же
> php, python, JS; а низкоуровневые протоколы и отлаживают люди, занимающиеся разработкой
> сетевых стеков, драйверов, коммутационного оборудования и т.д.
> И, на текущий момент http-пакеты запросто парсит лиса в средствах web-разработки, bugzilla,
> liveHTTPheader и прочие-прочие. Соответстввенно и дебажится это все нормально, а вот
> ковыряться в hex-кодах что-то совсем нет желания, да еще и тянуть
> себе wireshark.Так http 2.0 не запрещает же заголовки собирать руками.
>>Бинарные логи -> бинарные протоколы -> бинарное мышление
>>А если серьезно, то как же потом его отлаживать-то?Бинарно
> Бинарные логи -> бинарные протоколы -> бинарное мышление
> А если серьезно, то как же потом его отлаживать-то?Опцией "-vvvvv" и tcpdump'ом/wireshark'ом.
> - были вытеснены sip'ом, несмотря на его проблемы с nat'ом.Скайпу не забудьте все это рассказать, главное. С его самопальным бинарным протоколом.
> Текст" здесь - один из компонентов.
Текст здесь - лишь пережиток прошлого и кусок архаики, который все портит. Пытаться представлять потенциально бинарные данные как текст - клиника в терминальной стадии. Особенно феерично в жаббере вышло.
> Скайпу не забудьте все это рассказать, главное. С его самопальным бинарным протоколом.Понятия "промышленное использование" и "софт для хомяков" - мешать не надо.
> Текст здесь - лишь пережиток прошлого и кусок архаики, который все портит.
Будь современным мужиком, пиши в скайп друзяшкам бинарными кодами.
> Особенно феерично в жаббере вышло.
in-band передача - один из вариантов, когда прямая передача не доступна. Проблемы?
> Понятия "промышленное использование" и "софт для хомяков" - мешать не надо.В результате пока кульсисопы вещают про "промышленное использование", большую часть рынка сожрала мерзкая проприетара. Которая не по феншую, но зато в отличие от стандартного гoвна сделанного по укурке - еще и работает. В реальном мире с реальными сетями. Со всеми их NAT, firewall и проксями. Чем SIP ни разу похвастаться не может, и вообще, под SIP изначально вообще невозможно вменяемо настроить фаер.
> Будь современным мужиком, пиши в скайп друзяшкам бинарными кодами.
Там бинарных данных летает только в путь. Какое нибудь там видео или голосовые данные - ну хоть ты ycpись, не текст и все тут.
> in-band передача - один из вариантов, когда прямая передача не доступна. Проблемы?
Да, я видел как это работает. Передает. Со скоростью 2 килобайта в секунду. Раздувая файло base64-кодированием. И то - это понимает только половина клиентов. За такую реализацию протоколов - надо расстреливать с особой жестокостью. С точки зрения дизайна протокла и просто юзабилити жаббер вышел редкостным г-ом. Сложный в парсинге, глючный, кривой, вечно ничерта не работает. Вот это получается когда какие-то кpeтины пытаются все представить как XML.
>> in-band передача - один из вариантов, когда прямая передача не доступна. Проблемы?
> Да, я видел как это работает. Передает.передача файла в IM, средствами IM-протокола — это вообще верх идиотизма.
>заговор идиотов, которым не нравится бинарный протокол только из-за бинарности.Автор www.catb.org/esr/writings/taoup/html/ch05s03.html известный заговорщик, да. </> Только, называя его идиотом, ты больше сообщаешь нам о себе.
POP3, SMTP, IMAP. Отличные примеры как не надо делать протоколы. В том числе почтовые.Замечательные протоколы. Без докачки, раздувающие аттачи на треть, загибающиеся от спама и потому обвешанные костылями как собака блохами. Весь этот гайд по дизайну протоколов годится для одной вещи: распечатать на мягкой бумаге и положить в сортире, чтобы было чем зад вытирать.
Хотя, конечно, некоторым нравится когда их ото всех щелей вышибают проприетарные аськи и скайпы. Которые намного лучше работают, что и является решающим фактором для юзерья.
Сколько анaльной боли-то...> Замечательные протоколы.
Именно так. Достаточно хороши, чтобы справляться со своей задачей. А то что альтернатива лучше - это вилами по воде писано.
> загибающиеся от спама
Вы так говорите, как будто аська и благословенный бинарный скайп от спама не страдает.
> Которые намного лучше работают, что и является решающим фактором для юзерья.
Чем там упарываются хомяки в этом году - меня не волнует. Позавчера это была аська, вчера - скайп, сегодня - воццап, завтра ещё какую хрень придумают. irc их всех переживёт.
> Сколько анaльной боли-то...Хаха, иногда быает так что оппонент сам согласен с тем что протоколы эпичное деpьмо и доставляют их пользователям головняк :). Вы жжоте!
> Именно так. Достаточно хороши, чтобы справляться со своей задачей.
В результате в энтерпрайзах их место занял микрософтовсий exchange. Он решает более широкий круг задач и по своим самопальным протоколам работает лучше, чем это окаменелое дepьмо мамонта, сделанное в эпоху черно-зеленых терминалов. Поэтому многие корпорахи даже на вендорлок и дойку согласились. Все-таки людям надо работу работать, а не выслушивать булшит про подгон своих требований к дepьмовым свойствам протоколов.
Наверное вам так больше нравится, да? Когда в результате все общаются по каким-то проприентарным скайпам, переписываются через проприентарный аутглюк с собственным протоколом и прочая. Прямо такое ощущение что в стандарты зачастую специально пхают самые горбатые и дурные протоколы. Чтобы проприерасам можно было сделать лучше.
> А то что альтернатива лучше - это вилами по воде писано.
А тут рынок все решает, а не какой-то хрен с опеннета. И там все достаточно недвусмысленно.
> Вы так говорите, как будто аська и благословенный бинарный скайп от спама не страдает.
Кстати что-что а там есть более-менее нормальное решение проблемы спама. Оно у них недоработанное, но в целом на основе ICQ получить почти 100% отсутствие спама - зело проще чем на основе SMTP. Из-за списка контактов и авторизации.
> какую хрень придумают. irc их всех переживёт.
IRC жив только местами, как во фриноде. Ну и сказать что он такой уж чисто текстовый... между серверами линк обычно сжат deflate и ssl во все поля. Да и какой-нибудь DH-based auth в SASL - текстовым является довольно условно. Да и сам текст летает зачастую в каком-нибудь UTF-8, который представляет собой полный ассортимент байтов. А когда серваки или сервисы пытаются сильно умничать в парсинге этого как текста, вместо просто проброса как есть aka "бинарные данные"... у... там столько лулзов возникает, это я тебе голуба, говорю как краевед :). В протоколе IRC уйма бестолковостей. Некоторые, кстати, так нормально местами и не доконопатили - скажем, древнючее развлечение "riding a netsplit" до сих пор позволяет извлекать некоторое количество лулзов, хотя проблема известна ...цать лет и с ней ...цать лет борятся :). Но в силу отсутствия реальной привязки креденшлсов/прав к юзерю это костыли. С множеством изъянов в краевых случаев.
> Ждем форков основных браузеров и веб-серверов от энтузиастов, в которых будет полностью
> выпилен HTTP/2 и которые будут как и раньше использовать текстовой протокол
> HTTP/1.1 или даже более простой и поэтому более надежный HTTP/1.0А чё - разве браузеры да веб-серверы с подключением http/2.0 к себе будут выпиливать из себя поддержку http/1.*? Так ими же станет невозможно пользоваться, если они отключат http/1.*.
У Дэниеля Бернштейна не самые лучшие впечатления о России: http://cr.yp.to/conferences/russia.html
Спасибо, совершенно великолепная статья
Как по мне, в этой заметке Бернштейн выставляет себя в смешном и глупом виде. Гостиница за 30 долларов - и на что можно рассчитывать? При том, что за перелет в бизнес-классе он наверняка заплатил несколько кусков зелени! Ну не идиот ли?))Ну и отношение к достопримечательностям: фонтан в Чикаго больше, чем в Петергофе, следовательно, в Петергофе нечего смотреть. Тупо.
> несколько кусков зелени! Ну не идиот ли?))Как ни странно, бестолковости встречаются и в казалось бы премимум отелях. Типа хамоватого персонала, необоснованной бюрократии и вообще - "ж..й к клиенту".
> следовательно, в Петергофе нечего смотреть.
Однако ж про "buildings are falling apart" верно подмечено. Был в питере. Половина зданий неухоженные, а то и откровенно заcpaнные и разваливающиеся. А другим людям вот не понятно - как можно жить в таком хлеву и ничего по этому поводу не делать.
технически он прав, да.
и таки-да не без толики хумора, написано.
плюс он как и заметная часть ученых, как человек путешествующий не часто и без энтузиазма - болезненно переживает каждую конференцию, практически, вдали от дома и родного ему лично. тут нет большой специфики, у нас так-же примерно.
ну так летом 2000-го 30 баксов было ого-го-го, не то что нынче.
Это для аборигенов было огого. А для него - копейки. Как можно не понимать такой простой вещи - если ты платишь за перелет несколько тысяч долларов (а, значит, ты богатенький буратино - в экономе-то меньше штуки будет), как может гостиница обойтись в несколько десятков? Или так - какой уровень комфорта можно ожидать? Ну, если соотнести.. то, наверно, самый занюханный хостел? Я бы так на его месте подумал...Согласиться на такое можно, только имея представление о России, где медведи по улицам бродят - что, в общем-то и подтверждается в заметке. И это не делает чести г-ну Бернштейну. Математик он, может быть, и отличный - но человек недалекий, к сожалению.