HTTP 흐름 가볍게 이해하기 (1~3까지)

🌞 HTTP이 발전 이해하기 🌞

HTTP/0.9

• GET메소드만 존재
• HTML만 읽을 수 있고 클라이언트 정보 X
• 하지만 WWW의 근간이 되어 더욱이 발전할 수 있었음

HTTP/1.0

• 헤더를 통해 클라이언트와 서버 정보 전달이 가능해졌다.
• 또한, content-type헤더를 통해서 HTML뿐만 아니라, 이미지 동영상같은 다양한 정보를 주고 받을 수 있게 되었다.
• POST가 추가되어 클라이언트의 정보를 웹으로 전달할 수 있게 되었다.
• content-Encoding을 통해서 클라이언트와 서버간의 압축정보를 공유가 가능해졌다.

HTTP/1.1

• HTTP의 첫 번쨰 공식 표준버전이다
• GET, POST, PUT, DELETE의 함수를 모두 지원
• 하나의 TCP 연결을 지속적 연결을 추가함으로 재사용해 많은 콘텐츠 전달
• via 헤더로 중계서버 정보 공유, accept헤더로 클라이언트 지원 형식을 알 수 있게 됨
• 하지만 HOL(Head-Of-Line-blocking)문제를 해결하지 못했다.
  • 이는 서버가 응답을 지연하면 나머지의 요청또한 지연이 되는 것을 의미한다.

HTTP/2

• 보다 개선된 웹프로토콜을 위해 구글이 시작한 SPDY프로젝트이다.
• 텍스트 방식으 프로토콜 메시지를 binaray format을 사용해 경량화 함
• HTTP1.1의 비해 멀티플렉싱, 스트림 우선순위 설정, 헤더압축, 서버 푸시같은 최적화 기능이 추가되었다.
• HTTP2.0은 HOC의 문제를 해결했으나 TCP의 HOC문제는 해결하지 못했다.

HTTP

• 새로운 프로토콜인 QUIC(전송프로토콜)를 사용하는 HTTP의 최상위 버전이다
• QUIC는 UDP프로토콜을 채택했고, 구글에서 개발을 하였습니다.
• QUIC는 한 번 맺은 QUIC를 최대한 재사용하기 때문에 클라이언트와 서버간의 연결을 만다는 과정의 시간이 대폭 줄어들었다.
• 하지만 아직은 실험적인 단계이므로 많이 사용하지 않는다.

---

🌐 HTTP/2의 최적화 기술 🌐

💡 HTTP2의 가장 큰 목표는 클라이언트와 서버가 컨텐츠주고받는 시간을 줄이고 서버 응답이 느린 콘텐츠가 다른 정상적인 컨텐츠를 방해하지 않도록 하는 것

정리

• 기존 텍스트 방식을 이진프레임방식으로 바꾸며 프로토콜을 경량화했다.
• HTTP요청과 응답의 중복헤더를 걸러 내어 헤더의 크기를 최소화 함
• 서버푸시를 통해 서버가 미리 빠르게 전송하여 RTT를 최소화 함
• 구글 SPDY를 통해 최대 55%빠른 앱을 만듬

HTTP/2 의 이진프레임

• HTTP2 이전에 요청과 응답은 메세지라는 단위로 구성되어있다.
• HTTP/2에서는 메시지 단위 말고도 프레임, 스트림이라는 단위가 푸가되었다.
• 프레임 : HTTP2통신상 가장 작은 정보 단위이며 헤더나 데이터 중 하나
• 메세지 : HTTP1과 마찬가지로 응답단위이고 다수의 프레임으로 이루어져있음
• 스트림 : 클라이언트와 서버 사이의 맺어진 연경을 통해 양방향으로 주고 받는 하나 혹은 복수의 메지시이다.

• 여러 프레임이 모여 메세지가 되고, 여러개의 메세지가 모여서 스트림이 된다.
• 큰 데이터는 여러개의 프레임에 나뉘어 전달되는데 멀티플렉싱이 적용되어 순서에 상관없이 전달이 되고 클라이언트는 프레임들을 조림하여 완료하여 완전한 데이터를 만들어 낸다
• 하나의 TCP연결을 통해 다수의 클라이 언트 요청과 서버의 응답이 비동기 방식으로 이루어지는 멀티플렉싱을 사용되어 HTTP1.1의 HOC문제가 자연스레 해결이 되었다.

멀티플렉싱

• 파이프라이닝은 선입선출의 방식을 계속해서 사용했기 때문에 HOC가 해결되지 않았다. HTTP멀티플렉싱의 스트림의 유연한 구조로 인해 응답 프레임들은 요청 순서에 상관없이 만들어진 순서대로 클라이 언트에 전달이 가능하다
• 멀티플렉싱 : TCP 연결상에서 다수의 클라이언트 요청과 서버의 응답이 비동기방식으로 이루어지는 기술을 멀티플렉싱이라 한다.

헤더압축

• HTTP1.1까지는 content-Encoding을 헤더를 통한 알고리즘을 사용해 HTTP페이로드를 서버에서 압축했다.
• 따라서 헤더는 압축없이 그대로 전달이 되는 문제가 있었다.
• HTTP2는 클라이언트와 서버사이의 가상테이블을 설정하고 중복되는 헤더값을 테이블에 저장하고 참고하는 방식으로 중복 전달을 제거했다.
• 클라이언트가 두번의 요청을 보낸다고 가정하면 HTTP/1.x의 경우 두개의 요청 Header에 중복 값이 존재해도 그냥 중복 전송한다. 하지만 HTTP/2에선 Header에 중복값이 존재하는 경우 Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고 중복된 Header는 index값만 전송하고 중복되지 않은 Header정보의 값은 Huffman Encoding 기법으로 인코딩 처리 하여 전송한다.

 

서버 푸시

클라이언트의 요청이 없이도 서버가 응답을 알아서 보내는 서버푸시 기능이 HTTP2에서 추가되었다.

 

• 서버푸시의 대상은 웹서버 관리자나 개발자가 미리정할 수 있다.

• 추가적인 왕복이 필요하지 않다.

---

🌈 HTTP/3의 최적화 기술 ⛱️

QUIC (새로운 전송계층)

• 구글에서 개발한 OSI 네번째 계층인 전송계층 프로토콜이다.
• Quick UDP Internet Connections를 의미한다.
• 전달 속도 향상과 더불어 클라이언트와 서버의 연걸 수를 최소화하고 대역폭을 예상해 패킷의 혼잡을 피하는 것이 주요 특징이다
• 클라이언트가 서버를 한 번이라도 접속을 했다면, 별로의 정보교환 없이 바로 데이터를 보내는 기술을 Zero RTT라고 한다.

 

UDP로 바꾸는게 성능향상이 되는이유

1. UDP의 헤더의 크기가 작은만큼 보내는 데이터의 지연을 줄일 수 있습니다.
2. QUIC 방식이 UDP의 방식으로 Zero RTT(Round Trip Time, 왕복 시간)로 연결에 걸리는 시간이 줄어듭니다.

HTTP/3의 특징

• 가장 큰 특징은 TCP/IP기반의 레이어 프로토콜인 HTTP를 QUIC위로 이동시켰다는 것이다.
• 이를 HQ라고 부른다(HTTP over QUIC)