funkcje usługi aplikacja systemu Azure Gateway

Usługa Azure Application Gateway to moduł równoważenia obciążenia ruchu internetowego, który umożliwia zarządzanie ruchem kierowanym do aplikacji internetowych.

Application Gateway conceptual

Uwaga

W przypadku obciążeń internetowych zdecydowanie zalecamy korzystanie z ochrony przed atakami DDoS platformy Azure i zapory aplikacji internetowej w celu ochrony przed pojawiającymi się atakami DDoS. Inną opcją jest zastosowanie usługi Azure Front Door wraz z zaporą aplikacji internetowej. Usługa Azure Front Door oferuje ochronę na poziomie platformy przed atakami DDoS na poziomie sieci. Aby uzyskać więcej informacji, zobacz Punkt odniesienia zabezpieczeń dla usług platformy Azure.

Usługa Application Gateway obejmuje następujące funkcje:

Kończenie żądań protokołu SSL/TLS (Secure Sockets Layer)

Usługa Application Gateway obsługuje kończenie żądań SSL/TLS w bramie, po czym ruch zwykle przepływa niezaszyfrowany do serwerów zaplecza. Ta funkcja umożliwia odciążenie serwerów sieci Web z nadmiaru kosztownych operacji szyfrowania i odszyfrowywania. Jednak czasami niezaszyfrowana komunikacja z serwerami nie jest akceptowalną opcją. Może to być spowodowane wymaganiami dotyczącymi zabezpieczeń, wymaganiami dotyczącymi zgodności lub aplikacją może zaakceptować tylko bezpieczne połączenie. W przypadku tych aplikacji usługa Application Gateway obsługuje kompleksowe szyfrowanie SSL/TLS.

Aby uzyskać więcej informacji, zobacz Overview of SSL termination and end to end SSL with Application Gateway (Omówienie kończenia żądań protokołu SSL i kompleksowej usługi SSL w usłudze Application Gateway)

Skalowanie automatyczne

Usługa Application Gateway Standard_v2 obsługuje skalowanie automatyczne i umożliwia skalowanie w górę lub w dół na podstawie zmieniających się wzorców obciążenia ruchu. Dzięki skalowaniu automatycznemu nie trzeba również wybierać rozmiaru wdrożenia ani liczby wystąpień podczas aprowizowania usługi.

Aby uzyskać więcej informacji na temat funkcji usługi Application Gateway Standard_v2, zobacz Co to jest aplikacja systemu Azure Gateway w wersji 2.

Nadmiarowość stref

Usługa Standard_v2 Application Gateway może obejmować wiele Strefy dostępności, zapewniając lepszą odporność błędów i usuwając konieczność aprowizacji oddzielnych bram aplikacji w każdej strefie.

Statyczny adres VIP

Jednostka SKU Standard_v2 bramy aplikacji obsługuje wyłącznie statyczny typ adresu VIP. Dzięki temu adres VIP skojarzony z bramą aplikacji nie zmienia się nawet w okresie istnienia usługi Application Gateway.

Web Application Firewall

Zapora aplikacji internetowej to usługa, która zapewnia scentralizowaną ochronę aplikacji internetowych przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach. Zapora aplikacji internetowej jest oparta na regułach z podstawowych zestawów reguł OWASP (Open Web Application Security Project) 3.1 (tylko WAF_v2), 3.0 i 2.2.9.

Aplikacje internetowe coraz częściej stają się obiektami złośliwych ataków wykorzystujących znane luki w zabezpieczeniach. Wśród nich często zdarzają się np. ataki polegające na iniekcji SQL i ataki z użyciem skryptów wykorzystywanych w wielu witrynach. Zapobieganie takim atakom z poziomu kodu aplikacji może być trudne. Może też wymagać rygorystycznego przestrzegania harmonogramu konserwacji, poprawek i monitorowania na wielu warstwach topologii aplikacji. Scentralizowana zapora aplikacji internetowej ułatwia zarządzanie zabezpieczeniami oraz zapewnia lepszą ochronę administratorów aplikacji przed zagrożeniami i intruzami. Zapora aplikacji internetowej może reagować na zagrożenia bezpieczeństwa szybciej — poprzez wdrażanie poprawek zapobiegających wykorzystaniu znanych luk w zabezpieczeniach w centralnej lokalizacji zamiast w poszczególnych aplikacjach internetowych. Istniejące bramy aplikacji można łatwo przekonwertować na bramę aplikacji z włączoną zaporą aplikacji internetowej.

