Не разработчик Nest, но я запускаю управляемую управляемую службу Elasticsearch . Хотя «поддержание активности» звучит ценно, для соединения HTTP оно более ценно, чем для соединения TCP .
В Википедии :
Как правило, TCP Keepalive отправляются каждые 45 или 60 секунд на незанятом TCP-соединении, и соединение пропадает после пропуска 3 последовательных ACK.
Это звучит довольно удобно, но если вы проведете некоторые измерения, установление TCP-соединений, вероятно, будет менее миллисекунды в одном и том же центре данных.
Учитывая, что мы смотрим на активность Elasticsearch, мы сейчас находимся в области HTTP. И HTTP-соединение может иметь немало дополнительных затрат. Особенно в наши дни и в эпоху безопасных соединений, когда рукопожатие для обмена сертификатами TLS может состоять из нескольких пакетов и принимать порядка ~ 50 мс.
Таким образом, TCP keepalive может сэкономить миллисекунды в минуту, HTTP keepalive может сэкономить десятки миллисекунд за запрос. Для приложения, генерирующего более одного HTTP-запроса в минуту, HTTP keep-alive может сэкономить много времени в совокупности.
TCP keepalive, с другой стороны, будет незначительным.
См. Также: Отношение между продолжительностью HTTP Keep Alive и продолжительностью таймаута TCP
Так почему же в Nest включена опция поддержки активности TCP? Возможно, это лучший вопрос для разработчика Nest. Как соратник, иногда приятно включить опцию для всех настраиваемых возможностей, хотя бы только для полноты.