Нужен http/socks прокси, реализующий стратегию Record/Replay для нагрузочного тестированию.

Народ,

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

Разъяснение. Есть сервис, которая использует в качестве бэкэнда помимо БД и кэша, а-ля memcached, использует ещё провайдеров, которые доставляют контент по протоколам SOAP/HTTP, POP3, IMAP.

Есть задача -- организовать нагрузочное тестирование сервиса, при котором SOAP/HTTP, POP3, IMAP провайдеры доставляют данные по сценарию. То есть, вместо провайдеров данных используем заглушки.

Использовать вместо реальных провайдеров заглушки представляется возможным, если система ходит к ним за порцией данных через прокси (http, socks). Тогда для каждой сессии можно записать дамп данных, для последующей симуции той сессии в reply режиме, под нагрузочным тестированием.

Но! POP3, IMAP используют SSL как протокол сессионного уровня, а SOAP/HTTP используют OAuth.

Люди!! Есть здесь эксперты с мировым именем и знанием TLS/SSL??? Которые могут навскидку сказать, можно записать один-в-один SSL сессию, и потом повторить её без ошибок со стороны клиента?

Здравствуйте, Olksy, Вы писали:

O>Люди!! Есть здесь эксперты с мировым именем и знанием TLS/SSL??? Которые могут навскидку сказать, можно записать один-в-один SSL сессию, и потом повторить её без ошибок со стороны клиента?

Если подразумевается повторить "один в один" не прикладной уровень завернутый в ssl, а именно сам ssl-поток, то при использовании готовых имплементаций ssl-клиентов и серверов не получится, т.к. сама процедура организации безопасного соединения вся построена на рандомных последовательностях.

O>>Люди!! Есть здесь эксперты с мировым именем и знанием TLS/SSL??? Которые могут навскидку сказать, можно записать один-в-один SSL сессию, и потом повторить её без ошибок со стороны клиента?

А>Если подразумевается повторить "один в один" не прикладной уровень завернутый в ssl, а именно сам sshttp://www.rsdn.ru/forum/NewMsg.aspx?mid=3702434l-

Автор:
Дата: 12.02.10

поток, то при использовании готовых имплементаций ssl-клиентов и серверов не получится, т.к. сама процедура организации безопасного соединения вся построена на рандомных последовательностях.

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

Найден также путь преодоления этого затруднения, т.к., в моем случае, клиент готов принимать от сервера любой SSL сертификат. Прокси, например, берём этот проект за основу, может сам установить SSL сессию с клиентом, и прокинуть ещё одну сессию на сервер провайдера данных.

Вот ещё один вкусный пример реализации, правда, как оказалось, очень и очень сырой. Умеет делать вышеупомяную SSL-сессию, и дамп сессии.

C OAuth оказалось проще, т.к. ключ для сессии можно переиспользовать много раз.