하나의 Connection에서 여러 요청과 응답을 동시에 처리할 수 있다. 각 응답은 요청 순서에 상관없이 스트림으로 받기 때문에 HOL Blocking 문제도 해결이 가능하다.
헤더 압축(Header Compression)
HPACK이라는 압축 기술을 사용하여 헤더 정보를 효율적으로 압축한다. 이를 통해 데이터 전송량이 줄어들고 성능이 향상된다.
서버 푸시(Server Push)
서버가 클라이언트의 요청 없이도 응답을 보낼 수 있다. 예를 들어, 하나의 HTML 문서에 CSS 및 JavaScript 파일이 있다고 가정하면 기존에는 HTML 문서 요청 후 다시 각 리소스들을 요청했는데 Server Push를 통해 클라이언트 요청을 최소화하고 서버가 미리 리소스를 보내줄 수 있도록 개선했다.
스트림 우선순위(Stream Prioritization)
응답의 우선순위를 설정하여 중요한 리소스부터 먼저 전송할 수 있다.
1. 스트림(Stream): 구성된 Connection 내에서 독립적으로 데이터가 흐를 수 있는 양방향 통로로, 동시에 여러 요청과 응답을 주고받을 수 있다. 2. 메시지(Message): 요청 또는 응답에 해당하는 프레임의 전체 시퀀스이다. 메시지는 여러 개의 프레임으로 구성된다. 3. 프레임(Frame): HTTP/2.0 통신에서의 최소 단위로, 데이터와 메타데이터를 포함하는 단일 통신 블록이다. 각 프레임에는 하나의 프레임 헤더가 포함된다.
가장 큰 특징은 TCP가 아닌 UDP, 정확히 말하면 QUIC(Quick UDP Internet Connections)을 사용한다는 것이다. TCP는 신뢰성을 확보하지만 지연을 줄이기 힘든 구조인데, 반면에 QUIC는 TCP Handshake 과정을 최적화하는 것에 초점을 맞춰 설계되었다.
HTTP/3.0는 TCP 대신 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 한다. QUIC는 UDP 위에서 작동하며, UDP의 장점을 활용하면서, TCP와 UDP의 문제점들을 해결하기 위해 설계되었다.
신뢰성
데이터 확인: QUIC은 각 데이터 패킷이 제대로 수신되었는지 확인하기 위해 ACK 패킷을 사용한다.
재전송: 송신 측은 특정 시간 동안 ACK을 받지 못하면 패킷이 손실된 것으로 간주하고 해당 패킷을 재전송한다.
순서 제어: 헤더에 별도의 패킷 번호 공간을 부여해 순서를 보장한다.
멀티플렉싱(Multiplexing)
HTTP/2.0의 강점인 멀티플렉싱을 QUIC에서도 지원한다. 하나의 연결 내 여러 개의 스트림을 독립적으로 전송할 수 있어, 한 스트림의 손실이나 지연이 다른 스트림에 영향을 주지 않는다.
연결 지향
TCP는 클라이언트 IP가 바뀌면 연결을 끊어버리는데, 다시 연결을 생성하려면 3-way Handshake를 다시 해야 하고, latency가 발생된다.
QUIC는 Connection ID를 사용해 연결 지향적인 기능을 구현한다. 이는 클라이언트 IP와 무관하기 때문에 네트워크 경로가 변경되더라도 연결을 계속 유지할 수 있다.
헤더 압축
HPACK을 사용하는 HTTP/2.0와 달리, HTTP/3.0는 QPACK이라는 새로운 헤더 압축 방식이 적용된다.
연결 지연(latency) 감소
QUIC는 0-RTT(Zero Round Trip Time) 연결 설정을 지원하여, 연결 설정 시간을 단축시키고 빠른 데이터 전송이 가능하다.
Zero round-trip time (0-RTT): 한 번 HTTP 연결이 이루어지고 나면, 클라이언트는 더 이상 Handshake를 통해 통신 방법을 확인하려 서로를 확인하는 프로세스를 진행하지 않는다. 지속적인 확인이 필요한 TCP가 아닌 QUIC을 통해 빠르게 동작하는 것이 가능해진다.
하나의 Connection에서 여러 요청과 응답을 동시에 처리할 수 있다. 각 응답은 요청 순서에 상관없이 스트림으로 받기 때문에 HOL Blocking 문제도 해결이 가능하다.
헤더 압축(Header Compression)
HPACK이라는 압축 기술을 사용하여 헤더 정보를 효율적으로 압축한다. 이를 통해 데이터 전송량이 줄어들고 성능이 향상된다.
서버 푸시(Server Push)
서버가 클라이언트의 요청 없이도 응답을 보낼 수 있다. 예를 들어, 하나의 HTML 문서에 CSS 및 JavaScript 파일이 있다고 가정하면 기존에는 HTML 문서 요청 후 다시 각 리소스들을 요청했는데 Server Push를 통해 클라이언트 요청을 최소화하고 서버가 미리 리소스를 보내줄 수 있도록 개선했다.
스트림 우선순위(Stream Prioritization)
응답의 우선순위를 설정하여 중요한 리소스부터 먼저 전송할 수 있다.
1. 스트림(Stream): 구성된 Connection 내에서 독립적으로 데이터가 흐를 수 있는 양방향 통로로, 동시에 여러 요청과 응답을 주고받을 수 있다. 2. 메시지(Message): 요청 또는 응답에 해당하는 프레임의 전체 시퀀스이다. 메시지는 여러 개의 프레임으로 구성된다. 3. 프레임(Frame): HTTP/2.0 통신에서의 최소 단위로, 데이터와 메타데이터를 포함하는 단일 통신 블록이다. 각 프레임에는 하나의 프레임 헤더가 포함된다.
가장 큰 특징은 TCP가 아닌 UDP, 정확히 말하면 QUIC(Quick UDP Internet Connections)을 사용한다는 것이다. TCP는 신뢰성을 확보하지만 지연을 줄이기 힘든 구조인데, 반면에 QUIC는 TCP Handshake 과정을 최적화하는 것에 초점을 맞춰 설계되었다.
HTTP/3.0는 TCP 대신 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 한다. QUIC는 UDP 위에서 작동하며, UDP의 장점을 활용하면서, TCP와 UDP의 문제점들을 해결하기 위해 설계되었다.
신뢰성
데이터 확인: QUIC은 각 데이터 패킷이 제대로 수신되었는지 확인하기 위해 ACK 패킷을 사용한다.
재전송: 송신 측은 특정 시간 동안 ACK을 받지 못하면 패킷이 손실된 것으로 간주하고 해당 패킷을 재전송한다.
순서 제어: 헤더에 별도의 패킷 번호 공간을 부여해 순서를 보장한다.
멀티플렉싱(Multiplexing)
HTTP/2.0의 강점인 멀티플렉싱을 QUIC에서도 지원한다. 하나의 연결 내 여러 개의 스트림을 독립적으로 전송할 수 있어, 한 스트림의 손실이나 지연이 다른 스트림에 영향을 주지 않는다.
연결 지향
TCP는 클라이언트 IP가 바뀌면 연결을 끊어버리는데, 다시 연결을 생성하려면 3-way Handshake를 다시 해야 하고, latency가 발생된다.
QUIC는 Connection ID를 사용해 연결 지향적인 기능을 구현한다. 이는 클라이언트 IP와 무관하기 때문에 네트워크 경로가 변경되더라도 연결을 계속 유지할 수 있다.
헤더 압축
HPACK을 사용하는 HTTP/2.0와 달리, HTTP/3.0는 QPACK이라는 새로운 헤더 압축 방식이 적용된다.
연결 지연(latency) 감소
QUIC는 0-RTT(Zero Round Trip Time) 연결 설정을 지원하여, 연결 설정 시간을 단축시키고 빠른 데이터 전송이 가능하다.
Zero round-trip time (0-RTT): 한 번 HTTP 연결이 이루어지고 나면, 클라이언트는 더 이상 Handshake를 통해 통신 방법을 확인하려 서로를 확인하는 프로세스를 진행하지 않는다. 지속적인 확인이 필요한 TCP가 아닌 QUIC을 통해 빠르게 동작하는 것이 가능해진다.
