Пользователь
102,0
рейтинг
9 июня 2012 в 16:06

Разработка → Разбор протокола SPDY командой Opera Software

Мартин Нильссон (Martin Nilsson), ведущий программист Opera Software, отправил в рабочую группу IETF HTTP-WG подробный обзор SPDY, сделанный специалистами Opera.

Как известно, протокол SPDY представляет собой улучшенную версию HTTP и во многих случаях значительно увеличивает скорость передачи данных по TCP. Он включён по умолчанию в браузерах Chrome (с января 2011 г.) и Firefox (четыре дня назад).

Мартин Нильссон отмечает, что компания Opera давно занимается оптимизацией передачи данных по HTTP, в том числе в Opera Mini и Opera Turbo, так что они могут оценить различные методы оптимизации SPDY.

Обзор от Opera состоит из трёх частей. В первой части анализируются концептуальные функции SPDY и осуществляется краткая оценка полезности каждой из них. Во второй части приводится оценка бинарной реализации протокола, а в третьей части — предложения Opera по улучшению SPDY. В составлении отчёта принимали участие сотрудники из нескольких подразделений компании, так что его можно назвать продуктом коллективного творчества программистов Opera Software.

Итак, транспортный протокол SPDY работает поверх TCP и заменяет собой HTTP, хотя позволяет транслировать всю семантику HTTP в SPDY. Вот что думают специалисты Opera по поводу методов оптимизации, применённых в SPDY:

1. Конвейер и порядок обработки очереди. Это две очень важные концепции, которые значительно улучшают производительность HTTP. Понятие конвейера появилось в HTTP 1.1 и компания Opera потратила много усилий для популяризации этого решения. К сожалению, очень многие производители оборудования так и не смогли корректно реализовать HTTP 1.1. Порядок обработки очереди устраняет проблемы со стопором конвейера, когда более медленные пакеты блокируют быстрые — и это можно легко реализовать в HTTP, если добавить идентификаторы запроса в заголовки пакетов.

2. Мультиплексирование позволяет обрабатывать более важные запросы/ответы с преимуществом перед менее важными по одному соединению TCP, без открытия нового соединения. В реализации SPDY отсутствуют спецификации по выбору размера фреймов. И поскольку SPDY поддерживает push, то теоретически можно открывать новое соединение по инициативе сервера.

3. Контроль потока за счёт определения размера буфера получателя. В спецификациях SPDY не указано, какие проблемы должен решать этот метод оптимизации. Похоже, что эти проблемы можно решить менее радикальными способами.

4. Сжатие заголовков с помощью zlib. В таблице указан средний размер запроса при сжатии разными методами.
HTTP                                  821.1
HTTP zlib                             543.5
HTTP сжатие со словарём     497.0
SPDY                                  913.7
SPDY zlib                             606.5
SPDY сжатие со словарём     517.0

5. Асинхронные заголовки. Фрейм HEADERS позволяет каждой стороне устанавливать дополнительные заголовки для запроса или ответа, но из-за этого могут возникнуть проблемы, если критически важный заголовок окажется последним. Данная функция делает SPDY более уязвимым перед атаками типа инъекций.

6. Push со стороны сервера. В протоколе указано, что сервер может пушить только после ранее полученного запроса, что делает эту функцию бесполезной, например, для push’а новых элементов RSS, также отсутствует механизм для контроля за размером транслируемого контента или полного отключения функции. У клиента есть выбор принять или игнорировать эту информацию, но это может быть дорогостоящей и бесполезной тратой канала.

В качестве улучшения SPDY специалисты Opera предлагают:

  • установить обязательный фрейм SETTINGS с версией и параметрами соединения, который всегда идёт первым;
  • установить разумный диапазон размеров для каждого поля, основываясь на статистике, где это возможно, и меняя его в случае надобности;
  • установить специализированные фреймы HTTP внутри SPDY;
  • разработать лучшую структуру для списков пар key-value;
  • с клиентской стороны должен быть контроль, какие данные принимать через push от сервера;
  • убрать нынешний контроль потока и заменить его на паузу (имеется возможность для динамического изменения приоритета);
  • не использовать словарь для сжатия заголовков, он даёт мало преимуществ;
  • установить правила для асинхронных заголовков, чтобы запретить перезапись заголовков HTTP, а получатель заранее знал, какие заголовки будут сгенерированы.

