IIS URL 다시 쓰기 및 ASP.NET 라우팅
로 루슬란 야쿠셰프
IIS용 URL 다시 쓰기 모듈이 릴리스되고 .NET Framework 4에 ASP.NET 라우팅이 포함되면서 ASP.NET 개발자는 이러한 두 기능이 서로 어떻게 관련되는지, 그리고 둘 중 하나를 사용해야 하는지에 대해 많은 질문을 받았습니다. 이 문서에서는 이러한 두 기술의 차이점을 설명하고 웹 개발자에게 IIS URL 다시 쓰기를 사용하는 시기와 ASP.NET 라우팅을 사용하는 시기에 대한 지침을 제공합니다.
대략적인 관점에서 볼 때 이러한 기술은 매우 유사한 기능을 제공하는 것처럼 보입니다. 둘 다 웹 애플리케이션에서 사용자에게 친숙하고 검색 엔진에 친숙한 URL을 가질 수 있도록 합니다. 그러나 웹 애플리케이션에 사용할 항목에 대해 올바른 결정을 내리는 데 중요한 두 기술 간에는 기본적인 차이점이 있습니다. 이러한 차이점을 이해하는 데 도움이 되도록 먼저 IIS URL 다시 작성 및 ASP.NET 라우팅이 작동하는 방법을 설명합니다.
IIS URL 다시 쓰기
URL 다시 쓰기의 기본 개념은 새로운 개념이 아닙니다. 약 10년 전에 Apache 웹 서버에서 도입되었습니다. 그 이후로 웹 서버 관리자 및 웹 개발자에게 매우 유용한 도구로 입증되었습니다. Apache에서 호스트되는 많은 인기 애플리케이션은 이제 URL 다시 쓰기를 사용하여 "클린" URL을 지원할 수 있습니다.
URL 다시 쓰기의 개념은 간단합니다. 클라이언트가 특정 URL에 대한 요청을 웹 서버에 보내면 URL 재작성 모듈은 요청된 URL을 분석하고 동일한 서버의 다른 URL로 변경합니다. URL 다시 쓰기 모듈은 요청 처리 파이프라인에서 일찍 실행되며 웹 서버가 요청을 처리하는 데 사용할 처리기를 결정하기 전에 요청된 URL을 수정합니다. 다시 작성된 URL에 따라 선택된 처리기는 요청을 처리하고 웹 브라우저로 다시 전송되는 응답을 생성합니다. 요청 클라이언트는 다시 작성된 URL을 볼 수 없습니다. 클라이언트에 관한 한 원래 URL에서 응답을 받았습니다.
IIS 아키텍처 측면에서 이 프로세스는 다음 다이어그램으로 표시됩니다.
URL 다시 쓰기 모듈은 사전 시작 요청 또는 요청 시작 단계에서 요청 처리 파이프라인에 연결한 다음 다시 쓰기 규칙 집합을 사용하여 요청된 URL 경로를 평가하는 네이티브 코드 모듈입니다. 각 다시 쓰기 규칙은 URL 경로를 분석하고 모든 규칙 조건이 충족되면 원래 경로를 새 경로로 변경합니다. 모든 규칙을 평가한 후 URL 다시 쓰기 모듈은 IIS 파이프라인 처리의 나머지 부분을 통해 요청에 사용되는 최종 URL 경로를 생성합니다. 즉, IIS 파이프라인의 처리기 선택은 URL 다시 쓰기 모듈에서 생성되는 다시 작성된 URL을 기반으로 합니다.
ASP.NET 라우팅
ASP.NET 라우팅은 개발자가 특정 URL을 해당 URL에 대한 요청을 처리할 수 있는 처리기와 연결할 수 있는 요청 디스패치 메커니즘입니다. 이 연결은 특정 URL 경로에 대해 호출할 처리기를 정의하는 "경로"를 등록하여 수행됩니다. 웹 서버에 대한 요청이 이루어지면 ASP.NET 라우팅은 등록된 경로 목록에서 요청된 URL 경로를 조회합니다. 경로가 발견되면 해당 경로에 대한 해당 처리기가 호출되어 해당 요청을 처리합니다.
IIS 및 ASP.NET 아키텍처 측면에서 이 프로세스는 다음 다이어그램으로 표시됩니다.
ASP.NET 라우팅은 캐시 확인 단계(PostResolveRequestCache 이벤트) 및 맵 처리기 단계(PostMapRequestHandler 이벤트)에서 IIS 요청 처리 파이프라인에 연결하는 관리 코드 모듈로 구현됩니다. ASP.NET 라우팅은 웹 애플리케이션에 대한 모든 요청에 대해 실행되도록 구성됩니다.
PostResolveRequestCache 이벤트 중에 모듈은 요청된 URL 경로와 일치하는 경로에 대한 라우팅 테이블(경로 개체 컬렉션)을 살펴봅니다. 일치하는 항목이 발견되면 모듈은 해당 경로에 해당하는 처리기에 대한 참조를 가져오고 현재 HTTP 컨텍스트의 일부로 참조를 저장합니다. 처리기는 System.Web.IHttpHandler 인터페이스를 구현하는 모든 .NET Framework 개체일 수 있습니다. 경로를 찾을 수 없는 경우 모듈은 아무 작업도 수행하지 않으며 URL이 통과하여 정상적으로 처리됩니다(일반적으로 디스크의 파일과 일치).
PostMapRequestHandler 이벤트 중에 모듈은 HTTP 컨텍스트에 처리기에 대한 정보가 포함되어 있는지 확인합니다. 이 경우 ASP.NET 라우팅은 정보를 사용하여 현재 HTTP 컨텍스트의 Handler 속성을 설정합니다. 이렇게 하면 실행 처리기 단계에서 IIS는 라우팅 모듈에서 선택한 처리기를 실행합니다. 해당 정보가 설정되지 않은 경우 모듈은 아무 작업도 수행하지 않으며 URL은 IIS에서 처리기를 선택할 수 있도록 합니다.
IIS URL 다시 쓰기와 ASP.NET 라우팅 간의 차이점
위의 설명에 따라 IIS URL 다시 쓰기와 ASP.NET 라우팅 간에 다음과 같은 기본 개념적 차이가 있습니다.
- URL 다시 쓰기는 웹 서버에서 요청을 처리하기 전에 URL 경로를 조작하는 데 사용됩니다. URL 재작성 모듈은 다시 작성된 URL을 처리할 처리기를 알 수 없습니다. 또한 실제 요청 처리기는 URL이 다시 작성되었음을 알지 못할 수 있습니다.
- ASP.NET 라우팅은 요청된 URL 경로를 기반으로 처리기에 요청을 디스패치하는 데 사용됩니다. URL 다시 쓰기와 달리 라우팅 모듈은 처리기에 대해 알고 요청된 URL에 대한 응답을 생성해야 하는 처리기를 선택합니다. ASP.NET 라우팅을 고급 처리기 매핑 메커니즘으로 생각할 수 있습니다.
이러한 개념적 차이점 외에도 IIS URL 다시 쓰기와 ASP.NET 라우팅 간에 다음과 같은 기능적 차이가 있습니다.
- IIS URL 다시 쓰기 모듈은 ASP.NET, PHP, ASP 및 정적 파일을 포함하는 모든 유형의 웹 애플리케이션에서 사용할 수 있습니다. ASP.NET 라우팅은 .NET Framework 기반 웹 애플리케이션에서만 사용할 수 있습니다.
- IIS URL 다시 쓰기 모듈은 통합 또는 클래식 IIS 파이프라인 모드가 애플리케이션 풀에 사용되는지 여부에 관계없이 동일한 방식으로 작동합니다. ASP.NET 라우팅의 경우 통합 파이프라인 모드를 사용하는 것이 좋습니다. ASP.NET 라우팅은 클래식 모드에서 작동할 수 있지만 이 경우 애플리케이션 URL에는 파일 이름 확장명을 포함해야 합니다. 그렇지 않으면 IIS에서 "*" 처리기 매핑을 사용하도록 애플리케이션을 구성해야 합니다.
- IIS URL 다시 쓰기 모듈은 도메인 이름, HTTP 헤더 및 서버 변수에 따라 다시 작성 결정을 내릴 수 있습니다. 기본적으로 ASP.NET 라우팅은 URL 경로 및 HTTP-Method 헤더에서만 작동합니다.
- URL 다시 쓰기 모듈은 재작성 외에도 HTTP 리디렉션을 수행하고, 사용자 지정 상태 코드를 발급하고, 요청을 중단할 수 있습니다. ASP.NET 라우팅은 이러한 작업을 수행하지 않습니다.
- URL 다시 쓰기 모듈은 현재 버전에서 확장할 수 없습니다. ASP.NET 라우팅은 완전히 확장 가능하고 사용자 지정할 수 있습니다.
어떤 옵션을 사용해야 하나요?
웹 애플리케이션에 클린 URL을 사용하도록 설정하는 기술을 선택해야 하는 경우 이 모든 정보는 무엇을 의미하나요? 이 섹션에서는 이 옵션을 선택하는 방법을 설명합니다.
웹 애플리케이션이 ASP.NET 제외한 모든 항목을 사용하여 빌드된 경우 IIS URL 다시 쓰기 모듈을 사용합니다. 그렇지 않으면 규칙은 다음과 같습니다.
- ASP.NET MVC 또는 ASP.NET동적 데이터 기술을 사용하는 새 ASP.NET 웹 애플리케이션을 개발하는 경우 ASP.NET 라우팅을 사용합니다. 애플리케이션은 웹 페이지의 링크에 대한 클린 URL 생성을 포함하여 클린 URL에 대한 기본 지원을 활용할 수 있습니다. ASP.NET 라우팅은 아직 표준 Web Forms 애플리케이션을 지원하지 않지만 나중에 지원할 계획이 있습니다.
- 레거시 ASP.NET 웹 애플리케이션이 이미 있고 변경하지 않으려면 URL 다시 쓰기 모듈을 사용합니다. URL 다시 쓰기 모듈을 사용하면 검색 엔진에 친숙한 URL을 애플리케이션에서 현재 사용하는 형식으로 변환할 수 있습니다. 또한 검색 엔진 크롤러를 클린 URL로 리디렉션하는 데 사용할 수 있는 리디렉션 규칙을 만들 수 있습니다.
그러나 실제로는 선택 항목이 또는 일 필요는 없습니다. 기술은 함께 사용할 수 있으며 서로를 보완할 수 있습니다. 다음 섹션에서는 ASP.NET 라우팅 및 IIS URL 다시 쓰기를 함께 사용할 수 있는 몇 가지 시나리오를 간략하게 설명합니다.
애플리케이션에 정식 URL을 적용합니다.
대신 http://mysite.com/Home/About를 http://www.mysite.com/home/about 강제로 사용해야 합니다. 웹 클라이언트가 원하는 형식을 준수하지 않는 URL을 요청하면 클라이언트는 정식 URL로 리디렉션됩니다. 이 시나리오에서는 URL 다시 쓰기 모듈을 사용하여 정식 URL을 적용하고 리디렉션을 수행하고 ASP.NET 라우팅을 사용하여 요청된 URL 경로를 처리할 처리기를 선택할 수 있습니다.
다음 예제에서는 이 시나리오에 사용할 수 있는 URL 다시 쓰기 규칙을 보여줍니다.
<rewrite>
<rules>
<rule name="Enforce canonical hostname" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
</conditions>
<action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
다른 사이트 또는 서버에서 정적 콘텐츠 제공
웹 애플리케이션은 동적 웹 콘텐츠가 한 사이트 또는 서버에 있고 모든 정적 콘텐츠가 다른 사이트 또는 서버에 있는 방식으로 여러 서버에 배포됩니다. 현재 서버의 동적 웹 페이지에 대한 모든 요청을 처리하면서 IIS 애플리케이션 요청 라우팅 모듈 과 함께 URL 다시 쓰기 모듈을 사용하여 정적 파일에 대한 모든 요청을 다른 서버로 전달할 수 있습니다. 이러한 방식으로 ASP.NET 라우팅은 동적 웹 콘텐츠에만 사용되며 정적 콘텐츠에 대한 URL을 평가하지 않습니다.
다음 예제에서는 이 시나리오에 사용할 수 있는 URL 다시 쓰기 규칙을 보여줍니다.
<rewrite>
<rules>
<rule name="Forward to static file server">
<match url="^.+\.(?:jpg|bmp|gif)$" />
<action type="Rewrite" url="http://static_file_server/{R:0}" />
</rule>
</rules>
</rewrite>
정적 콘텐츠 관리.
정적 파일 또는 폴더를 새 위치로 이동한 경우에도 이전 버전과의 호환성을 위해 이전 URL을 계속 지원할 수 있습니다. 실제로 웹 사이트 방문자가 파일 또는 폴더가 이동되었음을 알지 못할 수 있습니다. 이 경우 URL 다시 쓰기 모듈을 사용하여 정적 파일의 경로를 다시 작성할 수 있으며 동적 ASP.NET 웹 페이지에 대한 모든 URL은 라우팅 모듈에서 처리됩니다.
다음 예제에서는 이 시나리오에 사용할 수 있는 URL 다시 쓰기 규칙을 보여줍니다.
<rewrite>
<rules>
<rule name="Rewrite to new folder">
<match url="^Images/(.+)$" />
<action type="Rewrite" url="NewImages/{R:1}" />
</rule>
</rules>
</rewrite>
요청 차단.
URL 다시 쓰기 모듈을 사용하여 다양한 조건에 따라 특정 요청을 차단할 수 있습니다. 예를 들어 특정 사이트 크롤러가 웹 사이트의 특정 URL 경로에 액세스하지 못하도록 방지할 수 있습니다. 이렇게 하면 금지된 요청이 ASP.NET 라우터에 도착하지 않으므로 웹 서버의 부하가 줄어듭니다.
다음 예제에서는 원치 않는 사이트 크롤러를 차단하는 데 사용할 수 있는 URL 다시 쓰기 규칙을 보여줍니다. 요청은 사용자 에이전트 HTTP 헤더 또는 클라이언트의 IP 주소를 기반으로 특정 URL 경로에 대해 차단됩니다.
<rewrite>
<rules>
<rule name="Block SomeRobot" stopProcessing="true">
<match url="^folder1/folder2" />
<conditions logicalGrouping="MatchAny">
<add input="{USER_AGENT}" pattern="SomeRobot" />
<add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
</conditions>
<action type="AbortRequest" />
</rule>
</rules>
</rewrite>
미래 방향
IIS URL 재작성 및 ASP.NET 라우팅에는 기능적 중복이 있지만 각 기술에 고유한 시나리오를 해결합니다. 이 때문에 이러한 두 기술은 IIS에서 독립적인 구성 요소로 계속 존재하고 발전할 것이며, 이러한 기술 간의 통합이 더 엄격할 가능성이 있습니다. 예를 들어 ASP.NET 라우팅은 URL 다시 쓰기 모듈과 함께 제공되는 몇 가지 풍부한 도구를 활용할 수 있습니다. URL 다시 쓰기 모듈은 URL 다시 쓰기 논리를 사용자 지정하기 위한 확장성을 제공하는 측면에서 ASP.NET 더 잘 통합할 수 있습니다.
결론
IIS URL 재작성 또는 ASP.NET 라우팅을 사용하여 웹 애플리케이션에 대한 URL 조작 시나리오를 구현할 수 있습니다. ASP.NET 라우팅은 ASP.NET 최적화된 솔루션이므로 처음부터 ASP.NET 애플리케이션을 디자인하고 클린 URL 구조를 원하는 웹 개발자에게 적합할 수 있습니다. IIS URL 다시 쓰기는 다양한 시나리오를 해결하는 일반적인 URL 조작 메커니즘입니다. 특히 웹 개발자와 웹 서버/사이트 관리자가 애플리케이션 코드를 수정하지 않고 기존 웹 애플리케이션에 클린 URL을 사용하도록 설정하는 데 사용할 수 있습니다.
관련 문서
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기