Путь к HTTP/2 / Habr

От переводчика: перед вами краткий обзор протокола HTTP и его истории — от версии 0.9 к версии 2.

HTTP — протокол, пронизывающий веб. Знать его обязан каждый веб-разработчик. Понимание работы HTTP поможет вам делать более качественные веб-приложения.

В этой статье мы обсудим, что такое HTTP, и как он стал именно таким, каким мы видим его сегодня.

Что такое HTTP?

Итак, рассмотрим для начала, что же такое HTTP? HTTP — протокол прикладного уровня, реализованный поверх протокола TCP/IP. HTTP определяет, как взаимодействуют между собой клиент и сервер, как запрашивается и передаётся контент по интернету. Под протоколом прикладного уровня я понимаю, что это лишь абстракция, стандартизующая, как узлы сети (клиенты и серверы) взаимодействуют друг с другом. Сам HTTP зависит от протокола TCP/IP, позволяющего посылать и отправлять запросы между клиентом и сервером. По умолчанию используется 80 порт TCP, но могут использоваться и другие. HTTPS, например, использует 443 порт.

HTTP/0.9 — первый стандарт (1991)

Первой задокументированной версией HTTP стал HTTP/0.9, выпущенный в 1991 году. Это был самый простой протокол на свете, c одним-единственным методом — GET. Если клиенту нужно было получить какую-либо страницу на сервере, он делал запрос:

GET /index.html

А от сервера приходил примерно такой ответ:

(response body)
(connection closed)

Вот и всё. Сервер получает запрос, посылает HTML в ответ, и как только весь контент будет передан, закрывает соединение. В HTTP/0.9 нет никаких заголовков, единственный метод — GET, а ответ приходит в HTML.

Итак, HTTP/0.9 стал первым шагом во всей дальнейшей истории.

HTTP/1.0 — 1996

В отличие от HTTP/0.9, спроектированного только для HTML-ответов, HTTP/1.0 справляется и с другими форматами: изображения, видео, текст и другие типы контента. В него добавлены новые методы (такие, как POST и HEAD). Изменился формат запросов/ответов. К запросам и ответам добавились HTTP-заголовки. Добавлены коды состояний, чтобы различать разные ответы сервера. Введена поддержка кодировок. Добавлены составные типы данных (multi-part types), авторизация, кэширование, различные кодировки контента и ещё многое другое.

Вот так выглядели простые запрос и ответ по протоколу HTTP/1.0:

GET / HTTP/1.0
Host: kamranahmed.info
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

Помимо запроса клиент посылал персональную информацию, требуемый тип ответа и т.д. В HTTP/0.9 клиент не послал бы такую информацию, поскольку заголовков попросту не существовало.

Пример ответа на подобный запрос:

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

(response body)
(connection closed)

В начале ответа стоит HTTP/1.0 (HTTP и номер версии), затем код состояния — 200, затем — описание кода состояния.

В новой версии заголовки запросов и ответов были закодированы в ASCII (HTTP/0.9 весь был закодирован в ASCII), а вот тело ответа могло быть любого контентного типа — изображением, видео, HTML, обычным текстом и т. п. Теперь сервер мог послать любой тип контента клиенту, поэтому словосочетание «Hyper Text» в аббревиатуре HTTP стало искажением. HMTP, или Hypermedia Transfer Protocol, пожалуй, стало бы более уместным названием, но все к тому времени уже привыкли к HTTP.

Один из главных недостатков HTTP/1.0 — то, что вы не можете послать несколько запросов во время одного соединения. Если клиенту надо что-либо получить от сервера, ему нужно открыть новое TCP-соединение, и, как только запрос будет выполнен, это соединение закроется. Для каждого следующего запроса нужно создавать новое соединение.

Почему это плохо? Давайте предположим, что вы открываете страницу, содержащую 10 изображений, 5 файлов стилей и 5 JavaScript файлов. В общей сложности при запросе к этой странице вам нужно получить 20 ресурсов — а это значит, что серверу придётся создать 20 отдельных соединений. Такое число соединений значительно сказывается на производительности, поскольку каждое новое TCP-соединение требует «тройного рукопожатия», за которым следует медленный старт.

Тройное рукопожатие

«Тройное рукопожатие» — это обмен последовательностью пакетов между клиентом и сервером, позволяющий установить TCP-соединение для начала передачи данных.

• SYN — Клиент генерирует случайное число, например, x, и отправляет его на сервер.
• SYN ACK — Сервер подтверждает этот запрос, посылая обратно пакет ACK, состоящий из случайного числа, выбранного сервером (допустим, y), и числа x + 1, где x — число, пришедшее от клиента.
• ACK — клиент увеличивает число y, полученное от сервера и посылает y + 1 на сервер.

Примечание переводчика: SYN — синхронизация номеров последовательности, (англ. Synchronize sequence numbers). ACK — поле «Номер подтверждения» задействовано (англ. Acknowledgement field is significant).

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

Тем не менее, некоторые реализации HTTP/1.0 старались преодолеть эту проблему, добавив новый заголовок Connection: keep-alive, который говорил бы серверу «Эй, дружище, не закрывай это соединение, оно нам ещё пригодится». Однако эта возможность не была широко распространена, поэтому проблема оставалась актуальна.

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

