Рассмотрим приложение, которое обращается к удаленному HTTPS-серверу, отправляя запросы в формате POST в формате JSON по URL-адресу на сервере и получая ответы в формате JSON. Сервер не поддерживает HTTP / 2 мультиплексирование.
Существует много запросов с сильно варьирующейся рабочей нагрузкой (от простоя до сотен TPS). Сообщения JSON имеют порядок 1 кбайт. Клиент и сервер аутентифицируются сертификатами + секретными ключами. Запросы можно считать независимыми (в частности, сервер обрабатывает запросы одинаково для всех каналов HTTPS, открытых с одним и тем же сертификатом клиента).
HTTP / 1.1 не позволяет * несколько одновременных запросов POST по одному и тому же соединению. Следовательно, пропускная способность не может превышать N / (Tr + Ts) TPS, где N - количество открытых HTTPS / TLS используемые каналы, Tr - задержка прохождения сигнала в сети, а Ts - время обработки на стороне сервера (в порядке 30 мс при низкой нагрузке, из-за доступа к базе данных и других факторов). Открытие HTTPS-соединения стоит как минимум 4 Tr и значительное процессорное время с обеих сторон. Похоже, что-то необходимо для управления пулом HTTPS-соединений на стороне клиента.
Как обычно решается эта проблема?
Что такое общие библиотеки или фоновые демоны / сервисы, автоматически открывающие новые HTTPS-соединения по мере необходимости и повторно использующие их по возможности?
Было бы неплохо, если бы он обнаружился, когда сервер перестал отвечать на запросы, и обработал откат на сервер резервного копирования по другому URL-адресу с возвратом на главный сервер, когда он снова включился.
Примечание. Следующим шагом будет распределение нагрузки, но тогда мой уровень распределения нагрузки должен несколько обрабатывать сходство между запросами, поскольку они не являются полностью независимыми (отправка зависимого запроса на неправильный сервер надежно обнаруживается сервером, хотя).
[*] Из-за того, как интерпретируется RFC 2616 , я сказал .