Использование Recv-Q и Send-Q

Question

Какая польза от столбцов Recv-Q и Send-Q при выводе команды netstat И когда мы используем это в сценарии в реальном времени? В моей системе оба столбца всегда отображаются как ноль. Какой смысл для этого?

Answer 1

Со страницы моего руководства:

Recv-Q

Установлено: Количество байтов, не скопированных пользовательской программой, подключенной к этому сокету.

Прослушивание: Начиная с ядра 2.6.18, этот столбец содержит текущее отставание синхронизации.

Send-Q

Установлено: Количество байтов, не подтвержденных удаленным хостом.

Прослушивание: начиная с ядра 2.6.18, этот столбец содержит максимальный размер журнала ожидания синхронизации.

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

Пример реального сценария, где это может отличаться от 0 (для установленных соединений, но я думаю, вы поймете идею):

Недавно я работал над встроенным устройством Linux, разговаривая с (плохо спроектированным) устройством стороннего производителя. На этом стороннем устройстве приложение иногда зависало, не считывая данные, полученные им по TCP-соединению, в результате чего его окно TCP снижалось до 0 и оставалось там в течение десятков секунд (явление, наблюдаемое через wireshark на зеркальном порте между 2 хозяина). В таком случае:

• Recv-Q: работает netstat на стороннем устройстве (которое я не имел в виду) может показывать возрастающее значение Recv-Q, вплоть до некоторого значения крыши, когда другая сторона (я) прекращает отправку данных, потому что окно становится равным 0, так как приложение делает не читает данные, имеющиеся на его сокете, и эти данные остаются буферизованными в реализации TCP в ОС, не попадая в зависшее приложение -> со стороны получателя, проблема приложения.

• Send-Q: работает netstat на моей стороне (которую я не пробовал, потому что 1/ проблема была ясна из wireshark и была в первом случае выше, а 2/ это не воспроизводилось на 100%) может показывать ненулевой Send-Q, если другая сторона TCP реализация на уровне ОС застряла и перестала ACK знать мои данные -> со стороны отправителя, получив реализацию TCP (обычно на уровне ОС).

Обратите внимание, что описанный выше сценарий Send-Q также может быть проблемой отправляющей стороны (моя сторона), если моя реализация TCP в Linux работала некорректно и продолжала отправлять данные после того, как окно TCP опустилось до 0: у принимающей стороны больше нет места для эти данные -> не подтверждают.

Также обратите внимание, что проблема Send-Q может быть вызвана не из-за получателя, а из-за некоторой проблемы маршрутизации где-то между отправителем и получателем. Некоторые пакеты находятся "на лету" между двумя хостами, но пока не получают ACKnowledge. С другой стороны, проблема Recv-Q определенно на хосте: пакеты получены, подтверждены ACK, но еще не прочитаны из приложения.

РЕДАКТИРОВАТЬ:

В реальной жизни с нехитрыми хостами и приложениями, как вы можете разумно ожидать, я бы поспорил, что проблема Send-Q будет в большинстве случаев вызвана некоторой проблемой маршрутизации / плохой работой сети между отправляющей и принимающей сторонами. Состояние пакетов "на лету" никогда не следует забывать:

• Пакет может находиться в сети между отправителем и получателем,

• (или получил, но ACK еще не отправлен, см. выше)

• или ACK может находиться в сети между получателем и отправителем.

Требуется RTT (круговая поездка) для отправки пакета, а затем подтверждения.

Answer 2

принятый ответ @jbm.

Прослушивание: Начиная с ядра 2.6.18, этот столбец содержит текущую задержку синхронизации. Прослушивание: Начиная с ядра 2.6.18 этот столбец содержит максимальный размер backlog синхронизации.

они не являются невыполненными синхронизаторами, они являются невыполненными ожиданиями.