IIS와 ASP.NET 개발 서버의 결정적 차이(C#)
작성자 : Scott Mitchell
ASP.NET 애플리케이션을 로컬로 테스트할 때 ASP.NET 개발 웹 서버를 사용할 가능성이 높습니다. 그러나 프로덕션 웹 사이트는 대부분 IIS를 구동합니다. 이러한 웹 서버가 요청을 처리하는 방법에는 몇 가지 차이점이 있으며 이러한 차이는 중요한 결과를 초래할 수 있습니다. 이 자습서에서는 몇 가지 더 많은 게르만 차이점을 살펴봅니다.
소개
사용자가 ASP.NET 애플리케이션을 방문할 때마다 브라우저는 웹 사이트에 요청을 보냅니다. 해당 요청은 요청된 리소스에 대한 콘텐츠를 생성하고 반환하기 위해 ASP.NET 런타임과 조정하는 웹 서버 소프트웨어에 의해 선택됩니다. I nternet I nformation S 서비스(IIS)는 Windows 서버에 대한 일반적인 인터넷 기반 기능을 제공하는 서비스 모음입니다. IIS는 프로덕션 환경에서 ASP.NET 애플리케이션에 가장 일반적으로 사용되는 웹 서버입니다. 웹 호스트 공급자가 ASP.NET 애플리케이션을 제공하는 데 사용하는 웹 서버 소프트웨어일 가능성이 높습니다. IIS는 개발 환경에서 웹 서버 소프트웨어로도 사용할 수 있지만 IIS를 설치하고 올바르게 구성하는 것이 필요합니다.
ASP.NET 개발 서버는 개발 환경에 대한 대체 웹 서버 옵션입니다. 와 함께 제공하고 Visual Studio에 통합됩니다. 웹 애플리케이션이 IIS를 사용하도록 구성되지 않은 한 visual Studio 내에서 웹 페이지를 처음 방문할 때 ASP.NET 개발 서버가 자동으로 시작되고 웹 서버로 사용됩니다. 배포해야 할 파일 결정 자습서에서 다시 만든 데모 웹 애플리케이션은 둘 다 IIS를 사용하도록 구성되지 않은 파일 시스템 기반 웹 애플리케이션이었습니다. 따라서 Visual Studio 내에서 이러한 웹 사이트 중 하나를 방문할 때 ASP.NET 개발 서버가 사용됩니다.
완벽한 세상에서 개발 및 프로덕션 환경은 동일합니다. 그러나 앞의 자습서에서 설명한 것처럼 환경에 다른 구성 설정이 있는 것은 드문 일이 아닙니다. 환경에서 다른 웹 서버 소프트웨어를 사용하면 애플리케이션을 배포할 때 고려해야 하는 다른 변수가 추가됩니다. 이 자습서에서는 IIS와 ASP.NET 개발 서버 간의 주요 차이점에 대해 설명합니다. 이러한 차이 때문에 개발 환경에서 완벽하게 실행되는 코드가 예외를 throw하거나 프로덕션 환경에서 실행될 때 다르게 동작하는 시나리오가 있습니다.
보안 컨텍스트 차이점
웹 서버 소프트웨어가 들어오는 요청을 처리할 때마다 해당 요청을 특정 보안 컨텍스트와 연결합니다. 이 보안 컨텍스트 정보는 운영 체제에서 요청에 의해 허용되는 작업을 결정하는 데 사용됩니다. 예를 들어 ASP.NET 페이지에는 디스크의 파일에 일부 메시지를 기록하는 코드가 포함될 수 있습니다. 이 ASP.NET 페이지를 오류 없이 실행하려면 보안 컨텍스트에 적절한 파일 시스템 수준 권한, 즉 해당 파일에 대한 쓰기 권한이 있어야 합니다.
ASP.NET 개발 서버는 들어오는 요청을 현재 로그온한 사용자의 보안 컨텍스트와 연결합니다. 데스크톱에 관리자로 로그온한 경우 ASP.NET 개발 서버에서 제공하는 ASP.NET 페이지는 관리자와 동일한 액세스 권한을 가집니다. 그러나 IIS에서 처리하는 ASP.NET 요청은 특정 컴퓨터 계정과 연결됩니다. 웹 호스트 공급자가 각 고객에 대해 고유한 계정을 구성했을 수 있지만 기본적으로 네트워크 서비스 컴퓨터 계정은 IIS 버전 6 및 7에서 사용됩니다. 또한 웹 호스트 공급자가 이 컴퓨터 계정에 대해 제한된 권한을 부여했을 가능성이 높습니다. 결과적으로 개발 환경에서 오류 없이 실행되는 웹 페이지가 있을 수 있지만 프로덕션 환경에서 호스트될 때 권한 부여 관련 예외를 생성할 수 있습니다.
이 유형의 오류를 실제로 표시하기 위해 책 검토 웹 사이트에서 24시간 동안 3.5 의 교육 ASP.NET 가장 최근의 날짜와 시간을 저장하는 파일을 디스크에 만드는 페이지를 만들었습니다. 따라가려면 페이지를 열고 ~/Tech/TYASP35.aspx 이벤트 처리기에 다음 코드를 Page_Load 추가합니다.
protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
참고
메서드가 File.WriteAllText 없는 경우 새 파일을 만든 다음 지정된 내용을 씁니다. 파일이 이미 있는 경우 기존 콘텐츠를 덮어씁니다.
다음으로, ASP.NET 개발 서버를 사용하여 개발 환경 의 24시간 내 교육 ASP.NET 3.5 책 검토 페이지를 방문하세요. 웹 애플리케이션의 루트 디렉터리에서 텍스트 파일을 만들고 수정할 수 있는 충분한 권한이 있는 계정으로 컴퓨터에 로그온했다고 가정하면 책 검토는 이전과 동일하게 표시되지만 페이지를 방문할 때마다 날짜와 시간 및 사용자의 IP 주소가 파일에 저장 LastTYASP35Access.txt 됩니다. 브라우저에서 이 파일을 가리킵니다. 그림 1에 표시된 것과 유사한 메시지가 표시됩니다.
그림 1: 텍스트 파일에 책 검토가 마지막으로 방문한 날짜 및 시간이 포함되어 있습니다(전체 크기 이미지를 보려면 클릭).
프로덕션에 웹 애플리케이션을 배포한 다음, 호스트된 Teach Yourself ASP.NET 3.5 in 24시간 책 검토 페이지를 방문합니다. 이 시점에서 책 검토 페이지가 정상적으로 표시되거나 그림 2에 표시된 오류 메시지가 표시됩니다. 일부 웹 호스트 공급자는 익명 ASP.NET 컴퓨터 계정에 쓰기 권한을 부여합니다. 이 경우 페이지는 오류 없이 작동합니다. 그러나 웹 호스트 공급자가 익명 계정에 UnauthorizedAccessException 대한 쓰기 액세스를 금지하는 경우 페이지에서 현재 날짜와 시간을 파일에 쓰려고 할 때 TYASP35.aspx 예외가 LastTYASP35Access.txt 발생합니다.
그림 2: IIS에서 사용하는 기본 컴퓨터 계정에 파일 시스템에 쓸 수 있는 권한이 없습니다(전체 크기 이미지를 보려면 클릭).
좋은 소식은 대부분의 웹 호스트 공급자에 웹 사이트에서 파일 시스템 권한을 지정할 수 있는 일종의 사용 권한 도구가 있다는 것입니다. 익명 ASP.NET 계정에 루트 디렉터리에 대한 쓰기 권한을 부여한 다음 책 검토 페이지를 다시 방문합니다. (필요한 경우 기본 ASP.NET 계정에 쓰기 권한을 부여하는 방법에 대한 지원을 받으려면 웹 호스트 공급자에게 문의하세요.) 이번에는 페이지가 오류 없이 로드되고 LastTYASP35Access.txt 파일을 성공적으로 만들어야 합니다.
여기서는 ASP.NET 개발 서버가 IIS와 다른 보안 컨텍스트에서 작동하기 때문에 파일 시스템에서 읽거나 쓰거나 Windows 이벤트 로그에서 읽거나 쓰거나 Windows 레지스트리에 읽거나 쓰는 ASP.NET 페이지가 개발에 예상대로 작동하지만 프로덕션 환경에서 예외가 발생할 수 있습니다. 공유 웹 호스팅 환경에 배포할 웹 애플리케이션을 빌드하는 경우 이벤트 로그 또는 Windows 레지스트리를 읽거나 쓰지 마세요. 또한 프로덕션 환경의 적절한 폴더에 대한 읽기 및 쓰기 권한을 부여해야 할 수 있으므로 파일 시스템에서 읽거나 쓰는 ASP.NET 페이지를 기록해 둡니다.
정적 콘텐츠 제공의 차이점
IIS와 ASP.NET 개발 서버 간의 또 다른 핵심 차이점은 정적 콘텐츠에 대한 요청을 처리하는 방법입니다. ASP.NET 페이지, 이미지 또는 JavaScript 파일 등 ASP.NET 개발 서버에 들어오는 모든 요청은 ASP.NET 런타임에서 처리됩니다. 기본적으로 IIS는 ASP.NET 웹 페이지, 웹 서비스 등과 같은 ASP.NET 리소스에 대한 요청이 들어오는 경우에만 ASP.NET 런타임을 호출합니다. 이미지, CSS 파일, JavaScript 파일, PDF 파일, ZIP 파일 등 정적 콘텐츠에 대한 요청은 ASP.NET 런타임의 개입 없이 IIS에서 검색됩니다. (정적 콘텐츠를 제공하는 경우 IIS에서 ASP.NET 런타임으로 작업하도록 지시할 수 있습니다. 자세한 내용은 이 자습서의 "IIS 7을 사용하여 정적 파일에서 Forms-Based 인증 및 URL 인증 수행" 섹션을 참조하세요.
ASP.NET 런타임은 인증(요청자 식별) 및 권한 부여(요청자에게 요청된 콘텐츠를 볼 수 있는 권한이 있는지 확인)를 포함하여 요청된 콘텐츠를 생성하는 여러 단계를 수행합니다. 일반적으로 사용되는 인증 형식은 양식 기반 인증으로, 사용자가 웹 페이지의 텍스트 상자에 자격 증명(일반적으로 사용자 이름 및 암호)을 입력하여 식별합니다. 자격 증명의 유효성을 검사하면 웹 사이트는 사용자의 브라우저에 인증 티켓 쿠키를 저장합니다. 이 쿠키는 웹 사이트에 대한 모든 후속 요청과 함께 전송되며 사용자를 인증하는 데 사용됩니다. 또한 특정 폴더에 액세스할 수 있거나 액세스할 수 없는 사용자를 지정하는 URL 권한 부여 규칙을 지정할 수 있습니다. 많은 ASP.NET 웹 사이트는 양식 기반 인증 및 URL 권한 부여를 사용하여 사용자 계정을 지원하고 인증된 사용자 또는 특정 역할에 속한 사용자만 액세스할 수 있는 사이트의 일부를 정의합니다.
참고
ASP에 대한 철저한 검사를 위해. NET의 양식 기반 인증, URL 권한 부여 및 기타 사용자 계정 관련 기능은 내 웹 사이트 보안 자습서를 검사 합니다.
양식 기반 권한 부여를 사용하여 사용자 계정을 지원하고 URL 권한 부여를 사용하여 인증된 사용자만 허용하도록 구성된 폴더가 있는 웹 사이트를 고려합니다. 이 폴더에는 ASP.NET 페이지 및 PDF 파일이 포함되어 있으며 인증된 사용자만 이러한 PDF 파일을 볼 수 있다는 의도가 있다고 상상해 보세요.
방문자가 브라우저의 주소 표시줄에 URL을 직접 입력하여 이러한 PDF 파일 중 하나를 보려고 하면 어떻게 됩니까? 알아보려면 책 검토 사이트에 새 폴더를 만들고, PDF 파일을 추가하고, 익명 사용자가 이 폴더를 방문하지 못하도록 URL 권한 부여를 사용하도록 사이트를 구성해 보겠습니다. 데모 애플리케이션을 다운로드하면 라는 PrivateDocs 폴더를 만들고 웹 사이트 보안 자습서 (맞춤 방법)에서 PDF를 추가한 것을 볼 수 있습니다. 폴더에는 PrivateDocs 익명 사용자를 거부하는 URL 권한 부여 규칙을 지정하는 파일도 포함되어 Web.config 있습니다.
<?xml version="1.0"?>
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
마지막으로, 루트 디렉터리에서 파일을 업데이트하고 다음을 대체하여 양식 기반 인증을 Web.config 사용하도록 웹 애플리케이션을 구성했습니다.
<authentication mode="Windows" />
다음으로 바꾸기:
<authentication mode="Forms" />
ASP.NET 개발 서버를 사용하여 사이트를 방문하여 브라우저의 주소 표시줄에 있는 PDF 파일 중 하나에 대한 직접 URL을 입력합니다. 이 자습서와 연결된 웹 사이트를 다운로드한 경우 URL은 다음과 같습니다. http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf
주소 표시줄에 이 URL을 입력하면 브라우저가 파일에 대한 ASP.NET 개발 서버에 요청을 보냅니다. ASP.NET 개발 서버는 처리를 위해 ASP.NET 런타임에 요청을 처리합니다. 아직 로그인하지 않았고 폴더의 PrivateDocs 가 익명 액세스를 거부하도록 구성되었으므로 Web.config ASP.NET 런타임에서 자동으로 로그인 페이지 Login.aspx 로 리디렉션됩니다(그림 3 참조). 사용자를 로그인 페이지로 리디렉션할 때 ASP.NET 사용자가 보려고 한 페이지를 나타내는 querystring 매개 변수를 포함합니다 ReturnUrl . 성공적으로 로그인한 후에는 이 페이지로 돌아갈 수 있습니다.
그림 3: 권한이 없는 사용자가 로그인 페이지로 자동으로 리디렉션됩니다(전체 크기 이미지를 보려면 클릭).
이제 프로덕션에서 이 동작이 어떻게 동작하는지 살펴보겠습니다. 애플리케이션을 배포하고 프로덕션의 폴더에 있는 PDF 중 하나에 직접 URL을 PrivateDocs 입력합니다. 그러면 브라우저에서 파일에 대한 요청 IIS를 보내라는 메시지가 표시됩니다. 정적 파일이 요청되므로 IIS는 ASP.NET 런타임을 호출하지 않고 파일을 검색하고 반환합니다. 결과적으로 url 권한 부여 검사 수행되지 않았습니다. 개인 PDF의 콘텐츠는 파일에 대한 직접 URL을 아는 모든 사용자가 액세스할 수 있습니다.
그림 4: 익명 사용자는 파일에 직접 URL을 입력하여 프라이빗 PDF 파일을 다운로드할 수 있습니다(전체 크기 이미지를 보려면 클릭).
IIS 7을 사용하여 정적 파일에서 Forms-Based 인증 및 URL 인증 수행
권한이 없는 사용자로부터 정적 콘텐츠를 보호하는 데 사용할 수 있는 몇 가지 기술이 있습니다. IIS 7에는 IIS의 워크플로와 ASP.NET 런타임 워크플로를 결합하는 통합 파이프라인이 도입되었습니다. 간단히 말해서 IIS에 들어오는 모든 요청(PDF 파일과 같은 정적 콘텐츠 포함)ASP.NET 런타임의 인증 및 권한 부여 모듈을 호출하도록 지시할 수 있습니다. 통합 파이프라인을 사용하도록 웹 사이트를 구성하는 방법을 알아보려면 웹 호스트 공급자에게 문의하세요.
통합 파이프라인을 사용하도록 IIS가 구성되면 루트 디렉터리의 파일에 다음 태그 Web.config 를 추가합니다.
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
이 태그는 IIS 7에 ASP.NET 기반 인증 및 권한 부여 모듈을 사용하도록 지시합니다. 애플리케이션을 다시 배포한 다음 PDF 파일을 다시 방문합니다. 이번에는 IIS가 요청을 처리하면 ASP.NET 런타임의 인증 및 권한 부여 논리에 요청을 검사할 수 있는 기회가 제공됩니다. 인증된 사용자만 폴더의 콘텐츠를 볼 수 있는 PrivateDocs 권한이 있으므로 익명 방문자가 자동으로 로그인 페이지로 리디렉션됩니다(그림 3 참조).
참고
웹 호스트 공급자가 여전히 IIS 6을 사용하는 경우 통합 파이프라인 기능을 사용할 수 없습니다. 한 가지 해결 방법은 HTTP 액세스를 금지하는 폴더(예: App_Data)에 개인 문서를 배치한 다음 이러한 문서를 제공하는 페이지를 만드는 것입니다. 이 페이지는 라고 GetPDF.aspx할 수 있으며 querystring 매개 변수를 통해 PDF의 이름을 전달합니다. 페이지는 GetPDF.aspx 먼저 사용자에게 파일을 볼 수 있는 권한이 있는지 확인하고, 이 경우 메서드를 Response.WriteFile(filePath) 사용하여 요청된 PDF 파일의 내용을 요청 클라이언트에 다시 보냅니다. 통합 파이프라인을 사용하도록 설정하지 않으려는 경우 이 기술은 IIS 7에서도 작동합니다.
요약
프로덕션 환경의 웹 애플리케이션은 Microsoft의 IIS 웹 서버 소프트웨어를 사용하여 호스팅됩니다. 그러나 개발 환경에서는 IIS 또는 ASP.NET 개발 서버를 사용하여 애플리케이션을 호스트할 수 있습니다. 다른 소프트웨어를 사용하면 혼합에 다른 변수가 추가되기 때문에 두 환경에서 동일한 웹 서버 소프트웨어를 사용하는 것이 좋습니다. 그러나 ASP.NET 개발 서버의 사용 편의성을 통해 개발 환경에서 매력적인 선택이 될 수 있습니다. 좋은 소식은 IIS와 ASP.NET 개발 서버 간에 몇 가지 근본적인 차이점이 있다는 것입니다. 이러한 차이점을 알고 있다면 환경에 관계없이 애플리케이션이 동일한 방식으로 작동하고 작동하도록 하는 단계를 수행할 수 있습니다.
행복한 프로그래밍!
추가 정보
이 자습서에서 설명하는 topics 대한 자세한 내용은 다음 리소스를 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기