Veelgestelde vragen over Azure Front Door

Azure Front Door is een cloudservice die uw toepassingen sneller en betrouwbaarder levert. Het maakt gebruik van taakverdeling op laag 7 om verkeer over meerdere regio's en eindpunten te verdelen. Het biedt ook dynamische siteversnelling (DSA) voor het optimaliseren van webprestaties en bijna realtime-failover om hoge beschikbaarheid te garanderen. Azure Front Door is een volledig beheerde service, dus u hoeft zich geen zorgen te maken over schalen of onderhoud.

Azure Front Door is een service die veel voordelen biedt voor uw webtoepassingen, zoals dynamische siteversnelling (DSA), die de prestaties en gebruikerservaring van uw sites verbetert. Azure Front Door verwerkt ook TLS/SSL-offloading en end-to-end TLS, wat de beveiliging en versleuteling van uw webverkeer verbetert. Daarnaast biedt Azure Front Door Web Application Firewall, sessieaffiniteit op basis van cookies, routering op basis van URL-pad, gratis certificaten en meerdere domeinbeheer, en meer. Zie de vergelijking van lagen voor meer informatie over de functies en mogelijkheden van Azure Front Door.

Azure Front Door en Azure-toepassing Gateway zijn beide load balancers voor HTTP/HTTPS-verkeer, maar ze hebben verschillende bereiken. Front Door is een wereldwijde service die aanvragen over regio's kan distribueren, terwijl Application Gateway een regionale service is die aanvragen binnen een regio kan verdelen. Azure Front Door werkt met schaaleenheden, clusters of stempeleenheden, terwijl Azure-toepassing Gateway werkt met VM's, containers of andere resources in dezelfde schaaleenheid.

Application Gateway achter Front Door is handig in deze situaties:

• U wilt niet alleen het verkeer wereldwijd verdelen, maar ook binnen uw virtuele netwerk. Front Door kan alleen taakverdeling op basis van paden uitvoeren op globaal niveau, maar Application Gateway kan dit doen in uw virtuele netwerk.
• U hebt verbindingsafvoer nodig, die Front Door niet ondersteunt. Application Gateway kan verbindingsafvoer inschakelen voor uw VM's of containers.
• U wilt alle TLS/SSL-verwerking offloaden en alleen HTTP-aanvragen in uw virtuele netwerk gebruiken. Application Gateway achter Front Door kan deze installatie bereiken.
• U wilt sessieaffiniteit gebruiken op zowel regionaal als serverniveau. Front Door kan het verkeer van een gebruikerssessie verzenden naar dezelfde back-end in een regio, maar Application Gateway kan het verzenden naar dezelfde server in de back-end.

Het koppelen van twee CDN's is over het algemeen geen aanbevolen benadering, maar wordt geleverd met de volgende nadelen

1. De laatste mijlversnelling van CDN maakt gebruik van het houden van de verbindingsstroom met de oorsprong en het vinden van een optimaal pad naar de oorsprong om de beste resultaten te behalen. Als u twee CDN's koppelt, worden doorgaans enkele voordelen van last mile acceleration genegeerd.
2. Beveiligingsmaatregelen worden minder effectief op het tweede CDN. Alle client-IP-gebaseerde ACLing werkt niet op het tweede CDN, omdat het tweede CDN het afsluitknooppunt van het eerste CDN ziet als client-IP-adressen. De nettolading van inhoud wordt nog steeds geïnspecteerd.
3. Veel organisaties kunnen niet omgaan met de complexiteit van het oplossen van problemen met twee CDN's die worden gekoppeld en wanneer een probleem moeilijk wordt om erachter te komen welke CDN het probleem ondervindt.

Als u Azure Front Door wilt gebruiken, moet u een openbaar VIP of een DNS-naam hebben die openbaar toegankelijk is. Azure Front Door gebruikt het openbare IP-adres om het verkeer naar uw oorsprong te routeren. Een veelvoorkomend scenario is het implementeren van een Azure Load Balancer achter Front Door. U kunt Private Link ook gebruiken met Azure Front Door Premium om verbinding te maken met een interne load balancer. Zie Private Link inschakelen met een interne load balancer voor meer informatie.

Azure Front Door ondersteunt HTTP, HTTPS en HTTP/2.

