Spdy протокол

Готовимся к HTTP/2. руководство для веб-дизайнеров и разработчиков

Spdy протокол

Протокол передачи гипертекста (HTTP) управляет соединением между сервером и браузерами. Впервые с 1999 года мы получили новую версию этого протокола, и она обещает существенно более быстрые сайты для всех.

Я расскажу о ключевых особенностях нового протокола, рассмотрю его совместимость с браузерами и серверами.

HTTP – это старый протокол, изначально определённый в 1991 году, и в последний раз серьёзно изменённый в версии HTTP/1.1.

Сайты в 1999 году сильно отличались от тех, которые мы разрабатываем сегодня. Сейчас, чтобы отобразить домашнюю страницу среднего сайта, требуется 1,9 Мб. При этом загружается более 100 отдельных ресурсов, от изображений и шрифтов до файлов JavaScript и CSS.

HTTP/1.1 плохо работает с большим количеством ресурсов. Поэтому лучшие практики оптимизации направлены на повышение производительности этой версии протокола.

В 2009 году два инженера корпорации Google рассказали про исследовательский проект под названием SPDY. Этот проект был нацелен на решение проблем, связанных с работой протокола HTTP/1.1. SPDY позволяет:

  • Использовать конкурирующие запросы в одном соединении TCP (мультиплексирование).
  • Браузерам устанавливать приоритеты так, чтобы ресурсы, важные для отображения страницы, загружались первыми.
  • Сжимать и уменьшать заголовки HTTP
  • Реализовать технологию server push, в рамках которой сервер может пересылать браузеру важные ресурсы, прежде чем его об этом попросят.

В добавление к этому SPDY обязывает шифровать соединение (HTTPS) между браузером и сервером.

SPDY не заменяет HTTP. Он скорее является туннелем для протокола и изменяет процесс отправки запросов и ответов HTTP. Для него обязательна поддержка, как на стороне сервера, так и на стороне клиента. Благодаря поддержке, доступной в NGNIX и пакетах от Google для Apache, SPDY применялся достаточно широко. При этом современные версии основных браузеров поддерживают его в полном объеме.

Поддержка SPDY браузерами по данным «Can I Use»

Поддержка SPDY была прекращена в Edge из-за того, что специалисты Microsoft реализовали в новом браузере поддержку HTTP/2 – последней по времени выхода версии протокола HTTP. Но другие современные браузеры всё ещё сохраняют поддержку SPDY.

Поддержка HTTP/2 браузерами по данным «Can I Use»

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

Требование соединения по HTTPS было отменено. Несмотря на это, разработчики всех браузеров решили реализовать поддержку HTTP/2 только для TLS (https) соединений.

Поэтому использования HTTP/2 подразумевает использование сайтом HTTPS.

Спецификация HTTP/2 была завершена в феврале 2015 года. Спустя год он прекрасно поддерживается браузерами. Так же, как и SPDY, HTTP/2 предполагает поддержку, как в браузере, так и на сервере.

Уже существует много его реализаций для серверов. Вы можете следить за ними в справочнике по HTTP/2.

HTTP/2 обратно совместим с HTTP/1.1, поэтому есть возможность его проигнорировать, и всё продолжит работать, как раньше. Изменение протокола незаметно для пользователей. Многие из читателей этой статьи уже используют протокол, отличный от HTTP/1.1 многие годы. Например, если у вас есть аккаунт в почтовом сервисе Gmail, и вы используете браузер Google Chrome для доступа к нему.

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

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

Для многих ресурсов наиболее сложным при переходе на HTTP/2 может быть вовсе не сам протокол, а требование о работе сайта через защищённое соединение. Если вы разрабатываете новый сайт или обновляете старый, первым шагом должен быть переход на https.

Это важно не только для HTTP/2. Google использует защищённое соединение как сигнал при ранжировании сайта, а браузеры начинают отмечать не https сайты как «небезопасные».

При использовании протокола HTTP/1.1 получение одного большого изображения гораздо более эффективно для браузера, чем совершение множества запросов к маленьким файлам. Чтобы обойти это, можно включить иконки в один спрайт-файл.

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

Благодаря мультиплексированию в HTTP/2 очереди запросов к ресурсам больше не являются проблемой. Предоставление изображений по отдельности лучше по нескольким причинам: нужно будет отправить только то, что запрошено.

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

Другой метод решения проблемы множественных запросов в HTTP/1.1 – встраивание изображений в CSS, используя data URI. Встраивание изображений таким образом сильно увеличивает размер файла стилей.

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

В HTTP/2 эта «лучшая практика» скорее будет вредить, чем улучшать производительность.

