지난번에 HTTP와 HTTPS에 대해 알아봤는데, HTTP 버전별 차이가 궁금해서 정리하게 되었습니다.
HTTP/0.9
HTTP의 가장 초기 버전으로, 1991년에 고안되었습니다.
가장 초기에 고안된 버전인 만큼 구조도 가장 단순했습니다. 요청 메소드도 GET 하나였고, 응답은 무조건 HTML 파일이었습니다. 응답 코드, 헤더와 같은 부가 정보도 전달이 불가능 했습니다.
그러나 웹이 커짐에 따라 HTML 말고도 다양한 정보 전달이 필요해졌고, 기능을 확장하게 됩니다.
HTTP/1.0
HTTP 1.0은 여러 기능을 더해 표준을 만들어 1996년에 공개됩니다.
헤더 도입
우선 현재에도 많이 활용되는 헤더를 도입했습니다.
헤더의 도입으로 메타데이터를 주고받고 확장이 가능하게 개선되었습니다.
요청과 응답시에 모두 메타데이터를 담을 수 있는 헤더를 추가할 수 있게 바뀌었습니다.
요청 메소드 확장
요청 메소드가 GET, HEAD, POST로 확장되어 다양한 목적을 표현할 수 있게 되었습니다.
상태코드 추가
상태코드가 추가되어 클라이언트가 결과를 빠르게 파악하고 대처할 수 있게 되었습니다.
그러나 여전히 문제는 존재했습니다. HTTP/1.0은 Connectionless 원칙에 따라 무조건 한번의 요청에는 한번의 응답만 할 수 있었습니다. 이는 매 요청마다 TCP Handsake를 반복해야 해서 비효율적으로 동작하는 원인이 되었습니다.
HTTP/1.1
1.0에서 언급한 비효율적인 연결 문제를 해결하기 위해 개선된 버전이 1997년에 공개됩니다.
가장 큰 변화는 Persistent Connection과 Pipelining이 추가된 것 입니다.
Persistent Connection
Persistent Connection은 Keep-Alive로도 불리는데, 이름 그대로 연결을 계속 유지하는 기능입니다.
기존에는 Connectionless 원칙에 따라 한번 요청-응답이 진행된 연결을 즉시 TCP 연결을 종료했습니다.
그러나 Persistent Connection은 지정된 timeout TCP 연결을 종료하지 않고 잠시 대기했다가, 다시 요청이 들어오면 Handsake를 생략하고 바로 데이터를 교환하는 방식으로 동작합니다.
이는 HTTP/1.0의 비효율성을 해결할 수 있었습니다.
Pipelining
Pipelining은 여러 요청-응답 진행 시 앞 요청의 응답을 기다리지 않고 순차적으로 여러 요청을 보내고 그 순서에 맞게 응답을 받는 방법입니다. 기존 방식의 요청-응답-요청-응답 프로세스를 요청1|요청2->응답1|응답2로 처리할 수 있게 되면서 여러 요청-응답을 한번에 진행할때 더 빠르게 결과를 받아볼 수 있었습니다.
그러나 웹의 규모가 점점 커지면서 새로운 문제들이 나오게 되었습니다.
첫 번째 문제는 헤더의 중복입니다.
Persistent Connection과 Pipelining으로 여러 요청을 한번의 연결로 전달하면서, 연속된 요청-응답에 중복으로 담기는 헤더가 많아졌습니다.
이는 굉장한 낭비로 이어지게 됩니다.
두 번째 문제는 HOLB(Head-of-Line Blocking) 입니다.
Pipelining은 여러 요청을 받고, 받은 순서대로 처리해서 돌려주는 기능입니다.
이 기능에서 만약 앞 요청의 처리가 너무 오래 소요되게 되면 뒤에있는 요청도 줄줄이 처리가 밀리는 문제가 발생합니다.
HTTP/2.0
HTTP/2.0은 위에서 제시된 문제점을 해결하기 위해 2015년에 공개됩니다. HTTP/2.0은 SPDY 프로토콜을 기반으로 동작합니다.
SPDY 프로토콜
출처: https://d2.naver.com/helloworld/140351
SPDY는 구글에서 달라진 웹 환경에 대응하기 위해 제안한 프로토콜입니다. HTTP/1.1의 문제점을 해결하기 위해 여러 기술이 적용되었습니다.
메세지 전송 방식 변화
기존 HTTP의 전송 방식은 텍스트 전송 방식이었습니다.
SPDY는 Binary Frame 계층을 추가해 매시지를 프레임 단위로 분할하여 추가적인 바이너리 인코딩을 진행합니다.
이는 전송 속도 계선과 오류 발생 가능성을 낮추는 효과가 있다고 합니다.
멀티플렉싱 (Multiplexing)
하나의 TCP 연결 안에서 요청과 응답을 동시에 처리합니다.
기존에는 응답을 기다리지 않고 요청을 여러개 보내도 결국 순서대로 처리하고 응답을 보냈습니다.
그러나 멀티플랙싱은 요청-응답을 기다리지 않고 여러 요청을 동시에 처리합니다.
조금 더 자세히 살펴보면, SPDY에서는 TCP 연결이 스트림, 메시지, 프레임 단위로 세분화 되었습니다.
스트림은 요청과 응답이 양방향으로 오가는 연결 단위로, TCP에서 여러개의 스트림이 동시에 존재할 수 있습니다.
메시지는 하나의 요청과 응답을 구성하는 단위, 프레임은 메시지를 구성하는 최소 단위입니다.
클라이언트와 서버는 응답-요청을 여러 프레임으로 나눠 스트림을 통해 주고받고 나눠진 프레임을 재조립 하며 데이터를 주고받습니다.
헤더 압축 (Header Compression)
HTTP의 헤더 중복 문제를 헤더 압축으로 해결했습니다.
SPDY에서는 DEFLATE라는 알고리즘을 사용했다고 합니다.
서버 푸시 (Server Push)
클라이언트가 요청한 정보 외에에 필요하다고 판단되는 정보를 서버가 미리 파악해서 한번에 전달하는 기술입니다.
예를들어, index.html만 요청할 때 그에 필요한 js와 css 파일도 필요할 것으로 판단하고 같이 응답으로 보내는 것이 서버 푸시입니다.
항상 TLS 적용
SPDY는 보안을 위해 항상 TLS 위에서만 동작하게 설계되었습니다.
그래서 HTTPS로 작성된 웹사이트만 적용이 가능합니다.
HTTP/2.0은 SPDY를 조금 더 수정해서 적용하게 됩니다.
가장 큰 차이점은 헤더 압축 알고리즘입니다. 기존에 SPDY에 적용된 알고리즘은 DEFLATE인데, 보안 취약점이 발견되어 허프만 코딩 기반의 HPACK로 변경되었다고 합니다.
그러나 2.0에도 여전히 문제가 있습니다.
HTTP/2.0도 근본적으로는 TCP 기반으로 동작합니다. TCP는 UDP와 다르게 패킷이 손실되면 재전송을 진행합니다. 그래서 여러 프레임이 전송 도중 하나라도 문제가 생기면 다른 스트림의 전송까지 영향을 주어 HOLB 문제가 발생하게 됩니다.
HTTP/3.0
그래서 2022년에 HTTP/3.0이 공개됩니다. TCP의 근본적인 문제를 해결하기 위해, UDP 기반의 QUIC로 교체한 버전입니다.
QUIC 프로토콜
기존 TCP는 Handsake, 패킷 유실 등 많은 문제가 있었지만, 이를 바꾸기 위해서는 운영체제 커널에 있는 TCP 프로토콜을 전세계의 모든 장비에서 업데이트 해야하는 문제가 있습니다. 그래서 구글은 UDP를 기반으로 QUIC라는 새로운 프로토콜을 만들기로 합니다.
UDP 사용 QUIC는 UDP를 기반으로 동작합니다. UDP는 신뢰성을 보장하지 않는 프로토콜입니다. 그래서 TCP Handsake 과정을 걷어내는 대신, 신뢰성에 필요한 기능들은 따로 구현하여 추가하게 되었습니다. 이를 0-RTT라고 합니다.
HOLB 해결
QUIC는 각 스트림을 완전히 독립적으로 분리합니다.
그 결과, 서로 다른 스트림에서 발생한 문제는 서로 영향을 받지 않아 기존의 HOLB 문제를 해결하게 됩니다.
연결 유지
TCP는 IP에 따라 연결을 생성하고 유지합니다.
그래서 와이파이에서 데이터로 넘어갈 때 TCP 연결이 끊기게 됩니다.
그러나 QUIC는 Connection ID를 이용해서 연결을 구분합니다.
그래서 네트워크가 바뀌어 IP가 변경되더라도 연결이 유지됩니다.
결과적으로 TCP의 문제점을 해결하기 위해 TCP를 완전히 버리고 UDP 기반의 QUIC를 적용하여 문제를 해결했습니다. 최근에는 많은 CDN 서버에서 3.0을 지원하면서 HTTP/3.0 트래픽이 전세계 트래픽 중 20%를 넘게 차지할 정도로 보급이 진행되는 중 입니다.