Azure Front Door ondersteunt het HTTP/2-protocol voor clientverbindingen. De communicatie van de back-endpool maakt echter gebruik van het HTTP/1.1-protocol. HTTP/2-ondersteuning is standaard ingeschakeld.

U kunt verschillende soorten origins gebruiken voor Azure Front Door, zoals:

• Opslag (Azure Blob, Klassiek, Statische websites)
• Cloudservice
• App Service
• Statische web-app
• API Management
• Application Gateway
• Openbaar IP-adres
• Azure Spring Apps
• Container Instances
• Container Apps
• Elke aangepaste hostnaam met openbare toegang.

De oorsprong moet een openbaar IP-adres of een DNS-hostnaam hebben die openbaar kan worden omgezet. U kunt back-ends uit verschillende zones, regio's of zelfs buiten Azure combineren, zolang ze openbaar toegankelijk zijn.

Azure Front Door is niet beperkt tot een Azure-regio, maar werkt wereldwijd. De enige locatie die u moet kiezen wanneer u een Front Door maakt, is de locatie van de resourcegroep, die bepaalt waar de metagegevens van de resourcegroep worden opgeslagen. Het Front Door-profiel is een wereldwijde resource en de configuratie wordt gedistribueerd naar alle edge-locaties wereldwijd.

Zie Azure Front Door POP-locaties voor een volledige lijst met aanwezigheidspunten die wereldwijde taakverdeling en contentlevering bieden voor Azure Front Door. Deze lijst wordt regelmatig bijgewerkt omdat er nieuwe POP's worden toegevoegd of verwijderd. U kunt ook de Azure Resource Manager-API gebruiken om programmatisch een query uit te voeren op de huidige lijst met POP's.

Azure Front Door is een service die uw toepassing wereldwijd distribueert over meerdere regio's. Het maakt gebruik van een algemene infrastructuur die wordt gedeeld door alle klanten, maar u kunt uw eigen Front Door-profiel aanpassen om de specifieke vereisten van uw toepassing te configureren. De configuraties van andere klanten kunnen geen invloed hebben op uw Front Door-configuratie, die is geïsoleerd van hun configuratie.

U kunt host-, pad- en queryreeksonderdelen van een URL omleiden met Azure Front Door. Raadpleeg URL-omleiding voor meer informatie over het configureren van URL-omleiding.

Front Door sorteert de routes voor uw webtoepassing niet. In plaats daarvan kiest het de route die het beste past bij de aanvraag. Zie Hoe Front Door aanvragen voor routes matcht met aanvragen voor een routeringsregel.

Om optimale prestaties van de functies van Front Door te garanderen, moet u alleen verkeer toestaan dat afkomstig is van Azure Front Door om uw oorsprong te bereiken. Als gevolg hiervan worden niet-geautoriseerde of schadelijke aanvragen geconfronteerd met het beveiligings- en routeringsbeleid van Front Door en worden de toegang geweigerd. Zie Verkeer beveiligen naar Azure Front Door-origins voor meer informatie over het beveiligen van uw oorsprong.

Het IP-adres van de front-end-anycast van uw Front Door is opgelost en kan niet veranderen zolang u de Front Door gebruikt. Het vaste IP-adres van de front-end-anycast van uw Front Door is echter geen garantie. Vermijd het rechtstreeks vertrouwen op het IP-adres.

Azure Front Door is een dynamische service waarmee verkeer wordt gerouteerd naar de beste beschikbare back-end. Het biedt momenteel geen statische of toegewezen front-end-IP's voorcast-IP's.

Ja. Raadpleeg de eigenschap MatchedRulesSetName onder Access-logboeken.

Ja. Zie Microsoft-reactie op DDoS-aanvallen tegen HTTP/2 voor meer informatie.

Azure Front Door ondersteunt de headers X-Forwarded-For, X-Forwarded-Host en X-Forwarded-Proto. Deze headers helpen Front Door het oorspronkelijke IP-adres en protocol van de client te identificeren. Als X-Forwarded-For al aanwezig is, voegt Front Door het IP-adres van de clientsocket toe aan het einde van de lijst. Anders wordt de header met het IP-adres van de clientsocket gemaakt als de waarde. Voor X-Forwarded-Host en X-Forwarded-Proto vervangt Front Door de bestaande waarden door een eigen waarde.

Zie Ondersteunde HTTP-headers van Front Door voor meer informatie.

De implementatietijd voor nieuwe Front Door-configuraties is afhankelijk van het type wijziging. Normaal gesproken duurt het 3 tot 20 minuten voordat de wijzigingen zijn doorgegeven aan al onze edge-locaties wereldwijd.

Updates voor routes of oorspronkelijke groepen/back-endpools zijn naadloos en veroorzaken geen downtime (ervan uitgaande dat de nieuwe configuratie juist is). Certificaatupdates worden ook atomisch uitgevoerd, dus er is geen risico op uitval.

Nee Momenteel ondersteunt Azure Front Door alleen HTTP/1.1 van de rand naar de oorsprong. Voor gebruik van gRPC is HTTP/2 vereist.

• Front Door Standard-/Premium- en Azure CDN-profielen kunnen zonder downtime worden verplaatst tussen resourcegroepen of abonnementen. Volg deze instructies om de verplaatsing uit te voeren.
• Front Door Classic biedt geen ondersteuning voor het verplaatsen tussen resourcegroepen of abonnementen. U kunt in plaats daarvan het klassieke profiel migreren naar Standard/Premium en vervolgens de verplaatsing uitvoeren.
• Als de klant WAF heeft gekoppeld aan de Front Door Standard/Premium, mislukt de verplaatsingsbewerking. De klant moet eerst WAF-beleid ontkoppelen, verplaatsen en vervolgens koppelen.

Als u de Azure Front Door Standard-, Premium- of (klassieke) laag wilt gebruiken, hebt u een openbaar IP-adres of een DNS-naam nodig die openbaar kan worden omgezet. Met deze vereiste van een openbaar IP-adres of een DNS-naam die openbaar kan worden omgezet, kan Azure Front Door verkeer routeren naar uw back-endbronnen. U kunt Azure-resources zoals Application Gateways of Azure Load Balancers gebruiken om verkeer naar resources in een virtueel netwerk te routeren. Als u de Front Door Premium-laag gebruikt, kunt u Private Link gebruiken om verbinding te maken met oorsprongen achter een interne load balancer met een privé-eindpunt. Zie Veilige origins met Private Link voor meer informatie.

Een origin-groep is een verzameling origins die vergelijkbare typen aanvragen kan verwerken. U hebt een andere oorsprongsgroep nodig voor elke toepassing of workload die anders is.

In een origin-groep maakt u een origin voor elke server of service die aanvragen kan verwerken. Als uw oorsprong een load balancer heeft, zoals Azure-toepassing Gateway, of wordt gehost op een PaaS met een load balancer, heeft de oorspronkelijke groep slechts één oorsprong. Uw oorsprong zorgt voor failover en taakverdeling tussen oorsprongen die Front Door niet ziet.

Als u bijvoorbeeld een toepassing op Azure-app Service host, is de wijze waarop u Front Door instelt, afhankelijk van het aantal toepassingsexemplaren dat u hebt:

• Implementatie met één regio: Maak één oorspronkelijke groep. Maak in die oorspronkelijke groep één oorsprong voor de App Service-app. Uw App Service-app kan worden uitgeschaald voor werknemers, maar Front Door ziet één oorsprong.
• Actieve/passieve implementatie voor meerdere regio's: Maak één oorsprongsgroep. Maak in die oorspronkelijke groep een oorsprong voor elke App Service-app. Stel de prioriteit van elke origin in zodat de hoofdtoepassing een hogere prioriteit heeft dan de back-uptoepassing.
• Actieve/actieve implementatie voor meerdere regio's: Maak één origin-groep. Maak in die oorspronkelijke groep een oorsprong voor elke App Service-app. Stel de prioriteit van elke oorsprong in op dezelfde. Stel het gewicht van elke oorsprong in om te bepalen hoeveel aanvragen naar die oorsprong gaan.

Zie Origins- en origin-groepen in Azure Front Door voor meer informatie.

Azure Front Door is een service die snelle en betrouwbare weblevering biedt voor uw toepassingen. Het biedt functies zoals caching, taakverdeling, beveiliging en routering. U moet echter rekening houden met enkele time-outs en limieten die van toepassing zijn op Azure Front Door. Deze time-outs en limieten omvatten de maximale aanvraaggrootte, de maximale antwoordgrootte, de maximale headergrootte, het maximum aantal headers, het maximum aantal regels en het maximum aantal oorspronkelijke groepen. U vindt de gedetailleerde informatie over deze time-outs en limieten in de Documentatie van Azure Front Door.