На финальной стадии сборки сайта многие соединяют все мелкие файлы CSS и JavaScript, используемые на нем. Мы зачастую разделяем их при разработке, чтобы было легче управлять ими. Но доставка одного файла браузеру более эффективна в плане производительности, чем доставка пяти. И мы снова пытаемся сократить количество HTTP-запросов.

Если вы это делаете, то посетителям придётся загрузить все стили CSS и JavaScript сайта. Можно обойти эту проблему, подключая только определённые файлы для каждой области сайта в процессе его сборки.

Запросы HTTP «дёшевы» в мире HTTP/2. Постраничная организация используемых ресурсов при разработке сайта будет гораздо лучшей идеей. Так можно будет загружать в браузер только тот код, который требуется отображения текущей веб-страницы.

При использовании протокола HTTP/1.1 вы ограничены в количестве одновременно открытых соединений.

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

С его помощью можно сократить время загрузки. Но он может создать проблемы, не говоря уж о затратах на подготовку инфраструктуры сайта.

HTTP/2 устраняет необходимость использования domain sharding: можно запрашивать любое количество ресурсов. Но это навредит производительности: создаются дополнительные соединения TCP, и препятствует расстановке приоритетов в HTTP/2.

Несколько советов, как подготовиться к переходу на HTTP/2.

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

При переходе на HTTP/2 вы получите лучшую производительность при аккуратном управлении ресурсами, когда только то, что требуется определённой странице, отправляется этой странице.

На данный момент лучшая практика для HTTP/1.1 – ограничить разделение двумя именами хостов. В HTTP/2 существует способ объединить эти соединения, если сертификат TLS действителен для обоих хостов и хосты находятся на одном IP-адресе. TLS сертификат необходим для работы через HTTP/2.

В этой статье я не рассказываю о том, как получить преимущество от новых инструментов HTTP/2, таких как server push. Эта технология позволяет решать, какие ресурсы являются приоритетными, и заставляет сервер передавать их перед менее важными ресурсами.

Решение о переходе на HTTP/2 сводится к тому, поддерживается ли этот протокол большинством браузеров ваших пользователей. Помните, что HTTP/2 обратно совместим, поэтому вам не придётся делать ничего особенного.

Если большинство посетителей используют браузеры, поддерживающие HTTP/2, настал момент для оптимизации под этих пользователей. Например, многие преимущества HTTP/2 наиболее остро ощутят пользователи мобильных устройств. Если у вашего сайта большой процент мобильного трафика – это может быть сигналом к переходу на HTTP/2.

  1. Запустите сайт с безопасным соединением или перейдите на TLS прямо сейчас.
  2. Подготовьтесь к HTTP/2 в процессе сборки сайта. Используйте советы, приведенные выше, чтобы создать сайт, оптимизированный под обе версии протокола.
  3. Проверьте хостинг. Удостоверьтесь в том, что ваш сервер поддерживает HTTP/2.
  4. Разверните оптимизацию под HTTP/2. Прекратите использовать устаревшие практики и переходите к применению новых.

После того, как вы перейдёте на HTTP/2, стоит проверить, насколько увеличится скорость вашего сайта.

Растущий объём информации о HTTP/2 доступен в сети. Ниже я перечислила некоторые ресурсы, к которым я обращалась при написании этой статьи.

  • “Hypertext Transfer Protocol Version 2 (HTTP/2)” (спецификация). Это для людей, получающих удовольствие от чтения спецификаций, или тех, кому требуется понимание тонких моментов. Для всех остальных HTTP/2 FAQ – это прекрасный обзор основных функций.
  • Индикатор HTTP/2 и SPDY: Chrome. Этот плагин позволяют узнать, предоставляется ли сайт, на котором вы находитесь, через HTTP/2.

Данная публикация представляет собой перевод статьи «Getting Ready For HTTP/2 A Guide For Web Designers And Developers» , подготовленной дружной командой проекта Интернет-технологии.ру

Источник: https://www.internet-technologies.ru/articles/gotovimsya-k-http-2.html

Почему мы не используем CDN: рассказ про SPDY и SSL

Spdy протокол

Повествование ведется от лица Zack Tollman из компании thethemefoundry.com.

На прошлой неделе мы перешли на SSL-протокол, который был установлен для всего нашего сайта. Мы трепетно подошли к этому моменту, но не обошлось и без некоторого волнения. Мы переживали по поводу того, как это скажется на производительности сайта.

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

Однако после небольшого тестирования различных CDN мы пришли к некоторым неожиданным результатам.

До перехода на CDN

Прежде чем рассказать о том, что произошло с сайтом в плане производительности, давайте взглянем на то, как работал сайт до перехода на CDN.

