HTTP 프로토콜

인프런의 김영한님 강의를 보고 정리한 내용입니다.

 

 

먼저, 프로토콜이 뭔데?

 

나무위키에서는 프로토콜을 컴퓨터 또는 전자기기 간의 원활한 통신을 위해 지키기로 약속한 규약

 

통신을 하기 위해서 우편물과 같이 발신 수신 등의 정보와 관련 된 IP와 MAC 주소 등이 필요한데..

 

우편물의 편지와 같은 HTTP에 대해서 알아보자.

---

HTTP(HyperText Transfer Protocol)

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3

HTTP/1.1을 주로 사용한다고 한다.

2와 3도 점점 사용한다.

 

서버간에 데이터를 주고 받을 대도 대부분 HTTP 사용한다.

특징

• 클라이언트 서버구조
  • 클라이언트는 서버에 요청을 보내고, 응답을 대기
  • 서버가 요청에 대한 결과를 만들어서 응답
• 무상태 프로토콜(stateless)
  • 서버가 클라이언트의 상태를 보존하지 않는다.
    • 장점: 서버 확정성 높다(scale out)
    • 단점: 클라이언트가 추가 데이터 전송
  • 저녁 6시 선착순 1000명 치킨 이벤트 => 수만명 동시 요청 
    • 어떻게 처리할까?(대용량 트래픽 처리?)
• 비 연결성(connetcionless)
  • 기본적으로 통신 연결을 유지하지 않는다.
  • 한계
    • TPC/IP 연결을 새로 맺어야함 - 3 way handshake 시간 추가
  • 극복
    • HTTP 지속 연결(Persistent Connections)로 문제 해결

상태유지

예) 로그인

• 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
• 상태 유지는 최소한만 사용

 

HTTP 메세지

General

시작 라인(start line)

HTTP 버전

HTTP 상태코드

• 200: 성공
• 400: 클라이언트 요청 오류
• 500: 서버 내부 오류

헤더(Header)

• HTTP 전송에 필요한 모든 부가 정보
  • 메세지 바디의 내용, 바디의 크기, 압축, 인증, 캐쉬 관리 정보 등등...

바디(Body)

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

 

HTTP Method

URI(Uniform Resource Identifier)

• 리소스?
  • 예) 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
  • 회원이라는 개념 자체가 바로 리소스다.(?)
• 리소스를 어떻게 식별하는게 좋을까?
  • 회원이라는 리소스만 식별하면된다. -> 회원 리소스를 URI에 매핑
• 리소스 식별
  • 회원 목록 조회  /members
  • 회원 등록          /members/{id}
  • 회원 수정          /members/{id}
  • 회원 삭제          /members/{id}

등록, 수정, 삭제를 어떻게 구별할 것인가?

 

• URI는 리소스만 식별
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리
  • 소스: 회원
  • 행위: 조회, 등록, 삭제, 변경
• 리소는 명사, 행위는 동사

 

행위를 구분하는 방법이 HTTP 메서드 이다~!

 

• GET: 리소스 조회
  • 쿼리 파라미터, 쿼리 스트링을 통해서 전달
• POST: 요청 데이터 처리, 등록에 사용
  • 메세지 바디를 통해 서버로 요청 데이터 전달
  • 새 리소스 생성 / 요청 데이터 처리 / 다른 메서드로 처리하기 애매한 경우
  • 예) POST /orders/{orderid}/start-delivery (컨트롤 URI)
• PUT: 리소스를 완전 대체, 해당 리소스가 없으면 생성
  • 클라이언트가 리소스 위치를 알고 URL 지정(POST와 차이점)
  • 기존 데이터를 완전히 수정해버린다.
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

 

HTTP 메서드의 속성

안전(safe)

• 호출해도 리소스를 변경하지 않다.
• GET

멱등(Idempotent)

• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
• GET, PUT, DELETE
• 자동 복구메커니즘
  • 서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가 판단 근거
• 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.

캐시가능(Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음