HTTP/1.1 – 1999

Прошло 3 года со времён HTTP/1.0, и в 1999 вышла новая версия протокола — HTTP/1.1, включающая множество улучшений:

• Новые HTTP-методы — PUT, PATCH, HEAD, OPTIONS, DELETE.
• Идентификация хостов. В HTTP/1.0 заголовок Host не был обязательным, а HTTP/1.1 сделал его таковым.
• Постоянные соединения. Как говорилось выше, в HTTP/1.0 одно соединение обрабатывало лишь один запрос и после этого сразу закрывалось, что вызывало серьёзные проблемы с производительностью и проблемы с задержками. В HTTP/1.1 появились постоянные соединения, т.е. соединения, которые по умолчанию не закрывались, оставаясь открытыми для нескольких последовательных запросов. Чтобы закрыть соединение, нужно было при запросе добавить заголовок Connection: close. Клиенты обычно посылали этот заголовок в последнем запросе к серверу, чтобы безопасно закрыть соединение.
• Потоковая передача данных, при которой клиент может в рамках соединения посылать множественные запросы к серверу, не ожидая ответов, а сервер посылает ответы в той же последовательности, в которой получены запросы. Но, вы можете спросить, как же клиент узнает, когда закончится один ответ и начнётся другой? Для разрешения этой задачи устанавливается заголовок Content-Length, с помощью которого клиент определяет, где заканчивается один ответ и можно ожидать следующий.

Замечу, что для того, чтобы ощутить пользу постоянных соединений или потоковой передачи данных, заголовок Content-Length должен быть доступен в ответе. Это позволит клиенту понять, когда завершится передача и можно будет отправить следующий запрос (в случае обычных последовательных запросов) или начинать ожидание следующего ответа (в случае потоковой передачи).

• Chunked Transfers если контент строится динамически и сервер в начале передачи не может определить Content-Length, он начинает отсылать контент частями, друг за другом, и добавлять Content-Length к каждой передаваемой части. Когда все части отправлены, посылается пустой пакет с заголовком Content-Length, установленным в 0, сигнализируя клиенту, что передача завершена. Чтобы сказать клиенту, что передача будет вестись по частям, сервер добавляет заголовок
  Transfer-Encoding: chunked.
• В отличие от базовой аутентификации в HTTP/1.0, в HTTP/1.1 добавились дайджест-аутентификация и прокси-аутентификация.
• Кэширование.
• Диапазоны байт (byte ranges).
• Кодировки
• Согласование содержимого (content negotiation).
• Клиентские куки.
• Улучшенная поддержка сжатия.
• И другие…

Особенности HTTP/1.1 — отдельная тема для разговора, и в этой статье я не буду задерживаться на ней надолго. Вы можете найти огромное количество материалов по этой теме. Рекомендую к прочтению Key differences between HTTP/1.0 and HTTP/1.1 и, для супергероев, ссылку на RFC.