Здесь нужно отметить несколько важных аспектов. Во-первых, время до получения первого байта (TT) равнялось 205ms. Значение TT – это время поиска DNS (84ms; выделено сине-зеленым цветом) + квитирование связи TCP (95ms; выделено оранжевым цветом) + время до получения первого ответа HTML-заголовка (26ms; выделено ярко-зеленым). Время TT в 205ms является вполне приемлемым, т.е.

мы обслуживаем WordPress действительно быстро и нашего сетевого соединения вполне хватает. Во-вторых, весь сайт загружается за 1600ms (1.6s; синяя линия). У нас имеются некоторые дополнительные скрипты, которые включаются позже, однако они не влияют на создание страницы. В-третьих, обратите внимания на диагональный «водопад». Это прекрасная визуализация данных, загружаемых последовательно.

Современные браузеры могут открывать множество соединений в одно и то же время к одному URL, однако каждое из них требует отдельного TCP-соединения. Это приводит к появлению диагонального «водопада». Наконец, обратите внимание на 6 уникальных оранжевых столбиков до 16 пункта. Эти оранжевые столбцы отражают время, которое требуется браузеру для соединения с сервером.

Как вы можете видеть, времени требуется немного.

Старый сайт будет нашей отправной точкой для измерения производительности нового сайта. К сожалению, мы не можем провести сравнение 1:1 между сайтами, поскольку эти два сервера находятся в разных локациях (Нью-Джерси и Техас).

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

Несмотря на это, я считаю, что те результаты, которые мы имеем, по-прежнему будут интересны.

Почему SSL имеет проблемы с производительностью

Протокол SSL имеет присущие ему проблемы с производительностью. На самом базовом уровне SSL требует дополнительного раундтрипа (приема-передачи пакетов) между сервером и браузером.

Чтобы получить пример того, как SSL влияет на производительность, достаточно взглянуть на изображение выше, где квитирование связи TCP составляет 95ms. По существу это время приема-передачи (RTT) между тестовой локацией (Лос-Анджелес) и сервером (Нью-Джерси).

Согласование SSL требует совершить два дополнительных раундтрипа между сервером и браузером. Таким образом, если бы мы просто применили тщательно настроенную SSL-реализацию к нашим старым серверам, то мы бы получили двойное увеличение времени 95ms x 2 (190ms) на согласование SSL, что в итоге привело бы к увеличению TT на 190 ms.

Кроме того, если ваш сервер не будет корректно настроен, то вы, скорее всего, столкнетесь с дополнительными издержками. В целом, при добавлении SSL важно очень тщательно рассмотреть влияние на производительность.

Готовим Nginx к SSL

Учитывая предупреждения Ilya Grigorik о 5 дополнительных раундтрипах для «ванильной» сборки Nginx, мы воспользовались ручной компиляцией Nginx (основной версии пакета). Мы использовали Nginx 1.5.

9 (чтобы обойти баг с «большим сертификатом»), скомпилировали в OpenSSL 1.0.1e (для включения NPN) и включили Perfect Forward Secrecy (чтобы добавить дополнительную защиту), чтобы число дополнительных раундтрипов было не более 2 при реализации SSL для сайта.

Мы добавили следующие директивы к блоку сервера для нашего сайта:

ssl_protocols             TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers               ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS; ssl_buffer_size           8k;

В первой строке мы объявляем TLS-версии, которые мы поддерживаем. Это позволяет сайту поддерживать широкий спектр защищенных соединений с браузерами. Единственный браузер, который не поддерживается – это IE6, что оказалось для нас вполне приемлемо.

IE6 поддерживает только SSL 3.0 и ниже, который подвержен renegotiation-уязвимости. В следующей строке мы выбираем предпочтительные шифры, используемые для согласования TLS. Мы решили воспользоваться рекомендациями Hynek Schlawack, которые проверены Qualys SSL Labs.

Наконец, мы уменьшаем размер SSL буфера (по умолчанию 16kb), чтобы избежать сценария переполнения буфера, который привел бы к дополнительным раундтрипам в обе стороны.

Наконец, такая реализация показала себя как A в SSL Labs – прекрасном инструменте для изучения вашей реализации SSL.

В ходе настройки сервера мы также убедились в том, что реализовали SPDY в Nginx. SPDY поддерживается Nginx по умолчанию, начиная с версии 1.3.15. Ранние версии Nginx нужно вручную компилировать для поддержки SPDY. SPDY стал отправной точкой для HTTP 2.0.

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