De configuratie-updates voor de meeste regelsets worden in minder dan 20 minuten uitgevoerd. De regel wordt direct toegepast nadat de update is voltooid.

Azure Front Door en Azure CDN zijn twee services die snelle en betrouwbare weblevering bieden voor uw toepassingen. Ze zijn echter niet compatibel met elkaar, omdat ze hetzelfde netwerk van Azure Edge-sites delen om inhoud aan uw gebruikers te leveren. Dit gedeelde netwerk veroorzaakt conflicten tussen hun routerings- en cachebeleid. Daarom moet u Azure Front Door of Azure CDN kiezen voor uw toepassing, afhankelijk van uw prestatie- en beveiligingsvereisten.

Het feit dat beide profielen dezelfde Azure Edge-sites gebruiken om binnenkomende aanvragen af te handelen, zorgt voor deze beperking, waardoor u geen Azure Front Door-profiel achter elkaar kunt nesten. Deze installatie veroorzaakt routeringsconflicten en prestatieproblemen. Daarom moet u ervoor zorgen dat uw Azure Front Door-profielen onafhankelijk zijn en niet aan elkaar zijn gekoppeld als u meerdere profielen voor uw toepassingen moet gebruiken.

Azure Front Door gebruikt drie servicetags om het verkeer tussen uw clients en uw oorsprongen te beheren:

• De AzureFrontDoor.Backend-servicetag bevat de IP-adressen die Front Door gebruikt om toegang te krijgen tot uw origins. U kunt deze servicetag toepassen wanneer u beveiliging voor uw origins configureert.
• De servicetag AzureFrontDoor.Frontend bevat de IP-adressen die clients gebruiken om Front Door te bereiken. U kunt de AzureFrontDoor.Frontend servicetag toepassen wanneer u het uitgaande verkeer wilt beheren dat verbinding kan maken met services achter Azure Front Door.
• De servicetag AzureFrontDoor.FirstParty is gereserveerd voor een selecte groep Microsoft-services gehost op Azure Front Door.

Zie de beschikbare servicetags voor meer informatie over azure Front Door-servicetags.

Azure Front Door heeft een time-out van 5 seconden voor het ontvangen van headers van de client. De verbinding wordt beëindigd als de client na het tot stand brengen van tcp/TLS-verbinding geen headers binnen 5 seconden naar Azure Front Door verzendt. U kunt deze time-outwaarde niet configureren.

Azure Front Door heeft een time-out van 90 seconden http-keep-alive. De verbinding wordt beëindigd als de client gedurende 90 seconden geen gegevens verzendt. Dit is de TIME-out voor HTTP-keep-alive voor Azure Front Door. U kunt deze time-outwaarde niet configureren.

U kunt niet dezelfde domeinen gebruiken voor meer dan één Front Door-eindpunt, omdat Front Door de route (protocol + host + padcombinatie) voor elke aanvraag moet onderscheiden. Als u dubbele routes hebt voor verschillende eindpunten, kan Azure Front Door de aanvragen niet correct verwerken.

Op dit moment bieden we niet de mogelijkheid om domeinen van het ene eindpunt naar het andere te verplaatsen zonder onderbreking van de service. U moet enige downtime plannen als u uw domeinen naar een ander eindpunt wilt migreren.

De functie Azure Front Door Private Link is regioneutraal en werkt zelfs als u een regio kiest die verschilt van de regio waar uw oorsprong zich bevindt. In dergelijke gevallen moet u, om een lagere latentie te garanderen, altijd een Azure-regio kiezen die het dichtst bij uw oorsprong ligt bij het inschakelen van een Azure Front Door Private Link-eindpunt. We zijn bezig met het inschakelen van ondersteuning voor meer regio's. Zodra een nieuwe regio wordt ondersteund, kunt u deze instructies volgen om het verkeer geleidelijk naar de nieuwe regio te verplaatsen.

Azure Front Door is een platform dat verkeer over de hele wereld distribueert en omhoog kan schalen om te voldoen aan de eisen van uw toepassing. Het maakt gebruik van de wereldwijde netwerkrand van Microsoft om globale taakverdelingsmogelijkheden te bieden waarmee u uw hele toepassing of specifieke microservices kunt overschakelen naar verschillende regio's of clouds als er een storing is opgetreden.