HTTP/1.1 появился в 1999 и пробыл стандартом долгие годы. И, хотя он и был намного лучше своего предшественника, со временем начал устаревать. Веб постоянно растёт и меняется, и с каждым днём загрузка веб-страниц требует всё больших ресурсов. Сегодня стандартной веб-странице приходится открывать более 30 соединений. Вы скажете: «Но… ведь… в HTTP/1.1 существуют постоянные соединения…». Однако, дело в том, что HTTP/1.1 поддерживает лишь одно внешнее соединение в любой момент времени. HTTP/1.1 пытался исправить это потоковой передачей данных, однако это не решало задачу полностью. Возникала проблема блокировки начала очереди (

SPDY — 2009

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

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

Следует пояснить, в чём разница: время задержки — величина, показывающая, сколько времени займёт передача данных от отправителя к получателю (в миллисекундах), а пропускная способность — количество данных, переданных в секунду (бит в секунду).

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

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

В 2015 в Google решили, что не должно быть двух конкурирующих стандартов, и объединили SPDY с HTTP, дав начало HTTP/2.

HTTP/2 — 2015

Думаю, вы уже убедились, что нам нужна новая версия HTTP-протокола. HTTP/2 разрабатывался для транспортировки контента с низким временем задержки. Главные отличия от HTTP/1.1:

• бинарный вместо текстового
• мультиплексирование — передача нескольких асинхронных HTTP-запросов по одному TCP-соединению
• сжатие заголовков методом HPACK
• Server Push — несколько ответов на один запрос
• приоритизация запросов
• безопасность

1. Бинарный протокол

HTTP/2 пытается решить проблему выросшей задержки, существовавшую в HTTP/1.x, переходом на бинарный формат. Бинарные сообщения быстрее разбираются автоматически, но, в отличие от HTTP/1.x, не удобны для чтения человеком. Основные составляющие HTTP/2 — фреймы (Frames) и потоки (Streams).

Фреймы и потоки.

Сейчас HTTP-сообщения состоят из одного или более фреймов. Для метаданных используется фрейм HEADERS, для основных данных — фрейм DATA, и ещё существуют другие типы фреймов (RST_STREAM, SETTINGS, PRIORITY и т.д.), с которыми можно ознакомиться в спецификации HTTP/2.

Каждый запрос и ответ HTTP/2 получает уникальный идентификатор потока и разделяется на фреймы. Фреймы представляют собой просто бинарные части данных. Коллекция фреймов называется потоком (Stream). Каждый фрейм содержит идентификатор потока, показывающий, к какому потоку он принадлежит, а также каждый фрейм содержит общий заголовок. Также, помимо того, что идентификатор потока уникален, стоит упомянуть, что каждый клиентский запрос использует нечётные id, а ответ от сервера — чётные.

Помимо HEADERS и DATA, стоит упомянуть ещё и RST_STREAM — специальный тип фреймов, использующийся для прерывания потоков. Клиент может послать этот фрейм серверу, сигнализируя, что данный поток ему больше не нужен. В HTTP/1.1 единственным способом заставить сервер перестать посылать ответы было закрытие соединения, что увеличивало время задержки, ведь нужно было открыть новое соединение для любых дальнейших запросов. А в HTTP/2 клиент может отправить RST_STREAM и перестать получать определённый поток. При этом соединение останется открытым, что позволяет работать остальным потокам.

2. Мультиплексирование

Поскольку HTTP/2 является бинарным протоколом, использующим для запросов и ответов фреймы и потоки, как было упомянуто выше, все потоки посылаются в едином TCP-соединении, без создания дополнительных. Сервер, в свою очередь, отвечает аналогичным асинхронным образом. Это значит, что ответ не имеет порядка, и клиент использует идентификатор потока, чтобы понять, к какому потоку принадлежит тот или иной пакет. Это решает проблему блокировки начала очереди (head-of-line blocking) — клиенту не придётся простаивать, ожидая обработки длинного запроса, ведь во время ожидания могут обрабатываться остальные запросы.

3. Сжатие заголовков методом HPACK

Это было частью отдельного RFC, специально нацеленного на оптимизацию отправляемых заголовков. В основе лежало то, что если мы постоянного обращаемся к серверу из одного и того же клиента, то в заголовках раз за разом посылается огромное количество повторяющихся данных. А иногда к этому добавляются ещё и куки, раздувающие размер заголовков, что снижает пропускную способность сети и увеличивает время задержки. Чтобы решить эту проблему, в HTTP/2 появилось сжатие заголовков.

В отличие от запросов и ответов, заголовки не сжимаются в gzip или подобные форматы. Для сжатия используется иной механизм — литеральные значения сжимаются по алгоритму Хаффмана, а клиент и сервер поддерживают единую таблицу заголовков. Повторяющиеся заголовки (например, user agent) опускаются при повторных запросах и ссылаются на их позицию в таблице заголовков.

Раз уж зашла речь о заголовках, позвольте добавить, что они не отличаются от HTTP/1.1, за исключением того, что добавилось несколько псевдозаголовков, таких как :method, :scheme, :host, :path и прочие.

4. Server Push

Server push — ещё одна потрясающая особенность HTTP/2. Сервер, зная, что клиент собирается запросить определённый ресурс, может отправить его, не дожидаясь запроса. Вот, например, когда это будет полезно: браузер загружает веб-страницу, он разбирает её и находит, какой ещё контент необходимо загрузить с сервера, а затем отправляет соответствующие запросы.

Server push позволяет серверу снизить количество дополнительных запросов. Если он знает, что клиент собирается запросить данные, он сразу их посылает. Сервер отправляет специальный фрейм PUSH_PROMISE, говоря клиенту: «Эй, дружище, сейчас я тебе отправлю вот этот ресурс. И не надо лишний раз беспокоить.» Фрейм PUSH_PROMISE связан с потоком, который вызвал отправку push-а, и содержит идентификатор потока, по которому сервер отправит нужный ресурс.

5. Приоритизация запросов

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

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

6. Безопасность

Насчёт того, должна ли безопасность (передача поверх протокола TLS) быть обязательной для HTTP/2 или нет, развилась обширная дискуссия. В конце концов было решено не делать это обязательным. Однако большинство производителей браузеров заявило, что они будут поддерживать HTTP/2 только тогда, когда он будет использоваться поверх TLS. Таким образом, хотя спецификация не требует шифрования для HTTP/2, оно всё равно станет обязательным по умолчанию. При этом HTTP/2, реализованный поверх TLS, накладывает некоторые ограничения: необходим TLS версии 1.2 или выше, есть ограничения на минимальный размер ключей, требуются эфемерные ключи и так далее.

Заключение

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

HTTP/2 может многое предложить для увеличения производительности, и, похоже, самое время начать его использовать.

Оригинал: Journey to HTTP/2, автор Kamran Ahmed.

Перевод: Андрей Алексеев, редактура: Анатолий Тутов, Jabher, Игорь Пелехань, Наталья Ёркина, Тимофей Маринин, Чайка Чурсина, Яна Крикливая.

Протокол HTTP. Что такое незащищенный протокол HTTP?

HTTP (HyperText Transfer Protocol) — протокол передачи гипертекста. Его разработали в 1992 году для передачи гипертекстовых HTML-документов, но сегодня задействуют для работы с самыми разными данными. Гипертекст — это текст с гиперссылками: нажав на них, вы можете получить новые страницы или другие ресурсы.

Для пересылки данных HTTP использует протокол TCP. В то же время HTTP-протокол выступает основой и транспорта для других прикладных протоколов. К примеру, SOAP, XML-RPC, WebDAV.

Как работает HTTP

HTTP работает на основе клиент-серверной архитектуры. Клиент — это потребитель, который инициирует установку соединения и отправляет запрос серверу. Сервер ожидает соединения, чтобы получить запрос. Затем он обрабатывает данные из запроса и возвращает результат обработки в ответном сообщении. В ответе сервер может передать документ, который включает поддокументы, отдельно представленную структуру, скрипты, фото, видео и другие данные. Между запросом и ответом может быть цепочка посредников (прокси и др.).

Запросы обычно передает веб-браузер. Но такие задачи нередко возлагают на ботов, которые сканируют страницы веб-ресурсов для обновления данных. К примеру, обходом страниц занимаются поисковые роботы для индексации для поисковых систем.

В клиентском запросе обязательно содержится URI (Uniform Resource Identifier). Он указывает на определенный ресурс: файл на сервере, логический или абстрактный объект. Клиент может указать в запросе, а сервер — в ответе представление ресурса по разным параметрам: языку, кодировке, формату. Для этого используются заголовки HTTP-запросов.

Самое важное здесь — возможность указать двоичное представление. Благодаря этому, собственно, HTTP протокол позволяет передавать не только гипертекст, но и двоичные данные.

HTTP-протокол не сохраняет своего состояния между запросом и ответом. Поэтому для сохранения данных приходится задействовать дополнительные инструменты — сессии на сервере и cookies на стороне клиента. Кроме того, сервер может хранить заголовки HTTP-запросов и IP-адреса клиентов. Но протокол сам по себе не знает, какие запросы отправлялись и принимались ранее.

Почему HTTP небезопасен

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

Именно поэтому на смену HTTP приходит HTTPS (HTTP + security, безопасность). Этот протокол предполагает шифрование данных.

HTTPS работает на транспортном уровне, тогда как HTTP — на прикладном. Таким образом, транспортный уровень, на котором выполняется управление соединениями, выходит за пределы HTTP-протокола.

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

Кроме того, HTTP-протокол позволяет подменить данные на пути от сервера к браузеру. В результате вы можете увидеть в браузере совсем не то, что ожидали. Или получить вредонос вместо безобидной картинки.

Также HTTPS требует подтверждение домена. Хакеры не смогут подменить домен, чтобы перехватывать данные из запросов.

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

В то же время для перехода на HTTPS требуется получить SSL-сертификат. Это платная услуга, и многие владельцы небольших сайтов отказываются от неё (а значит, и от перехода на HTTPS), а значит, ставят данные пользователей под угрозу.

Стандарты HTTP протокола. Версии HTTP протокола и их особенности

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. В данной записи мы познакомимся со стандартами HTTP протокола, где их искать и что дадут нам эти стандарты, рассматривая стандарты HTTP, мы невольно затронем историю развития протокола HTTP, а заодно и то, какие изменения вводились от версии к версии HTTP.

Стандарты HTTP протокола. История развития HTTP протокола. Версии HTTP протокола

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

Стандарты HTTP, версии HTTP протокола

На данный момент есть четыре стандарта HTTP протокола:

1. Стандарт HTTP/0.9 – версия протокола HTTP 0.9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Протокол версии 0.9 был призван упорядочить взаимодействие между клиентом и сервером в сети. После появления стандарта HTTP/0.9 появилось разделение функций между клиентом и сервером при их взаимодействии. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0). Данный документ стал основой для реализации приложений и компонентов с использованием протокола HTTP версии 1.0. Кстати, разработчики могут идентифицировать свои приложения при передаче HTTP сообщений.
3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). Доработки коснулись: общего дизайна стандарта, формулировки и разъяснения некоторых терминов, исправлены опечатки, даны некоторые разъяснения по взаимодействию клиента и HTTP сервера в спорных ситуациях. Основным нововведением в версию протокола HTTP 1.1 был режим постоянного соединения (можете почитать про постоянные HTTP соединения), другими словами: за одно соединение можно было отправлять несколько HTTP запросов и получать несколько HTTP ответов в том порядке, в котором делались запросы. Вторым основным нововведение в версию протокола HTTP 1.1 является то, что теперь клиент при установке соединения с сервером должен обязательно посылать имя хоста в специальном поле HTTP заголовка (данное нововведение привело к массовому распространению виртуальных хостингов). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Стоит заметить, что версия HTTP протокола является очень важным HTTP параметром, который должны использовать все приложения. Так же замечу, что независимо от номера стандарта HTTP протокол предъявляет требования к приложениям, которые его используют.
4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета. Версия протокола HTTP 2 является бинарной. В версии протокола HTTP 2 будет поддерживаться мультиплексирование (объединение) запросов, поскольку появится объединение, появится и приоритет запросов и многое другое, думаю, в завершении цикла заметок по HTTP мы познакомимся со всеми нововведениями HTTP.

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

Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением ZametkiNaPolyah.ru!

