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

В Arstechnica появилась хорошая статья про SPDYeng — протокол ускорения загрузки веб-страниц который предлагают и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 можно было бы протолкнуть с куда большей вероятностью.

About This Author

  • http://twitter.com/sergey_shepelev Sergey Shepelev

    Про недостатки:
    1. SSL ограничивает *прозрачное* кеширование, да.
    Большая часть контента недоступна по SSL? Это что значит? SSL вообще никак контент не предоставляет. И абсолютно весь контент недоступен по SPDY.
    На сервер, действительно нагрузка больше, на клиенты — я вас умоляю. :)

    2. Там упоминается ускорение в два раза на TCP. По-моему, неплохо.

    3. Может быть, через IETF и «по-хорошему». Но они пишут, что все желающие могут принять участие в обсуждении, предложить свои идеи. Кроме неплохих мозгов в самом гугле, собсно те же ребята из IETF могут присоединиться. Вам важно, чтоб это было именно «через», то есть IETF, как пункт окончательного принятия решений?

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

    Они именно так и пишут. Поэтому меняют HTTP, а не TCP.

    Про альтернативы:
    1. CDN на поисковиках. Это не вместо. Ничто не мешает сделать это совместно с SPDY.

    2. Из SPDY взять идеи. Здесь мы всё-таки согласны :) я б ещё добавил что надо сделать ограничение на заголовок User-Agent в 20 символов.

    3. Механизмы частичного кеширования. Это называется iframe, оно давно есть и работает. Кстати, тоже не вместо, iframe с SPDY тоже будет работать.

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

    Из трех пунктов получается, что два не вместо SPDY, а один берет из SPDY не все улучшения. И эффект будет больше? Где-то тут нестыковка с логикой.

    > а при наличии веса Google можно было бы протолкнуть с куда большей вероятностью.

    А это уже не надо через IETF?

  • http://metin2wiki.ru CSRedRat

    На тему протокола SPDY (т.к. он более эффективен при использовании сетевого протокола SCTP). В связи с этим очень уместно было бы внедрение реализации протокола SCTP (Stream Control Transmission Protocol — «протокол передачи с управлением потоком») в новую версию Windows. Это обеспечит защиту от SYN-flood атак, безопасное установление подключения (с помощью четырёхэтапного квитирования), а также приятные нововведения в виде сохранения границ сообщения, многопоточность, неупорядоченная доставка, поддержка множественных интерфейсов. Внедрение данного протокола позволит вывести сети на новый уровень, увеличить скорость, надёжность, безопасность и возможности передачи данных по сети. Ведь новый протокол создавался с учётом недостатков устаревшего TCP, с учётом современных сетей и полного использования их возможностей, а также особое внимание было уделено надёжности и безопасности.

    Давно пора продвигать протокол SCTP повсеместно! Учитывая нынешнее активное продвижение в сторону IPv6. + массу полезностей из этого извлекает ещё один хороший протокол SPDY. Нельзя тормозить развитие технологий и необходимо проталкивать современные протоколы в массы. Остаётся убедить Microsoft в полезности и необходимости данных протоколов и склонить к их интенсивному внедрению.

Яндекс.Метрика