что означает данный tcp/ip пакет?
Разработчики сервера клянутся и божатся, что в сервере никто никого никак не дропает, что по логам пусто и т.д.Значит, RST в пакете Пушкин выставил? Запроси с них pcap дамп на твой IP.
Почти каждый день, в т.ч. и в выходные, от сервера ВНЕЗАПНО, но - обязательно в районе 8 утра (! приходит tcp пакеткто-то по крону что-то передёргивает или dhcp lease истекает.
а если сервер ещё и на винде то гг.
2. Известно, что периодически один из этих 13 узлов (Chicago.Level3.net) иногда дает задержку около 200-300 мс вместо 30-50, это происходит в течение всего дня.Это нормально.
Почти каждый день, в т.ч. и в выходные, от сервера ВНЕЗАПНО, но - обязательно в районе 8 утра (!Насколько точно выдерживается время?
Может ещё файрвол какой-нибудь по дороге, а утром у него автоматом обновляются настройки.
Как вариант, там на пути может использоваться какой-нить балансировщик или stateful firewall. И если в указанное время происходят какие-то обновления на них или могут переключаться с одного балансировщика на другой, то сессии могут не полностью синхронизироваться, и ты получаешь reset. При этом на самом сервере этого видно не будет. Ты уточни, 8 утра по твоему времени это сколько по времени сервера. Если вдруг окажется около полуночи или 3-4 ночи, то у многих операторов проходят переключения в один их этих временных промежутков.
Еще как вариант, обмен идет круглосуточный, но с какими задержками? Если перед этим долго не было трафика, то опять же некоторые железки могут просто молча дропать такие сессии.
Еще как вариант, обмен идет круглосуточный, но с какими задержками? Если перед этим долго не было трафика, то опять же некоторые железки могут просто молча дропать такие сессии.
8 часов - разница с Нуёрком.
может дропнуть и в 7:55, а может и в 8:15. В течении 20-30 минут, в общем. Но в районе 8 утраПочти каждый день, в т.ч. и в выходные, от сервера ВНЕЗАПНО, но - обязательно в районе 8 утра (!Насколько точно выдерживается время?
Ты уточни, 8 утра по твоему времени это сколько по времени сервера. Если вдруг окажется около полуночи или 3-4 ночи, то у многих операторов проходят переключения в один их этих временных промежутков.и сервер, и клиент находятся в нью-йорке. Поэтому 8 утра по времени клиента есть 8 утра по времени сервера
Еще как вариант, обмен идет круглосуточный, но с какими задержками? Если перед этим долго не было трафика, то опять же некоторые железки могут просто молча дропать такие сессии.На выходных трафика почти нет - дроп присутствует. В будни трафик большой и круглосуточный - дроп присутствует. Запуск множества traceroute-ов для прозвонки узлов по пути от сервера к клиенту ничего интересного не выдает.
Насчет dhcp lease: может ли вышеописанная ситуация из-за неверно настроенной локальной сети?
Запуск множества traceroute-ов для прозвонки узлов по пути от сервера к клиенту ничего интересного не выдает.Запусти tcpdump лучше. При чём здесь вообще узлы, если ответ c RST от севера?
На application layer при использовании TCP сокетов есть возможность сгенерить RST в TCP пакете всего лишь в двух случаях:
* close/shutdown на чтение, но есть невычитанные данные в receive queue
* close/shutdown на запись с ненулевым истёкшим linger, но данные не были отосланы из transmit queue
Если эти две ситуации в приложении не подтверждаются, значит нужно отрывать руки админам или стекописателям на серверной стороне.
Мне в голову приходят несколько идей, почему сервер или железка перед сервером может так себя вести. Может быть в это время на сервер идет много соединений, он принимает это за атаку и сбрасывает все, в том числе и существующие. Либо сервер чем-то занят и начинает терять пакеты, это зависит от версии операционки и настроек сервера.
Со стороны клиента более-менее реальное что мне видится, это что у офиса клиентов два аплинка и в 8 утра происходит почему-то переключение между ними.
Со стороны клиента более-менее реальное что мне видится, это что у офиса клиентов два аплинка и в 8 утра происходит почему-то переключение между ними.
Напомнило одну историю.
Вторым часом X было время 9:34 утра. Каждый день в это время ситуация повторялась. Это была первая зацепка.
Оставить комментарий
NataNata
Ситуация:1. Имеется удаленный сервер, до него от клиента - 13 узлов (соответственно, на машине клиента ping -i 13 xxx.xxx.xxx.xxx проходит успешно, ping -i 12 xxx.xxx.xxx.xxx выдает TTL expired in transit).
2. Известно, что периодически один из этих 13 узлов (Chicago.Level3.net) иногда дает задержку около 200-300 мс вместо 30-50, это происходит в течение всего дня.
3. Сервер круглосуточно шлет данные к клиенту по нескольким портам, в будни поток велик, в выходные очень мал.
Проблема:
Почти каждый день, в т.ч. и в выходные, от сервера ВНЕЗАПНО, но - обязательно в районе 8 утра (! приходит tcp пакет, содержащий флаги RST+ACK, Seq не 0, Ack не 0, с TTL-ом, равным 114 (т.е., 127-13). Поэтому на клиенте дропаются соединения, что не есть хорошо. Через сниффер видно, что клиент серверу шлет данные как обычно, и клиент дисконнекта не инициирует. Разработчики сервера клянутся и божатся, что в сервере никто никого никак не дропает, что по логам пусто и т.д.
Вопрос:
Что может означать пакет, присылаемый сервером в данной ситуации? Чтение мануалов, документации tcp/ip и rfc не помогло разобраться в ситуации.