HTTP — протокол уровня приложений / Habr

Введение

В Интернете есть очень эффективный протокол прикладного уровня, который готовит компьютеры к обмену информацией: Hypertext Transfer Protocol, или HTTP. HTTP — протокол прикладного уровня поверх коммуникационного протокола TCP/IP. HTTP часто упускается из вида при изучении веб-дизайна и веб-разработки, что является ошибкой: понимание его помогает определить лучший способ взаимодействия с пользователями, достичь лучшей производительности сайта и создает эффективный инструмент для управления информацией в сети Интернет.

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

Что такое коммуникационный протокол?

• синтакс (формат данных и программного кода)
• семантика (управление информацией и обработка ошибок)
• тайминг (согласование по времени и последовательности)

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

Где HTTP вклинивается в механизм?

• Уровень сетевого доступа, описывающий доступ к физическому устройству (т.е. использующее сетевую карту)
• Межсетевой уровень, описывающий размещения данных в дейтаграмме и роутинг данных — как они пакуются (IP)
• Транспортный уровень, описывающий способ, которым доставляются данные из исходной точки к финальному получателю (TCP, UDP)
• Прикладной уровень, описывающий значение или формат передаваемых сообщений (HTTP)

Давайте доберемся до сервера

Давайте поговорим немного об HTTP

