В сценарии, когда ARR настроен на использование SSL / TLS для подключения к серверам содержимого, использует ли он сеансы SSL (например, идентификаторы сеанса как указано в RFC 5246), чтобы последующие соединения с серверами содержимого могли использовать сокращенное рукопожатие?
Если да, можно ли обслуживать несколько клиентов с помощью одного сеанса SSL с сервером содержимого?
Я знаю, что реализация SSL для ARR исходит из базового компонента schannel, и я считаю, что он по умолчанию выполняет кэширование для обеих сторон соединения на Как настроить элементы кэша сервера и клиента Secure Sockets Layer. Однако я не смог найти исчерпывающей статьи в поддержку сценария ARR.
Отвечая на свой вопрос после использования Wireshark для определения ответа.
Да, AAR будет использовать сеансы SSL, и эти сеансы могут обслуживать несколько клиентов.
Используя Wireshark, я заметил следующее:
Client1 -> AAR GET /foo
AAR -> ContentServer Client Hello
ContentServer -> AAR Server Hello, Certificate, Server Hello Done
AAR -> ContentServer Client Key Exchange, Change Cipher Spec,
Encrypted Handshake Message
ContentServer -> AAR Change Cipher Spec, Encrypted Handshake Message
AAR -> ContentServer <encrypted application data>
Client2 -> AAR GET /bar
AAR -> ContentServer Client Hello
ContentServer -> AAR Server Hello, Change Cipher Spec,
Encrypted Handshake Message
AAR -> ContentServer Change Cipher Spec, Encrypted Handshake Message
AAR -> ContentServer <encrypted application data>
Это точно соответствует ожидаемым результатам, показанным на диаграммах в Ускорение SSL: включение повторного использования сеанса.
Прежде всего, я не знаю ответа, но предполагаю, что он, по крайней мере, использует идентификатор сеанса.
Во-вторых, я бы попытался выяснить это, не просматривая документацию, которая может или не может быть заслуживающей доверия по такой детали, а путем анализа трафика и таким образом обеспечения 100% правильного ответа. Я считаю, что это самый простой способ, когда речь идет о прокси-серверах, которые могут управлять трафиком с различными эффектами - действительно ли он делает то, что я считаю?
Если я правильно помню свои «сниффы», SessionID является частью незашифрованного заголовка пакета SSL и может быть сразу же просмотрен в Wireshark или любом другом анализаторе пакетов.
Наконец, если вы хотите расшифровать для полного понимания это тоже возможно, и здесь тоже, чтобы ответить на ваш второй вопрос не с помощью дедукции, а с помощью явных данных потока.