웹 서버 상세 처리 과정
1. 정적 페이지 접근 시(HTTP Server)
- 브라우저를 통한 정적 페이지(html, img, js, css, xml등) 접근 시 웹 서버 내부 처리 과정은 아래와 같다.
- Wite Shark를 통해 본 TCP/HTTP 처리 과정
- 파란 테두리: Socket(TCP) 처리 과정을 나타낸다.(TCP 세션 수립)
- 빨간 테두리: HTTP Request/Response 처리 과정을 나타낸다.
1. HTTP Session(논리적 연결) 생성
2. 클라이언트(브라우저) 프로그램안의 Thread가 Client Socket(TCP(임의의 남는 랜덤 포트))을 만들어(생성) 서버 Socket(TCP(80))에 연결을 수행한다.(이때 Client-Socket에는 HTTP 통신 전문(Request-Header 등)에 대한 내용이 포함된다.)
- 이 과정을 통해 TCP 세션 수립(3-way HandShaking)이 완료된다.
- 이 과정을 통해 Client/Server 메시지(데이터 패킷) 교환 준비가 완료된다.
3. "웹 서버"는 요청된 Client-Socket 데이터(HTTP 통신 전문)를 바탕으로 HTTP Request 및 Response를 수행한다.
3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.
4. 서버 Socket Close(웹 서버는 HTTP Response 수행 후 생성된 서버 Socket을 닫는다. 하지만 Socket은 보통 바로 끊어지지 않고 얼마간 Listen(대기) 상태로 유지된다.)
5. 클라이언트 Socket Close 및 브라우저 쓰레드 종료.
6. HTTP Session Close
- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.
2. 동적 페이지 접근 시(HTTP Server + WAS 구성 시)
- 브라우저를 통한 동적 페이지(asp, aspx, php, jsp등) 접근 시 웹 서버 내부 처리 과정은 아래와 같다.
1. HTTP Session(논리적 연결) 생성
2. 클라이언트(브라우저) 프로그램안의 Thread가 Client Socket(TCP(임의의 남는 랜덤 포트))을 만들어(생성) 서버 Socket(TCP(80))에 연결을 수행한다.(이때 Client-Socket에는 HTTP 통신 전문(Request-Header 등)에 대한 내용이 포함된다.)
- 이 과정을 통해 TCP 세션 수립(3-way HandShaking)이 완료된다.
- 이 과정을 통해 Client/Server 메시지(데이터 패킷) 교환 준비가 완료된다.
3. "웹 서버"는 요청된 Client-Socket 데이터(HTTP 통신 전문)를 바탕으로 HTTP Request 및 Response를 수행한다.
3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.
- 이때 요청된 동적 페이지(index.aspx) 처리를 위해 WAS에 요청(구문 해석) 후 그 결과(*.html)를 응답한다.
4. 서버 Socket Close(웹 서버는 HTTP Response 수행 후 생성된 서버 Socket을 닫는다. 하지만 Socket은 보통 바로 끊어지지 않고 얼마간 Listen(대기) 상태로 유지된다.)
5. 클라이언트 Socket Close 및 브라우저 쓰레드 종료.
6. HTTP Session Close
- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.
- IIS는 웹 서버(정적 컨텐츠 처리) + WAS(보통 동적 컨텐츠 처리를 위해 사용)가 결합된 형태를 가진다. 즉, 분리된(웹 서버 + WAS) 형태와는 달리 내부 처리 과정이 다소 상이 할 수 있다. 하지만 기본 계념은 크게 벗어나지 않는다.
- 웹 서버의 주된 역활은 클라이언트/서버간의 HTTP 통신이며, WAS는 비지니스 로직처리가 포함된 동적 페이지 처리에 더 큰 비중을 둔다.(정적 페이지 처리 또한 가능하다.)
3. HTTP Session Close 처리
- 클라이언트 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.(이 과정을 통해 브라우저에 생성된 Memory Cookie도 같이 소멸된다.)
1. 사용자 물리적 접속 종료 이벤트(브라우저 닫기 등)
2. HTTP Session Timeout
- HTTP Session 생성 후 웹 서버에 접근한 클라이언트(사용자)가 서버에 할당된 Session Timeout 시간 까지 아무런 사용자 이벤트(사이트 내부에서 일어나는 모든 행위)를 발생 시키는 않을 경우 웹 서버는 내부적으로 논리적 세션 연결을 끊어버린다.)
3. 웹 서버 재 시작(IIS Restart)
4. *.dll 파일 Re-Build 과정(ASP.NET 기준)
참고 사이트:
web server와 WAS(web application server)
http://pds5.egloos.com/pds/200708/18/42/200703_WAS(Web_Application_Server).pdf
TCP 세션 수립 과정
http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD
HTTP Session 이란?
1. HTTP Session이란?
1. session이란? 서버가 해당 서버(웹)로 접근(request)한 클라이언트(사용자)를 식별하는 방법
2. 서버(웹)는 접근한 클라이언트(사용자)에게 response-header field인 set-cookie 값으로 클라이언트 식별자인 session-id(임의의 긴 문자열)를 발행(응답)한다.
3. 서버로부터 발행(응답)된 session-id는 해당 서버(웹)와 클라이언트(브라우저) 메모리에 저장된다.
이때 클라이언트 메모리에 사용되는 cookie 타입은 세션 종료 시 같이 소멸되는 "Memory cookie"가 사용된다.
4. 서버로부터 발행된 session(데이터)을 통해 개인화(사용자)를 위한 데이터(userInfo 등..)로 활용할 수 있다.
2. HTTP Session 동작 순서
1. 클라이언트(사용자)가 서버로 접속(http 요청)을 시도한다.
2. 서버(웹)는 접근한 클라이언트의 request-header field인 cookie를 확인해 클라이언트가 해당 session-id를 보내왔는지 확인한다.
3. 만약 클라이언트로 부터 발송된 session-id가 없다면, 서버는 session-id를 생성해 클라이언트에게 response-header field인 set-cookie 값으로 session-id(임의의 긴 문자열)를 발행(응답)한다.
* 첫 번째 요청(http) 시 클라이언트로 부터 발송된 session-id 가 없으므로 서버는 session-id를 생성해 클라이언트에게 발행(응답)한다.
* 두 번째 요청(http) 시 클라이언트는 서버로 부터 발행(응답)된 session-id를 request-header cookie 값으로 포함하고 있다.
4. 서버로부터 발행(응답)된 session-id는 해당 서버(웹)와 클라이언트(사용자 브라우저) 메모리에 저장된다.
이때 사용되는 cookie 타입은 세션 종료 시 같이 소멸되는 "memory cookie"가 사용된다.
5. 클라이언트 접속 종료(브라우저 닫기 등..) 시 서버에 저장된 session-id(server resource 소유)는 소멸된다.
3. 각 브라우저 별 Session Life Circle
1. IE(8 기준):
1.1 클라이언트가 첫 번째 요청을 시도한다.
1.2 새로운 탭을 활성화 시킨 후 재 요청을 시도한다.(첫 번째 요청 session-id 값과 동일)
1.3 새로운 창을 활성화 시킨 후 재 요청을 시도한다.
- 아래 그림과 같이 IE(8 기준) 브라우저의 경우 신규 창 활성화 후 재 요청 시 session-id가 변경된 것을 볼 수 있다.(즉, 신규 탭과 달리 신규 창의 경우 서버로 부터 새로운 session(id)을 발급받게 되는 것이다..)
2. Chrome(버전 23.0.1271.97 m)
2.1 클라이언트가 첫 번째 요청을 시도한다.
- Chrome 브라우저와 같은 경우 첫 번째 요청 시 다른 브라우저들의 결과와 달리 response-header의 set-cookie값이 아닌 두 번째 요청의 결과와 같은 request-header의 cookie 값으로 session-id가 포함되어있다.
2.2 새로운 탭을 활성화 시킨 후 재 요청을 시도한다.(첫 번째 요청 session-id 값과 동일)
2.3 새로운 창을 활성화 시킨 후 재 요청을 시도한다.
IE(8 기준) 브라우저와 달리 신규 창 활성화 후 재요청 시에도 기존 session-id는 변하지 않는다.
3. Firefox(버전 17.0.1)
3.1 클라이언트가 첫 번째 요청을 시도한다.
3.2 새로운 탭을 활성화 시킨 후 재 요청을 시도한다.(첫 번째 요청 session-id 값과 동일)
3.3 새로운 창을 활성화 시킨 후 재 요청을 시도한다.
- 신규 창 활성화 후 재요청 시에도 기존 session-id는 변하지 않는다.
4. Safari(버전 5.01)
4.1 클라이언트가 첫 번째 요청을 시도한다.
4.2 새로운 탭을 활성화 시킨 후 재 요청을 시도한다.(첫 번째 요청 session-id 값과 동일)
- Safari 브라우저의 경우 이전 브라우저들의 결과와 달리 request-header cookie값으로 session-id가 포함 되지 않는다.
4.3 새로운 창을 활성화 시킨 후 재 요청을 시도한다.
- 신규 창 활성화 후 재요청 시에도 기존 session-id는 변하지 않는다.
참고 사이트:
http session(위키):
http://en.wikipedia.org/wiki/
http session에 대해서 알아보자:
http://tobewiseys.tistory.com/
http session hijacking:
Cookie, Session 이란:
http://www.lovelgw.com/Blog/243
[Node.js] For문과 비동기 Callback
"JS 비동기 이벤트 실행 순서"로 인해 첫 번째 예제의 타이머 이벤트 callback은 for 문이 종료된 후 실행된다.
즉, 이벤트 큐에 쌓인(Event Loop 감지 후) 이벤트 callback들의 실행 시점은 for문 에서 선언된 i 변수가 증감 후 9가 되어 루프를 빠져나온 시점인 것이다.
1. Client-Side 코드 예제
for (var i = 0; i < 10; i++){
this.setTimeout(function(){
console.log(i); // 10
}, 10);
}
// 아래 나머지 예제들은 문법 상 차이만 존재하며, 의미는 동일하다.
// 즉, 타이머 이벤트나 전달되는 callback에 즉시 실행 함수를 랩핑하여 클로저를 발생시켜 위 문제를 해결한다.
for (var i = 0; i < 10; i++){
// 타이머 이벤트에 즉시 실행 함수를 랩핑.
(function(i){
this.setTimeout(function(){
console.log(i); // 0 ~ 9
}, 10);
})(i);
}
for (var i = 0; i < 10; i++){
// 전달되는 타이머 이벤트의 callback에 즉시 실행 함수를 랩핑.
this.setTimeout((function(i){
return function(){
console.log(i); // 0 ~ 9
}
})(i), 10);
}
2. Server-Side Node.js 코드 예제
- Server-Side Javascript인 Node.js도 위 동작 방식과 동일하다.
for (var i = 0; i < 10; i++){
// setTimeout 타이머와 같이 비동기로 동작한다
process.nextTick(function(){
console.log(i); // 10
});
}
for (var i = 0; i < 10; i++){
// 타이머 이벤트에 즉시 실행 함수를 랩핑.
(function(i){
process.nextTick(function(){
console.log(i); // 0 ~ 9
});
})(i);
}
for (var i = 0; i < 10; i++){
global.setTimeout((function(i){
return function(){
console.log(i); // 0 ~ 9
}
})(i), 10);
}
3.결과
