Подтвердить что ты не робот

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

Любые мысли о том, почему я могу получать тонны "зависаний" при попытке загрузить файл через 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-адресу и загружаться каждый раз (возможно, какая-то логика повторения происходит под капотом)

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

Любые мысли?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Я надеюсь, что это объяснение по крайней мере спасет кого-то еще.

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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