무하프로젝트

Wire Shake를 통해 본 Keep-Alive 처리 과정

1. HTTP 기본 구조(HTTP 1.0 이하)

- 파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

- 빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며, 다시 생성 되는 구조이다.

웹 서버 상세 처리 과정:

http://mohwaproject.tistory.com/entry/%EC%A0%95%EC%A0%81%EB%8F%99%EC%A0%81-%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95

2. Keep-Alive(HTTP 1.1 이상) 기능 이란?

위 HTTP 기본 구조를 바탕으로 맷어진 Socket 연결이 종료된 시점(HTTP Response 이후)부터 웹 서버에 정의된 Keep-Alive Timeout 까지 기존 연결(Socket)을 유지하는 기능.

즉, 정의된 시간(Keep-Alive Timeout) 내에 새로운 HTTP 요청이 발생한다면? 맷어진 Socket 연결을 지속적으로 유지할 수 있다.(앞서 말한바와 같이 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다.)

- IIS 테스트 결과 정의된 시간의 50% 이상 일찍 끊어진다.(120초 / 2)

3. IIS(6 / 7) Keep-Alive 설정 방법

- IIS 6: 

1. Keep-Alive 활성화 설정 및 Keep-Alive Timeout 정의

- 연결 시간 제한은 기본 120초를 갖는다.

- IIS 7:

1. Keep-Alive 활성화 설정

2. Keep-Alive Timeout 정의

- 연결 시간 제한은 기본 120초를 갖는다.

4. 웹 서버 HTTP Connection 변화

- Keep-Alive 비활성화 시:

1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)

2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.

- Keep-Alive 활성화 시:

1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)

- 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초)  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)

2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)

5.  Wire Shake를 통해 본 Keep-Alive 처리 과정

- 파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

- 빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)

- Keep-Alive 처리 과정

1. HTTP Session(논리적 연결) 생성

2. 정의된 Keep-Alive Timeout 내에 새로운 HTTP 요청이 발생할 경우, 새로운 Socket을 재 생성하는 것이 아닌 활성화 된 Keep-Alive 기능을 통해 유지된 Socket 연결에 Request하게 된다.

즉, Socket 연결에 필요한 모든 비용이 감소하게 되며, 그에 따라 전체적인 성능도 좋아지게 된다.

3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.

4. 정의된 Keep-Alive Timeout 동안 맷어진 Socket 연결은 지속적으로 유지된다.

5. HTTP Session Close

- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.

- Keep Alive Timeout(연결 유지 시간) 종료 시 처리 과정

- 파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

- 빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)

- 주황 테두리: Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(정의된 Keep-Alive Timeout(연결 유지 시간) 종료 시  첫 번째 요청과 같이 TCP 세션 수립과정 이 다시 발생하게 된다.)

TCP 세션 수립 과정

http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD

HTTP 1.1 Keep-Alive 기능에 대해

http://pungjoo.tistory.com/2

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

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/Session_(computer_science)

http session에 대해서 알아보자:

http://tobewiseys.tistory.com/72

http session hijacking:

http://www.iamcorean.net/145

Cookie, Session 이란:

http://www.lovelgw.com/Blog/243