Pull to refresh

Как HTTP/2 сделает веб быстрее

Reading time21 min
Views59K


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

Путь к HTTP/2

Reading time11 min
Views98K

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


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


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

Читать дальше →

Эволюция HTTP. Часть 1. Краткая история развития самого популярного протокола Всемирной паутины

Reading time11 min
Views11K

Привет! Меня зовут Глеб Гончаров, я руководитель группы разработки клиентского продукта в СберМаркете. В серии статей я рассмотрю историю развития протокола HTTP. Полное обсуждение семантики выходит за рамки, но понимание ключевых изменений в устройстве HTTP и мотивов принимаемых решений даст необходимую основу для обсуждения вопросов производительности и ограничений протокола, особенно в контексте предстоящих улучшений HTTP/2 и его преемника HTTP/3. Про HTTP-NG сейчас написано только на английском и буквально в нескольких редких книгах, так что я поизучал домашние страницы членов комитета и их презентации 1996-1998 гг., чтобы понять основные мотивы. Хочу поделиться находками с аудиторией Хабра.

Читать далее

Разбираем HTTP/2 по байтам

Level of difficultyMedium
Reading time24 min
Views39K

image


Откройте любую статью с обзором HTTP/1.1. Скорее всего, там найдётся хотя бы один пример запроса и ответа, допустим, такие:


GET / HTTP/1.1
Host: localhost

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 38
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<h1>Привет!</h1>

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


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

Читать дальше →

HTTP/3: от корней до кончиков

Reading time16 min
Views48K
Протокол прикладного уровня HTTP лежит в основе интернета. Он начал свою жизнь в 1991 году как HTTP/0.9, а к 1999 году превратился в HTTP/1.1, который был стандартизирован Инженерным советом Интернета (IETF).

HTTP/1.1 долго всех удовлетворял, но растущие потребности Сети потребовали апгрейда — и в 2015 году приняли HTTP/2. На этом история не закончилась: совсем недавно IETF анонсировал новую версию HTTP/3. Для некоторых это стало неожиданностью и вызвало некоторое замешательство. Если вы не отслеживаете работу IETF, может показаться, что HTTP/3 появился из ниоткуда. Тем не менее, мы можем отследить его происхождение по истории экспериментов и эволюции веб-протоколов, в частности, транспортного протокола QUIC.

Если вы не знакомы с QUIC, мои коллеги по Cloudflare довольно подробно осветили разные аспекты: например, см. статьи о реальных недостатках современного HTTP и подробности о протоколе транспортного уровня. Мы собрали эти и другие материалы на сайте cloudflare-quic.com. А если интересно, обязательно ознакомьтесь с quiche: это наша собственная реализация QUIC, написанная на Rust с открытым исходным кодом.
Читать дальше →

HTTP/3 от А до Я: основные концепции. Часть 1

Reading time20 min
Views93K

image
Фото Florencia Viadana, Unsplash.com


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

Читать дальше →

HTTP или SOCKS прокси, что выбрать? Чем отличаются HTTP(S) и SOCKS прокси — разбор дилетанта

Level of difficultyMedium
Reading time10 min
Views8.6K

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

Читать далее

HTTP or SOCKS Proxy: Which One to Choose?A Dilettante’s Analysis of the Differences between HTTP(S) and SOCKS Proxies

Level of difficultyEasy
Reading time10 min
Views570

Proxy servers have long become an integral part of the modern network. They are used to enhance anonymity, bypass blocks, balance loads, and control traffic. However, not everyone understands that there is a fundamental difference between HTTP(S) proxies and SOCKS proxies. In this article, I will attempt to examine in detail the technical aspects of both types, review their advantages and limitations, and provide examples of configuration and usage – though this part is more of an elective (optional, if you will, but I really feel like including it).

Read more

Семь советов по внедрению HTTP/2

Reading time9 min
Views46K
Недавно вышла новая версия стандарта HTTP. В мае 2015 года был утвержден HTTP/2, который получил распространение среди браузеров и веб-серверов (включая NGINX и NGINX Plus). На данный момент более 60% используемых браузеров поддерживают HTTP/2, причем эта цифра продолжает увеличиваться с каждым месяцем.

Стандарт HTTP/2 основан на протоколе SPDY, разработанном компанией Google. В Google Chrome поддержка SPDY будет осуществляться до начала 2016 года. NGINX одним из первых реализовал протокол SPDY и сейчас играет ведущую роль в продвижении HTTP/2. Была опубликована статья, в которой дано подробное описание HTTP/2, приводится сравнение со SPDY и подробно описывается процесс внедрения нового протокола.
Читать дальше →

