TCP/IP 에 있는 다른 많은 프로토콜과 마찬가지로 HTTP 도 클라이언트와 서버 간에 통신을 한다. 텍스트와 이미지 등과 같은 리소스가 필요하다고 요청하는 쪽이 클라이언트가 되고, 이러한 리소스를 제공하는 쪽이 서버가 된다.
HTTP 를 사용하여 2대의 컴퓨터 간에 통신을 하는 경우, 한 번 통신을 할 때마다 반드시 어느 한 쪽은 클라이언트가 되고 다른 한 쪽은 서버가 된다.
경우에 따라서는 2대의 컴퓨터 간에 클라이언트와 서버가 바뀌는 일도 있을 수 있지만, 한 번 통신했을 떄만 본다면 클라이언트와 서버의 역할은 반드시 정해져 있다. HTTP 는 클라이언트와 서버의 역할을 명확하게 구분한다.
HTTP 는 클라이언트로부터 리퀘스트가 송신되며, 그 결과가 서버로부터 리스폰스로 되돌아온다. 즉, 반드시 클라이언트 측으로부터 통신이 시작된다. 서버 측은 리퀘스트를 받지 않고서는 리스폰스를 송신하는 일은 없다.
HTTP 는 상태를 계속 유지하지 않는 스테이트리스(stateless) 프로토콜이다. HTTP 프로토콜은 독자적으로 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않는다. 결국, HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 알지 못한다.
HTTP 에서는 새로운 리퀘스트가 보내질 때마다 새로운 리스폰스가 생성된다. 프로토콜에서는 과거의 리퀘스트나 리스폰스 정보를 전혀 가지고 있지 않다. 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성을 확보하기 위해서 이와 같이 간단하게 설계되어 있는 것이다.
그러나 웹이 진화함에 따라, 스테이트리스 특성만으로는 처리하기 어려운 일이 증가되었다. 예를 들면 쇼핑 사이트에서 로그인했을 때이다. 다른 페이지로 이동하더라도 로그인 상태를 유지할 필요가 있다. 이를 위해서는 누가 어떤 리퀘스트를 보냈는지를 파악하기 위해 상태를 유지해야 한다.
HTTP/1.1 은 상태를 유지하지 않는 프로토콜이다. 그래서 상태를 계속 유지하고 싶은 요구에 부응하기 위해서 쿠키가 도입되었다. 쿠키로 인해 HTTP 를 이용한 통신에서도 상태를 계속 관리할 수 있게 되었다.
HTTP 는 URI 를 사용하여 인터넷 상의 리소스를 지정 한다. 이 URI 가 있는 덕분에 인터넷 상의 어떤 장소에 있는 리소스도 호출할 수 있다.
클라이언트는 리소스를 호출할 때마다 리퀘스트를 송신할 때에 리퀘스트 안에 URI 를 리퀘스트 URI 라고 불리는 형식으로 포함해야 한다. 리퀘스트 URI 를 지정하는 방법은 여러 종류가 있다.
모든 URI 를 리퀘스트 URI 에 포함한다.
GET [<http://hackr.jp/index.htm>](<http://hackr.jp/index.htm>) HTTP/1.1
Host 헤더 필드에 네트워크 로케이션을 포함한다.
GET /index.htm HTTP/1.1
Host: hackr.jp
이것 외에도 특정 리소스가 아닌 서버 자신에게 리퀘스트를 송신하는 경우에는 리퀘스트 URI 에 [*] 을 지정할 수 있다. 아래는 HTTP 서버가 지원하고 있는 메소드를 묻는 예시이다.
OPTIONS * HTTP/1.1