Назад | Перейти на главную страницу

Журналы IIS показывают sc-win32-status = 64, но только через некоторые сети

У меня есть приложение ASP.NET, работающее на клиентском сервере (W2k3, IIS6, .NET 2.0). FWIW, это Тест например, он не был перемещен в Производство все же. Таким образом, он не работает под SSL, балансировкой нагрузки и т. Д.

Когда я открываю одну из страниц на их сервере из нашего офиса, страница попадает один раз. Проверка журналов IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) показывает GET для этой страницы, затем я нажимаю кнопку на странице, и в файле журнала отображается POST. Кажется, пока это работает нормально.

Теперь, когда я подключаюсь к сети клиента и получаю доступ к странице с одной из их локальных машин, в файле журнала отображается GET, затем я нажимаю кнопку на странице, и журнал показывает два POST в ту же секунду. Первый показывает статус (sc-status, sc-substatus, sc-win32-status) 200 0 64, второй показывает 200 0 0.

В файле журнала оба POST идентичны. В основном журнал выглядит так (за исключением того, что я замаскировал некоторые данные):

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 x.x.x.x GET /File.aspx - 80 - y.y.y.y Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.0;+WOW64;+Trident/4.0;+SLCC1;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618;+MDDR;+OfficeLiveConnector.1.4;+OfficeLivePatch.0.0) 200 0 0
2009-08-11 20:19:45 x.x.x.x POST /File.aspx - 80 - y.y.y.y Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.0;+WOW64;+Trident/4.0;+SLCC1;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618;+MDDR;+OfficeLiveConnector.1.4;+OfficeLivePatch.0.0) 200 0 64
2009-08-11 20:19:45 x.x.x.x POST /File.aspx - 80 - y.y.y.y Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.0;+WOW64;+Trident/4.0;+SLCC1;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618;+MDDR;+OfficeLiveConnector.1.4;+OfficeLivePatch.0.0) 200 0 0

Проблема в, страница получает двойное нажатие. База данных выполняет операцию для первого запроса, затем второй запрос обнаруживает, что выполняется повторяющаяся операция, и выдает сообщение об ошибке. Пользователи думают, что их операция не удалась, но на самом деле это удалось.

Описание ошибки sc-win32-status 64: «Указанное сетевое имя больше не доступно». Это наводит меня на мысль, учитывая, что оба запроса POST показывают статус HTTP 200, что сервер успешно обслуживает запрос, но клиент никогда не получает уведомления и повторно отправляет запрос.

Обновить: Я обнаружил, что у очень небольшого количества дублированных запросов POST sc-win32-status было 995 вместо 64, как первоначально сообщалось. Описание ошибки sc-win32-status = 995: «Операция ввода-вывода была прервана из-за выхода потока или запроса приложения». В этом нет никакого смысла (учитывая, что у меня есть полный доступ к коду). Я до сих пор не понимаю, как и почему возникает эта проблема, но новый код ошибки заставляет меня думать, что это, возможно, не проблема сети, и теперь я исследую возможность случайной ошибки кода.

Это мое понимание проблемы до сих пор:

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

Обновить: Я нашел интересную информацию Вот и Вот, поэтому я в основном переписал страницу, чтобы убедиться, что не было плохой разметки и т. д., и ... проблема исчезла! Это был всего лишь выстрел в темноте, и я не мог однозначно сказать, что именно решило проблему, поскольку это затрагивало некоторых наших клиентов только при некоторых очень специфических обстоятельствах ...

У меня возникла та же проблема, когда я пытался передать сжатые двоичные файлы из IIS6 через прокси-сервер. При прямом переходе на сайт проблем не возникало.

Я обнаружил, что это была причина в моем случае, запустив Скрипач на клиентской машине и проверяю ответ. Fiddler предупреждает, что ответ закодирован, а затем жалуется, что магическое число в файле gzip неверно.

Я отключил сжатие gzip для двоичных файлов в своем коде, и проблема перестала возникать.