Повторное использование кэша сеанса F5 SSL с приложением весенней загрузки

Question

Мы запускаем приложение с весенней загрузкой со встроенным tomcat. Приложение само по себе работает нормально. Когда мы представили F5 LOAD Balancer для балансировки нагрузки трафика, наша пропускная способность снизилась. Когда мы подключаемся к серверу напрямую, мы видим, что во время рукопожатия сервер повторно использует кэшированный сеанс.

Когда вызовы маршрутизируются с F5, всегда создается новый сеанс. Что может быть причиной для этого. Это работало хорошо и внезапно сломалось. Мы подозреваем, что наша конфигурация f5 не работает. Любые указатели для дальнейшего расследования будут полезны.

%% Initialized:  [Session-22, SSL_NULL_WITH_NULL_NULL]
Standard ciphersuite chosen: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
%% Negotiating:  [Session-22, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
*** ServerHello, TLSv1.2

Answer 1

Из K6767, упомянутого ранее, есть ссылка на:

K13854: Система BIG-IP неправильно распределяет размер кэша сеанса SSL на основе виртуальной

Это объясняет, почему необходимо сократить размер кэша SSL, когда несколько виртуальных серверов вызывают один и тот же профиль.

Answer 2

Я подозреваю, что ваши кэши сеанса SSL и / или профили тайм-аута могут не быть настроены после значений по умолчанию или слишком малы для вашего приложения.

Проверьте и обновите размеры кеша сеанса и время ожидания до приемлемых уровней.

K6767: Обзор настроек профиля кэша сеанса BIG-IP SSL

Вам также может понадобиться проверить другие настройки тайм-аута, чтобы убедиться, что весь сеанс tcp не сбрасывается из-за тайм-аута простоя. Трудно сказать, не зная, как ваше приложение раскручивает и разрушает трафик.

K7606: Обзор тайм-аутов простоя BIG-IP

Я подозреваю, что первый КБ, который я связал, решит вашу проблему, но всегда безопасно проверить все настройки тайм-аута для профилей, используемых этим виртуальным сервером. Надеюсь, что это приведет вас в правильном направлении.