Udostępnij za pośrednictwem

Funkcje usługi Azure Application 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.

Pojęcie dotyczące Application Gateway

Uwaga / Notatka

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 podstawę bezpieczeństwa dla usług Azure.

Application Gateway obejmuje następujące funkcje:

Zakończenie połączenia Secure Sockets Layer (SSL/TLS)

Application Gateway obsługuje zakończenie protokołu SSL/TLS w bramie, po czym ruch zwykle przepływa niezaszyfrowany do serwerów zaplecza. Ta funkcja pozwala odciążyć serwery internetowe od kosztownych kosztów ogólnych związanych z szyfrowaniem i deszyfrowaniem. Czasami jednak nieszyfrowana komunikacja z serwerami nie jest akceptowalną opcją. Może to być spowodowane wymaganiami dotyczącymi zabezpieczeń, wymaganiami dotyczącymi zgodności lub aplikacja może akceptować tylko bezpieczne połączenie. W przypadku tych aplikacji Application Gateway obsługuje kompleksowe szyfrowanie SSL/TLS.

Aby uzyskać więcej informacji, zobacz Omówienie kończenia protokołu SSL i kompleksowego protokołu SSL z Application Gateway

Skalowanie automatyczne

Application Gateway obsługuje Standard_v2 skalowanie automatyczne i może skalować w górę lub w dół na podstawie zmieniających się wzorców obciążenia ruchu. Skalowanie automatyczne eliminuje również wymaganie wybrania rozmiaru wdrożenia lub liczby wystąpień podczas aprowizacji.

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

Redundancja strefowa

Standard_v2 Application Gateway może obejmować wiele Strefy dostępności, oferując lepszą odporność na uszkodzenia i eliminując konieczność aprowizacji oddzielnych Application Gateway w każdej strefie.

Statyczny VIP

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

Zapora aplikacji internetowych

Web Application Firewall (WAF) to usługa, która zapewnia scentralizowaną ochronę aplikacji internetowych przed typowymi programami wykorzystującymi luki 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 są coraz bardziej celem złośliwych ataków, które wykorzystują typowe 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 w kodzie aplikacji może być trudne i może wymagać rygorystycznej konserwacji, stosowania poprawek i monitorowania w wielu warstwach topologii aplikacji. Scentralizowana zapora aplikacji internetowej ułatwia zarządzanie zabezpieczeniami i zapewnia lepszą gwarancję administratorom aplikacji przed zagrożeniami lub włamaniami. Rozwiązanie zapory aplikacji internetowej może również szybciej reagować na zagrożenie bezpieczeństwa, stosując poprawki do znanej luki w zabezpieczeniach w centralnej lokalizacji, w porównaniu do konieczności zabezpieczania każdej z poszczególnych aplikacji internetowych. Istniejące bramy aplikacji można łatwo przekonwertować na bramę aplikacji z obsługą Web Application Firewall.

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

Kontroler ruchu przychodzącego dla usługi AKS

Application Gateway Ingress Controller (AGIC) umożliwia używanie Application Gateway jako ruchu przychodzącego dla klastra Azure Kubernetes Service (AKS).

Kontroler ruchu przychodzącego działa jako zasobnik w klastrze usługi AKS i zużywa zasoby ruchu przychodzącego kubernetes i konwertuje je na konfigurację Application Gateway, która umożliwia bramie równoważenie obciążenia ruchu do zasobników Kubernetes. Kontroler ruchu przychodzącego obsługuje tylko jednostki SKU 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. Jednym ze scenariuszy jest kierowanie żądań dla różnych typów zawartości do innej puli.

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

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

Hostowanie wielu witryn

Za pomocą 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 serwerów 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 są kierowane do puli ContosoServerPool, http://fabrikam.com są kierowane do puli FabrikamServerPool i tak dalej.

Podobnie dwie subdomeny tej samej domeny nadrzędnej mogą być hostowane w tym samym wdrożeniu bramy aplikacji. Przykłady użycia poddomen mogą obejmować http://blog.contoso.com i http://app.contoso.com hostowane w jednym wdrożeniu bramy aplikacji. 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 nasłuchiwaczu.

Przekierowanie

Typowym scenariuszem dla wielu aplikacji internetowych jest obsługa automatycznego przekierowywania HTTP do HTTPS w celu zapewnienia, że cała komunikacja między aplikacją a jej użytkownikami odbywa się za pośrednictwem zaszyfrowanej ścieżki.