Zapoznaj się z tematem Ochrona przed atakami DDoS aplikacji, aby uzyskać wskazówki dotyczące używania zapory aplikacji internetowej platformy Azure z usługą Application Gateway w celu ochrony przed atakami DDoS. Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Web Application Firewall.

Kontroler ruchu przychodzącego dla usługi AKS

Kontroler ruchu przychodzącego usługi Application Gateway (AGIC) umożliwia używanie usługi Application Gateway jako ruchu przychodzącego dla klastra usługi Azure Kubernetes Service (AKS).

Kontroler ruchu przychodzącego działa jako zasobnik w klastrze usługi AKS i korzysta z zasobów ruchu przychodzącego Kubernetes i konwertuje je na konfigurację usługi Application Gateway, co umożliwia bramie równoważenie obciążenia ruchu do zasobników Kubernetes. Kontroler ruchu przychodzącego obsługuje tylko jednostki SKU usługi Application Gateway Standard_v2 i WAF_v2.

Aby uzyskać więcej informacji, zobacz Application Gateway Ingress Controller (AGIC).

Routing oparty na adresach URL

Routing oparty na ścieżkach URL umożliwia kierowanie ruchu do pul serwerów zaplecza na podstawie ścieżek URL żądania. Jeden ze scenariuszy polega na kierowaniu żądań dla różnych typów zawartości do różnych pul.

Na przykład żądania dotyczące adresu http://contoso.com/video/* są kierowane do puli VideoServerPool, a żądania dotyczące adresu http://contoso.com/images/* — do puli ImageServerPool. Pula DefaultServerPool jest wybierana, jeśli żaden z wzorców ścieżki nie pasuje.

Aby uzyskać więcej informacji, zobacz Omówienie routingu opartego na ścieżkach URL.

Hostowanie wielu witryn

Za pomocą usługi Application Gateway można skonfigurować routing na podstawie nazwy hosta lub nazwy domeny dla więcej niż jednej aplikacji internetowej w tej samej bramie aplikacji. Ta funkcja umożliwia skonfigurowanie bardziej wydajnej topologii dla wdrożeń przez dodanie nawet ponad 100 witryn internetowych do jednej bramy aplikacji. Każdą witrynę sieci Web można skierować do jej puli zaplecza. Na przykład trzy domeny — contoso.com, fabrikam.com i adatum.com — wskazują adres IP bramy aplikacji. Utworzysz trzy odbiorniki obejmujące wiele witryn i skonfigurujesz każdy odbiornik dla odpowiedniego portu i ustawienia protokołu.

Żądania dotyczące http://contoso.com żądania są kierowane do puli ContosoServerPool, http://fabrikam.com są kierowane do puli FabrikamServerPool itd.

Podobnie dwie domeny podrzędne tej samej domeny nadrzędnej mogą być hostowane w ramach tego samego wdrożenia usługi Application Gateway. Przykłady użycia domen podrzędnych mogą obejmować domeny podrzędne http://blog.contoso.com i http://app.contoso.com hostowane w ramach jednego wdrożenia usługi Application Gateway. Aby uzyskać więcej informacji, zobacz Hostowanie wielu witryn w usłudze Application Gateway.

Możesz również określić nazwy hosta z symbolami wieloznacznymi w odbiorniku obejmującym wiele witryn, z maksymalnie pięcioma nazwami hostów na odbiornik. Aby dowiedzieć się więcej, zobacz nazwy hostów z symbolami wieloznacznymi w odbiorniku.

Przekierowania

Typowy scenariusz dla wielu aplikacji internetowych obejmuje obsługę automatycznego przekierowania protokołu HTTP do HTTPS, aby zagwarantować, że cała komunikacja między aplikacją a jej użytkownikami odbywa się za pośrednictwem ścieżki szyfrowanej.

