Configurazione dei listener Attributi del listener Regole dei listener Tipi di operazioni delle regole Tipi di condizioni della regola Intestazioni X-Forwarded

Ascoltatori per Application Load Balancer

Un ascoltatore è un processo che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Prima di iniziare a utilizzare l'Application Load Balancer, è necessario aggiungere almeno un ascoltatore. Se il sistema di bilanciamento del carico non ha un ascoltatore, non può ricevere traffico dai client. Le regole che definisci per i tuoi listener determinano il modo in cui il load balancer indirizza le richieste verso le destinazioni registrate, ad esempio le EC2 istanze.

Indice

Configurazione dei listener

I listener supportano i seguenti protocolli e porte:

Protocolli:, HTTP HTTPS
Porte: 1-65535

È possibile utilizzare un HTTPS listener per affidare il lavoro di crittografia e decrittografia al sistema di bilanciamento del carico, in modo che le applicazioni possano concentrarsi sulla propria logica di business. Se il protocollo listener lo èHTTPS, è necessario distribuire almeno un certificato server sul listener. SSL Per ulteriori informazioni, consulta Crea un HTTPS listener per il tuo Application Load Balancer.

Se devi assicurarti che le destinazioni decrittografino il HTTPS traffico anziché il load balancer, puoi creare un Network Load Balancer con TCP un listener sulla porta 443. Con un TCP listener, il load balancer trasmette il traffico crittografato alle destinazioni senza decrittografarlo. Per ulteriori informazioni, consulta la Guida per l'utente dei Network Load Balancer.

Gli Application Load Balancer forniscono supporto nativo per. WebSockets È possibile aggiornare una connessione HTTP /1.1 esistente in una WebSocket (wsowss) connessione utilizzando un HTTP aggiornamento della connessione. Quando si esegue l'aggiornamento, la TCP connessione utilizzata per le richieste (al sistema di bilanciamento del carico e alla destinazione) diventa una WebSocket connessione persistente tra il client e la destinazione tramite il sistema di bilanciamento del carico. È possibile utilizzare sia WebSockets con gli ascoltatori che con gli HTTP ascoltatoriHTTPS. Le opzioni che scegli per il tuo listener si applicano sia alle WebSocket connessioni che al HTTP traffico. Per ulteriori informazioni, consulta How the WebSocket Protocol Works nella Amazon CloudFront Developer Guide.

Gli Application Load Balancer forniscono supporto nativo per HTTP /2 con listener. HTTPS È possibile inviare fino a 128 richieste in parallelo utilizzando una connessione HTTP /2. È possibile utilizzare la versione del protocollo per inviare la richiesta alle destinazioni utilizzando /2. HTTP Per ulteriori informazioni, consulta Versione del protocollo. Poiché HTTP /2 utilizza le connessioni front-end in modo più efficiente, potresti notare un minor numero di connessioni tra i client e il sistema di bilanciamento del carico. Non è possibile utilizzare la funzionalità server-push di /2. HTTP

Per ulteriori informazioni, consulta Routing della richiesta nella Guida per l'utente di Elastic Load Balancing.

Attributi del listener

Di seguito sono riportati gli attributi del listener per Application Load Balancers

