[HTTP 프로토콜 강좌]#29 HTTP 가속 - TCP Multiplexing

오늘이 HTTP 가속 기술의 마지막 시간이다.

HTTP 프로토콜 강좌를 시작한지 약 4개월 정도 된것 같다.
거의 다 왔다. 이번 포스팅과 다음 포스팅까지해서 30개의 강좌를 끝으로 마무리하려 한다.

하지만, 기술은 항상 변하고 또 변한다.
이후 정리할 내용이 더 있다고 생각되면, 포스팅을 멈추진 않을 계획이다.

TCP Multiplexing

강좌 초반 HTTP 기본 동작에 대해 다음과 같이 설명한 바 있다.

"HTTP는 어플리케이션 영역으로 TCP 연결 기반위에서 동작한다"

그럼 단순한 HTTP 메시지 교환의 동작 흐름을 다시 좀 살펴보자.

HTTP 메시지를 전달하기 위해서는 반드시 TCP 세션을 먼저 연결해야 하고, 메시지 교환이 완료되면 TCP 연결을 종료해야 한다.

이런 사용자의 수가 많다고 가정하게 되면.. 본연의 HTTP 요청과 응답을 처리하는 것과 함께 TCP 연결을 맺고 끊는 것을 잘 관리 해야 하는 동작이 필요하다.
TCP 연결 관리에 대한 부담이 사실 웹서버의 성능에 직접적으로 관련되는 요소가 되는 것이다.

TCP 커넥션의 부하를 줄이기 위한 HTTP 프로토콜의 기술이 2가지가 있었다.
기억할 것이다. 그것은 바로

1. Persistence
2. Pipelining

이다.

이에 대한 세부 내용은 여기 를 클릭하여 해당 강좌를 참고하도록 하자.

간단히 이야기 하면..
Persistence 는 TCP 세션의 재사용 기술이고, Pipelining 은 HTTP 트랜잭션들의 순차처리가 아닌 병행처리를 지원하는 기술이다.



위 2가지 기술들을 활용하여 웹서버의 TCP 부하를 획기적으로 줄이는 장비가 있다.
초기에는 이를 "TCP Processor" 라고 칭했으나, 요즘은 ADC 스위치나 웹가속기에 이 기능이 포함되어 있다.

이 장비는 앞서 강의했던 SSL 가속기와 같이 클라이언트와 웹서버 사이에 놓이게 되며, TCP 세션을 중간에서 중개해 주는 일종의 세션 Proxy 같은 역할을 수행하는 형식이다.

그림으로 살펴 보면 아래와 같다.

위와 같이 4명의 클라이언트가 웹서버에 접속한다고 가정한다면..
웹서는 4개의 TCP 세션과 4개의 HTTP 요청을 처리해야 한다.

하지만, 클라이언트와 웹서버 중간에 TCP Processor 역할을 하는 장비가 놓이게 된다면, 웹서버는 1개의 TCP 세션과 4개의 HTTP 요청을 처리하게 된다.
TCP Processor 가 TCP 세션의 부담을 줄여주기 때문이다.

통상 장비마다 동작하는 알고리즘에는 차이가 있을지 모르지만, 궁극적으로 구현하려는 모양은 위와 같다.

최초 접속하는 클라이언트의 TCP 세션을 재활용하는 방식으로 동작하는것이 통상적이긴 하다.



이 기술에는 한가지 유념해야 할 사항이 있다.
위 기술을 이용해서 웹서버의 TCP 세션에 대한 부담을 줄여줄 수는 있으나, TCP 세션을 재활용하기 때문에 한가지 제약사항이 따른다. 바로 클라이언트의 IP가 NAT되는 점이다.

TCP는 IP 기반위에서 동작하는 프로토콜이다. TCP 세션을 재활용하는 것은 IP를 재활용하는 의미와 같다.
따라서 재활용되는 세션상에서 처리되는 클라이언트의 HTTP 요청은 모두 사용자의 IP가 변경된다고 보는게 맞다.

이런 환경에서 사용자의 IP를 구분하기 위해서는 HTTP 헤더의 "X-forwarded-for" 를 사용할 수 있는데, 이에 대해서는 다음 강좌에서 다루기로 한다.

여기까지 해서 HTTP 가속 이란 주제의 강좌를 마무리한다.