W przeszłości można było używać technik, takich jak tworzenie dedykowanej puli, której jedynym celem jest przekierowywanie żądań odbieranych w protokole HTTP do protokołu HTTPS. Application Gateway obsługuje możliwość przekierowywania ruchu w Application Gateway. Upraszcza to konfigurację aplikacji, optymalizuje użycie zasobów i obsługuje nowe scenariusze przekierowania, w tym przekierowania globalne i oparte na ścieżkach. Application Gateway obsługa przekierowywania nie jest ograniczona do samego przekierowania HTTP do HTTPS. Jest to ogólny mechanizm przekierowania, dzięki czemu można przekierowywać z i do dowolnego portu zdefiniowanego za pomocą reguł. Obsługuje również przekierowanie do witryny zewnętrznej.

Application Gateway obsługa przekierowywania oferuje następujące możliwości:

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

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

Afiniczność 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ę, Application Gateway może kierować kolejny ruch z sesji użytkownika do tego samego serwera w celu przetworzenia. 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 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ą komunikację w trybie pełnego dupleksu między serwerem a klientem za pośrednictwem długotrwałego połączenia TCP. Pozwala to na bardziej interaktywną komunikację między serwerem WWW a klientem, która może być dwukierunkowa bez konieczności sondowania, co jest wymagane w implementacjach opartych na protokole HTTP. Protokoły te 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 skutkuje bardziej efektywnym wykorzystaniem zasobów. Te protokoły są przeznaczone do pracy nad tradycyjnymi portami HTTP 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ń

Opróżnianie połączeń pomaga osiągnąć bezpieczne usuwanie elementów członkowskich puli zaplecza podczas planowanych aktualizacji usług lub problemów z kondycją zaplecza. To ustawienie jest włączane 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 zapewnia, że wszystkie wyrejestrowane wystąpienia puli zaplecza nie otrzymują żadnych nowych żądań, jednocześnie zezwalając istniejącym żądaniom na ukończenie w skonfigurowanym limicie czasu. Dotyczy to przypadków, w których wystąpienia zaplecza są jawnie usuwane z puli zaplecza po zmianie konfiguracji przez użytkownika.

Opróżnianie połączeń jest również honorowane w przypadku połączeń protokołu WebSocket. Opróżnianie połączenia jest wywoływane dla każdej aktualizacji bramy. Aby zapobiec utracie połączenia z istniejącymi elementami członkowskimi puli zaplecza, upewnij się, że włączono opróżnianie połączeń.

Aby uzyskać więcej informacji, zobacz Konfiguracja ustawień zaplecza.

Niestandardowe strony błędów

Usługa Application Gateway umożliwia tworzenie niestandardowych stron błędów zamiast wyświetlania domyślnych stron błędów. Możesz użyć własnego znakowania firmowego i układu za pomocą niestandardowej strony błędu.

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

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

Nagłówki HTTP pozwalają klientowi i serwerowi przesyłać dodatkowe informacje wraz z żądaniem lub odpowiedzią. Ponowne zapisywanie tych nagłówków HTTP pomaga w realizacji kilku ważnych scenariuszy, takich jak:

  • Dodawanie pól nagłówka 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 portach z nagłówków X-Forwarded-For.

Application Gateway i jednostka SKU zapory aplikacji internetowej w wersji 2 obsługuje możliwość dodawania, usuwania lub aktualizowania nagłówków żądań i odpowiedzi HTTP, podczas gdy pakiety żądań i odpowiedzi są przenoszone między pulami klientów 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 adresów URL można wybrać kierowanie żądań do jednej z pul zaplecza na podstawie oryginalnej ścieżki lub ponownie zapisanej ścieżki 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.

Rozmiary

Application Gateway Standard_v2 można skonfigurować do skalowania automatycznego lub wdrożeń 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 Skalowanie automatyczne w wersji 2 i Opis cen.

Application Gateway Standard (v1) jest oferowany w trzech rozmiarach: małym, średnim i dużym. Małe rozmiary instancji są przeznaczone do scenariuszy programistycznych i testowych.

Aby uzyskać pełną listę limitów bramy aplikacji, zobacz Application Gateway limity usługi.

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 protokołu SSL:

Średni rozmiar odpowiedzi strony zaplecza Mały Średni 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 / Notatka

Te wartości są przybliżonymi wartościami 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ługi strony. Aby uzyskać dokładne dane dotyczące wydajności, należy przeprowadzić własne testy. Te wartości są podane tylko w celu uzyskania wskazówek dotyczących planowania wydajności.

Porównanie funkcji wersji

Aby zapoznać się z porównaniem funkcji Application Gateway v1-v2, zobacz Co to jest Azure Application Gateway v2.

Dalsze kroki