현재 구글에서는 HTTP 3.0 + QUIC을 사용하고 있는데..
HTTP 1.0부터 차근차근 정리해보자.
1) HTTP 1.0
하나의 요청에 하나의 응답. 매번 새롭게 연결해야하기 때문에 성능이 저하되고 서버 부하 비용 또한 증가한다.
2) HTTP 1.1
HTTP 1.0의 불편함을 줄이기 위해 persistent connection 을 도입한 HTTP 1.1이 나왔다.
일정한 TIME동안 connection을 닫지 않는 방식이다.
pipelining: 순차적인 여러 요청을 연속적으로 보내서 순차적으로 응답을 받아 시간 지연을 줄인다.
하지만,
만약 한 작업이 오래 걸리는 작업이라면? 뒷부분은 무한 대기상태.. head of line blocking의 단점이 있다.
또, 헤더 구조가 중복될 수 있다.
3) HTTP 2.0
HTTP 2.0은 1.1을 확장한 것이다. 대체가 아님!
먼저, 메시지 전송 방식을 변화시켜서 멀티플렉싱이 가능하도록 했다. 한 번의 요청으로 여러 개의 리소스 전송이 가능하다는 것이다. 이 때 stream prioritization을 통해 전송할 수 있다.
또, 바이너리 프레이밍 계층을 사용하여 파싱 전송 속도를 향상 시키고 오류를 줄였다.
클라이언트가 아직 요청하지 않았어도 추후 요청할 것으로 예상되는 데이터를 함께 보내줄 수 있다. 즉, 한 번의 요청으로 여러 개의 관련된 리소스가 전송되는 서버 푸시 기능이 있다.
HTTP 1.1에서의 문제였던 헤더 중복문제는 헤더 압축을 통해 해결했다. HPACK 알고리즘을 사용하고, 허프만 인코딩을 통해 헤더를 압축한다.
하지만 여전히 HOL(head of line blocking) 문제가 있다.
4) QUIC
UDP 기반 전송 계층 프로토콜이다.
왜 TCP가 아닌 UDP일까?
TCP는 신뢰성을 확보할 수 있지만 시간 지연을 줄이기는 어려운 구조이다.
따라서 첫 연결 때 필요한 정보와 함께 데이터를 전송하면 연결이 성공했을 경우 해당 설정을 캐싱하여 다음 연결 때 바로 적용이 가능하다.
connection uuid 고유한 식별자로 서버와 연결하기 때문에 커넥션 재수립이 필요없다.
TLS를 적용하고 독립 스트림을 사용하기 때문에 향상된 멀티플렉싱이 가능하다.
TLS란?
일단, HTTP에서의 문제점은 데이터가 거쳐가는 모든 곳에서 데이터를 볼 수 있다는 것이다.
또, 상대방이 내가 원하는 상대방인지도 알 수 없고, 요청, 응답 내용이 변조될 수 있다.
TLS는 Transport Layer Security의 약자로, 전송계층을 보안한다.
응용 계층의 데이터를 암호화, 복호화를 수행하고 443포트를 사용한다.
특징으로는,
암호화, 인증, 무결성 등이 있다.