К счастью, прямо перед тем, как мы начали это делать, вышел патч SPDY 3.1, предоставленный Automattic и MaxCDN, и мы смогли перейти к нашей реализации Nginx.

Если вы хотите получить аналогичную сборку Nginx, я рекомендую посмотреть на наши инструкции по компиляции Nginx. Эти инструкции позволяют откомпилировать Nginx с поддержкой PageSpeed и Nginx Cache Purge.

CDN для ускорения

Мы долгое время обдумывали применение CDN на нашем сайте. Мы решили сделать это вместе с вышедшим обновлением. Опять же, мы считали, что добавление улучшения скорости с помощью CDN поможет нам смягчить проблемы с производительностью, вызванные переходом к SSL.

Мы получили действительно интересный опыт, связанный с изучением CDN-провайдеров, о котором мы напишем позже. Для начала мы выбрали MaxCDN, который оказалось действительно легко и быстро установить и настроить.

Мы использовали плагин от Марка Джекита с несколькими изменениями для совместимости с https.

Производительность с CDN

Когда все было сделано, я решил тут же перейти к тестированию сайта.

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

Первое, что нужно отметить: в нашей гонке к TT появился новый цвет. Фиолетовый столбец в пункте 1 отражает SSL-согласование. Мы ожидали, что оно появится. Начальное соединение, которое отражало наше время приема-передачи пакетов, стало равно 57ms, а SSL-согласование заняло 103ms.

Это говорит о том, что мы успешно избежали дополнительных раундтрипов, о которых предостерегал Ilya в своей статье, и остались в районе 1-2 дополнительных раундтрипов, что вполне приемлемо. Если бы мы просто реализовали SSL, то в таком случае наша производительность стала бы хуже из-за 1-2 раундтрипов, что является ожидаемым результатом.

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

К сожалению, здесь присутствуют и другие строки, которые нужно рассмотреть, и они выглядят далеко не идеально. Во второй строке время согласования SSL обеспокоило нас. Эта строка отражает загрузку CSS-файла для нашего сайта с серверов MaxCDN.

Данный запрос включает в себя поиск DNS (76ms; сине-зеленый цвет), TCP-соединение (110ms; оранжевый цвет) и SSL-согласование (429ms; фиолетовый). Обратите внимание, что SSL-согласование вышло примерно в 4 раза дольше, чем начальное TCP-соединение. Ясно, что SSL-согласование настроено не слишком хорошо.

Мы потратили кучу времени, настраивая скорость нашего SSL-соединения, и теперь страдаем от медленного SSL-согласования на CDN. Естественно, мы ждали совсем другого результата от применения CDN.

Что еще нужно добавить по поводу производительности CDN: согласование SSL повторяется три раза (пункты 2-13, 15-16). Кроме того, мы сталкиваемся с дополнительным поиском DNS, что замедляет загрузку наших данных.

К счастью, как я и предполагал, SSL-согласование использует восстановление SSL, что в итоге приводит к заметному ускорению. Наконец, обратите внимание на диагональный «водопад» элементов.

Мы видим тот же самый паттерн загрузки, с которым мы сталкивались в наших начальных тестах еще до запуска сайта.

Если сеть CDN расположена дальше от сервера

Одно из преимуществ использования CDN заключается в том, что для загрузки сайта используются серверы, которые находятся ближе всего к посетителям в физическом плане, что снижает время приема-передачи. Как вы видели, время приема-передачи – очень важная составляющая.

Если вы не можете сократить количество раундтрипов, то, возможно, вы можете снизить время, которое они занимают. CDN способна помочь в этом.

Я решил провести тест из Австралии, чтобы увидеть, как быстро работает наш сайт – сделано это было по той причине, что наш дизайнер, Скотт, живет там, поэтому мне хотелось узнать, как сайт будет работать у него.

Опять же, мы видим значительное время SSL-согласования с нашим сайтом. Время приема-передачи находится в диапазоне 200ms, что напоминает время приема-передачи до наших серверов.

Я надеялся на то, что, даже учитывая плохое начальное время соединения с нашим сайтом, CDN поможет устранить некоторые слабые стороны и передаст данные действительно быстро.

Как оказалось, этого не случилось, поскольку все тормозилось медленным SSL-согласованием и последовательными соединениями.

Без CDN

Получив не самые лучшие результаты при работе с CDN, мы решили посмотреть, как все будет работать вообще без CDN.

Эти результаты поразили меня до глубины души. Мы видим прекрасное время согласования SSL. Далее, для элементов 2-15 (наших данных) вообще отсутствует SSL-согласование или время соединения.

HTTP-мультиплексирование SPDY позволяет всем этим запросам использовать одно и то же TCP-соединение. Нам не нужно открывать дополнительные соединения или SSL-согласования.

