Мартин Нильссон (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
