웹 상에서 클라이언트와 서버간에 요청과 응답으로 정보를 주고 받을 수 있는 프로토콜
✔︎ 주로 HTML 문서를 주고받는데 사용
✔︎ 주로 TCP를 사용하며 80번 포트를 사용한다.
✔︎ 비연결(connectionless): 클라이언트가 요청을 서버에 보내고 서버가 응답을 클라이언트에게 보내면 연결을 끊어진다.
✔︎ 무상태(stateless): 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다.
✔︎ 새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었습니다(Content-Type 덕분에).
✔︎ connection 당 하나의 요청만 처리 → 매번 연결을 새로 생성 → 속도 느림
After(파이프라이닝 적용)요청1 → 응답1 → 요청2 → 응답2 …
요청1에 대한 응답이 되기 전까지 요청2 진행 할 수 없다(비효율적)
요청1 → 요청2 → 응답1 → 응답2 …
속도 향상 but 순차적으로 처리해야 함
HTTP/1.1의 persistent와 pipelining →여러개 요청 처리 가능 but 순차적으로 처리해야함 → HOLB(Head Of Line Blocking)
HOLB(Head of Line Blocking)
여러 요청과 응답들을 병렬적으로 보낸다 → 속도 향상
응답에 대한 우선 순위를 지정하고 우선순위가 높을 수록 응답을 빨리한다.
서버가 클라이언트의 요청이 없어도 필요하게될 특정 파일들을 서버에서 단일 HTTP 요청 응답 시 함께 전송할 수 있다.
Server push X
HTML 요청 → 응답 → css 요청→ 응답 → jpg 요청 → 응답 ….
Server push O
HTML 요청 → 응답(HTML, CSS, JPG)
이전 Header의 내용과 중복되는 필드를 재전송 하지 않도록 하여 데이터를 절약하고 HTTP Header를 문자열 전송 방식에서 HTTP/2에서는 Huffman Coding을 사용하는 HPACK이라는 Header 압축방식을 이용하여 데이터 전송 효율을 높였다.
GET: 리소스 조회
POST: 요청 데이터 처리(주로 데이터 추가)
PUT: 리소스를 수정(update)
PATCH: 리소스를 일부 수정
DELETE: 리소스 삭제
동일한 요청을 여러번 보냈을 때 서버의 상태도 동일하게 남는다.
POST
PATCH
리소스를 부분 수정하는 메서드로서 구현 방법에 제한이 없다.
수정할 데이터를 보내주는 것이 아니라 행위를 명시하여 수정할 수 있다.
기존 리소스 {id : 1, count : 1}
PATCH /users/1 {type : increase}
수정된 리소스 {id : 1, count : 2}
이러한 PATCH 메서드의 경우 같은 요청일지라도 매번 서버의 상태를 변경하게 된다.
✔︎ HEAD
GET과 동일하지만 서버에서 Body를 return 하지 않는다.
✔︎ OPTIONS
웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용.
✔︎ CONNECT
Client가 Proxy를 통해서 Server와 SSL통신을 하고자 할 때 사용된다.
✔︎ TRACE
대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행