Ripristino TCP del bilanciatore di carico e timeout di inattività

È 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.

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 RST chiudono immediatamente il socket corrispondente. 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.

Scegli tra il reset TCP e i keepalive

Usa i seguenti criteri per decidere quale meccanismo il tuo scenario richiede:

• Abilita il reset TCP quando vuoi che gli endpoint vengano avvisati immediatamente della chiusura di un flusso inattivo, così le applicazioni possono eliminare e ristabilire le connessioni invece di aspettare il proprio timeout TCP.
• Usa i keepalive TCP quando i periodi di inattività superano l'intervallo configurabile del timeout di inattività o quando l'applicazione si comporta in modo imprevisto con i reset TCP abilitati. I Keepalive non sono raccomandati per applicazioni mobili, perché scaricano la batteria del dispositivo più velocemente.
• Usa i keepalive a livello applicativo quando la connessione passa attraverso un proxy in qualche punto del percorso, perché un proxy può terminare la connessione TCP che i keepalive del livello di trasporto mantengono attiva.

Esaminando attentamente l'intero scenario end-to-end, puoi determinare i vantaggi di abilitare i reset TCP e di regolare il timeout inattivo. Poi decidi se sono necessari ulteriori passaggi per garantire il comportamento applicativo desiderato.

Timeout di inattività TCP configurabile

Azure Load Balancer Standard ha un intervallo di timeout da 4 minuti a 100 minuti per le regole del load balancer e le regole NAT in ingresso. Le regole in uscita hanno un intervallo configurabile da 4 a 120 minuti. Il tempo predefinito è di 4 minuti per tutti i tipi di regole. 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 (ritirato) aveva un intervallo di timeout fino a 60 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.

Il TCP keep-alive descritto in questa sezione si applica solo alle connessioni in ingresso. La reimpostazione TCP e il timeout di inattività configurabile sono supportati separatamente per le regole in uscita. 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 ingresso

• 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.

Limitazioni

Queste limitazioni si applicano al reset TCP e al timeout inattivo su Azure Load Balancer:

• Il reset TCP viene inviato solo durante una connessione TCP nello stato STABILITO.
• Il timeout di inattività non è supportato per le regole di bilanciamento del carico UDP.
• Il reset TCP non è supportato per le regole delle porte per l'alta disponibilità (HA) di un bilanciatore del carico interno quando nel percorso è presente un'appliance virtuale di rete (NVA). Come soluzione alternativa, usa una regola in uscita con il reset TCP dall'appliance virtuale di rete.
• Il timeout di inattività TCP non è supportato per le regole delle porte HA del bilanciatore di carico interno quando una route definita dall'utente (UDR) inoltra il traffico al bilanciatore di carico interno.

Passaggi successivi

• Altre informazioni su Azure Load Balancer Standard.
• Altre informazioni sulle regole in uscita.
• Configurare la reimpostazione TCP in caso di timeout di inattività