5

Я нахожусь на сервере 192.168.0.2 и хочу сделать HTTP-вызов на 192.168.0.1(оба сервера являются RPis и работают под Linux (raspbian)).

curl -XGET http://192.168.0.1:8081/api

API на 192.168.0.1 (который я называю) является моим (скрипт Python, основанный на bottle) и работает большую часть времени. Часть прослушивания HTTP иногда таинственно зависает, что приводит к тому, что вызов curl выше зависания, а затем время ожидания.

Я запустил tcpdump на 192.168.0.1 (принимающий сервер, на котором размещен API), когда API не отвечал, а анализ wireshark показывает некоторые повторные передачи сразу после инициализации вызова:

Что обычно является причиной такого поведения? (если есть "обычная" причина).

Примечание 1: При необходимости я изменю API так, чтобы он регистрировал больше данных для части веб-сервера, но из-за невоспроизводимой природы зависания я сомневаюсь, что это его ошибка (другие части (потоки) работают отлично и нет никакого сбоя ни одной нити).

Примечание 2: перезагрузка сервера (также возможно перезапуск самого скрипта (что я не делаю, поскольку я скорее перезагружаю машину)) решает проблему.

|источник

1 ответ1

6

Что означает последовательность повторных передач с флагами PSH, ACK (и ложная повторная передача назад)?

Что обычно является причиной такого поведения? (если есть "обычная" причина).

PSH ACK Wireshark Trace

(Также см. ServerFault - PHA ACK во время моего подключения)

ACK означает, что машина, отправляющая пакет с ACK, подтверждает данные, полученные от другой машины. В TCP после установления соединения все пакеты, отправленные любой из сторон, будут содержать ACK, даже если это просто повторное подтверждение данных, которые уже были подтверждены.

PSH указывает отправителю, что, если реализация TCP принимающего компьютера еще не предоставила данные, полученные им, в код, который читает данные (программу или библиотеку, используемую программой), он должен сделать это в этот момент. Чтобы процитировать RFC 793, официальная спецификация для TCP:

Данные, которые передаются по соединению, могут рассматриваться как поток октетов. Отправляющий пользователь указывает в каждом вызове SEND, должны ли данные в этом вызове (и любые предшествующие вызовы) быть немедленно переданы принимающему пользователю посредством установки флага PUSH.

Отправляющему TCP разрешается собирать данные от отправляющего пользователя и отправлять эти данные по сегментам по своему усмотрению, пока не будет передана функция push, затем он должен отправить все неотправленные данные. Когда принимающий TCP видит флаг PUSH, он не должен ждать больше данных от отправляющего TCP, прежде чем передавать данные в принимающий процесс.

Ложные ретрансляции

Если вы видите ложные повторные передачи, это означает, что отправитель думал, что пакеты были потеряны, и отправил их снова, даже если получатель отправил для него пакет подтверждения.

Возможные причины

  • Неверная конфигурация между сервером и клиентскими компьютерами
  • Неверная конфигурация между любым отправителем и получателем в любом месте пути перехода пакетов TCP
  • Правила межсетевого экрана или фильтры пакетов, блокирующие пакеты

Устранение дополнительных проблем

  • Проверьте журналы сервера, когда это также происходит
  • Запустите трассировку TCP с Wireshark на сервере, чтобы увидеть, как выглядят эти пакеты при возникновении проблемы.
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .