HTTP 기본, HTTP 메서드 정리

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

* 본 포스팅은 인프런 김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식을 들으며 적은 강의노트입니다. *

 

 

HTTP 기본

- 우리가 가장 많이 사용하는 것은 HTTP/1.1 버전, 이 버전이 우리에게 가장 중요한 버전이다.

- HTTP/1.1, 2 버전은 TCP 기반 프로토콜, HTTP/3 버전은 UDP 기반 프로토콜이다.

- 현재는 HTTP/1.1을 주로 사용하고, 2,3 버전 사용도 점점 증가하는 추세다.

 

구글에서 hello 검색 후 개발자 도구를 확인한 창

개발자 도구 창에서 Network로 들어간 다음, 오른쪽 마우스를 클릭해서 protocol 옵션을 활성화하면

다음과 같이 h2, h3 등으로 2 버전, 3 버전 이렇게 표시가 된다는 것을 확인할 수 있다.

 

HTTP 특징

- 클라이언트 서버 구조

- 무상태 프로토콜(스테이스리스), 비연결성

- HTTP 메세지

- 단순함, 확장 가능

 

클라이언트 서버 구조

- Request Response 구조

- 클라이언트는 서버에 요청을 보내고, 응답을 대기

- 서버가 요청에 대한 결과를 만들어서 응답

 

무상태 프로토콜 (Stateless)

- 서버가 클라이언트의 상태를 보존하지 않음

- 장점으로는 서버 확장성이 높다는 것 (스케일 아웃)

- 단점으로는 클라이언트가 추가 데이터를 전송해야 함

 

Stateful과 Stateless의 차이

- Stateful은 서버가 클라이언트의 상태를 유지하는 것, Stateless는 유지하지 않는 것

- Stateful은 서버가 변경되지 않으면 상태를 유지하기 때문에 편리할 수 있으나, 서버가 중간에 바뀌게 되면 상태를 유지한 데이터도 사라지기 때문에 에러가 발생한다.

- Stateless는 서버 변경과 상관없이 클라이언트 측에서 서버가 필요한 데이터를 모두 넘겨주기 때문에 에러가 발생하지 않는다.

- 즉, Stateless (무상태)는 응답 서버를 쉽게 바꿀 수 있어서, 무한한 서버 증설이 가능하다.

 

 

Stateful 방식

Stateless 방식

Stateless의 스케일 아웃 방식

 

Stateless 실무 한계

- 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.

- 무상태 예시 : 로그인이 필요 없는 단순한 서비스 소개 화면

- 상태 유지 예시 : 로그인

- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

- 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지

- 상태유지는 최소한만 사용해야 한다.

 

 

비연결성 (Connectionless)

- HTTP는 기본이 연결을 유지하지 않는 모델

- 일반적으로 초 단위 이하의 빠른 속도로 응답

- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음

예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.

- 서버 자원을 매우 효율적으로 사용할 수 있음

 

비연결성의 한계와 극복

- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가

- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수많은 자원이 함께 다운로드

- 지금은 HTTP 지속 연결(Persistent Connection)로 문제 해결

- HTTP/2, HTTP/3 에서 더 많은 최적화

 

HTTP 메세지

HTTP 요청 / 응답 메세지 형태

HTTP 시작 라인

- 요청 메세지 (HTTP 메서드, 요청 대상, HTTP 버전)

- 응답 메세지 (HTTP 버전, HTTP 상태 코드, 이유 문구)

 

HTTP 헤더의 용도

- HTTP 전송에 필요한 모든 부가정보 (body의 내용, body의 크기, 압축, 요청 클라이언트 정보, 서버 어플 정보, 캐시 관리 정보 등)

- 표준 헤더가 너무 많음

- 필요시 임의 헤더 추가 가능함

 

HTTP 바디의 용도

- 실제 전송할 데이터

- HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능

---

HTTP 메서드

 

API URI 설계의 좋지 않은 예시

API URI 설계의 포인트

리소스 식별에 따른 API URI 설계 예시

HTTP 메서드 종류

대표적인 메서드

- GET : 리소스 조회

- POST : 요청 데이터 처리, 주로 등록에 사용함

- PUT : 리소스를 대체, 해당 리소스가 없으면 생성

- PATCH : 리소스 부분 변경

- DELETE : 리소스 삭제

 

기타 메서드

- HEAD : GET과 동일하지만, 메세지 부분을 제외하고 상태 줄과 헤더만 반환한다

- OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명 

- CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정

- TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행

 

HTTP GET 방식

HTTP POST 방식

POST 방식을 사용해야 하는 경우

HTTP PUT 방식

HTTP PATCH 방식

HTTP DELETE 방식

 

HTTP 메서드 속성

안전(Safe Methods)

- 호출을 해도 리소스를 변경하지 않는 것을 안전하다고 표현한다.

- 로그는 안전에 고려되지 않는다. 안전은 해당 리소스만 고려한다.

 

멱등(Idempotent)

- 한 번 호출하든 백 번 호출하든 결과가 똑같다.

- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.

- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. 

- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

- POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

- 서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시해도 되는지 판단근거가 된다.

 

캐시가능(Cacheable)

- GET, HEAD, POST, PATCH 캐시 가능

- 실제로는 GET, HEAD 정도만 캐시로 사용함

- POST, PATCH는 본문의 내용까지 캐시 키로 고려해야 해서 구현이 쉽지 않음