TCP Keepalive и Idle Timeout PCAP-анализ: межсетевые экраны, NAT, балансировщики нагрузки и долгоживущие соединения
Как анализировать пакеты поддержки активности TCP, тайм-аут простоя, истечение сеанса NAT, разрывы соединений с брандмауэром, сброс балансировщика нагрузки, долгоживущие соединения API и доказательства захвата пакетов.
Долгоживущие TCP-соединения могут выйти из строя после нескольких минут или часов бездействия. Сеансы SSH зависают. сброс подключений к базе данных. Соединения WebSocket прерываются. Перемежающиеся потоки RTSP TCP останавливаются после периодов простоя. Клиенты API видят сломанную трубу. Пользователи ищут «TCP keepalive pcap», «тайм-аут простоя брандмауэра», «тайм-аут сеанса NAT», «сброс балансировщика нагрузки при простое соединения» и «долговременное разрыв соединения TCP», поскольку ошибка приложения часто появляется спустя много времени после принятия решения о реальном тайм-ауте.
PCAP Surgery полезен, поскольку расследование простоя зависит от времени. Вам нужен последний реальный пакет данных, любые проверки активности TCP, ACK, пакеты FIN/RST и точная продолжительность простоя.
Что такое поддержка активности TCP
TCP Keepalive — это дополнительный механизм, который отправляет небольшие зонды при бездействующем соединении, чтобы проверить, доступен ли партнер по-прежнему. Он также может поддерживать состояние NAT и брандмауэра, если проверки происходят чаще, чем тайм-аут промежуточного блока.
Но настройки по умолчанию часто слишком медленны для современной инфраструктуры. Состояние простоя брандмауэра может истечь через 60 секунд, тогда как поддержка активности TCP OS может начаться намного позже.
Симптомы простоя
Общие симптомы включают в себя:
- Соединение работает, но после фиксированного времени простоя происходит сбой.
- Первый запрос после простоя сбрасывается.
- WebSocket отключается ровно через 60 секунд.
- Пул базы данных имеет устаревшие соединения.
- SSH зависает через NAT.
- Балансировщик нагрузки отправляет RST по истечении времени ожидания.
- Клиент отправляет данные после простоя и не получает ответа.
Точное время является ключом к разгадке.
FIN против RST против бесшумного падения
Миддлбоксы и конечные точки могут закрывать простаивающие соединения разными способами:
- ФИН: изящное закрытие.
- RST: неудачное закрытие.
- Тихий сброс: нет пакета; более поздний трафик игнорируется.
Если брандмауэр автоматически сбросит состояние, обе конечные точки могут подумать, что соединение все еще существует. Следующий пакет данных запускает повторную передачу или сброс.
Поддерживаемые доказательства
В трассировке ищите небольшие пакеты в периоды простоя. Проверка активности TCP часто использует порядковые номера непосредственно перед следующим ожидаемым байтом. Анализатор может пометить их как активные.
Вопросы:
- Были ли отправлены сообщения об активности?
- Как часто?
- Подтвердил ли их узел?
- Сбросил ли промежуточный ящик после проверки активности?
- Расследование началось слишком поздно?
- Соединение прервалось до интервала поддержки активности?
Балансировщики нагрузки и прокси
Балансировщики нагрузки часто применяют тайм-ауты простоя. Если клиент ожидает, что соединение продержится 30 минут, но балансировщик нагрузки закрывает неактивные соединения через 60 секунд, приложение должно отправить контрольные сигналы или повторно подключиться.
Свидетельства пакета могут показать, кто отправил закрытие или сброс и сколько времени прошло с момента получения последних данных.
Checklist
Используйте этот рабочий процесс:
- Определите долгоживущее TCP-соединение.
- Отметьте последний пакет данных приложения.
- Измерьте время простоя до отказа.
- Найдите проверки активности TCP.
- Проверьте, подтверждены ли датчики.
- Определите отправителя FIN или RST.
- Если закрытия не появляется, ищите тихое отключение и повторную передачу.
- Сравните время ожидания с настройками брандмауэра/балансировщика нагрузки.
- Сохраняйте время при обрезке.
- Коррелируйте с тактовыми сигналами приложений.
Окончательный диагноз
Сбои TCP в режиме простоя являются проблемами синхронизации. Свидетельство пакета может различать закрытие конечной точки, истечение срока действия состояния брандмауэра/NAT, тайм-аут балансировщика нагрузки, отсутствие подтверждения активности, слишком медленное подтверждение активности и автоматическое отключение.
PCAP Surgery помогает сохранить интервал простоя и данные о закрытии/сбросе, что позволяет точно объяснить длительные сбои соединения.