Далее следует описание самой странной сетевой проблемы, с которой я столкнулся.
История
Я работаю с клиентом, который сообщил, что не может проверить свою электронную почту, начиная с сегодняшнего утра. Две недели назад они завершили большое обновление, в ходе которого были заменены все их ПК и добавлен новый сервер SBS в домен Windows.
Клиент получает электронную почту по протоколу POP3 с помощью Outlook 2010 в Windows 7, но сообщения не принимаются. В окне выполнения отправки / получения указано, что загрузка остановлена примерно на 1%.
Я попытался подключиться к серверу POP3, используя telnet клиент и наблюдал подобное поведение. После подачи команды RETR 1 Я видел, как проходят небольшие порции данных (около 1 КБ) со все более длинными паузами между ними. Между порциями данных паузы, кажется, удваиваются по длине - я наблюдал паузы, которые длились 1, 3, 7, 14 и 28 секунд. После этого я перестал считать.
Выполнение того же теста загрузки сообщения POP3, запустив telnet на Терминальном сервере (Svr 2008 Std) в том же домене дали те же результаты.
Затем загрузил небольшой сценарий PHP, который возвращал страницу произвольной длины на сервер в Интернете, и попытался получить к ней доступ с сервера терминалов в локальной сети. Я тестировал различные размеры от 1 КБ до 1 МБ, и никаких зависаний не наблюдалось. HTTP, похоже, не затронут.
Наконец, я подключил свой персональный ноутбук (не член домена) к сети и снова попробовал тест POP3 - все сообщение было загружено сразу.
Обновление (2011-03-10)
Я использовал Wireshark, чтобы получить четкий захват пакетов разговора POP3 сегодня. Первоначальный диалог (USER, PASS, LIST) работает, как ожидалось, с немедленным ответом сервера. (Результаты LIST помещаются в один пакет.) После того, как команда RETR выдается и сообщение начинает потоковую передачу, начинаются задержки. Моя предыдущая оценка была немного неверной, и задержки фактически соответствуют ожидаемой продолжительности: 1, 2, 4, 8, 16 секунд и т. Д. Клиент отправляет ACKS сразу же, в пределах 200 мс после каждого полученного пакета.
Кроме того, мы попытались подключить одну из затронутых рабочих станций к Интернету напрямую, и она смогла загрузить сообщения на полной скорости. На данный момент я сильно подозреваю, что неисправен маршрутизатор (Cisco 1711), но я недостаточно знаю о IOS для проведения дальнейшей диагностики.
Что я знаю
Что я не знаю
В качестве администратора выполните из командной строки клиента следующее:
netsh interface tcp set global autotuninglevel=disabled
Это отключает масштабирование окна TCP? Проблема сохраняется? Если нет, значит проблема где-то между клиентом и сервером в сетевом оборудовании, включая кабели, сетевые интерфейсы и их драйверы, коммутаторы и маршрутизаторы.
Установлен ли какой-то программный брандмауэр или антивирус? Он может перехватить весь трафик порта 110, чтобы запустить его против своей вирусной базы данных. Это может вызывать замедление. То, как он разбивает 1 КБ, предполагает, что если это AV, он может быть привязан к CPU / Disk IO / и т. Д.
Попробуйте запустить монитор ресурсов (запустить диспетчер задач (Ctrl + Shift + Esc), производительность, монитор ресурсов) и просмотрите список процессов для ЦП и диска, чтобы увидеть, есть ли какие-либо конкретные всплески процесса при загрузке сообщения. (Я бы по-прежнему предлагал протестировать с помощью telnet, чтобы избежать загрязнения данных Outlook и т. Д.)
Вы также можете проверить трафик с помощью анализатора пакетов для получения дополнительных подсказок. Мне интересно, может ли клиент (из-за AV или по какой-либо другой причине) действительно медленно возвращать ACK пакетам сервера, и это вызывает Избежание перегрузки TCP чтобы продолжать увеличивать отсрочку передачи и, следовательно, задержку между каждым пакетом. Насколько мне известно, чуть больше 1 КБ заставило бы вас сидеть прямо около максимального размера сегмента (размера отдельного пакета), что имело бы смысл с точки зрения того, почему вы получаете только столько данных за «пакет». (Отказ от ответственности: мои знания в этой области устарели и утрачены. Не надейтесь на них слишком сильно.)
Если это задержка TCP, это также может быть из-за отброшенных пакетов, но я сомневаюсь, что у всех новых машин плохой кабель или что-то в этом роде. Скорее всего, проблема в программном обеспечении, поскольку я полагаю, что все они выглядят одинаково.
РЕДАКТИРОВАТЬ: Основываясь на предоставленной информации и другом ответе Адамо, я нашел статью в базе знаний Microsoft, которая, похоже, напрямую касается вашей проблемы:
В частности, проблема заключается в следующем:
«Эта проблема возникает, если сетевое аппаратное устройство, такое как маршрутизатор, не поддерживает масштабирование окна TCP. Масштабирование окна TCP - новая функция Windows Vista».
Одно из исправлений - выполнение команды, предоставленной adamo. Похоже, вы также сможете обновить маршрутизатор. Глядя на навигатор функций на веб-сайте Cisco похоже, что масштабирование окна TCP поддерживается в новых выпусках IOS для вашего оборудования. Если вы получите новый образ для своего маршрутизатора и установите его там, это должно решить вашу проблему без потери преимуществ масштабирования окна TCP.