Изучая некоторые временные проблемы с сетью, я заметил, что, кажется, было получено большое количество RST-пакетов:
TCP:
40091950 активных подключений открытых
44754733 отверстия для пассивного подключения
2840116 неудачных попыток подключения
Получено 49571981 сброса соединения
30748407 сбросов отправлено
Может ли кто-нибудь прокомментировать, указывает ли это на проблему? Это кажется невероятно высоким, но, возможно, я просто неправильно интерпретирую результаты. Из того, что я прочитал, RST отправляется, когда TCP-соединение не получает ACK для данных, которые оно отправляет.
Мы запускаем несколько серверов Centos 6.5, веб-приложения, работающие в tomcat, сбалансированы за httpd. Каждый кот будет устанавливать много недолговечных соединений друг с другом, так что это может быть результатом этого?
Я провел некоторый анализ, пакеты RST не приходят от маршрутизатора или с одного конкретного хоста, но, похоже, приходят со всех хостов.
TCP - это конечный автомат. TCP-соединение существует для обоих участников разговора, и оба участника должны согласовать текущее состояние соединения.
Сброс TCP обычно происходит, когда система получает данные, которые не согласуются с ее представлением о соединении.
В Википедии есть отличный Диаграмма состояний TCP объясняя все возможные состояния и допустимые переходы между этими состояниями.
Что касается вашей проблемы, не видя трафика, трудно сказать, однако довольно часто можно увидеть сбросы при разрыве, когда один конец закрыл соединение, но на другом конце все еще были данные в буфере или в полете для отправки.
Представьте себе следующее
HostA HostB
ESTABLISHED
Data ------------> 1. here is some data
<------------ ACK 2. i have received your data
Data ------------> 3. here is some data
<------------ ACK 4. i have received your data
Data ------> 5. (data hasn't reached HostB yet)
<------------ FIN 6. we're done here, close this connection
Data -----> 7. (data reaches HostB)
<------------ RST 8. i didn't expect this!
В 6, HostB отправил FIN поэтому сокет HostB вошел FIN_WAIT1 и ожидал ACK от HostA.
Однако вместо ожидаемого ACK, HostB получил больше данных. Отправка данных в сокет в FIN_WAIT1 недействителен, он не согласуется с тем, что конечный автомат HostB считает следующим допустимым шагом. Что-то пошло не так, поэтому отправляется Reset, чтобы полностью завершить TCP-диалог.