HTTP 프로토콜
HTTP의 클라이언트-서버 통신
TCP/IP에 다른 프로토콜과 마찬가지로 HTTP도 클라이언트와 서버간에 통신을 합니다.
텍스트나 이미지등을 요청하는 쪽이 클라이언트가 되며, 이런 리소스를 제공하는 쪽이 서버가 됩니다.
리퀘스트와 리스폰스를 교환하여 통신
클라이언트를 리퀘스트를 송신하게 됩니다.
리퀘스트를 받은 서버는 리스폰스를 클라이언트에게 돌려줍니다.
서버측은 리퀘스트를 받지않고서 리스폰스를 송신하는 일이 없습니다.
HTTP는 상태유지를 하지 않는다.
HTTP는 상태를 계속 유지하지 않는 Stateless 프로토콜 입니다.
즉 클라이언트,서버 모두 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.
새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성됩니다.
이는 많은 데이터를 빠르고 확실하게 처리하는 범위성(Scalability)을 확보하기 위해서 이와같이 간단하게 설계되어 있는 것 입니다.
하지만 상태를 유지하고 싶으면 어떻게 할까요? 그럴때를 위하여 쿠키(Cookie)라는 기술이 도입되었습니다
쿠키란?
쿠키는 리퀘스트와 리스폰스에 쿠키정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템입니다.
클라이언트가 같은 서버로 리퀘스트 보낼때 자동으로 쿠키값을 넣어서 송신합니다.
서버는 클라이언트가 보낸 쿠키를 화깅ㄴ하여 어느 클라이언트가 접속했는지 체크하고 서버상에 기록으로 이전 상태를 알 수 있습니다.
리퀘스트 URI로 리소스를 식별
HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정합니다. URI에 관해서는 이전 포스트에 설명되어 있습니다.
메소드를 이용하여 지시를 내린다.
서버에 기능에 관련하여 임무를 부여하거나 지시를 내릴수 있습니다.
메소드는 리소스에 어떠한 행동을 하기 원하는지를 지시하기 위해 존재하며 GET, POST, HEAD등이 있습니다.
HTTP 메소드에 대해서는 다음포스트에서 자세히 설명할 예정입니다.
지속 연결로 접속량을 절약
HTTP초기 버전에서는 통신할때마다 TCP에 의해 연결 및 종료를 할 필요가 있어서 트래픽이 많았었습니다.
이런 문제를 해결하기 위하여 이후에는 TCP연결 문제를 해결하기 위하여 지속연결(Persistent Connections)이라는 방법을 고안하였습니다.
이 지속연결의 특징은 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지합니다.
파이프라인화
지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인 (HTTP pipelining)화를 가능하게 합니다.
리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤 리퀘스트를 발행하던 것을, 파이프라인화에 의해서 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있게 되었습니다.
예를 들면, HTML 한페이지에서 10개의 이미지를 포함한 웹 페이지를 리퀘스트 할 경우에는 개별 연결보다 지속 연결이 리퀘스트 완료가 더 빠르고, 게다가 지속 연결보다 파이프라인화 쪽이 빠릅니다. 리퀘스트가 늘어날 수록 현저하게 차이납니다.