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

Ответ 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 (круговая поездка) для отправки пакета, а затем подтверждения.