HTTP 프로토콜(Hypertext Transfer Protocol)

HTTP : 클라이언트 - 서버 프로토콜. 

- 헤더를 통해 확장가능

 

- 상태를 저장하지 않는 Stateless. 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없음. 

 

- 그래서 상태가 있는 세션은 있음. 각 요청들에 세션을 만들도록 HTTP 쿠키가 추가됨.

 

- 연결이 필수는 아니지만 연결 기반인 TCP표준에 의존.

 

 

HTTP 주요 버전들

HTTP/1.0 (아래 요청, 응답 구성 사진들에 해당)

- 각 요청/응답에 대해 별도의 TCP 연결을 염. 요청이 보내져야 할 때마다 커넥션이 매번 새로 생성.
  응답이 도착한 이후에는 연결을 닫음. (단기 커넥션) 

  단점 : 새로운 연결을 맺는데 시간이 상당, TCP 기반 커넥션 성능은 오직 커넥션이 예열된 상태일 때만 나아진다는 것. 
  여러 요청을 연속해서 보내는 경우에는 단일 TCP 연결을 공유하는 것보다 비효율적

 

- 사람이 메시지를 읽을 수 있음

 

- 새로운 HTTP 헤더의 도움으로 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능 추가

 

- Host 헤더는 없었음.

 

 

 

HTTP/1.1

- 커넥션 재사용 가능. 사용된 커넥션을 다시 열어 시간 절약
  (응답을 한번 보내고 나서 연결을 바로 닫지 않음. 연속적인 요청 사이에 커넥션 유지. 영속적인 커넥션)
  단점 : 유휴 상태일 때도 서버 리소스 소비, 과부하 상태에서는 DoS 공격당할 수 있음. 

 

- 1.1 버전까지만 해도 사람이 메시지를 읽을 수 있음.

 

- HTTP 파이프라이닝 추가. 응답조차 기다리지 않고 연속적인 요청을 보내서 네트워크 지연 줄임. 
  첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두 번째 요청 전송 가능.
   -> 커뮤니케이션 레이턴시 낮춤
   -> GET, HEAD, PUT, DELETE 같은 idempotent 한 method만 가능. 실패가 발생한 경우에는 단순히 파이프라인 콘텐츠를 다시 반복하면 됨. 

 

- 본문은 압축이 되는데 헤더는 압축이 안됨. 

 

- 다중전송(multiplexing)이 불가능. 서버 하나에 연결을 여러개 열어야 함. 

 

- Host 헤더 덕분에 동일 IP 주소에 다른 도메인을 호스트 하는 기능이 서버 코로케이션을 가능케 함. 

 

단기커넥션, 영속적인 커넥션, HTTP 파이프라이닝

 

 

 

HTTP/2.0

- 단일 연결 상에서 메시지 다중 전송 -> 연결을 좀 더 지속되고 효율적으로 유지

 

- 메시지가 프레임 속으로 캡슐화 되어서 직접 읽는게 불가능. 
  이진 구조인 프레임 안으로 임베드돼서 헤더의 압축과 다중화(multiplexing)와 같은 최적화 가능.
 (이진 프레이밍 메커니즘. binary framing mechanism)

 

- 병렬 요청이 동일한 커넥션 상에서 이루어질 수 있는 다중화(multiplexing) 프로토콜. 
  메시지를 프레임으로 나누어 스트림에 끼워 넣음. data와 header 프레임이 분리되어 있어서 header 압축 가능.
  multiplexing(다중 전송) : stream 여러 개를 하나로 묶는 과정 가능. 

 

- 순서를 제거해 줌. 

 

- 전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 불필요한 오버헤드 제거, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들 압축

 

- 서버푸쉬를 통해 서버로 하여금 사전에 클라이언트 캐시를 필요하게 될 데이터로 채워 넣도록 허용함. 

 

Frame과 Stream

 

 

 

 

HTTP Request 구성

HTTP Request 구성

Host :  resource의 URL

본문 : optional.

 

 

 

HTTP Response 구성

HTTP Response 구성

 

Status code : 요청의 성공 여부와, 그 이유를 나타내는 상태코드

Status message : 상태코드의 짧은 설명을 나타내는 상태 메시지

본문 : optional.

 

 

---

 

브라우저 : 항상 요청을 보내는 개체. 서버가 될 수 없음.

 

프락시 : 애플리케이션 계층에서 동작 

- 캐싱 (브라우저 캐싱 등)

- 필터링(바이러스 백신 스캔, 유해 콘텐츠 차단 등)

- 로드 밸런싱(여러 서버들이 서로 다른 요청을 처리하도록 허용)

- 인증(다양한 리소스에 대한 접근 제어)

- 로깅(이력 정보를 저장)

등의 기능 수행

 

---

 

HTTP 요청 Method 

* 한 것들은 모두 idempotent(멱등적)

GET : 특정 리소스의 표시 요청. 데이터를 가져오는 것. 데이터를 받기만 함. 

 

POST : 서버에 데이터를 전송하여 서버가 상태를 바꾸도록 만듦.
            리소스의 위치를 지정하지 않았을 때 리소스를 생성. creates at a server defined URL
            => 매번 다른 곳에 새로운 리소스가 생성될 수 있으므로 idempotent 하지 않음. 

 

PUT : 목적 리소스를 요청 payload(전송되는 데이터)로 바꿈. 해당 리소스를 완전히 교체해 버림. 
          리소스의 위치가 지정되었을 때 생성 또는 업데이트를 위해 활용 가능. 
          creates/replaces at the client defined URL

 

DELETE : 특정 리소스 삭제

 

 

 

 

PATCH : 리소스의 위치를 알고 있을 때 부분적으로 업데이트하기 위해 활용

               updates part at the client defined URL

               아래의 예시를 이유로 멱등적이지 X.
               ex) 나이를 10으로 변경해 줘 -> 멱등적.
               but 나이를 10씩 증가시켜 줘 -> 멱등적이지 않음. 2번 호출하게 되면 +10 +10이 되어 버리기 때문.

 

 

 

 

 

실습

• POST vs PUT vs PATCH의 차이, idempotent 여부 비교

 

Reference

• https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP
• https://1ambda.github.io/javascripts/rest-api-put-vs-post/