Как работать с долго работающими ответами сервера и балансировщиком нагрузки, который рассматривает это как остановленное соединение

Question

Случай / Предположение:

1. Есть сервер, который написан кем-то другим.
2. Этот сервер имеет конечную точку GET /api/watch.
3. Эта конечная точкаявляется простым HTTP / 1.1
4. Эта конечная точка будет записывать события, подобные

   {type:"foo", message:"bar"}
   

   , в поток ответов, как только они появятся (одно событие в строке, а затем сброс).
5. Иногда этот сервер записывает события каждыйсекунда к выходу, иногда каждые 15 минут.
6. Между моим клиентом и этим сервером существует сторонний балансировщик нагрузки, который предполагает, что соединение останавливается, если в течение более 60 секунд не выполняется никаких действий для соединения, иразрывает соединение, не закрывая его.
7. Клиент написан на простом Golang и просто делает запрос GET к этой конечной точке.
8. Как только соединение помечено LB как устаревший клиент (то же самое случается и с curl тоже) не уведомляется о том, что LB разорвал соединение, и все еще ожидает получения материала в ответ на запрос GET.

Итак: Каковы мои возможности справиться с этой ситуацией?

Что не возможно:

1. Изменить сервер.
2. Используйте другой сервер.
3. Используйте что-то еще, кроме этой конечной точки и того, как она написана.
4. Изменить балансировщик нагрузки.
5. Использовать другой LB.
6. Оставить LB вне соединения.

Answer 1

15 минут - невероятно долгий тихий период для базового HTTP - возможно, лучше подходящий для WebSockets.Если не считать изменения протокола, вы должны иметь возможность регулировать период ожидания на балансировщике нагрузки (трудно сказать, поскольку вы не указали, что такое LB), чтобы лучше соответствовать вашему варианту использования, хотя и не всембалансировщики нагрузки позволят достичь тайм-аутов до 15 минут.Если вы не можете изменить протокол , а не может увеличить тайм-аут достаточно высоко, вам придется отправлять сообщения поддержки активности с сервера время от времени (просто за исключением периода времени ожидания, так что, возможно, 55 сваша текущая конфигурация, или немного меньше, чем максимальный период ожидания, который вы можете установить на LB).Это должно быть что-то, что клиент знал, чтобы отбросить, например {"type": "keepalive"} - что-то, что легко идентифицировать на стороне клиента как «поддельное» сообщение для целей поддержки активности.