실전 프로젝트 11일차 회고

SaGo_MunGcci·2022년 9월 5일

Practice Project

실전 프로젝트

목록 보기

8/19

Today do list

http 1.0, 1.1 ,2.0, 3.0 공부
카카오 소셜 로그인 구현

TIL

http 1.0, 1.1 ,2.0, 3.0

전체

HTTP/0.9 (1991년)
HTTP/1.0 (1996년)
HTTP/1.1 (1997년) : 가장 많이 사용중
HTTP/2.0 (2015년) : HTTP 1.1의 성능 개선 및 확장
HTTP/3.0 (진행중)

핵심

HTTP 1.1 이 모든것의 기반이기 때문에 잘 알고 그 다음에 2.0 / 3.0을 알아두면 좋다
추후 사용될 HTTP 3.0도 인지해두자

참고 : https://velog.io/@neity16/HTTP-HTTP-%EB%B2%84%EC%A0%84-%EB%B3%84-%ED%8A%B9%EC%A7%95

HTTP/0.9 (1991년)

처음 버전에는 버전 번호가 없어서 이후 버전과 구별하기 위해 나중에 0.9라고 불렀다.(1991년)
요청은 한줄로만 구성되며, 리소스에 대한 method는 GET만 존재했다.

GET /mypage.html

응답도 극도로 단순해서 파일 자체로만 구성되어 있었다.


<html>
A very simple HTML page
</html>

HTTP 헤더도 없고, HTML파일만 전송 가능했던 것이 특징이다.

HTTP/1.0 (1996년)

1.0부터 여러 메타정보(헤더)가 포함되기 시작했다.
버전 정보가 GET라인에 붙은 형태로 전송되기 작했다.
상태 코드가 응답의 시작부분에 붙어 전송되었고, 그 결과에 대한 동작을 할 수 있게 되었다.
HTTP 헤더 개념이 추가되어 유연하고 확장 가능하도록 만들어주었다.
Content-Type헤더 덕분에 일반 HTML 파일 이외의 문서를 전송할 수 있었다.

이때의 일반적인 요청 및 응답은 다음과 같다.

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

이때의 이미지 요청(해당 응답 포함)시.

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

HTTP/1.1(1997년)

1997년 등장
Persistent Connection 추가
- 지정한 timemout 동안 커넥션을 닫지 않는 방법을 통해 커넥션의 사용성이 높아짐

Pipelining 추가
- 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식이 등장

순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선
하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아니다 (multiplexing 되지는 않음)

한계
- Head Of Line Blocking (HOL)
  : 결국 앞 요청의 응답이 너무 오래걸리면 뒤 요청은 Blocking 되어버림
- Header 구조의 중복
  : 연속된 요청의 헤더의 많은 중복이 발생

HTTP/2.0 (2015년) : HTTP 1.1의 성능 개선 및 확장

네이버는 h2이다?!

처음 http/2.0의 초기모델을 제시한것은 구글에서 만든 시험용 프로토콜인 SPDY였다. SPDY를 주시하고 있었던 HTTP Working Group이 HTTP/2 의 출발점으로 SPDY 사양을 채택했다. 그래서 SPDY는 HTTP/2.0의 시험용 브랜치가 되었고 나란히 발전하여 HTTP/2 표준이 발행되었다.

바이너리 프레이밍 계층
HTTP/2.0 의 핵심은 기존의 요청메세지를 작은 프레임으로 쪼개었다는 것이다.

헤더부분과 컨텐트 부분을 하나의 프레임으로 분리 시켰고 기존의 텍스트 형식의 요청메세지를 새 바이너리 인코딩을 통해 최적화 시켰다.
이렇게 하나의 논리적인 스트림(요청하고 응답하는 하나의 데이터 양방향 흐름)을 여러개의 프레임으로 분리 시켰다.

따라서 각 프레임에는 이것이 어떤 스트림인지 고유한 식별자가 있다.
그리고 더 중요한 지점은 이러한 여러개의 스트림을 인터리빙 한다는 것이다. 여기서 인터리빙은 여러개의 스트림에서 쪼개진 프레임들을 서로 끼워넣는 것을 얘기한다.

위의 그림에서 스트림 1,3,5 총 3개의 스트림이 동시에 병렬적으로 하나의 연결안에서 이루어지는 것을 알 수 있다. 이로써 응답 다중화 (멀티플렉싱)을 가능하게 하고 위에서 언급 되었던 HOL block 문제를 해결 할 수 있다. 또한 여러 개의 연결이 없어도 되기 때문에 리소스 비용이 더 절감될 수 있는 장점이 있다.

정리한 그림은 다음과 같다.