Журналы 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: дата и время s-ip cs-метод cs-uri-stem cs-uri-запрос s-порт cs-имя пользователя c-ip cs (пользователь-агент) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - гггг Mozilla / 4.0 + (совместимый; + 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 xxxx POST /File.aspx - 80 - гггг Mozilla / 4.0 + (совместимый; + 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 xxxx POST /File.aspx - 80 - гггг Mozilla / 4.0 + (совместимый; + 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, что сервер успешно обработал запрос, но клиент никогда не уведомляется и повторно отправляет запрос.

• Как я могу устранить это?

• Есть идеи, что может быть причиной такого поведения только в их внутренней сети?

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

• Что может сделать это воспроизводимым 100% времени в их локальной сети, но 0% времени в другом месте?

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

Это мое понимание вопроса до сих пор:

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

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

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

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

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

Я не эксперт в этом, но я столкнулся с подобной проблемой, которая возникала только при использовании IP-адреса, а не имени хоста.

Может быть, это немного помогает ...

Мат.