Questo documento mostra esempi di utilizzo della gestione del traffico per alcuni usi specifici d'uso diversi. Sono possibili molti altri casi d'uso.
Il documento contiene esempi per i seguenti bilanciatori del carico:
- Bilanciatore del carico delle applicazioni esterno regionale
- Bilanciatore del carico delle applicazioni interno regionale
- Bilanciatore del carico delle applicazioni interno tra regioni
Bilanciatore del carico delle applicazioni esterno regionale e bilanciatore del carico delle applicazioni interno regionale. Per la configurazione della gestione del traffico dei bilanciatori di carico regionali, la documentazione dell'API mappa URL regionale e dell' API servizio di backend regionale fornisce un elenco completo dei campi, incluse le semantiche relative a relazioni, restrizioni e cardinalità.
L'unico la differenza tra questi due bilanciatori del carico è lo schema di bilanciamento del carico, che segue:
- I bilanciatori del carico delle applicazioni esterni regionali utilizzano
EXTERNAL_MANAGED
. - I bilanciatori del carico delle applicazioni interni regionali utilizzano
INTERNAL_MANAGED
.
Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico delle applicazioni interno tra regioni. Per la configurazione della gestione del traffico:
I bilanciatori del carico delle applicazioni interni regionali utilizzano l'API mappa URL regionale e la documentazione dell'API servizio di backend regionale fornisce un elenco completo dei campi, incluse le semantiche relative a relazioni, restrizioni e cardinalità.
I bilanciatori del carico delle applicazioni interni tra regioni utilizzano l'API mappa URL globale e la documentazione dell' API servizio di backend globale fornisce un elenco completo dei campi, incluse le semantiche relative a relazioni, restrizioni e cardinalità.
Oltre alle funzionalità di routing avanzate descritte in questa pagina, alcuni bilanciatori del carico delle applicazioni si integrano con le estensioni di servizio per consentirti di inserire logica personalizzata nel percorso dati del bilanciamento del carico configurando i callout delle estensioni di servizio.
Prima di iniziare
Assicurati di comprendere come funziona la gestione del traffico. Per ulteriori informazioni, consulta la sezione Concetti di gestione del traffico.
Segui le istruzioni in Configurare un il bilanciatore del carico delle applicazioni interno, e configurare tutti gli host VM o i cluster GKE di cui hai bisogno.
Crea il controllo di integrità richiesto o riutilizzane uno esistente, come descritto in Configurazione del bilanciatore del carico.
Configura la gestione del traffico
Nell'ambiente di configurazione scelto, puoi configurare la gestione del traffico usando configurazioni YAML. Una mappa di URL e un servizio di backend hanno ciascuno il proprio file YAML. A seconda della funzionalità che ti interessa, devi scrivere un file YAML della mappa URL, un file YAML del servizio di backend o entrambi.
Per assistenza nella scrittura di questi file YAML, puoi utilizzare gli esempi in questa pagina e la documentazione dell'API Cloud Load Balancing.
Per il bilanciatore del carico delle applicazioni interno regionale, puoi anche utilizzare la console Google Cloud e configurare la gestione del traffico.Per i bilanciatori del carico delle applicazioni interni e esterni regionali, la documentazione dell'API mappa URL regionale e dell' API servizio di backend regionale fornisce un elenco completo dei campi, incluse le semantiche relative a relazioni, restrizioni e cardinalità.
Accedi agli esempi YAML nella console Google Cloud
Per accedere agli esempi YAML nella console Google Cloud:
Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
- Fai clic su Crea bilanciatore del carico.
- Completa i passaggi della procedura guidata per creare un bilanciatore del carico delle applicazioni interno regionale.
- Nella configurazione delle Regole di routing, seleziona Regola avanzata per host, percorso e route.
- Fai clic su Aggiungi matcher host e percorso.
- Fai clic sul link Indicazioni sul codice.
Viene visualizzata la pagina Esempi YAML matcher percorso.
Mappa il traffico a un singolo servizio
Invia tutto il traffico a un singolo servizio. Assicurati di sostituire i segnaposto.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
Suddividi il traffico tra due servizi
Suddividi il traffico tra due o tra più servizi. Assicurati di sostituire segnaposto.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
weight: 5
Configurare un reindirizzamento URL
L'esempio seguente restituisce un codice di risposta 3xx configurabile. L'esempio imposta anche l'intestazione di risposta Location
con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
urlRedirect:
hostRedirect: "new-host-name.com" # Omit to keep the requested host
pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
redirectResponseCode: FOUND
stripQuery: True
Mirroring del traffico
Oltre a inoltrare la richiesta al servizio di backend selezionato, puoi inviare una richiesta identica al servizio di backend mirror configurato in modalità fire and forget. Il bilanciatore del carico non attende una risposta dal a cui invia la richiesta sottoposta a mirroring. Il mirroring è utile per testare una nuova versione di un servizio di backend. Puoi utilizzarlo anche per eseguire il debug della produzione gli errori in una versione di debug del servizio di backend, anziché in completamente gestita.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
Tieni presenti le seguenti limitazioni quando utilizzi il mirroring del traffico:
- Il mirroring del traffico è supportato quando entrambi i servizi di backend sono stati gestiti gruppi di istanze, NEG a livello di zona o backend NEG ibridi. Non è supportato per i NEG internet, i NEG serverless e i backend Private Service Connect.
- Le richieste al servizio di backend con mirroring non generano log per Cloud Logging e Cloud Monitoring.
Riscrivere l'URL richiesto
Riscrivere la porzione del nome host dell'URL, la parte del percorso dell'URL oppure prima di inviare una richiesta al servizio di backend selezionato. Assicurati di sostituire i segnaposto.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
urlRewrite:
hostRewrite: "new-host-name.com" # Omit to keep the requested host
pathPrefixRewrite: "/new-path/" # Omit to keep the requested path
Riprovare una richiesta
Configura le condizioni in cui il bilanciatore del carico riprova le richieste non riuscite, il tempo di attesa prima di riprovare e il numero massimo di tentativi consentiti.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
Specifica il timeout della route
Specifica il timeout per il percorso selezionato. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al momento in cui la risposta viene elaborata completamente. Il timeout include tutti i tentativi di ripetizione. Assicurati di sostituire i segnaposto.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 500000000
Configurare l'iniezione di errori
Introduci errori durante la gestione delle richieste per simulare gli errori, tra cui: latenza elevata, sovraccarico del servizio, errori del servizio e rete il partizionamento orizzontale. Questa funzionalità è utile per testare la resilienza di un servizio in caso di guasti simulati.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 500000000
percentage: 25
abort:
httpStatus: 503
percentage: 50
Configura CORS
Configura i criteri di condivisione delle risorse tra origini (CORS) per gestire impostazioni per l'applicazione delle richieste CORS.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: my-domain.com
allowMethods: GET, POST
allowHeaders: Authorization, Content-Type
maxAge: 1200
allowCredentials: True
Aggiungere e rimuovere intestazioni di richiesta e risposta
Aggiungi e rimuovi le intestazioni della richiesta prima di inviare una richiesta al servizio di backend. Inoltre, aggiungi e rimuovi le intestazioni di risposta dopo aver ricevuto una risposta dal servizio di backend.
Anche i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni supportano l'uso
variabili nelle intestazioni personalizzate. Puoi specificare una o più variabili nei campi del valore dell'intestazione personalizzata (headerValue
) che vengono poi tradotti nei relativi valori per richiesta. Per un elenco dei valori delle intestazioni supportati, consulta
Creare intestazioni personalizzate nelle mappe URL.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
headerAction:
requestHeadersToAdd:
- headerName: header-1-name
headerValue: header-1-value
replace: True
requestHeadersToRemove:
- header-2-name
- header-3-name
responseHeadersToAdd:
- headerName: header-4-name
headerValue: header-4-value
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Configura rilevamento outlier
Specifica i criteri per l'espulsione di VM o endpoint di backend non integri nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato sufficientemente integro per ricevere nuovamente il traffico. Assicurati di sostituire i segnaposto.
loadBalancingScheme: LOAD_BALANCING_SCHEME
localityLbPolicy: RANDOM
name: regions/REGION/backendServices/BACKEND_SERVICE_1
outlierDetection:
baseEjectionTime:
nanos: 0
seconds: '30'
consecutiveErrors: 5
consecutiveGatewayFailure: 3
enforcingConsecutiveErrors: 2
enforcingConsecutiveGatewayFailure: 100
enforcingSuccessRate: 100
interval:
nanos: 0
seconds: '1'
maxEjectionPercent: 50
successRateMinimumHosts: 5
successRateRequestVolume: 100
successRateStdevFactor: 1900
region: region/REGION
Configura interruzione di circuito
L'interruzione di circuiti consente di impostare soglie di errore per impedire le richieste del client di sovraccaricare i tuoi backend. Quando le richieste raggiungono il limite che hai impostato, smette di consentire nuove connessioni o di inviare dando ai backend il tempo di recuperare. Pertanto, l'interruttore di sicurezza previene gli errori a cascata restituendo un errore al client anziché sovraccaricare un backend. Ciò consente la pubblicazione di una parte del traffico fornendo al contempo Tempo necessario per gestire la situazione di sovraccarico, ad esempio un picco di traffico aumentando la capacità tramite la scalabilità automatica.
Imposta limiti superiori per le richieste per connessione, nonché il volume di connessioni a un servizio di backend. Limita anche il numero di richieste in attesa e di nuovi tentativi.
loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
localityLbPolicy: RANDOM
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
capacityScaler: 1.0
group: region/REGION/instanceGroups/INSTANCE_GROUP
maxUtilization: 0.8
circuitBreakers:
maxConnections: 1000
maxPendingRequests: 200
maxRequests: 1000
maxRequestsPerConnection: 100
maxRetries: 3
connectionDraining:
drainingTimeoutSec: 0
healthChecks:
- region/REGION/healthChecks/HEALTH_CHECK
Configurare la suddivisione del traffico: procedura dettagliata
Questo esempio illustra i seguenti passaggi:
Crea modelli distinti per servizi diversi.
Crea gruppi di istanze per questi modelli.
Crea regole di routing che impostano la suddivisione del traffico in 95%/5%.
Invia comandi curl che mostrano che le percentuali di suddivisione del traffico corrispondono approssimativamente alla configurazione.
Queste istruzioni presuppongono quanto segue:
- La regione è
us-west1
. Sono stati creati un proxy di destinazione e una regola di forwarding, insieme a una mappa URL denominato
regional-lb-map
.La mappa URL invia tutto il traffico a un solo servizio di backend, denominato
red-service
, che è il servizio di backend predefinito.Hai configurato un percorso alternativo che invia il 5% del traffico a
blue-service
e il 95% del traffico agreen-service
.Viene utilizzato un matcher percorso.
Stai utilizzando Cloud Shell o un altro ambiente con bash installato.
Definisci i servizi
La seguente funzione bash crea un servizio di backend, che include modello di istanza e gruppo di istanze gestite.
Queste istruzioni presuppongono che un controllo di integrità HTTP (regional-lb-basic-check
) abbia
un'istanza di blocco note. Per le istruzioni, vedi Configurare un bilanciatore del carico delle applicazioni interno.
function make_service() { local name="$1" local region="$2" local zone="$3" local network="$4" local subnet="$5" local subdir="$6" www_dir="/var/www/html/$subdir" (set -x; \ gcloud compute instance-templates create "${name}-template" \ --region="$region" \ --network="$network" \ --subnet="$subnet" \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-10 \ --image-project=debian-cloud \ --metadata=startup-script="#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl sudo mkdir -p $www_dir /bin/hostname | sudo tee ${www_dir}index.html systemctl restart apache2"; \ gcloud compute instance-groups managed create \ "${name}-instance-group" \ --zone="$zone" \ --size=2 \ --template="${name}-template"; \ gcloud compute backend-services create "${name}-service" \ --load-balancing-scheme=LOAD_BALANCING_SCHEME\ --protocol=HTTP \ --health-checks=regional-lb-basic-check \ --health-checks-region="$region" \ --region="$region"; \ gcloud compute backend-services add-backend "${name}-service" \ --balancing-mode='UTILIZATION' \ --instance-group="${name}-instance-group" \ --instance-group-zone="$zone" \ --region="$region") }
Crea i servizi
Richiama la funzione per creare tre servizi: red
, green
e blue
. Il servizio red
funge da servizio predefinito per le richieste a /
. I servizi green
e
blue
sono entrambi configurati su /PREFIX
per gestire rispettivamente il 95% e il 5% del traffico.
make_service red us-west1 us-west1-a lb-network backend-subnet "" make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX
Crea la mappa URL
gcloud
Esporta la mappa degli URL esistente utilizzando il comando
gcloud compute url-maps export
:gcloud compute url-maps export regional-lb-map \ --destination=regional-lb-map-config.yaml \ --region=us-west1
Aggiorna il file della mappa URL
regional-lb-map-config.yaml
aggiungendo quanto segue alla fine del file:hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: regions/us-west1/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: regions/us-west1/backendServices/green-service weight: 95 - backendService: regions/us-west1/backendServices/blue-service weight: 5
Aggiorna la mappa URL utilizzando il comando
gcloud compute url-maps import
:gcloud compute url-maps import regional-lb-map \ --region=us-west1 \ --source=regional-lb-map-config.yaml
Testa la configurazione
Per testare la configurazione, assicurati innanzitutto che le richieste all'indirizzo IP del bilanciatore del carico configurato in precedenza siano gestite dalla configurazione predefinita red
.
Poi verifica che le richieste inviate
FORWARDING_RULE_IP_ADDRESS/PREFIX
sono suddivisi come previsto.
Crea una VM client
Per le istruzioni, consulta Creazione di un'istanza VM nella zona da testare per la connettività.
Inviare richieste a FORWARDING_RULE_IP_ADDRESS
Utilizza
ssh
per connetterti al client.gcloud compute ssh global-lb-client-us-west1-a \ --zone=us-west1-a
Esegui questo comando:
for LB_IP in FORWARDING_RULE_IP_ADDRESS; do RESULTS= for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1 IFS=':' echo "***" echo "*** Results of load balancing to $LB_IP: " echo "***" for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c echo done
Controlla i risultati
*** ***Results of load balancing to FORWARDING_RULE_IP_ADDRESS: *** 502 red-instance-group-9jvq 498 red-instance-group-sww8
Inviare richieste a FORWARDING_RULE_IP_ADDRESS/PREFIX
Invia richieste a FORWARDING_RULE_IP_ADDRESS/PREFIX
e
osserva la suddivisione del traffico.
for LB_IP in FORWARDING_RULE_IP_ADDRESS; do RESULTS= for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1 IFS=':' echo "***" echo "*** Results of load balancing to $LB_IP/PREFIX: " echo "***" for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c echo done
Controlla i risultati
*** ***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX: *** 21 blue-instance-group-8n49 27 blue-instance-group-vlqc 476 green-instance-group-c0wv 476 green-instance-group-rmf4
La configurazione canary invia correttamente il 95% delle richieste /PREFIX
a
dal servizio green
e il 5% al servizio blue
.
Configurare l'affinità sessione in base a HTTP_COOKIE
Il controllo del traffico ti consente di configurare l'affinità sessione in base a un
cookie fornito. Per configurare l'affinità di sessione basata su HTTP_COOKIE per un servizio di backend chiamato red-service
, segui queste istruzioni.
Utilizza il comando
gcloud compute backend-services export
per recuperare la configurazione del servizio di backend.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --region=us-west1
Aggiorna il file
red-service-config.yaml
come segue:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 500000000 minimumRingSize: 10000
Nel file
red-service-config.yaml
, elimina la seguente riga:sessionAffinity: NONE
Aggiorna il file di configurazione del servizio di backend:
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --region=us-west1
Risoluzione dei problemi
Utilizza queste informazioni per la risoluzione dei problemi quando il traffico non è instradato in base alle regole di route e ai criteri di traffico che hai configurato.
Per informazioni su logging e monitoraggio, consulta Logging e monitoraggio HTTP(S) interno.Sintomi:
- Aumento del traffico verso i servizi nelle regole precedenti a quella in questione.
- Aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.
Soluzione: controlla l'ordine delle regole di route. Le regole di route vengono interpretate nell'ordine in cui sono specificate.
Le regole di route all'interno di una mappa URL vengono interpretate nell'ordine in cui vengono specificato. Questo è diverso dal modo in cui le regole dei percorsi vengono interpretate dalla corrispondenza del prefisso più lungo. Per una regola di percorso, i bilanciatori del carico delle applicazioni interni selezionare una singola regola percorso; Tuttavia, quando utilizzi le regole di route, possono essere potrebbe essere applicabile.
Quando definisci le regole di routing, assicurati che le regole nella parte superiore dell'elenco non indirizzino inavvertitamente il traffico che altrimenti sarebbe stato indirizzato da una regola di routing successiva. Il servizio che riceve traffico indirizzato erroneamente rifiuterà probabilmente le richieste e il servizio nelle tue regole di route riceverebbe meno traffico o non ne riceverebbe affatto.