Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернет, завершил (http://www.ietf.org/mail-archive/web/ietf-announce/current/m... формирование RFC для протокола HTTP/2.0 и опубликовал (https://www.rfc-editor.org/info/rfc7540) связанную с ним спецификацию как RFC 7540 (http://www.rfc-editor.org/rfc/rfc7540.txt). RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.
В основу HTTP/2.0 положен протокол SPDY (https://www.opennet.ru/opennews/art.shtml?num=33638), разработанный компанией Google и позволяющий ускорить загрузку сайтов на 15-50%. HTTP/2.0 решает задачи повышения эффективности использования сетевых ресурсов и снижения задержек при соединении и обмене данными между клиентом и сервером, в условиях изменившихся современных реалий, при которых для загрузки сайта требуется отправить множество отдельных запросов (в среднем около 100), связанных с получением CSS, файлов JavaScript и картинок. Протокол HTTP/1.1, в силу блокировок при конвейерной передаче данных и высоких накладных расходов на отдачу ресурсов небольшого размера, не может обеспечить должную эффективность и вынуждает устанавливать несколько одновременных TCP-соединений к серверу.
Основные особенности (http://daniel.haxx.se/http2/) (PDF (https://github.com/vlet/http2-explained/blob/master/http2.ru... HTTP/2.0:
- Применение бинарного протокола, оперирующего передачей бинарных кадров. Каждый кадр имеет заголовок с информацией о типе, размере, опциях и идентификаторе потока. Кадры с типом DATA используются для передачи данных, HEADERS - HTTP-заголовков, RST_STREAM - для досрочного прерывания отправки данных;
- Мультиплексирование и распараллеливание потоков в рамках одного TCP-соединения. Пакеты разных потоков смешиваются и, в отличие от конвейерной передачи HTTP/1.1, не ожидают окончания отправки запроса. Поддержка эффективной двунаправленной передачи данных. Возможность мультиплексирования при обращении к разным хостам, что позволяет дополнительно ускорить одновременную загрузку web-контента с разных сайтов (в SPDY мультиплексирование поддерживается только для одного хоста);
- Возможность установки приоритетов и зависимостей для потоков, что позволяет выделить наиболее важные потоки, которые нужно выполнить в первую очередь, а также определить зависимость одного потока от другого;
- Сжатие HTTP-заголовков. В том числе поддерживается устранение дубликатов заголовков и Cookie, повторяющихся для серии запросов к одному сайту. Допускается определение отдельных заголовков не подлежащих сжатию;
- Низкая чувствительность к задержкам;
- Средства для согласования протокола между клиентом и сервером, позволяющие выбрать HTTP/1.1, HTTP/2.0 и другие протоколы: сервер предоставляет список поддерживаемых протоколов, которые может выбрать клиент. Для шифрованных соединений параметры TLS согласовываются при помощи протокола APLN, при котором клиент сообщает список поддерживаемых опций, а сервер выбирает наиболее оптимальный для себя вариант;
- Обеспечение высокого уровня совместимости с HTTP/1.1: сохранены заголовки, схема URI, коды состояния и методы (GET, POST и т.п.). Обеспечена возможность создания прокси для доступа клиентов HTTP/1.1 к серверам HTTP/2.0;
- Возможность установки шифрованных (HTTPS) и не шифрованных соединений (HTTP). Шифрование осуществляется с использованием TLS 1.2 или более новой версии. Несмотря на то, что спецификация допускает создание нешифрованных соединений, разработчики Firefox и Chrome намерены обеспечить работу HTTP/2.0 только поверх TLS;
- Поддержка технологии Server push (https://ru.wikipedia.org/wiki/%D0%A2%D0%... для передачи данных от сервера к клиенту (например, когда сервер считает, что после определённого запроса обязательно будут затребованы другие данные, он может отправить эти данные не дожидаясь фактического запроса);
- Поддержка HTTP/2.0 уже реализована в браузерах Firefox 36+, Chrome (требуется сборка с "--enable-spdy4") и IE 11. Серверные реализации пока ограничиваются (https://github.com/http2/http2-spec/wiki/Implementations)&nb... (http://open.litespeedtech.com/), H2O (https://github.com/kazuho/h2o), nghttp2 (https://nghttp2.org/) и некоторыми библиотеками на высокоуровневых языках.
Дополнительно можно обратить внимание на публикацию (http://www.rfc-editor.org/pipermail/rfc-dist/2015-May/004288... 7539 (https://www.rfc-editor.org/info/rfc7539), стандартизующий потоковый шифр ChaCha20 (http://cr.yp.to/chacha.html) и алгоритм аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), разработанные Дэниэлом Бернштейном (Daniel J. Bernstein (http://cr.yp.to/djb.html)), Таней Лэндж
(Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация который позволяет добиться фиксированного времени выполнения без задействования специальной аппаратной поддержки. В настоящее время данные алгоритмы включены в состав OpenSSH и составляют встроенный набор шифров, используемых при сборке без OpenSSL.
URL: http://www.ietf.org/mail-archive/web/ietf-announce/current/m...
Новость: https://www.opennet.ru/opennews/art.shtml?num=42236
