LXF129:Что за штука

Текущая версия на 16:35, 30 октября 2011

[править] Что за штука… SPDY?

Мы с трудом упросили фаната скорости Марко Фиоретти притормозить: очень хочется выяснить планы Google по ускорению web-серфинга...

• Здорово — еще один акроним! И как он раскрывается?

Во-первых, это способ ускорения web-серфинга, предложенный Google в ноябре 2009 года. Во-вторых, это не акроним, а аббревиатура. По версии Google, слово SPDY (произносится «спиди», быстрый) намекает на скорость и на то, «как сжатие может помочь увеличить ее».

• Чувствую, нужно обратиться к основам Интернета...

Вы, наверное, замечали, что большинство интернет-адресов начинается префиксом http://. HTTP означает Hyper Text Transfer Protocol (Протокол передачи гипертекста). Для браузера префикс http:// в начале адреса равносилен команде «использовать протокол HTTP, чтобы попасть к файлу по указанному адресу». Файлом может быть что угодно – от фотографии до потокового видео или текста, динамически извлеченного из базы данных.

• И как же браузер это делает?

Он находит сервер, где хранится нужный файл, и посылает туда запрос в формате HTTP. Если такой документ существует, то сервер отвечает отправкой HTTP-заголовка, в котором содержатся метаданные (размер файла, время изменения и пр.), затем передает и сам файл.

• Чего же недостает HTTP?

В стародавние времена с HTTP было все в порядке, ведь протокол был рассчитан на запрос и передачу за один сеанс одного файла, независимо от его размера. В середине 90‑х, когда почти все web-страницы были нарезкой из простого текста, протокол был весьма эффективен. Современные страницы – это коллажи из различных, порой очень мелких объектов: таблиц стилей CSS, информации о состоянии (cookies), картинок, звуковых дорожек, текста и всевозможных скриптов.

• А почему HTTP перестал справляться?

Видите ли, HTTP создает новый сеанс – с заголовком, запросами и пр. – для каждого из этих мелких объектов. Мало того: в HTTP нет средств минимизации латентности, то есть времени, необходимого на полную доставку web-страницы от источника до места назначения. Благодаря широкополосному соединению инфраструктура Интернета работает теперь значительно быстрее, но даже в высокоскоростном физическом канале сеть все равно будет изрядно «тормозить», если передачей файлов руководит медленный протокол. Несмотря на организацию параллельных сеансов, как в современных браузерах, лишней информации и задержек все равно слишком много.

• Ладно, вернемся к SPDY. Расскажите мне о новой технологии.

Это новый протокол, предложенный Google на замену HTTP. Предполагается, что он устранит или сведет к минимуму затруднения, которые я только что описал, за счет сжатия заголовков.

• Какие заголовки будут сжимать?

Те, из которых состоят стандартные HTTP-запросы и отклики. По данным Google, сжатие заголовков (т. е. строк простого текста) с помощью gzip уменьшит их размер более чем на 80 % и сбережет по секунде на загрузке каждой страницы. А есть еще уплотнение ресурсов...

• А поподробнее, пожалуйста!

SPDY объединяет отдельные HTTP-потоки, необходимые для доставки полной web-страницы. Для этого используется тот же протокол SSL (Secure Socket Layer), который применяется для шифрования интернет-трафика. Все компоненты web-страницы упаковываются в единый пакет данных; пересылка идет по общему каналу.

• Где ж тут экономия места — ведь общий объем пакета равен сумме всех его компонентов!

И да, и нет: ведь мы экономим на упаковке! Все компоненты сложены в один большой цифровой набор, и понадобится только один комплект заголовков, контрольных пакетов и прочих «сопроводительных документов». В результате значительно сокращается количество лишних битов, необходимых для доставки web-страницы на ваш компьютер.

• Мне кажется, латентность при этом тоже сокращается...

Именно! Если у нас один поток данных вместо множества мелких ручейков, сокращается количество необходимых действий (и время, необходимое компьютеру для проверки результатов).

• Получается, что по функциональности SPDY подобен HTTP, только быстрее?

