- 11/16/2019
- 4 minutes to read
-
-
a -
j -
D -
s -
v -
+2
-
Ez a cikk elmagyarázza, hogyan fogadja egy alkalmazáskapu a bejövő kéréseket, és továbbítja azokat a backendhez.
Hogyan fogad el egy alkalmazáskapu egy kérést
-
Mielőtt egy ügyfél kérést küld egy alkalmazáskapunak, egy DNS-kiszolgáló (Domain Name System) segítségével feloldja az alkalmazáskapu tartománynevét. Az Azure ellenőrzi a DNS-bejegyzést, mivel minden alkalmazáskapu az azure.com tartományban található.
-
Az Azure DNS visszaadja az IP-címet az ügyfélnek, amely az alkalmazáskapu frontend IP-címe.
-
Az alkalmazáskapu egy vagy több figyelőn fogadja a bejövő forgalmat. A figyelő egy logikai egység, amely ellenőrzi a kapcsolati kéréseket. Egy frontend IP-címmel, protokollal és portszámmal van konfigurálva az ügyfelektől az alkalmazás-átjáróhoz érkező kapcsolatokhoz.
-
Ha webalkalmazási tűzfal (WAF) van használatban, az alkalmazás-átjáró ellenőrzi a kérés fejléceit és a testet, ha van, a WAF-szabályok alapján. Ez a művelet határozza meg, hogy a kérés érvényes kérés vagy biztonsági fenyegetés. Ha a kérés érvényes, a rendszer továbbítja a backendhez. Ha a kérés nem érvényes, és a WAF megelőzési üzemmódban van, akkor biztonsági fenyegetésként blokkolva van. Ha Érzékelési módban van, a kérés kiértékelésre és naplózásra kerül, de továbbra is továbbításra kerül a backend-kiszolgálóra.
AzAzure Application Gateway belső alkalmazás-terheléselosztóként vagy internetre néző alkalmazás-terheléselosztóként is használható. Az internetre néző alkalmazás-átjáró nyilvános IP-címeket használ. Az internetre néző alkalmazás-átjáró DNS-neve nyilvánosan feloldható a nyilvános IP-címére. Ennek eredményeképpen az internetre néző alkalmazás-átjárók továbbíthatják az internetről érkező ügyfélkéréseket.
A belső alkalmazás-átjárók csak privát IP-címeket használnak. Ha egyéni vagy privát DNS-zónát használ, a tartománynévnek belsőleg feloldhatónak kell lennie az alkalmazáskapu privát IP-címére. Ezért a belső terheléselosztók csak az alkalmazás-átjáró virtuális hálózatához hozzáférő ügyfelek kéréseit tudják továbbítani.
Hogyan irányítja az alkalmazás-átjáró a kéréseket
Ha egy kérés érvényes és a WAF nem blokkolja, az alkalmazás-átjáró kiértékeli a kérésirányítási szabályt, amely a hallgatóhoz tartozik. Ez a művelet határozza meg, hogy melyik backend-poolba irányítsa a kérést.
A kérésirányítási szabály alapján az alkalmazáskapu meghatározza, hogy a hallgató összes kérését egy adott backend-poolba irányítsa, a kéréseket az URL-útvonal alapján különböző backend-poolokba irányítsa, vagy a kéréseket egy másik portra vagy külső webhelyre irányítsa át.
Megjegyzés
A szabályok feldolgozása a v1 SKU portálon felsorolt sorrendben történik.
Amikor az alkalmazás-átjáró kiválasztja a backend-poolt, a kérést a poolban lévő egészséges backend-kiszolgálók egyikére küldi (y.y.y.y.y). A kiszolgáló egészségi állapotát egy állapotszonda határozza meg. Ha a backend-pool több kiszolgálót tartalmaz, az alkalmazás-átjáró körkörös algoritmust használ a kérések egészséges kiszolgálók közötti továbbítására. Ez kiegyensúlyozza a kérések terhelését a kiszolgálókon.
Az alkalmazás-átjáró a backend-kiszolgáló meghatározása után a HTTP-beállítások alapján új TCP-munkamenetet nyit a backend-kiszolgálóval. A HTTP-beállítások megadják a protokollt, a portot és az útválasztással kapcsolatos egyéb beállításokat, amelyek a háttértár-kiszolgálóval való új munkamenet létrehozásához szükségesek.
A HTTP-beállításokban használt port és protokoll határozza meg, hogy az alkalmazás-átjáró és a háttértár-kiszolgálók közötti forgalom titkosított (így valósul meg a végponttól-végpontig TLS) vagy titkosítatlan.
Amikor az alkalmazás-átjáró elküldi az eredeti kérést a backend-kiszolgálónak, tiszteletben tartja a HTTP-beállításokban a hostnév, az elérési útvonal és a protokoll felülbírálásával kapcsolatban elvégzett egyéni konfigurációt. Ez a művelet fenntartja a cookie-alapú munkamenet-affinitást, a kapcsolat lemerítését, az állomásnév kiválasztását a backendről és így tovább.
Figyelem
Ha a backend pool:
- nyilvános végpont, az alkalmazás-átjáró a frontend nyilvános IP-címét használja a kiszolgáló eléréséhez. Ha nincs nyilvános frontend IP-cím, akkor a kimenő külső kapcsolathoz rendel egyet.
- Tartalmaz egy belső feloldható FQDN-t vagy egy privát IP-címet, az alkalmazáskapu a kérést a backend-kiszolgálóhoz a példány privát IP-címeinek használatával irányítja.
- Tartalmaz egy külső végpontot vagy egy külső feloldható FQDN-t, az alkalmazáskapu a kérést a frontend nyilvános IP-címének használatával irányítja a backend-kiszolgálóhoz. A DNS-feloldás egy privát DNS-zónán vagy egyéni DNS-kiszolgálón alapul, ha be van állítva, vagy az Azure által biztosított alapértelmezett DNS-t használja. Ha nincs nyilvános frontend IP-cím, akkor a kimenő külső kapcsolathoz rendel egyet.
Módosítások a kéréshez
Az alkalmazás-átjáró minden kéréshez négy további fejlécet illeszt, mielőtt továbbítja a kéréseket a backendhez. Ezek a fejlécek az x-forwarded-for, x-forwarded-proto, x-forwarded-port és x-original-host. Az x-forwarded-for fejléc formátuma az IP:port vesszővel elválasztott listája.
Az x-forwarded-proto érvényes értékei a HTTP vagy a HTTPS. Az x-forwarded-port azt a portot adja meg, amelyen a kérés az alkalmazás átjárójához érkezett. Az X-original-host fejléc tartalmazza az eredeti host fejlécet, amellyel a kérés érkezett. Ez a fejléc hasznos az Azure weboldal-integrációban, ahol a bejövő host fejléc módosul, mielőtt a forgalom a backend felé továbbításra kerül. Ha a munkamenet-affinitás opcióként engedélyezve van, akkor hozzáad egy átjáró által kezelt affinitási sütit.
Az alkalmazás-átjárót úgy konfigurálhatja, hogy a Rewrite HTTP headers and URL használatával módosítsa a kérés és a válasz fejléceit és az URL-t, vagy a path-override beállítással módosítsa az URI útvonalát. Ha azonban nincs ilyen beállítás, akkor minden bejövő kérést proxyként továbbít a backend felé.
Tudjon meg többet az alkalmazáskapu összetevőiről
.