초기의 HTTP 버전은 HTTP 통신을 한번 할 때마다 TCP에 의해 연결과 종료를 해야했다.
당시의 통신에서는 작은 사이즈의 텍스트를 보내는 정도였기 때문에 별다른 문제는 없었다.
그러나 HTTP가 널리 보급되어가면서 다량의 이미지를 포함한 문서 등이 늘어나게 됐다.
하나의 HTML에 여러 이미지가 포함되어 있는 경우 브라우저를 사용해서 리퀘스트를 하면 HTML 문서에 포함되어 있는 이미지를 획득하기 위해서 여러 리퀘스트를 송신해야 했다. 매번 리퀘스트를 보낼때마다 TCP 연결과 종료를 반복하게 되니 통신량도 늘어나게 됐다.
지속연결(Persistent Connections)
HTTP/1.1과 일부 HTTP/1.0에서는 TCP연결 문제를 해결하기 위해 지속연결을 고안하였다.
지속연결은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP연결을 계속 유지하는 특징이 있다. 즉 한번의 연결로 여러번의 리퀘스트를 요청하고 리스폰스를 받을 수 있게 되었다.
TCP커넥션의 연결과 종료를 반복하는 오버헤드를 줄이게 되고, 서버에 대한 과부하가 경감되며 리퀘스트/리스폰스가 빠르게 이루어진다는 장점을 갖고 있다.
파이프라인화
지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인(HTTP pipelining)화를 가능하게 한다. 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 그다음 리퀘스트를 송신했던 것을 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 연속적으로 보낼 수 있게 된 것이다.
쿠키
HTTP는 stateless 프로토콜이기 때문에, 과거에 교환했었던 리퀘스트와 리스폰스의 상태를 관리하지 않는다. 과거의 상태를 근거로 해서 현재 리퀘스트를 처리하는게 불가능하다. 이러한 특징들로 서버의 CPU나 메모리같은 리소스의 소비를 줄일수 있는 장점도 있다.
하지만 큰 단점도 존재하게 되는데 어떤 사이트에서 로그인을 한 뒤에 잠시 다른 사이트를 방문했다가 돌아왔을 때 로그인이 유지되지가 않아 불편함을 유발하는 점이다. 이러한 단점을 보완하기 위해 쿠키라는 시스템이 도입됐다.
쿠키는 서버에서 클라이언트로 리퀘스트에 대한 리스폰스를 보낼 때 쿠키를 발행하여 같이 송신한다. 리스폰스를 받은 클라이언트는 리스폰스로 보내진 Set-Cookie라는 헤더필드에 의해 쿠키를 보존하게 된다.
그 다음 재차 통신을 하게 될 때 클라이언트는 리퀘스트에 쿠키를 붙여서 송신하게 되면, 서버에서는 쿠키를 확인해서 어느 클라이언트가 접속했는지 확인하고 서버상의 기록을 확인해 이전 상태를 알 수 있게된다.
1. 리퀘스트메세지(쿠키를 갖고 있지 않은 상태)
GET /reader/HTTP/1.1
Host: www.youngjin.com
- 리스폰스(서버가 쿠키를 발행하여 송신)
HTTP /1.1 2000 OK
DATE : The. 12 Jul 2012 07:12:20 GMT
Server: Apache
<Set-Cookie: sid=1342077140226724; // 내용생략>
- 리퀘스트(보관하고 있던 쿠키를 자동 송신)
GET /image/HTTP/1.1
Host: www.youngjin.com
Cookie: sid=1342077140226724
참고 : 그림으로 배우는 HTTP & Network Basic
참고 : 성공과 실패를 결정하는 1%의 네트워크 원리