HTTP Request Smuggling: как особенности в обработке HTTP-заголовков приводят к атакам CL.TE и TE.CL

Level of difficultyMedium
Reading time11 min
Views217

HTTP Request Smuggling  или контрабанда HTTP-запросов — тип уязвимости, который возникает из-за несоответствий в обработке HTTP-запросов между фронтендом и бэкендом. Каким образом различия в интерпретации заголовков позволяют атакующим использовать эту уязвимость? Как HTTP Request Smuggling можно использован в сочетании с Web Cache Poisoning? И на что обратить внимание, чтобы предотвратить подобные атаки? Разберем вместе на примере лабораторных работ с PortSwigger.

Читать далее

Как HTTP(S) используется для DNS: DNS-over-HTTPS на практике

Level of difficultyHard
Reading time14 min
Views4.8K

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

Читать далее

Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 1

Reading time16 min
Views10K

Преамбула


Наша команда занимается разработкой небольшого, удобного в использовании, встраиваемого, асинхронного HTTP-сервера для современного C++ под названием RESTinio. Начали его делать потому, что нужна была именно асинхронная обработка входящих HTTP-запросов, а ничего готового, чтобы нам понравилось, не нашлось. Как показывает жизнь, асинхронная обработка HTTP-запросов в C++ приложениях нужна не только нам. Давеча на связь вышли разработчики из одной компании с вопросом о том, можно ли как-то подружить асинхронную обработку входящих запросов в RESTinio с выдачей асинхронных исходящих запросов посредством libcurl.

По мере выяснения ситуации мы обнаружили, что эта компания столкнулась с условиями, с которыми сталкивались и мы сами, и из-за которых мы и занялись разработкой RESTinio. Суть в том, что написанное на C++ приложение принимает входящий HTTP-запрос. В процессе обработки запроса приложению нужно обратиться к стороннему серверу. Этот сервер может отвечать довольно долго. Скажем, 10 секунд (хотя 10 секунд — это еще хорошо). Если делать синхронный запрос к стороннему серверу, то блокируется рабочая нить, на которой выполняется HTTP-запрос. А это начинает ограничивать количество параллельных запросов, которые может обслуживать приложение.
Читать дальше →

Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 2

Reading time22 min
Views9.9K
В предыдущей статье мы начали рассказывать о том, как можно реализовать асинхронную обработку входящих HTTP-запросов, внутри которой нужно выполнять асинхронные исходящие HTTP-запросы. Мы рассмотрели реализованную на C++ и RESTinio имитацию стороннего сервера, который долго отвечает на HTTP-запросы. Сейчас же мы поговорим о том, как можно реализовать выдачу асинхронных исходящих HTTP-запросов к этому серверу посредством curl_multi_perform.

Несколько слов о том, как можно использовать curl_multi


Библиотека libcurl широко известна в мире C и C++. Но, вероятно, наиболее широко она известна в виде т.н. curl_easy. Использовать curl_easy просто: сперва вызываем curl_easy_init, затем несколько раз вызываем curl_easy_setopt, затем один раз curl_easy_perform. И, в общем-то, все.

В контексте нашего рассказа с curl_easy плохо то, что это синхронный интерфейс. Т.е. каждый вызов curl_easy_perform блокирует вызвавшую его рабочую нить до завершения выполнения запроса. Что нам категорически не подходит, т.к. мы не хотим блокировать свои рабочие нити на то время, пока медленный сторонний сервер соизволит нам ответить. От libcurl-а нам нужна асинхронная работа с HTTP-запросами.

И libcurl позволяет работать с HTTP-запросами асинхронно через т.н. curl_multi. При использовании curl_multi программист все так же вызывает curl_easy_init и curl_easy_setopt для подготовки каждого своего HTTP-запроса. Но не делает вызов curl_easy_perform. Вместо этого пользователь создает экземпляр curl_multi через вызов curl_multi_init. Затем добавляет в этот curl_multi-экземпляр подготовленные curl_easy-экземпляры через curl_multi_add_handle и…
Читать дальше →

Почему до сих пор повсеместно не используется HTTPS?

Reading time8 min
Views72K
Шифрование. Мы все его любим и хотим использовать везде. Но почему оно до сих пор не применяется повсеместно?

