Как использовать столбцы Recv-Q и Send-Q в выводе netstat? Как мне использовать это в реалистичном сценарии?
В моей системе оба столбца всегда отображаются как ноль. Какой смысл для этого?
Как использовать столбцы Recv-Q и Send-Q в выводе netstat? Как мне использовать это в реалистичном сценарии?
В моей системе оба столбца всегда отображаются как ноль. Какой смысл для этого?
Со страницы моего руководства:
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 (круговая поездка) для отправки пакета, а затем подтверждения.