Dzienniki IIS pokazują sc-win32-status = 64, ale tylko przez niektóre sieci

Mam aplikację ASP.NET działającą na serwerze klienta (W2k3, IIS6, .NET 2.0). FWIW, to jest instancja testowa , nie została jeszcze przeniesiona do produkcji . Więc nie działa w trybie SSL, równoważenia obciążenia itp.

Kiedy uzyskuję dostęp do jednej ze stron na serwerze z naszego biura, strona zostaje trafiona raz. Sprawdzanie dzienników IIS (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) pokazuje GET dla tej strony, następnie wciskam przycisk na stronie, a plik dziennika pokazuje POST. Wygląda na to, że do tej pory działało dobrze.

Teraz, gdy zdalnie włączam się do sieci klienta i uzyskuję dostęp do strony z jednego z ich lokalnych komputerów, plik dziennika pokazuje GET, następnie wciskam przycisk na stronie, a dziennik pokazuje dwa testy POST w tym samym momencie. Pierwszy pokazuje status (sc-status, sc-podstatus, sc-win32-status) 200 0 64, drugi pokazuje 200 0 0.

W pliku dziennika oba POST są identyczne. Zasadniczo dziennik wygląda tak (z wyjątkiem tego, że zamaskowałem niektóre dane):

# Pola: data godzina s-ip cs-method cs-uri-stem cs-uri-query s-port cs-nazwa użytkownika c-ip cs (User-Agent) sc-status sc-podstacja sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - rrrr Mozilla / 4.0 + (kompatybilny; + 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 - rrrr Mozilla / 4.0 + (kompatybilny; + 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 - rrrr Mozilla / 4.0 + (kompatybilny; + 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

Problem polega na tym , że strona trafia dwukrotnie. Baza danych wykonuje operację dla pierwszego żądania, a następnie drugie żądanie wykrywa, że ​​wykonywana jest zduplikowana operacja i wyświetla komunikat o błędzie. Użytkownicy myślą, że ich operacja się nie powiodła, ale tak naprawdę się udało.

Opis błędu sc-win32-status 64 brzmi: „Określona nazwa sieci nie jest już dostępna”. To prowadzi mnie do przekonania, biorąc pod uwagę, że oba żądania POST pokazują status HTTP 200, że serwer pomyślnie obsługuje żądanie, ale klient nigdy nie jest powiadamiany i przesyła żądanie ponownie.

• Jak mogę rozwiązać ten problem?

• Wszelkie pomysły, co może być przyczyną takiego zachowania tylko w ich wewnętrznej sieci?

• Powinienem wspomnieć, że dzieje się to w dwóch oddzielnych witrynach klientów, ale nie dzieje się to w sześciu innych witrynach naszych klientów ani w naszym biurze, ani też nie łączy się z żadnym z naszych ośmiu klientów przez Internet.

• Co może sprawić, że będzie to powtarzalne 100% czasu w sieci lokalnej, ale 0% czasu gdziekolwiek indziej?

Aktualizacja: Odkryłem, że bardzo mała liczba zduplikowanych żądań POST miała status sc-win32 995 zamiast 64, jak pierwotnie podano. Opis błędu sc-win32-status = 995 brzmi: „Operacja we / wy została przerwana z powodu wyjścia wątku lub żądania aplikacji”. To nie ma sensu (biorąc pod uwagę, że mam pełny dostęp do kodu). Nadal nie rozumiem, w jaki sposób i dlaczego występuje ten problem, ale nowy kod błędu prowadzi mnie do wniosku, że może to nie być problem z siecią, a teraz badam możliwość wystąpienia błędu losowego kodu.

Oto moje dotychczasowe zrozumienie problemu:

• sc-win32-status 64 oznacza „Określona nazwa sieci nie jest już dostępna”.
• Po wysłaniu przez IIS ostatecznej odpowiedzi do klienta, zwykle czeka ona na wiadomość ACK od klienta.
• Czasami klienci resetują połączenie zamiast wysyłać końcowe potwierdzenie ACK z powrotem na serwer. To nie jest wdzięczne zamknięcie połączenia, więc IIS rejestruje kod „64”.
• Wielu klientów zresetuje połączenie po ich zakończeniu, aby zwolnić gniazdo zamiast pozostawiać go w TIME_WAIT / CLOSE_WAIT.
• Serwery proxy robią to częściej niż inni.

Aktualizacja: Tu i tutaj znalazłem kilka interesujących informacji , więc w zasadzie ponownie napisałem stronę, aby upewnić się, że nie ma złych znaczników itp. I ... problem zniknął! To był tylko strzał w ciemność i nie mogłem definitywnie powiedzieć, co naprawiło problem, ponieważ wpłynęło to tylko na niektórych naszych klientów w bardzo szczególnych okolicznościach ...

Ten sam problem wystąpił podczas próby udostępniania spakowanych plików binarnych z IIS6 za pośrednictwem serwera proxy. Nie miałem żadnego problemu, gdy wchodziłem bezpośrednio na stronę.

Stwierdziłem, że taka była przyczyna w moim przypadku, uruchamiając Fiddler na maszynie klienta i sprawdzając odpowiedź. Skrzypek ostrzega, że ​​odpowiedź jest zakodowana, a następnie skarży się, że magiczna liczba w pliku gzip była nieprawidłowa.

Wyłączyłem kompresję gzip dla plików binarnych w moim kodzie i problem przestał występować.

Nie jestem ekspertem w tej dziedzinie, ale natknąłem się na podobny problem, który wystąpił tylko przy użyciu adresu IP zamiast nazwy hosta.

Może to trochę pomaga ...

Mata.