Все элементы на странице загружаются примерно за 900ms, что является прекрасным результатом (да, это быстрее, чем в случае со старым сайтом, но здесь и сервер расположен ближе).

Также заметьте, что диагональный поток «водопада» стал меньше. Такая форма вышла из-за того, что SPDY позволяет слать многочисленные HTTP-запросы через одно и то же TCP-соединение. Важно отметить, что в случае использования CDN мы не увидели никаких преимуществ SPDY. Отказавшись от CDN, мы тут же увидели все плюсы повторного использования TCP-соединения и SSL-согласования.

Бесспорно, SPDY несет огромную выгоду для нас. Несмотря на то, что мы теряем 70-90ms на SSL-согласовании, мы также экономим огромное время, которое тратилось раньше на открытие большого количества соединений.

Без CDN в Австралии

Предыдущие результаты оказались очень неожиданными. О такой выгоде нельзя было даже мечтать! Теперь мы должны были принять решение по поводу CDN. Да, производительность CDN не была такой уж прекрасной, однако, возможно, она поможет Скотту из Австралии быстрее работать с сайтом.

Честно говоря, я не ожидал такого результата. Я думал, что CDN будет гораздо лучше, чем SPDY в одной локации. Все наши данные загрузились через CDN чуть менее чем за 5 секунд.

Аналогичное действие через SPDY заняло примерно 2.7s. Производительность без CDN смогла одержать уверенную победу над производительностью с CDN.

В нашем случае вышло так, что в плане скорости преимущества SPDY заметно перевесили плюсы от CDN.

Нужно также сказать, что мы пробовали и другие CDN. К сожалению, мы столкнулись с аналогичными результатами. Мы нашли CDN с лучшим временем SSL-согласования и свели общее время загрузки сайта из Австралии до 4.5s, однако мультиплексирование все равно сработало лучше, чем размещение данных в более близкой физической локации.

Пояснения

Чтобы внести ясность в статью, я хочу сделать некоторые пояснения. В частности:

  • Физические локации нашего старого и нового сервера отличались. Не все тесты проходили на том же самом аппаратном обеспечении, хотя оно было сопоставимо между собой.
  • Все тесты проводились в Chrome, который является самым продвинутым в плане производительности браузером. Примерно 50% наших посетителей используют Chrome, что заметно облегчило нам принятие решения.
  • Мы не рассматривали разнообразные локации по всему миру. Мы сконцентрировались на США и Австралии.
  • Мы тестировали только домашнюю страницу; однако другие страницы могут содержать в себе больше изображений и данных.

Заключение

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

Данные были переданы очень быстро, мы избежали лишних соединений, а также получили выгоду от быстрых SSL-согласований. Скорость – лишь одно из преимуществ CDN.

В нашем случае скорость была единственной целью, которой мы хотели добиться от CDN, но у нас это не вышло.

Оглядываясь назад, можно сказать, что использование SPDY и CDN было достаточно глупым решением. Передавая данные на другой домен, мы действительно теряем все плюсы SPDY.

Изначально я не понимал, какую именно пользу может принести нам SPDY, и лишь после практического применения увидел ее. Было трудно найти CDN-провайдера, использующего SPDY.

Если вы сможете объединить преимущества  SPDY и CDN, то это будет достаточно интересным действием. В теории такое возможно, если провайдер CDN поддерживает SPDY и разрешает SSL для CNAME.

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

Если бы мы не протестировали производительность CDN, то мы бы по-прежнему использовали бы ее, считая, что это позволяет нам поднять производительность, не говоря уже о том, что мы бы платили за сервис, который не приносил бы нам ожидаемой пользы.

Мы рады тому, что наши инвестиции в Nginx и SPDY окупились должным образом!

Источник: thethemefoundry.com/blog

Источник: https://oddstyle.ru/wordpress-2/stati-wordpress/pochemu-my-ne-ispolzuem-cdn-rasskaz-pro-spdy-i-ssl.html

Протокол SPDY – капитальный ремонт Интернета

Spdy протокол

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

Протокол HTTP 1.0 появился практически одновременно с Интернетом в его современном виде, в далеком 1996 году. Год спустя была утверждена обновленная версия HTTP 1.1, и с тех пор, в течение 15 лет, возможно, самое значимое изобретение человечества базируется на технологии, которую по всем критериям следует назвать устаревшей.

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

Изначально поддержка нового стандарта появилась именно в Chrome, а чуть позже о его поддержке заявили и в Mozilla, внедрив SPDY в Firefox 11.

Остальные компании пока молчат, но почти нет сомнений в том, что Opera Software, как один из самых прогрессивных разработчиков, вскоре присоединится к Google и Mozilla, а вот Apple и Microsoft, наоборот, могут начать свои закулисные игры.

Особенно это касается Microsoft, поскольку в Редмонде разрабатывают собственный протокол Microsoft S+M (Microsoft Speed + Mobility), во многих аспектах напоминающий SPDY и точно так же претендующий на то, чтобы стать основой протокола HTTP 2.0.

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

Демонстрируемые протоколом результаты постоянно улучшаются, и если около года назад прямое сравнение скорости HTTP и SPDY показывало 30% разницу в производительности, то сейчас говорят уже о 64%, хотя  изначально ставилась более скромная цель – 50% сокращение задержек.

Чтобы понять, почему HTTP тормозит развитие Интернета и требует замены, необходимо перечислить недостатки этого протокола:

• HTTP отправляет лишь один запрос по каналу соединения. Браузеры со временем научились обходить это ограничение и сейчас могут использовать сразу несколько параллельных соединений (как правило, 6 штук), однако это не решает проблему полностью.

• Пока браузер на компьютере пользователя не отправит запрос, сервер не сможет выслать необходимые данные, даже если известно, что они необходимы на клиентской стороне.

• Заголовки запросов и ответов в HTTP не сжимаются, что ведет к увеличению задержек, особенно заметных на медленных соединениях. Размер заголовка,как правило, находится в пределах от 0.2 до 2 КБ, при типичном значении в 0.7 КБ.

• Некоторые заголовки отправляются постоянно (User-Agent, Host), хотя, как правило, они не меняются в рамках одной сессии и лишь зря засоряют пропускной канал.

• HTTP использует лишь опциональную компрессию, в то время как ее следует применять постоянно.

К достоинствам SPDY относятся следующие пункты:

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

• Простая установка. Модификация требуется лишь в браузере и веб-сервере, а сам протокол умеет использовать старую сетевую инфраструктуру, поскольку на базовом уровне SPDY по-прежнему работает поверх TCP. Изменения в коде страниц также не нужны.

• Неограниченное количество запросов по ограниченному каналу приводит к тому, что в результате ни одно приложение не получает необходимые данные вовремя. Поэтому в SPDY реализована система приоритетов, позволяющая передавать критически важные данные в первую очередь.

• Снижение веб-трафика достигается за счет использования компрессии заголовков и удаления ненужных данных. Это позволяет уменьшать размер заголовков запросов на 88%, а заголовков ответов – на 85%, чего уже достаточно для значительного ускорения загрузки страниц на медленных соединениях.

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

• Учитывая то, что SPDY отправляет на 40% меньше пакетов по сравнению с HTTP и использует меньше TCP-соединений, вероятность потери и повторной отправки пакетов также снижается. В случаях неудачной доставки пакетов SPDY быстрее HTTP на 27% при прочих равных.

• Возможность передачи данных сервером даже до поступления запроса от клиента также приводит к снижению задержек.

Как проверить, активен ли SPDY на конкретном сайте

Чтобы каждый раз не открывать скрытые настройки браузера для проверки используемого протокола, можно использовать SPDY Indicator – расширение для Chrome и Firefox, отображающее тип соединения, установленного между сайтом и браузером. Если SPDY активен, то иконка SPDY Indicator становится зеленой.

Поддерживаемые ресурсы

На текущий момент поддержка SPDY реализована лишь на нескольких крупных сайтах: Gmail, Google, GooglePlus, , . Однако учитывая, что в апреле 2012 года Google выпустила mod_spdy для Apache, даже небольшие веб-сайты, работающие на этом веб-сервере, могут переходить на SPDY и использовать все его преимущества.

Одним из ранних адептов SPDY является и Amazon. Браузер Silk, установленный в AmazonKindleFire, использует SPDY для соединения с серверами AmazonElasticComputeCloud.

Тестирование скорости

Поскольку Google все еще лишь планирует выпустить специальные инструменты для тестирования производительности SPDY, для самостоятельной проверки пришлось искать другие способы.
В результате было найдено расширение Page Benchmarker для Chrome, для работы которого браузер необходимо запускать с ключом —enable-benchmarking.

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

Проверка проводилась на сайтах .com, Google.com.ua, .com, Gmail.com.

В каждом случае с помощью SPDY Indicator предварительно проводилась проверка поддержки SPDY указанными сайтами.

Page Benchmarker в обязательном порядке требует, чтобы введенный url страницы точно совпадал с тем, что откроет браузер, поэтому если на сайте используется редирект, то бенчмарк вылетает с ошибкой.

