Задержки SSL-сессии против идентификаторов сеанса

Чтобы повысить эффективность установления связи SSL для не сохраняющихся (коротких) соединений, есть две отдельные функции, известные широко:

Идентификаторы сеанса TLS
Закладки сеанса TLS

В случае очень многих коротких сеансов подключения, какой механизм с точки зрения производительности является предпочтительным и должен использоваться?

Я знаю, что серверу необходимо кэшировать идентификаторы сеанса, а также билеты на сессию легко распределяются в случае балансировки нагрузки, но пусть предполагается, что один сервер прослушивает один порт (без балансировки нагрузки), и он получает очень много SHORT входящих TLS сеансы связи.

Итак, какой подход (сеансы или билеты) предпочтительнее с учетом этого сценария?

Ответ 1

Когда сервер отправляет сообщение "Hello Server", он может включать идентификатор сеанса. Клиент должен сохранить его и представить в сообщении "Привет клиент" следующего сеанса. Если сервер находит соответствующий сеанс в своем кэше и принимает решение возобновить сеанс, он отправит обратно тот же идентификатор сеанса и продолжит сокращенное рукопожатие SSL. В противном случае он выдаст новый идентификатор сеанса и переключится на полное рукопожатие. Этот механизм подробно описан в RFC 5246. Это наиболее распространенный механизм, поскольку он существует с более ранних версий SSL.

В последнем обмене полным SSL-квитированием сервер может включать в себя сообщение "Новый билет сеанса" (не представлено в квитировании, описанном на рисунке), которое будет содержать полное состояние сеанса (включая главный секрет, согласованный между клиентом и сервер и комплект шифров используются). Следовательно, это состояние зашифровано и защищено целостностью с помощью ключа, известного только серверу. Этот непрозрачный объект известен как билет сеанса. Детали лежат в RFC 5077, который заменяет RFC 4507.

Билетный механизм является расширением TLS. Клиент может объявить о своей поддержке, отправив пустое расширение "Session Ticket" в сообщении "Client Hello". Сервер ответит пустым расширением "Session Ticket" в своем сообщении "Server Hello", если он его поддерживает. Если один из них не поддерживает это расширение, они могут использовать механизм идентификатора сеанса, встроенный в SSL.

RFC 5077 идентифицирует ситуации, когда билеты желательны по идентификаторам сеанса. Основное улучшение состоит в том, чтобы избежать необходимости поддерживать кэш сеанса на стороне сервера, поскольку все состояние сеанса запоминается клиентом, а не сервером. Кэш сеанса может быть дорогостоящим с точки зрения памяти, и его может быть сложно разделить между несколькими хостами, когда запросы сбалансированы между серверами.

Ответ 2

С идентификаторами сеанса серверу необходимо отслеживать предыдущие сеансы, которые могут быть продолжены в определенный момент времени. Это приводит к некоторой дополнительной работе, которую должен выполнять сервер.

Сессионный билет, напротив, не является идентификатором, а данные сеанса, зашифрованные сервером (и только сервер может его расшифровать). Когда клиент хочет продолжить сеанс, он все еще знает секретный ключ, но сервер больше не работает. Таким образом, клиент отправляет сеансовый билет на сервер, и только сервер способен расшифровать его содержимое. Любая информация, необходимая для продолжения сеанса, включена там, поэтому сервер может возобновить сеанс, не сохраняя никакой информации. Вся дополнительная нагрузка выполняется на клиенте (сохраняя секретный ключ и сеансовый билет).

Ответ 3

В этой ситуации вам нужны только идентификаторы сеансов, и они встроены в большинство реализаций SSL, в отличие от RFC 5077, которые по-прежнему являются расширением TLS.