на нашем сервере возникла серьезная проблема с тайм-аутом соединения, поэтому мы отслеживаем TCP-соединение с помощью tcptrack
мы выяснили, что если клиент начал подключаться к серверу, tcptrack показывает подключение, но в состоянии SYN_SENT, и netstat -nat ничего не показывает. (tcptrack и netstat все работают на сервере)
я сделал стендовый тест, используя ab в той же интрасети к указанному NIC он обработал 10000 одновременных подключений и 400000 запросов нормально
ps: это случается не каждый раз, но случалось часто
pps: есть ли какие-нибудь хорошие инструменты, чтобы отследить, где было потеряно tcp-соединение?
Это означает, что SYN был отправлен клиентом и либо не дошел до сервера, либо сервер не ответил на него, либо сервер решил ответить на него, не отслеживая его. Серверу не нужно отслеживать каждый отправляемый SYN-ответ (и он может использовать SYN файлы cookie), потому что они могут быть подделаны, что создает риск атак типа "отказ в обслуживании".
Когда я получаю `` нежелательный '' трафик, как в трафике, который был специально заблокирован правилами IPTABLES (как при DROPped), tcptrack показывает входящий IP-адрес вместе со статусом SYN_SENT (вместе со временем подключения и скоростью передачи данных 0 бит / сек). Этот список остается там в течение нескольких секунд, пока не исчезнет.
Итак - возможно, что соединения, которые вы видите, заблокированы по какой-то причине. IP-адреса, которые приходят с SYN_SENT, могут быть заблокированы из-за IPTABLES DROP. Вы можете ненадолго отключить IPTABLES и посмотреть, продолжится ли это. Если да, убедитесь, что адреса должны быть заблокированы.