W przeszłości można było użyć technik, takich jak tworzenie dedykowanej puli, których jedynym celem jest przekierowywanie żądań odbieranych przez protokół HTTP do protokołu HTTPS. Usługa Application Gateway obsługuje możliwość przekierowywania ruchu sieciowego w tej usłudze. Upraszcza to konfigurację aplikacji, optymalizuje wykorzystanie zasobów i umożliwia obsługę nowych scenariuszy przekierowania, w tym przekierowania globalnego i opartego na ścieżce. Obsługa przekierowania usługi Application Gateway nie jest ograniczona tylko do przekierowania HTTP do protokołu HTTPS. Jest to ogólny mechanizm przekierowania, dzięki czemu możliwe jest przekierowanie z i do dowolnego portu zdefiniowanego przy użyciu reguł. Obsługiwane jest również przekierowanie do zewnętrznej witryny.

Obsługa przekierowania dla usługi Application Gateway oferuje następujące możliwości:

  • Globalne przekierowanie z jednego portu do innego portu w bramie. Umożliwia to przekierowanie protokołu HTTP do HTTPS w witrynie.
  • Przekierowanie na podstawie ścieżki. Ten typ przekierowania umożliwia przekierowanie protokołu HTTP do HTTPS tylko w określonym obszarze witryny, na przykład obszarze koszyka określonym przez element /cart/*.
  • Przekierowanie do zewnętrznej witryny.

Aby uzyskać więcej informacji, zobacz Omówienie przekierowania usługi Application Gateway.

Koligacja sesji

Funkcja koligacji sesji na podstawie plików cookie jest przydatna, gdy chcesz zachować sesję użytkownika na tym samym serwerze. Korzystając z plików cookie zarządzanych przez bramę, usługa Application Gateway może kierować kolejny ruch z sesji użytkownika do tego samego serwera do przetwarzania. Jest to ważne w przypadkach, w których stan sesji jest zapisywany lokalnie na serwerze dla sesji użytkownika.

Aby uzyskać więcej informacji, zobacz Jak działa brama aplikacji.

Ruch protokołów WebSocket i HTTP/2

Usługa Application Gateway zapewnia natywną obsługę protokołów WebSocket i HTTP/2. Nie ma żadnych ustawień konfigurowanych przez użytkownika umożliwiających selektywne włączenie lub wyłączenie obsługi protokołu WebSocket.

Protokoły WebSocket i HTTP/2 umożliwiają pełnodupleksową komunikację między serwerem i klientem przez długotrwałe połączenie TCP. Pozwala to na bardziej interaktywną komunikację między serwerem internetowym a klientem, która może być dwukierunkowa bez konieczności sondowania, co jest wymagane w implementacjach opartych na protokole HTTP. Te protokoły mają niskie obciążenie, w przeciwieństwie do protokołu HTTP, i mogą ponownie używać tego samego połączenia TCP dla wielu żądań/odpowiedzi, co powoduje bardziej wydajne wykorzystanie zasobów. Te protokoły są przeznaczone do pracy z użyciem tradycyjnych portów HTTP, tj. 80 i 443.

Aby uzyskać więcej informacji, zobacz Obsługa protokołu WebSocket i obsługa protokołu HTTP/2.

Opróżnianie połączeń

Połączenie opróżnianie jonów pomaga w bezproblemowym usuwaniu elementów członkowskich puli zaplecza podczas planowanych aktualizacji usługi lub problemów z kondycją zaplecza. To ustawienie jest włączone za pośrednictwem ustawienia zaplecza i jest stosowane do wszystkich elementów członkowskich puli zaplecza podczas tworzenia reguły. Po włączeniu brama aplikacji gwarantuje, że wszystkie wyrejestrowane wystąpienia puli zaplecza nie otrzymają żadnych nowych żądań, zezwalając na ukończenie istniejących żądań w ramach skonfigurowanego limitu czasu. Dotyczy to przypadków, w których wystąpienia zaplecza to:

  • jawnie usunięte z puli zaplecza po zmianie konfiguracji przez użytkownika
  • zgłaszane jako w złej kondycji przez sondy kondycji lub
  • usunięto podczas operacji skalowania w poziomie

Jedynym wyjątkiem jest to, że żądania nadal są kierowane do wyrejestrowania wystąpień z powodu koligacji sesji zarządzanej przez bramę.

Opróżnianie połączenia jest również uznawane za połączenia WebSocket. Połączenie opróżnianie jest wywoływane dla każdej pojedynczej aktualizacji bramy. Aby zapobiec utracie połączenia istniejącym członkom puli zaplecza, upewnij się, że włączono opróżnianie połączeń.

Aby uzyskać informacje na temat limitów czasu, zobacz Konfigurowanie Ustawienia zaplecza.

Niestandardowe strony błędów

Usługa Application Gateway umożliwia tworzenie niestandardowych stron błędów wyświetlanych zamiast domyślnych strony błędów. W przypadku niestandardowych stron błędów możesz użyć własnych oznakowań i układu.

Aby uzyskać więcej informacji, zobacz Błędy niestandardowe.

Ponowne zapisywanie nagłówków HTTP i adresów URL

Nagłówki HTTP umożliwiają klientowi i serwerowi przekazywanie dodatkowych informacji z żądaniem lub odpowiedzią. Ponowne zapisywanie tych nagłówków HTTP ułatwia wykonanie kilku ważnych scenariuszy, takich jak:

  • Dodawanie pól nagłówków związanych z zabezpieczeniami, takich jak HSTS/X-XSS-Protection.
  • Usuwanie pól nagłówka odpowiedzi, które mogą ujawniać poufne informacje.
  • Usuwanie informacji o porcie z nagłówków X-Forwarded-For.

Usługa Application Gateway i jednostka SKU zapory aplikacji internetowej w wersji 2 obsługują możliwość dodawania, usuwania lub aktualizowania nagłówków żądań HTTP i odpowiedzi, podczas gdy pakiety żądań i odpowiedzi są przenoszone między pulami klienta i zaplecza. Można też ponownie zapisywać adresy URL, parametry ciągu zapytania i nazwę hosta. W przypadku ponownego zapisywania adresów URL i routingu opartego na ścieżkach URL można wybrać kierowanie żądań do jednej z pul zaplecza na podstawie oryginalnej ścieżki lub ścieżki przepisanej przy użyciu opcji ponownej oceny mapy ścieżki.

Ta funkcja umożliwia też dodawanie warunków w celu zapewnienia, że określone nagłówki lub adres URL zostaną zapisane ponownie tylko po spełnieniu określonych warunków. Te warunki są oparte na informacjach dotyczących żądania i odpowiedzi.

Aby uzyskać więcej informacji, zobacz Ponowne zapisywanie nagłówków HTTP i adresów URL.

Szacowanie zapotrzebowania na elementy infrastruktury

Standard_v2 usługi Application Gateway można skonfigurować na potrzeby skalowania automatycznego lub wdrożenia o stałym rozmiarze. Jednostka SKU w wersji 2 nie oferuje różnych rozmiarów wystąpień. Aby uzyskać więcej informacji na temat wydajności i cen w wersji 2, zobacz Autoskalowanie w wersji 2 i Informacje o cenach.

Usługa Application Gateway Standard (wersja 1) jest oferowana w trzech rozmiarach: Mały, Średni i Duży. Rozmiary małych wystąpień są przeznaczone na potrzeby programowania i scenariuszy testowania.

Pełna lista limitów usługi Application Gateway znajduje się na stronie ograniczeń usługi Application Gateway.

W poniższej tabeli przedstawiono średnią przepływność wydajności dla każdego wystąpienia bramy aplikacji w wersji 1 z włączonym odciążaniem SSL:

Średni rozmiar odpowiedzi strony zaplecza Mały Śred. Duży
6 KB 7,5 Mb/s 13 Mb/s 50 Mb/s
100 KB 35 Mb/s 100 Mb/s 200 Mb/s

Uwaga

Są to przybliżone wartości przepływności bramy aplikacji. Rzeczywista przepływność zależy od różnych szczegółów środowiska, takich jak średni rozmiar strony, lokalizacja wystąpień zaplecza i czas przetwarzania w celu obsłużenia strony. Aby uzyskać dokładne wartości wydajności, należy przeprowadzić własne testy. Te wartości są podane tylko jako wskazówki na potrzeby planowania pojemności.

Porównanie funkcji wersji

Aby zapoznać się z porównaniem funkcji usługi Application Gateway w wersji 1-v2, zobacz Co to jest aplikacja systemu Azure Gateway w wersji 2.

Następne kroki