Jak działa brama aplikacji

  • 11/16/2019
  • 4 minuty na przeczytanie
    • a
    • j
    • . D
    • s
    • v
    • +2

Ten artykuł wyjaśnia, w jaki sposób brama aplikacji przyjmuje przychodzące żądania i kieruje je do backendu.

Jak brama aplikacji przyjmuje żądanie

Jak brama aplikacji przyjmuje żądanie

  1. Przed wysłaniem przez klienta żądania do bramy aplikacji, rozwiązuje on nazwę domeny bramy aplikacji za pomocą serwera Domain Name System (DNS). Azure kontroluje wpis DNS, ponieważ wszystkie bramy aplikacji znajdują się w domenie azure.com.

  2. Serwer DNS Azure zwraca klientowi adres IP, który jest frontendowym adresem IP bramy aplikacji.

  3. Brama aplikacji akceptuje ruch przychodzący na jednym lub większej liczbie listenerów. Słuchacz jest logiczną jednostką, która sprawdza żądania połączenia. Jest on skonfigurowany z adresem IP frontu, protokołem i numerem portu dla połączeń od klientów do bramy aplikacji.

  4. Jeśli używana jest zapora aplikacji internetowych (WAF), brama aplikacji sprawdza nagłówki żądań i treść, jeśli są obecne, pod kątem reguł WAF. Ta czynność określa, czy żądanie jest żądaniem ważnym, czy stanowi zagrożenie bezpieczeństwa. Jeśli żądanie jest ważne, jest ono kierowane do backendu. Jeśli żądanie nie jest ważne, a WAF działa w trybie zapobiegania, jest ono blokowane jako zagrożenie bezpieczeństwa. Jeśli działa w trybie wykrywania, żądanie jest analizowane i rejestrowane, ale nadal kierowane do serwera backendu.

Azure Application Gateway może być używany jako wewnętrzny load balancer aplikacji lub jako load balancer aplikacji skierowanych do Internetu. Brama aplikacji działająca w Internecie używa publicznych adresów IP. Nazwa DNS bramy aplikacji działającej w Internecie jest publicznie rozwiązywalna z jej publicznym adresem IP. W rezultacie bramy aplikacji działające w Internecie mogą kierować żądania klientów z Internetu.

Wewnętrzne bramy aplikacji używają tylko prywatnych adresów IP. Jeśli używasz niestandardowej lub prywatnej strefy DNS, nazwa domeny powinna być wewnętrznie rozwiązywalna z prywatnym adresem IP bramy aplikacji. Dlatego wewnętrzne load-balancery mogą kierować żądania tylko od klientów z dostępem do sieci wirtualnej dla bramy aplikacji.

Jak brama aplikacji kieruje żądanie

Jeśli żądanie jest ważne i nie zostało zablokowane przez WAF, brama aplikacji ocenia regułę kierowania żądania, która jest powiązana z listenerem. Ta czynność określa, do której puli backendu skierować żądanie.

W oparciu o regułę routingu żądań brama aplikacji określa, czy skierować wszystkie żądania na listenerze do określonej puli backendu, skierować żądania do różnych puli backendu na podstawie ścieżki URL lub przekierować żądania do innego portu lub witryny zewnętrznej.

Uwaga

Reguły są przetwarzane w kolejności, w jakiej są wymienione w portalu dla v1 SKU.

Gdy brama aplikacji wybiera pulę backendu, wysyła żądanie do jednego ze zdrowych serwerów backendu w puli (y.y.y.y). Stan zdrowia serwera jest określany za pomocą sondy stanu. Jeśli pula backendów zawiera wiele serwerów, brama aplikacji używa algorytmu round-robin do kierowania żądań między zdrowymi serwerami. W ten sposób równoważone jest obciążenie serwerów żądaniami.

Po określeniu przez bramę aplikacji serwera zaplecza otwiera ona nową sesję TCP z serwerem zaplecza na podstawie ustawień HTTP. Ustawienia HTTP określają protokół, port i inne ustawienia związane z trasowaniem, które są wymagane do ustanowienia nowej sesji z serwerem backend.

Port i protokół używane w ustawieniach HTTP określają, czy ruch między bramą aplikacji a serwerami backend jest szyfrowany (dzięki czemu uzyskuje się end-to-end TLS), czy jest nieszyfrowany.

Gdy brama aplikacji wysyła oryginalne żądanie do serwera zaplecza, honoruje wszelkie niestandardowe konfiguracje dokonane w ustawieniach HTTP związane z nadpisywaniem nazwy hosta, ścieżki i protokołu. Ta akcja utrzymuje powiązanie sesji oparte na plikach cookie, opróżnianie połączenia, wybór nazwy hosta z backendu i tak dalej.

Uwaga

Jeśli pula backendu:

  • jest publicznym punktem końcowym, brama aplikacji używa swojego publicznego IP frontend, aby dotrzeć do serwera. Jeśli nie ma publicznego adresu IP, jest on przydzielany dla połączeń zewnętrznych outbound.
  • Zawiera wewnętrznie rozwiązywalny FQDN lub prywatny adres IP, brama aplikacji kieruje żądanie do serwera backend przy użyciu prywatnych adresów IP instancji.
  • Zawiera zewnętrzny punkt końcowy lub zewnętrznie rozwiązywalny FQDN, brama aplikacji kieruje żądanie do serwera backend przy użyciu jego publicznego adresu IP frontend. Rozdzielczość DNS jest oparta na prywatnej strefie DNS lub niestandardowym serwerze DNS, jeśli jest skonfigurowany, lub używa domyślnego DNS dostarczonego przez Azure. Jeśli nie ma publicznego adresu IP frontendu, jest on przypisywany dla połączeń zewnętrznych outbound.

Modyfikacje żądania

Brama aplikacji wstawia cztery dodatkowe nagłówki do wszystkich żądań, zanim przekaże je do backendu. Te nagłówki to x-forwarded-for, x-forwarded-proto, x-forwarded-port, i x-original-host. Format nagłówka x-forwarded-for to oddzielona przecinkami lista IP:port.

Poprawne wartości dla x-forwarded-proto to HTTP lub HTTPS. X-forwarded-port określa port, na którym żądanie dotarło do bramy aplikacji. Nagłówek X-original-host zawiera oryginalny nagłówek hosta, z którym dotarło żądanie. Nagłówek ten jest przydatny w integracji witryn Azure, gdzie przychodzący nagłówek hosta jest modyfikowany zanim ruch zostanie skierowany do backendu. Jeśli powiązanie sesji jest włączone jako opcja, dodaje ono cookie powiązania zarządzane przez bramę.

Można skonfigurować bramę aplikacji do modyfikowania nagłówków żądania i odpowiedzi oraz adresu URL za pomocą funkcji Rewrite HTTP headers and URL lub do modyfikowania ścieżki URI za pomocą ustawienia path-override. Jednakże, jeśli nie zostanie to skonfigurowane, wszystkie przychodzące żądania są proxy do backendu.

Naucz się o komponentach bramy aplikacji

.

Dodaj komentarz