Полная версия SPDY Review и обсуждение в списке рассылки IETF HTTP-WG
Анатолий Ализар @alizar
карма
744,5
рейтинг 102,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (45)

  • 0
    О, только захотел прочитать эту статью на английском, как ее перевели!
    • +8
      Такие статьи всегда лучше читать в оригинале.
      • +5
        Особенно когда из 10-страничного документа на английском приводится трёхстраничная выжимка на русском.
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        • +5
          Не, ну я гоготнул над «реактивным твиттером», например. Спасибо.
        • +19
          Ну я к примеру вам минусов не накидал, но с вашим мнением в корне не согласен. Молча сделать — оно конечно хорошо для пользователей сейчас, но уже в обозримом будущем эти архитектурные ошибки (да и просто ошибки) повылазят и страдать будут и разработчики, и пользователи. Вся история развития интернета тому подтверждение.
        • +14
          >Пока другие уже наслаждаются реактивным твиттером, скруглениями краев и прочими няшками,… а пользователи Opera наседают на верстальщиков и вебмастеров всего мира, требуя делать для них специальные хаки для обеспечения нормальной работы и отображения их современных сайтов в запаздывающей или не уверенной в какой-то новой технологии Opera.

          Просто вы выглядите как ещё один критик, который где-то что-то прочитал, или же последний раз юзал Оперу 2-3 года назад, и спешит донести своё авторитетное мнение.
          Я вам порекомендую сначала поставить Оперу и поюзать её, а потом браться за её критику.
          И да, очень интересно читать такое о браузере, который дал своим современным «конкурентам» большую часть их стандартных фишек, и разработчики которого вообще являются одними из авторов HTML5.

          Чтобы вы понимали ситуацию, единственное, чего из +- существенных популярных современных фишек не поддерживает Opera — CSS3 Animations (которые даже в последних вебкитах и ФФ требуют префикса), WebGL — который пока что используется исключительно для лулзов демонстрации того, как можно на него портануть Quake 3, ну и да, SPDY. Причём 2 первые опции поддерживаются в следующей, 12 версии браузера.
          Назовите мне другие опции CSS3 / HTML5, которые ещё не поддерживаются Оперой, при этом поддерживаются в большинстве других браузеров и при этом не имеют статус Draft.
          Я промолчу про сферу мобильных браузеров, где ситуация для вебкитов по сравнению с Оперой выглядит плачевно на данный момент.

          Да, есть сайты, которые полностью игнорируют альтернативные браузеры, и разрабам Оперы приходится подставлять юзерскриптные костыли. Но их выраженное меньшинство, и в повседневном использовании с большинством страниц нет никаких проблем, а преимущества Оперы перед другими браузерами преобладают.
          • +16
            И ещё это, как написал nsinreal выше:
            >Молча сделать — оно конечно хорошо для пользователей сейчас, но уже в обозримом будущем эти архитектурные ошибки (да и просто ошибки) повылазят и страдать будут и разработчики, и пользователи. Вся история развития интернета тому подтверждение.
            В современном вебе есть крайне разрушительная тенденция — считать что есть два пути развития — «усё как у вебките» и неправильный.
            Это опасно, чему мы были свидетелями ещё 10 лет назад, благо сам Мелкософт отпраздновал смерть IE6. Пусть Гугл — более продвинутая контора, чем мелкомягкие, но и они не боги. Топик, собственно — это подтверждает. Или вы считаете что инженер норвежской компании предложил улучшения для текущей реализации SPDY просто чтобы привлечь к себе самому и к своему браузеру внимание?
          • –1
            Дробные проценты, даже не знаю к какой версии спецификации они относятся (CSS1?) — внедрены вот только-только недавно. И то, кажется, пока только в бете.
            Вообще история с этими несчастными процентами уже дичайший и несмешной баян. Но я считаю её очень показательной иллюстрацией к принципу «а мы пойдем другим путем» (о котором и писал автор первого коммента в ветке).
            • 0
              Для симметрии давайте вспомним, как в хроме рисуются скроллбары прозрачных элементов, как рисуется фон строк таблицы и т.д. и т.п.
              • 0
                Собственно, никто и не говорит, что есть «святые» браузеры. Баги есть везде.
                Только одно дело «частные» баги, проявляющиеся в редких специфических ситуациях, и совсем другое — неподдержка одной из древних и фундаментальных штук. Причем под многолетнюю(!) ругань разработчиков.
                • +1
                  Фон tr — это и есть древняя и фундаментальная штука под многолетнюю ругань разрабов.

                  Зачем так остро нужны дробные проценты — представляю с трудом. Да, делить проще без округления и ручного расчёта, но как часто нужно именно 80.375% и 19.625%, но ни в коем случае не 80% и 20%? В среднем — никогда.
                  • +2
                    Ладно, про tr поверю, хотя в реальных проектах ну не сталкивался до сих пор.

                    Про дробные проценты — мне они нужны постоянно. Обычно ситуации 2 сортов:

                    1. Многоколоночная верстка. Чаще всего это 3 колонки (каждая по 33.33%). Вот недавно мне были нужны 8 колонок (по 12.5%).
                    Аргумент «да кто там заметит эту погрешность в доли процента...» — не принимается. Если блок очерчен какими-то линейками или подсвечен контрастным фоном, смещение даже на десяток пикселей уже очень заметно и выглядит неряшливо. Кроме того, округление там идет не к ближайшему, а всегда вниз. В упомянутом 8-колоночном случае это давало погрешность уже 8*0,5=4% экрана. Это уже просто катастрофа.
                    Да, есть методы обхода (через дополнительную html-разметку), но оно мне надо?

                    2. Когда эти проценты рассчитываются скриптом в анимациях, округление процентов приводит к дерганью.
          • +4
            Будучи приверженцом Оперы, не могу заметить что:
            Назовите мне другие опции CSS3 / HTML5, которые ещё не поддерживаются Оперой, при этом поддерживаются в большинстве других браузеров и при этом не имеют статус Draft.
            Скоро таким модулем станет CSS Flexible Box Layout (на текущий момент актуальнее dev-версия). Его ещё не перевели в Last Call, но решение об этом уже принято. Поддерживается, хоть и в черновом варианте, в вебките, гекко и IE10.

            Также не хватает весьма полезного requestAnimationFrame и асинхронной загрузки скриптов (атрибут async).

            Вебсокеты в Опере выключены по умолчанию, хотя другие браузеры уже их обновили и включили.
            • +1
              Давайте хоть на минутку вспомним, что в опере до сих пор нельзя поменять курсор мышки, а это позвольте всё ещё CSS 2.1.

              developer.mozilla.org/en/CSS/cursor
              • +2
                Вы к чему это?
                CSS-свойство «cursor:...» работает в Опере с незапамятных времён.
                Даже по вашей ссылке указано, что Опера поддерживает большинство курсоров ещё с бородатых версий 7-9.
                • 0
                  Это всё к тому, что не работает курсор с url(). Собственно без этого и эказанной ниже функции для анимации, невозможно делать нормальные игры (да возможно, но это уже точно будет не то, что можно сделать в Хроме или Лисе).
              • +1
                Скольким нужен кастомный курсор, а скольким куда более гибкая система раскладки? И рядом не стояло. requestAnimationFrame тоже позволит сэкономить процессор и батарею, особенно когда открыто много вкладок. Это вещи, которые могут очень сильно повлиять на пользовательский опыт.
            • 0
              (removed, stupid comment)
              • 0
                Ну, да, в Опере 12.1 сделали Flexbox и включили сокеты.
          • +5
            Назовите мне другие опции CSS3 / HTML5, которые ещё не поддерживаются Оперой, при этом поддерживаются в большинстве других браузеров и при этом не имеют статус Draft.
            Список тех фич, которые популярны среди браузеростроителей, однако на сегодняшний день никак не поддерживаются Оперою, хорошо известен:

            • атрибуты async и defer для изменения поведения при загрузке внешних скриптов;
               
            • Cross-Origin Resource Sharing (посылка XMLHttpRequest в другой домен) — впрочем, её обещают реализовать в Opera 12;
               
            • HTML5 drag and drop — впрочем, его обещают реализовать в Opera 12;
               
            • Navigation Timing API (это уж никак не Draft: это Candidate Recommendation!);
               
            • XMLHttpRequest 2;
               
            • современная версия вебсокетов;
               
            • CSS-свойство resize;
               
            • API matchMedia для применения медиазапросов джаваскриптом;
               
            • 3D-преобразования CSS3;
               
            • Flexible Box Chrome поддерживает по современной версии спецификации, Firefox по предыдущей, а Opera никак — так что и костылём не подпереть;
               
            • API requestAnimationFrame;
               
            • база данных IndexedDB;
               
            • CSS-функция calc().

            Некоторые из этих фич и впрямь пребывают в состоянии Working Draft. Однако заботит ли это читателя? Нет. Читатель видит только, что в ряде популярных браузеров они работают, а в Opera не работают.
            • +2
              Да, есть фичи, которые не поддерживаются в Опере.

              Но не всё из упомянутого вами популярно среди, собственно, сайтостроителей.
              И в CSS1-2 были непопулярные фишки, которые реализованы в других браузерах и при этом не пользуются популярностью веб-разработчиков. И Оперу с её считанными процентами пользователей в глобальном масштабе в этом винить непоследовательно. Что плохого в отсутствии реализации этих фишек в ней в такой ситуации?

              Другое дело, что, собственно, измерение популярности веб-браузерных фишек — как минимум, не совсем тривиально, особенно если пытаться рассматривать не определённую выборку, а весь интернет.

              И кстати, говоря о неподдерживаемых свойствах CSS — нельзя не отметить, что львиная доля неподдерживаемых Оперой свойств на данный момент в вебкитах и ФФ требует префикса. Это я к «двум путям развития», упомянутым выше.
              • +2
                Ну, это возражение справедливо. Многие из новых возможностей никак не используются сайтостроителями, притом, уж конечно, не Opera, а Internet Explorer им главный тормоз — а пуще того невозможность поставить свежий Internet Explorer на операционную систему Windows XP, до сих пор вполне популярную, хотя давно уж на менее чем у половины компьютеров стоящую.

                И всё же во Хроме да в Файерфоксе можно найти выше мною перечисленные новинки (хотя бы и с префиксами — это нормально, это даже и следует так по стандарту для реализаций тех свойств, которые только в черновике ещё существуют), а в Опере нет.

                Это печально, тем более что есть, напротив, такие свойства, которые сейчас в одной Опере только и реализованы тóлком (например, многоколоночная вёрстка в точности по спецификации, или формы HTML5, или ещё ввод дат и времён и значений цвета, или CSS3-свойства object-fit да object-position), да ведь и есть же ещё примерно столько же таких свойств, которые первыми появились в Опере и затем лишь оказалися подхвачены прочими браузерами.

                То-то и выходит, что сочинять новинки авторы Оперы умеют, а вот подхватывать чужие новинки у них получается не так хорошо и не так быстро.
                • 0
                  > уж конечно, не Opera, а Internet Explorer им главный тормоз
                  Это, кстати, тоже небесспорный постулат.

                  В абсолютном исчислении проблем в IE безусловно больше, намного больше. Но:
                  1. В большинстве совсем они подробно изучены, масса материала в сети, для многих найдены и отлажены пусть и костыльные, но пути обхода.
                  2. Сам IE любезно предоставляет кучу инструментов для решения своих же багов: фильтры, условные комментарии, CSS-хаки, VML, behaviors, expressions и прочая и прочая.
                  3. Есть много способов удобно и надежно определить, что посетитель пришел именно через IE и подсунуть ему персональные стили. В Опере единственный известный мне рабочий способ — JS.

                  В итоге проблем с Оперой, конечно, меньше. Но уж если случается… бывает упираешься в проблему и тратишь по нескольку дней на поиск/изобретение костыля.
        • +3
          То же самое можно сказать про блоги, касающиеся Firefox и Chrome…
      • +5
        > Вместо того, чтобы точно так же взять SPDY «as is», внедрить и отрапортовать об этом пользователям, они проводят анализ протокола и публикуют подобные отчеты.

        Нахера? По принципу «шо бы было»? SPDY критикуют все, кому не лень, причем примерно с тех же позиций, что и Опера, с фактами на руках.
        • –1
          Одно дело сделать и критиковать другое — просто критиковать
          • +1
            Еще раз спрошу. Зачем делать? Чтобы было? Зачем тратить силы на протокол, проблемы которого видны и могут быть объективно оценены без реализации?

            Давайте я буду генерить по стандарту в день, а вы, вместо того, чтобы их разбирать, будете реализовывать?
            • –2
              У всех стандартов есть проблемы. так что не поддерживать вообще никакие? Опера все же догоняющий браузер, и если у всех конкурентов эта фугнция есть, чтобы удержаться на рынке, надо ее поддерживать. а дальше, в меру сил, развивать и улучшать.
              • +1
                > У всех стандартов есть проблемы. так что не поддерживать вообще никакие?

                С каких пор SPDY стал стандартом?

                > если у всех конкурентов эта фугнция есть

                Ага, ага. Прям-таки у всех

                > чтобы удержаться на рынке, надо ее поддерживать.

                Чтобы удержаться на рынке, SPDY даром не нужен.

                Ну и вся эта демагогия никак не относится к бредятине типа «Одно дело сделать и критиковать другое — просто критиковать»
              • +1
                Ну и да, к вопросу о «сперва добейся»

                lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0546.html
                We have Opera Mini that uses several different protocols, both similar to
                HTTP as well as of the persistent TCP connection type. These are all
                binary protocols using different versions of request-response, RPC, push
                features, as well as compression of different sorts. We have Opera Turbo,
                which is essentially a modified HTTP with prioritized, out-of-order
                pipelining and some simple compression. Finally we have integrations with
                different 3rd party technologies, some of which are mentioned on the press
                release pages
                www.opera.com/press/releases/2004/11/04/
                www.opera.com/press/releases/2007/02/06/


                То есть ВНЕЗАПНО Опера реализует толпу похожих технологий и вполне может оценить недостатки протокола, не реализуя его.

                Но да, но да, надо обязательно ломиться реализовывать все, что появляется в интернете ибо!
  • +10
    SPDY не нужен.
    • –6
      Не знаю, SPDY или не SPDY, но уже давным давно пора жать всю текстовую инфу (HTML/CSS/что там еще) любым пакером на уровне протокола. Во времена диалап мопедов так и делали, только жаль ethernet не подхватил инициативу.
      • +2
        Большинство веб-серверов отдают контент ужатый gzip-ом.
      • +1
        >но уже давным давно пора жать всю текстовую инфу

        Вообще-то все так давно и происходит. Промониторье запросы браузера, например, к хабру — везде Content-Encoding:gzip
        • +2
          Заголовки не жмутся. Это проблема, особенно, если cookie большие.
          • 0
            >Заголовки не жмутся.

            Соглашусь, но мне кажется что без накопления словаря между сообщениями это не сильно поможет.
          • 0
            Зачем вам большие cookie?
            • 0
              Мне — незачем, а вот сайтам, которые я посещаю, они зачем-то нужны.
  • +2
    Интересно, по каким причинам они решили заниматься мультиплексированием по TCP вместо гораздо более подходящего SCTP?
    • +3
      1) Очевидно же. Просто TCP поддерживается (можно смело делать такое предположение что) везде и всегда. А заверни это все в SCTP мы сразу уткнемся в кучу софта и оборудования которое просто не умеет с ним работать. Вот например, вы уверены что ваш роутер умеет NATить и Файерволить SCTP? А роутеры на тех вай-фай точках где вы бываете? А в интернет-кафе? А еще на миллионах машин?
      2) Кстати, в SCTP «завернуть» и сам HTTP можно ведь он намертво не «приклеен на эпоксидке» к TCP. Вот например, так называемый «https» из себя представляет ничто иное как HTTP «завернутый» в ssl-соединение.

      • 0
        Ну как появится спрос, сразу научаться. А так, можно деградировать до нынешнего TCP.
        • 0
          > Ну как появится спрос, сразу научаться.

          Не появится, и не научаться! Вы хоть себе примерно представляете количество миллиардов строк кода, которые надо переписать во всем софте по всему миру чтобы перейти с TCP на SCTP? Поэтому SCTP как был, так и останется узко-нишевым протоколом, который будут использовать не по принципу «давайте использовать, потому что лучше», а по принципу «в данной конкретной системе эффект от SCTP реально окупит трудозатраты и геморой на его внедрение».

          > А так, можно деградировать до нынешнего TCP.

          А вот тут, пожалуйста, поподробнее. У вас есть на руках результаты каких-то новых, ранее неизвестных, подробных исследований «деградации TCP» о которых до сих пор не знает широкая общественность? Я вам могу привести всего лишь несколько реальных (и общеизвестных) примеров, когда «особенности TCP» могут представлять собой «более-менее узкое место» НО… и при всем этом, насколько вам известно, до сих пор «суммарная весомость» этих примеров так и не набрала настолько «критическую массу» нареканий, чтобы началось массовое «бурление» по поводу массового отказа от TCP.

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