Session in ASP.Net Webform - 강좌4
Session in ASP.Net Webform - 강좌4
목차
세션 모드 및 상태 제공자세션 상태세션 이벤트세션 모드InProc 세션 모드InProc 세션 모드 개요언제 InProc 세션 모드를 사용해야 합니까?장점과 단점
StateServer 세션 모드StateServer 세션 모드 개요StateServer 세션 모드 구성StateServer 세션 모드 작동 방식StateServer 세션 모드의 예장점과 단점
SQL 서버 세션 모드SQLServer 세션 모드 작동 방식언제 SQL Server 세션 모드를 사용해야 합니까?SQL Server 세션 모드 구성장점과 단점
사용자 지정 세션 모드사용자 정의 세션 모드는 어떻게 작동합니까?사용자 정의 세션 모드는 언제 사용해야 합니까?사용자 지정 세션 모드 구성장점과 단점
- 프로덕션 배포 개요
- 애플리케이션 풀
- 애플리케이션 풀의 ID
- 애플리케이션 풀 생성 및 할당
- 웹가든
- 웹 정원을 만드는 방법
- 세션이 웹 가든에 의존하는 방식
- 웹 팜 및 로드 밸런서
- 웹 팜 및 로드 밸런서 시나리오에서 세션 처리
- 세션 및 쿠키
- 쿠키멍깅이란?
- ASP.NET에서 Cookie-Munging이 작동하는 방식
- 세션 제거
- 세션 활성화 및 비활성화
- 요약
Production Deployment (프로덕션 배포에 대해 알아보자)
일반적으로 Production environments 는 운영중인 production server 상에서 어플리케이션을 언제 효율적으로 활용하는지를 의미합니다. 이는 웹개발자가 운영 중인 서버상에 있는 어플리케이션을 효율적으로 활용하는 부분에 대해서 커다란 도전이기도 합니다. 많은 사용자가 있는 큰 production environment 이유로 하나의 서버로 인해 많은 사용자의 LOAD 를 취급한다는 거은 불가능합니다.
따라서 여기서 web farm 개념이나 Load balance , Web Garden 등이 있습니다. 단 몇 개월 이후, 저자는 백만명의 사용자로 인해 접근할 수 있는 운영중인 production environments 에서 하나의 웹어플리케이션을 효율적으로 활용하였습니다.. 그리고 10 개 active directory , load balance 위의 10개 web server 그리고 많은 DB server, exchange server, LCS 서버 등 보다 더 있었습니다.
만약에 웹서버의 개수를 보게 된다면, 이는 다양합니다. 다양한 서버와 연관된 주요 위험은 세션 관리입니다. 아래와 같은 이미지는 Production environments 에 대한 일반적인 다이어그램을 보여줍니다.
웹어플리케이션을 효율적으로 하는 반면, 명심해야 할 필요가 있는 다른 시나리오를 설명할것입니다.
애플리케이션 풀 (Application Pool) :
이것은 프로덕션 환경(Production environments) 에서 애플리케이션을 위해 만들어야 하는 가장 중요한 것 중 하나입니다. application pool 은 동일한 구성을 공유하는 IIS worker processes 집합을 분리하는 데 사용됩니다. application pool 을 사용하면 더 나은 보안, 안정성 및 가용성을 위해 웹 애플리케이션을 격리할 수 있습니다.
worker processes 는 각 application pool 을 구분하는 프로세스 경계 역할을 하므로 하나의 worker processes 또는 응용 프로그램에 문제가 있거나 재활용될 때 다른 응용 프로그램이나 worker processes 는 영향을 받지 않습니다.
애플리케이션 풀(Application Pool) 을 알아보자
application pool ID 구성은 프로세스가 리소스에 액세스할 때 worker processes 의 ID를 결정하기 때문에 IIS 6.0 및 IIS 7.0 보안의 중요한 측면입니다. IIS 7.0에는 IIS 6.0과 동일한 세 가지 미리 정의된 ID가 있습니다.
| 애플리케이션 풀 ID | 설명 |
| LocalSystem | 서버에 대한 관리 권한이 있는 기본 제공 계정입니다. 로컬 및 원격 리소스 모두에 액세스할 수 있습니다. 서버 파일이나 리소스에 액세스하려면 application pool 의 ID를 LocalSystem. |
| LocalServices | 빌트인 계정은 인증된 로컬 사용자 계정의 권한을 가집니다. 네트워크 액세스 권한이 없습니다. |
| NetworkServices | 이것은 application pool 의 기본 ID입니다. NetworkServices인증된 로컬 사용자 계정의 권한이 있습니다. |
IIS 콘솔을 열고 application pool 폴더 > 새로 만들기를 마우스 오른쪽 버튼으로 클릭합니다.
application pool ID를 "StateServerAppPool " 이름으로 하고 ok 저장합니다.
애플리케이션 풀에 위에 생성한 풀 이름인 'StateServerAppPool' 를 선택하여 할당합니다.
따라서 이 웹 사이트는 StateServerAppPool 과 함께 독립적으로 실행됩니다. 다른 응용 프로그램과 관련된 이슈는 이 응용 프로그램에겐 어떤 영향을 미치지 않습니다. 이것이 application pool 을 별도로 만들게 된 주요 이점입니다.
웹가든(Web Garden)
기본적으로 각 응용 프로그램 풀은 단일 작업자 프로세스(W3Wp.exe)로 실행됩니다. 단일 응용 프로그램 풀로 여러 작업자 프로세스를 할당할 수 있습니다. (1개의 애플리케이션 풀로 다수의 작업프로세스에 할당할 수 있음)
여러 개의 작업자 프로세스가 있는 응용 프로그램 풀을 Web Garden(웹 가든)이라고 합니다.
반면에 하나의 작업자 프로세스만 사용하는있는 응용프로그램 풀은 Applicaton Pool (애플리케이션 풀) 이라고 위에서 언급했습니다.
동일한 응용 프로그램 풀을 사용하는 많은 작업자 프로세스는 때때로 더 나은 처리 성능과 응용 프로그램 응답 시간을 제공할 수 있습니다. 그리고 각 작업자 프로세스에는 자체 스레드 및 메모리 공간이 있어야 합니다.
그림과 같이 IIS에는 여러 개의 application pool 이 있을 수 있으며 각 application pool 에는 적어도 하나의 worker processes 가 있습니다. 📢📢📢 웹 가든에는 여러 worker processes 가 포함되어야 합니다.
웹 애플리케이션과 함께 웹 가든을 사용하는 데 특정 제한 사항이 있습니다. InProc 세션 모드를 사용하면 세션이 다른 worker processes 에 의해 처리되기 때문에 응용 프로그램이 올바르게 작동하지 않습니다.
이 문제를 방지하려면 OutProc 세션 모드를 사용해야 하며 ✅✅✅ 세션 StateServer 또는 SQL-Server 세션 상태를 사용할 수 있습니다.
Web Garden 을 사용하게 되면,
- InProc 세션모드는 사용불가(x)
- StateServer 와 SQL-Server 는 둘 다 사용가능(0)
주요 이점: 웹 가든의 worker processes 는 특정 application pool 에 도착하는 request 을 공유합니다. 만약 특정 하나의 worker processes 가 실패하면 다른 worker processes 에 요청하여 계속해서 처리할 수 있습니다.
Web Garden 생성하는 방법?
응용 프로그램 풀을 마우스 오른쪽 버튼으로 클릭 > 성능 탭으로 이동 > Web Garden 섹션 확인(그림에서 강조 표시됨):
기본적으로 애플리케이션 풀이며, 개수는 1입니다. 📢📢📢📢 2개 이상으로 변경하면 웹 가든으로 변경되어 가동됩니다.
만약에 어플리케이션 풀과 Web Garden 을 ii7 에서 생성하고자 한다면, 해당 강좌를 읽어보시기 바랍니다.
[강좌바로가기=> article]
Session은 Web Garden에 어떻게 의존합니까?
InProc 은 작업자 프로세스에서 처리한다고 이미 설명했습니다. 메모리 객체 내부에 데이터를 보관합니다. 이제 여러 작업자 프로세스가 있는 경우 각 작업자 프로세스마다 자체 메모리가 있기 때문에 세션을 처리하기가 매우 어려울 것입니다.
따라서 첫 번째 request 이 WP1으로 이동하고 안에서 세션 데이터를 유지하고, 두 번째 request 이 WP2로 이동하면 세션 데이터를 검색하려고 하는데 이를 사용할 수 없어서 오류가 발생합니다.
✅✅✅✅✅ 따라서 InProc 세션 모드에서 Web Garden 을 사용하지 마세요.
이미 설명했듯이 이 2개의 세션 모드는 작업자 프로세스에 의존하지 않기 때문에 Web Gardens 에서 StateServer 또는 SQLServer 세션 모드를 사용할 수 있습니다.
예제에서 IIS를 다시 시작하더라도 여전히 세션 데이터에 액세스할 수 있다고 설명했습니다.
간략하게 줄여서 정리하자면...
| Session Mode | 추천사항 |
| InProc | 비추천 |
| StateServer | 추천 |
| SQLServer | 추천 |
🚨🚨🚨🚨 웹가든을 사용할 경우 데이터베이스가 존재하지 않거나 좀 더 성능을 고려한다면, StateServer 를 추천해 봅니다.
Web Farm 그리고 Load Balancer:
웹 애플리케이션이 여러 웹 서버에서 호스팅되고 서버의 부하를 기반으로 액세스하는 경우 이를 Web Farm 이라고 합니다.
이는 production deployment 에서 사용되는 가장 일반적인 용어입니다. 이러한 용어는 애플리케이션을 배포하기 위해 여러 웹 서버를 사용할 때 사용됩니다. 이것을 사용하는 주된 이유는 부하를 여러 서버에 분산시켜야 하기 때문입니다. 로드 밸런서는 여러 서버에 로드를 분산하는 데 사용됩니다.
위의 다이어그램을 보면 클라이언트가 URL을 요청하고 액세스할 서버를 결정하는 Load Balancer 에 도달합니다. 로드 밸런서는 모든 다른 웹 서버에 트래픽을 분산합니다.
이 다이어그램을 확인하자면, 클라이언트는 URL 로 요청을 하고 로드 밴런서는 HIT 할 것입니다. 지금 로드 벨런서는 어떤 서버에 접근을 할것인지 결정을 할것입니다. 로드밸렌서는 모든 웹서버상의 트래픽을 분산처리를 할것입니다.
이제 이것이 세션에 어떤 영향을 주는지 알아보죠.
Web Farm 과 Load Balancer 에서 세션처리
세션 처리는 Web Farm 에서 가장 어려운 작업 중 하나입니다.
InProc : InProc 세션 모드에서 세션 데이터는 작업자 프로세스의 메모리 내에 개체 안에 저장됩니다. 각 서버에는 자체 작업자 프로세스가 있으며 메모리 내부에 세션 데이터를 보관합니다.
한 서버가 다운되고 요청이 다른 서버로 이동하면 사용자는 세션 데이터를 얻을 수 없습니다. 따라서 Web Farms 에서는 InProc 을 사용하지 않는 것이 좋습니다. 😡😡😡😡
StateServer : state server 가 무엇인지, state server 를 구성하는 방법 등에 대해서는 이미 설명했습니다. Web Farm 시나리오의 경우 모든 Session Data 가 하나의 위치에 저장되기 때문에 이것이 얼마나 중요한지 쉽게 이해할 수 있습니다.
.
Web Farm 에서는 <machinekey> 모든 웹 서버에 동일한 항목이 있는지 확인해야 합니다. 다른 사항은 앞서 설명한 것과 동일합니다. 모든 web.config (stateConnectionString) 파일은 세션 상태에 대해 동일한 구성을 갖습니다 .
🎵🎵🎵 정리하자면
- machinekey 값을 모든 웹서버에 동일하게 기재해야 합니다.
- stateConnectionString 연결자도 모든 웹서버에 동일하게 기재해야 합니다.
SQL Server : 이것은 Web Farm 에서 사용할 수 있는 최상의 또 다른 접근 방식입니다. 먼저 💡💡💡 데이터베이스를 구성해야 합니다. 필요한 단계에 대해 설명했습니다.
위의 그림과 같이 모든 웹 서버 세션 데이터는 하나의 SQL Server 데이터베이스에 저장됩니다. 그리고 이는 쉽게 접근할 수 있습니다.
🎉🎉🎉🎉 StateServer 및 SQLServer 모드 모두에서 개체를 직렬화해야 한다는 점을 명심해야 합니다.
만약에 웹 서버 중 하나가 다운되면 로드 밸런서가 로드를 다른 서버로 분산하고 세션의 데이터가 중앙 데이터베이스 서버에 저장되기 때문에 사용자는 여전히 서버에서 세션 데이터를 읽을 수 있습니다.
요약하면 Web Farm 에서 StateServer 또는 SQLServer 세션 모드를 사용할 수 있습니다. InProc을 피해야 합니다.
Session 과 Cookies
클라이언트는 Session 작업을 위해 Cookie 를 사용합니다. 클라이언트는 각 요청에 적절한 세션 ID를 제시해야 하기 때문입니다. 다음과 같은 방법으로 이를 수행할 수 있습니다.
cookies 사용
ASP.NET_SessionIdASP.NET은 세션 컬렉션이 사용될 때 자동으로 이름이 지정된 특수 쿠키를 만듭니다 . 이것이 기본값입니다. 세션 ID는 해당 쿠키를 통해 전송됩니다.
Cookie Munging
일부 오래된 브라우저는 쿠키를 지원하지 않거나 사용자가 브라우저에서 쿠키를 비활성화할 수 있습니다. 이 경우 ASP.NET은 특수하게 수정된(또는 "폐쇄된") URL로 세션 ID를 전송합니다.
Cookie Munging 은 어떻게 작동합니까?
사용자가 서버의 페이지를 요청하면 서버는 세션 ID를 인코딩하고 페이지의 모든 HREF 링크에 추가합니다. 사용자가 링크를 클릭하면 ASP.NET은 해당 세션 ID를 디코딩하여 사용자가 요청하는 페이지로 전달합니다. 이제 요청 페이지에서 세션 변수를 검색할 수 있습니다. 이 모든 것은 ASP.NET이 사용자의 브라우저가 쿠키를 지원하지 않는다는 것을 감지하면 자동으로 발생합니다.
Cookie Munging 을 구현하는 방법은 무엇입니까?
이를 위해 Session State 를 Cookie 가 없도록 만들어야 합니다.
세션 삭제하기
다음은 세션을 제거하는 데 사용되는 방법 목록입니다.
| 메소드 | 설명 |
| Session.Remove(strSessionName); | session state collection 에서 항목을 제거합니다. |
| Session.RemoveAll() | session collection 에서 모든 항목을 제거합니다. |
| Session.Clear() | session collection 에서 모든 항목을 제거합니다. 참고: Clear와 RemoveAll 사이에는 차이가 없습니다. RemoveAll()은 내부적으로 Clear()를 호출합니다. |
| Session.Abandon() | 현재 세션을 취소합니다. |
두가지 방법으로 session State 를 활성화 또는 비활성화할 수 있습니다.
- Page level
- Application level
Page Level :
Page 지시문의 EnableSessionState 특성을 사용하여 페이지 수준에서 세션 상태를 비활성화할 수 있습니다.
같은 방법으로 읽기 전용으로 만들 수도 있습니다. 이렇게 하면 세션 데이터에 액세스할 수 있지만 세션에 데이터 쓰기는 허용되지 않습니다.
Application Level :
Web.Config 의 enableSessionState 속성을 사용하여 전체 웹 응용 프로그램에 대해 Session state 를 비활성화할 수 있습니다.
일반적으로, 일부 페이지는 세션 데이터가 필요하지 않거나 세션 데이터만 읽을 수 있기 때문에 page level 을 사용합니다.
요약
이제 Session, 설정 및 사용 방법, Web Farm 에 적용하는 방법 등에 대해 잘 알고 계시기를 바랍니다. 요약하자면 다음과 같습니다.
- in-process( InProc ) Session provider 는 모든 것이 메모리 내부에 저장되기 때문에 가장 빠릅니다. 웹 서버를 다시 시작하거나 worker process 를 재활용하면 세션 데이터가 손실됩니다. 사용자 수가 적은 소규모 웹 애플리케이션에서 사용할 수 있습니다. Web Farm 에서 InProc을 사용하지 마십시오.
- StateServer Session provider 에서 세션 데이터는 aspnet_state.exe 에 의해 유지 됩니다. 웹 서버에서 세션 데이터를 유지합니다. 따라서 웹 서버의 문제는 세션 데이터에 영향을 미치지 않습니다. StateServer 세션에 데이터를 저장하기 전에 객체를 직렬화해야 합니다. Web Farm 에서 안전하게 사용할 수 있습니다.
- SQLServer Session provider 는 SQL Server에 데이터를 저장합니다. 연결 문자열을 제공해야 합니다. 여기에서도 데이터를 세션에 저장하기 전에 직렬화해야 합니다. 이는 Web Farm 이 있는 Production 환경에서 매우 유용합니다.
- custom data sources 에 대해 또는 기존 테이블을 사용하여 세션 데이터를 저장해야 하는 경우 Custom provider를 사용할 수 있습니다 . Custom mode 에서 custom session IDs 를 생성할 수도 있습니다. 그러나 자체의 Custom provider 를 만드는 것은 권장되지 않습니다. third party provider 를 사용하는 것이 좋습니다.
Further study and references
이미 다양한 섹션에 일부를 추가했습니다. 다음은 추가 학습에 실제로 도움이 될 몇 가지 링크를 추가로 제공하는 것입니다.
- ASP.NET Session Overview
- ASP.NET Session State Overview
- Different Session Modes
- Web Farm-Load Balancing in ASP.NET
- Enabling and Disabling Session Mode
- Configuring Session Modes
🎈🎈📢📢📢 Session in ASP.Net webform - 강좌1 바로가기
🎈🎈📢📢📢 Session in ASP.Net webform - 강좌2 바로가기
🎈🎈📢📢📢 Session in ASP.Net webform - 강좌3 바로가기
🎈🎈📢📢📢 Session in ASP.Net webform - 강좌4 바로가기
출처(번역)
Exploring Session in ASP.NET
This article describes Session in ASP.NET 2.0. Different types of Session and their configuration. Also describes Session on Web Farm, Load Balancer, and Web Garden scenarios.
www.codeproject.com
소스
원문 PDF (영문)
'닷넷관련 > ASP.NET WEBFORM' 카테고리의 다른 글
| Session in ASP.Net Webform - 강좌3 (0) | 2022.12.27 |
|---|---|
| Session in ASP.Net Webform - 강좌2 (0) | 2022.12.27 |
| Session in ASP.Net webform - 강좌1 (0) | 2022.12.27 |
| asp.net webform 의 child page 에서 master page 에 접근하여 metadata tag 값 추가하는 방법. (0) | 2019.09.05 |
| asp.net webform 의 HTTP Headers 브라우저 캐시 차단하는 방법 (2) | 2017.09.11 |