routing.http.request.x_amzn_mtls_clientcert_serial_number.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Mtls-ClientCert-Serial-Number. HTTP
routing.http.request.x_amzn_mtls_clientcert_issuer.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della HTTP richiesta X-Amzn-Mtls-Clientcert-Issuer.
routing.http.request.x_amzn_mtls_clientcert_subject.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Mtls-Clientcert-Sject. HTTP
routing.http.request.x_amzn_mtls_clientcert_validity.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Mtls-Clientcert-Validity. HTTP
routing.http.request.x_amzn_mtls_clientcert_leaf.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Mtls-Clientcert-Leaf. HTTP
routing.http.request.x_amzn_mtls_clientcert.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Mtls-Clientcert. HTTP
routing.http.request.x_amzn_tls_version.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Tls-Version. HTTP
routing.http.request.x_amzn_tls_cipher_suite.header_name: Consente di modificare il nome dell'intestazione dell'intestazione della richiesta X-Amzn-Tls-Cipher-Suite. HTTP
routing.http.response.server.enabled: Consente di consentire o rimuovere l'intestazione del server di risposta. HTTP
routing.http.response.strict_transport_security.header_value: Informa i browser che è necessario accedere al sito solo tramiteHTTPS, e che eventuali futuri tentativi di accedervi utilizzando HTTP dovrebbero essere automaticamente convertiti inHTTPS.
routing.http.response.access_control_allow_origin.header_value: Speciifica a quali origini è consentito l'accesso al server.
routing.http.response.access_control_allow_methods.header_value: Restituisce quali HTTP metodi sono consentiti quando si accede al server da un'origine diversa.
routing.http.response.access_control_allow_headers.header_value: Speciifica quali intestazioni possono essere utilizzate durante la richiesta.
routing.http.response.access_control_allow_credentials.header_value: Indica se il browser deve includere credenziali come i cookie o l'autenticazione quando effettua le richieste.
routing.http.response.access_control_expose_headers.header_value: Restituisce le intestazioni che il browser può esporre al client richiedente.
routing.http.response.access_control_max_age.header_value: Specifica per quanto tempo i risultati di una richiesta di preflight possono essere memorizzati nella cache, in secondi.
routing.http.response.content_security_policy.header_value: Speciifica le restrizioni applicate dal browser per ridurre al minimo il rischio di determinati tipi di minacce alla sicurezza.
routing.http.response.x_content_type_options.header_value: Indica se i MIME tipi pubblicizzati nelle intestazioni Content-Type devono essere seguiti e non modificati.
routing.http.response.x_frame_options.header_value: Indica se il browser è autorizzato a eseguire il rendering di una pagina in un frame, iframe, embed o oggetto.

Regole dei listener

Ogni ascoltatore ha un'operazione predefinita, nota anche come regola predefinita. La regola predefinita non può essere eliminata ed è sempre eseguita per ultima. È possibile creare regole aggiuntive e consistono in una priorità, una o più operazioni e una o più condizioni. Puoi aggiungere o modificare le regole in qualsiasi momento. Per ulteriori informazioni, consulta Modificare una regola.

Regole predefinite

Le operazioni per la regola predefinita vengono definite al momento della creazione del listener. Le regole predefinite non possono avere condizioni. Se non viene soddisfatta nessuna condizione per qualsiasi regola del listener, viene eseguita l'operazione per la regola predefinita.

Di seguito è riportato un esempio di una regola predefinita come illustrato nella console:

Priorità regola

Ogni regola ha una priorità. Le regole vengono valutate in base all'ordine di priorità, dal valore più basso a quello più alto. La regola predefinita è valutata per ultima. È possibile modificare la priorità di una regola non predefinita in qualsiasi momento. Non è possibile modificare la priorità della regola di default. Per ulteriori informazioni, consulta Aggiornare la priorità delle regole.

Operazioni delle regole

Ogni operazione della regola dispone di un tipo, di una priorità e delle informazioni necessarie per eseguire l'operazione. Per ulteriori informazioni, consulta Tipi di operazioni delle regole.

Condizioni della regola

Ogni condizione della regola ha informazioni su tipo e configurazione. Quando le condizioni di una regola vengono soddisfatte, l'operazione viene eseguita. Per ulteriori informazioni, consulta Tipi di condizioni della regola.

Tipi di operazioni delle regole

I tipi di operazione supportati per una regola dell'ascoltatore sono i seguenti:

authenticate-cognito: [HTTPSascoltatori] Usa Amazon Cognito per autenticare gli utenti. Per ulteriori informazioni, consulta Autenticazione degli utenti tramite Application Load Balancer.
authenticate-oidc: [HTTPSlisteners] Utilizzate un provider di identità conforme a OpenID Connect OIDC () per autenticare gli utenti.
fixed-response: Restituisce una risposta personalizzata. HTTP Per ulteriori informazioni, consulta Operazioni con risposta fissa.
forward: Inoltrare le richieste verso il gruppo di destinazioni indicato. Per ulteriori informazioni, consulta Operazioni di inoltro.
redirect: Reindirizza le richieste da una URL all'altra. Per ulteriori informazioni, consulta Operazioni di reindirizzamento.

Viene eseguita per prima l'operazione con priorità minore. Ogni regola deve includere esattamente una delle seguenti operazioni: forward, redirect o fixed-response e deve essere l’ultima operazione da eseguire.

Se la versione del protocollo è g RPC o HTTP /2, le uniche azioni supportate sono forward le azioni.

Operazioni con risposta fissa

È possibile utilizzare fixed-response le azioni per eliminare le richieste dei client e restituire una HTTP risposta personalizzata. È possibile utilizzare questa operazione per inviare un codice di risposta 2XX, 4XX o 5XX e un messaggio opzionale.

Quando viene intrapresa un'fixed-responseazione, l'azione e la destinazione URL del reindirizzamento vengono registrate nei log di accesso. Per ulteriori informazioni, consulta Voci dei log di accesso. Il conteggio delle operazioni fixed-response avvenute con successo viene segnalato dal parametro HTTP_Fixed_Response_Count. Per ulteriori informazioni, consulta Parametri di Application Load Balancer.

Esempio di azione a risposta fissa per AWS CLI

Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. Le seguenti operazioni inviano una risposta fissa con il codice di stato specificato e il corpo del messaggio.


