У меня проблема с замедлением RDC до сканирования или полным отключением. Клиент - XP SP3 с RDC 6, сервер - Win 2k8 R2. Оба были тщательно просканированы и не содержали вирусов.
Я загрузил и установил Wireshark на клиентском компьютере и выполнил захват пакетов во время сеанса RDC. Журнал показал как минимум 10-20 потерь повторной передачи / дублирования / сегмента в минуту при нормальном использовании. Затем, когда у меня был разрыв связи, он увеличивался до нескольких десятков в секунду.
К вашему сведению, я очень мало знаю об инструменте Wireshark или о том, как провести полный анализ этой проблемы.
** РЕДАКТИРОВАТЬ **
Немного о моей сетевой архитектуре:
Клиент -
Сервер -
У других удаленных клиентов нет проблем с подключением к серверам (скорость или отключение). Несколько других ноутбуков использовались в месте расположения клиента, чтобы убедиться, что это не проблема оборудования. Также заменен кабельный модем.
Возможно, информации недостаточно, но вот несколько общих рекомендаций:
Если другие удаленные клиенты в порядке и не испытывают симптомов, проблема, вероятно, не в сервере. Это может быть соединение для этого клиента.
Повторная передача обычно означает, что пакет не был подтвержден, поэтому при захвате пакета обычно не будет реальных «ошибок». Это означает, что один конец отправлял пакеты, а другой не был подтвержден. Вы можете захотеть выполнить захват с обоих концов, чтобы определить, будет ли повторная передача односторонней или двусторонней.
Если вы пингуете свой хост от клиента, какое время отклика? Если оно превышает 150 мс, возможно, у вас неоптимальное соединение.
Параметр сетевого адаптера сервера для разгрузки большой отправки должен быть отключен. Windows должна быть достаточно умной, чтобы знать, что она не может отправлять большие пакеты на машины в разных подсетях, но, к сожалению, это не всегда так. Если ваш сервер является гостевым Hyper-V, это почти наверняка проблема.
MTU. Вообще говоря, при удаленном доступе к серверу, когда вы не в той же подсети, MTU всегда должен быть любым наименьшим MTU между двумя конечными точками. И это обычно означает клиента. Для удаленных клиентов, которые подключаются через VPN, нередко MTU составляет 1400 или даже меньше. Может быть полезно установить MTU сервера в соответствии с наименьшим значением MTU, чтобы избежать проблем, когда MTU не может быть обнаружен должным образом (иногда их называют маршрутизаторами черной дыры). Чтобы узнать MTU для вашего соединения, вы можете ввести следующую команду со своего клиента:
ping -f -l xxxx <server ip>
Где xxxx - размер MTU. Начните с 1400. Если он работает, увеличивайте его, пока не появится сообщение «Пакет должен быть фрагментирован, но DF установлен». Если 1400 не работает, уменьшайте его до тех пор, пока не заработает. Максимальное допустимое число - это размер полезной нагрузки. Добавьте 28 к размеру полезной нагрузки, и это будет ваш MTU.
Вы можете установить MTU сервера в следующем месте реестра:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}
FYI - пакеты RDP всегда отправляются с установленным битом «Не фрагментировать».
Имейте в виду, что сетевой монитор часто ошибочно отмечает пакеты как «Потерянный сегмент» в начале захвата для любого TCP-диалога, начатого до захвата.
Это потому, что Netmanager будет видеть подтверждения (порядковые номера) для пакетов, которые произошли до начала захвата. Поскольку он видит ACK, но не видит соответствующий пакет, он предполагает, что пакет потерян, и помечает его как «Потерянный сегмент». Будьте осторожны, чтобы не спутать это начало захвата потерянного сегмента с фактически потерянными сегментами. Если вы сортируете диалоги по отдельным IP-потокам, они должны сортироваться вверху.
Как вариант, вы можете сохранить снимок в файл, а затем повторно загрузить его в Netmanager. Я заметил, что он больше не будет отмечать начало подтверждений захвата как «Потерянный сегмент» после перезагрузки.
Вы получаете следующие пакеты:
Если вы получили повторную передачу TCP, это связано с тем, что отправленный вами ACK не был получен сервером. Сервер не знал, что пакет TCP был получен, считает, что он был утерян, и отправит его снова.
Дублирующий ACK обычно получается отправителем в следующем сценарии:
Третья ошибка (потерянный сегмент) - это точно такой сценарий, но на стороне получателя. Это означает, что пакет 3 был получен до пакета 2.
Все эти ошибки указывают на перегрузку: где-то по пути пакеты теряются. У этого может быть множество причин, поэтому нам действительно нужно хорошее представление о вашей сетевой архитектуре, чтобы мы могли сказать вам, в чем причина.
Обычно заторы - это не плохо. TCP автоматически настраивается на этот сценарий, увеличивая скорость передачи до тех пор, пока не начнется отбрасывание / замедление пакетов. Тот факт, что заторы здесь создают проблемы, может иметь несколько различных причин: