|
Internet Information Services (IIS) 6.0 기술 개요
요약
관리자들과 웹 어플리케이션 개발자들은 확장성 있고 안전하면서 빠르고 안정적인 웹 플랫폼을 요구하고 있습니다. Internet Information Services (IIS 6.0)과 Microsoft?? Windows?? Server 2003은 웹 어플리케이션 서버 관리와 가용성, 안정성, 보안, 성능 및 확장성을 위한 다양한 신기능들을 소개하고 있으며 전 세계 고객들의 요구 사항을 충족시켜주기 위해 구조적으로 대폭 개선되었습니다.
이 문서는 여러분이 IIS 6.0을 배포할 때 Windows Server 제품군에서 이용할 수 있는 차세대 웹 인프라 기능들에 대해 간략하게 설명합니다. IIS 6.0과 Windows Server 2003은 가장 신뢰할 수 있고 생산적이며 연결성이 높은 통합 웹 서버 솔루션을 제공합니다.
목차
어플리케이션 서버 구성하기……………………………………………………………………………2
Configure Your Server 어플리케이션.. 2
Add/Remove Components 어플리케이션.. 2
IIS 6.0 아키텍처—새로운 요청 프로세싱 아키텍처... 3
요청 프로세싱 아키텍처…………………………………………………………………………………3
작업자 프로세스 분리 모드……………………………………………………………………………..4
어플리케이션이나 사이트가 다른 어플리케이션이나 사이트를 중단시키지 못하도록 함.. 5
IIS 5.0 분리 모드…………………………………………………………………………………………8
잠금 상태의 서버……………………………………………………………………………………….10
IIS 웹 서비스 확장 프로그램 이용하여 기능 잠그기.. 10
구성 가능한 작업자 프로세스 독자성…………………………………………………………………11
IIS는 기본적으로 낮은 권한의 계정으로 실행됩니다……………………………………………….11
SSL 개선 기능 ………………………………………………………………………………………….11
Passport 통합……………………………………………………………………………………………12
URL 인증과 새로운 인증 프레임 워크 확장하기 ….…………………………………………………12
강제적이고 위임된 인증………………………………………………………………………………...12
XML 메타데이터…………………………………………………………………………………………14
XML 형식의 일반 텍스트 메타베이스 파일의 이점.. 14
IIS WMI 공급자………………………………………………………………………………………….16
명령줄 관리…………………………………………………………………………………………… 16
새로운 웹 기반 관리 콘솔………………………………………………………………………………17
HTTP.sys—새로운 커널 모드 드라이버…………………………………………………………… 19
캐싱 정책 및 스레드 관리…………………………………………………………………………… 19
웹 가든………………………………………………………………………………………………… .19
지속적인 ASP 템플릿 캐시…………………………………………………………………………… 19
x86.0을 위한 대용량 메모리 지원…………………………………………………………………….19
사이트 확장성…………………………………………………………………………………………...20
ASP.NET과 IIS 통합 및 다양한 언어 선택…………………………………………………………..21
ExecuteURL…………………………………………………………………………………………….21
글로벌 인터셉터………………………………………………………………………………………..22
VectorSend……………………………………………………………………………………………...22
동적 컨텐트 캐싱………………………………………………………………………………………..22
ReportUnhealthy………………………………………………………………………………………..22
Custom Errors………………………………………………………………………………………….23
Unicode ISAPI………………………………………………………………………………………….23
ASP의 COM+ 서비스………………………………………………………………………………… 23
64-비트 지원……………………………………………………………………………………………25
IPv6.0 지원……………………………………………………………………………………………..25
미세 압축………………………………………………………………………………………………..25
리소스 계정과 Quality-of-Service (QoS)…………………………………………………………….25
로깅 개선 기능………………………………………………………………………………………….25
File Transfer Protocol (FTP)…………………………………………………………………………..26
관리자들과 웹 어플리케이션 개발자들은 확장성 있고 안전하면서 빠르고 안정적인 웹 플랫폼을 요구하고 있습니다. Internet Information Services (IIS 6.0)와 Microsoft?? Windows?? Server 2003은 웹 어플리케이션 서버 관리와 가용성, 안정성, 보안, 성능 및 확장성을 위한 다양한 신기능들을 소개하고 있으며 전 세계 고객들의 요구 사항을 충족시켜주기 위해 구조적으로 대폭 개선되었습니다.
이 문서는 Windows Server 제품군에서 이용할 수 있는 차세대 웹 인프라 기능들에 대해 간략하게 설명하고 있으며 여러분이 IIS 6.0을 배포할 때 사용할 수 있는 새로운 기술적 기능과 이점에 대해서도 설명하고 있습니다.
이 백서에서 다루고 있는 주제들:
· IIS 6.0 아키텍처—새로운 요청 프로세싱 아키텍처
· 플랫폼 개선 기능
어플리케이션 서버는 Windows Server 2003 제품군을 위한 새로운 서버 역할입니다. 이 새로운 서버 역할은 어플리케이션 서버라 불리는 단일 제품에 여러 가지 핵심 서버 기술들을 결합하고 있으며 이러한 기술들은 다음과 같습니다.
서버의 이러한 기술들을 한 곳에 결합함으로써 웹 어플리케이션 개발자와 관리자들은 이제 서버에 별도의 소프트웨어를 설치하지 않고도 데이터베이스를 운영하는 ASP.NET 어플리케이션과 같은 동적 컨텐트를 호스트할 수 있게 되었습니다.
어플리케이션 서버는 Windows Server 2003 내의 두 지점에 구성할 수 있습니다.
Configure Your Server (CYS) 어플리케이션은 Windows Server 2003 역할을 구성하는 중앙 지점이며 이젠 어플리케이션 서버라 불리는 새로운 역할을 포함하고 있습니다. 이 역할은 기존 웹 서버 역할을 대신합니다. 이러한 새로운 역할이 설치되면, 역할 관리는 Manage Your Server 어플리케이션에 의해 수행되는데 이 어플리케이션에는 어플리케이션 서버를 위한 새로운 항목이 포함되어 있습니다.
어플리케이션 서버는 최 상위 수준의 선택적 구성요소로서 Windows Add/Remove Components 어플리케이션에 위치해 있는데 여기엔 어플리케이션 서버(IIS, ASP.NET, COM+, and MSMQ)에 속해있는 서버 어플리케이션이 설치될 수 있으며 그들의 하위 구성요소가 구성되는 새로운 위치입니다. 어플리케이션 서버를 구성하는 Windows Add/Remove 구성요소 방식은 설치할 특정 하위 구성요소들을 보다 세밀하게 제어하기 위한 라우트입니다.
웹 사이트와 어플리케이션 코드는 점점 더 복잡해지고 있습니다. 고객 환경에 호스트되어 있는 사용자 지정 어플리케이션과 웹 사이트에는 불완전한 코드가 포함될 수도 있습니다. 그러므로 프로세스를 호스팅하려면 메모리 누출, 액세스 위반 및 기타 오류들을 자동으로 탐지함으로써 런타임 환경을 기민하게 관리할 수 있어야 합니다. 이러한 오류가 발생할 경우, 기본 아키텍처는 내결함성이 있어야 하며 필요한 프로세스를 민첩하게 재생하거나 재시작해야 하며 최종 사용자의 사용이 중단되는 일 없이 지속적으로 요청을 대기시켜 놓아야 합니다.
이러한 강력하고 민첩하게 관리되는 런타임을 제공하기 위해 IIS 6.0은 커널 수준의 요청 대기 기능을 제공합니다. 이는 작업자 프로세스 분리 모드로 알려진 민첩한 프로세스 관리 기능을 갖춘 새로운 어플리케이션 분리 환경입니다.
IIS 5.0은 Inetinfo.exe라는 하나의 프로세스만을 가지도록 설계되었으며, 요청을 하나 이상의 독립 프로세스 어플리케이션(dllhost.exe)에 분배할 수 있는 주 웹 서버 프로세스로서 작동합니다. 이에 반하여 IIS 6.0은 새로운 커널 모드 드라이버를 사용하는 두 개의 새로운 구성요소로 재설계되었습니다. 이로써 IIS는 코드를 처리하는 어플리케이션에서 핵심 웹 서버 코드를 분석할 수 있게 되었습니다. 이러한 두 가지 새로운 구성요소는 다음과 같습니다.
· HTTP.sys—커널 모드 HTTP 리스너
· WWW 서비스 관리 및 모니터링 구성요소 —사용자 모드 구성 및 프로세스 관리자
작업자 프로세스[1] 서비스는 HTTP.sys의 어플리케이션 풀(pools)[2]을 요청합니다.
참고 8개의 프로세서를 가진 서버를 이용한 벤치마크에서 기존 버전에 비해 100% 이상의 처리량을 나타낸다는 것이 사전 테스트를 통해 확인되었습니다. 이는 웹 어플리케이션 서버의 새로운 요청 프로세싱 아키텍처와 확장성 개선 기능으로 인한 것입니다.
IIS 6.0에서 HTTP.sys는 요청을 수신하고 이러한 요청들을 각 요청에 대한 해당 대기열에 대기시킵니다. 각 요청 대기열은 하나의 어플리케이션 풀에 해당합니다. HTTP.sys에는 써드파티 코드가 실행되지 않으므로, 일반적으로 웹 서비스의 상태에 영향을 미치는 사용자 모드 코드상의 오류로 인한 영향을 받지 않습니다.
만약 무언가가 사용자 모드 요청 프로세싱 인프라를 종료시킨 경우, WWW service가 작동되는 한 HTTP.sys는 지속적으로 요청을 수신하고 대기시킵니다. HTTP.sys는 요청을 수신하여 더 이상 사용할 수 있는 대기열이 없고 대기열에 더 이상의 공간이 남아있지 않거나 웹 서비스가 중단될 때까지 해당 대기열에 요청을 지속적으로 대기시킵니다.
작업자 프로세스가 중단된 것을 WWW 서비스가 알게 되고 처리되지 못한 요청이 작업자 프로세스의 어플리케이션 풀을 위해 처리되도록 대기중인 경우엔 새로운 작업자 프로세스를 시작합니다. 그러므로 사용자 모드 요청 프로세스가 일시적으로 중단된 경우에도 요청이 계속 수신되고 대기되므로 최종 사용자는 프로세스가 중단된 사실을 알 지 못합니다.
새로운 IIS 6.0 아키텍처의 또 다른 핵심 부분은 WWW 서비스 관리 및 모니터링 구성요소의 기능성입니다. WWW 서비스 관리 및 모니터링 구성요소는 HTTP.sys와 같은 중요한 IIS 6.0 서비스가 위치해있고 써드파티 코드가 절대 로드되지 못하는 WWW 서비스의 핵심 부분을 구성하고 있습니다.
IIS 6.0은 핵심 웹 서버에서 써드 파티 어플리케이션 코드를 완벽하게 분리시킵니다. 이는 WWW 서비스와 HTTP.sys에 중요한 웹 서버 기능(구성 관리 및 요청 대기와 같은)을 보관해둠으로써 가능하며 어플리케이션 코드가 작업자 프로세스라 불리는 전용 미니 웹 서버 프로세스에서 실행되도록 합니다.
WWW 서비스 관리 및 모니터링 구성요소는 구성과 프로세스 관리라는 두 가지 주요 부문을 담당하고 있습니다. 초기화 때, WWW 서비스의 요청 프로세스 관리자 부분은 메타데이터 정보를 읽고 각 어플리케이션 별로 하나의 항목을 가지고 있는 HTTP.sys 이름 공간 라우팅 테이블을 초기화합니다. 각 항목에는 어플리케이션 풀에 매핑된 URL을 지정 어플리케이션 풀에 라우트한 정보가 들어있습니다.
이러한 사전 등록 단계는 HTTP.sys에게 해당 이름 공간의 요청에 응답하는 어플리케이션이 있다는 것을 알려주고 요청 시, HTTP.sys가 어플리케이션 풀을 위해 작업자 프로세스가 시작되도록 요청할 수 있다는 것을 알려줍니다. 모든 사전 등록 작업은 HTTP.sys가 요청을 프로세스에 라우트하기 전에 이루어집니다. 어플리케이션 풀과 새로운 어플리케이션이 추가될 때, 웹 서비스는 HTTP.sys가 새로운 URL에 대한 요청을 수용하고, 새로운 어플리케이션 풀을 위한 새로운 요청 대기열을 설정하며 새로운 URL이 어디에 라우트되어야 할 지를 알려주도록 구성합니다.
요청 프로세스 관리 역할에서 WWW 서비스 관리 및 모니터링 구성요소는 요청을 처리하는 작업자 프로세스의 주기를 조절합니다. 이를 위해선 다음과 같은 작업들을 결정해야 합니다.
· 언제 작업자 프로세스를 시작해야 하는지
· 언제 작업자 프로세스를 재생해야 하는지
· 더 이상의 요청을 처리하지 못할 경우 언제 작업자 프로세스를 다시 시작해야 하는지.
IIS 6.0은 작업자 프로세스 분리 모드를 도입하고 있으며 이는 분리된 환경에서 모든 어플리케이션 코드를 실행하지만 기존 IIS 버전보다 성능이 저하되지는 않습니다. HTTP 요청은 올바른 어플리케이션 풀 대기열에 라우트됩니다. 어플리케이션 풀을 제공하는 사용자 모드 작업자 프로세스는 HTTP.sys에서 요청을 직접 가져오고 요청을 독립 프로세스 DLL 호스트로 보내고 다시 되돌려 받아야 하는 경우 발생되는 불필요한 프로세스 홉들을 제거합니다.
IIS 6.0에는 더 이상 종속 프로세스 어플리케이션이 존재하지 않습니다. ISAPI 확장 프로그램 지원과 같은 모든 필수 HTTP 어플리케이션 런타임 서비스는 모든 어플리케이션 풀에서 동일하게 사용할 수 있습니다. 이러한 설계는 기능 장애가 있는 웹 어플리케이션이나 웹 서버가 그러한 서버상의 다른 작업자 프로세스에서 제공하는 다른 웹 어플리케이션(또는 다른 웹 사이트)을 방해하지 못하도록 합니다. 이로써 전체 웹 서비스를 중단시키지 않고도 종속 프로세스 구성요소를 언로드할 수 있게 되었습니다. 호스트 작업자 프로세스는 컨텐트를 제공하는 다른 작업자 프로세스에 영향을 미치지 않고도 일시적으로 중단될 수 있습니다. 어플리케이션 풀 별로 프로세스 수준에서 사용할 수 있는 다른 운영 체제 서비스(예:CPU 조절)를 활용할 수 있는 이점도 있습니다. 그리고 Windows는 보다 많은 동시 프로세스를 지원할 수 있도록 재설계되었습니다.
IIS 6.0 작업자 프로세스 분리 모드 방식은 관리자로 하여금 각기 다른 웹 어플리케이션이나 웹 사이트를 어플리케이션 풀이라 불리는 별도의 그룹으로 만들 수 있도록 합니다. 부문별 서버의 경우 하나의 어플리케이션 풀에는 Web-HR을 두고 다른 풀에는 Web-Finance을 둘 수 있습니다. 인터넷 서비스 공급자(ISP)의 경우 하나의 어플리케이션 풀에는 CustomerX.com을 두고 다른 풀에는 CustomerY.com을 둘 수도 있습니다.
어플리케이션 풀은 하나 이상의 작업자 프로세스를 공유하는 일련의 웹 어플리케이션을 정의합니다. 각 어플리케이션 풀은 프로세스 경계에 의해 다른 어플리케이션 풀들과 구분됩니다. 하나의 어플리케이션 풀에 라우트되어 있는 어플리케이션은 다른 어플리케이션 풀의 영향을 받지 않으며, 현재 어플리케이션 풀에 의해 서비스되는 동안 그 어플리케이션은 다른 어플리케이션 풀에 라우트될 수 없습니다.
참고 어플리케이션은 서버가 실행되는 동안에도 다른 어플리케이션 풀에 할당될 수 있습니다.
어플리케이션 풀은 효율적인 이름공간 그룹입니다. HTTP.sys에서 어플리케이션 풀은 어플리케이션 풀을 제공하는 사용자 모드 작업자 프로세스가 요청을 가져올 수 있는 요청 대기열을 말합니다.
작업자 프로세스 분리 모드는 어플리케이션이나 사이트가 다른 어플리케이션이나 사이트를 중단시키지 못하도록 합니다. 또한 어플리케이션이나 사이트를 별도의 작업자 프로세스로 구별해줌으로써 사이트/어플리케이션을 온라인화 또는 오프라인화하고(시스템에서 실행중인 모든 사이트/어플리케이션에 대해 독립적으로) 어플리케이션이 사용하는 구성요소를 변경하며 어플리케이션을 디버깅하고 어플리케이션에 대한 카운터를 모니터링하고 어플리케이션이 사용하는 리소스를 조절하는 등의 다양한 관리 작업이 간편해집니다.
작업자 프로세스 분리 모드는 특히 다음 부문에 있어서 기존 기능보다 개선되었습니다.
· 견고함. 이 아키텍처는 IIS 6.0 작업자 프로세스 분리 모드가 제공하는 각기 다른 웹 어플리케이션이나 웹 사이트들이 서로간에 또는 서버에 손상을 주지 않도록 합니다.
· 재부팅이 필요없음. 사용자는 서버를 재부팅하거나 전체 WWW 서비스를 중단시킬 필요가 전혀 없습니다. 컨텐트나 구성요소 업그레이드, 웹 어플리케이션 디버깅 또는 오류가 발생한 웹 어플리케이션 처리와 같은 일반 작업들은 서버상의 다른 사이트나 어플리케이션에 대한 서비스에 영향을 주지 않습니다.
· 자가 치료. IIS 6.0은 중단된 어플리케이션의 자동 재시작 및 기능 불량 어플리케이션이나 잘못된 코드를 가지고 있는 어플리케이션의 주기적 재시작 기능을 지원합니다.
· 확장형. IIS 6.0은 서버에 수 백개에서 수 천개의 사이트가 있는 ISP 시나리오에 대한 확장성을 지원합니다. IIS 6.0는 서버상의 동등한 작업자 프로세스들이 제각기 서버상의 단일 작업자 프로세스에 의해 제공되는 요청의 일부를 수신하는 웹 가든도 지원합니다. 이는 우수한 멀티프로세서 확장성을 지원합니다.
· 강력한 어플리케이션 개념. IIS 6.0은 어플리케이션을 관리 단위로서 지원합니다. 이는 어플리케이션이 분리되도록 하여 어플리케이션을 ‘견고함’의 단위가 되도록 하고 어플리케이션을 기반으로 리소스를 조절하고 확장할 수 있도록 합니다.
결론은 어플리케이션 자신이 호스팅하는 작업자 프로세스가 종료되는 경우에도 웹 서버가 훨씬 안정적이고 가용성이 높아졌다는 것입니다.
작업자 분리 모드는 IIS 4.0에 도입된 어플리케이션 분리 개념을 한층 개발시킨 것입니다. 어플리케이션은 서로 간에 완벽하게 분리될 수 있으며 이때 어플리케이션 오류는 다른 프로세스상의 다른 어플리케이션에는 영향을 미치지 않습니다. IIS 6.0 작업자 프로세스 분리 모드는 보다 우수한 분리 기능을 제공하는데, 분리 시 성능이 저하되지는 않습니다. 사용자 모드 프로세스가 어플리케이션에 대한 커널로부터 요청을 가져오도록 하지 않고 커널에서 요청을 직접 가져온 다음 다른 사용자 모드 프로세스에 적절히 라우트합니다.
작업자 프로세스 분리 모드에는 다음과 같은 기능들이 포함되어 있으며 이는 성능에는 영향을 주지 않고 견고성을 향상시킵니다.
사용자 코드와 서버간의 완벽한 분리. 모든 사용자 코드는 핵심 웹 서버에서 완벽하게 분리되어 있는 작업자 프로세스에 의해 처리됩니다. 이는 ISAPI가 핵심 웹 서버에 대한 종속 프로세스에 주로 호스트되는 IIS 5.0를 향상시킵니다.
작업자 프로세스에 로드되어 있는 ISAPI가 중단되거나 액세스 위반을 한 경우에 취할 수 있는 유일한 방법이 ISAPI를 호스트하는 작업자 프로세스입니다. 한편 WWW 서비스는 중단된 작업자 프로세스를 대체할 새로운 작업자 프로세스를 생성하며 이 때 다른 작업자 프로세스들은 영향을 받지 않습니다.
다중 어플리케이션 풀. With IIS 5.0, 어플리케이션들은 독립 프로세스로 함께 풀링될 수 있지만 하나의 어플리케이션(DLLHOST.EXE)에서만 가능합니다. IIS 6.0이 작업자 프로세스 분리 모드에서 작동할 때, 관리자는 여러 개의 어플리케이션 풀을 만들 수 있으며, 이때 각 어플리케이션 풀은 (리사이클링 구성 등과 같은) 각기 다른 구성을 가질 수 있습니다.
우수한 로드 밸런서 지원. 어플리케이션 풀의 출현으로 IIS는 어플리케이션의 물리적 구분이 매우 잘 정의되어 있습니다. 그러므로 한 대의 Windows 서버에서 수백, 수천 개의 사이트 및 어플리케이션을 연동하여 실행할 수도 있습니다. 이 구성에서는 문제가 있는 하나의 어플리케이션이 다른 여러 온전한 어플리케이션에 영향을 미치지 못한다는 점이 중요합니다. 서버로 하여금 다른 온전한 어플리케이션에 대한 요청을 수용하도록 하면서, 문제가 있는 어플리케이션에 대한 트래픽만을 라우트하기 위해선 로드 밸런서나 스위치와 자동으로 커뮤니케이션할 수 있도록 하는 것이 좋습니다.
예를 들어, 어플리케이션 A와 B에 대한 서버 프로세싱 요청을 가정해봅시다. 어플리케이션 B에 오류가 자주 발생하여 IIS는 이 어플리케이션이 자동으로 종료되도록 결정한 경우에도(아래의 신속한 오류 보호 섹션 참조), 서버는 어플리케이션 A에 대한 요청을 수신할 수 있어야 합니다.
IIS 6.0은 WWW 서비스가 특정 어플리케이션의 오류를 탐지한 경우 이벤트와 명령을 실행할 수 있는 기본 확장성 모델을 보유하고 있습니다. 이 구성 능력으로 인해 로드 밸런서와 스위치는 온전한 어플리케이션에 트래픽을 라우팅하면서 동시에 문제가 있는 어플리케이션에 대한 트래픽 라우팅은 자동으로 중단되도록 구성될 수 있습니다.
웹 가든. IIS 6.0 작업자 프로세스 분리 모델은 여러 개의 작업자 프로세스가 해당 어플리케이션 풀에 대한 요청을 처리하도록 구성할 수 있습니다. 기본적으로, 각 어플리케이션 풀은 하나의 작업자 프로세스를 보유하고 있습니다. 하지만, 어플리케이션 풀은 N개의 동등한 작업자 프로세스로 하여금 작업을 공유하도록 구성될 수도 있습니다. 이러한 구성을 웹 가든이라고 하는데 이는 실제로 웹 팜과 유사하기 때문이며 차이점이 있다면 웹 가든은 한대의 서버에만 존재한다는 것입니다.
요청은 HTTP.sys에 의해 그룹화되어 있는 일련의 작업자 프로세스간에 분배됩니다. 이 분배는 웹 가든에 있는 일련의 각 프로세스로부터의 “요청에 대한 요청”의 대기열과 어플리케이션 풀에 대해 수신되는 요청 대기열의 매칭을 기반으로 합니다. 웹 가든의 이점은 하나의 작업자 프로세스가 교착상태에 빠질 경우(스크립트 엔진이 불안정하게 정지된 경우), 다른 작업자 프로세스가 요청을 수용하고 처리합니다.
상태 모니터링. WWW 서비스는 작업자 프로세스가 완전히 차단되었는지 여부를 정기적으로 확인하기 위해 이를 핑(ping)해줌으로써 작업자 프로세스의 상태를 모니터링할 수 있습니다. 작업자 프로세스가 차단된 경우, WWW 서비스는 작업자 프로세스를 종료하고 이를 대신하기 위해 다른 작업자 프로세스를 생성합니다.
게다가, WWW 서비스는 각 작업자 프로세스에 대한 통신 채널을 유지하면서 통신 채널이 중단되었는지를 확인하여 언제 작업자 프로세스가 중단되었는지를 쉽게 알 수 있습니다.
프로세서 선호도. 작업자 프로세스는 빈도가 보다 높은 CPU 캐시(L1 또는 L2) 히트를 활용하기 위해 특정 CPU에 대한 선호도를 가질 수 있습니다.
어플리케이션 풀에 사이트와 어플리케이션 할당하기. IIS 5.0에서와 마찬가지로 IIS 6.0에서, 어플리케이션은 AppIsolated 속성을 가진 메타베이스에 이름 별로 분류되어 있는 이름 공간으로 정의됩니다. 기본적으로 사이트는 하나의 간단한 어플리케이션으로 간주되며 이때 루트 이름 공간”/”는 어플리케이션으로 구성됩니다.
어플리케이션 풀은 하나의 웹 어플리케이션에서 여러 어플리케이션으로, 여러 개의 사이트를 서비스하도록 구성될 수도 있습니다. 어플리케이션을 어플리케이션 풀로 할당하는 일은 어플리케이션을 메타베이스의 어떤 어플리케이션 풀로 라우팅할 것인지를 구성하는 것처럼 간단한 작업입니다.
요청 시 시작(Demand Start). 어플리케이션 풀은 다음과 같은 이점을 활용합니다. 예를 들어 이름 공간 부분이 서버에 도착하는 부분에 대해 처음으로 URL 요청을 하는 경우, 이름 공간 그룹에 서비스를 제공하는 프로세스를 요청에 의해 시작합니다. IIS 6.0 어플리케이션 관리자(WWW 서비스에 포함되어 있는)는 요청 시 프로세스를 시작 하는 구성요소이며 일반적으로 작업자 프로세스의 주기를 제어하고 모니터링합니다.
유휴상태 시간제한. 어플리케이션 풀은 구성 가능한 일정 시간 동안 유휴상태일 경우, 자신의 작업자 프로세스가 종료를 요청하도록 구성할 수 있습니다. 이는 사용되지 않는 리소스에 대해서도 마찬가지 입니다.
그 어플리케이션 풀에 대한 요청이 있을 경우엔 추가 작업자 프로세스가 개시됩니다. (추가 정보는 상기의 Demand Start 참조)
신속한 오류 보호. 작업자 프로세스가 중단될 경우, WWW 서비스와의 통신 채널도 중단됩니다. WWW 서비스는 이러한 중단 상태를 탐지하고 조치를 취하는데 일반적으로 이벤트를 로깅하고 작업자 프로세스를 다시 시작합니다. 그 외에도 IIS 6.0은 특정 어플리케이션 풀이 연속적으로 발생하는 여러 가지 오류에 시달리고 있는 경우 자동으로 비활성화되도록 구성될 수도 있으며 이것이 바로 신속한 오류 보호 기능입니다.
신속한 오류 보호는 어플리케이션 풀을 “비작동” 모드에 두고 HTTP.sys는 모든 요청에 대한 비작동 메시지인 “503–서비스를 사용할 수 없음”을 그 즉시 이름 공간의 그 부분으로 반환합니다. 여기에는 그러한 어플리케이션 풀을 위해 이미 대기중인 요청들이 포함됩니다.
관리자는 이름 공간 그룹을 명시적으로 “비작동” 모드에 둘 수도 있습니다. 가령 어플리케이션이 심각한 어플리케이션 문제로 인해 오프라인되는 경우. 이는 어플리케이션 풀을 중단시키면 되며 IIS Manager나 스크립트를 통해 실행할 수 있습니다.
작업 프로세스 종료하기. 작업자 프로세스 분리 모드는 “만료상태”로 간주되는 모든 작업자 프로세스를 종료하도록 구성될 수 있습니다. 작업자 프로세스가 일정 시간 동안의 핑에 대해 응답하기를 중단한 경우, WWW 서비스는 그러한 작업자 프로세스가 만료상태임을 표시합니다. 일반적으로 WWW 서비스는 그 작업자 프로세스를 종료하고 대체 프로세스를 개시합니다.
“종료”가 작동 상태인 경우, WWW 서비스는 “만료 상태”인 작업자 프로세스가 계속 실행되도록 둔 채로 그 자리에서 새로운 프로세스를 개시합니다. WWW 서비스가 작업자 프로세스를 orphans할 때, 이는 작업자 프로세스에서 명령을 실행할 수 있도록(디버거를 첨부할 때처럼) 구성될 수도 있습니다.
작업자 프로세스 재생. 오늘날, 많은 기업과 조직들은 메모리가 누출되고 열악한 코딩으로 시달리며 불확실한 문제들을 가지고 있는 어플리케이션으로 인해 많은 문제들을 안고 있습니다. 이로 인해 관리자들은 그들의 웹 서버를 정기적으로 재부팅하거나 다시 시작해야 합니다. IIS의 이전 버전에서는 전체 웹 서버를 중단하지 않고는 웹 사이트를 다시 시작시킬 수가 없었습니다.
작업자 프로세스 분리 모드는 오류가 많은 어플리케이션을 관리하기 위해 어플리케이션 풀에 있는 작업자 프로세스가 정기적으로 다시 시작되도록 구성될 수 있습니다. 다음과 같은 기준을 기반으로 다시 시작되도록 작업자 프로세스를 예약할 수 있습니다.
작업자 프로세스가 다시 시작될 때, WWW 서비스는 기존 작업자 프로세스가 종료될 것이라는 것을 알려주며 작업자 프로세스가 남은 요청을 처리할 수 있는 구성 가능한 제한 시간을 제공합니다. 동시에, WWW 서비스는 동일한 이름 공간 그룹을 위해 대체 작업자 프로세스를 생성하며 새로운 작업자 프로세스는 기존 작업자 프로세스가 중단되기 전에 개시됩니다. 이 프로세스로 인해 서비스가 중단되는 일이 없게 됩니다. 기존 작업자 프로세스는 처리되지 못한 요청을 완료하기 위해 HTTP.sys와의 커뮤니케이션을 유지하며 구성 가능한 제한 시간이 지난 후에도 종료되지 않을 경우에 중단되거나 강제로 종료됩니다.
IIS 6.0은 우수한 안정성, 분리성, 가용성 및 성능을 웹 서버에 제공하기 위해 작업자 프로세스 분리 모드를 도입하였습니다. 작업자 프로세스 분리 모드가 향상된 분리성, 안정성, 가용성 및 성능을 제공하지만, 일부 어플리케이션들은 다중 인스턴스, 작동 중인 세션 상태 또는 원시 데이터 필터를 읽을 수 있도록 작성된 어플리케이션 등과 같은 복잡성 문제로 인해 그러한 환경에서 작동되지 못할 수도 있습니다. 그러므로 IIS 6.0은 호환성을 위해 IIS 5.0 분리 모델이라 불리는 다른 프로세스 모델로 전환될 수도 있습니다.
IIS 5.0 분리 모드는 IIS 5.0과 매우 유사하게 작동합니다.
사용자 모드라 불리는 커널 모드 이상의 모든 모드는 IIS 5.0과 동일한 방식으로 작동됩니다. 동일한 필수 사용자 모드 프로세스가 IIS 5.0에도 존재하므로 IIS 5.0 분리 모드는 사용자가 IIS 6.0을 실행할 수 있는 가장 호환적인 방법입니다. 동일한 어플리케이션 분리 방법(상, 중, 하)이 존재하고 있으며 Inetinfo.exe는 각 요청이 여전히 통과해야 하는 마스터 프로세스입니다.
IIS 5.0 분리 모드 역시 작업자 프로세스 분리 모드와 동일한 이점을 HTTP. sys로부터 받습니다. 이러한 이점을 커널 모드 요청 대기 및 커널 모드 캐싱이라고 합니다. IIS 6.0은 웹 서비스가 HTTP.sys에 통신하는 방식을 재설계하였습니다.
참고 FTP와 SMTP처럼 Inetinfo에 들어있는 모든 다른 서비스들은 IIS 5.0에서와 마찬가지로 작동을 하며 여전히 Inetinfo에 들어있습니다. WWW 서비스만이 HTTP.sys로부터 요청을 가져오도록 변경되었습니다.
경험을 통해 우리는 발생 가능한 모든 공격을 사전에 예측하고 취약점들을 미리 해결하는 것이 불가능 하다는 것을 알았습니다. 하지만 해커들이 공통적으로 악용하는 분야에는 일정한 형식이 보였습니다. 그 결과 IIS를 보다 안전하게 만들기 위해 IIS 6.0에는 다양한 예방 수단이 구축되어 있습니다. 또한 IIS는 대폭 개선되어 보다 간편하게 사이트를 잠그고 보안 패치를 발견하여 적용할 수 있게 되었습니다.
IIS는 정적 컨텐트(.htm, .jpg, .bmp 등)만 제공되는 잠금 상태로 설치되므로 부가적인 보안이 제공됩니다.
다양한 수준의 보안
보안 수준 |
설명 |
IIS는 Windows Server 2003에 기본적으로 설치되지 않습니다. |
보안은 시스템의 공격 부위를 줄이기 위한 것이므로 IIS는 Windows Server 2003에 기본적으로 설치되지 않습니다. 관리자는 IIS를 명시적으로 선택하여 설치해야 합니다. |
IIS는 잠금 상태로 설치됩니다 |
IIS의 기본 설치는 최소한의 기능만을 공개합니다. 정적 파일들만 제공되고 다른 모든 기능들은 관리자가 명시적으로 활성화해주어야 합니다. |
업그레이드 비활성화 |
IIS는 매우 강력한 어플리케이션입니다. 우연히 설치된 IIS 서버는 Windows Server 2003 업그레이드에서 비활성화될 것입니다. |
그룹 정책을 통해 IIS를 사용할 수 없도록 합니다 |
Windows Server 2003을 이용하여 도메인 관리자들은 사용자들이 자신의 컴퓨터에 IIS를 설치하지 못하도록 할 수 있습니다. |
낮은 권한의 계정으로 실행합니다 |
IIS 작업자 프로세스는 낮은 권한의 사용자 계정에서 실행되며 이는 발생 가능한 공격으로 인한 영향을 대폭 줄여줍니다. |
안전한 ASP |
모든 ASP 내장 기능들은 항상 낮은 권한의 계정(익명 사용자)으로 실행됩니다. |
인식 가능한 파일 확장자
|
IIS는 인식 가능한 파일 확장자를 가지고 있는 파일에 대한 요청만을 제공하며 인식이 불가능한 파일 확장자에 대한 요청은 거부합니다. |
웹 사용자들은 명령줄 도구에 액세스할 수 없습니다 |
유해한 공격자들은 종종 웹 서버를 통해 실행 가능한 명령줄 도구를 이용하곤 합니다. IIS 6.0에서 명령줄 도구는 웹 서버에 의해선 실행되지 않습니다. |
컨텐트에 대한 쓰기 방지 |
침입자가 일단 서버에 액세스하게 되면 이들은 웹 사이트를 손상시키려고 합니다. 익명의 웹 사용자로 하여금 웹 컨텐트에 덮어쓰기 하지 못하도록 함으로써 이러한 공격을 예방할 수 있습니다. |
시간 제한 및 제약 |
IIS 6.0에서 기본 설정은 공격적이고 안전합니다. 이로써 기존에는 지나치게 관대했던 시간 제한 및 제약을 통해 공격을 최소화하고 있습니다. |
업로드 데이터 제한 |
관리자들은 서버에 업로드될 수 있는 데이터의 크기를 제한할 수 있습니다. |
버퍼 오버플로우 보호 |
작업자 프로세스는 버퍼 오버플로우가 발견된 경우 프로그램을 찾아서 이를 종료합니다. |
파일 확인 |
핵심 서버는 요청을 요청 처리기(ISAPI 확장 프로그램)에 보내기 전에 요청된 컨텐트가 존재하는지 여부를 확인합니다. |
여러분의 웹 서버의 공격 부위를 줄이기 위해, IIS 6.0은 기본 설치 후 정적 컨텐트만을 제공합니다. IIS APIs (ISAPI)나 Common Gateway Interfaces (CGI)가 제공하는 프로그램형 기능은 IIS 관리자가 수동으로 활성화시켜 주어야 합니다.
ISAPIs와 CGIs는 웹 페이지의 기능을 확장시키며 이러한 이유로 인해 ISAPIs와 CGIs는 이 문서에서 웹 서비스 확장 프로그램으로 언급됩니다. 예를 들어, 이 버전의 IIS를 이용하여 Active Server Pages를 실행하려면, ISAPI asp.dll이 새로운 웹 서비스 확장 프로그램으로서 활성화되어야만 합니다.
Web Service Extension 노드를 이용하여 웹 사이트 관리자들은 각 기업들의 요구를 기반으로 IIS 기능을 활성화하거나 비활성화할 수 있습니다. 그러므로 Active Server Pages나 FrontPage?? Server 확장 프로그램과 같은 부가적인 기능은 그러한 기능들을 원하는 대로 작동시키기 전에 먼저 활성화시켜주어야 합니다.
IIS 6.0은 웹 서비스 확장 프로그램을 위한 프로그래밍이 가능하고, 명령줄을 이용하는 그래픽 인터페이스를 제공합니다.
웹 서버상에서 여러 개의 어플리케이션이나 사이트를 실행하려면 웹 서버에 대한 요구 사항이 추가됩니다. ISP가 서로 경쟁관계에 있는 두 기업을 호스트하는 경우, 서버상에서 이들 두 어플리케이션들이 서로 완전히 분리되어 실행되도록 해주어야 합니다. 더욱 중요한 것은 ISP가 악의를 가진 한 어플리케이션의 관리자가 다른 어플리케이션의 데이터에 액세스할 수 없도록 하는 것입니다.
완벽한 분리가 반드시 이루어져야 합니다. IIS 6.0은 구성 가능한 작업자 프로세스를 통해 이러한 수준의 분리를 제공합니다. 대역폭과 CPU 조절(throttling)과 같은 다른 분리 기능 또는 메모리 기반의 리사이클링이 통합되어 있는 IIS 6.0은 경쟁이 심한 회사들까지도 하나의 웹 서버에서 호스트할 수 있는 환경을 제공합니다. 마찬가지로 IIS 6.0은 여러 개의 어플리케이션들이 완전히 분리된 상태로 하나의 웹 서버상에서 실행되는 환경을 제공합니다.
작업자 프로세스는 NetworkService로서 실행되는데 이는 매우 적은 권한을 가진 새로운 내장형 계정입니다. 낮은 권한의 계정으로 실행시키는 것은 매우 중요한 보안 원칙 중 하나입니다. 작업자 프로세스가 현재의 시스템에 매우 적은 권한을 가지고 있을 경우엔, 보안 취약점을 악용할 수 있는 능력을 대폭 억제할 수 있습니다.
IIS 6.0에는 세 가지 주요 SSL 개선 기능이 들어있으며 이는 다음과 같습니다.
성능. IIS 5.0은 이미 시장에서 가장 빠른 소프트웨어 기반 SSL 개선 기능을 제공하고 있습니다. 그 결과 모든 SSL 웹 사이트의 50%는 IIS에서 실행되고 있습니다. IIS 6.0은 이보다 훨씬 빠를 것입니다. Microsoft는 보다 우수한 성능과 확장성을 위해 현재의 SSL 개선 기능을 조정하고 간소화하였습니다.
원격형 인증 개체. IIS 5.0에서 관리자들은 암호화 서비스 공급자(CAPI) 인증서 저장소가 원격형이 아니므로 SSL 인증서를 원격으로 관리할 수 없었습니다. 고객들은 수백, 수천 대에 이르는 IIS 서버를 SSL 인증서를 이용하여 관리하므로 인증서를 원격으로 관리할 수 있는 방법을 필요로 하는데 바로 CertObject로 인해 고객들은 그러한 작업을 할 수 있습니다.
선택형 암호화 서비스 공급자. SSL이 활성화되면 CPU가 수 많은 집약적 암호 분석을 수행해야 하므로 성능이 대폭 떨어집니다. 하드웨어 기반의 가속기(accelerator) 카드는 이러한 암호 계산을 하드웨어에 오프로드할 수 있습니다. 이는 자신의 Crypto API- (CAPI) 공급자를 시스템에 연결합니다. IIS 6.0은 그러한 써드 파티 공급자를 손쉽게 선택할 수 있도록 해줍니다.
인증
인증 기능이 “당신은 누구십니까?”라는 질문에 대답한 후 “당신은 어떤 작업을 할 수 있습니까?”라는 질문에 대답하는 경우, 이 인증은 사용자가 특정 작업을 하는 것을 허용 또는 거부하게 됩니다. Windows Server 2003은 IIS 6.0을 위한 인증 지원 방식으로 Passport를 통합시키고 있습니다. IIS 6.0은 Windows Server 2003 제품군에서 제공하는 새로운 인증 프레임워크 사용을 확대하였습니다. 또한 웹 어플리케이션은 액세스 제어를 위해 인증 관리자(Authorization Manager)와 함께 URL 인증을 사용합니다. Windows Server 2003에는 강제적이고 위임된 인증이 추가되어 도메인 관리자들에게 특정 시스템이나 서비스에만 위임을 허용하는 제어권을 제공합니다.
Windows Server 2003은 IIS 6.0을 위한 인증 지원 방식으로 Passport를 통합하였습니다. 이 통합으로 인해 핵심 웹 서버에 Passport 인증을 제공하고 표준 Passport 구성요소가 제공하는 Passport 버전 2 인터페이스를 사용하게 됩니다. 관리자는 암호 만료 또는 제공과 같은 계정 관리 문제를 처리하지 않고도 Passport 고객 기반(150,000,000 이상)을 활용할 수 있습니다.
Passport 인증이 확인되면, Windows Server 2003 Passport 사용자는 그들의 Windows Server 2003 Passport ID를 통해 Active Directory?? 사용자로 매핑될 수 있습니다(그러한 매핑이 존재할 경우). 사용자를 위해 Local Security Authority (LSA)는 토큰을 생성하고 HTTP 요청을 위해 IIS가 이를 설정합니다.
어플리케이션 개발자들과 웹 사이트 관리자들은 Active Directory 사용자를 기반으로 하는 인증을 위해 이 보안 모델을 사용할 수 있습니다. 이러한 자격 증명은 Windows Server 2003에서 지원하는 새로운 Constrained Delegation 기능을 이용하여 위임할 수 있습니다.
오늘날, ACLs는 인증 결정을 하기 위해 사용되고 있습니다. 문제는 ACL 모델이 상당히 개체(파일, 디렉터리) 기반이며 리소스 관리자(NTFS 파일 시스템)의 요구사항을 충족시키려고 한다는 점입니다. 하지만 오늘날 사용되는 대부분의 웹 어플리케이션들은 비즈니스 어플리케이션이며 개체 위주가 아닌 작업 기반입니다.
어플리케이션이 작업 기반의 액세스 제어 모델을 제공하고자 하는 경우, 독자적인 모델을 만들어야 합니다. Windows Server 2003의 새로운 인증 프레임워크를 통해 Microsoft는 이러한 비즈니스 어플리케이션의 요구를 충족시켜줄 수 있는 방법을 제공합니다.
IIS 6.0은 특정 URL에 게이트키퍼(gatekeeper) 인증을 제공함으로써 Windows Server 2003 제품군과 함께 제공되는 새로운 인증 프레임워크의 사용을 확대합니다. 또한 웹 어플리케이션은 동일한 정책 저장소로부터 웹 어플리케이션을 손상시키고 있는 URL에 대한 액세스를 제어하고 어플리케이션 전용 작업들을 관리하기 위해 인증 관리자(Authorization Manager)와 함께 URL 인증을 사용할 수 있습니다.
동일한 정책 저장소에 정책을 보관함으로써 관리자들은 URL에 대한 액세스와 단일 관리 지점에서의 어플리케이션 기능을 관리할 수 있으며 동시에 저장소 수준 어플리케이션 그룹과 사용자가 프로그래밍할 수 있는 비즈니스 규칙을 활용할 수 있습니다.
위임은 서버 어플리케이션으로 하여금 네트워크상의 사용자처럼 작동하도록 하는 작업입니다. 이에 대한 예로는 기업의 여러 서버에서 클라이언트 자격으로 정보에 액세스한 다음 통합된 데이터를 HTTP를 통해 최종 사용자에게 제공하는 기업 인트라넷 상의 웹 서비스 어플리케이션을 들 수 있습니다.
Windows Server 2003에는 강제적인 위임 기능이 추가되어 도메인 관리자들에게 특정 컴퓨터나 서비스에 대해서만 위임을 허용하는 제어권을 제공합니다. 다음은 위임 권장 사항입니다.
· 위임은 서버가 클라이언트를 대신하여 도메인이나 포리스트에 있는 모든 리소스에 연결되도록 해서는 안됩니다. 특정 서비스(예, 백엔드 SQL 데이터베이스나 원격 파일 저장소)에 대한 연결만 허용해야 합니다. 그렇지 않으면 악의를 가진 서버 관리자나 어플리케이션이 클라이언트를 가장하고 클라이언트를 대신하여 모든 리소스에 대한 인증을 할 수 있습니다.
· 위임은 클라이언트가 자신의 자격 증명을 서버와 공유하도록 요구해선 안됩니다. 악의를 가진 서버 관리자나 어플리케이션이 여러분의 자격 증명을 가지고 있다면 이를 원하는 백엔드 데이터 저장소에서 뿐 아니라 전체 도메인에서 이용할 수 있게 됩니다.
강제적이고 위임된 인증은 Remote Procedure Call (RPC)과 Distributed Component Object Model (DCOM)과 같은 고성능 프로토콜을 활용할 수 있는 기회가 많기 때문에 Windows 환경에 적합한 어플리케이션을 설계할 때 매우 권장되는 방법입니다. 이들 프로토콜들은 서버간에 사용자 컨텍스트를 투명하게 전달하고 사용자 컨텍스트를 가장하며, 사용자 컨텍스트가 개체에 대해 인증 규칙에 의거한 사용자로서 인증받도록 하는데 사용되며 도메인 그룹 정보, 로컬 그룹 정보 및 서버에 들어있는 리소스에 대한 DACL(Discretionary Access Control Lists)에 의해 정의됩니다.
일반적인 인터넷 웹 사이트는 더 이상 한 대의 서버에서만 운영되지 않습니다. 웹 사이트는 이제 여러 대의 웹 서버나 웹 팜에 고루 분산되어 있습니다(웹 팜은 컨텐트, 비즈니스 로직 및 서비스 제공을 전담하는 서버 클러스터입니다). 기업과 조직들이 웹을 통해 보다 많은 어플리케이션을 제공함에 따라 웹 사용이 가능한 비즈니스 계열 어플리케이션을 제공하는 인트라넷 사이트도 그 수가 증가해왔습니다.
또한, 원격 관리가 일반화되면서 향상된 API 액세스에 대한 요구와 직접 구성 지원 기능을 향상시켜 달라는 요구가 늘어나고 있습니다. 지난 몇 해 동안의 인터넷 및 인트라넷 변화로 인해 웹 사이트를 관리하는 일이 사무실에서 한대 또는 몇 대의 웹 서버를 관리하는 것 만큼 간단한 일이 아니라 통합된 복잡한 프로세스가 되었습니다.
IIS 6.0은 IIS 웹 사이트를 관리하는 관리자들을 위해 관리 기능을 개선시켜주는 새로운 기능들을 소개하고 있습니다. IIS 6.0에는 메타베이스의 스토리지 계층 대체 기능(구성 저장소)이 들어있으며 이는 강력하고 복구 가능한 방식으로 메타베이스 구성을 직접 텍스트로 편집할 수 있도록 합니다. 게다가, Windows Management Instrumentation (WMI) 지원 기능과 향상된 명령줄 지원 기능으로 인해 IIS Manager를 사용하지 않고도 웹 사이트를 관리할 수 있습니다.
메타베이스는 상속, 데이터 입력, 알림 수정 및 보안과 같은 다양한 기능들이 통합된 IIS에서 사용되는 구성 값의 계층적 저장소입니다. IIS 4.0과 IIS 5.0에 대한 메타베이스 구성은 독점적인 바이너리 파일에 저장되어 있으며 읽기나 편집이 쉽지 않습니다. IIS 6.0은 MetaBase.bin이라 불리는 독점적인 바이너리 파일을 일반 텍스트 XML 형식 파일로 대체하였습니다.
XML 형식의 일반 텍스트 메타베이스 파일의 이점은 다음과 같습니다.
새로운 XML 메타베이스는 웹 서버를 관리하기 위해 스크립트나 코드를 사용하지 않고도 관리자가 직접 구성을 읽고 편집할 수 있도록 합니다. XML 메타베이스는 다음과 같은 작업을 매우 용이하게 해줍니다.
기존 바이너리 메타베이스는 아무런 문제 없이 새로운 XML 메타베이스로 업그레이드됩니다.
새로운 XML 메타베이스는 성능 및 확장성을 대폭 향상시켰습니다. 새로운 XML 메타베이스는 다음과 같습니다.
새로운 XML 메타베이스는 다음과 같은 시나리오를 가능케 함으로써 관리 문제를 해결하였습니다.
관리자와 어플리케이션 개발자들은 블랙 박스 같은 기록 장치를 가지고 있지 않으며 액세스가 가능하고 신속한 구성 저장소가 필요하다고 오랫동안 언급해왔습니다. 새로운 XML 메타베이스는 다음에 소개된 기능들을 통해 성능과 관리 문제를 해결함으로써 이러한 요구를 만족시켜주고 있습니다.
ADSI 스키마와 스키마 확장성은 지속적으로 지원될 것입니다. 사람이 읽고 편집할 수 있는 스키마는 ADSI를 지원하며 텍스트 형식에 대한 사용자의 읽기 능력과 편집 능력을 강화하였습니다. 새로운 IIS 6.0 구성이 메타베이스에 추가되고 ADSI에 도입되어, 기존 스크립트나 도구들을 통해서도 새로운 기능을 활용할 수 있습니다.
자동 버저닝과 기록. 메타베이스 기록 기능은 디스크에 기록되어 있는 메타베이스에 대한 변경 사항을 자동으로 추적합니다. 메타베이스가 디스크에 기록될 때 IIS는 새로운 MetaBase.xml 파일에 버전 번호를 표시하고 기록 폴더에 파일의 사본을 저장합니다. 각 기록 파일에는 고유한 버전 번호가 표시되며 이는 메타베이스 롤백이나 복원 프로세스에 사용됩니다. 메타베이스 기록 기능은 기본적으로 활성화되어 있습니다.
실행 중 편집. IIS 6.0은 관리자가 IIS를 실행하면서 MetaBase.xml 파일을 편집할 수 있도록 합니다. 가령, 새로운 구성 선택 사항들은 노트패드에서 MetaBase.xml을 열어서 간편하게 추가할 수도 있고 새로운 사이트나 가상 디렉터리를 위한 새로운 구성에 입력하거나 기존 구성을 편집하여 추가할 수도 있습니다.
구성 가져오기와 내보내기 IIS 6.0은 두 가지의 새로운 Admin Base Object (ABO) 방식을 소개하고 있습니다.
이러한 방식들은 모든 노드 수준의 구성이 서버들 간에 내보내지고 가져오기 할 수 있도록 합니다. 안전한 데이터는 새로운 백업/복원 지원 기능과 유사한 사용자 제공 암호를 통해 보호됩니다. 이러한 새로운 방식들은 ADSI와 WMI 사용자 및 IIS Manager를 통해서도 사용이 가능합니다.
내보내기() 및 가져오기()를 이용하여 관리자들은 다음과 같은 작업을 수행할 수 있습니다.
서버 독립적 백업. IIS 6.0에서는 암호를 이용하여 메타베이스를 백업하고 복원할 수 있도록 개발자들에게 새로운 Admin Base Object (ABO) API를 제공합니다. 이로써 관리자들과 개발자들은 서버 독립적 백업을 만들 수 있습니다.
세션 키는 백업 시 선택적으로 사용자가 제공하는 암호를 이용하여 암호화되며 이는 시스템 키를 기반으로 하지 않습니다. 메타베이스를 백업할 때 시스템은 사용자가 제공한 암호로 세션 키를 암호화합니다. 복원 시, 제공된 암호는 세션 키를 암호 해제하며 세션 키는 현재의 시스템 키를 이용하여 다시 암호화됩니다.
이 새로운 복원 방식은 기존 백업 방식으로 만들어진 백업도 복원할 수 있으며 세션 키가 암호 해제되지 못할 때엔 기존 복원 방식이 사용하던 것과 동일한 작업을 수행합니다. WMI와 ADSI는 이러한 방식을 지원합니다. 기존 메타베이스 백업/복원 사용자 인터페이스 역시 새로운 백업/복원 방식을 사용합니다.
Windows 2000은 서버를 구성하는 새로운 수단을 소개하였으며 성능 카운터와 시스템 구성(Windows Management Instrumentation (WMI))과 같은 중요한 데이터에 액세스할 수 있었습니다. 쿼리 지원과 개체간의 결합과 같은 WMI 기능들을 활용하기 위해, IIS 6.0는 여러분의 웹 서버를 보다 강력하고 유연한 방식으로 관리할 수 있도록 해주는 다양한 프로그래밍 인터페이스를 제공하는 WMI 공급자를 보유하고 있습니다. IIS WMI 공급자는 메타베이스 편집을 위해 IIS ADSI 공급자와 유사한 기능을 제공합니다.
IIS WMI 공급자의 목적은 IIS ADSI 공급자와 동등한 수준으로 관리성을 제공하고 확장 가능한 스키마를 지원하는 것입니다. 특히 이는 IIS 메타베이스 스키마와 동일한 WMI 스키마를 필요로 합니다. 이들은 ADSI와 WMI에 대한 각 개체와 데이터 모델 별로 다를 수도 있지만 이 둘은 동일한 기능을 제공합니다. 즉, ADSI 모델을 이용하는 작업을 위해 작성된 스크립트는 WMI 모델을 위해서도 작성될 수 있습니다. 메타베이스에 미치는 영향도 동일합니다. 마찬가지로 ADSI을 통해 이루어진 모든 스키마 확장은 자동으로 WMI 공급자에 반영됩니다. ADSI의 스키마에 변경사항이 생긴 경우, 이 변경 사항은 IIS WMI 공급자에게도 강요됩니다.
IIS 6.0은 이제 IIS 6.0 웹 서버를 관리하는데 사용되는 Windows\System32 directory에서 지원되는 스크립트를 장착하였습니다. Visual Basic?? 스크립팅 언어로 작성된 이 스크립트는 IIS WMI 공급자를 이용하여 메타베이스 내에 구성을 설정합니다. 이러한 스크립트들은 사용자 인터페이스를 사용할 필요 없이 웹 관리자들이 명령줄에서 접하게 되는 가장 일반적인 작업들을 수행하도록 설계되었습니다.
IIS 6.0에는 다음과 같은 작업을 위해 지원되는 명령줄 관리 스크립트가 장착되어 있습니다.
Remote Administration (HTML) 도구를 이용하여 관리자들은 웹 브라우저를 통해 인터넷이나 인트라넷에서 원격으로 IIS를 관리할 수 있습니다.
차세대 어플리케이션들은 웹 서버의 성능 및 확장성 속성에 대한 요구가 매우 높습니다. HTTP 요청이 처리되는 속도를 향상시키고 보다 많은 어플리케이션과 사이트들이 한 대의 서버에서 실행될 수 있도록 함으로써 사이트를 호스트하는데 필요한 서버의 수를 절감하게 됩니다. 이는 보다 많은 용량을 처리하면서 기존 하드웨어에 대한 투자를 장기간 유지할 수 있다는 것을 의미하기도 합니다.
참고 사전 테스트에서는 특정 작업로드 하에서 8개의 프로세서를 가진 서버가 처리량에 있어서 100% 이상의 성능을 나타낸다고 밝혔습니다.
Windows Server 2003은 HTTP 파싱과 캐싱을 위해 새로운 커널 모드 드라이버인 HTTP.sys를 소개하고 있습니다. HTTP는 웹 서버 처리량이 증가하도록 특별히 조정되었고 요청된 컨텐트가 커널에서 바로 처리할 수 있는 것으로 분류된 경우 프로세서가 사용자 모드로 전환되지 않도록 설계되었습니다. 이는 IIS 6.0이 HTTP.sys 위에 구축되었기 때문에 IIS 사용자에게 있어 매우 중요합니다. 사용자 모드 구성요소가 요청 프로세싱에 참여해야 하는 경우, HTTP.sys는 라우팅 결정에 다른 사용자 모드 프로세스가 참여하지 않고도 해당 사용자 모드 작업자 프로세스에 그 요청을 라우트합니다.
IIS 6.0은 프로세싱 환경을 보다 잘 인식하고 있습니다. IIS 커널과 사용자 모드 구성요소는 프로세서 위치를 인식하도록 제작되었으며 프로세서 별 내부 데이터 장소를 유지하기 위해 최선을 다합니다. 그리고 멀티프로세서 시스템상의 서버 확장성을 향상시켜줍니다. 또한 관리자는 특정 어플리케이션/서버와 특정 프로세서 하위시스템의 작업로드간에 선호도를 구축할 수 있습니다. 이는 아래의 그림 1에서처럼 어플리케이션이 하나의 운영 체제 이미지에 가상 어플리케이션 프로세싱 저장소(silos)를 설치할 수 있다는 것을 의미합니다.
그림1. IIS 6.0의 가상 요청 프로세싱 저장소(silos)
새로운 커널 모드 드라이버인 HTTP.sys는 모든 수신(서버 측) HTTP 요청에 대한 단일 접속 지점입니다. 이는 HTTP 서버 어플리케이션을 위한 고성능 연결성을 제공합니다. 드라이버는 최 상위 TCP/IP에 위치해 있으며 수신하도록 구성된 IP/포트 조합으로부터 모든 연결 요청을 수신합니다. HTTP.sys는 전반적인 연결 관리, 대역폭 조절 및 웹 서버 로깅을 담당합니다.
참고 IIS 5.0과 비교해볼 때 정적 컨텐트의 처리량에 있어서200% 향상된 성능을 나타내며 캐시된 응답은 165% 높은 처리량을 나타내었다고 사전 테스트에서 입증되었습니다.
IIS 6.0에는 캐시 가능한 일련의 어플리케이션과 사이트를 결정하기 위해 고급 추론 기능이 장착되어 있습니다. 항목이 캐시 가능하다는 이유로 그 항목을 인 메모리 캐시에 추가한다는 것은 말이 안되는데 이는 그 항목을 관리하고 항목이 소비하는 메모리에 비용이 들기 때문입니다. 그러므로 IIS 6.0은 특정 어플리케이션이 수신하는 요청의 분배를 기반으로 어떤 항목이 캐시되어야 하는지를 결정하기 위하여 새로운 추론 기능을 사용합니다. 이는 잦은 요청에 대한 성능을 유지시키면서 서버에서 리소스를 보다 잘 활용할 수 있게 해주므로 웹 서버의 확장성이 향상된다는 것을 의미합니다.
IIS 6.0은 서버의 전반적인 상태를 모니터링하기 위해 추론 기능을 장착하였으며 이러한 기반에서 동시성을 증가시키거나 절감시킬 지를 결정합니다. 여기서 중심이 되는 아이디어는 동시성을 사용하면 효율적이라는 것입니다. 예를 들어, 프로세서 기반 요청을 실행할 때엔 동시 작업을 시작하는 것이 반드시 최선의 방법은 아니라는 것입니다.
웹 가든은 어플리케이션 풀로서 그 풀에 라우트되어 있는 요청을 처리하는 여러 개의 프로세스들입니다. 여러분은 웹 가든에 있는 작업자 프로세스들이 멀티프로세서 시스템상의 해당 CPU에 연결되도록 구성할 수 있습니다.
웹 가든을 이용하여 웹 어플리케이션은 확장성을 향상시키는데 이는 한 프로세스의 소프트웨어 lock이 어플리케이션에 들어오는 모든 요청을 차단하지 못하기 때문입니다. 웹 가든에 4개의 프로세스가 있는 경우 특정 소프트웨어 lock은 요청의 4분의 1을 차단합니다.
Active Server Pages (ASP) 코드가 IIS 5.0에서 실행되기 전에, ASP 엔진은 ASP 파일을 ASP 템플릿으로 컴파일합니다. 이러한 ASP 템플릿들은 프로세스 메모리에 저장됩니다. 사이트가 수 많은 ASP 페이지로 이루어져 있는 경우, 이 캐시는 새로운 템플릿을 위한 여유 공간을 만들기 위해 오래된 템플릿부터 할당 해제를 합니다.
IIS 6.0으로 인해 이러한 템플릿들은 디스크에 지속적으로 남아있습니다. 이러한 ASP 파일들 중 하나가 다시 요청될 경우, ASP 엔진은 ASP 파일을 로드하고 이를 다시 컴파일하기 위해 부가적인 CPU 시간을 소비하지 않고 템플릿을 로드합니다.
참고 사전 테스트에서는 지속적인 온 디스크 캐싱으로 인해 처리량에 있어서 50% 이상의 성능이 향상되었다고 밝히고 있습니다.
엄청난 양의 캐시 데이터를 요구하는 작업 로드에 있어서, IIS 6.0은 x86 시스템을 위해 최대 64기가바이트까지 캐시되도록 구성할 수 있습니다.
IIS 6.0은 내부 리소스가 사용되는 방식을 개선하였습니다. IIS 6.0 방식은 초기화 때 리소스를 미리 할당하지 않고 HTTP 요청이 특정 시스템 리소스를 요청하기 때문에 오히려 할당 리소스의 하나가 되는데 이는 다음과 같은 기능들이 개선되었기 때문입니다.
사전 테스트에서는 IIS 5.0과 비교했을 때 IIS 6.0에서 훨씬 많은 수의 풀링된 어플리케이션들이 실행된다고 밝히고 있습니다. IIS 6.0은 수 천 개의 분리된 어플리케이션을 구성할 수 있으며 이들 각 어플리케이션들은 고유한 보안 ID로 실행됩니다. 동시에 분리되는 어플리케이션의 수는 시스템 리소스의 기능입니다. IIS 6.0은 어플리케이션이 공유 어플리케이션 풀에서 실행되도록 구성될 때, 서버 별로 수만 개의 어플리케이션을 손쉽게 구성할 수 있습니다.
참고 20,000개 사이트의 시동 시간을 테스트한 결과 두 개의 프로세서를 갖춘 서버에서 보다 2분 적게 걸렸습니다.
새로운 IIS 6.0 아키텍처의 부가적인 확장성 개선 기능은 IIS가 작업자 프로세스를 실행시키지 않고도 수 많은 사이트로부터의 요청을 수신할 수 있다는 것입니다(상기의 요청 프로세싱 아키텍처 참조).
이 “요청 시 시작”기능과 작업자 프로세스를 중단시키는 기능을 결합한다는 것은 많은 사이트를 호스팅하고 있는 웹 서버가 훨씬 확장될 수 있다는 것을 의미하는데 IIS 6.0이 활발히 작동중인 사이트에서 자신의 리소스가 사용되는 것을 조정하기 때문입니다. IIS 6.0은 활동성이 없는 사이트를 위해서도 동적으로 커널 캐시된 항목을 트림합니다.
IIS 6.0은 여러 가지 새로운 프로그램 기능을 제공하며 지속적으로 ISAPI 프로그래밍 모델에 구축되고 있습니다. 이러한 새로운 기능들은 다음과 같습니다.
· ASP.NET과 IIS 통합
· 내부 리디렉션 (ExecuteURL과 글로벌 인터셉터)
· 버퍼와 핸들 보내기(VecorSend)
· 동적 컨텐트 캐싱
· Custom Error 를 위한 ISAPI 지원
· 작업자 프로세스 리사이클링
· 향상된 ISAPI Unicode 지원
· ASP의 COM+ 서비스
Windows Server 2003은 ASP.NET과 IIS 통합으로 개발자들이 향상된 경험을 할 수 있도록 합니다. IIS 6.0에 구축된 플랫폼 개선 기능들은 개발자들에게 매우 높은 수준의 기능성을 제공합니다. 가령, 신속한 어플리케이션 개발과 다양한 언어 선택과 같은 기능이 있습니다.
Windows Server 2003에서는 IIS 6.0의 향상된 프로세스 모델 통합으로 인해 ASP.NET과 .NET 프레임워크의 사용 환경이 향상되었습니다.
IIS 6.0은 XML, SOAP 및 IPv6과 같은 최신 웹 표준을 지원합니다.
HSE_REQ_EXEC_URL ServerSupportFunction은 이제 ISAPI 확장 프로그램이 요청을 다른 URL로 간편하게 리디렉트할 수 있도록 합니다. 이는 ISAPI 확장 프로그램 개발자들이 요청을 서로 연결시킬 수 있도록 하여 증가하는 그들의 요구에 대응하고 있습니다.
ExecuteURL은 거의 모든 read raw data 필터를 대체할 수 있는 기능을 제공합니다.
read raw data 필터 개발을 위한 가장 일반적인 고객 시나리오는 대상 URL이 요청을 처리하기 전에 요청의 엔터티 본문을 검사 또는 변경하려고 하는 것입니다. (자신이 대상 URL이 아닌 경우)요청의 엔터티 본문을 볼 수 있는 유일한 방법은 read raw data 알림을 이용하는 것입니다. 공교롭게도 이를 위해 ISAPI 필터를 작성하기란 매우 어려우며 일부 구성에서는 불가능할 수도 있습니다.
한편 ISAPI 확장 프로그램은 엔터티 본문을 간편하게 검색하고 조작하는 기능을 제공합니다. ExecuteURL은 ISAPI 확장 프로그램이 요청 엔터티 본문을 처리하고 이를 자식 요청에 전달하여 거의 모든 read raw data 필터 개발자들의 요구를 충족시켜주고 있습니다.
ExecuteURL은 IIS 6.0으로 하여금 특정 URL 영역에 대해 수신되는 모든 HTTP요청을 차단, 변경, 리디렉트 또는 거부할 수 있는 ISAPI 요청 인터셉터를 구현할 수 있도록 합니다.
· IIS 5.0는 어플리케이션에 대한 어플리케이션 매핑을 편집하여 구성된 단일 와일드카드(*) 스크립트맵을 이용하여 모든 요청을 차단하는 하나의 ISAPI 확장 프로그램을 이미 지원하고 있습니다.
· IIS 6.0에서 단일 와일드카드(*) 스크립트맵 개념은 여러 개의 글로벌 인터셉터가 실행되도록 확장되었습니다.
특정 URL에 대한 모든 요청을 수용하는 것은 ISAPI 필터에서만 가능한 기능이었습니다. ISAPI필터는 다음과 같은 문제점이 있습니다.
글로벌 인터셉터는 ISAPI 확장 프로그램이므로, ISAPI 필터의 제한이 없으며 ExecuteURL와 함께 기능성을 제공하여 거의 모든 read raw data 필터를 대체합니다.
오늘날 ISAPI 개발자들은 응답을 구성하는 여러 개의 버퍼를 보유하고 있는 경우 두 가지 가능성을 가집니다. 이들은 WriteClient를 여러 번 호출하거나 하나의 대형 버퍼에 응답을 모을 수 있습니다.
· 첫 번째 방법은 버퍼당 하나의 커널 모드가 전환되므로 성능 병목현상이 발생합니다.
· 두 번째 방법 역시 성능을 소모하지만 추가 메모리가 필요합니다. VectorSend는 이 문제에 대한 IIS 6.0 솔루션입니다.
ISAPIs를 위한 서버 지원 기능으로 구현된 VectorSend는 개발자들이 전송할 버퍼 목록과 파일 핸들을 함께 보관하고 마지막 응답을 컴파일하기 위해 IIS 6.0에 전달합니다. HTTP.sys는 모든 버퍼와 파일 핸들을 커널 내 하나의 응답 버퍼로 컴파일한 다음 이를 전송합니다.
또 다른 새로운 기능은 동적 컨텐트를 위한 커널 모드 캐시를 구현하는 것입니다. 이 기능의 이점은 많은 고객들이 변경되지 않는 컨텐트를 프로그램적으로 만들 수 있다는 것입니다.
이전 버전의 IIS에서는 요청이 커널 모드에서 모든 동적 요청을 위한 사용자 모드로 전환되어야 하며 응답도 다시 생성되어야 합니다. 이러한 전환이 일어나지 않도록 하고 커널 모드 캐시에서 캐시된 컨텐트를 가져오도록 하여 성능을 대폭 향상시킵니다.
HSE_REQ_REPORT_UNHEALTHY라 불리는 새로운 ISAPI 확장 프로그램 ServerSupportFunction은 ISAPI 확장 프로그램이 IIS 6.0 작업자 프로세스로 하여금 작업자 프로세스를 리사이클시키는 요청을 하도록 합니다. 개발자들은 자신의 어플리케이션 ISAPI가 불안정해지거나 어떤 이유에서 불확실한 상태가 될 경우, 이러한 새로운 서버 지원 기능을 이용하여 리사이클을 요청할 수 있습니다.
참고 ISAPI가 HSE_REQ_REPORT_UNHEALTHY를 호출한 다음 리사이클링되도록 하려면 상태 모니터링이 작동되어야 합니다.
HSE_REQ_REPORT_UNHEALTHY을 호출할 때, 개발자는 ISAPI가 HSE_REQ_REPORT_UNHEALTHY를 호출하는 이유를 나타내는 문자열을 전송할 수도 있습니다. 그런 다음 이 문자열은 작업자 프로세스가 어플리케이션 이벤트 로그에 게시하는 이벤트에 추가됩니다.
ISAPI 개발자들은 더 이상 독자적인 오류 메시지를 생성할 필요가 없습니다. 대신에 HSE_REQ_SEND_CUSTOM_ERROR라 불리는 새로운 ServerSupportFunction을 통해 IIS에 구축된 Custom Error 지원 기능에 접속할 수 있습니다.
Unicode는 전 세계 경제에 있어서 점점 더 중요해지고 있습니다. HTTP 프로토콜의 비 Unicode 구조로 인하여, IIS 5.0은 시스템 코드페이지에 대한 개발자의 사용을 제한합니다. UTF-8 인코드 URL로 인해 Unicode를 사용할 수 있게 되었습니다.
IIS 6.0는 고객들이 Unicode로 된 서버 변수를 받을 수 있도록 하며 개발자들이 URL을 Unicode로 나타낼 수 있도록 하기 위해 두 개의 새로운 ServerSupportFunctions을 추가합니다. 여러 가지 언어로 된 사이트를 가지고 있는 국제적인 고객들은 이 기능과 향상된 개발 경험을 활용할 수 있습니다.
IIS 4.0과 5.0에서, ASP 어플리케이션들은 일련의 서비스를 이용하기 위해 COM+ 구성 저장소에 어플리케이션의 WAM 개체를 구성함으로써 COM+ 서비스를 이용할 수 있습니다. 이는 COM+ 서비스가 COM 구성요소와 함께 사용되도록 개발되었기 때문입니다.
IIS 6.0에서 IIS와 COM+ 팀은 구성요소에서 COM+ 서비스를 분리시키고 ASP 어플리케이션이 일련의 COM+ 서비스를 사용하도록 합니다. Windows 2000의 COM+에서 제공되는 이러한 서비스들 외에도, 몇 가지 새로운 서비스들이 추가되었으며 이들은 ASP에서도 지원됩니다.
퓨전은 ASP 어플리케이션이 특정 버전의 시스템 런타임 DLL이나 기존 COM 구성요소를 사용하도록 합니다. 퓨전은 어플리케이션 개발자가 그들의 어플리케이션과 호환되는 시스템 런타임 라이브러리와 기존 COM 구성 요소들의 정확한 버전을 지정하도록 합니다. 그러므로 어플리케이션이 로드되고 실행될 때, 런타임 라이브러리와 COM 구성요소의 이러한 버전들을 항상 수신하게 됩니다.
기존 어플리케이션들은 시스템에 설치되어 있는 시스템 런타임 DLL 버전이 무엇이건 간에 무조건 사용해야만 했었습니다. 그래서 새로운 버전이 설치되고 기능이 다소 변경되는 경우 문제를 야기시킬 수도 있었습니다.
COM+ 파티션은 관리자로 하여금 각기 다른 사용자에 대해 단일 COM+ 어플리케이션의 구성을 다르게 정의하도록 합니다. 이 구성에는 보안 및 버전 정보가 포함됩니다. COM+ 파티션에 관한 추가 정보는 COM+문서를 참조하십시오.
COM+ 추적기가 활성화된 경우 관리자는 어떤 코드가 ASP세션에서 실행되고 있는 지와 언제 실행되는지를 모니터링할 수 있습니다. 이 정보는 ASP 어플리케이션을 디버그하는 데 매우 유용합니다. COM+ 추적기에 관한 추가 정보는 COM+ 문서를 참조하십시오.
COM+을 이용하는 ASP는 어플리케이션에서 페이지를 실행할 때 개발자들이 사용할 스레딩 모델을 결정할 수 있도록 합니다. 기본적으로 ASP는 Single Threaded Apartment를 사용합니다. 하지만 어플리케이션이 풀링 가능한 개체를 사용하는 경우엔 멀티 스레드 아파트(Multi-Threaded Apartment)에서도 실행됩니다.
앞서 언급한 기능들 외에도 IIS 6.0은 플랫폼의 기능을 전반적으로 다양하게 개선하였으며 이러한 기능들이 IIS를 보다 경쟁력 있는 웹 어플리케이션 플랫폼으로 만들어주고 있습니다.
전체 Windows Server 2003 제품군 코드 기반은 32 비트와 64 비트 플랫폼용으로 컴파일되었습니다. 확장성 높은 어플리케이션을 요구하는 고객들은 이 두 플랫폼에서 지원되고 실행되는 운영체제를 활용할 수 있습니다.
Internet Protocol version 6.0 (IPv6.0)은 인터넷을 위한 차세대 IP 프로토콜입니다. Windows Server 2003 제품군은 이제 생산 준비를 마친 IPv6.0 스택에 구현되어 있습니다. IPv6.0 프로토콜 스택이 설치된 서버에서 IIS 6.0은 IPv6.0를 통해 도달한 HTTP 요청을 자동으로 처리합니다.
혼잡한 네트워크상에서는 압축 응답이 매우 유용합니다. IIS 5.0에서 압축은 ISAPI 필터였으며 전체 서버에 대해서만 사용이 가능했었습니다. IIS 6.0에서는 훨씬 세밀한 구성(파일 수준)을 할 수 있습니다.
Quality-of-Service (QoS)는 웹 서버의 특정 구성요소 또는 그 서버가 제공하는 특정 컨텐트가 모든 서버의 리소스(메모리나 CUP 주기와 같은)를 가져오지 못하도록 합니다. 이로써 관리자는 특정 사이트나 어플리케이션 풀, 전체 WWW 서비스 등에서 사용되는 리소스를 제어할 수 있습니다.
기본적으로 QoS는 시스템상의 다른 서비스/사이트/어플리케이션들이 수신하는 수준의 서비스 품질을 보장해줍니다. 이는 특정 웹 사이트나 어플리케이션 또는 WWW 서비스가 사용하는 리소스를 제한해줌으로써 가능합니다.
IIS 6.0에서 QoS는 다음과 같은 기능들의 형식을 취합니다.
IIS 6.0의 로깅 개선 기능은 다음과 같습니다:
추가된 Unicode와 UTF-8 지원 기능으로, IIS 6.0은 이제 ASCII(또는 로컬 코드페이지) 대신에 UTF-8로 로그 파일을 작성하는 기능도 지원합니다. WWW 서비스 수준에서 구성이 가능한 이 설정은 HTTP.sys에게 로컬 코드페이지나 UTF-8로 로그 파일을 작성하는 방법을 알려줍니다.
바이너리 로깅은 여러 사이트들이 특별한 형식 없이 바이너리로 단일 로그 파일을 작성할 수 있도록 합니다. 데이터를 특정 방식으로 포맷할 필요가 없으므로 이 새로운 로깅 형식은 현재의 텍스트 기반[World Wide Web Consortium (W3C), IIS 및 National Center for Supercomputing Applications (NCSA)] 로깅 형식보다 우수한 성능을 제공할 것입니다.
또한, 수 만개의 사이트에 로그해야 하는 로그 파일 버퍼의 수가 대폭 줄어들기 때문에 바이너리 로깅은 확장성에 있어서 이점을 제공합니다. 도구들은 로그 항목을 발췌하기 위해 로그 파일을 후 처리하는데 사용됩니다.
로그 항목과 파일의 형식이 게시되므로 바이너리 로그 파일을 처리하기 위해 자체 제작한 도구들도 사용될 수 있습니다.
IIS 6.0은 W3C와 바이너리 로깅 형식으로 HTTP substatus 코드에 로그하는 기능도 지원합니다. IIS는 특정 유형의 문제에 대해 특정 substatus 코드를 반환하기 때문에 Substatus 코드는 디버깅이나 문제해결에 종종 유용합니다.
가령, 필요한 어플리케이션이 잠금 해제되어 있지 않아서 요청이 제공되지 않을 경우(새로 설치 시 ASP가 기본적으로 잠금 상태인 것처럼), 클라이언트는 일반 404를 받게 됩니다. IIs는 실제로 W3C와 바이너리 로그 파일에 로그되는 404.2를 생성합니다.
IIS 6.0의 FTP 개선 기능은 다음과 같습니다.
일반적으로 ISP/ASP 고객들은 구하기 쉽고 널리 사용되기 때문에 FTP를 이용하여 그들의 웹 컨텐트를 업로드해 왔습니다. IIS 6.0는 별개의 디렉터리에 사용자를 분리할 수 있도록 하여 사용자들이 다른 사용자의 웹 컨텐트를 보거나 덮어 쓰기하지 못하도록 합니다.
사용자의 최 상위 수준의 디렉터리는 FRP 서비스의 루트로 나타나므로 디렉터리 트리의 상위 항목을 검색할 수 없도록 함으로써 액세스를 제한합니다. 사용자는 자신의 특정 사이트 내에서 파일이나 폴더를 생성, 변경 또는 삭제할 수 있습니다.
FTP 구현 기능은 프론트엔드와 백엔드 서버의 수에 상관없이 구성되어 안정성과 가용성을 향상시킵니다. FTP는 최종 사용자에게 영향을 미치지 않으면서 가상 디렉터리와 서버가 추가됨에 따라 간편하게 확장됩니다.
PASV FTP는 클라이언트가 이차 연결을 할 수 있도록 서버로 하여금 데이터를 공개하도록 합니다. 이는 FTP 관리 채널에 사용되던 일반 포트 21과는 별개의 연결입니다.
PASV 연결에 사용되는 포트 범위는 이제 IIS 6.0을 이용하여 구성할 수 있게 되었습니다. 이 기능은 관리자가 인터넷에 공개되는 포트 범위에 대해 보다 세밀한 제어를 할 수 있도록 하여 IIS 6.0 FTP 서버의 공격 부위를 축소시킬 수 있습니다.
Windows Server 2003은 다음과 같은 새로운 기능들을 제공함으로써 패치 관리 기능을 대폭 향상시켰습니다.
패치 설치 시 서비스가 중단되지 않음. 새로운 IIS 6.0 아키텍처에는 작업자 프로세스 리사이클링이 포함되어 있는데 이는 서비스가 중단되는 일 없이 관리자가 모든 IIS 핫 픽스와 새로운 작업자 프로세스 DLL을 간편하게 설치할 수 있다는 의미입니다.
자동 업데이트. 자동 업데이트 버전 1.0은 세 가지 옵션을 제공합니다:
· 패치가 제공되는 순간에 패치 가용성에 대해 알려줍니다.
· 패치를 다운로드하고 패치의 가용성에 대해 알려줍니다.
· 예약 설치 (이 옵션은 관리자가 지정한 시간에 패치를 자동으로 다운로드하고 설치할 수 있도록 합니다.)
Windows Update Corporate Edition. 대부분의 IT부서는 사용자들이 보안 패치를 표준 운영 환경에서 먼저 테스트해보지 않은 상태에서는 보안 패치와 기타 Windows Update 패키지를 설치하지 못하도록 합니다.
Corporate Windows Update는 이제 사용자들이 그들의 조직에서 요구하는 패치에 대한 품질 보증 테스트를 실시할 수 있도록 합니다. 패치가 지정된 테스트에 합격하게 되면 방화벽 너머의 Corporate Windows Update 서버에 설치될 수 있고 방화벽 내부의 모든 시스템들은 패치를 적용할 수 있게 됩니다.
Resource Free DLLs. Windows는 실제 구현에서 지역화된 리소스를 분리하였습니다. 이로써 30개의 언어로 된 픽스들을 신속하게 설계하는 Microsoft의 능력이 향상되었습니다.
IIS 6.0과 Windows Server 2003은 가장 신뢰할 수 있고 생산적이며 연결성이 높은 통합 웹 서버 솔루션을 제공합니다. IIS 6.0는 웹 서버의 안정성, 관리성, 보안, 성능 및 확장성을 향상시키기 위해 다양한 신 기능을 제공합니다. XML 메타베이스로 인해, 관리자들은 컴퓨터간에 서버 구성 정보를 전송할 수 있게 되었으며 XML 메타베이스는 원격 관리도 허용합니다. 작업자 프로세스 분리 모드는 잘못된 어플리케이션이나 웹 사이트로부터 IIS의 핵심(core)을 보호해줍니다. 또한, IIS 5.0 분리 모드 역시 여전히 어플리케이션을 위해 제공되고 있어서 관리자들의 선택의 폭이 넓어졌습니다. IIS 6.0은 더욱 다양한 명령줄 도구들을 소개하고 있으며 WMI 공급자도 COM 개체 인터페이스를 이용하여 IIS 메타베이스 데이터에 액세스할 수 있게 해주며 비록 유사하긴 하지만 ADSI보다 관리 효율적인 방식입니다.
전 세계 고객들의 요구 사항을 충족시키기 위해 구조적으로 대폭 개선되었습니다. 이러한 모든 개선 기능들로 인해 IIS 6.0은 IIS 5.0보다 서버당 수천 개 이상의 웹 사이트를 호스트 할 수 있게 되었으며 처리량과 시동 시간이 향상되었습니다. 이러한 개선 기능과 기능 및 새로운 아키텍처가 결합되어 IIS 6.0을 가장 안정적이고 강력하며 관리가 용이한 웹 서버로 만들어주고 있습니다.
· http://www.microsoft.com/windows.netserver/evaluation/overview/technologies/iis.mspx에서 제공하는 IIS 6.0의 새로운 기능
· http://www.microsoft.com/windows.netserver/evaluation/overview/technologies/security.mspx에서 제공하는 새로운 Security 기능
· http://www.microsoft.com/windows.netserver/techinfo/overviews/security.mspx 에서 제공하는 보안 기술 개요
· http://www.microsoft.com/windows.netserver/evaluation/overview/default.mspx에서 제공하는 Windows Server 2003 제품군 개요
· http://www.microsoft.com/windows.netserver/evaluation/features/에서 제공하는 Windows Server 2003 기능 안내서
· http://www.microsoft.com//windows.netserver/evaluation/overview/dotnet/default.mspx에서 제공하는 Windows Server 2003 제품군의 “.NET” 소개
· http://www.microsoft.com/windows2000/technologies/web/default.asp에서 제공하는 Windows 2000 Web and Application Services
Windows Server 2003에 관한 최신 정보는 http://www.microsoft.com/Windows Server 2003 에서 제공하는 Windows Server 2003 Web site 를 참조하십시오.
[1] 작업자 프로세스: ISAPI 필터와 확장자 로드 및 인증과 같은 모든 웹 어플리케이션 프로세싱이 새로운 WWW 서비스 DLL에 의해 수행됩니다. 이 DLL은 작업자 프로세스라 불리는 하나 이상의 호스트 프로세스에 로드됩니다. 작업자 프로세스 실행 파일의 이름은 w3wp.exe입니다. 작업자 프로세스가 IIS 6.0과 상호 작동하는 방법에 대한 추가 정보는 이 섹션 다음에 나오는 작업자 프로세스 분리 모드를 참조하십시오.
[2] 어플리케이션 풀: 어플리케이션 풀은 HTTP.sys내에 있는 하나의 요청 대기열에 해당하며 하나 이상의 작업자 프로세스로 이루어져 있습니다. 어플리케이션 풀은 하나 이상의 고유한 웹 어플리케이션에 대한 요청을 처리할 수 있습니다. 이러한 웹 어플리케이션들은 자신의 URL을 기반으로 하여 어플리케이션 풀에 할당됩니다. 동시에 여러 개의 어플리케이션 풀이 작동될 수도 있습니다. 어플리케이션 풀에 대한 추가 정보는 이 섹션 다음에 나오는 작업자 프로세스 분리 모드를 참고하십시오.