IIS 로그에 sc-win32-status = 64가 표시되지만 일부 네트워크를 통해서만 표시 MSIE + 8.0; + Windows +

클라이언트 서버 (W2k3, IIS6, .NET 2.0)에서 실행되는 ASP.NET 응용 프로그램이 있습니다. 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는 동일합니다. 기본적으로 로그는 다음과 같습니다 (일부 데이터를 마스킹 한 경우 제외).

# 필드 : 날짜 시간 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 xxxx GET /File.aspx-80-yyyy 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) 20000
2009-08-11 20:19:45 xxxx POST /File.aspx-80-yyyy 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-yyyy 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) 20000

문제는 페이지가 두 번 적중하는 것입니다. 데이터베이스는 첫 번째 요청에 대한 작업을 수행 한 다음 두 번째 요청은 중복 작업이 수행되고 있음을 감지하고 오류 메시지를 발생시킵니다. 사용자는 작업이 실패했다고 생각하지만 실제로 성공했습니다.

sc-win32-status 64의 오류 설명은 “지정된 네트워크 이름을 더 이상 사용할 수 없습니다.”입니다. 이것은 두 POST 요청 모두 HTTP 상태가 200으로 표시되어 서버가 요청을 성공적으로 처리했지만 클라이언트에게 알리지 않고 요청을 다시 제출한다는 것을 믿습니다.

  • 이 문제를 어떻게 해결할 수 있습니까?

  • 내부 네트워크에서만이 동작을 유발할 수있는 아이디어가 있습니까?

  • 나는이 두 개의 별도의 클라이언트 사이트에서 무슨 일이 일어나고 언급해야하지만, 않습니다 하지 우리의 다른 클라이언트 사이트의 6시에 발생, 또는 우리의 사무실에서, 또는 웹을 통해 8 개 클라이언트의 연결.

  • 이 문제를 로컬 네트워크에서 100 % 재현 할 수 있지만 다른 곳에서는 0 % 재현 할 수있는 것은 무엇입니까?

업데이트 : 매우 작은 수의 복제 된 POST 요청에 원래보고 된대로 64 대신 sc-win32 상태가 995라는 것을 알았습니다. sc-win32-status = 995의 오류 설명은 다음과 같습니다. “스레드 종료 또는 응용 프로그램 요청으로 인해 I / O 작업이 중단되었습니다.” 이것은 말이되지 않습니다 (코드에 대한 모든 액세스 권한이 있다고 간주). 나는 여전히이 문제가 어떻게 또는 왜 발생하는지 이해하지 못하지만 새로운 오류 코드는 결국 네트워크 문제가 아닐 수 있다고 믿게 만들고 무작위 코드 버그의 가능성을 조사하고 있습니다.

답변

이것은 지금까지 문제에 대한 나의 이해입니다.

  • sc-win32-status 64는 “지정된 네트워크 이름을 더 이상 사용할 수 없음”을 의미합니다.
  • IIS가 최종 응답을 클라이언트에 보낸 후 일반적으로 클라이언트로부터 ACK 메시지를 기다립니다.
  • 때때로 클라이언트는 최종 ACK를 서버로 다시 보내는 대신 연결을 재설정합니다. 이것은 적절한 연결이 아니며 IIS는“64”코드를 기록합니다.
  • 많은 클라이언트는 연결이 완료되면 TIME_WAIT / CLOSE_WAIT에 그대로 두지 않고 연결을 해제하기 위해 연결을 재설정합니다.
  • 프록시는 다른 것보다 더 많이하는 경향이 있습니다.

업데이트 : 여기 와 여기에 흥미로운 정보가 있었으므로 기본적으로 페이지를 다시 작성하여 잘못된 마크 업 등이 없었으며 문제가 해결되었습니다! 그것은 어두운 곳에서 촬영 한 것이며, 특정 상황에서 고객에게만 영향을 미쳤 기 때문에 문제가 해결 된 것이 무엇인지 분명히 말할 수 없었습니다 …

답변

프록시 서버를 통해 IIS6에서 gzipped 바이너리 파일을 제공하려고 할 때도 이와 동일한 문제가 발생했습니다. 웹 사이트를 직접 방문 할 때 아무런 문제가 없었습니다.

클라이언트 컴퓨터 에서 Fiddler 를 실행 하고 응답을 검사하여 이것이 내 원인이라는 것을 알았습니다 . 피들러는 응답이 인코딩되었음을 경고 한 다음 gzip 파일의 마법 번호가 올바르지 않다고 불평합니다.

내 코드에서 이진 파일에 대한 gzip 압축을 해제하고 문제가 발생하지 않았습니다.

답변

나는 이것에 대해 전문가가 아니지만 호스트 이름 대신 IP 주소를 사용할 때만 발생하는 비슷한 문제를 겪었습니다.

어쩌면 조금 도움이 될 것입니다 …

매트.

답변