Именно этим объясняется использование локальной версии поисковика Google, а также наличие или отсутствие приставки www в разных адресах.

Для Gmail и вовсе пришлось предварительно авторизироваться и указать столь хитрый url, без которого Page Benchmarker наотрез отказывался работать.

Последним и также обязательным условием для запуска Page Benchmarker является использование протокола https. В принципе это уже зависит от настроек браузера, но по умолчанию Chrome запрещает использование SPDY, если передача данных происходит по незащищенному соединению (http).

Используя дефолтные настройки, тест запускался несколько раз с отключенным и включенным SPDY для каждого url. Разработчики расширения не особо потрудились описать его возможности, но в колонке totalloadmean отображается время в миллисекундах, потраченное на загрузку и рендеринг страницы.

Для наглядности — эти же данные в виде диаграммы. Время загрузки сайтов в миллисекундах (меньше – лучше):

Как это ни странно, но положительные результаты в тестах были получены только для Gmail, где SPDY уменьшал время загрузки страницы в среднем на 23%, с 1205 до 930 мс. Для разница была практически незаметна и составляла всего 3%, причем не в пользу SPDY.

На титульная страница начала грузиться дольше на 12.5%, а на google.com.ua – и вовсе на 32%, что явно демонстрирует тот факт, что не все так хорошо на практике, как в теории, и SPDY еще требуется определенная доработка перед релизом.

Источник: https://itc.ua/articles/protokol-spdy-kapitalnyiy-remont-interneta/

Обзор протокола SPDY

Spdy протокол

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

Другими словами, уже сейчас около половины пользователей Интернета используют браузер, поддерживающий самый новый стандарт передачи данных, на который сайты только-только начинают переходить.
Протокол HTTP 1.0 появился практически одновременно с Интернетом в его современном виде, в далеком 1996 году. Год спустя была утверждена обновленная версия HTTP 1.

1, и с тех пор, в течение 15 лет, возможно, самое значимое изобретение человечества базируется на технологии, которую по всем критериям следует назвать устаревшей.SPDY также не является новой разработкой, однако возраст этого стандарта исчисляется лишь несколькими годами. В Google начали работу над ним около двух с половиной лет назад.

Изначально поддержка нового стандарта появилась именно в Chrome, а чуть позже о его поддержке заявили и в Mozilla, внедрив SPDY в Firefox 11. Остальные компании пока молчат, но почти нет сомнений в том, что Opera Software, как один из самых прогрессивных разработчиков, вскоре присоединится к Google и Mozilla, а вот Apple и Microsoft, наоборот, могут начать свои закулисные игры.

Особенно это касается Microsoft, поскольку в Редмонде разрабатывают собственный протокол Microsoft S+M (Microsoft Speed + Mobility), во многих аспектах напоминающий SPDY и точно так же претендующий на то, чтобы стать основой протокола HTTP 2.0.

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

Демонстрируемые протоколом результаты постоянно улучшаются, и если около года назад прямое сравнение скорости HTTP и SPDY показывало 30% разницу в производительности, то сейчас говорят уже о 64%, хотя  изначально ставилась более скромная цель – 50% сокращение задержек.

 Чтобы понять, почему HTTP тормозит развитие Интернета и требует замены, необходимо перечислить недостатки этого протокола:• HTTP отправляет лишь один запрос по каналу соединения. Браузеры со временем научились обходить это ограничение и сейчас могут использовать сразу несколько параллельных соединений (как правило, 6 штук), однако это не решает проблему полностью.

• Пока браузер на компьютере пользователя не отправит запрос, сервер не сможет выслать необходимые данные, даже если известно, что они необходимы на клиентской стороне.• Заголовки запросов и ответов в HTTP не сжимаются, что ведет к увеличению задержек, особенно заметных на медленных соединениях. Размер заголовка,как правило, находится в пределах от 0.2 до 2 КБ, при типичном значении в 0.7 КБ.

• Некоторые заголовки отправляются постоянно (User-Agent, Host), хотя, как правило, они не меняются в рамках одной сессии и лишь зря засоряют пропускной канал.• HTTP использует лишь опциональную компрессию, в то время как ее следует применять постоянно. К достоинствам SPDY относятся следующие пункты:• Снижение времени загрузки страницы.

В одном соединении можно отправлять неограниченное количество запросов, что существенно повышает эффективность и скорость передачи данных.• Простая установка. Модификация требуется лишь в браузере и веб-сервере, а сам протокол умеет использовать старую сетевую инфраструктуру, поскольку на базовом уровне SPDY по-прежнему работает поверх TCP. Изменения в коде страниц также не нужны.