• GET: Что мы хотим получить информацию.
• /: Что информация, которую мы хотим получить находится в корне сайта.
• HTTP/1.1: Что мы используем HTTP версии 1.1.
• Host: Мы пытаемся обратиться к определенному сайту.
• www.opera.com: имя сайта — www.opera.com.

 HTTP/1.1 200 OK

 Date: Wed, 23 Nov 2011 19:41:37 GMT

 Server: Apache

 Content-Type: text/html; charset=utf-8

 Set-Cookie: language=none; path=/; domain=www.opera.com; expires=Thu, 25-Aug-2011 19:41:38 GMT

 Set-Cookie: language=en; path=/; domain=.opera.com; expires=Sat, 20-Nov-2021 19:41:38 GMT

 Vary: Accept-Encoding

 Transfer-Encoding: chunked

 <!DOCTYPE html>

 <html lang="en">

Резюме

Что такое HTTP протокол: определение и основные понятия, связанные с HTTP

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Начнем знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол.  Протокол HTTP – это как правила движения на дороге, только правила дорожного движения соблюдает не все и не всегда. А вот если наши приложения не будут соблюдать протокол HTTP, то они не смогут работать в интернете.

Что такое HTTP протокол

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

HTTP протокол: определение и принципы работы

Содержание статьи:

HTTP (HyperText Transfer Protocol) – это протокол седьмого уровня модели OSI для передачи данных, в основе которого лежит архитектура взаимодействие клиент-сервер. Изначально протокол HTTP разрабатывался для передачи HTML документов между сервером и клиентом при помощи HTTP сообщений. Поскольку в основе протокола лежит взаимодействие клиент-сервер, то предполагается, что есть клиент, который делает HTTP запросы и есть HTTP сервер, который обрабатывает эти запросы и дает клиенту HTTP ответы. Все ответы сервера содержат коды состояния, а все запросы клиента имеют HTTP методы. Данная серия публикаций поможет нам разобраться с тем, как взаимодействуют клиент и сервер по средствам HTTP протокола.

Протокол HTTP довольно строгий и требует от приложений (кстати, протокол HTTP позволяет идентифицировать приложения) как клиентский, так и серверных строго исполнения стандарта (можешь посмотреть все стандарты HTTP протокола). Приведем несколько примеров HTTP клиентов: веб-браузер, приложения на Android, iOS, Windows. Приведем несколько примеров серверов HTTP: Apache, IIS, nginx, lighthttpd и другие.

Типичные задачи HTTP протокола и передача данных по HTTP

Типичные задачи, которые решает HTTP протокол: протокол HTTP осуществляет доступ к веб-ресурсам и обмен данными между пользовательскими приложениями. По сути HTTP протокол обеспечивает работу интернета. Иногда HTTP протокол используется как транспорт для других протоколов (при помощи HTTP протокола передается информация для других протоколов): SOAP, XML-RPC и другие.

Передача данных по HTTP протоколу осуществляется через TCP/IP соединение (вы можете прочитать более подробно про HTTP соединение и обсуждение в HTTP). Машина, которая выступает в роли сервера использует восьмидесятый TCP порт или порт 8080. Клиентские приложения, которые используют HTTP протокол обычно настроены на использование 80-го порта для соединения с HTTP сервером.

HTTP протокол – это абстракция над протоколом IP, вы можете обращаться к адресу m.vk.com, vk.com, но фактически, на третьем уровне модели OSI, вы будете обращаться к одному и тому же узлу с одним адресом IP, но информацию вы будете получать разную.

HTTP протокол не имеет инструментов для шифрования данных при передаче (если интересно, то почитайте про безопасность в HTTP), но для него есть расширяющие протоколы: SSL и TLS. По сути SSL – это более ранняя версия TLS протокола. Но об этом мы поговорим в других публикациях.

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

Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением ZametkiNaPolyah.ru!

Как HTTP/2 сделает веб быстрее / NIX corporate blog / Habr

Протокол передачи гипертекста (HTTP) — это простой, ограниченный и невероятно скучный протокол, лежащий в основе Всемирной паутины. По сути, HTTP позволяет считывать данные из подключённых к сети ресурсов, и в течение десятилетий он выступает в роли быстрого, безопасного и качественного “посредника”.
В этой обзорной статье мы расскажем об использовании и преимуществах HTTP/2 для конечных пользователей, разработчиков и организаций, стремящихся использовать современные технологии. Здесь вы найдёте всю необходимую информацию о HTTP/2, от основ до более сложных вопросов.

