Про SPDY и ускорение Web’а

В Arstechnica появилась хорошая статья про SPDY^eng — протокол ускорения загрузки веб-страниц который предлагают иccледователи из Google.

SPDY — это протокол расширяющий и дополняющий HTTP таким образом чтобы убрать из него все неоднозначности, вроде того что статус в ответе описан иначе чем остальные поля и сжатие запросов и ответов и так далее.  Подробнее можно прочитать здесь — http://dev.chromium.org/spdy

При том что действительно, тема интересная важная и так далее, а Google при его массе и скорости может эту идею даже протолкнуть, на самом деле всё несколько сложнее. Собственно в статье в Arstecnica это изложено:

1. Сейчас SPDY работает только поверх сессий SSL что во-первых ограничивает кеширование данных, а во вторых не повлияет на то что большая часть контента в публичной части сети доступно не по SSL, и в третьих использование SSL априори создаёт дополнительную нагрузку на ресурсы клиента и сервера что также ограничивает применимость.

2. Протокол SCTP который там уже упоминается всё ещё в весьма зачаточном состоянии, примерно как IPv6, но IPv6 всё таки активно продвигается на страхе что адреса IPv4 скоро закончатся, а вот для SCTP такой мотивации нет, а изменений потребуется не меньше. В то же время без SCTP эффект от SPDY поверх TCP будет невелик.

3. По хорошему новый протокол бы надо обсуждать через IETF и прежде чем его активно продвигать, понять востребован ли будет он на рынке, да и вообще оценить нет ли там чего-либо неучтенного.

На мой взгляд подход должен быть иным — не подмена протокола, а организаций кеширования, prefetching и реорганизация контента под блочное кеширование.

А то есть менять надо не транспортный протокол который затронет операционные системы, сетевое оборудование, IDS системы, фаерволы, антивирусы и прочая, прочая.

Вместо этого можно поступить так:

1. Поисковики могут создавать свои CDN’ы и начать заключать договора с крупнейшими хостингами чтобы те предлагали их CDN своим клиентам по умолчанию и на бесплатной основе, а также заманивать владельцев сайтов в эти CDN за счет ускорения отклика от сайта что позволит и повысить удобство посетителям сайтов, так и позволит поисковикам собирать информацию быстрее. А где-то и в реальном времени.

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

3. Предложить механизмы, программы, продукты и так далее кеширования отдельных участков веб страниц и интегрировать эту информацию на уровне HTTP протокола. То есть создать возможность при запросе веб-страницы или любого иного документа с комплексным содержимым возвращать не один ETag код, а несколько хэшей/идентификаторов блоков, но не более 20 блоков. Далее с помощью расширения к HTTP запрашивать о том не изменились ли отдельные или все блоки и в результате получать не всю страницу или подтверждения что она не менялась, а статус частично изменено и данные только изменившихся блоков склейка которых происходит уже на клиенте.

Это в принципе не так уж сложно сделать, а эффект будет куда больше, поскольку это позволит локализовать статические куски контента при обновлении страниц, а, при некотором развитии этого подхода, распространять кеширование с одной страницы на их группы.

Например, если блок футера на страницах сайта является статическим, то он может быть включён в перечень таких глобально кешируемых участков и применятся также как применяются Cookie к определённому пути.

Да, это немного усложнит и увеличит HTTP запросы от клиента, но в любом случае себя оправдает, а при наличии веса Google можно было бы протолкнуть с куда большей вероятностью.