Вовсе нет. Поскольку SPDY использует SSL, а SSL поддерживает шифрование, Google предлагает заодно повысить конфиденциальность просмотра web-страниц. Сам SSL как протокол используется в технологии SPDY потому, что способен формировать как бы трубу, по которой безопасно путешествуют наши упакованные данные. В пути их ничто не изменит, их не заблокируют старые прокси или маршрутизаторы, «понимающие» только HTTP. Кроме того...

• Еще не все?! SPDY осталось только сделать мне стирку и уборку!

Ну, это вряд ли, но новый протокол позволяет серверам «проталкивать» контент в ваш браузер, упреждая запросы, путем «отдачи со стороны сервера» (server push) или «серверного намека» (server hint). Первое равносильно сообщению сервера вашему браузеру: «Эй, прихвати-ка еще один файл – раз ты заказал эту страничку, другая тебе понадобится уже через пару миллисекунд». Так можно здорово ускорить перемещение по web-сайтам, но представьте себе, что эти «файлы в нагрузку» – рекламные баннеры или фоновый звук, которые вам совсем не нужны! Серверный намек – то же поведение, только в более мягкой форме. Сервер лишь «предлагает» браузеру взять что-то дополнительно, для ускорения просмотра.

• Какой прирост скорости ожидается при использовании SPDY?

Первые тесты, проведенные Google на нескольких наиболее популярных сайтах, обнаружили обгон HTTP на 27–60 %. Однако Google предупреждает, что для получения достоверных результатов необходимо более продолжительное тестирование и доработка имитационных моделей.

• Но и 27 % неплохо, а? Сетевые администраторы будут рады.

Теоретически. На практике SPDY не обязательно исправит недостатки HTTP. Некоторых беспокоит, что принудительное шифрование увеличит нагрузку на web-серверы и клиентские терминалы (особенно маломощные). На это можно возразить, что основным ограничением сейчас является пропускная способность сетей, а не мощности процессоров. Другие предупреждают о последствиях утраты пакетов, вопросах обратной совместимости и проблемах кэширования SSL.

• А почему утрата пакетов на SPDY более опасна, чем на HTTP?

При передаче по SDPY все компоненты web-страницы передаются разом, и при потере одного из них страница будет оставаться пустой дольше, чем при передаче по HTTP. Google возражает, что, поскольку при использовании SPDY сокращается общий объем трафика, потеря пакетов не должна ухудшить общую картину. Опять же, определенный ответ дадут только практические испытания.

• Два конкурирующих протокола для загрузки web-страниц вызовут кошмары с совместимостью…

Ну, пусть браузер начинает с HTTP-запроса, а затем, если сервер поддерживает новую технологию, переключится на SPDY – вряд ли это будет помехой. Сложнее с кэшированием.

• Почему?

Статические web-страницы кэшируются во внутренних сетях интернет-провайдеров. Например, возвращаясь на домашнюю страницу LXF, вы получаете изображения обложек и прочие элементы от ближнего прокси, а не от далекого web-сервера, и загрузка идет быстрее. SSL-капсулы – это объекты, непроницаемые для всех промежуточных узлов на пути между сервером и вашим компьютером, так что кэширование невозможно. В итоге – опять же, в некоторых случаях – загрузка web-страниц может замедлиться, что противоречит основному предназначению SPDY.

• Разве SPDY — единственный способ ускорения web-серфинга?

Нет, есть и другие предложения: например, SCTP (Stream Control Transmission Protocol), SST (Structured Stream Transport) и SMUX (http://www.w3.org/TR/WD-mux). Однако, по мнению Google, устранение недостатков HTTP с помощью SPDY гораздо проще организовать и осуществить, чем выполнить преобразование всей транспортной системы (что предлагают остальные проекты).

• Думаете, SPDY прорвется?

Да. То есть, если точные исследования трафика подтвердят первые обнадеживающие результаты и если будет разработана щадящая, гибкая методика конверсии web-серверов. Посмотрим. А пока каждый, у кого есть «представительство» в Интернете, может значительно ускорить web-серфинг. Просто уберите ненужные Flash и JavaScript со своих страниц!

• Где можно узнать о SPDY подробнее?

Лучший источник – официальная информационная статья Google о SPDY: http://www.chromium.org/spdy/spdy-whitepaper.