2.4 Why UDP? (Perché UDP?)

2.4. Why UDP? (Perché UDP?)

RADIUS utilizza UDP come protocollo di trasporto per diverse ragioni:

Se l'algoritmo di retry del client RADIUS è progettato correttamente, UDP può offrire prestazioni superiori a TCP in condizioni di rete degradate o sotto carico pesante del server di autenticazione, perché il client RADIUS può rapidamente passare a un server alternativo, o riprovare con un server primario dopo un breve intervallo.

Se un server TCP riceve una raffica di richieste di autenticazione, normalmente metterà in coda quelle richieste e servirà una alla volta. Il ritardo nella risposta può causare il timeout del client e la ritrasmissione della richiesta, facendo accodare un'altra richiesta di autenticazione al server TCP. Alla fine, la coda del server è piena e le richieste vengono perse, anche se non è stato fatto alcun lavoro per autenticare quelle richieste. Se il server fosse basato su UDP, il timeout della richiesta causerebbe l'invio della richiesta a un server alternativo, o dopo un breve ritardo al server originale, ma solo una richiesta entrerebbe in coda.

UDP semplifica l'implementazione del server. In un server UDP, non è necessario gestire le connessioni TCP concorrenti o lo stato delle connessioni TCP.

UDP semplifica l'implementazione del client. In un ambiente di rete tollerante ai guasti con più server RADIUS, il client può inviare richieste a più server contemporaneamente, con la garanzia che la prima risposta ricevuta sarà la più rapida. Con TCP, il client avrebbe dovuto stabilire connessioni con ogni server prima di inviare richieste, quindi determinare quale risposta è arrivata per prima, e quindi chiudere le altre connessioni. Inoltre, UDP fornisce l'indicazione che la richiesta non è stata elaborata dal server se il timeout scade. Con TCP, il client avrebbe dovuto utilizzare un meccanismo di timeout dell'applicazione per determinare se la richiesta era stata elaborata.