2.4 Why UDP? (为什么使用UDP?)

2.4 Why UDP? (为什么使用UDP?)

一个经常被问到的问题是为什么 RADIUS 使用 UDP 而不是 TCP 作为传输协议。UDP 的选择纯粹是出于技术原因。

有许多问题必须被理解。RADIUS 是一个基于事务的协议, 具有几个有趣的特性:

1. 如果对主认证服务器的请求失败, 则必须查询辅助服务器。

   为了满足这一要求, 必须在传输层之上保留请求的副本以允许替代传输。这意味着仍然需要重传定时器。

2. 此特定协议的时序要求与 TCP 提供的显著不同。

   在一个极端情况下, RADIUS 不需要对丢失数据进行 "响应式" 检测。用户愿意等待几秒钟以完成认证。通常激进的 TCP 重传 (基于平均往返时间) 不是必需的, TCP 的确认开销也不是必需的。

   在另一个极端情况下, 用户不愿意等待几分钟进行认证。因此, 两分钟后可靠传递 TCP 数据是没有用的。更快地使用备用服务器允许用户在放弃之前获得访问权限。

3. 该协议的无状态特性简化了 UDP 的使用。

   客户端和服务器来来去去。系统被重新启动或独立地进行电源循环。通常这不会造成问题, 通过创造性的超时和对丢失的 TCP 连接的检测, 可以编写代码来处理异常事件。然而, UDP 完全消除了所有这些特殊处理。每个客户端和服务器可以只打开一次它们的 UDP 传输, 并在网络上的所有类型的故障事件中保持打开状态。

4. UDP 简化了服务器实现。

   在 RADIUS 的最早实现中, 服务器是单线程的。这意味着接收、处理和返回单个请求。在后端安全机制需要实时 (1 秒或更长时间) 的环境中, 这被发现是无法管理的。服务器请求队列会填满, 在每分钟对数百人进行认证的环境中, 请求周转时间增加到超过用户愿意等待的时间 (当数据库中的特定查找或通过 DNS 的查找花费 30 秒或更长时间时, 这尤其严重)。显而易见的解决方案是使服务器多线程化。使用 UDP 很容易实现这一点。生成单独的进程来服务每个请求, 这些进程可以直接使用简单的 UDP 数据包响应客户端 NAS 到客户端的原始传输。

这并非万能良药。如前所述, 使用 UDP 需要 TCP 内置的一件事: 使用 UDP, 我们必须人为地管理到同一服务器的重传定时器, 尽管它们不需要 TCP 提供的相同时序关注。这一个代价是为 UDP 在此协议中的优势付出的小代价。

没有 TCP, 我们可能仍然会使用用绳子连接的锡罐。但对于这个特定的协议, UDP 是一个更好的选择。