Ответ 1
Когда сервер отправляет сообщение "Hello Server", он может включать идентификатор сеанса. Клиент должен сохранить его и представить в сообщении "Привет клиент" следующего сеанса. Если сервер находит соответствующий сеанс в своем кэше и принимает решение возобновить сеанс, он отправит обратно тот же идентификатор сеанса и продолжит сокращенное рукопожатие SSL. В противном случае он выдаст новый идентификатор сеанса и переключится на полное рукопожатие. Этот механизм подробно описан в RFC 5246. Это наиболее распространенный механизм, поскольку он существует с более ранних версий SSL.
В последнем обмене полным SSL-квитированием сервер может включать в себя сообщение "Новый билет сеанса" (не представлено в квитировании, описанном на рисунке), которое будет содержать полное состояние сеанса (включая главный секрет, согласованный между клиентом и сервер и комплект шифров используются). Следовательно, это состояние зашифровано и защищено целостностью с помощью ключа, известного только серверу. Этот непрозрачный объект известен как билет сеанса. Детали лежат в RFC 5077, который заменяет RFC 4507.
Билетный механизм является расширением TLS. Клиент может объявить о своей поддержке, отправив пустое расширение "Session Ticket" в сообщении "Client Hello". Сервер ответит пустым расширением "Session Ticket" в своем сообщении "Server Hello", если он его поддерживает. Если один из них не поддерживает это расширение, они могут использовать механизм идентификатора сеанса, встроенный в SSL.
RFC 5077 идентифицирует ситуации, когда билеты желательны по идентификаторам сеанса. Основное улучшение состоит в том, чтобы избежать необходимости поддерживать кэш сеанса на стороне сервера, поскольку все состояние сеанса запоминается клиентом, а не сервером. Кэш сеанса может быть дорогостоящим с точки зрения памяти, и его может быть сложно разделить между несколькими хостами, когда запросы сбалансированы между серверами.