2.4. Почему UDP?
Достаточно часто спрашивают, почему протокол RADIUS использует транспорт UDP, а не TCP. Выбор протокола UDP был обусловлен техническими причинами.
Здесь нужно разобраться со множеством вопросов. Протокол RADIUS работает на основе транзакций, что ведет к ряду интересных особенностей:
При отказе основного сервера идентификации запросы должны передаваться резервному серверу.
Для выполнения этого требования копия запроса должна сохраняться выше транспортного уровня чтобы обеспечить возможность повторного запроса. Это требует поддержки таймеров повтора передачи.
Временные требования протокола существенно отличаются от обеспечиваемых TCP временных параметров.
С одной стороны, RADIUS не требует "нести ответственность" за детектирование потери данных. Пользователь может подождать завершения процедуры идентификации в течение нескольких секунд. Не требуется агрессивная политика TCP в части передачи повторов (на основе среднего времени кругового обхода), а также передача подтверждений, увеличивающая уровень служебного трафика.
С другой стороны, пользователя вряд ли устроит процедура идентификации, занимающая несколько минут. Следовательно гарантированная доставка данных на основе TCP в течение 2 минут не принесет пользы. Передача запроса альтернативному серверу позволит пользователю быстрее завершить процедуру идентификации.
Протокол по своей природе не требует организации прямых соединений.
Клиенты и серверы "приходят и уходят". Системы могут перезагружаться или выключаться. В общем случае это не вызывает проблем и средства обнаружения обрыва соединений TCP вкупе с механизмами тайм-аутов позволяют обрабатывать аномальные ситуации. Однако использование протокола UDP полностью избавляет от таких ситуаций без какой-либо специальной обработки. Каждый клиент или сервер может активизировать свой транспорт UDP и сохранять его в активном состоянии независимо от возникающих в сети проблем.
UDP упрощает реализацию серверов.
Первые реализации серверов RADIUS были однопотоковыми. Это означало, что запросы принимались и обрабатывались по одному. Такое решение оказалось неприемлемым для сред, где реализация механизмов безопасности занимала достаточно продолжительное время (1 секунду или более). Очередь запросов сервера могла содержать достаточно много запросов и в средах, где каждую минуту проверяется идентификация сотен пользователей, пользователи были вынуждены ждать завершения идентификации слишком долго. Ожидание увеличивалось дополнительно при обращении к базам данных или серверам DNS и могло затянуться на 30 секунд и более того. Обычно такие проблемы решаются путем создания многопотоковых (multi-threaded) серверов. Реализация таких серверов существенно упрощается при использовании протокола UDP. Для обработки каждого запроса порождается отдельный процесс и этот процесс может напрямую взаимодействовать с клиентом NAS, обмениваясь с ним пакетами UDP.
Однако ничего не достается даром и отказ от использования TCP приводит к необходимости реализации протоколом некоторых функций, которые в TCP поддерживаются транспортным уровнем. В частности, при работе по протоколу UDP требуется поддержка таймеров повторной передачи для сервера, хотя и не со столь жесткими требованиями, как в TCP. Это достаточно невысокая плата за те преимущества, которые обеспечивает работа на основе протокола UDP.
Для протокола RADIUS транспорт UDP является оптимальным решением.