Web.config 자세한 설명 + asp.net 최적화
저자：Eve Cole
업데이트 시간：2009-07-01 16:44:14
1. Web.config 파일 이해
Web.config 파일은 asp.NET 웹 애플리케이션의 구성 정보(예: asp.NET 웹 애플리케이션 설정에 가장 일반적으로 사용되는 인증 방법)를 저장하는 데 사용되는 XML 텍스트 파일입니다. 디렉토리의 응용 프로그램 단계입니다. .NET을 통해 새 웹 응용 프로그램을 만들면 기본 구성 설정을 포함하여 기본 Web.config 파일이 루트 디렉터리에 자동으로 생성되고 모든 하위 디렉터리는 해당 구성 설정을 상속합니다. 하위 디렉터리의 구성 설정을 수정하려는 경우 하위 디렉터리에 새 Web.config 파일을 만들 수 있습니다. 상위 디렉터리에서 상속된 구성 정보 외에 구성 정보를 제공할 수 있으며 상위 디렉터리에 정의된 설정을 재정의하거나 수정할 수도 있습니다.
(1).Web.Config는 xml 파일 사양으로 저장되며 구성 파일은 다음과 같은 형식으로 구분됩니다.
1. 구성 섹션 핸들러 선언 특성: 구성 파일의 상단에 위치하며 <configSections> 태그에 포함되어 있습니다.
2. 특정 애플리케이션 구성 기능: <appSetting>에 있습니다. 애플리케이션에 대한 전역 상수 설정과 같은 정보를 정의할 수 있습니다.
3. 구성 섹션 설정 기능: <system.Web> 섹션에 있으며 asp.net 런타임의 동작을 제어합니다.
4. 구성 섹션 그룹의 기능: <sectionGroup> 태그를 사용하면 그룹화를 사용자 정의하고 <configSections> 내부 또는 다른 <sectionGroup> 태그 내부에 배치할 수 있습니다.
(2) 구성 섹션의 각 섹션.
1.<configuration> 섹션 루트 요소, 다른 섹션이 그 안에 있습니다.
2. <appSetting> 섹션 이 섹션은 애플리케이션 설정을 정의하는 데 사용됩니다. 일부 불확실한 설정의 경우 사용자는 실제 상황에 따라 자체 사용법을 설정할 수도 있습니다.
I.<앱 설정>
<add key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/>
<앱 설정>
연결 문자열 상수가 정의되어 있으며, 프로그램 코드를 수정하지 않고도 연결 문자열을 실제 응용 프로그램에서 수정할 수 있습니다.
II.<앱 설정>
<add key="ErrPage" value="Error.aspx"/><appSettings>는 오류 리디렉션 페이지를 정의합니다.
3.<컴파일> 섹션 형식:
<편집
defaultLanguage="c#"
디버그="참"
/>
I.기본 언어: 배경 코드 언어를 정의합니다. C#과 vb.net의 두 가지 언어를 선택할 수 있습니다.
IIdebug: true인 경우 aspx 디버깅이 시작되고 false인 경우 aspx 디버깅이 시작되지 않으므로 실행 중인 애플리케이션의 성능이 향상됩니다. 일반적으로 프로그래머들은 개발할 때 true로 설정하고 고객에게 넘겨줄 때 false로 설정합니다.
4.<customErrors> 섹션 형식:
<맞춤 오류
모드="원격만"
defaultRedirect="error.aspx"
<error statusCode="440" 리디렉션="err440page.aspx"/>
<error statusCode="500" 리디렉션="err500Page.aspx"/>
/>
I.mode: On, Off, RemoteOnly의 3가지 상태가 있습니다. On은 사용자 정의된 정보가 항상 표시됨을 의미하고, Off는 자세한 asp.net 오류 정보가 항상 표시됨을 의미하며, RemoteOnly는 로컬 웹 서버에서 실행되지 않는 사용자에게만 사용자 정의된 정보가 표시된다는 것을 의미합니다.
II.defaultRedirect: 오류 발생 시 리디렉션에 사용되는 URL 주소입니다.
III.statusCode: 특정 오류 상태를 나타내는 오류 상태 코드를 나타냅니다.
IV. 리디렉션: 리디렉션된 URL에 오류가 있습니다.
5.<세계화> 섹션 형식:
<세계화
requestEncoding="utf-8"
responseEncoding="utf-8"
fileEncoding="utf-8"
/>
I.requestEncoding: 들어오는 각 요청의 인코딩을 확인하는 데 사용됩니다.
II.responseEncoding: 다시 전송된 응답의 콘텐츠 인코딩을 확인하는 데 사용됩니다.
III.fileEncoding: aspx, asax 및 기타 파일 구문 분석에 대한 기본 인코딩을 확인하는 데 사용됩니다.
6.<sessionState> 섹션 형식:
<세션상태
모드="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="데이터 소스=127.0.0.1;Trusted_Connection=yes"
쿠키가 없음="거짓"
시간 초과="20"
/>
I.mode: off, Inproc, StateServer, SqlServer 상태로 구분
mode = InProc은 프로세스에 저장됩니다. 특징: 최고의 성능과 가장 빠른 속도를 갖지만 여러 서버에서 공유할 수 없습니다. mode = "StateServer"는 상태 서버에 저장됩니다. 서버, 이 방법을 사용하십시오. 그러나 정보는 상태 서버에 저장됩니다. 상태 서버가 실패하면 정보가 손실됩니다. Mode="SqlServer"는 SQL 서버에 저장됩니다. 특징: 작업 부하가 커지지만 정보는 손실되지 않습니다.
II. stateConnectionString: asp.net 응용 프로그램이 원격 세션 상태를 저장하는 서버 이름을 지정합니다. 기본값은 로컬 컴퓨터입니다.
III.sqlConnectionString: 세션 상태 데이터베이스를 사용하는 경우 여기에서 연결 문자열을 설정합니다.
IV. 쿠키 없음: true로 설정하면 쿠키 세션 상태가 고객을 식별하는 데 사용되지 않으며 그렇지 않으면 그 반대가 됩니다.
V. TimeOut: 세션 상태를 저장하는 시간을 정의하는 데 사용됩니다. 시간 제한을 초과하면 세션이 자동으로 종료됩니다.
7.<인증> 섹션 형식:
<인증 모드="양식">
<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" protection="All" timeout="30"/>
</인증>
<인가>
<사용자 거부="?"/>
</인증>
I.Windows: IIS 인증 방법을 사용합니다.
II.Forms: 양식 기반 유효성 검사 사용
III.Passport: Passport 쿠키 확인 모드를 사용합니다.
IV.None: 어떠한 검증 방법도 사용하지 않습니다. 여기에 포함된 Forms 노드 속성의 의미는 다음과 같습니다.
I.이름: 인증을 완료하는 데 사용되는 HTTP 쿠키의 이름을 지정합니다.
II.LoginUrl: 확인이 실패하거나 시간 초과된 경우 리디렉션되는 페이지 URL(일반적으로 사용자가 다시 로그인할 수 있도록 하는 로그인 페이지)입니다.
III.보호: 쿠키 데이터의 보호 방법을 지정합니다.
다음으로 설정 가능: 모두 없음 암호화 검증 4가지 보호 방법
a. 모두는 두 가지 방법으로 데이터를 암호화하고 유효성 확인을 수행하는 것을 의미합니다.
b. 없음은 쿠키가 보호되지 않음을 의미합니다.
c. 암호화는 쿠키 콘텐츠를 암호화하는 것을 의미합니다.
d. 유효성 검사는 쿠키 콘텐츠의 유효성을 확인하는 것을 의미합니다.
IV.TimeOut: 쿠키 만료 시간을 지정합니다.
런타임 시 Web.config 파일에 대한 수정 사항은 서비스를 다시 시작하지 않고도 적용될 수 있습니다(참고: <processModel> 섹션에 대한 예외). 물론 Web.config 파일은 확장 가능합니다. 새로운 구성 매개변수를 사용자 정의하고 구성 섹션 핸들러를 작성하여 이를 처리할 수 있습니다.
web.config 구성 파일(기본 구성 설정)에는 다음 코드가 모두 있어야 합니다.
<구성>
<시스템.웹>
그리고
</system.web>
</구성>
학습 목적으로 다음 예에서는 이 xml 태그를 생략했습니다.
1. <authentication> 섹션의 역할: asp.NET 인증 지원(4가지 유형: Windows, Forms, PassPort 및 None)을 구성합니다. 이 요소는 컴퓨터, 사이트 또는 응용 프로그램 수준에서만 선언할 수 있습니다. <authentication> 요소는 <authorization> 섹션과 함께 사용해야 합니다.
예:
다음 예시는 로그인하지 않은 사용자가 인증이 필요한 웹 페이지에 접속하면 해당 웹 페이지가 자동으로 로그인 웹 페이지로 이동하는 예입니다.
<인증 모드="양식" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</인증>
loginUrl 요소는 로그인 웹페이지의 이름을 나타내고, name은 쿠키 이름을 나타냅니다.
2. <authorization> 섹션의 역할: URL 리소스에 대한 클라이언트 액세스를 제어합니다(예: 익명 사용자의 액세스 허용). 이 요소는 모든 수준(컴퓨터, 사이트, 응용 프로그램, 하위 디렉터리 또는 페이지)에서 선언할 수 있습니다. <authentication> 섹션과 함께 필요합니다.
예: 다음 예에서는 익명 사용자에 대한 액세스를 비활성화합니다.
<인가>
<사용자 거부="?"/>
</인증>
참고: user.identity.name을 사용하여 현재 인증된 사용자 이름을 얻을 수 있습니다. web.Security.FormsAuthentication.RedirectFromLoginPage 메소드를 사용하여 인증된 사용자를 사용자가 방금 요청한 페이지로 리디렉션할 수 있습니다.
3. <compilation> 섹션의 역할: asp.NET에서 사용되는 모든 컴파일 설정을 구성합니다. 기본 디버그 특성은 "True"입니다. 프로그램을 컴파일하고 사용하기 위해 전달한 후에는 False로 설정해야 합니다. 자세한 내용은 Web.config 파일에 설명되어 있으며 여기서는 예제가 생략되었습니다.
4.<맞춤 오류>
역할: asp.NET 애플리케이션에 대한 사용자 정의 오류 메시지에 대한 정보를 제공합니다. xml 웹 서비스에서 발생하는 오류에는 적용되지 않습니다.
예: 오류가 발생하면 사용자 정의 오류 페이지로 이동합니다.
<customErrors defaultRedirect="ErrorPage.aspx" 모드="RemoteOnly">
</customErrors>
defaultRedirect 요소는 사용자 정의된 오류 웹 페이지의 이름을 나타냅니다. 모드 요소는 로컬 웹 서버에서 실행되지 않는 사용자에게 사용자 정의(친숙한) 정보를 표시함을 나타냅니다.
5. <httpRuntime> 섹션의 역할: asp.NET HTTP 런타임 설정을 구성합니다. 이 섹션은 컴퓨터, 사이트, 응용 프로그램 및 하위 디렉터리 수준에서 선언될 수 있습니다.
예: 사용자 업로드 파일의 최대 크기를 4M로, 최대 시간을 60초로, 최대 요청 수를 100으로 제어합니다.
<httpRuntime maxRequestLength="4096"executionTimeout="60" appRequestQueueLimit="100"/>
6. <페이지>
역할: 페이지별 구성 설정(예: 세션 상태 활성화 여부, 보기 상태, 사용자 입력 감지 여부 등)을 식별합니다. <페이지>는 컴퓨터, 사이트, 응용 프로그램 및 하위 디렉터리 수준에서 선언할 수 있습니다.
예: 사용자가 브라우저에 입력한 콘텐츠에 잠재적으로 위험한 데이터가 있는지 탐지하지 않습니다. (참고: 이 항목은 기본적으로 탐지됩니다. 비 탐지를 사용할 경우 사용자 입력을 인코딩하거나 확인해야 합니다.) 클라이언트 페이지가 포스트백될 때 암호화된 보기 상태를 검사하여 클라이언트 측에서 보기 상태가 변조되지 않았는지 확인합니다. (참고: 이 항목은 기본적으로 확인되지 않습니다)
<pages buffer="true" 활성화ViewStateMac="true" verifyRequest="false"/>
7. <세션상태>
기능: 현재 애플리케이션에 대한 세션 상태 설정을 구성합니다(예: 세션 상태 활성화 여부 및 세션 상태 저장 위치 설정).
예:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</sessionState>
메모:
mode="InProc"은 세션 상태를 로컬에 저장한다는 의미입니다(원격 서버나 SAL 서버에 저장하거나 세션 상태를 비활성화하도록 선택할 수도 있음).
cookieless="true"는 사용자의 브라우저가 쿠키를 지원하지 않는 경우 세션 상태를 활성화한다는 의미입니다(기본값은 False입니다).
timeout="20"은 세션이 유휴 상태일 수 있는 시간(분)을 의미합니다.
8. <추적>
기능: 오류가 발생한 위치를 확인하기 위해 주로 프로그램 테스트에 사용되는 asp.NET 추적 서비스를 구성합니다.
예: 다음은 Web.config의 기본 구성입니다.
<trace 활성화="false" requestLimit="10" pageOutput="false" TraceMode="SortByTime" localOnly="true" />
메모:
enabled="false"는 추적을 활성화하지 않음을 의미합니다.
requestLimit="10"은 서버에 저장된 추적 요청 수를 지정합니다.
pageOutput="false"는 추적 유틸리티를 통해서만 추적 출력에 액세스할 수 있음을 의미합니다.
TraceMode="SortByTime"은 추적 정보가 추적이 처리되는 순서대로 표시됨을 나타냅니다.
localOnly="true"는 추적 뷰어(trace.axd)가 호스트 웹 서버에만 사용됨을 의미합니다. 사용자 지정 Web.config 파일 구성 섹션 프로세스는 두 단계로 구분됩니다.
1. 구성 파일 상단의 <configSections> 및 </configSections> 태그 사이에 구성 섹션의 이름과 구성 데이터를 처리하는 .NET Framework 클래스의 이름을 선언합니다.
2. <configSections> 영역 이후에 선언된 섹션에 대한 실제 구성 설정을 수행합니다.
예: 데이터베이스 연결 문자열을 저장할 섹션 생성
<구성>
<config섹션>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<앱 설정>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</app설정>
<시스템.웹>
...
</system.web>
</구성>
Web.config 파일 액세스 ConfigurationSettings.AppSettings 정적 문자열 컬렉션을 사용하여 Web.config 파일에 액세스할 수 있습니다. 예: 위 예에서 설정된 연결 문자열을 가져옵니다. 예를 들어:
보호된 정적 문자열 Isdebug = ConfigurationSettings.AppSettings["debug"]
2. web.config의 세션 구성에 대한 자세한 설명 응용 프로그램의 구성 파일 Web.config를 열면 다음 단락을 찾을 수 있습니다.
< 세션상태
모드="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="데이터 소스=127.0.0.1;Trusted_Connection=yes"
쿠키가 없음="false"
시간 초과="20"
/>
이 섹션에서는 애플리케이션이 세션 정보를 저장하는 방법을 구성합니다. 아래의 다양한 작업은 주로 이 구성에 중점을 둡니다. 먼저 이 구성에 포함된 내용의 의미를 살펴보겠습니다. sessionState 노드의 구문은 다음과 같습니다.
< sessionState mode="Off|InProc|StateServer|SQLServer"
쿠키리스="true|false"
timeout="분"
stateConnectionString="tcpip=서버:포트"
sqlConnectionString="SQL 연결 문자열"
stateNetworkTimeout="초"
/>
필수 속성은 다음과 같습니다. 속성 옵션 설명
모드는 세션 정보를 저장할 위치를 설정합니다.
Ø Off는 세션 기능을 사용하지 않도록 설정됩니다.
Ø InProc은 프로세스에 세션을 저장하도록 설정되어 있으며 이는 asp의 저장 방식입니다.
Ø StateServer는 독립적인 상태 서비스에 세션을 저장하도록 설정됩니다.
Ø SQLServer 설정은 SQL Server에 세션을 저장합니다.
선택적 속성은 다음과 같습니다. 속성 옵션 설명
Ø 클라이언트의 세션 정보가 저장되는 쿠키 없는 세트,
Ø 실제로는 쿠키 없는 모드를 사용합니다.
Ø false 쿠키 모드를 사용하며 기본값입니다.
Ø 시간 초과는 서버가 자동으로 세션 정보를 포기하는 시간(분)을 설정합니다. 기본값은 20분입니다.
stateConnectionString은 상태 서비스에 세션 정보를 저장할 때 사용되는 서버 이름과 포트 번호를 설정합니다(예: "tcpip=127.0.0.1:42424"). 이 속성은 mode 값이 StateServer인 경우 필수입니다.
sqlConnectionString은 SQL Server에 연결할 때 연결 문자열을 설정합니다. 예를 들어 "데이터 원본= localhost; 통합 보안=SSPI; 초기 카탈로그=northwind"입니다. 이 특성은 mode 값이 SQLServer인 경우 필요합니다.
stateNetworkTimeout은 StateServer 모드를 사용하여 세션 상태를 저장할 때 웹 서버와 상태 정보를 저장하는 서버 사이의 TCP/IP 연결이 끊어지기까지의 유휴 시간(초)을 설정합니다. 기본값은 10초입니다.
asp.NET의 클라이언트 세션 상태 저장은 위의 세션 모델 소개에 나와 있습니다. 세션 상태는 클라이언트와 서버라는 두 위치에 저장되어야 함을 알 수 있습니다. 클라이언트는 해당 웹사이트의 SessionID를 저장하는 역할만 담당하며, 다른 세션 정보는 서버 측에 저장됩니다. ASP에서는 클라이언트의 SessionID가 실제로 쿠키 형식으로 저장됩니다. 사용자가 브라우저 설정에서 쿠키를 비활성화하기로 선택한 경우 세션의 편리함을 누릴 수 없으며 특정 웹사이트에 액세스하지 못할 수도 있습니다. 위의 문제를 해결하기 위해 asp.NET에서 클라이언트의 세션 정보 저장 방식은 Cookie와 Cookieless의 두 가지 유형으로 구분됩니다.
asp.NET에서는 기본적으로 클라이언트에 세션 정보를 저장하는 데 쿠키가 계속 사용됩니다. Cookieless를 사용하여 클라이언트에 세션 정보를 저장하려는 경우 방법은 다음과 같습니다.
현재 웹 애플리케이션의 루트 디렉터리를 찾아 Web.Config 파일을 열고 다음 단락을 찾습니다.
< 세션상태
모드="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="데이터 소스=127.0.0.1;Trusted_Connection=yes"
쿠키가 없음="false"
시간 초과="20"
/>
이 단락의 cookieless="false"는 cookieless="true"로 변경됩니다. 이러한 방식으로 클라이언트의 세션 정보는 더 이상 쿠키를 사용하여 저장되지 않고 URL을 통해 저장됩니다. 현재 IE를 닫고 새 IE를 열고 바로 웹 애플리케이션을 다시 방문하면 다음과 유사한 내용이 표시됩니다.
그 중 http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245 )/default.aspx 에서 굵은 글씨로 표시된 것이 클라이언트의 세션 ID이다. 이 정보는 IIS에 의해 자동으로 추가되며 이전의 일반 연결에는 영향을 미치지 않습니다.
asp.NET의 서버측에 세션 상태를 저장하기 위한 준비:
실험적인 현상을 더 잘 경험하려면 SessionState.aspx라는 페이지를 만든 후 <body></body>에 다음 코드를 추가하면 됩니다.
<scriptrunat="서버">
하위 Session_Add(발신자 개체, e As EventArgs)
세션("MySession") = text1.Value
span1.InnerHtml = "세션 데이터가 업데이트되었습니다! < P>세션에 다음이 포함되어 있습니다: < 글꼴 색상=빨간색>" & session("MySession") & "< /font>"
서브 끝
하위 CheckSession(개체로 보낸 사람, eAs EventArgs)
If (Session("MySession")Is Nothing) Then
span1.InnerHtml = "아무것도 없습니다. 세션 데이터가 손실되었습니다!"
또 다른
span1.InnerHtml = "귀하의 세션에는 다음이 포함됩니다: < 글꼴 색상= 빨간색>" & session("MySession").ToString() & "< /font>"
종료 조건
서브 끝
</script>
< formrunat="server"id="Form2">
< inputid="text1"type="text"runat="server"name="text1">
< inputtype="submit"runat="server"OnServerClick="Session_Add"
value="세션 상태에 추가 " id="Submit1"name="Submit1">
< inputtype="submit"runat="server"OnServerClick="CheckSession"
value=" 세션 상태 보기 " id="Submit2"name="Submit2">
< /양식>
< 시간 크기="1">
<fontsize="6"><spanid="span1"runat="서버" />< /font>
SessionState.aspx 페이지를 사용하여 현재 서버에서 세션 정보가 손실되었는지 여부를 테스트할 수 있습니다.
프로세스에 서버 세션 정보 저장 Web.config 파일의 이전 단락으로 돌아가 보겠습니다.
< 세션상태
모드="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="데이터 소스=127.0.0.1;Trusted_Connection=yes"
쿠키가 없음="거짓"
시간 초과="20"
/>
mode 값이 InProc이면 서버가 이 모드를 사용하고 있음을 나타냅니다.
이 방법은 ASP의 이전 모드와 동일합니다. 즉, 서버는 IIS 프로세스에 세션 정보를 저장합니다. IIS를 종료하고 다시 시작하면 이 정보가 손실됩니다. 하지만 이 모드에는 가장 큰 장점도 있는데, 바로 최고의 성능입니다. 모든 세션 정보는 IIS 프로세스에 저장되므로 IIS는 이 정보에 빠르게 액세스할 수 있습니다. 이 모드의 성능은 세션 정보를 프로세스 외부에 저장하거나 세션 정보를 많이 저장하는 것보다 빠릅니다. 이 모드는 asp.NET의 기본 방식이기도 합니다.
좋아요, 이제 실험을 해보겠습니다. 지금 바로 SessionState.aspx 페이지를 열고 몇 가지 문자를 입력하여 세션에 저장하세요. 그런 다음 IIS를 다시 시작하겠습니다. 현재 사이트를 중지하고 다시 시작하는 것이 아니라 IIS에서 로컬 컴퓨터 이름을 가진 노드를 마우스 오른쪽 단추로 클릭하고 IIS 다시 시작을 선택하는 것입니다. (NT4를 사용할 때 IIS를 다시 시작하려면 컴퓨터를 다시 시작해야 했던 것 같습니다. Microsoft는 정말 @#$%^&) SessionState.aspx 페이지로 돌아가서 지금 막 세션 정보를 확인해보면 해당 정보가 나와 있는 것을 알 수 있습니다. 잃어버린.
프로세스 외부에 서버 세션 정보 저장 먼저 관리 도구 -> 서비스를 열고 asp.NET State Service라는 서비스를 찾아 시작합니다. 실제로 이 서비스는 세션 정보를 저장하는 프로세스를 시작합니다. 이 서비스를 시작하면 Windows 작업 관리자->프로세스에서 aspnet_state.exe라는 프로세스를 볼 수 있습니다. 이는 세션 정보를 저장하는 프로세스입니다.
그런 다음 Web.config 파일의 위 단락으로 돌아가서 모드 값을 StateServer로 변경합니다. 파일을 저장한 후 IE를 다시 열고 SessionState.aspx 페이지를 열고 일부 정보를 세션에 저장합니다. 이때, IIS를 다시 시작하고 SessionState.aspx 페이지로 돌아가서 지금 막 세션 정보를 확인해보고 잃어버리지 않았는지 확인해 보겠습니다.
실제로 세션 정보를 프로세스 외부에 저장하는 방식은 해당 정보가 로컬 머신의 프로세스 외부에 저장될 수 있을 뿐만 아니라 다른 서버의 프로세스에도 세션 정보가 저장될 수 있음을 의미합니다. 이때 mode 값을 StateServer로 변경해야 할 뿐만 아니라 stateConnectionString에도 해당 파라미터를 설정해야 합니다. 예를 들어, 계산은 192.168.0.1입니다. IP 주소가 192.168.0.2인 컴퓨터의 프로세스에 세션을 저장하려면 stateConnectionString="tcpip=192.168.0.2:42424"와 같이 설정해야 합니다. 물론 192.168.0.2 컴퓨터에 .NET Framework를 설치하고 asp.NET State Services 서비스를 시작하는 것을 잊지 마십시오.
SQL Server에 서버 세션 정보 저장 먼저 몇 가지 준비 작업을 수행하겠습니다. SQL Server 및 SQL Server 프록시 서비스를 시작합니다. SQL Server에서 InstallSqlState.sql이라는 스크립트 파일을 실행합니다. 이 스크립트 파일은 특별히 세션 정보를 저장하기 위해 SQL Server에 데이터베이스를 생성하고 세션 정보 데이터베이스를 유지 관리하는 SQL Server 에이전트 작업을 생성합니다. 다음 경로에서 해당 파일을 찾을 수 있습니다.
[시스템 드라이브]winntMicrosoft.NETFramework[버전]
그런 다음 쿼리 분석기를 열고 SQL Server에 연결하고 지금 바로 파일을 열고 실행하십시오. 잠시 기다리면 데이터베이스와 작업이 생성됩니다. 이때 Enterprise Manager를 열면 ASPState라는 새 데이터베이스가 추가된 것을 확인할 수 있습니다. 하지만 이 데이터베이스에는 일부 저장 프로시저만 있고 사용자 테이블은 없습니다. 실제로 세션 정보는 tempdb 데이터베이스의 ASPStateTempSessions 테이블에 저장되고, 또 다른 ASPStateTempApplications 테이블은 ASP에 응용 프로그램 개체 정보를 저장합니다. 이 두 테이블도 방금 스크립트에 의해 생성되었습니다. 또한 관리->SQL 서버 에이전트->작업을 확인하여 ASPState_Job_DeleteExpiredSessions라는 추가 작업도 있는지 확인하세요. 이 작업은 실제로 ASPStateTempSessions 테이블에서 만료된 세션 정보를 1분마다 삭제합니다.
다음으로 Web.config 파일로 돌아가서 모드 값을 SQLServer로 수정합니다. 동시에 sqlConnectionString 값도 수정해야 합니다. 형식은 다음과 같습니다.
sqlConnectionString="데이터 소스=localhost; 통합 보안=SSPI;"
데이터 원본은 SQL Server 서버의 IP 주소를 참조합니다. SQL Server와 IIS가 동일한 시스템인 경우 127.0.0.1을 작성하면 됩니다. Integrated Security=SSPI는 Windows 통합 인증을 사용한다는 의미입니다. 이러한 방식으로 데이터베이스에 액세스하면 userid=sa;password=password sex를 사용하는 SQL Server 인증 방법보다 더 나은 보안을 얻을 수 있습니다. . 물론 SQL Server가 다른 컴퓨터에서 실행 중인 경우 Active Directory 도메인을 통해 양쪽에서 인증의 일관성을 유지해야 할 수도 있습니다.
다시한번 실험을 해보겠습니다. SessionState.aspx에 세션 정보를 추가한 다음, 해당 세션 정보가 SQL Server에 이미 존재하는지 확인합니다. 컴퓨터를 다시 시작해도 세션 정보가 손실되지 않습니다. 이제 세션 정보가 어떻게 보이는지 완전히 확인했으며 이는 SQL Server에 저장되어 있습니다. 수행할 수 있는 작업은 성능에 따라 다릅니다.
요약 3. asp.net 양식 인증의 일반 설정
asp.net 양식 인증에 대한 일반 설정:
1: web.config에서 양식 인증을 추가합니다.
<인증 모드="양식">
<forms name="auth" loginUrl="index.aspx" timeout="30"></forms>
</인증>
<인가>
<사용자 거부="?"
</인증>
2: 등록 페이지가 있는 경우 익명 사용자가 등록 페이지를 호출하여 등록할 수 있어야 합니다.
다음 코드는 <configuration><system.web> 사이에 있어야 하며 <system.web>..</system.web> 사이에는 포함되어서는 안 됩니다.
----------------익명 사용자가 userReg.aspx 페이지에 액세스할 수 있음을 나타냅니다.
<위치 경로="userReg.aspx">
<시스템.웹>
<인가>
<사용자 허용="?"
</인증>
</system.web>
</위치>
3. 로그인 성공 후, 인증된 합법적인 사용자가 통과했음을 나타내는 신원 확인 티켓을 생성해야 합니다.
if (로그인 성공)
System.Web.Security.FormsAuthentication.SetAuthCookie(사용자 이름, false);
4. Web.config 파일에 액세스합니다. ConfigurationSettings.AppSettings 정적 문자열 컬렉션을 사용하여 Web.config 파일에 액세스할 수 있습니다. 예: 위 예에서 설정된 연결 문자열을 가져옵니다. 예를 들어:
보호된 정적 문자열 Isdebug = ConfigurationSettings.AppSettings["scon"]
asp.Net 성능 최적화.
(1).세션 상태 저장 방법 선택
Webconfig 파일에서 구성합니다.
<sessionState 모드="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="데이터 소스=127.0.0.1;Trusted_Connection=yes"
cookieless="false" 시간 초과="20"/>
ASP.NET에는 세션 상태 정보를 저장하는 세 가지 방법이 있습니다.
1. 프로세스에 저장됨: 속성 모드 = InProc
특징: 최고의 성능과 가장 빠른 속도를 제공하지만 여러 서버에서 공유할 수 없습니다.
2. 상태 서버에 저장됨: 속성 모드 = "StateServer"
기능: 사용자 세션 정보를 서버 전체에서 유지해야 하는 경우 이 방법을 사용합니다.
하지만 정보는 상태 서버에 저장되며, 상태 서버에 장애가 발생하면 해당 정보는 손실됩니다.
3. SQL Server에 저장됨: 속성 모드="SqlServer"
특징: 작업량은 늘어나지만 정보는 손실되지 않습니다.
한 가지 더:
I. 일부 페이지에는 세션 상태가 필요하지 않으므로 세션 상태를 비활성화할 수 있습니다.
코드는 다음과 같습니다: <%@ Page EnableSessionState="false" %>
II. 페이지가 세션 변수에 액세스해야 하지만 수정이 허용되지 않는 경우 페이지 세션 상태를 읽기 전용으로 설정할 수 있습니다.
코드는 다음과 같습니다: <%@ Page EnableSessionState="false" %>
사용시 특정 상황에 따라 특정 방법을 선택할 수 있습니다.
(2).Page.IsPostBack 사용
Page.IsPostBack은 클라이언트에서 반환되는지 여부를 나타냅니다. 처음 실행하는 경우 해당 값이 반환되지 않습니다.
false인 경우, 페이지의 이벤트가 트리거되거나 페이지가 새로 고쳐지면 Page.IsPostBack 값이 포스트백이므로 true가 됩니다.
일반적으로 사용되는 방법: Page_Load 방법:
개인 무효 Page_Load(객체 전송자,EventArgs e)
{
if(!Page.IsPostBack)
{
....; //페이지를 초기화하는 코드입니다. 이 코드는 페이지가 처음 초기화될 때 실행되고 두 번째로 다시 게시될 때 실행됩니다.
//다시 실행되지 않습니다. 효율성을 향상시킵니다.
}
}
일부 컨트롤은 초기화 후 상태를 유지해야 하기 때문에 IsPostBack을 사용해야 하는 경우가 많습니다.
예: DropDownList, 매번 초기화되면 사용자가 어떤 옵션을 선택하든 기본값으로 초기화됩니다.
(3) 서버 컨트롤을 사용하지 마십시오.
1. 일반적인 정적 표시 정보의 경우 서버 측 컨트롤을 사용하여 표시하지 마십시오. 서버 측 컨트롤은 실행을 위해 서버에 다시 게시되어야 하기 때문입니다.
일반적으로 <DIV>로 표시하면 프로그램 실행의 효율성이 떨어집니다.
서버 측 컨트롤을 사용하는 경우 runat="server"를 제거하면 효율성도 향상됩니다.
2. 서버측 컨트롤의 상태 보기를 비활성화합니다. 일부 컨트롤은 해당 상태를 유지할 필요가 없습니다. EnableViewState=false;
전체 페이지 컨트롤이 상태 보기를 유지할 필요가 없는 경우 전체 페이지의 상태 보기를 false로 설정할 수 있습니다.
코드는 다음과 같습니다: <%@ Page EnableViewState="false"%>
3. Web.Config 파일에서 구성합니다.
asp.NET 세션은 Web.config 또는 Machine.config의 Sessionsstate 요소에서 구성할 수 있습니다.
다음은 Web.config의 설정 예입니다.
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(4) DataGrid를 사용하지 마십시오.
DataGrid가 강력하다는 것은 누구나 알고 있습니다. 그러나 강력하기는 하지만 성능 오버헤드도 증가시킵니다. 일반적으로 다른 컨트롤을 사용합니다: DataList
또는 Repeater 컨트롤을 통해 이를 달성할 수 있으므로 DataGrid를 사용하지 마십시오.
(5).문자열 작업
1. 포장 작업은 효율성이 떨어집니다.
예를 들어 두 개의 코드 조각을 실행합니다.
문자열 테스트="";
for(int i=0;i<10000;i++)
{
테스트 = 테스트 + 나;
}
그리고
문자열 테스트="";
for(int i=0;i<10000;i++)
{
테스트 = 테스트 + i.ToString();
}
아래 코드 조각은 분명히 더 효율적입니다. i는 정수이기 때문에 시스템은 연결하기 전에 먼저 i를 문자열 유형으로 변환해야 합니다.
독자는 이를 자신의 컴퓨터에 복사하여 테스트할 수 있습니다.
2. StringBulider 클래스 사용
문자열 연결을 수행하는 경우: string str = str1 + str2 + ....;
일반적으로 연결이 3개 이상인 경우 문자열 클래스 대신 StringBuilder를 사용하는 것이 가장 좋습니다. 그러면 문자열 개체가 다시 생성되는 것을 방지할 수 있습니다.
성능 손실.
일반적으로 SQL 문을 어셈블할 때 사용됩니다: StringBulider.
독자는 자신의 컴퓨터에서 테스트할 수 있습니다.
3. 가능한 한 적게 사용하십시오:
노력하다
{}
잡다
{}
마지막으로
{}
명령문. 이 명령문의 실행 효율성은 상대적으로 낮습니다.
(6) ADO.Net 활용 최적화
1. 데이터베이스 연결이 열리고 닫힙니다. 연결이 필요할 때 열고, 데이터베이스에 접근한 후에는 즉시 연결을 닫는다.
예를 들어 두 가지 코드 조각을 살펴보겠습니다.
나.
DataSet ds = 새로운 DataSet();
SqlConnection MyConnection = new SqlConnection("서버=localhost; uid=sa; pwd=; 데이터베이스=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //연결 열기
for(int i=0;i<1000;i++) //for 루프는 데이터를 얻기 전에 비즈니스 논리 작업을 시뮬레이션합니다.
{
Thread.Sleep(1000);
}
myAdapter.Fill(ds);
for(int i=0;i<1000;i++) //for 루프는 데이터를 얻은 후 비즈니스 논리 작업을 시뮬레이션합니다.
{
Thread.Sleep(1000);
}
MyConnection.Close(); //연결을 닫습니다.
II.
DataSet ds = 새로운 DataSet();
SqlConnection MyConnection = new SqlConnection("서버=localhost; uid=sa; pwd=; 데이터베이스=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //for 루프는 데이터를 얻기 전에 비즈니스 논리 작업을 시뮬레이션합니다.
{
Thread.Sleep(1000);
}
MyConnection.Open(); //연결 열기
myAdapter.Fill(ds);
MyConnection.Close(); //연결을 닫습니다.
for(int i=0;i<1000;i++) ////for 루프는 데이터를 얻은 후 비즈니스 로직 작업을 시뮬레이션합니다.
{
Thread.Sleep(1000);
}
I 코드보다 디스플레이 II 코드가 훨씬 더 좋습니다. 사용자가 많으면 연결 풀이 가득 찰 가능성이 높습니다. 심한 경우 충돌이 발생할 수 있습니다.
2. 데이터베이스 쿼리
I. SQL 문을 직접 생성합니다. SQL Server는 매번 컴파일을 해야 하기 때문에 성능이 크게 향상되지는 않습니다. 게다가 충분히 안전하지도 않습니다. 쉽게 공격받습니다.
II. 매개변수와 함께 sql 명령을 사용하십시오. 이런 방식으로 SQL Server는 이를 한 번만 컴파일하고 컴파일된 명령을 다른 매개 변수에 재사용할 수 있습니다. 성능이 향상되었습니다.
III. SQL Server 저장 프로시저를 한 번만 사용하면 독립적이고 수정 및 유지 관리가 쉽습니다. 이는 한 번에 여러 번 명령문을 보내는 기능을 완료할 수 있습니다.
흐름. 저장 프로시저가 반드시 명령문보다 효율적이지는 않습니다. 비즈니스 논리가 매우 복잡한 경우 명령문이 저장 프로시저보다 더 효율적인 경우도 있습니다.
(6) 캐시 최적화.
캐시에는 페이지 캐시와 API 캐시의 두 가지 유형이 있습니다.
1. 페이지 캐싱 및 조각 캐싱 사용
<%@ OutputCache Duration="5" VaryByParam="없음"%>
<%@ OutputCache 기간=60 VaryByParam=”TextBox1,TextBox2” %>
참고: 기간은 캐시 만료 시간을 설정하는 것입니다.
VarByParam은 매개변수에 따라 설정이 변경되는지 여부입니다. None이면 모든 매개변수가 동일한 캐시를 사용합니다.
TextBox1을 설정할 때 여러 매개변수가 있는 경우 TextBox1의 다양한 값에 따라 별도로 캐시하고 조합하여 캐시합니다.
2.API 캐시. 애플리케이션에 사용하기 위해
I. 캐시 사용의 예:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II. 다음을 사용할 때 Page.Cache와 HttpContext.Current.Cache의 차이점에 주의하세요.
그들은 동일한 개체를 참조합니다. Page.Cache를 global.asax 또는 자체 클래스에서 사용하는 경우: HttpContext.Current.Cache. 일부 이벤트에서는 HttpRuntime.Cache를 사용합니다.