Проблема в сертификатах?


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

Большинство предложений перехода на повсеместное шифрование звучат примерно так: «NSA записывает весь наш трафик, почему бы не шифровать его?». Целью подобных предложений является повышение стоимости пассивного слежения за всем трафиком, а не более сложные и целевые атаки, которые применяются злоумышленниками.

Ребята из Let's Encrypt уже догадались, что проблема с сертификатами почти полностью поддаётся автоматизации, и что её реализация для выпуска, установки, конфигурации и продления на нескольких наиболее распространённых платформах может покрыть подавляющее большинство Интернета. Замечательная работа, и, хоть и осталось сделать многое, я думаю, что мы можем считать проблему сертификатов решённой.
Читать дальше →

Как перевести сайт целиком на постоянный HTTPS для всех

Reading time6 min
Views45K

Шифруем всё подряд


Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.

Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.

Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.

То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.

Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.
Читать дальше →

Простейший HTTP сервер на Golang и Elixir. Сравнение производительности

Reading time10 min
Views33K

image
Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:


Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  452793 requests in 10.03s, 58.30MB read
Requests/sec:  45133.28
Transfer/sec:      5.81MB

elixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  184703 requests in 10.02s, 28.57MB read
Requests/sec:  18441.79
Transfer/sec:      2.85MB

Как жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.

Читать дальше →

HTTP/3: разрушение основ и дивный новый мир

Reading time8 min
Views55K
Вот уже больше 20 лет мы смотрим веб-странички по протоколу HTTP. Большинство пользователей вообще не задумывается о том, что это такое и как оно работает. Другие знают, что где-то под HTTP есть TLS, а под ним TCP, под которым IP и так далее. А третьи – еретики – считают, что TCP – это прошлый век, им хочется чего-то более быстрого, надёжного и защищённого. Но в своих попытках изобрести новый идеальный протокол они вернулись к технологиям 80-х годов и пытаются построить на них свой дивный новый мир.

Читать дальше →

Полное руководство по переходу с HTTP на HTTPS

Reading time36 min
Views228K

В наше время HTTPS обязателен для каждого веб-сайта: пользователи ищут замочек в адресной строке, когда передают личные данные; Chrome и Firefox недвусмысленно помечают как небезопасные веб-сайты с формами на страницах без HTTPS; это влияет на позиции в поисковой выдаче и оказывает серьёзное влияние на приватность в целом. Кроме того, сейчас имеется несколько вариантов получить бесплатный сертификат, так что переход на HTTPS — всего лишь вопрос желания.


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

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

Сюда включены детальные инструкции для владельцев виртуального хостинга на cPanel, администраторов серверов Apache HTTP и nginx под Linux и Unix, а также Internet Information Server под Windows.
Читать дальше →

Пишем высокопроизводительный http клиент на примере fasthttp. Александр Валялкин (VertaMedia)

Reading time15 min
Views35K

Библиотека Fasthttp — ускоренная альтернатива net/http из стандартных пакетов Golang.
Как она устроена? Почему она такая быстрая?


Предлагаю вашему вниманию расшифровку доклада Александра Валялкина Fasthttp client internals.
Паттерны из Fasthttp можно использовать для ускорения ваших приложений, вашего кода.



Кому интересно, добро пожаловать под кат.

Упрощаем написание HTTP обработчиков на Golang

Reading time6 min
Views11K

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


  • Логирование входящего HTTP запроса
  • Проверка на допустимость HTTP метода
  • Выполнение аутентификации (basic, MS AD, ...)
  • Проверка валидности token (при необходимости)
  • Считывание тела (body) входящего запроса
  • Считывание заголовка (header) входящего запроса
  • Собственно обработка запроса и формирование ответа
  • Установка HSTS Strict-Transport-Security
  • Установка Content-Type для исходящего ответа (response)
  • Логирование исходящего HTTP ответа
  • Запись заголовка (header) исходящего ответа
  • Запись тела исходящего ответа
  • Обработка и логирование ошибок
  • Обработка defer recovery для восстановления после возможной panic

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


Повторять все это в каждом HTTP обработчике крайне неэффективно.


Даже если вынести весь код в отдельные подфункции, все равно получается примерно по 80-100 строк кода на каждый HTTP обработчик без учета собственно обработки запроса и формирования ответа.


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


Этот подход реализован в шаблоне backend сервера на Golang

Читать дальше →