Cum funcționează o pasarelă de aplicații

• 11/16/2019
• 4 minute de citit
• • a
  • j
  • . D
  • s
  • v
  • +2

Acest articol explică modul în care un gateway de aplicații acceptă cererile primite și le direcționează către backend.

Cum acceptă o cerere un gateway de aplicații

1. Înainte ca un client să trimită o cerere către un gateway de aplicații, acesta rezolvă numele de domeniu al gateway-ului de aplicații prin utilizarea unui server DNS (Domain Name System). Azure controlează intrarea DNS, deoarece toate gateway-urile de aplicații se află în domeniul azure.com.

2. Serviciul Azure DNS returnează clientului adresa IP, care este adresa IP frontală a gateway-ului de aplicații.

3. Pasarela de aplicații acceptă traficul de intrare pe unul sau mai mulți ascultători. Un ascultător este o entitate logică care verifică cererile de conectare. Acesta este configurat cu o adresă IP frontală, un protocol și un număr de port pentru conexiunile de la clienți către gateway-ul de aplicații.

4. Dacă se utilizează un firewall pentru aplicații web (WAF), gateway-ul de aplicații verifică anteturile cererii și corpul, dacă este prezent, în funcție de regulile WAF. Această acțiune determină dacă cererea este o cerere validă sau o amenințare la adresa securității. Dacă cererea este validă, aceasta este direcționată către backend. În cazul în care cererea nu este validă și WAF este în modul de prevenire, aceasta este blocată ca amenințare la adresa securității. Dacă este în modul Detection (Detecție), cererea este evaluată și înregistrată, dar este în continuare redirecționată către serverul backend.

Azure Application Gateway poate fi utilizat ca un load balancer de aplicații interne sau ca un load balancer de aplicații orientate către internet. Un gateway de aplicații orientat spre internet utilizează adrese IP publice. Numele DNS al unui gateway de aplicații orientat către internet poate fi rezolvat public la adresa IP publică a acestuia. Ca urmare, gateway-urile de aplicații orientate spre internet pot direcționa solicitările clienților de pe internet.

Pasarele de aplicații interne utilizează numai adrese IP private. Dacă utilizați o zonă DNS personalizată sau privată, numele de domeniu trebuie să poată fi rezolvat intern la adresa IP privată a gateway-ului de aplicații. Prin urmare, distribuitoarele de sarcină interne pot ruta numai cererile de la clienții care au acces la o rețea virtuală pentru gateway-ul de aplicații.

Cum rutează un gateway de aplicații o cerere

Dacă o cerere este validă și nu este blocată de WAF, gateway-ul de aplicații evaluează regula de rutare a cererii care este asociată cu ascultătorul. Această acțiune determină către ce pool de backend să direcționeze solicitarea.

Pe baza regulii de direcționare a solicitării, gateway-ul de aplicații determină dacă direcționează toate solicitările de pe ascultător către un pool de backend specific, direcționează solicitările către diferite pool-uri de backend pe baza căii URL sau redirecționează solicitările către un alt port sau site extern.

Când gateway-ul aplicației selectează pool-ul backend, acesta trimite cererea către unul dintre serverele backend sănătoase din pool (y.y.y.y.y). Starea de sănătate a serverului este determinată de o sondă de sănătate. În cazul în care pool-ul backend conține mai multe servere, gateway-ul aplicației utilizează un algoritm round-robin pentru a direcționa cererile între serverele sănătoase. Acest lucru echilibrează sarcina solicitărilor pe servere.

După ce gateway-ul aplicației determină serverul backend, acesta deschide o nouă sesiune TCP cu serverul backend pe baza setărilor HTTP. Setările HTTP specifică protocolul, portul și alte setări legate de rutare care sunt necesare pentru a stabili o nouă sesiune cu serverul backend.

Portul și protocolul utilizate în setările HTTP determină dacă traficul dintre gateway-ul de aplicații și serverele backend este criptat (realizând astfel TLS de la un capăt la altul) sau este necriptat.

Când o pasarelă de aplicații trimite cererea inițială către serverul backend, aceasta onorează orice configurație personalizată efectuată în setările HTTP referitoare la înlocuirea numelui de gazdă, a căii și a protocolului. Această acțiune menține afinitatea sesiunii bazată pe cookie-uri, epuizarea conexiunii, selectarea numelui de gazdă din backend și așa mai departe.

Modificări la cerere

Un gateway de aplicații inserează patru antetări suplimentare la toate cererile înainte de a transmite cererile către backend. Aceste antete sunt x-forwarded-for, x-forwarded-proto, x-forwarded-port și x-original-host. Formatul pentru antetul x-forwarded-for este o listă separată prin virgulă de IP:port.

Valorile valabile pentru x-forwarded-proto sunt HTTP sau HTTPS. X-forwarded-port specifică portul prin care cererea a ajuns la gateway-ul aplicației. Antetul X-original-host conține antetul original al gazdei cu care a sosit cererea. Acest antet este util în cadrul integrării site-ului web Azure, unde antetul de gazdă care sosește este modificat înainte ca traficul să fie direcționat către backend. Dacă afinitatea sesiunii este activată ca opțiune, atunci se adaugă un cookie de afinitate gestionat de gateway.

Puteți configura gateway-ul de aplicații pentru a modifica antetele de cerere și de răspuns și URL-ul prin utilizarea Rewrite HTTP headers and URL sau pentru a modifica calea URI prin utilizarea unei setări de suprapunere a căii. Cu toate acestea, dacă nu sunt configurate în acest sens, toate cererile primite sunt redirecționate către backend.

Învățați despre componentele gateway-ului de aplicații

.