[server] IIS 로그에 sc-win32-status = 64가 표시되지만 일부 네트워크를 통해서만 표시

Server / 글쓴이

클라이언트 서버 (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 주소를 사용할 때만 발생하는 비슷한 문제를 겪었습니다.

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

매트.

답변