HTTP 메서드
리퀘스트 URI로 지정한 리소스에 리퀘스트를 보내는 경우에는 메소드라고 불리는 명령이 있습니다.
메서드는 리소스에 어떠한 행동을 하기 원하는지를 지시하기 위해 존재하는데 GET, POST, DELETE 등이 있습니다.
- HTTP/1.0과 HTTP/1.1에서 지원하고 있는 메서드
| 메서드 | 설명 | 제공하고 있는 HTTP 버전 |
|---|---|---|
| GET | 리소스 취득 | 1.0, 1.1 |
| POST | 엔티티 바디 전송 | 1.0, 1.1 |
| PUT | 파일 전송 | 1.0, 1.1 |
| HEAD | 메시지 헤더 취득 | 1.0, 1.1 |
| DELETE | 파일 삭제 | 1.0, 1.1 |
| OPTIONS | 서포트하고 있는 메서드 문의 | 1.1 |
| TRACE | 경로 조사 | 1.1 |
| CONNECT | 프록시에의 터널링 요구 | 1.1 |
| LINK | 리소스 간에 링크 관계를 확립 | 1.0 |
| UNLINK | 링크 관계 삭제 | 1.0 |
지속적인 연결
HTTP 초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결을 종료할 필요가 있었습니다.
초기 당시의 통신에서는 작은 사이즈의 텍스트를 보내는 정도였기에 문제가 없었으나, 후에 다량의 이미지를 포함한 문서가 발생하며 한계에 봉착하였습니다.
그렇기에 리퀘스트를 보낼 때마다 매번 TCP 연결, 종료를 수행하기엔 통신량 낭비가 극심하여,
HTTP/1.1 & 일부의 HTTP/1.0에서는 이러한 문제를 해결하기 위해 지속적 연결(Persistent Connections)이라는 방법을 고안하였습니다.
- 지속적 연결의 이점
- TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주어, 서버에 대한 부하가 경감된다.
- 리퀘스트와 리스폰스 응답이 빠르게 완료되어 웹 페이지를 빠르게 표출할 수 있다.
- 파이프라인화
- 지속 연결은 리스폰스를 기다리지 않고 ---바로 다음 리퀘스트를 보낼 수 있어 파이프라인화를 가능케 합니다.
- 개별 연결보다 지속 연결이 리퀘스트 완료 성능이 뛰어나고, 이는 리퀘스트의 수가 늘어날수록 현저히 나타난다.
쿠키를 사용한 상태 관리
HTTP는 stateless 프로토콜이기에, 과거에 교환했던 상태를 관리하지 않는다.
이는 새로운 페이지로 이동할 때마다 재차 로그인을 해야하는 상황을 야기한다는 점에서 단점을 갖으나,
서버의 CPU나 메모리같은 리소스의 소비를 억제할 수 있다는 장점 또한 갖는다.
이와 같은 문제를 해결하기 위해 "쿠키"라는 시스템이 도입되었다.
쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다.
그러면 다음 번 리퀘스트에서 자동으로 쿠키 값을 넣어 송신하게 되는데, 서버는 쿠키 값을 확인하여 해당 클라이언트의 이전 상태 값을 판별할 수 있다.
