[Документация Yandex Cloud](../../index.md) > [Yandex Application Load Balancer](../index.md) > [Концепции](index.md) > HTTP-роутеры

# HTTP-роутеры

HTTP-роутер определяет правила маршрутизации HTTP-запросов в [группы бэкендов](backend-group.md).

Указывать HTTP-роутеры можно только для [обработчиков](application-load-balancer.md#listener) типа **HTTP**. Если обработчик принимает <q>чистый</q> TCP-трафик (тип **Stream**), то для него напрямую указывается группа бэкендов.

Если HTTP-роутер используется хотя бы в одном балансировщике, удалить его нельзя. Сначала [удалите](../operations/application-load-balancer-update.md) его из всех балансировщиков.

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

Маршруты внутри HTTP-роутера объединены в [виртуальные хосты](#virtual-host). Маршрутизация происходит в два этапа.

1. На основе заголовка `Host` (`:authority` в случае HTTP/2) выбирается наиболее подходящий виртуальный хост. 

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

## Виртуальные хосты {#virtual-host}

Виртуальные хосты объединяют [маршруты](#routes), относящиеся к одному набору доменов — значений заголовков `Host` (`:authority`) HTTP-запроса. Поддерживаются как точные совпадения, так и символы подстановки. При получении входящего запроса балансировщик по очереди проверяет предикаты маршрутов и выбирает первый, удовлетворяющий запросу.

Балансировщик направляет трафик на [бэкенд](backend-group.md), который указывает на различные ресурсы. Эти ресурсы могут быть подвержены внешним угрозам. Вы можете защитить ресурсы с помощью сервиса [Yandex Smart Web Security](../../smartwebsecurity/concepts/index.md), подключив [профиль безопасности](../../smartwebsecurity/operations/host-connect.md) к виртуальному хосту. Также вы можете ограничить количество запросов к виртуальному хосту с помощью модуля [Global RateLimit](rate-limiter.md).

Если балансировщик управляется [Ingress-контроллером](../tools/k8s-ingress-controller/index.md) Application Load Balancer, то подключать профиль безопасности следует с помощью [аннотации ресурса Ingress](../k8s-ref/ingress.md#annot-security-profile-id).

Также на уровне виртуального хоста настраиваются модификации HTTP-заголовков запросов и ответов.

## Маршруты {#routes}

Маршруты состоят из набора условий (предиката), на основании которых балансировщик выбирает маршрут для запроса, и действия над запросом. Доступные условия и действия зависят от типа маршрута.

### Типы маршрутов {#routes-types}

HTTP-роутеры поддерживают два типа маршрутов — **HTTP** и **gRPC**:

1. HTTP-маршруты предназначены для обработки HTTP-запросов по протоколам HTTP/1.1 и HTTP/2.

   В качестве условия для маршрута можно указать начало, полный путь запроса или [регулярное выражение](https://ru.wikipedia.org/wiki/Регулярные_выражения) стандарта [RE2](https://github.com/google/re2/wiki/Syntax), а также метод запроса (GET, POST и т. д.).

   С запросом, который удовлетворяет условиям, можно выполнить одно из действий:

   * Передача запроса в [группу бэкендов](backend-group.md) типа **HTTP** для обработки. В этом случае вы можете изменить заголовок `Host` на указанное значение или настроить автоматическую замену на адрес целевой ВМ.

     Помимо заголовка `Host`, вы можете настроить [таймауты](#timeouts) на обработку запроса, добавить поддержку WebSocket, указать протоколы, на которые группа бэкендов может перейти в рамках TCP-соединения по запросу клиента, изменить URI перед передачей запроса в бэкенды.

   * Перенаправление запроса на другой адрес с выбранным кодом ответа и модификациями URI запроса. В этом случае можно заменить путь (полностью или частично), удалить query-параметры, изменить хост, порт и схему.

     Если в качестве условия для маршрута указан полный путь запроса, то заменить только начало пути не получится. Заменится весь путь, даже если в настройках указано изменить только начало.
   
     Если в оригинальном URI использована схема `http` (`https`) и указан порт `80` (`443`), при изменении схемы порт будет удален.
   * Немедленный возврат статического ответа балансировщика на запрос, поступивший по этому маршруту.

1. gRPC-маршруты предназначены для обработки gRPC-запросов ([удалённых вызовов процедур](https://ru.wikipedia.org/wiki/Удалённый_вызов_процедур)) по протоколу HTTP/2.

   В качестве условия для gRPC-маршрута можно указать начало, полное имя метода (FQMN, fully qualified method name) или [регулярное выражение](https://ru.wikipedia.org/wiki/Регулярные_выражения) стандарта [RE2](https://github.com/google/re2/wiki/Syntax). Значение должно начинаться с косой черты `/`.

   С запросом, который удовлетворяет условиям, можно выполнить одно из действий:

   * Передача запроса в [группу бэкендов](backend-group.md) типа **gRPC** для обработки. В этом случае вы можете настроить [таймауты](#timeouts) на обработку запроса и заменить заголовок `Host` на указанное значение или настроить автоматическую замену на адрес целевой ВМ.

   * Немедленный возврат статического ответа.

### Таймауты {#timeouts}

Запрос, который удовлетворяет условиям маршрута, можно передать в группу бэкендов для обработки. В этом случае есть возможность настроить таймауты:

* **Таймаут, с** — максимальное время поддержания HTTP-соединения между узлом балансировщика и бэкендом. Доступно только для групп бэкендов типа HTTP. Значение по умолчанию — `60`.

* **Максимальный таймаут, с** — максимальный период, на который может быть установлено соединение между узлом балансировщика и бэкендом. Доступно только для групп бэкендов типа gRPC. Клиент может указать в запросе HTTP-заголовок `grpc-timeout` с меньшим значением таймаута. Значение по умолчанию — `60`.

* **Таймаут простоя, с** — максимальное время, в течение которого соединение может поддерживаться без передачи данных. Значения по умолчанию нет. Если таймаут не указан, он не учитывается. Таймаут простоя можно использовать в сценариях потоковой передачи (например, для длительных опросов, событий, отправляемых сервером). В некоторых случаях, когда основной таймаут не указан, таймаут простоя может быть установлен автоматически.

Если соединение для групп бэкендов типа HTTP завершится по таймауту, балансировщик вернет код `504 Gateway Timeout`.

## Примеры использования {#examples}

* [Организация виртуального хостинга](../tutorials/virtual-hosting.md)
* [Терминирование TLS-соединений с помощью консоли управления](../tutorials/tls-termination/console.md)
* [Создание L7-балансировщика с защитой от DDoS с помощью консоли управления или CLI](../tutorials/alb-with-ddos-protection/console.md)
* [Миграция сервисов с балансировщика NLB на L7-балансировщик ALB для подключения защиты Yandex Smart Web Security](../tutorials/migration-from-nlb-to-alb/index.md)
* [Интеграция L7-балансировщика с Cloud CDN и Object Storage](../tutorials/cdn-storage-integration/index.md)
* [Организация сине-зеленого и канареечного развертывания версий веб-сервиса](../tutorials/blue-green-canary-deployment.md)
* [Запись логов балансировщика в PostgreSQL](../tutorials/logging.md)
* [Создание L7-балансировщика Application Load Balancer с профилем безопасности Yandex Smart Web Security](../tutorials/balancer-with-sws-profile/index.md)