Persistent connection
HTTP 초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP 에 의해 연결을 종료할 필요가 있었다.
초기 통신은 작은 사이즈의 텍스트를 보내는 정도였기 때문에 이렇게 기능을 구현해도 문제가 없었으나, HTTP 가 널리 보급되어 감에 따라 다량의 이미지를 포함한 문서 등이 늘어나게 되었다.
하나의 HTML 에 여러 이미지가 포함되어 있는 경우 브라우저를 사용해서 리퀘스트를 하면 HTML 문서에 포함되어 있는 이미지를 획득하기 위해서 여러 리퀘스트를 송신하게 된다. 이때 리퀘스트를 보낼 때마다 매번 TCP 연결과 종료를 하게 되어 쓸모없는 통신량이 늘어났다.
이러한 문제를 해결하기 위해 HTML 1.1 버전에서는 지속연결(Persistent connection) 이라는 방법을 고안하게 되었다.
지속연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다. 지속 연결을 하는 이점은 TCP 커넥션의 연결과 종료를 반복하는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 경감된다. 또한 오버헤드가 줄어드는 만큼 HTTP 리퀘스트와 리스폰스가 빠르게 완료되기 때문에 웹페이지를 표시하는 속도를 향상시킬 수 있다.
지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인(HTTP pipelining) 화를 가능하게 한다.
파이프라인화에 의해서 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것을, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있다.
Stateless
HTTP 는 Stateless 프로토콜이기 때문에, 과거에 교환했었던 리퀘스트와 리스폰스의 상태를 관리하지 않는다. 따라서 과거 상태를 근거로 해서 현재 리퀘스트를 처리한다는 것은 불가능하다.
예를 들어 인증이 필요한 웹 페이지에서 상태 관리를 하지 않는다면 인증을 마친 상태를 잊어버리기 때문에 새로운 페이지로 이동할 때마다 재차 로그인 정보를 보내든지 리퀘스트마다 매개 변수나 추가 정보를 붙여서 로그인 상태를 관리해야 하는 상황이 발생한다.
물론 Stateless 프로토콜에도 이점은 있다. 상태를 유지하지 않는다는 점에서 서버의 CPU 나 메모리 같은 리소스의 소비를 억제할 수 있다. 또한 단순한 프로토콜이기에 HTTP 가 다양한 곳에서 이용되는 측면도 있다.
Stateless 프로토콜이라는 특징은 남겨둔 채, 이와 같은 문제를 해결하기 위해 쿠키라는 시스템이 도입되었다. 쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다. 쿠키는 서버에서 리스폰스로 보내진 Set-Cookie 라는 헤더 필드에 의해 쿠키를 클라이언트에 저장하게 된다. 그리고 다음 번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때, 자동으로 쿠키값을 넣어서 전달한다. 서버는 클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.
댓글