HTTP version

HTTP 0.9

• 1991년
• HTTP 초기 버전을 구분하기 위해 부르는 버전
• 요청은 단일 라인으로 구성되며, 리소스에 대한 method는 GET만 존재
• 응답도 극도로 단순 (파일 내용 자체로만 구성)
• HTTP 헤더 X, HTML파일만 전송 가능!

HTTP 1.0

• 1996년
• HTTP 헤더(header) 개념이 도입, 요청과 응답에 추가
• 메타데이터를 주고 받고 프로토콜을 유연하고 확장 가능하도록 개선됨
• 버전 정보와 요청 method가 함께 전송되기 시작
• 상태 코드 라인도 응답의 시작부분에 추가
  ▶️ 브라우저 요청의 성공과 실패를 파악 가능해짐
  ▶️ 해당 결과에 대한 로컬 캐시 갱신 등의 사용이 가능해짐
• Content-Type 도입 = HTML 이외의 문서 전송 가능

‼️한계
커넥션 하나당 요청 하나와 응답 하나만 처리 가능
➡️ 매우 비효율적 + 서버 부하

HTTP 1.1

• 1997년
• Persistent Connection 추가
• 지정한 timemout 동안 커넥션을 닫지 않음
  ▶️ 커넥션의 사용성이 높아짐
• Pipelining 추가
  ▶️앞 요청의 응답을 기다리지 X,
  순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식 등장
  ▶️순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선
  ▶️하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아님 (multiplexing 되지는 않음)

‼️ 한계

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

HTTP 2.0

• 2015년
• 기존 HTTP 1.X 버전의 성능 향상에 초점을 맞춘 프로토콜
• 구글이 개발한 비표준 개방형 프로토콜 SPDY를 기반

‼️ 기존 버전의 문제점
시간이 지남에 따라 웹에서 담아야 할 정보는 점점 늘어감 + 하나의 웹사이트에 수 많은 멀티미디어 리소스들과 비동기 요청들이 발생
➡️ 기존 HTTP 1.1로 버티기 어려움

Multiplexed Streams

• HTTP Pipelining(http1.1)의 개선안
• 하나의 Connection으로 동시에 여러 개의 메세지를 주고 받을 수 O
• 응답은 요청 순서에 상관없이 Stream으로 받음
  ➡️ HOL Blocking 발생 X
  

Stream Prioritization

• 응답에 대한 우선순위 부여, 우선순위가 높을수록 빠르게 응답
  EX). 하나의 HTML 문서에 CSS 파일과 여러 IMG 파일
  여기서 만약 여러 IMG 파일을 응답하느라 CSS 파일의 응답이 느려지면 클라이언트는 렌더링을 하지 못하고 기다리게 됨
  → 따라서 CSS 파일의 우선순위를 올려 렌더링을 진행 + IMG 파일은 도착하는 대로 띄워주는 것이 더 효율적
  

Server Push

• 서버가 클라이언트의 요청없이 응답을 보냄
  EX) 하나의 HTML 문서에 CSS 파일과 여러 IMG 파일 (위와 같음)
  기존에는 HTML 문서를 요청한 후 다시 각각의 CSS 파일과 여러 IMG 파일을 위한 요청을 보내야 했음

하지만 Server Push로 인해서 클라이언트의 요청을 최소화하고 서버가 리소스를 알아서 보내줄 수 있음

Header Compression

• HTTP 1.1) 이전 요청과 중복되는 Header도 똑같이 전송해야 함
  ➡️ 네트워크 자원 낭비
• HTTP 2.0)
  ✅Header Table과 Huffman Encoding을 사용하는 HPACK 압축방식으로 이를 개선

클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경령화

HTTP 3.0

‼️ 기존 버전의 한계점
http 2.0은 HOL를 해결했지만,

• TCP를 사용하기 때문에 여기서 발생하는 HOLB(Head Of Line Blocking)문제 발생
• 2.0) 하나의 연결 안에서 여러개의 스트림이 전송
  → 여기서 하나의 패킷이 빠지거나 없어지면 없어진 패킷을 다시 전송하고 목적지에 도달하는동안 전체 TCP 연결이 중단!
  → 즉, TCP 자체가 신뢰성 이 보장된 프로토콜이기 때문에 이와 같은 문제가 발생
  ✅ 그래서 TCP를 이용하는 한 이 이슈를 고치는 것은 쉽지 않다고 판단됨
  ➡️ UDP를 이용하면서도 TCP의 혼잡제어나 신뢰성을 보장하는 장점을 살리는 방안을 고민

QUIC 프로토콜

• Quick UDP Internet Connections
• 말 그대로 UDP를 사용하여 빠르게 인터넷 연결을 하는 새로운 프로토콜
• UDP가 데이터 전송의 신뢰성을 보장하지 않지만 UDP위에 새로운 전송계층을 추가함으로써 TCP에 존재하는 패킷 재전송, 혼잡 제어, 속도 제어 등 여러 기능들을 제공

✅ QUIC을 선택하면서 얻게 된 장점

• 암호화가 프로토콜의 일부기능으로 포함
• 스트림 연결과 암호화 스펙등을 포함한 모든 핸드쉐이크가 단일 요청/응답으로 끝남
• 패킷이 개별적으로 암호화, 다른 데이터 부분의 패킷을 기다릴 필요가 없음
• 통신이 멀티플렉싱 → HOLB 극복
• QUIC는 운영체제 커널과 독립적으로 응용 프로그램 공간내에서 구현할 수 있으며, 덕분에 데이터의 이동에 따른 컨텍스트 전환에 의한 오버헤드가 없어짐!
• Source Address와 무관하게 서버에 대한 연결을 고유하게 식별하는 연결 식별자가 포함되어 있어, IP주소가 변경되더라도 커넥션을 유지할 수 있음