HTTP/1 ~ HTTP/3

Sumin Kim·2022년 10월 4일

http protocol 같은 경우 신뢰성있는 연결만 해주면 전송프로토콜은 뭘써도 상관없다고 이론적으로 알려져있음

HTTP 1.0
- 헤더가 생김 → 버전도 붙고 응답에는 상태코드도 붙고 content type 이라는 부분이 생겨서 전에는 html만 보낼 수 있었다면 이제는 여러 파일들을 보낼 수 있게됨
- 커넥션 하나당 요청 하나랑 응답하나만 정해줄 수 있음 → 매번 새로운 연결로 성능이 저하되고 서버 부하비용도 올라감
HTTP 1.1
- HTTP 1.0 ‘ 단점 ⇒ 극복하기 위해 persistent connection 을 사용 : 지정한 timeout 동안 커넥션을 닫지 않는 방식 == 한 커넥션을 열어두면 여러 요청이 이 커넥션을 사용할 수 있도록 → 네트워크 사용시간이 훨씬 줄어든다
- 파이프라이닝이라는 기법 도입 (하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법) → 문제 : HTTP의 Head of line Blocking (첫번째 요청이 처리가 안되면 다음 요청이 처리가 안됨) && Header 구조의 중복 (중복을 그대로 전송 - 데이터가 커짐)

기존 HTTP/1.X 버전의 성능향상에 초점을 맞춘 프로토콜
표준의 대체가 아닌 확장

메시지 전송 방식의 변화
- 기존엔 일반 텍스트 형식의 메시지를 보냈었는데, 바이너리 프레임이라는 계층이 생겨서 여기서 메시지를 프레임 단위로 분할하고 바이너리로 인코딩 → 파싱이나 전송속도 상승, 오류 발생 가능성 낮아짐
Multiplexing (다중화) 가능해짐
- HTTP의 Head of line blocking (http 요청이 순서대로 응답이 되야함) 해결 : 어떤 메시지 하는 순서라는게 사라짐
  - 인터리빙이라는 끼어들기가 가능해져서 순서가 의미없어짐
Stream Prioritization
- 리소스간 우선순위를 설정 가능 (가중치를 줄 수 있어서 먼저 전송할 데이터를 정할 수 있음)
Server push
- 리소스를 서버에서 알아서 push 해서 보내줄 수 있는것
Header compression
- 헤더의 크기를 줄여 페이지 로드 시간 감소 (Static dynamic table을 이용해 중복을 걸러내고 중복제외한 내용을 압축해서 보냄 - 헤더의 크기를 85% 줄였고 페이지 로드시간도 감소)
  
  → 문제 : TCP 의 Head of Line blocking 을 해결하지 못함 (TCP가 지연을 줄이기 어려운 구조이기때문에 QUIC이 나오게 됨(UDP기반))

전송계층 프로토콜 (TCP나 UDP 같은 것인데 UDP 기반으로 만들었음)
TCP 는 신뢰성을 확보하지만 지연을 줄이기 힘든 구조 → 반면 UDP는 데이터 전송에 집중한 설계라 별도의 기능없이 원하는 기능을 구현할 수 있고 TCP 의 지연을 줄이면서 TCP 만큼 신뢰성확보 가능한 UDP를 바탕으로 QUIC을 만들었음
전송속도 향상 : 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송해서 연결 성공시 설정을 캐싱해서 다음 연결때 바로 성립이 가능하도록(hand shake 필요없이)
- connection UUID 라는 고유한 식별자로 서버와 연결해서 커넥션을 재수립 필요X
TLS 라는 것을 적용하고해서 보안성 향상
독립 스트림으로 향상된 멀티 플레싱 가능

위에서 설명한 QUIC을 바탕으로 HTTP3가 나옴

새로운 연결에 대해서 핸드세이크로 인한 지연, 패킷 손실이 다른 스트림에 미치는 영향, 패킷 손실로 인한 지연으로부터 자유로울 수 있다.
빠른 콘텐츠 전달이 생명인 CDN들은 앞 다투어 서비스들을 적용하고 있고, 당연히 해당 CDN을 이용하는 서비스 제공자들은 HTTP/3를 지원한다. 구글에서 제공하는 상당수의 컨텐츠들(유튜브 포함), 페이스북 등이 지원하도록 구성되었고, 클라이언트는 크롬, 엣지 브라우저, curl 등이 이미 지원하고 있다.