Содержание:

• Что такое HTTP/2?
• Для чего создавался HTTP/2?
• Чем был плох HTTP 1.1?
• Особенности HTTP/2
• Как HTTP/2 работает с HTTPS?
• Различия между HTTP 1.x, SPDY и HTTP/2
• Основные преимущества HTTP/2
• Сравнение производительности HTTPS, SPDY и HTTP/2
• Браузерная поддержка HTTP/2 и доступность
• Как начать использовать HTTP/2?

Что такое HTTP/2?

Первая задокументированная версия HTTP — HTTP 0.9 — вышла в 1991. В 1996 появился HTTP 1.0. Годом позже вышел HTTP 1.1 с небольшими улучшениями.

В феврале 2015 Рабочая группа HTTP Инженерного совета Интернета (IETF) пересмотрела протокол HTTP и разработала вторую основную версию в виде HTTP/2. В мае того же года спецификация реализации была официально стандартизирована в качестве ответа на HTTP-совместимый протокол SPDY, созданный в Google. Дискуссия на тему «HTTP/2 против SPDY» будет вестись на протяжении всей статьи.

Что такое протокол?

Протоколы обычно состоят из трёх основных частей: заголовка (header), полезных данных (payload) и футера (footer). Заголовок идёт первым и содержит адреса источника и получателя, а также другую информацию, например размер и тип. Полезные данные — это информация, которая передаётся посредством протокола. Футер передаётся в последнюю очередь и выполняет роль управляющего поля для маршрутизации клиент-серверных запросов к адресатам. Заголовок и футер позволяют избегать ошибок при передаче полезных данных.

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

Протокол HTTP изначально состоял из двух основных команд:

GET — получение информации с сервера,
POST — принимает данные для хранения.

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

Для чего создавался HTTP/2?

Главная цель разработки новой версии HTTP заключалась в обеспечении трёх свойств, которые редко ассоциируются с одним лишь сетевым протоколом, без необходимости использования дополнительных сетевых технологий, — простота, высокая производительность и устойчивость. Эти свойства обеспечены благодаря уменьшению задержек при обработке браузерных запросов с помощью таких мер, как мультиплексирование, сжатие, приоритезация запросов и отправка данных по инициативе сервера (Server Push).

В качестве усовершенствований HTTP используются такие механизмы, как контроль потоков (flow control), апгрейд (upgrade) и обработка ошибок. Они позволяют разработчикам обеспечивать высокую производительность и устойчивость веб-приложений. Коллективная система (collective system) позволяет серверам эффективно передавать клиентам больше контента, чем они запросили, что предотвращает постоянные запросы информации, пока сайт не будет целиком загружен в окне браузера. Например, возможность отправки данных по инициативе сервера (Server Push), предоставляемая HTTP/2, позволяет серверу отдавать сразу весь контент страницы, за исключением того, что уже имеется в кэше браузера. Накладные расходы протокола минимизируются за счёт эффективного сжатия HTTP-заголовков, что повышает производительность при обработке каждого браузерного запроса и серверного отклика.

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

Марк Ноттингем, Глава Рабочей группы HTTP IETF и член W3C TAG:

«… мы не меняем весь HTTP — методы, коды статусов и большинство заголовков остаются теми же. Мы лишь переработали его с точки зрения повышения эффективности использования, чтобы он был более щадящим по отношению к интернету…»

Чем был плох HTTP 1.1?

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

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

Сетевой индустрии фактически пришлось хакнуть эти ограничения с помощью таких методик, как доменный шардинг (domain sharding), конкатенация, встраивание и спрайтинг (spriting) данных, а также ряд других. Неэффективное использование HTTP 1.1 базовых TCP-соединений является причиной плохой приоритезации ресурсов, и в результате — экспоненциальной деградации производительности по мере роста сложности, функциональности и объёма веб-приложений.

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

Например, с помощью Cookie Hack злоумышленники могут повторно использовать предыдущую рабочую сессию для получения несанкционированного доступа к паролю пользователя. А причина в том, что HTTP 1.1 не предоставляет инструментов конечного подтверждения подлинности. Понимая, что в HTTP/2 будут искать аналогичные лазейки, его разработчики постарались повысить безопасность протокола с помощью улучшенной реализации новых возможностей TLS.

Особенности HTTP/2

Мультиплексированные потоки

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

Бинарные фреймовые форматы позволяют одновременно обмениваться многочисленными, независимыми последовательностями, передаваемыми в обе стороны, без какой-либо задержки между потоками. Этот подход даёт массу преимуществ:

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

Отправка данных по инициативе сервера (Server Push)

Полученный от сервера ресурс Y кэшируется на клиенте для будущего использования. Этот механизм позволяет экономить циклы «запрос-ответ» и снижает сетевую задержку. Изначально Server Push появился в протоколе SPDY. Идентификаторы потоков, содержащие псевдозаголовки наподобие :path, инициируют передачу сервером дополнительной информации, которая должна быть закэширована. Клиент должен либо явным образом позволить серверу передавать себе кэшируемые ресурсы посредством HTTP/2, либо прервать инициированные потоки, имеющие специальный идентификатор.

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

Реализация HTTP/2 демонстрирует высокую производительность при работе с инициативно передаваемыми ресурсами:

• Инициативно передаваемые ресурсы сохраняются в кэше клиента.
• Клиент может многократно использовать эти ресурсы на разных страницах.
• Сервер может мультиплексировать инициативно передаваемые ресурсы вместе с запрошенной информацией в рамках того же TCP-соединения.
• Сервер может приоритезировать инициативно передаваемые ресурсы. Это ключевое отличие с точки зрения производительности между HTTP/2 и HTTP 1.
• Клиент может отклонить инициативно передаваемые ресурсы для поддержания эффективности репозитория, или может вообще отключить функцию Server Push.
• Клиент может также ограничивать количество одновременно мультиплексированных потоков с инициативно передаваемыми данными.

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

Двоичный протокол

Читать двоичные команды будет труднее, чем аналогичные текстовые, но зато сети будет легче их генерировать и парсить фреймы. Семантика остаётся без изменений. Браузеры, использующие HTTP/2, перед отправкой в сеть конвертируют текстовые команды в двоичные. Двоичный слой фреймов не имеет обратной совместимости с клиентами и серверами, использующими HTTP 1.x. Он является ключевым фактором, обеспечивающим значительный прирост производительности по сравнению с SPDY и HTTP 1.x. Какие преимущества даёт интернет-компаниям и онлайн-сервисам использование двоичных команд:

• Низкие накладные расходы при парсинге данных — критически важное преимущество HTTP/2 по сравнению с HTTP 1.
• Ниже вероятность ошибок.
• Меньше нагрузка на сеть.
• Эффективное использование сетевых ресурсов.
• Решение проблем с безопасностью, наподобие атак с разделением запросов (response splitting attack), проистекающих из текстовой природы HTTP 1.x.
• Реализуются прочие возможности HTTP/2, включая сжатие, мультиплексирование, приоритезацию, управление потоками и эффективную обработку TLS.
• Компактность команд упрощают их обработку и реализацию.
• Выше эффективность и устойчивость к сбоям при обработке данных, передаваемых между клиентом и сервером.
• Снижение сетевой задержки и повышение пропускной способности.

Приоритезация потоков

Приоритезация осуществляется с помощью присваивания каждому потоку зависимостей (Dependencies) и веса (Weight). Хотя все потоки, по сути, и так зависят друг от друга, ещё добавляется присваивание веса в диапазоне от 1 до 256. Детали механизма приоритезации всё ещё обсуждаются. Тем не менее, в реальных условиях сервер редко управляет такими ресурсами, как ЦПУ и подключения к БД. Сложность реализации сама по себе не даёт серверам выполнять запросы на приоритезацию потоков. Продолжение работ в этом направлении имеет особенное значение для успеха HTTP/2 в долгосрочной перспективе, потому что протокол позволяет обрабатывать многочисленные потоки в рамках единственного TCP-соединения.

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

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

Сжатие заголовков с сохранением состояния

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

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

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

• Эффективную приоритезацию потоков.
• Эффективное использование механизмов мультиплексирования.
• Снижает накладные расходы при использовании ресурсов. Это один из первых вопросов, обсуждаемых при сравнении HTTP/2 с HTTP 1 и SPDY.
• Кодирование больших и часто используемых заголовков, что позволяет не отправлять весь фрейм с заголовком. Передаваемый размер каждого потока быстро уменьшается.
• Устойчивость к атакам, например, CRIME — эксплойтам потоков данных со сжатыми заголовками.

Различия между HTTP 1.x и SPDY

Как HTTP/2 работает с HTTPS

Браузерная поддержка HTTP/2 включает в себя HTTPS-шифрование, и фактически улучшает общую производительность обеспечения безопасности при работе с HTTPS. Ключевыми особенностями HTTP/2, позволяющими обеспечить безопасность цифровых коммуникаций в чувствительном сетевом окружении, являются:

• меньшее количество TLS-хэндшейков,
• меньшее потребление ресурсов на стороне клиента и сервера,
• улучшенные возможности повторного использования имеющихся веб-сессий, но без уязвимостей, характерных для HTTP 1.x.

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

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

Основные преимущества HTTP/2

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

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

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

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

Способность протокола отправлять и принимать больше данных в каждом цикле обмена данными клиент-сервер — это не оптимизационный хак, а реальное, доступное и практическое преимущество HTTP/2. В качестве аналогии можно привести сравнение вакуумного поезда с обычным: отсутствие трения и сопротивления воздуха позволяет транспортному средству перемещаться быстрее, брать больше пассажиров и эффективнее использовать доступные каналы без установки более мощных двигателей. Также снижается вес поезда и улучшается его аэродинамика.

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

Что происходит, когда механизмы передачи данных сметают все преграды на пути к повышению производительности сети? У высокой скорости работы сайтов есть побочные явления: пользователи получают больше удовольствия, улучшается оптимизация для поисковых сервисов, ресурсы используются эффективнее, растёт аудитория и объёмы продаж, и многое другое.

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

Производительность мобильной сети

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

Интернет подешевле

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

Экспансивный охват

Насыщенность мультимедиа

Улучшение опыта использования мобильного интернета

Более эффективное использование сети

Безопасность

Инновационность

