무하프로젝트 ::

2008/09/11 23:11

HTTP 프로토콜

2008/09/11 23:11 in Web Architecture

당분간 제가 올리는 포스트의 모든 내용들은 현재의 신기술이 아니라 이전글과 마찬가지로 대부분의
개발자 분들이 반드시 숙지하여야 하고 꼭 이해하고 넘어가야 하는 부분임에도 불구하고 개발상의 필요성에 의해
쉽게 지나치고 넘어가버리는 웹에 대한 전반적인 아키텍쳐부분을 다룰생각입니다.

이번글은 그런의미에 본다면 이전글보다 먼저 다뤘어야 하는 부분이면서 아키텍쳐상 가장 시초가 되는
글이 될꺼같습니다. 다음 글은 좀더 공부하여 TCP/IP에 대해서도 다뤄봐야 할꺼같습니다.

참고사이트 : http://byhou.sshel.com/tc/byhou/14

1. HTTP란?

HTTP(HyperText Transfer Protocol)프로토콜이란?

즉 WWW 상에서 클라이언트(웹 브라우져) 와 서버(웹서버 HTTP데몬)가 서로 정보를 주고 받을수있는
미리정해진 통신 규약 이라는 뜻입니다.

주로 HTML문서를 주고 받는데 쓰이며 TCP:80번 포트를 사용합니다.
1996 ~ 1999년까지 HTTP 0.9 ~ HTTP1.0 이 발표 되었으며 이후에는 HTTP 1.1이 발표되어
현재까지 널리 쓰이고 있습니다.

정리하자면 HTTP란 클라이언트 와 서버 사이에서 웹의 기본 동작방식(Request/Response)
을 처리하는 프로토콜입니다.

그리고 HTTP 프로토콜은 TCP 상에서 구현된 OSI 7계층의 응용프로그램 레벨 이며
즉, HTTP 의 통신 역시 TCP 통신 상에서 이루어 진다는 것입니다.

일반적인 접근 방법으로는 웹브라우져를 통해서 http:로 시작하는 URL(인터넷 주소)로 접근할수 있습니다.

2. HTTP Version

- HTTP 발전과정

순서 : HTTP 0.9 --> HTTP 1.0 --> HTTP 1.1

HTTP 0.9 : 읽기 전용(이후에는 PUT , DELETE와 같은 요청으로 전송 데이터의 조작이 가능해짐)
GET 요청만 가능했습니다.

HTTP 1.0 : POST , HEAD 가 추가 되었습니다.
즉 클라이언트에서 서버로의 데이터 전송도 가능해 졌습니다.
(POST요청과 달리 GET요청의 경우 파라메터를 통해서 데이터전송(바이너리파일)을 할수
없습니다.)

HTTP 1.1 : PUT , DELETE , TRACE 등 추가 되었습니다.
클라이언트는 서버로의 데이터 전송 뿐만 아니라 변경 , 삭제 까지 가능하게
되었습니다.

* 1.1버전 에서의 가장 중요한 Header값의 추가로는 HTTP Keep Alive 라는것이 있습니다.

     [
         이부분에 대해서는 이전 포스트의 HTTP의 비연결통신에 대해서 보시면 상세하게
        나와 있습니다.
     ]

3. 멱등이란?

멱등이라는 말은 여러가지 의미로 사용됩니다.
HTTP/서블렛 환경에서 이말은 동일 요청이 서버에 어떤 잘못된 결과를 야기하지 않고 두번이상
이루어질 수 있다는 의미 입니다.

[

쉽게 말해서 GET요청은 보통 Redirect와 같은 다른 서버가 이입되지않는 작업을 하기에
두번이상 요청시에도 잘못된 결과를 야기하지 않습니다.

하지만 POST요청과 같은 경우는 보안상의 이점으로 DB서버를 엑세스하는 경우가 보통이므로
두번이상의 요청시에는 잘못된 결과를 야기할수있다는 것입니다.

예>홈페이지 신용카드 결제시 요청이 끝나지 않은 상태에서 사용자가 요청이
다시 들어간다면 중복결제가 될수있는 문제를 야기시킬수 있습니다.

     (사실 개인적인 생각으로는 멱등에 구분의 기준이 난해한것같습니다.
     W3C스펙에서 각 요청에 대한 일반적인 경우를 나누어 이와같이 분류했지만 어느 요청이든
     DB엑세스와 같은 작업이 가능한 것이므로 이렇게 구분을 짓는다는것은 조금은 난해하다고
     생각합니다. -_-;;)

]

4. HTTP 명세서

[1] Request: Client → Server

