1. HTTP 기본 구조(HTTP 1.0 이하)
![](https://t1.daumcdn.net/cfile/tistory/0223434350D7AD4B21)
- 파란 테두리: 첫 번째 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초를 갖는다.
![](https://t1.daumcdn.net/cfile/tistory/1152E13950D7D0E10D)
- IIS 7:
1. Keep-Alive 활성화 설정
![](https://t1.daumcdn.net/cfile/tistory/1223173B50D7D0EE17)
![](https://t1.daumcdn.net/cfile/tistory/27798A3450D7B28E3C)
![](https://t1.daumcdn.net/cfile/tistory/226E133650D7B29C33)
2. Keep-Alive Timeout 정의
- 연결 시간 제한은 기본 120초를 갖는다.
![](https://t1.daumcdn.net/cfile/tistory/2146213850D7D0FB09)
![](https://t1.daumcdn.net/cfile/tistory/23539F3350D7D11332)
4. 웹 서버 HTTP Connection 변화
- Keep-Alive 비활성화 시:
1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)
2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.
![](https://t1.daumcdn.net/cfile/tistory/11464C3850D7D12C0A)
- Keep-Alive 활성화 시:
1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)
- 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초) 시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)
2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)
![](https://t1.daumcdn.net/cfile/tistory/1544DF3950D7D13A22)
5. Wire Shake를 통해 본 Keep-Alive 처리 과정
![](https://t1.daumcdn.net/cfile/tistory/022FD83C50D7C96931)
- 파란 테두리: 첫 번째 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(연결 유지 시간) 종료 시 처리 과정
![](https://t1.daumcdn.net/cfile/tistory/210B213550D7B84518)
- 파란 테두리: 첫 번째 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 과정을 대략적으로 도식화 한 그림 입니다.
![](https://t1.daumcdn.net/cfile/tistory/1176CA444F98E3DD08)
TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.
![](https://t1.daumcdn.net/cfile/tistory/177B64374F98E2132E)
송신 측 호스트(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요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.
![](https://t1.daumcdn.net/cfile/tistory/1741C73C4F98E23222)
위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.
![](https://t1.daumcdn.net/cfile/tistory/20214C354F98E2481B)
페이지의 구성요소(js, css, img 등)이 요청됩니다.
![](https://t1.daumcdn.net/cfile/tistory/144BAA364F98E25C1C)
웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.
![](https://t1.daumcdn.net/cfile/tistory/14097A374F98E26B20)
출저
http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD