Концепция http2

Так для чего создан http2? Где границы, которые ограничивают область работы группы HTTPbis?

Они, на самом деле, достаточно чёткие и накладывают несколько ограничений на способность команды к инновациям.

• Она должна поддерживать парадигмы HTTP. Это по-прежнему протокол, где клиенты отправляют запросы на сервер поверх TCP.

• Ссылки http:// и https:// не могут быть изменены. Нельзя добавить новую схему. Количество контента, которое использует подобную адресацию слишком велико, чтобы когда-либо ожидать подобного изменения.

• HTTP1 серверы и клиенты будут существовать ещё десятилетия, мы должны иметь возможность проксировать их к http2-серверам.

• Следовательно, прокси должны быть способны конвертировать один в один возможности http2 в HTTP 1.1 для клиентов.

• Удалить или уменьшить число опциональных частей в протоколе. Это даже не столько требование, сколько мантра, пришедшая от SPDY и команды Google. Настаивая на том, что все требования обязательны, у вас не будет возможности не делать чего-то сейчас, а потом попасть в ловушку.

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

5.1. http2 для существующих URI схем

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

HTTP 1.1 уже имеет предопределённый способ для этого, так называемый Upgrade – заголовок, который позволяет серверу отправить ответ, используя новый протокол, при получении подобного запроса по старому протоколу. Ценой времени одной итерации запрос-ответ.

Расплата временем запроса-ответа не являлась тем, с чем команда SPDY могла согласиться, и, поскольку они также разрабатывали SPDY поверх TLS, они создали новое TLS-расширение, которое применялось для существенного сокращения согласования. Используя это расширение, названное NPN от Next Protocol Negotiation (согласование следующего протокола), сервер сообщает клиенту какие протоколы он знает, а клиент может выбрать и использовать наиболее предпочтительный.

5.2. http2 для https://

Большое внимание в http2 было уделено тому, чтобы он правильно работал поверх TLS. SPDY работал только поверх TLS и было сильное желание сделать TLS обязательным и для http2, но консенсус не был достигнут и поэтому http2 был выпущен с опциональным TLS. Однако, два известных разработчика спецификации чётко заявили, что они будут реализовывать только http2 поверх TLS: руководитель Mozilla Firefox и руководитель Google Chrome. Это два лидирующих браузера на сегодня.

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

Тема обязательного TLS вызывает много размахов руками и агитационных призывов в списках рассылки и собраниях – добро это или зло? Это больная тема – помните об этом, если вы решите задать этот вопрос прямо в лицо участнику HTTPbis!

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

5.3. http2 согласование поверх TLS

Согласование следующего протокола (NPN) – это протокол, который использовался SPDY для согласования с TLS-серверами. Так как это не был настоящий стандарт, он был переработан в IETF и вместо него появился ALPN: Application Layer Protocol Negotiation (согласование протокола на уровне приложения). ALPN продвигается для использования в http2, в то время как клиенты и серверы SPDY по-прежнему используют NPN.

То факт, что NPN появился первым, а для ALPN потребовалось время для прохождения стандартизации, привело к тому, что ранние реализации http2-клиентов и http2-серверов использовали оба этих расширения при согласовании http2. Также, поскольку NPN используется для SPDY и множество серверов поддерживают оба протокола SPDY и http2, то поддержка и NPN, и ALPN на таких серверах имеет смысл.

Основное отличие APLN от NPN заключается в том, кто определяет какой использовать протокол. В ALPN клиент указывает серверу список протоколов в порядке предпочтения и сервер выбирает то, что ему удобнее, в то время как в NPN клиент делает финальный выбор.

5.4. http2 для http://

Как кратко отмечалось ранее, для текстового HTTP 1.1 для согласования http2 требуется отправить запрос серверу с заголовком Upgrade. Если сервер понимает http2, он ответит статусом «101 Switching» и затем начнёт использовать http2 в соединении. Вы конечно понимаете, что эта процедура обновления стоит времени одного полного сетевого запроса-ответа, но с другой стороны http2-соединение можно сохранять работоспособным и повторно использовать значительно дольше, чем обычно используется HTTP1-соединение.

Несмотря на то, что некоторые представители браузеров настаивают, что они не будут реализовывать такой способ согласования http2, команда Internet Explorer выразила готовность его реализовать, а curl его уже поддерживает.