• Неограниченное количество запросов по ограниченному каналу приводит к тому, что в результате ни одно приложение не получает необходимые данные вовремя. Поэтому в SPDY реализована система приоритетов, позволяющая передавать критически важные данные в первую очередь.• Снижение веб-трафика достигается за счет использования компрессии заголовков и удаления ненужных данных.

Это позволяет уменьшать размер заголовков запросов на 88%, а заголовков ответов – на 85%, чего уже достаточно для значительного ускорения загрузки страниц на медленных соединениях.• Добавление прослойки в виде SSL-протокола обеспечивает надежную защиту передаваемых данных. Использование безопасного соединения немного снижает эффективность SPDY, однако даже в этом случае он оказывается экономнее и быстрее HTTP.• Учитывая то, что SPDY отправляет на 40% меньше пакетов по сравнению с HTTP и использует меньше TCP-соединений, вероятность потери и повторной отправки пакетов также снижается. В случаях неудачной доставки пакетов SPDY быстрее HTTP на 27% при прочих равных.• Возможность передачи данных сервером даже до поступления запроса от клиента также приводит к снижению задержек. 

Как проверить, активен ли SPDY на конкретном сайте

Чтобы каждый раз не открывать скрытые настройки браузера для проверки используемого протокола, можно использовать SPDY Indicator – расширение для Chrome и Firefox, отображающее тип соединения, установленного между сайтом и браузером. Если SPDY активен, то иконка SPDY Indicator становится зеленой.
Поддерживаемые ресурсы

На текущий момент поддержка SPDY реализована лишь на нескольких крупных сайтах: Gmail, Google, GooglePlus, , .

Однако учитывая, что в апреле 2012 года Google выпустила mod_spdy для Apache, даже небольшие веб-сайты, работающие на этом веб-сервере, могут переходить на SPDY и использовать все его преимущества.Одним из ранних адептов SPDY является и Amazon.

Браузер Silk, установленный в AmazonKindleFire, использует SPDY для соединения с серверами AmazonElasticComputeCloud.

Тестирование скорости

Поскольку Google все еще лишь планирует выпустить специальные инструменты для тестирования производительности SPDY, для самостоятельной проверки пришлось искать другие способы.

В результате было найдено расширение Page Benchmarker для Chrome, для работы которого браузер необходимо запускать с ключом –enable-benchmarking.

Page Benchmarker умеет загружать указанные через запятую сайты заданное количество раз, после чего отображает среднее время, необходимое для их открытия. Наличие опции очистки кэша и сброса соединений позволяет уравнять условия для каждой итерации, что приводит к более точным результатам.Проверка проводилась на сайтах .com, Google.com.ua, .com, Gmail.com.В каждом случае с помощью SPDY Indicator предварительно проводилась проверка поддержки SPDY указанными сайтами.Page Benchmarker в обязательном порядке требует, чтобы введенный url страницы точно совпадал с тем, что откроет браузер, поэтому если на сайте используется редирект, то бенчмарк вылетает с ошибкой. Именно этим объясняется использование локальной версии поисковика Google, а также наличие или отсутствие приставки www в разных адресах. Для Gmail и вовсе пришлось предварительно авторизироваться и указать столь хитрый url, без которого Page Benchmarker наотрез отказывался работать.Последним и также обязательным условием для запуска Page Benchmarker является использование протокола https. В принципе это уже зависит от настроек браузера, но по умолчанию Chrome запрещает использование SPDY, если передача данных происходит по незащищенному соединению (http).Используя дефолтные настройки, тест запускался несколько раз с отключенным и включенным SPDY для каждого url. Разработчики расширения не особо потрудились описать его возможности, но в колонке totalloadmean отображается время в миллисекундах, потраченное на загрузку и рендеринг страницы.Для наглядности – эти же данные в виде диаграммы. Время загрузки сайтов в миллисекундах (меньше – лучше):Как это ни странно, но положительные результаты в тестах были получены только для Gmail, где SPDY уменьшал время загрузки страницы в среднем на 23%, с 1205 до 930 мс. Для разница была практически незаметна и составляла всего 3%, причем не в пользу SPDY.

На титульная страница начала грузиться дольше на 12.5%, а на google.com.ua – и вовсе на 32%, что явно демонстрирует тот факт, что не все так хорошо на практике, как в теории, и SPDY еще требуется определенная доработка перед релизом.

Ключевые  SPDY протокол Предыдущая публикация Следующая публикация

Wix.com – бесплатное создание сайта

Реклама 2

DropboxSEO сервисыКак отключить или удалить плагин в браузере

Источник: https://webtun.com/others/3041-obzor-protokola-spdy.html

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.