[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

Operazioni di inoltro

È possibile utilizzare le operazioni forward per instradare le richieste a uno o più gruppi di destinazioni. Se si specificano più gruppi di destinazioni per un'operazione forward, è necessario specificare un peso per ciascun gruppo di destinazioni. Ogni peso del gruppo di destinazioni è un valore compreso tra 0 e 999. Le richieste che corrispondono a una regola del listener con gruppi di destinazioni ponderati vengono distribuite a questi gruppi di destinazioni in base ai rispettivi pesi. Ad esempio, se specifichi due gruppi di destinazioni, ciascuno con un peso di 10, ogni gruppo di destinazioni riceve la metà delle richieste. Se specifichi due gruppi di destinazioni, uno con un peso di 10 e l'altro con un peso di 20, il gruppo di destinazioni con un peso di 20 riceve il doppio delle richieste rispetto all'altro gruppo di destinazioni.

Per impostazione predefinita, la configurazione di una regola per distribuire il traffico tra gruppi di destinazioni ponderati non garantisce che le sticky session vengano rispettate. Per garantire che le sticky session siano rispettate, abilitare la persistenza del gruppo di destinazioni per la regola. Quando il load balancer indirizza per la prima volta una richiesta a un gruppo target ponderato, genera un cookie denominato AWSALBTG che codifica le informazioni sul gruppo target selezionato, crittografa il cookie e include il cookie nella risposta al client. Il client deve includere il cookie ricevuto nelle richieste successive al sistema di bilanciamento del carico. Quando il sistema di bilanciamento del carico riceve una richiesta che corrisponde a una regola con la persistenza del gruppo di destinazioni abilitata e contiene il cookie, la richiesta viene instradata al gruppo di destinazioni specificato nel cookie.

Gli Application Load Balancer non supportano i valori dei cookie codificati. URL

Con le richieste CORS (condivisione di risorse tra origini), alcuni browser richiedono SameSite=None; Secure l'attivazione della viscosità. In questo caso, Elastic Load Balancing genera un secondo cookie AWSALBTGCORS, che include le stesse informazioni dello stickiness cookie originale più questo attributo. SameSite I clienti ricevono entrambi i cookie.

Esempio di operazione di inoltro con un gruppo di destinazioni

Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente operazione inoltra le richieste al gruppo di destinazioni specificato.


[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]

Esempio di operazione di inoltro con due gruppi di destinazioni ponderati

L'operazione seguente inoltra le richieste ai due gruppi di destinazioni specificati, in base al peso di ciascun gruppo di destinazioni.


[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]

Esempio di operazione di inoltro con persistenza abilitata

Se si dispone di un'operazione di inoltro con più gruppi di destinazioni e per uno o più gruppi di destinazioni sono abilitate le sessioni permanenti, è necessario abilitare la persistenza del gruppo di destinazioni.

L'operazione seguente inoltra le richieste ai due gruppi di destinazioni specificati, con la persistenza del gruppo di destinazioni abilitata. Le richieste che non contengono il cookie AWSALBTG vengono instradate in base al peso di ciascun gruppo di destinazioni.


[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

Operazioni di reindirizzamento

È possibile utilizzare redirect le azioni per reindirizzare le richieste dei client da una all'altraURL. Puoi configurare i reindirizzamenti come temporanei (HTTP302) o permanenti (HTTP301) in base alle tue esigenze.

A URI è costituito dai seguenti componenti:


protocol://hostname:port/path?query

È necessario modificare almeno uno dei componenti seguenti per evitare un reindirizzamento loop: protocollo, nome host, porta o percorso. I componenti che non vengono modificati mantengono i loro valori originali.

protocol: Il protocollo (HTTPoHTTPS). È possibile HTTP reindirizzare verso HTTPHTTPS, HTTP verso e HTTPS versoHTTPS. Non è possibile reindirizzare HTTPS a. HTTP
hostname: Il nome host. Il nome host non prevede la distinzione tra lettere maiuscole e minuscole, può contenere fino a 128 caratteri di lunghezza e può contenere caratteri alfanumerici, caratteri jolly (* e ?) e trattini (-).
port: La porta (da 1 a 65535).
path: Il percorso assoluto, partendo da "/". Il percorso prevede la distinzione tra lettere maiuscole e minuscole, può contenere fino a 128 caratteri di lunghezza e può contenere caratteri alfanumerici, caratteri jolly (* e ?), & (con &) e i seguenti caratteri speciali: _-.$/~"'@:+
query: I parametri di query La lunghezza massima è 128 caratteri.

È possibile riutilizzare URI i componenti dell'originale URL nella destinazione URL utilizzando le seguenti parole chiave riservate:

#{protocol} - Mantiene il protocollo. Utilizzare nel protocollo e nei componenti query.
#{host} - Mantiene il dominio. Utilizzare nel nome host, nel percorso e nei componenti query.
#{port} - Mantiene la porta. Utilizzare nella porta, nel percorso e nei componenti query.
#{path} - Mantiene il percorso. Utilizzare nel percorso e nei componenti query.
#{query} - Mantiene i parametri di query. Utilizzare nel componente query.

Quando viene eseguita un'operazione redirect, l'operazione viene registrata nei log di accesso. Per ulteriori informazioni, consulta Voci dei log di accesso. Il conteggio delle operazioni redirect avvenute con successo viene segnalato dal parametro HTTP_Redirect_Count. Per ulteriori informazioni, consulta Parametri di Application Load Balancer.

Esempio di operazioni di reindirizzamento tramite la console

La regola seguente imposta un reindirizzamento permanente a un URL che utilizza il HTTPS protocollo e la porta specificata (40443), ma mantiene il nome host, il percorso e i parametri di query originali. Questa schermata è equivalente a "https://#{host}:40443/#{path}?#{query}".

Una regola che reindirizza la richiesta a un indirizzo URL che utilizza il HTTPS protocollo e la porta specificata (40443), ma mantiene il dominio, il percorso e i parametri di query originali dell'originale. URL

La regola seguente imposta un reindirizzamento permanente a un URL che mantiene il protocollo, la porta, il nome host e i parametri di query originali e utilizza la parola chiave per creare un percorso modificato. #{path} Questa schermata è equivalente a "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

Una regola che reindirizza la richiesta a una URL che mantiene il protocollo, la porta, il nome host e i parametri di query originali e utilizza la #{path} parola chiave per creare un percorso modificato.

Esempio di azione di reindirizzamento per AWS CLI

Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. L'azione seguente reindirizza una HTTP richiesta a una HTTPS richiesta sulla porta 443, con lo stesso nome host, percorso e stringa di query della richiesta. HTTP


[
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]

Tipi di condizioni della regola

I tipi di operazione supportati per una regola sono i seguenti:

host-header: Instradamento basato sul nome host di ogni richiesta. Per ulteriori informazioni, consulta Condizioni host.
http-header: Percorso basato sulle HTTP intestazioni di ogni richiesta. Per ulteriori informazioni, consulta HTTPcondizioni dell'intestazione.
http-request-method: Percorso basato sul metodo di HTTP richiesta di ogni richiesta. Per ulteriori informazioni, consulta HTTPcondizioni del metodo di richiesta.
path-pattern: Percorso basato sui modelli di percorso della richiestaURLs. Per ulteriori informazioni, consulta Condizioni percorso.
query-string: Instradamento basato su coppie chiave/valore nelle stringhe di query. Per ulteriori informazioni, consulta Condizioni delle stringhe di query.
source-ip: Instradamento basato sull’indirizzo IP di origine di ogni richiesta. Per ulteriori informazioni, consulta Condizioni indirizzo IP di origine.

Ogni regola può facoltativamente includere al massimo una delle seguenti condizioni: host-header, http-request-method, path-pattern e source-ip. Ogni regola può anche includere facoltativamente una o più delle seguenti condizioni: http-header e query-string.

Puoi specificare fino a tre valutazioni di corrispondenze per condizione. Ad esempio, per ogni http-header condizione, puoi specificare fino a tre stringhe da confrontare con il valore dell'HTTPintestazione nella richiesta. La condizione è soddisfatta se una delle stringhe corrisponde al valore dell'intestazione. HTTP Per fare in modo che tutte le stringhe siano una corrispondenza, crea una condizione per valutazione di corrispondenza.

Puoi specificare fino a cinque valutazioni di corrispondenze per regola. Ad esempio, puoi creare una regola con cinque condizioni in cui ogni condizione ha una valutazione di corrispondenza.

Nelel valutazioni di corripondenza è possibile includere caratteri jolly per le condizioni http-header,host-header, path-pattern e query-string. Esiste un limite di cinque caratteri jolly per regola.

Le regole vengono applicate solo ai ASCII caratteri visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.

Per le demo, consulta Instradamento avanzato delle richieste.

HTTPcondizioni dell'intestazione

È possibile utilizzare le condizioni di HTTP intestazione per configurare le regole che instradano le richieste in base alle HTTP intestazioni della richiesta. È possibile specificare i nomi dei campi di HTTP intestazione standard o personalizzati. Il nome dell'intestazione e la valutazione della corrispondenza non fanno distinzione tra lettere maiuscole e minuscole. I seguenti caratteri jolly sono supportati nelle stringhe di confronto: * (corrisponde a 0 o a più caratteri) e ? (corrisponde esattamente a 1 carattere). I caratteri jolly non sono supportati nel nome dell’intestazione.

Esempio di condizione di HTTP intestazione per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un’intestazione Utente-Agente che corrisponde a una delle stringhe specificate.


[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

HTTPcondizioni del metodo di richiesta

È possibile utilizzare le condizioni del metodo di HTTP richiesta per configurare le regole che instradano le richieste in base al HTTP metodo di richiesta della richiesta. È possibile specificare HTTP metodi standard o personalizzati. La valutazione della corrispondenza prevede la distinzione tra lettere maiuscole e minuscole. I caratteri jolly non sono supportati; pertanto, il nome del metodo deve essere una corrispondenza esatta.

È consigliabile effettuare l'instradamento GET e HEAD le richieste nello stesso modo, poiché la risposta a una HEAD richiesta può essere memorizzata nella cache.

Esempio HTTP di condizione del metodo per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La condizione seguente è soddisfatta dalle richieste che utilizzano il metodo specificato.


[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Condizioni host

È possibile utilizzare le condizioni host per definire regole in grado di inoltrare le richieste in base al nome host nell'intestazione host (noto anche come instradamento basato su host). In questo modo è possibile supportare più sottodomini e domini di primo livello diversi utilizzando un singolo sistema di bilanciamento del carico.

Un nome host non distingue tra maiuscole e minuscole, può avere una lunghezza massima di 128 caratteri e contenere qualsiasi carattere tra i seguenti:

A-Z, a-z, 0-9
- .
* (corrisponde a 0 o più caratteri)
? (corrisponde esattamente a 1 carattere)

Si deve includere il carattere "." almeno una volta. Dopo l'ultimo carattere "." è possibile includere solo caratteri alfabetici.

Esempio di nomi host

example.com
test.example.com
*.example.com

La regola *.example.com si applica a test.example.com ma non a example.com.

Esempio di condizione di intestazione dell'host per AWS CLI


[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Condizioni percorso

È possibile utilizzare le condizioni del percorso per definire regole che instradano le richieste in base a quanto URL contenuto nella richiesta (noto anche come routing basato sul percorso).

Il modello di percorso viene applicato solo al percorso diURL, non ai relativi parametri di query. Viene applicato solo ai ASCII caratteri visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.

La valutazione della regola viene eseguita solo dopo la normalizzazione. URI

Un modello di percorso non distingue tra maiuscole e minuscole, può avere una lunghezza massima di 128 caratteri e contenere qualsiasi carattere tra i seguenti.

A-Z, a-z, 0-9
_ - . $ / ~ " ' @ : +
& (utilizzo di &)
* (corrisponde a 0 o più caratteri)
? (corrisponde esattamente a 1 carattere)

Se la versione del protocollo è gRPC, le condizioni possono essere specifiche di un pacchetto, servizio o metodo.

Esempi di modelli di HTTP percorso

/img/*
/img/*/pics

Esempi di modelli di RPC percorso g

/package
/package.service
/package.service/method

Il modello di percorso viene utilizzato per instradare le richieste, ma non le modifica. Ad esempio, se una regola ha un modello di percorso /img/*, la regola inoltra una richiesta per /img/picture.jpg al gruppo target specificato come una richiesta per /img/picture.jpg.

Esempio di condizione del modello di percorso per AWS CLI


[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Condizioni delle stringhe di query

Puoi usare le condizioni delle stringhe di query per configurare le regole che instradano le richeste in base alle coppie chiave/valore o i valori nella stringa di query. La valutazione della corrispondenza non prevede la distinzione tra lettere maiuscole e minuscole. I seguenti caratteri jolly sono supportati: * (corrisponde a 0 o a più caratteri) e ? (corrisponde esattamente a 1 carattere).

Esempio di condizione della stringa di query per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con una stringa di query che include una coppia chiave/valore di "version=v1" o un set di chiavi impostato su “example”.


[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Condizioni indirizzo IP di origine

Puoi usare le condizioni dell’indirizzo IP di origine per configurare le regole che instradano le richieste in base all’indirizzo IP di origine della richiesta. L'indirizzo IP deve essere specificato nel CIDR formato. È possibile utilizzare entrambi IPv4 gli IPv6 indirizzi. I caratteri jolly non sono supportati. Non è possibile specificare 255.255.255.255/32 CIDR la condizione della regola IP di origine.

Se un client è al di là di un proxy, si tratta dell'indirizzo IP del proxy, non dell'indirizzo IP del client.

Questa condizione non è soddisfatta dagli indirizzi nell' X-Forwarded-Forintestazione. Per cercare gli indirizzi nell' X-Forwarded-Forintestazione, utilizza una http-header condizione.

Esempio di condizione IP di origine per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un indirizzo IP di origine in uno dei CIDR blocchi specificati.


[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]

HTTPheader e Application Load Balancer

HTTPle richieste e HTTP le risposte utilizzano i campi di intestazione per inviare informazioni sui messaggi. HTTP HTTPle intestazioni vengono aggiunte automaticamente. I campi intestazione sono costituti da coppie nome-valore separati da due punti e intervallati da un ritorno a capo e un avanzamento riga. Un set standard di campi di HTTP intestazione è definito in RFC 2616, Message Headers. Sono disponibili anche HTTP intestazioni non standard che vengono aggiunte automaticamente e ampiamente utilizzate dalle applicazioni. Alcune HTTP intestazioni non standard hanno un prefisso. X-Forwarded Gli Application Load Balancer supportano le seguenti intestazioni X-Forwarded.

Per ulteriori informazioni sulle HTTP connessioni, consulta Request routing nella Elastic Load Balancing User Guide.

X-Forwarded-For

L'intestazione della X-Forwarded-For richiesta consente di identificare l'indirizzo IP di un client quando si utilizza un sistema di bilanciamento del carico HTTP oHTTPS. Poiché i sistemi di bilanciamento del carico intercettano il traffico tra client e server, i log di accesso al server contengono solo l'indirizzo IP del sistema di bilanciamento del carico. Per visualizzare l'indirizzo IP del client, utilizza l'attributo routing.http.xff_header_processing.mode. Questo attributo consente di modificare, conservare o rimuovere l'X-Forwarded-Forintestazione nella HTTP richiesta prima che Application Load Balancer invii la richiesta alla destinazione. I valori possibili per questo attributo sono append, preserve e remove. Il valore predefinito per questo attributo è append.

Importante

L'X-Forwarded-Forintestazione deve essere utilizzata con cautela a causa dei potenziali rischi per la sicurezza. Le voci possono essere considerate affidabili solo se aggiunte da sistemi adeguatamente protetti all'interno della rete.

Append

Per impostazione predefinita, Application Load Balancer memorizza l'indirizzo IP del client nell'intestazione della richiesta X-Forwarded-For e passa l'intestazione al server. Se l'intestazione della richiesta X-Forwarded-For non è inclusa nella richiesta originale, il sistema di bilanciamento del carico ne crea una con l'indirizzo IP del client come valore della richiesta. In caso contrario, il load balancer aggiunge l'indirizzo IP del client all'intestazione esistente e quindi passa l'intestazione al server. L'intestazione della richiesta X-Forwarded-For può contenere più indirizzi IP separati da virgole.

L'intestazione della richiesta X-Forwarded-For assume la seguente forma:


X-Forwarded-For: client-ip-address

Di seguito è riportata un'intestazione della richiesta X-Forwarded-For di esempio per un client con l'indirizzo IP 203.0.113.7.


X-Forwarded-For: 203.0.113.7

Di seguito è riportato un esempio di intestazione di X-Forwarded-For richiesta per un client con un indirizzo di. IPv6 2001:DB8::21f:5bff:febf:ce22:8a2e


X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

Quando l'attributo di conservazione della porta del client (routing.http.xff_client_port.enabled) è abilitato nel sistema di bilanciamento del carico, l'intestazione della richiesta X-Forwarded-For include il client-port-number aggiunto al client-ip-address, separato da due punti. L'intestazione assume così la seguente forma:


IPv4 -- X-Forwarded-For: client-ip-address:client-port-number


IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

Si noti IPv6 infatti che quando il sistema di bilanciamento del carico aggiunge il client-ip-address all'intestazione esistente, racchiude l'indirizzo tra parentesi quadre.

Di seguito è riportato un esempio di intestazione di X-Forwarded-For richiesta per un client con un IPv4 indirizzo e un numero di porta di. 12.34.56.78 8080


X-Forwarded-For: 12.34.56.78:8080

Di seguito è riportato un esempio di intestazione di X-Forwarded-For richiesta per un client con un IPv6 indirizzo 2001:db8:85a3:8d3:1319:8a2e:370:7348 e un numero di porta di. 8080


X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Preserve

La preserve modalità dell'attributo garantisce che l'X-Forwarded-Forintestazione della HTTP richiesta non venga modificata in alcun modo prima di essere inviata alle destinazioni.

Rimuovi

La remove modalità dell'attributo rimuove l'X-Forwarded-Forintestazione nella HTTP richiesta prima che venga inviata ai target.

Nota

Se si abilita l'attributo di conservazione della porta del client (routing.http.xff_client_port.enabled) e inoltre si seleziona preserve o remove per l'attributo routing.http.xff_header_processing.mode, l'Application Load Balancer sovrascrive l'attributo di conservazione della porta del client. Mantiene l'intestazione X-Forwarded-For invariata o la rimuove, a seconda della modalità selezionata, prima di inviarla alle destinazioni.

La tabella seguente mostra esempi dell'intestazione X-Forwarded-For che la destinazione riceve quando si seleziona la modalità append, preserve o remove. In questo esempio, l'indirizzo IP dell'ultimo hop è 127.0.0.1.

Descrizione della richiesta	Richiesta di esempio	XFFin modalità `append`	XFFin `preserve` modalità	XFFin `remove` modalità
La richiesta viene inviata senza XFF intestazione	`GET /index.html HTTP/1.1 Host: example.com`	`X-Forwarded-For: 127.0.0.1`	Non presente	Non presente
La richiesta viene inviata con un'XFFintestazione e un indirizzo IP del client.	`GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4`	`X-Forwarded-For: 127.0.0.4, 127.0.0.1`	`X-Forwarded-For: 127.0.0.4`	Non presente
La richiesta viene inviata con un'XFFintestazione con più indirizzi IP del client.	`GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4, 127.0.0.8`	`X-Forwarded-For: 127.0.0.4, 127.0.0.8, 127.0.0.1`	`X-Forwarded-For: 127.0.0.4, 127.0.0.8`	Non presente

Per modificare, conservare o rimuovere X-Forwarded-For header utilizzando la console

Apri la EC2 console Amazon all'indirizzo https://console.aws.amazon.com/ec2/.
Seleziona Sistemi di bilanciamento del carico nel riquadro di navigazione.
Selezionare il load balancer.
Nella scheda Attributi, scegli Modifica.
Nella sezione Configurazione del traffico, in Gestione dei pacchetti, per l'X-Forwarded-For intestazione scegli Aggiungi (impostazione predefinita), Conserva o Rimuovi.
Scegli Save changes (Salva modifiche).

Per modificare, conservare o rimuovere X-Forwarded-For intestazione utilizzando il AWS CLI

Usa il modify-load-balancer-attributescomando con l'routing.http.xff_header_processing.modeattributo.

X-Forwarded-Proto

L'intestazione della X-Forwarded-Proto richiesta consente di identificare il protocollo (HTTPoHTTPS) utilizzato da un client per connettersi al sistema di bilanciamento del carico. I log di accesso al server contengono solo il protocollo utilizzato tra il server e il load balancer; non contengono informazioni sul protocollo utilizzato tra il client e il load balancer. Per determinare il protocollo utilizzato tra il client e il load balancer, utilizzare l'intestazione della richiesta X-Forwarded-Proto. Elastic Load Balancing archivia il protocollo utilizzato tra il client e il load balancer nell'intestazione della richiesta X-Forwarded-Proto e passa l'intestazione al server.

L'applicazione o il sito Web possono utilizzare il protocollo memorizzato nell'intestazione della X-Forwarded-Proto richiesta per fornire una risposta che reindirizza a quella appropriata. URL

L'intestazione della richiesta X-Forwarded-Proto assume la seguente forma:


X-Forwarded-Proto: originatingProtocol

L'esempio seguente contiene un'intestazione di X-Forwarded-Proto richiesta per una richiesta proveniente dal client come richiesta: HTTPS


X-Forwarded-Proto: https

X-Forwarded-Port

L'intestazione della richiesta X-Forwarded-Port consente di identificare la porta di destinazione utilizzata dal client per connettersi al load balancer.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Monitora la prenotazione

Crea un ascoltatore HTTP