В основе значительной части услуг, оказываемых Curator, лежит технология обратного прокси (reverse proxy). Это означает, что запросы, предназначенные для вашего сервера, сначала поступают на обратный прокси, а уже он перенаправляет их на ваш сервер, выступая в роли клиента. Аналогично происходит с ответами: сервер посылает их не пользователю напрямую, а обратному прокси, а он перенаправляет их пользователю.

Сервер, к которому обращается обратный прокси, называется апстримом.

Такая архитектура позволяет Curator решать следующие задачи:

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

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

См. также: как подключить обратный HTTP-прокси.

Проксирование HTTPПроксирование HTTP

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

Устройство пользователя обращается к DNS-серверу и получает IP-адрес обратного прокси. После этого непосредственное взаимодействие пользователя идёт только с серверами Curator. Запросы, которые не являются частью DDoS-атак, пересылаются на апстрим, при этом к ним добавляется заголовок X-Forwarded-For.

Исключение составляют следующие ситуации:

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

• Если вы настроили HTTP-перенаправления, то на соответствующие запросы обратный прокси Curator будет возвращать ответ самостоятельно, не пересылая запрос на апстрим.

Проксирование HTTPSПроксирование HTTPS

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

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

Добавить данные в хранилище сертификатов можно двумя способами:

• Настроив автоматический выпуск и обновление сертификатов.
• Загрузив файлы вручную через личный кабинет или API.

Автоматический выпуск сертификатовАвтоматический выпуск сертификатов

Для автоматического выпуска сертификатов Curator использует бесплатный сервис Let's Encrypt. Вы можете заказать выпуск такого сертификата через личный кабинет, указав список доменных имён, для которых должен быть выпущен сертификат.

Каждый сертификат Let's Encrypt действителен в течение 90 дней после выпуска. За несколько дней до окончания этого срока Curator автоматически отправляет запрос на перевыпуск сертификата и устанавливает его вместо устаревающего. В случае невозможности автоматического продления Curator уведомит вас об этом.

Чтобы подтвердить владение доменом для Let's Encrypt, обратный прокси возвращает особый токен по определённому URL (HTTP-01 challenge). Обратите внимание, что сервис Let's Encrypt сможет проверить наличие этого токена только тогда, когда A-записи в зоне DNS уже указывают на IP-адрес обратного прокси. Автоматический выпуск сертификата до изменения записей DNS невозможен. Таким образом, после изменения записей DNS и до выпуска сертификата ваш ресурс будет недоступен пользователям по протоколу HTTPS. Если вам необходимо, чтобы он стал доступен сразу после изменения записей DNS и обновления кешей, рекомендуется заранее получить и загрузить сертификат в хранилище в ручном режиме.

Ручное добавление файлов в хранилище сертификатовРучное добавление файлов в хранилище сертификатов

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

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

Данные можно добавить как через личный кабинет, так и через API-методы certrequest_upload, certrequest_install и sni_link_add. Поддерживаются сертификаты X.509 в формате PEM. В качестве контейнерных форматов поддерживаются pem, cer, crt, der, p7b, p7c, p12.

Проксирование HTTP/2Проксирование HTTP/2

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

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

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

Также обратный HTTP-прокси Curator поддерживает технологию HTTP/2 Server Push для упреждающей отправки ресурсов, которые могут потребоваться браузеру позднее. Подробнее см. в разделе HTTP/2 Server Push ниже.

Установление зашифрованного соединенияУстановление зашифрованного соединения

При работе с HTTPS-трафиком обратный прокси:

• Поддерживает следующие алгоритмы шифрования (cipher suites) для соединений с пользователями:

  Версии TLS	Алгоритмы шифрования
  TLS 1.0, 1.1, 1.2	ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 AES128-GCM-SHA256 AES128-SHA256 AES128-SHA DES-CBC3-SHA
  TLS 1.3	TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256

  Примечание

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

• Поддерживает все возможные алгоритмы и все версии TLS для соединений с апстримом. Подлинность апстрима не проверяется.

Оптимизация скоростиОптимизация скорости

Обратный HTTP-прокси Curator позволяет оптимизировать работу с соединениями за счёт нескольких технологий:

• Постоянные соединения с апстримом
• TLS offloading
• HTTP/2 Server Push

Постоянные соединения с апстримомПостоянные соединения с апстримом

При обработке HTTP-запроса посетителя сайта существенное время тратится на установление транспортной TCP-сессии. Если используется протокол HTTPS, то после создания каждой новой TCP-сессии выполняется TLS-рукопожатие (TLS handshake) и генерация сессионного ключа, что также занимает существенное время.

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

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

TLS offloadingTLS offloading

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

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

HTTP/2 Server PushHTTP/2 Server Push

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

Однако, поскольку обратный прокси и апстрим соединяются с использованием протокола HTTP/1.1, апстрим не может инициировать Server Push напрямую. Чтобы воспользоваться возможностью Server Push, настройте ваш веб-сервер так, чтобы в его ответах содержались HTTP-заголовки Link (RFC 5988) с параметром rel=preload. К одному ответу сервера можно добавить несколько заголовков Link.

Пример заголовка:

Link: </style.css>; as=style; rel=preload

Обнаружив в ответе такой заголовок, обратный прокси Curator запросит у апстрима указанный ресурс (в данном примере — файл стилей /style.css) и направит его пользователю с помощью HTTP/2 Server Push.