[2장] 간단한 프로토콜 HTTP

• TCP/IP : 인터넷과 관련된 모든 프로토콜들을 모은 것
• HTTP : 클라이언트부터 서버까지의 흐름을 관리하는 프로토콜

2.1 HTTP는 클라이언트와 서버 간에 통신을 한다

HTTP는 한 번 통신할 때 무조건 클라이언트와 서버가 있다.

• 클라이언트 : 리소스 요청(=리퀘스트. request)을 하는 곳
• 서버 : 리소스 요청을 받아 리소스를 제공(=리스폰스. response)하는 곳

2.2 리퀘스트와 리스폰스를 교환하여 성립

반드시 클라이언트에서 리퀘스트를 보내며, 서버에서는 리스폰스가 돌아온다.

무조건 통신은 클라이언트로부터 시작된다.

• 리퀘스트 메시지
  : 클라이언트가 리퀘스트 보내는 양식
  : 메소드, URI, 프로토콜 버전, 옵션 리퀘스트 헤더 필드와 엔티티로 구성

• 리스폰스 메시지
  : 프로토콜 버전, 상태 코드, 프레이즈, 옵션 리스폰스 헤더 필드와 바디로 구성

2.3 HTTP는 상태를 유지하지 않는 프로토콜

HTTP는 스테이트리스(stateless) 프로토콜이다.

• HTTP 프로토콜은 범위성(scalability. 데이터를 빠르고 확실하게 처리)을 위해 리퀘스트나 리스폰스를 따로 관리하지 않는다.
• 단, 누가 어떤 리퀘스트를 보냈는지 기억하기 위해 상태를 유지해야 할 경우, 쿠키(cookie)를 사용한다.

2.4 리퀘스트 URI로 리소스를 식별

HTTP는 URI를 이용해 인터넷 상의 리소스를 지정한다.

• 클라이언트는 리퀘스트에 리퀘스트 URI를 포함해야 한다. 지정방법은 다음과 같다.
  (1) 모든 URI를 리퀘스트 URI에 포함
  (2) Host 헤더 필드에 네트워크 로케이션을 포함
  (3) 서버 자신에게 리퀘스트 보내는 경우, [*] 으로 지정 가능

2.5 서버에 임무를 부여하는 HTTP 메소드

HTTP/1.1에서 사용 가능한 메소드들

(1) GET : 리소스 획득

리퀘스트 URI로 식별된 리소스를 가져오도록 요구. 서버가 해석한 결과를 받아온다.

(2) POST : 엔티티 전송

엔티티 전송에 사용되며, 리스폰스에 의한 엔티티의 획득만이 목적이 아니라는 점에서 GET과 차이

(3) PUT : 파일 전송

리퀘스트 중 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존 (=파일 전송)

• 보안 이슈 : PUT 자체 인증 기능이 없어 누구나 파일 업로드 가능
• 일반 웹사이트에서는 사용 X. 인증기능과 짝을 이루거나 REST방식에서만 사용

(4) HEAD : 메시지 헤더 취득

메시지 바디를 돌려주지 않는 GET. URI 유효성 확인과 리소스 갱신 시각 확인 목적으로 사용

(5) DELETE : 파일 삭제

PUT 메소드와 반대. 리퀘스트 URI로 지정된 리소스의 삭제 요구

• 보안 이슈 : DELETE 자체 인증 기능이 없다
• 일반 웹사이트에서는 사용 X. 인증기능과 짝을 이루거나 REST방식에서만 사용

(6) OPTIONS : 제공하고 있는 메소드의 문의

리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사

(7) TRACE : 경로 조사

웹 서버에 접속, 자신에게 통신을 되돌려 받는 루프백(loop-back) 발생시킨다.
리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 조사할 수 있어 프록시 서버 경유 등 origin 서버 접속 시 리퀘스트가 가공될 때 동작 확인 용으로 사용한다.

단, 보안 이슈가 있기에 보통 사용하지 않는다.

(8) CONNECT : 프록시에 터널링 요구

프록시에 터널 접속 확립을 요하여 TCP 통신을 터널링 시킬 때 사용한다.
암호화 된 것을 터널링시킬 때 주로 사용

2.6 메소드를 사용해서 지시를 내리다

리소스에 어떤 행동을 하기 원하는지 지시하기 위해 존재하며, 메소드는 대소문자를 구별하기 때문에 대문자로 기재해야 한다.

2.7 지속 연결로 접속량을 절약

• 지속 연결 (Persistent Connections)
  : 초기 HTTP에서 발생하는 불필요한 TCP 통신량 문제를 해결하기 위해 고안되었다.
  : 어느 한 쪽이 명시적으로 연결을 종료하지 않는다면 TCP 연결을 계속 유지한다.
  : TCP 커넥션의 오버헤드를 줄임으로써 서버 부하 경감과 웹 페이지의 빠른 표시 구현 가능
  
  

• 파이프라인화 (HTTP pipelining)
  : 지속 연결로 인해, 리스폰스를 기다리지 않고 여러 리퀘스트를 병행해서 보낼 수 있다.
  : 따라서 리퀘스트 수 늘어날 수록 효과 good

2.8 쿠키를 사용한 상태 관리

쿠키는 HTTP의 스테이트리스 특성에 따라 발생하는 문제를 해결한다.

• 문제
  : HTTP는 지난 리퀘스트와 리스폰스를 관리하지 않기에 과거 상태를 기반으로 현재 리퀘스트를 처리할 수 없다.
  : 상태를 유지하지 않음으로써 얻는 리소스 소비의 억제를 포기할 수 없다.

• 해결
  : stateless 프로토콜의 특징은 유지하면서 쿠키 도입

• 쿠키
  : 리퀘스트와 리스폰스에 쿠키 정보를 추가해 클라이언트의 상태를 파악한다.
  (1) 리스폰스 헤더 필드에 포함되어 클라이언트에 보존된다.
  (2) 클라이언트가 다음 리퀘스트를 보낼 때, 자동으로 쿠키를 함께 송신한다.
  (3) 서버는 받은 쿠키를 이용해 어느 클라이언트인지 확인하고, 서버 상의 기록을 이용해 이전 상태를 파악한다.