Почему TCP не получил ACK с сервера на машине Solaris?

Question

На стороне клиента приложение sftp отправляет пакет на порт 22 ssh-сервера.

SFTP-приложение отправляет пакет в TCP, из эфирного захвата мы видим, что отправка пакета sftp из приложения в TCP и отправка TCP в пакет на сервер, но TCP не получил TCP ACK от сервера, поэтому TCP снова отправляет пакет через несколько секунд, но по-прежнему не отвечает от сервера.

Похоже, что сервер не получил пакет от клиента.

ожидание клиента SFTP в режиме выбора для TCP recv с тайм-аутом 120 секунд через 120 секунд приложение получит тайм-аут от выбора и закроет операцию SFTP с ошибкой тайм-аута.

В перехвате я могу видеть пакет повторной передачи TCP много раз, но не могу получить ACK TCP сервера.

Сценарий: 1. Тайм-аут случается только иногда. 2. После этой проблемы следующий SFTP opration [upload] успешно с тем же сервером. 3. Кажется, сеть не имеет проблем, потому что следующая загрузка работает нормально. 4. и клиент, и сервер имеют ОС SOLARIS 5. мы не можем воспроизвести это в нашей лаборатории 6. Эта проблема возникает только в реальной сети клиентов. 7. Приложение на языке Си. Сервер SSH - открытый сервер SSH.

Я хочу знать: 1. Как мы можем найти причину, по которой TCP не получает ACK повторного запроса с сервера. 2. Являются ли какие-либо настройки системы TCP в Solaris причиной этой проблемы. 3. Пожалуйста, предоставьте любую информацию, чтобы мы могли решить эту проблему.

Answer 1

Я предполагаю, что ваша топология выглядит следующим образом:

           10.25.190.12               10.10.10.10
           [e1000g0]                  [eth0]
SFTP_Client--------------Network------------OpenSSH_Server

Есть две вещи, которые вам нужно сделать:

1. Установить, есть ли регулярные значительные потери пакетов междуваш клиент и сервер.TCP допускает некоторую потерю пакетов, но если вы начнете много отбрасывать (что честно трудно измерить), то в некоторых обстоятельствах он просто сдастся.Я бы предложил два способа обнаружения потери пакетов ... первый - mtr, второй - ping.mtr гораздо предпочтительнее, так как вы получаете статистику потерь за переход (см. Ниже).Запустите mtr 10.10.10.10 с клиента и mtr 10.25.190.12 с сервера.Иногда потеря пакетов зависит от пути, поэтому полезно делать это с обеих сторон, когда вы действительно хотите определить источник.Если вы видите потерю пакетов, сначала обратитесь к сетевым администраторам, чтобы исправить это;иначе ты тратишь время впустую.В процессе исправления потери пакетов, возможно, вы также исправите эту проблему TCP ACK.

2. Если значительных потерь пакетов нет, вам нужно прослушать обе стороны соединения одновременно с snoop или tshark (вы можете получить tshark из SunFreeware ), пока не увидите проблему снова.Когда вы обнаружите эту ситуацию с отсутствующими TCP ACK, выясните: A) OpenSSH_Server отправил ACK и B) получил ли SFTP_Client его.Если Клиент получает ACK на своем интерфейсе Ethernet, то вам, вероятно, нужно начать искать в своем программном обеспечении подсказки.Вы должны ограничивать свои нюансы IP-адресами клиента и сервера.По моему опыту, такая проблема возможна, но не является общей проблемой;90 +% времени, это просто потеря сетевых пакетов.

Пример вывода из mtr:

mpenning@mpenning-T61:~$ mtr -n 4.2.2.4
HOST: mpenning-T61              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.239.84.1                0.0%    407    8.8   9.1   7.7  11.0   1.0
  2. 66.68.3.223                0.0%    407   11.5   9.2   7.1  11.5   1.3
  3. 66.68.0.8                  0.0%    407   19.9  16.7  11.2  21.4   3.5
  4. 72.179.205.58              0.0%    407   18.5  23.7  18.5  28.9   4.0
  5. 66.109.6.108               5.2%    407   16.6  17.3  15.5  20.7   1.5 <----
  6. 66.109.6.181               4.8%    407   18.2  19.1  16.8  23.6   2.3
  7. 4.59.32.21                 6.3%    407   20.5  26.1  19.5  68.2  14.9
  8. 4.69.145.195               6.4%    406   21.4  27.6  19.8  79.1  18.1
  9. 4.2.2.4                    6.8%    406   22.3  23.3  19.4  32.1   3.7