Request    = Request-Line    ; Section 5.1
*(( general-header    ; Section 4.5
   | request-header ; Section 5.3
   | entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ]    ; Section 4.3

- Request-Line : method

GET : URL로 파라미터 값을 서버로 전달합니다.

GET은 멱등메소드입니다.

--------------------------------------------------------------------------------

HEAD : 표현의 메타데이타만 조회

클라이언트는 HEAD 메소드를 이용하여 전체 표현을 읽지 않고도 리소스가 존재하는지 검사하거나
리소스의 다른 정보를 찾을 수 있다. 즉 Entity-Header만을 돌려줍니다.

--------------------------------------------------------------------------------

OPTIONS : 클라이언트는 OPTIONS 메소드를 이용하여 특정 리소스에 허가된 일을 검사할 수 있다.

--------------------------------------------------------------------------------

POST : GET 요청과 동일하고 차이점으로는 message-body를 포함할 수 있다는 것이다.

--------------------------------------------------------------------------------

TRACE : 이전에 요청한 내용을 들을 것을 요청한다.

--------------------------------------------------------------------------------

CONNECT : 프로시가 사용하는 요청.

--------------------------------------------------------------------------------

DELETE :요청의 경우 삭제 후 응답 body에 상태 메시지 또는 비어있는 body를 돌려준다.

--------------------------------------------------------------------------------

Requset 요청 데이타

** CGI 프로그램은 form1이며 CGI에 전달할 데이터는 srch=srch=dogfish&srvr=Canada
message body 부분이 없음

*** Resouce ID 필드에 CGI 프로그램 이름만 주고 데이터는 message body 부분에 전달

CGI 프로그램은 form1이다.
CGI에 전달할 데이터는 srch=srch=dogfish&srvr=Canada이며 message body에
전달(GET 요청과의 차이점)

[2] Response: Server → Client

Response = Status-Line ; Section 6.1
   *(( general-header    ; Section 4.5
| response-header    ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
   CRLF
   [ message-body ]    ; Section 7.2

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP/1.1 200 OK
Date: Thu, 25 Sep 2008 07:49:09 GMT
Server: Apache
Last-Modified: Thu, 25 Sep 2008 07:43:06 GMT
Content-Length: 6764
Connection: close
Content-Type: text/html; charset=euc-kr

5. ETC

이 부분은 포스트 하지 않아도 되는 부분이지만 혹시 모르시는 분들이 있어서 포스트 합니다.

HTTP 1.1 을 지원하는 브라우저는 기본으로 1.1 을 사용하여 웹 서버와 통신을 합니다.

만일 이전 버전으로 통신하기를 원한다면 아래 옵션을 체크해제 하시면 됩니다. (거의 없을듯 ..-_-;;)

IE기준 :

Posted by 전성균

Trackback 0 Comment 0

2008/09/10 15:17

Asp , Asp.net 웹 리소스 처리방식의 대한 정리 - 2

2008/09/10 15:17 in Web Architecture

이전 포스트의 리소스 처리 글 중에서 조금 아쉬 웠었던 부분중 Client가 HTTP요청후 서버의 응답으로
최종 정적 페이지인 HTML을 응답 받기전 서버에서 어떠한 처리를 하는지에 대해서 이번 시간에는 좀더
구체적으로 알아보려합니다.

1. ASP 처리방식

- 우선 처리방식에 대해 알아보기전 Asp가 어떤 언어인지에 대해서 먼저 알아보도록 하겠습니다.
Asp는 Script 기반 방식의 언어이며 즉 이전의 CGI 언어의 발전된 형태라고 보시면 될꺼같습니다.

이전 포스트의 내용중 웹의 발전과정 부분을 보시면 알수있듯이, 웹어플 구현하기위한 프로그래밍
방식으로는 이전 CGI(C++ , C)방식이 있고 현재 주를 이루고있는 Script방식인 Asp , Asp.net등이
있습니다.

간단히 정리하자면 CGI방식의 개발상의 어려움과 프로세스 관리의 비효율성을 개선한것이 ISAPI필터방식
이고 그 방식으로 웹페이지 자체에 프로그래밍이 가능한 CGI언어로 Asp , Asp.net이 있는것입니다.

********************* 덧붙어서 좋은글이있어서 한글귀 퍼왔습니다. *******************************

   ASP역시 CGI나 ISAPI같은 서버 기술이지만 구현 방법에 있어서 커다란 차이점을 가지고 있습니다.
CGI나 ISAPI 프로그램은 서버내에 존재하는 실행프로그램이지만 ASP는 실행프로그램이 아닌
프로그래밍이 가능하도록 만들어진 웹 페이지인 것입니다.
-----------------------------------------------------------------------------------

   잘이해가 가지않으신다면 이문서부터 한번 보시는것이 좋으실꺼같습니다.

   웹프로그래밍이란?
   http://cafe.naver.com/graphiclove.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=63

   웹 기본동작방식 및 IIS 5.X 웹 리소스 처리 아키텍처..
   http://mohwaproject.tistory.com/entry/웹-리소스-처리-아키텍처

위에 그림에서 볼수있듯이 IIS 5.X기준으로 보자면 inetinfo.exe는 HTTP요청을 받아들인후
   정적/동적컨텐츠를 구분하여 해당 확장자(.asp,.aspx등)와 매핑되어있는 ISAPI Extension 모듈을
   자신의 프로세스 내에 로딩해서 요청을 처리한다.

   즉 html과 같은 정적페이지가 아닌 asp와 같은 동적페이지가 요청된다면 서버는 그것과
   매핑되어있는 ISAPI모듈로 처리한다는것이다. 이것은 위에그림처럼 asp페이지가 client로 부터
   요청된다면 서버의 ISAPI모듈인 asp.dll이 서버스크립트를 해석하여 모든 asp코드들을
정적페이지언어인 html로 변환하고 브라우져를 통해서 사용자에게 전달되는것이다.

2. ASP.net 처리방식

Asp.net 또한 asp와 마찬가지로 언어의 처리방식을 알아보기 전에 asp.net에 대한 기본적인 처리방식을
알아보겠습니다.

asp 와 asp.net의 가장 기본적이면서 가장 큰 차이점으로는 PostBack을 들수있습니다.

간단히 말하자면 기존 asp의 처리방식은 이와 같습니다. -->
(요청페이지 --> 처리모듈 --> 결과페이지)

하지만asp.net 같은 경우는 이렇습니다. -->
(요청페이지 + 처리모듈(코드비하인드) --> 결과페이지)

정리 하면 두 언어의 동작처리 방식에서 오는 차이점 때문에 리소스 처리 방식또한 다르다는
   것을 알아두자.

- 그럼 이제부터 본문으로 들어가서 asp.net의 실제 리소스 처리방식에 대해서 알아볼것이다.

Client로 부터 .aspx 페이지의 HTTP요청이 들어오면 aspnet_isapi.dll 모듈은 직접 컨텐츠를
처리하지않고 실제적으로 처리하는 작업자프로세스인 aspnet_wp.exe에게 전달한후
aspnet_isapi.dll 과 aspnet_wp.exe 사이의 연결은 프로세스 경계를넘어 데이터를 전송하기 위한
Win32 메커니즘인 명명 파이프(프로세스간의통신)를 통해 이루어 진다.

위에 그림에서 보듯이 Start.cs(코드비하인드)파일은 .Net 프레임워크의 System.Page클래스로 부터
상속을 받아 생성되었으며, 이는 초기 컴파일을 통해서 특정 이름의 DLL(그림예:Myproject.dll)로
만들어진후 이를 어셈블리 캐쉬에 저장한다. (이런한 초기 컴파일은 해당 파일이 처음 요청될 경우에만
발생한다.)

만약 해당파일이 어셈블리 캐쉬에 이미 존재한다면(페이지를 한번이상 요청했을경우)캐쉬에서
그 해당 파일을 사용하게 될것이다.

만약 Start.cs라는 파일이 중간에 수정된다면(이미 어셈블리에 캐쉬에 dll로 컴파일되어있는순간)
그럴 경우는 예상대로 어셈블리캐쉬에 있는 해당DLL을 삭제후 초기 컴파일부터 다시 수행하게
될 것이고, 그 결과 DLL을 어셈블리 캐쉬에 다시 올려놓게 될것이다.

- 여기까지가 디자인타임의 끝이고 이 다음부터 런타임부분으로 넘어가게 된다.

런타임 시(클라이언트로부터의 요청 시)는 요청에 의해 UI페이지인 Start.aspx는 코드 비하인드
파일의 *.DLL 을 상속하여 처리후 두번째 컴파일이 발생하게 된다.
이 런타임 컴파일은 CLR 의 JIT컴파일러에 의해 컴파일 되며 Temporary.dll 생성된 원시코드파일을
어셈블리 캐쉬에 올린다. 차후 요청시에는 파일이 수정되지 않는한 어셈블리 캐쉬의 Temporary.dll을
사용하게 된다.

[

위에서 예를 든, MyProject.dll 과 temporary.dll은 가상 명칭이다.
실제로는 ASP.NET에 의해서 이름이 랜덤하게 만들어지게 된다. 나중에 살펴보겠지만 그러한
DLL 들은 다음 경로에서 찾아 볼 수 있다.

- 이 곳이 바로 ASP.NET 을 위한 어셈블리 캐쉬라는 특별한 구역이다.

- C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\Temporary ASP.NET Files
\가상 디렉터리명

]

정리하면, 코드 비하인드 파일은 각 UI 페이지에 프로그래밍 로직을 제공해주는 역할을 하며,
여러 aspx 페이지에서 공유해서 사용될 수도 있다. (Asp.net 2.0(C#의 Partiion 키워드 참조)).

UI 페이지인 aspx 페이지에는 그 어떠한 프로그래밍 코드도 존재하지 않으며, 이는 모두 코드 비하인드
파일로 분리가 되어지고, 코드의 관리와, 유지 보수, 재 사용성을 증가시킨다.

- 경우에 따라서는 코드비하인드 파일을 이용하지 않고 .aspx페이지에 직접처리할수도있다.

이것이 코드 비하인드 이다. 물론, 위와 같은 식으로 클래스를 작성하고, 공유해서 사용하는 경우는 매우
드물 것이다.

각각의 ASP.NET 페이지는 자신만의 기능을 가질 것이고, 두 페이지가 공유해서 어떠한 로직을 가지는
경우는 드물다.
(이와같은 처리방식이 코드비하인드방식이며 asp의 모듈처리방식과 큰 차이가나는 부분이다.)

대부분의 ASP.NET 페이지는 위의 예처럼 하나의 클래스 파일을 공유해서 사용하지 않고, 자신만의
클래스 파일을 가지는 편이다. 하지만, 위의 방법은 이후 조금은 중급적인 코딩 방법에 상당한 도움을 준다.

- 위에 얘기는 헬퍼와 같은 공통 모듈클래스를 뜻한다.

Posted by 전성균

Trackback 0 Comment 0

2008/09/09 21:44

IIS 6.X 웹 리소스 처리 아키텍처

2008/09/09 21:44 in Web Architecture

무하의 2번째 포스트입니다.

이전과 마찬가지로 박종명님의 글을 나름 정리해본것입니다.

이전 포스트에서 정리했었던 IIS 5.x 아키텍쳐에 이어 이번에는 IIS 6.0 아키텍쳐 대해 정리해보겠습니다.
하지만 이전 asp 및 asp.net 처리에 대해 알아본것과는 달리 이번에는 asp.net 처리에 대해서만 정리합니다.
(6.0버전 asp처리에 대한 자료가 아직 없어서 이리저리 찾아보고 정리하여 다시한번 포스트하도록 하겠습니다.)

또 한가지로는 IIS 5.x 리소스 처리 아키텍쳐를 보시면 IIS 6.0과는 달리 아키텍쳐의 시작순서가
커널모드가 아닌 inetinfo.exe(사용자 모드)부터 시작하는것을 볼수있습니다.

이는 IIS 버전별 아키텍쳐상의 차이점이며 그림과같이 실제로도 5.X에서는 커널모드부분이
리소스 처리상 쓰이고 있지 않기 때문에 빠진것입니다.

또한 위의표를 보시면 IIS 버전별로 플랫폼 , 커널모드 , 메타베이스의 변화를 한눈에 알수있습니다.

IIS 5.x 와 6.0의 가장 큰 변화라 할수있는것은 각 모드별 처리방식 및 IIS의 메타베이스를 이진에서
XML기반파일로 관리하여 관리상의 이점을 얻을수있으면 바뀐내용에 관해서는 WAS가 실시간으로
반영한다는 점입니다.

iis 5.x

iis 6.0

1. ASP.net 처리 순서

- 6.0기반 Asp.net이 구동되는 기본 아키텍처는 다음과 같은 Out-Process 모델입니다

- 동작 순서

1. Client의 모든 HTTP요청은 5.x가 IIS 메인프로세서인 inetinfo.exe가 받아들이것과 달리
커널 모드에서 작동하는 http.sys 디바이스 드라이버가 받아 들인다.

http.sys 리스너는 Client 요청을 적절한 응용프로그램 풀 요청 대기열에 배치한다.

[

다수의 웹 응요프로그램들이 하나의 으용프로그램 풀을
사용하더라도 응용프로그램 풀의 요청 대기열은 오직 하나이다.

]

2. 응용프로그램 풀은 woker process(w3wp.exe) 와 가상디렉터리(AppDomain)
   를 구별한다.

[
IIS의 asp.net 아키텍쳐 부분을 보면 하나의 응용프로그램 풀에 하나의 woker process
   가 있고 그 안에 여러개의 AppDomain(가상디렉터리)로 나누어진다.
]

   HTTP 요청을 올바른 woker process로 보내기 위해 http.sys 매퍼가 사용하는 논리 프로세스
(논리적인구조를 관리) 경계에 의해 정의되는 (App Pool Request Queue)구성 개체이다.

3. WAS(Web Admin Service)는 메타베이스와 응용프로그램 풀을 관리하는 중추적인
역활을 담당한다.

   [
   WAS는 workder process를 (생성 , 관리)한다
   ]

5.x와 마찬가지로 IIS 메인프로세서 inetinfo.exe는 공유되지 않는 svchost.exe의
사용자 모드에서 Local System 권한으로 실행된다.

   또한 workder process 의 모니터링 , 리사이클링 등의 관리를 담당한다.

4. IIS 6.0의 메타베이스는 XML 기반의 파일로 관리되며 이 메타베이스의 변경사항을
실시간으로 반영한다.

XML 경로 : C:/WINDOWS/system32/inetsrv/MetaBase.xml

XML 변경예 : 다운로드 제한 AspBufferingLimit="4194304" 4MByte
업로드 제한 AspMaxRequestEntityAllowed="204800" 200KByte

   5. 닷넷 웹 리소스를 처리하기 위한 worker process 는 5.x의 aspnet_wp.exe프로세서를 사용하지않고
w3wp.exe를 사용한다.

- w3wp.exe 는 응용프로그램 풀 대기열(그림 2번에 해당) 로부터 요청을 읽어온다.

- w3wp.exe 는 똫ㄴ asp와 같은 닷넷 이전버전의 웹 리소스도 처리한다.

   6. inetinfo.exe(5,x의 격리모드)에서 호스트 되었던 aspnet_isapi.dll 은 이제 w3wp.exe 라는
worker process 가 로드한다.

   aspnet_isapi.dll 은 CLR 을 로드하고 파이프라인(명명 프로세스 통신)을 시작한다.

7. 기본적으로 모든 활성 웹 응용프로그램들은 하나의 Worker process에서 호스트
   (폴링수준)동작 한다. (asp의 격리수준과 같이 처리할수있다.)

그러나 멀티 CPU를 가진 웹 서버라면 다중 Worker process 가 실행되도록 할 수 있다(웹 가든)
machine.config 파일의 <processModel> 섹션의 webGarden 속성을 true 로 설정하고
cpuMask 속성을 비트 마스크값으로 지정

7-1.

- IIS 5.0 : 단일 머신에 둘 이상의 ASP.NET 작업자 프로세서(aspnet_wp.exe)
(멀티 CPU)

- IIS 6.0 : 하나의 응용프로그램풀이 둘 이상의 작업자 프로세서(w3wp.exe) 로 구성되는 경우

   1. 기본적으로 하나의 응용프로그램 풀은 하나의 worker process 에서 서비스된다.
   그러나 원한다면(성능과 가용성 등을 목적으로) 하나의 응용프로그램풀이 둘
   이상의 worker process 에서 서비스 되도록 구성할수 있다.

이렇게 설정하면 하나의 웹사이트가 둘 이상의 worker process 에서 실행되므로
   성능과 안정성의 이점을 가질 수 있게 된다.

   [
웹 가든에서의 모든 새로운 요청은 사용 가능한 worker process 간에 작업
로드(workload)를 분배하는 데 사용되는 로드밸런싱 기술인 라운드 로빈 스키마에
따라 worker process 에 할당된다.

]

   웹 가든 에서의 상태 관리
   - 하나의 웹사이트가 둘 이상의 worker process 에서 실행되도록 웹 가든을 구성하였다면
Application,Session 과 같은 응용프로그램 상태 값은 공유 되지 않을 것이다.
   이 경우 상태관리를 worker process 가 해서는 곤란하다.

상태 관리를 worker process 에서 분리하여 Out-of-process Session State 또는
SQL Server Session State 에 게로 상태관리를 넘겨야 하나의 웹사이트내의
모든 자원들에서 응용프로그램의 상태가 공유 될 것이다.

웹 가든 구성 시 주의 사항
   - 매우 하는 일이 많은(매우 바쁜) 응용 프로그램 풀에 다수의 worker process
를 할당하면 각 worker process 가 시작될 때 서버 리소스를 사용하기에
   다른 응용 프로그램 풀의 웹

   응용프로그램 성능에 영향을 미칠 수 있다. ( 너무 많은 worker process를
   구현하는것도 성능상에 문제가 될수있다.)