2.4 Why UDP? (なぜ UDP か?)

2.4. Why UDP? (なぜ UDP か?)

よくある質問は, なぜ RADIUS がトランスポートプロトコルとして TCP の代わりに UDP を使用するのかということです。UDP は純粋に技術的な理由で選択されました。

理解する必要があるいくつかの問題があります。RADIUS はトランザクションベースのプロトコルであり, いくつかの興味深い特性があります:

1. プライマリ認証サーバーへの要求が失敗した場合, セカンダリサーバーに照会する必要があります。

   この要件を満たすために, 要求のコピーをトランスポート層の上に保持して, 代替送信を可能にする必要があります。これは, 再送信タイマーがまだ必要であることを意味します。

2. この特定のプロトコルのタイミング要件は, TCP が提供するものとは大きく異なります。

   一方の極端では, RADIUS は失われたデータの "応答性のある" 検出を必要としません。ユーザーは認証が完了するまで数秒待つ意思があります。一般的に攻撃的な TCP 再送信 (平均往復時間に基づく) は必要なく, TCP の確認応答のオーバーヘッドも必要ありません。

   他方の極端では, ユーザーは認証のために数分待つ意思はありません。したがって, 2 分後の TCP データの信頼できる配信は有用ではありません。代替サーバーのより迅速な使用により, ユーザーはあきらめる前にアクセスを獲得できます。

3. このプロトコルのステートレスな性質により, UDP の使用が簡素化されます。

   クライアントとサーバーは出入りします。システムは再起動されるか, 独立して電源がオン/オフされます。一般的にこれは問題を引き起こさず, 創造的なタイムアウトと失われた TCP 接続の検出により, 異常なイベントを処理するコードを書くことができます。しかし, UDP はこの特別な処理のすべてを完全に排除します。各クライアントとサーバーは UDP トランスポートを一度だけ開き, ネットワーク上のすべてのタイプの障害イベントを通じてそれを開いたままにしておくことができます。

4. UDP はサーバーの実装を簡素化します。

   RADIUS の最も初期の実装では, サーバーはシングルスレッドでした。これは, 単一の要求が受信, 処理, 返されることを意味します。これは, バックエンドセキュリティメカニズムが実時間 (1 秒以上) を要する環境では管理不能であることがわかりました。サーバー要求キューがいっぱいになり, 毎分何百人もの人が認証されている環境では, 要求のターンアラウンドタイムがユーザーが待つ意思がある時間よりも長くなりました (これは, データベースまたは DNS での特定の検索に 30 秒以上かかる場合に特に深刻でした)。明白な解決策は, サーバーをマルチスレッド化することでした。これは UDP で簡単に実現されました。各要求を処理するために個別のプロセスが生成され, これらのプロセスはクライアントの元のトランスポートへの単純な UDP パケットでクライアント NAS に直接応答できました。

すべてが万能薬というわけではありません。前述のように, UDP を使用するには TCP に組み込まれている 1 つのことが必要です: UDP では, 同じサーバーへの再送信タイマーを人為的に管理する必要がありますが, TCP が提供するタイミングと同じ注意を必要としません。この 1 つのペナルティは, このプロトコルでの UDP の利点に対して支払う小さな代償です。

TCP がなければ, おそらく私たちはまだ糸でつながれたブリキ缶を使用しているでしょう。しかし, この特定のプロトコルでは, UDP がより良い選択です。