Опубликован черновик спецификации HTTP 2.0

    Сегодня был опубликован черновик спецификации стандарта HTTP/2.0. HTTP 2.0 — первая новая версия HTTP-протокола с появления HTTP 1.1, описанного в 1999 году (RFC 2616).
    Прочитать черновик можно по ссылке: http://tools.ietf.org/html/draft-ietf-httpbis-http2-04

    Главная новинка: в качестве основы HTTP/2.0 используется SPDY — бинарный протокол прикладного уровня от Google поверх TCP/TLS соединения.

    В HTTP/2.0 ожидается сохранение семантики HTTP, но уход от использования устаревшего синтаксиса и оформления сообщений в стиле HTTP/1.x. Среди ключевых задач, возложенных на HTTP/2.0:

    • Повышение эффективности использования сетевых ресурсов (в первую очередь — уход от необходимости в создании нескольких TCP-соединений);
    • Серьезное увеличение производительности для современных браузеров и мобильных устройств;
    • Возможность развертывания в современном Интернет, используя IPv4 и IPv6, и не забывая о NAT;
    • Упрощение развёртывания решений на базе HTTP;
    • Обеспечение современных требований к безопасности;
    • В процессе создания спецификации отдельное внимание уделяется необходимости учёта специфичных особенностей применения HTTP (например, WebAPI и прокси).

    В качестве основы HTTP/2.0 по предложению Марка Ноттингема, руководителя рабочей группы IETF, используется протокол SPDY, созданный компанией Google (он уже поддерживается на сайтах Google, Twitter, Wordpress.com, Facebook, а также в браузерах Chrome, Firefox, Opera и IE11 — спасибо kirugan за дополнения). SPDY позволяет существенно ускорить загрузку сайтов по HTTP за счёт сжатия заголовков HTTP, мультиплексирования запросов и расстановки приоритетов для запросов. Он разработан специально для минимизации задержек при соединении и обмене данными между клиентом и сервером: по данным самой Google, ускорение работы сайтов с его использованием составляет от 15% до 50%. Доступны реализации протокола на языках Python, Go, Ruby, Java и JavaScript (node.js). Подготовлен специальный прокси-сервер, позволяющий использовать протокол SPDY для любых сайтов. Код с реализацией SPDY открыт под лицензией Apache.

    На Хабре SPDY год назад обсуждали здесь.

    Исходный код и баг-трекер: https://github.com/http2/http2-spec
    Wiki: http://tools.ietf.org/wg/httpbis/
    Поделиться публикацией

    Комментарии 26

      +6
      SPDY уже поддерживается Opera, ну и вроде как обещают в IE 11
        0
        Спасибо, добавлю в пост.
          –3
          А также Firefox (с версии 11, но отключен по-умолчанию; включен по-умолчанию с версии 13).
            +3
            Пруф ИЕ11
            image
            0
            Звучит хорошо. :) Давно пора было обновить HTTP.
              –23
              Не взлетит.
              Или — взлетит, но намного позже html5.
              Лет на 20..100 примерно.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +2
                  Не совсем. По крайней мере в SPDY это не предусмотрено. Вместо этого используется возможность выбора протокола, заложенная в SSL. В браузере то все равно, а вот в какой-нибудь клиенте, работающий с HTTP API тащить еще и реализацию SSL не всегда хочется.
                  +4
                  Каким боком SPDY интересно коснулся html5? Как то уж слишком жирно, особенно цифра — 100.
                  Для html5 разработчик, SPDY почти прозрачно ляжет между ними и серверами. Конечно, знание протокола желательно, как и в случает HTTP 1.1. Однако, многие до сих пор его (1.1) толком не знает, не только клиентские разработчики.
                  +2
                  Бинарный протокол — YEAH!
                    +3
                    Если-бы… Топикстартер немного приукрасил, он не бинарный, как например net.tcp из WCF или TCP-сокеты.

                    SPDY does not replace HTTP; it modifies the way HTTP requests and responses are sent over the wire. When sent over SPDY, HTTP requests are processed, tokenized, simplified and compressed. ...all existing server-side applications can be used without modification if a SPDY-compatible translation layer is put in place.

                    Грубо говоря — прозрачный компрессор и менеджер пакетов между обычным веб-сервером и ethernet.
                      +7
                      Хочется взять и… придумать интернет с чистого листа.
                        0
                        Так никто и не мешает. Есть WCF — честно бинарный. Никто не мешает сделать и описать стандарт команд для HTTP3 на этой базе, за исключением, что адреса вместо HTTP:// будут NET.TCP://

                        Майкрософт не стала так делать по каким-то причинам, хотя такой новый честно бинарный интернет был бы в сотни раз быстрее. Ответ один — Майкрософт посчитала, что это никому не нужно, как жизненная необходимость.

                        WCF конечно рвет по производительности в десятки и сотни раз, но это только для корпоративного сектора со своей экосистемой. Для простых смертных нет стандарта, и там используются адаптеры и порты на классический HTTP.
                          0
                          … ну или Майкрософт бы просто никто не поддержал в *nix среде, хотя эта среда бодро поддерживает WCF, а до этого Remoting поддерживала.
                    +7
                    Google уже наигравшись со SPDY и осознав количество реальных проблем с ним, придумывает новую игрушку: QUIC (в этом же документе можете прочитать про часть проблем со SPDY).
                      0
                      — в этом же документе можете прочитать про часть проблем со SPDY
                      Можете подсказать, где? Там большой документ, написанный частично техническим языком.
                        0
                        Хм… я вроде ссылку дал именно на этот раздел: SPDY SUPPORT MOTIVATIONS
                        +1
                        Там только про проблемы SPDY over TCP, что логично, ибо QUIC — альтернатива TCP а не SPDY/HTTP.
                        +5
                        А за счет чего возникает преимущество по скорости у SPDY и HTTP/2? Я не понимаю.

                        Сжатие заголовков HTTP?
                        Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?

                        Мультиплексирование запросов и расстановка приоритетов для запросов? — это связанные вещи и рассматривать их лучше вместе.
                        Допустим, у нас есть загружаемая страница, с которой происходит еще 100 вызовов на дизайнерские картинки, превью фото, js, css…
                        Как сейчас работает правильная связка HTTP/1 клиент-сервер?
                        а) 4-8 параллельных соединений с клиента (реалии всех современных браузеров)
                        б) keep-alive
                        В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).
                        Несколько лет назад было такое многообещающее расширение — HTTP pipelining, предусматривавшее передачу нескольких HTTP-запросов в рамках одной TCP-сессии. Вот в нем проблема с тупящим запросом встала в полный рост: запросы из пачки должны были обрабатываться строго по очереди. В результате вместо увеличения скорости работы получили непредсказуемые тормоза. Сейчас это расширение поддерживается браузерами, но почти везде по умолчанию отключено. Но с параллельными соединениями ситуация другая: чтобы начали проявляться тормоза, нужно, чтобы все 4-8 соединений были забиты тупящими файлами. Я, наверное, могу придумать такую ситуацию: из 100 объектов на странице 10 относятся к одному домену, сервер с которым лег. Но это довольно искусственный пример (пропорция должна быть именно такой и мы неявно предполагаем, что страница без этих объектов все еще будет информативна для пользователя).

                        Получается, что сравнение не совсем корректно.
                        SPDY по сравнению с голым ненастроенным HTTP/1 сервером, доставленным на машине времени из 2000 года — да, превосходен.
                        SPDY по сравнению со связкой HTTP/1 + gzip,deflate + keep-alive + параллельные соединения с клиента… примерно то же самое.

                        А теперь самое интересное. SPDY требует наличия TLS.
                        Подождите, но ведь TLS-handshake для каждого соединения значительно дольше, чем TCP-handshake в старом добром HTTP/1? Да.
                        И шифрование трафика значительно увеличит нагрузку на сервер? Да.
                        И что, в Google это понимают? Да.
                        «Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection.» — честно признаются разработчики.

                        В общем, если ваш проект уже использует только https — наверное, есть небольшой бенефит от перехода на spdy.
                        А вот какой смысл переходить на него с http — не понимаю.
                          0
                          Более того, Google продвигает расширение к TLS которое позволит организовывать сессии, что в конечном итоге будет означать уникальный идентификатор каждого устройства со всеми вытекающими от сюда последствиями.
                            0
                            Но ведь в нынешних HTTP/1 браузерах и веб-серверах повсеместно используется Accept-Encoding:gzip,deflate. Что предлагает SPDY помимо этих же модулей, но только используемых по дефолту?

                            Это дает сжатие исходящих заголовков. А еще есть фишка со словарем: в SPDY определен словарь, используемый для сжатия. При обычном сжатии первый раз встреченную подстроку надо передать полностью, а при следующих встречах можно ссылаться на неё. В словарь заносятся часто встречаемые подстроки, например HTTP заголовки и сервер сразу может ссылаться на подстроки из словаря не передавая их в первый раз. В итоге можно достичь лучшего сжатия.
                            В результате нет необходимости каждый раз устанавливать tcp-соединение (б) и отпадает вопрос, что делать, когда один тупящий запрос тормозит остальные (а).

                            Это вы в идеальном мире быстрого домашнего интернета. А еще есть мобильный интернет, который бывает относительно быстрым, но с большим пингом. Поэтому keep-alive на нем работает не так клёво. Использование мультиплексирования позволяет полностью загрузить канал если надо делать много мелких запросов.
                            А теперь самое интересное. SPDY требует наличия TLS.

                            Не совсем так. Если вы хотите negotiation протокола, по которому будет работать клиент и сервер, то вот для этого negotiation и нужен TLS. При желании можно использовать SPDY без TLS на отдельном порту.
                            А еше говорят, что можно устанавливать TLS сессию без шифрования.
                              0
                              Фишка со словарем напоминает сжатие LZ, но в рамках сессии, а не запроса. Да, это интересная вещь. Но, как я понял документацию, этот словарь статический:

                              The stream is initialized with the following dictionary (without line breaks and IS null-terminated): optionsgetheadpostputdeletetraceacceptaccept-charsetaccept-encodingaccept-languageauthorizationexpectfromhostif-modified-sinceif-matchif-none-matchif-rangeif-unmodifiedsincemax-forwardsproxy-authorizationrangerefererteuser-agent100101200201202203204205206300301302303304305306307400401402403404405406407408409410411412413414415416417500501502503504505accept-rangesageetaglocationproxy-authenticatepublicretry-afterservervarywarningwww-authenticateallowcontent-basecontent-encodingcache-controlconnectiondatetrailertransfer-encodingupgradeviawarningcontent-languagecontent-lengthcontent-locationcontent-md5content-rangecontent-typeetagexpireslast-modifiedset-cookieMondayTuesdayWednesdayThursdayFridaySaturdaySundayJanFebMarAprMayJunJulAugSepOctNovDecchunkedtext/htmlimage/pngimage/jpgimage/gifapplication/xmlapplication/xhtmltext/plainpublicmax-agecharset=iso-8859-1utf-8gzipdeflateHTTP/1.1statusversionurl

                              То есть, передавая в каждом запросе
                              User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
                              SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
                              Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?

                              Это вы в идеальном мире быстрого домашнего интернета. А еще есть мобильный интернет

                              Интересный аргумент. Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.

                              А еше говорят, что можно устанавливать TLS сессию без шифрования.

                              Можно, факт. Но медленного установления соединения это не отменяет.

                              При желании можно использовать SPDY без TLS на отдельном порту.

                              Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
                              Не поделитесь более подробной информацией на этот счет?
                                0
                                Вся фишка словаря в его статичности. Его не надо передавать. Но:
                                There is a single zlib stream (context) for all name value pairs in one direction on a connection.

                                Т.е. последующие запросы к тому же серверу, идущие через то же соединение могут ссылаться на подстроки в предыдущих запросах. И как раз user agent сожмется.
                                А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом

                                Если не ошибаюсь, то все заголовки принудительно переводятся в нижний регистр.
                                Можно, факт. Но медленного установления соединения это не отменяет.

                                Не отменяет, но соединяться надо всего один раз за сессию.
                                Но есть и такой — на медленных мобильных каналах исходная страница будет загружаться кусками. И пока загрузится сама страница, большая часть сопутствующих запросов уже будет отправлена, неважно, по HTTP или SPDY.

                                Он бывает не медленный, но с большим latency. Т.е. при использовании keep alive между завершение запроса и началом следующего проходит приличное время, 0.5 секунды, например. Чтобы использоавть канал оптимально приходится держать много http соединений.
                                А на медленных соединениях хороша фишка с приоритетами, сервер может придерживать графику, пока передается контент. Но большие буферы на базовых станциях могут помешать работать приоритетам хорошо.
                                Вот с этим было бы очень интересно поэкспериментировать. Но я спрашивал об этом представителя nginx на последнем Highload++ и он явно сказал, что нет, SPDY этого не позволяет.
                                Не поделитесь более подробной информацией на этот счет?

                                Позволяет, просто это рассматривается как debug режим. Вы можете запустить хром со специальным ключиком и он будет использовать SPDY без SSL вместо HTTP. Т.е. он напрочь перестает работать с HTTP серверами и работает только с SPDY.
                                С серверной стороны аналогичного поведения можно добиться устанавливая какие-то флажки в конфигах. В модуле для apache точно есть, про nginx не помню.
                                Т.е. технически это делается, но совместимость с браузерами никакая. Но для замены HTTP API вполне может использоваться.
                                  0
                                  Я поддержу обоих оппонентов. В любом случае дефлейт исключительно заголовков конечно мало что даст — заголовки обычно ничтожно мизерны по сравннию с самим сообщением.
                                  А изначально бинарные данные так и будут перекодироваться избыточно в base64, а потом перекодироваться в бинарные — помощь от дефлейта будет, скорее всего крохотная, но зависит от данных.

                                  Комедия все-равно остается, как по изначально бинарному TCP передать обычное булево значение, один бит всего. Как он по HTTP передается — это целый цирк, SPDY этот цирк только веселее делает, который будет передан по TCP, который один бит булева значения мог бы передать одним битом технически, но передает 1900 байт и это даже в один TCP-пакет не помещается.

                                  Эффективность менеджера пакетов — большой вопрос, требующий большой истории опыта использования в разных условиях. Теоретический предел типа «10000% ускорения» можно и другими теоретическими способами достич на синтетических тестах, а практика штука злая и суровая.
                                  0
                                  То есть, передавая в каждом запросе
                                  User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
                                  SPDY будет ссылаться только на подстроку «User-Agent», чем сэкономит считанные байты, а сам юзер-агент будет передаваться полностью каждый раз. А, возможно, и название заголовка не будет сжато, так как оно набрано кэмел-кейсом.
                                  Реально клево помог бы сжимать заголовки пополняемый словарь, но его, как я понимаю, в SPDY не будет. Или будет?


                                  1. Да, заголовки приводятся к нижнему регистру
                                  2. Указанным словарём всего-лишь инициализируется сессия zlib, дальше конечно мы можем ссылаться и на отправленные ранее данные (в пределах окна). Так что повторяющиеся одинаковые запросы с легкостью будут сжаты до пары десятков байт, даже если они не были предугаданы в статическом словаре.
                                  3. Описанное в предыдущем пункте сжатие, к сожалению, в полной мере не применяется из-за CRIME-атаки, позволяющей по изменению размера шифрованных сжатых данных судить о их содержимом: code.google.com/p/chromium/issues/detail?id=139744
                              +3
                              Согласен с автором Varnish-cache, этот http/2.0 скорее похож на http/1.2, он не предлагает ничего концептуально нового. Нет качественного скачка вперед.

                              At the end of the day, a HTTP request or a HTTP response is just some metadata and an optional chunk of bytes as body, and if it already takes 700 pages to standardize that, and HTTP/2.0 will add another 100 pages to it, we're clearly doing something wrong.


                              полный текст

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое