Поделиться через

Маршрутизация входящих запросов

  • Статья

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

  • +: регистрация портов помещается в контейнер "Сильный подстановочный знак"

  • host: регистрация портов помещается в контейнер "Явный"

  • IP: регистрация портов помещается в контейнер "Слабый подстановочный знак с привязкой IP-адресов"

  • * : регистрация портов помещается в контейнер "Слабый подстановочный знак"

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

Алгоритм маршрутизации API HTTP-сервера находит лучшее соответствие для UrlPrefix путем поиска как записей регистрации, так и записей резервирования базы данных маршрутизации, начиная с сильного контейнера подстановочных знаков и заканчивая слабым подстановочными знаками. Лучшее совпадение в контейнере — это самое длинное совпадение в относительной части URI URLPrefix (при условии точного соответствия для узлов, портов и схем URL-адреса). После обнаружения совпадения в контейнере алгоритм маршрутизации останавливает поиск и пропускает все сегменты с низким приоритетом.

Например, рассмотрим следующие регистрации (перечисленные в порядке убывания приоритета на основе типов контейнеров:

  • Регистрация: https://+:80/vroot/ зарегистрировано приложением 1

  • Регистрация: https://adatum.com:80/ зарегистрировано приложением 2

  • Регистрация: https://\*:80/ зарегистрировано приложением 3

Входящие запросы на https://adatum.com:80/vroot/subdir/file.htm/ доставляются приложению 1. Входящие запросы для https://adatum.com:80/default.htm/ доставляются в приложение 2. Входящие запросы для https://otheradatum.com:80/file.htm/ доставляются приложению 3.

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

  • Регистрация: https://\*:80/vroot/ зарегистрировано приложением 1, пользователем A

  • Резервирование: https://adatum.com:80/ зарезервировано для пользователя B

Входящие запросы на https://adatum.com:80/vroot/file.htm/ не доставляются приложению 1, так как лучшее совпадение приводит к записи резервирования для пользователя B. Правила приоритета применяются в этом случае к резервированию с более высоким приоритетом. Если процесс не активен и зарегистрирован в запросах службы для полученного URL-адреса, запрос отклоняется с кодом состояния 400 (недопустимый запрос).