Als u fouten wilt voorkomen bij het leveren van grote bestanden, moet u ervoor zorgen dat de oorspronkelijke server de Content-Range header in het antwoord bevat en dat de headerwaarde overeenkomt met de werkelijke grootte van de hoofdtekst van het antwoord.

Meer informatie over het configureren van uw oorsprong en Front Door voor het leveren van grote bestanden vindt u in Levering van grote bestanden.

Domeinfronting is een netwerktechniek waarmee een aanvaller de werkelijke bestemming van een schadelijke aanvraag kan verbergen met behulp van een andere domeinnaam in de TLS-handshake en de HTTP-hostheader.

Azure Front Door -resources (Standard, Premium en Klassiek) of Azure CDN Standard van Microsoft -resources (klassiek) die zijn gemaakt na 8 november 2022, hebben blokkering van domeinfronting ingeschakeld. In plaats van een aanvraag met niet-overeenkomende SNI- en hostheaders te blokkeren, staan we de discrepantie toe als de twee domeinen deel uitmaken van hetzelfde abonnement en zijn opgenomen in de routes/routeringsregels. Blokkering van domeinfronting begint op 22 januari 2024 voor alle bestaande domeinen. Het afdwingen kan tot twee weken duren voordat ze worden doorgegeven aan alle regio's.

Wanneer Front Door een aanvraag blokkeert vanwege een niet-overeenkomende aanvraag:

• De client ontvangt een HTTP-foutcodeantwoord 421 Misdirected Request .
• Azure Front Door registreert het blok in de diagnostische logboeken onder de eigenschap Foutinformatie met de waarde SSLMismatchedSNI.

Zie Het beveiligen van onze benadering van domeinfronting in Azure en het verbieden van domeinfronting op Azure Front Door en Azure CDN Standard van Microsoft (klassiek) voor meer informatie over domeinfronting.

Front Door gebruikt TLS 1.2 als minimale versie voor alle profielen die na september 2019 zijn gemaakt.

U kunt ervoor kiezen om TLS 1.0, 1.1, 1.2 of 1.3 te gebruiken met Azure Front Door. Lees het end-to-end TLS-artikel van Azure Front Door voor meer informatie.

Azure Front Door is een service die snelle en veilige weblevering biedt. Hiermee kunt u definiëren hoe uw webverkeer wordt gerouteerd en geoptimaliseerd voor meerdere regio's en eindpunten. Azure Front Door-resources, zoals Front Door-profielen en routeringsregels, worden alleen in rekening gebracht wanneer ze zijn ingeschakeld. WaF-beleidsregels en -regels (Web Application Firewall) worden echter in rekening gebracht, ongeacht hun status. Zelfs als u een WAF-beleid of -regel uitschakelt, worden er nog steeds kosten voor u in rekening gebracht.

Nee

Nee

AFD biedt geen ondersteuning voor dynamische compressie voor inhoud die groter is dan 8 MB. Als de inhoud echter al is gecomprimeerd door de oorsprong, biedt Front Door ondersteuning voor het leveren van statische gecomprimeerde inhoud van meer dan 8 MB zolang de bereikaanvraag wordt ondersteund en gesegmenteerde overdrachtscodering niet is ingeschakeld.

Nee

Zie Metrische gegevens en logboeken bewaken voor Front Door voor informatie over logboeken en andere diagnostische mogelijkheden.

U kunt diagnostische logboeken opslaan in hun eigen opslagaccount en kiezen hoe lang ze moeten worden bewaard. U kunt ook diagnostische logboeken verzenden naar Event Hubs- of Azure Monitor-logboeken. Zie Diagnostische gegevens van Azure Front Door voor meer informatie.

Als u toegang wilt krijgen tot de auditlogboeken van Azure Front Door, moet u de portal bezoeken. Selecteer uw Front Door op de menupagina en selecteer activiteitenlogboek. Het activiteitenlogboek bevat de records van de bewerkingen van Uw Azure Front Door.

U kunt waarschuwingen voor Azure Front Door instellen op basis van metrische gegevens of logboeken. Hierdoor kunt u de prestaties en status van uw front-endhosts bewaken.

Zie Waarschuwingen configureren voor meer informatie over het maken van waarschuwingen voor Azure Front Door Standard en Premium.

Volgende stappen

• Meer informatie over het maken van een Azure Front Door-profiel .
• Meer informatie over de Azure Front Door-architectuur.