모든 개발자를 위한 HTTP 웹기본지식 - 김영한님
HTTP (Hyper Text Transfer Protocol)
모든 형태의 데이터를 HTTP 메시지를 통해 주고 받는다. (html, text, json, xml, 음성, 영상, 파일 등등)
HTTP/1.1 버전이 현재 가장 보편적으로 사용중인 버전
HTTP 특징
- 클라이언트 서버 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기하고 서버는 요청에대한 결과를 리턴해준다.
- 분리를 통해 클라이언트는 UI와 사용성에 집중하고, 서버는 비즈니스로직과 데이터에만 집중할 수 있게 만들어준다.
- 트래픽이 폭발하더라도? 클라이언트는 영향없고 백엔드만 수정하면 된다. (분리의 장점)
- 무상태 프로토콜 (Stateless)
- 서버가 클라이언트의 상태를 보존하지 않는다.
- 응답서버를 쉽게 바꿀 수 있다.
- 중간에 서버가 장애나도 아무 서버나 중개해서 응답하면된다.
- 갑자기 증가하는 트래픽에 대비하여 무한한 서버 확장이 가능한 구조이다 (scaleout)
- 상태유지 (stateful)
- 클라이언트가 항상 같은 서버와 통신해야한다.
- 응답 서버가 바뀌면 보존하고 있던 정보를 같이 넘겨줘야한다.
- 중간에 서버가 장애나면 요청부터 다시 시작해야한다.
- 최대한 무상태로 설계하는 것이 좋다.
- 불가능한 경우도 있다. 예를 들면 로그인 기능 (브라우저 쿠키와 서버 세션 등을 사용해서 상태를 보존해야한다.)
- 서버가 클라이언트의 상태를 보존하지 않는다.
- 비연결성
- 서버에서 응답을 보낸 이후에 클라이언트와 연결을 끊는다.
- 연결을 유지하지 않음으로서 서버 자원을 최소한으로 사용할 수 있다.
- 검색 버튼을 누르는 그 순간만 서버자원을 사용한다. (데이터 보내주고 끝)
- 매번 TCP/IP연결 (3 way handshake)을 새로해야하는 점은 한계점
- HTTP 지속 연결을 통해 이 문제도 거의 해결하였다. (HTTP버전이 올라가면서 더 최적화중)
HTTP메시지
시작라인
- 요청 메시지
- HTTP메서드, 요청대상, http버전
- GET /search?q=hello&hl=ko HTTP/1.1
- 응답 메시지
- HTTP버전, HTTP상태코드, 이유문구
- HTTP/1.1 200 OK
HTTP헤더
- HTTP 전송에 필요한 모든 부가정보
- 메시지 바디의 내용정보, 크기, 인증, 브라우저 정보 등등
공백라인
HTTP메시지 바디
- 실제 전송할 데이터
HTTP 메서드
URI를 통해 구분된 리소스의 행위를 구분하는 역할!
클라이언트가 서버에 어떤 것을 요청했을 때 기대하는 행동
GET
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 쿼리 파라미터를 통해서 전달
- 메시지 바디 사용은 가능하지만 권장하지 않음.
POST
- 요청 데이터 처리, 주로 등록에 사용 (
POST는 모든 걸 할 수 있다...) - 메시지 바디를 통해 서버로 요청 데이터 전달
PUT
- 리소스를 대체, 해당 리소스가 없으면 생성
- 데이터를 완전히 덮어씌운다. (UPDATE)
- 클라이언트가 리소스 위치를 알고 URI 지정
PATCH
- 리소스 부분 변경
- key값의 개수가 달라도 일치하는 부분만 변경
DELETE
- 리소스 삭제
HTTP메서드의 속성
안전
- 호출해도 리소스를 변경하지 않는다.
멱등
- 한 번 호출하든 100번 호출하든 결과가 똑같다.
- 서버가 타임아웃 등으로 문제가 생겼을 때, 같은 요청을 계속 해도되는지 판단하는 근거가 된다.
POST는 중복호출하면 중복된 결과가 여러개 생성되어 문제가 될 수 있다..!PUT은 해당 리소스를 완전히 교체해 버리기 때문에 멱등하다.PATCH는 설계에 따라 멱등하지 않을 수도 있다. (전달 받은 데이터로 값을 더하면서 갱신하는 등)
캐시 가능
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
| HTTP 메서드 | 안전 | 멱등 | 캐시가능 |
|---|---|---|---|
GET | 예 | 예 | 예 |
POST | 예 | 아니오 | 예 |
PUT | 예 | 예 | 아니오 |
PATCH | 예 | 아니오 | 예 |
DELETE | 예 | 예 | 아니오 |
HTTP 상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
2XX (Successful) : 요청 정상 처리
3XX (Redirection) : 요청을 완료하려면 추가행동 필요
- 3XX 응답 결과에
Location헤더가 있으면, Location 위치로 자동 이동 - 301, 308 (영구 리다이렉션)
- 301 : 리다이렉트시 요청 메서드가
GET으로 변하고 메시지 바디가 사라질 수 있다. - 308 : 리다이렉트시 요청 메서드와 본문이 유지된다. (요청 메서드도
POST면POST유지)
- 301 : 리다이렉트시 요청 메서드가
- 302, 307, 303 (일시 리다이렉션)
- 302, 303 : 요청 메서드가
GET으로 변경된다. - 307 : 요청 메서드가 유지된다.
- Post / Redirect / Get : 주문 후 화면을 결과 조회화면으로 리다이렉션해서 중복주문이 발생되지 않도록 해준다.
- 302, 303 : 요청 메서드가
- 304
- 캐시를 사용하라고 알려주는 것
- 로컬에 저장된 캐시를 사용할 것이기 때문에 메시지 바디가 응답 메시지에 포함되지 않는다.
4XX (Client Error) : 클라이언트 오류, 잘못된 문법 등
- 요청이 잘못되었기 때문에 재시도는 반드시 실패한다.
5XX (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
- 서버에 문제가 해결되면 재시도시 성공할 수도 있다.
- 비즈니스 로직상 발생되는 에러는 5XX에러를 사용하면 안된다.
- 4XX 혹은 2XX 정상 처리 후 메시지 바디에 오류코드를 담는 방식으로 사용해야한다.
HTTP 헤더
협상
- 클라이언트가 선호하는 표현 요청 (Accept-Language, Accept-Encoding ...)
캐시와 조건부헤더
네트워크를 통해 똑같은 정보를 다시 다운받지 않아도 된다. 속도가 빨라진다.
...
cache-control : max-age = 60
Last-Modified : 2020년 11월 10일 10:00:00
...- 캐시를 60초 동안 저장
- 유효시간 이내에 다시 조회할 경우, 캐시에 저장된 데이터를 사용한다.
- 캐시 유효시간이 초과하면 다시 네트워크로 데이터를 다운받고 캐시를 갱신한다.
- 응답 코드가 304 Not Modified면서, 캐시에 저장된 수정 시간과, 응답헤더의 수정시간이 같다면 유효시간이 초과했어도 그냥 캐시 정보를 쓰면된다. 어차피 똑같은 데이터이기 때문에!
수정시간은 변경되었지만, 의미 없는 변화라서 캐시에 저장된 버전을 그냥 사용하게 하고 싶을 때
- ETag를 서버에 보내서 같으면 유지, 다르면 다시 다운받기 (캐시 제어 로직을 서버에서 완전히 관리)
...
cache-control : max-age = 60
ETag : "v1.0"
...- 캐시를 60초 동안 저장, ETag도 함께 저장
60초 이후 재 요청시
...
if-None-Match : "v1.0"
...변경되지 않았으면 응답
...
HTTP/1.1 304 Not Modified
cache-control : max-age = 60
ETag : "v1.0"
...캐시가 되면 안될 때
...
cache-control : no-cache (원서버 검증 후 사용! 원서버 접근에 실패할 경우, 캐시 서버 설정에 따라 캐시 데이터 반환 가능)
cache-control : must-revalidate (원서버 검증 후 사용! 원서버 접근에 실패할 경우, 반드시 에러)
chche-control : no-store (민감정보 있으므로 저장하지 말 것)
...
꾸준하게!