Reimpostazione TCP e timeout di inattività di Load Balancer

  • Articolo

È possibile usare Load Balancer Standard per creare un comportamento delle applicazioni più prevedibile per gli scenari abilitando TCP Reset per timeout di inattività per una determinata regola. Il comportamento predefinito di Load Balancer prevede l'eliminazione trasparente dei flussi quando viene raggiunto il timeout di inattività di un flusso. L'abilitazione della reimpostazione TCP fa sì che Load Balancer invii reimpostazioni TCP bidirezionali (pacchetti di ripristino TCP ) in caso di timeout di inattività per informare gli endpoint dell'applicazione che la connessione è scaduta e non è più utilizzabile. Gli endpoint possono stabilire immediatamente una nuova connessione, se necessario.

Diagramma che mostra il comportamento di reimpostazione TCP predefinito dei nodi di rete.

Reimpostazione TCP

Si modifica questo comportamento predefinito e si abilita l'invio di TCP Reset per timeout di inattività per regole NAT in ingresso, regole di bilanciamento del carico e regole in uscita. Quando questo comportamento viene abilitato per ogni regola, Load Balancer invia TCP Reset bidirezionali (pacchetti TCP RST) agli endpoint client e server al momento del timeout di inattività per tutti i flussi corrispondenti.

Gli endpoint che ricevono pacchetti TCP rest chiudono il socket corrispondente immediatamente. Gli endpoint ricevono così una notifica immediata del rilascio della connessione e le eventuali comunicazioni future sulla stessa connessione TCP avranno esito negativo. Le applicazioni possono ripulire le connessioni alla chiusura del socket e ristabilire le connessioni all'occorrenza senza attendere il timeout della connessione TCP.

Per molti scenari, la reimpostazione TCP potrebbe ridurre la necessità di inviare keep-alive TCP (o di livello applicazione) per aggiornare il timeout di inattività di un flusso.

Se la durata dell'inattività supera i limiti della configurazione o l'applicazione mostra un comportamento indesiderato con TCP Reset abilitato, potrebbe comunque essere necessario usare keep-alive TCP (o al livello applicazione) per monitorare l'attività delle connessioni TCP. Inoltre, i keep-alive possono anche rimanere utili in caso di uso di proxy per la connessione nel percorso, in particolare i keep-alive al livello applicazione.

Esaminando attentamente l'intero scenario end-to-end, è possibile determinare i vantaggi derivanti dall'abilitazione delle reimpostazioni TCP e dalla regolazione del timeout di inattività. Quindi si decide se possono essere necessari altri passaggi per garantire il comportamento dell'applicazione desiderato.

Timeout di inattività TCP configurabile

Azure Load Balancer Standard ha un intervallo di timeout da 4 minuti a 100 minuti per le regole di bilanciamento del carico, le regole in uscita e le regole NAT in ingresso. Il valore predefinito è 4 minuti. Se un periodo di inattività è più lungo del valore di timeout, non ci sono garanzie che venga mantenuta la sessione TCP o HTTP tra il client e il servizio cloud. Azure Load Balancer Basic ha un intervallo di timeout di 30 minuti.

Quando la connessione viene chiusa, l'applicazione client potrebbe ricevere il messaggio di errore seguente: "Connessione sottostante chiusa: una connessione che doveva restare attiva è stata chiusa dal server in modo imprevisto".

Se le reimpostazioni TCP sono abilitate e non vengono ripristinate per qualsiasi motivo, vengono reimpostate per tutti i pacchetti successivi. Se l'opzione di reimpostazione TCP non è abilitata, i pacchetti vengono eliminati automaticamente.

Una prassi comune consiste nell'usare una connessione TCP keep-alive per mantenere la connessione attiva per un periodo più lungo. Per altre informazioni, vedere questi esempi .NET. Con la connessione keep-alive abilitata, i pacchetti vengono inviati durante i periodi di inattività della connessione. I pacchetti keep-alive garantiscono che il valore del timeout di inattività non venga raggiunto e che la connessione sia mantenuta per un lungo periodo.

L'impostazione funziona solo per le connessioni in entrata. Per evitare di perdere la connessione, configurare l'impostazione keep-alive TCP con un intervallo minore rispetto all'impostazione di timeout di inattività o aumentare il valore del timeout di inattività. Per supportare questi scenari, è disponibile il supporto per un timeout di inattività configurabile.

La connessione TCP keep-alive è adatta per gli scenari non vincolati alla durata della batteria, mentre non è consigliabile per le applicazioni mobili. L'uso di un'impostazione keep-alive TCP in un'applicazione per dispositivi mobili può far scaricare più velocemente la batteria del dispositivo.

Ordine di precedenza

È importante tenere conto del modo in cui i valori di timeout di inattività impostati per indirizzi IP diversi potrebbero potenzialmente interagire.

In entrata

  • Se è presente una regola di bilanciamento del carico (in ingresso) con un valore di timeout di inattività impostato in modo diverso rispetto al timeout di inattività dell'IP front-end a cui fa riferimento, il timeout di inattività dell'IP front-end del servizio di bilanciamento del carico ha la precedenza.
  • Se è presente una regola NAT in ingresso con un valore di timeout di inattività impostato in modo diverso rispetto al timeout di inattività dell'IP front-end a cui fa riferimento, il timeout di inattività dell'IP front-end del servizio di bilanciamento del carico ha la precedenza.

In uscita

  • Se è presente una regola in uscita con un valore di timeout di inattività diverso da 4 minuti (ovvero il timeout di inattività in uscita dell'IP pubblico bloccato), il timeout di inattività della regola in uscita ha la precedenza.
  • Poiché un gateway NAT avrà sempre la precedenza sulle regole in uscita del bilanciamento del carico (e sugli indirizzi IP pubblici assegnati direttamente alle macchine virtuali), verrà usato il valore di timeout di inattività assegnato al gateway NAT. Allo stesso modo, i timeout di inattività in uscita dell'IP pubblico bloccato di 4 minuti di qualsiasi IP assegnato al gateway NAT non vengono considerati.

Limiti

  • La reimpostazione TCP viene inviata solo durante la connessione TCP nello stato STABILITO.
  • Il timeout di inattività TCP non influisce sulle regole di bilanciamento del carico sul protocollo UDP.
  • La reimpostazione TCP non è supportata per le porte a disponibilità elevata del Load Balancer interno quando un'appliance virtuale di rete si trova nel percorso. Una soluzione alternativa potrebbe essere quella di usare la regola in uscita con la reimpostazione TCP dall'appliance virtuale di rete.

Passaggi successivi