Преимущества HTTP/2 с точки зрения SEO

Стандартные процессы поисковой оптимизации выходят за рамки маркетинговой фронтэнд-тактики. Теперь они охватывают полный цикл обмена данными между клиентом и сервером. SEO-оптимизаторы, которые ранее были ключевыми фигурами в командах интернет-маркетинга, потеряли свои позиции с появлением новых технологий цифровых коммуникаций. И преобладание среди них HTTP/2 свидетельствует о тектоническом сдвиге, который заставляет веб-разработчиков и маркетологов вернуться к чертёжным доскам.

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

Сравнение производительности HTTPS, SPDY и HTTP/2

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

Подробности тестирования:

Результаты этого теста говорят нам следующее:

• Размеры заголовков клиентского запроса и серверного отклика: HTTP/2 демонстрирует, что использование сжатия позволяет значительно уменьшить размер заголовка. При этом SPDY уменьшает заголовок только серверного отклика для данного запроса. HTTPS вообще не уменьшает заголовки.
• Размер сообщения серверного отклика: размер отклика HTTP/2-сервера оказался больше, но зато в нём применялось более стойкое шифрование.
• Количество использованных TCP-соединений: при обработке многочисленных одновременных запросов(мультиплексирование) HTTP/2 и SPDY используют меньше сетевых ресурсов, следовательно, снижается задержка.
• Скорость загрузки страницы: HTTP/2 постоянно был быстрее SPDY. HTTPS был значительно медленнее из-за отсутствия сжатия заголовков и инициативной отправки данных сервером.

Браузерная поддержка HTTP/2 и доступность

Клиентская поддержка

Основные мобильные браузеры, включая Android Browser, Chrome для Android и iOS, а также Safari в iOS8 и выше, уже поддерживают HTTP/2. Рекомендуется на всякий случай поставить последние стабильные версии мобильных и настольных браузеров, чтобы получить максимальную производительность и преимущества в безопасности.

Серверная поддержка: Apache и Nginx

Nginx-серверы, составляющие 66% всех активных веб-серверов, могут похвастаться встроенной поддержкой HTTP / 2. А для обеспечения браузерной поддержки HTTP/2 на Apache, нужно воспользоваться модулем mod_spdy. Он разработан Google для внедрения поддержки в Apache 2.2 таких функций, как мультиплексирование и сжатие заголовков. Это ПО было передано в дар Apache Software Foundation.

Как начать использовать HTTP/2?

1. Проверьте, чтобы был включен HTTPS:
   
   • Приобретите в проверенной организации сертификат SSL или TLS.
   • Активируйте сертификат.
   • Установите сертификат.
   • Обновите сервер для включения протокола HTTPS.
2. Проверьте, чтобы базовая сетевая инфраструктура включала в себя поддержку HTTP/2 на уровне серверного ПО. Серверы Nginx имеют нативную поддержку, в Apache она появилась в октябре 2015 (в версии 2.4). В более ранних версиях для поддержки HTTP/2 нужно установить дополнительные модули.
3. Обновите, сконфигурируйте и протестируйте ваши серверы. Здесь описана конфигурация и процедуры тестирования для серверов Apache. Свяжитесь со своим хостинг-провайдером и удостоверьтесь, что ваш сайт готов к использованию HTTP/2.
4. Для проверки правильности конфигурации HTTP/2 воспользуйтесь этим инструментом.

Заключение

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

Параметр версии протокола HTTP: как влияет версия HTTP приложения на взаимодействие

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжим знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. В этой публикации мы погорим про то, как приложения определяют версию HTTP протокола, по которой им следует общаться друг с другом. Другими словами про параметр версии HTTP протокола.

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

Параметр версии протокола HTTP

Содержание статьи:

HTTP протокол для указания версии использует нумерацию типа: мажорная.минорная. Первое, что должен указать клиент серверу при установке соединения по HTTP – это версия HTTP, которой они будут пользоваться для общения. В каждой версии HTTP есть свои особенности и тонкости. В рамках данных заметок мы будем изучать HTTP 1.1.

Когда разработчики стандарта HTTP меняют или расширяют семантику HTTP протокола, тогда они изменяют минорную версию HTTP. Когда меняется алгоритм анализа HTTP сообщений или, когда изменяется формат сообщений, то меняется мажорная версия HTTP протокола.

Я уже говорил, что версия HTTP протокола указывается в первой строке сообщения, общий синтаксис выглядит так:

HTTP-Version   = «HTTP» «/» 1*DIGIT «.» 1*DIGIT 

Пример HTTP версии:

HTTP/1.0 или HTTP/1.1

Помните про требования HTTP? Так вот ваше приложение должно включать HTTP версию в свои запросы или ответы. Версия HTTP, указанная в сообщение, говорит о том, что ваше приложение условно совместимо с той или иной версией HTTP.

HTTP версия приложения

HTTP версия приложения – это самая высокая HTTP версия, для которой ваше приложение (или приложение, которое вы используете) является, как минимум, условном совместимым, то есть выполнены все необходимые требования HTTP.

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

Подведем итог: HTTP параметр версии позволяет определить какой версией HTTP следует пользоваться приложениям и какую максимально возможную версию HTTP поддерживает приложение.

Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением ZametkiNaPolyah.ru!