Зависание / время ожидания загрузки файла IIS - sc-win32-status = 64

Question

Любые мысли о том, почему я могу получить тонны "зависаний" при попытке загрузить файл через HTTP, основаны на следующем?

• Сервер IIS 6
• Загружаемый файл является двоичным файлом, а не веб-страницей
• Зависает несколько клиентов, в том числе пакеты веб-обновлений TrueUpdate и FlexNet, а также пользовательское приложение .NET, которое просто выполняет базовую логику HttpWebRequest / HttpWebResponse и загружает с использованием потока ответов
• Подпись файла журнала IIS при успехе 200 0 0 (sc-status sc-substatus sc-win32-status)
• При ошибке подпись ошибки составляет 200 0 64
• sc-win32-status из 64 означает «указанное имя сети больше не доступно»
• Я могу указать firefox на URL-адрес и успешно загружать каждый раз (возможно, некоторая логика повторения происходит под капотом)

В этот момент мне кажется, что с моим сервером что-то не так, что он выдает эти ошибки, или это просто нормальное поведение сети, и мне нужно использовать (или написать) клиент, более устойчивый к сбоям.

Есть мысли?

Answer 1

Возможно, ваша проблема была связана с сетевым подключением низкого уровня с провайдером, как вы предположили в своем ответном комментарии. Я испытываю похожую проблему с IIS и некоторыми загадочными 200 0 64 строками, которые появляются в файле журнала, и именно так я нашел этот пост. Для справки, это мое понимание sc-win32-status = 64; Я надеюсь, что кто-то может исправить меня, если я ошибаюсь.

• sc-win32-status 64 означает «Указанное имя сети больше не доступно».
• После того, как IIS отправил окончательный ответ клиенту, он ожидает от клиента сообщения ACK.
• Иногда клиенты сбрасывают соединение вместо отправки окончательного подтверждения на сервер. Это не грациозное закрытие соединения, поэтому IIS регистрирует код «64», чтобы указать прерывание.
• Многие клиенты сбрасывают соединение, когда они закончили с ним, чтобы освободить сокет вместо того, чтобы оставлять его в TIME_WAIT / CLOSE_WAIT.
• Прокси могут иметь тенденцию делать это чаще, чем отдельные клиенты.

Answer 2

Я потратил две недели на изучение этой проблемы. Для меня у меня был сценарий, в котором прерывистые случайные запросы преждевременно прекращались. Это приводило к журналам IIS с кодом состояния 200, но с win32-состоянием 64.

Наша инфраструктура включает в себя два сервера Windows IIS за двумя балансировщиками нагрузки NetScaler в режиме высокой доступности.

В моем конкретном случае проблема заключалась в том, что в NetScaler была включена функция «Интегрированное кэширование» (http://support.citrix.com/proddocs/topic/ns-optimization-10-5-map/ns-IC-gen-wrapper-10-con.html).

После отключения этой функции прерывания запроса прекратились. И сайт работал нормально. Я не уверен, как или почему это вызывало проблему, но это так.

Если вы используете прокси-сервер или балансировщик нагрузки, выясните, какие функции они включили. Для меня причиной было что-то между клиентом и сервером, прерывающим запросы.

Я надеюсь, что это объяснение хотя бы сэкономит чужое время.

Answer 3

Потратил на это три дня. Это был тайм-аут, который был установлен на 4 секунды (запрос curl php). Решением было увеличить настройку тайм-аута:

//curl_setopt($ch, CURLOPT_TIMEOUT, 4); // times out after 4s
curl_setopt($ch, CURLOPT_TIMEOUT, 60); // times out after 60s

Answer 4

Проверьте заголовки с сервера, особенно тип контента и длину контента, возможно, что ваши клиенты не распознают формат двоичного файла и зависают при ожидании байтов, которые никогда не приходят, или, возможно, они закрывают базовое TCP-соединение, которое может привести к тому, что IIS зарегистрирует состояние win32 64.

Answer 5

Я предлагаю вам поставить Fiddler между вашим сервером и клиентом загрузки. Это должно выявить различия между Firefox и другими пользователями.

Answer 6

Вам нужно будет использовать проводник или сетевой монитор, чтобы собрать больше данных по этой проблеме. Я думаю.