2장 간단한 프로토콜 HTTP

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

• TCP/IP에 있는 다른 많은 프로토콜과 마찬가지로 HTTP도 클라이언트와 서버간에 통신을 한다
• 리소스를 필요하다고 요구하는쪽이 클라이언트, 제공하는 쪽이 서버가 된다
• HTTP는 클라이언트와 서버의 역할을 명확하게 구별해놨다

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

• HTTP는 클라이언트로부터 리쿼스트가 송신되며, 그 결과가 서버로부터 리스폰스로 되돌아온다
• 반드시 클라이언트 측으로부터 통신이 시작된다.

• 저번 프로젝트에서 서버간 통신을 위해 리쿼스트 리스폰스를 사용해본 경험이 있다

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

• HTTP는 상태를 계속 유지하지 않는 스테이트리스 프로토콜이다.
• 결국 HTTP프로토콜 레벨에서는 이전의 리쿼스트나 리스폰스에 대해서는 전혀 기억하지 않는다.
• 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 법위성을 확보하기 위해서 설계되어있다
• 그래서 상태를 계속 유지하고 싶은 요구에 부응하기 위해 쿠키라는 기술이 도입되었다.

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

• HTTP는 URI를 사용하여 인터넷 상의 리소스를 저정합니다.

리쿼스트 URI를 지정하는 방법

• 모든 URI를 리쿼스트 URI에 포함한다
• Host 헤더 필드에 네트워크 로케이션을 포함한다

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

• GET : 리소스 획득

GET 메소드는 리쿼스트를 URI로 식별된 리소스를 가져올 수 있도록 요구한다.

• POST : 엔티티 전송

POST 메소드는 앤티티를 전송하기 위해 사용된다.

• PUT : 파일 전송

PUT 메소드는 파일을 전송하기 위해서 사용된다.

리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구한다

• HEAD : 메시지 헤더 취득

HEAD 메소드는 GET과 같은 기능이지만 메시지 바디는 돌려주지 않는다

URI 유효성과 리소스 갱신 기간을 확인하는 목적 등으로 사용된다

• DELETE : 파일 삭제
• OPTION : 제공하고있는 메소드 문의
• TRACE : 경로 조사
• CONNECT : 프록시에 터널링 요구

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

초기에는 HTTP통신을 한번 할 떄마다 TCP에 의해 연결과 총료를 할 필요가 있었다.

리퀘스트를 보낼 떄마다 매번 TCP 연결과 종료를 하게 되는 쓸모없는 통신량이 늘어나게 된다.

지속연결

지속연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다

이점 : 서버에 대한 부하가 경감, 리스폰스가 빠르게 완료됨

파이프라인화

지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 한다.

리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있다.

2.8 쿠키를 사용한 상태 관리

HTTP는 과거에 교환했었던 리퀘스트와 리스폰스의 상태를 관리하지 않는다

쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템

쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다.

다음번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키 값을 넣어서 송신