IIS 요청 처리 모델 (Request Processing Models)

[그림1: http://www.adopenstatic.com/faq/IISRequestProcessing.aspx]


일반적으로 위와 같은 순서도에 의해서 사용자 요청처리를 하게 되어 있는데요,. 중간에 웹서버에서 로드한 ISAPI 모듈이 더 많을 경우 처리단계가 더 많아지게 됩니다.

각 처리과정별 Http 오류메시지 코드를 확인할수가 있는데요,. 어떤 처리과정에서 해당 오류메시지가 출력될수 있는지 쉽게 이해하는도 도움이 될듯 싶습니다.

일반적으로 요즘 많이 이용되는 WebKnight 나 UrlScan 처럼 모듈내 처리과정도 매우 많은 단계를 거치게 되는데요. 대용량 접속서버에서는 아무래도 다단계 처리일수록 웹서버에 부하는 증가할 것입니다.


이와함께,.. 위와 같은 처리는 실제 코어서비스 및 각 처리 프로세스간 연동에 의해서 처리되는데요,. 다음 그림은 IIS 6 의 아키텍쳐 구조입니다. 많이 알려진 내용이라... 위 처리도와 함께 IIS 아키텍쳐를 이해하고 있다면 매우 좋습니다.

[그림2: http://www.microsoft.com/technet/]


IIS 6 에서는 5 에서와는 달리 Http 프로토콜 스택(Http.sys) 를 커널에서 처리하고,. 각 요청처리를 별도의 응용프로그램풀(워커프로세스)로 처리하여 WWW Service 와 분리하여 웹서버의 안정성을 높이는 방향으로 개선되었습니다.

요청이 HTTP.sys 에 도착하면, HTTP.sys 는 요청이 정상적인이 아닌지를 판단하게 됩니다. 비정상적 요청이라면 해당 클라언트에게 요청을 그대로 해당코드 그대로 오류 리턴해 버립니다.

만약 정상적인 요청이라면,. 요청된 내용이 정적컨텐츠(Html 같은..) 라면 즉시 클라이언트에게 리턴을 해주고,.  동적컨텐츠(asp..) 라면 커널모드 케시에 해당 내용이 먼저 있는지 확인후에 캐시에 있다면 즉시 처리내용을 리턴해주고,. 

없다면 HTTP.sys 는  해당 요청 도메인이 속한 응용프로그램풀에 요청을 할당 합니다. 그러면,. 해당 요청을 처리후에 처리내용을 HTTP.sys 받고, 캐시를 한다음에 클라이언트에게 처리완료된 내용을 리턴해주게 됩니다.


그림1. 2 에 있는것은 실제 IIS Request Tracing 를 통해서도 확인해 볼수 있습니다.

- IIS Admin 서비스를 추적하는 방법: http://www.serverinfo.pe.kr/TipnTech.aspx?Seq=279

- IIS Request-Based Tracing (IIS 6.0) : http://www.microsoft.com/technet/prodtechnol/
WindowsServer2003/Library/IIS/b0aef644-7b19-418d-b658-fde4a93678a9.mspx

24-iis-1.gif
24-iis-2.gif