2.4 Why UDP? (Warum UDP?)

2.4. Why UDP? (Warum UDP?)

Eine häufig gestellte Frage ist, warum RADIUS UDP anstelle von TCP als Transportprotokoll verwendet. UDP wurde aus rein technischen Gründen gewählt.

Es gibt eine Reihe von Fragen, die verstanden werden müssen. RADIUS ist ein transaktionsbasiertes Protokoll, das mehrere interessante Eigenschaften hat:

1. Wenn die Anfrage an einen primären Authentifizierungsserver fehlschlägt, muss ein sekundärer Server abgefragt werden.

   Um diese Anforderung zu erfüllen, muss eine Kopie der Anfrage oberhalb der Transportschicht aufbewahrt werden, um eine alternative Übertragung zu ermöglichen. Dies bedeutet, dass Retransmission Timer weiterhin erforderlich sind.

2. Die Timing-Anforderungen dieses speziellen Protokolls unterscheiden sich erheblich von dem, was TCP bietet.

   An einem Extrem erfordert RADIUS keine "responsive" Erkennung verlorener Daten. Der Benutzer ist bereit, mehrere Sekunden auf den Abschluss der Authentifizierung zu warten. Die im Allgemeinen aggressive TCP-Neuübertragung (basierend auf durchschnittlicher Round-Trip-Zeit) ist nicht erforderlich, ebenso wenig wie der Acknowledgement-Overhead von TCP.

   Am anderen Extrem ist der Benutzer nicht bereit, mehrere Minuten auf die Authentifizierung zu warten. Daher ist die zuverlässige Zustellung von TCP-Daten zwei Minuten später nicht nützlich. Die schnellere Verwendung eines alternativen Servers ermöglicht es dem Benutzer, Zugriff zu erhalten, bevor er aufgibt.

3. Die zustandslose Natur dieses Protokolls vereinfacht die Verwendung von UDP.

   Clients und Server kommen und gehen. Systeme werden neu gestartet oder unabhängig voneinander aus- und eingeschaltet. Im Allgemeinen verursacht dies kein Problem, und mit kreativen Timeouts und Erkennung verlorener TCP-Verbindungen kann Code geschrieben werden, um anomale Ereignisse zu behandeln. UDP eliminiert jedoch vollständig jegliche spezielle Behandlung. Jeder Client und Server kann seinen UDP-Transport nur einmal öffnen und ihn durch alle Arten von Fehlerereignissen im Netzwerk geöffnet lassen.

4. UDP vereinfacht die Serverimplementierung.

   In den frühesten Implementierungen von RADIUS war der Server single-threaded. Dies bedeutet, dass eine einzelne Anfrage empfangen, verarbeitet und zurückgegeben wurde. Dies erwies sich als nicht handhabbar in Umgebungen, in denen der Backend-Sicherheitsmechanismus echte Zeit (1 oder mehr Sekunden) benötigte. Die Server-Request-Warteschlange würde sich füllen, und in Umgebungen, in denen Hunderte von Menschen jede Minute authentifiziert wurden, stieg die Request-Turn-Around-Zeit auf länger als Benutzer bereit waren zu warten (dies war besonders schwerwiegend, wenn eine spezifische Suche in einer Datenbank oder über DNS 30 oder mehr Sekunden dauerte). Die offensichtliche Lösung war, den Server multi-threaded zu machen. Dies zu erreichen war einfach mit UDP. Separate Prozesse wurden erzeugt, um jede Anfrage zu bedienen, und diese Prozesse konnten direkt an den Client-NAS mit einem einfachen UDP-Paket an den ursprünglichen Transport des Clients antworten.

Es ist nicht alles eine Panazie. Wie erwähnt, erfordert die Verwendung von UDP eine Sache, die in TCP eingebaut ist: Mit UDP müssen wir künstlich Retransmission Timer zum selben Server verwalten, obwohl sie nicht die gleiche Aufmerksamkeit für das Timing erfordern, die TCP bietet. Diese eine Strafe ist ein kleiner Preis für die Vorteile von UDP in diesem Protokoll.

Ohne TCP würden wir wahrscheinlich immer noch Blechdosen verwenden, die durch Schnur verbunden sind. Aber für dieses spezielle Protokoll ist UDP die bessere Wahl.