Что нужно учитывать при установке таймаутов простоя TCP?

Длительное простаивающее соединение может означать, что соединение разорвано (на любой стороне произошел сбой приложения, отключен сетевой кабель и т. Д.), Но ресурсы все равно будут выделены, а это означает, что:

• Это немного повлияет на производительность.
• Ваше приложение может иметь ограничение в X одновременных подключений, и, таким образом, вы можете отказывать в доступе новым клиентам, которые на самом деле не подключены.
• Вы не можете повторно подключить клиента, если вы использовали фиксированные порты как для источника, так и для пункта назначения (немного необычно, но возможно).
• Вы можете достичь пределов соединений / маршрутизации, препятствуя новым соединениям с любым другим портом или вызывая неожиданное поведение или сбой самого сервера.
• Многие приложения не остановятся, пока все соединения не будут закрыты должным образом, поэтому завершение работы или перезапуск службы займет больше времени.
• Вы не сможете отличить разорванное соединение от активного, не проверив в течение некоторого времени трафик TPC или не полагаясь на журналы приложений.
• Большинство клиентских приложений не знают, как реагировать на разорванные соединения: некоторые будут ждать внутреннего тайм-аута, а другие будут ждать вечно, вызывая потенциальную потерю данных, если клиенту потребуется перезапуск.

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

Используйте тайм-ауты простоя в соответствии с типом трафика, которым вы управляете (например, серверы Apache имеют тайм-аут по умолчанию, равный 5 минутам, поэтому ни одно соединение не будет бездействовать более 5 минут [и нескольких секунд]), но никогда установите меньший (или точно такой же) тайм-аут простоя TCP, чем тайм-аут вашего приложения. Реализуйте пакеты поддержки активности для длительных соединений по крайней мере каждые несколько минут, чтобы убедиться, что соединение активно (пакеты поддержки активности TCP, определенные при создании сокета, имеют тайм-аут в два часа, что я считаю слишком большим). Интерактивное программное обеспечение (например, сеансы ssh, удаленный рабочий стол, FTP) будет бездействовать в течение нескольких минут, пока пользователь читает, поэтому я бы не пошел менее 15 минут.

Примечание. Я бы не рекомендовал использовать тайм-аут простоя TCP менее нескольких минут, за исключением очень интенсивных соединений, которые не будут простаивать более нескольких секунд. Если возможно, установите разные временные привязки простоя в зависимости от вашего трафика (например, 6 минут для веб-серверов, 15 минут для сеансов ssh и т. Д.).

Если вам нужны более высокие таймауты (кто-то запрашивает "вечное" TCP-соединение), попробуйте вместо этого использовать поддержку активности на уровне приложения.