1. HTTP 기본 구조(HTTP 1.0 이하)
- 파란 테두리: 첫 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정
- 빨간 테두리: 두 번째 Socket(TCP) 연결 및 HTTP Request/Response 처리 과정
위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며, 다시 생성 되는 구조이다.
웹 서버 상세 처리 과정:
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 세션 수립과정 이 다시 발생하게 된다.)
출저: http://mohwaproject.tistory.com/entry/Wire-Shake%EB%A5%BC-%ED%86%B5%ED%95%B4-%EB%B3%B8-KeepAlive-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95
TCP 세션 수립 과정
이번 포스트에서는 SSL 동작 방식에 앞서 패킷 교환 방식의 기본인 TCP 3 Way Handshake에 대해서 알아보도록 하겠습니다.
TCP 3 Way Handshake의 정의:
송신 측과 수신 측이 서로 교환할 패킷을 위해 총 3개의 패킷을 주고받으며, 서로에 대한 전송을 보장하는 세션을 수립하는
과정입니다.
아래는 TCP 3 Way Handshake 과정을 대략적으로 도식화 한 그림 입니다.
TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.
송신 측 호스트(211.254.99.210(클라이언트))
수신 측 호스트(203.242.213.203(웹서버))
1. 송신 측은 수신 측과의 통신을 원하고 있음을 알리는 신호로 TCP 헤더의 SYN(Synchoronize) Flag를 활성화(1)하고, 패킷에 일련번호(S/N(seq = 0))를 붙어 상대방에게 알려줍니다.
2. 이때 수신 측은 송신 측 SYN(Synchoronize)Flag 신호에 대한 응답 패킷 생성에 들어가기 위해, ACK(Acknowledgement)Flag를 on 시키고, 송신 측 일련번호(S/N(seq = 0))에 1을 더한 응답(A/N(ack = 1))값과
자신의 일련번호(S/N(seq = 0))를 발송합니다. 또한, 이 과정은 송/수신 측의 양방향 세션이 수립되었음을 의미합니다.
3. 송신 측은 수신 측에게 두 번째 패킷(ack 및 일련번호(S/N(seq = 1) == (수신 측에게 받은 ack = 1 값))에 대한 응답을 주며, 이때부터 양 방향 패킷 교환이 시작되는 것입니다.
아래는 송/수신 간에 패킷 교환이 이루어지는 과정입니다.
송/수신간에 세션 수립(TCP 3 Way Handshake) 과정이 끝난 후 송신 측이 수신 측에게 GET요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.
위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.
페이지의 구성요소(js, css, img 등)이 요청됩니다.
웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.
출저
http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD
'2019년 이전 정리 > Server' 카테고리의 다른 글
| [HTTP] Keep-Alive 기능 (0) | 2014.07.14 |
|---|---|
| L4 로드밸런싱 (0) | 2014.05.19 |
| DTO로 VO를 쓸것인지 Map을 쓸것인지에 대한 고찰 [좋은글 펌] (0) | 2014.01.02 |
| Tomcat 에러 java.lang.UnsupportedClassVersionError (0) | 2013.12.16 |
| 클러스터링 환경 (0) | 2013.12.14 |
