HTTP 3.0 & HTTPS

HTTP 3.0

HTTP 2.0이 등장하며 성능을 상당히 향상시켰지만 여전히 TCP를 기반으로 하고 있기에 핸드쉐이크 과정의 지연 시간과 앞의 패킷이 지연되면 뒤의 모든 패킷이 지연되는 HOLB 문제가 발생합니다.

구글은 이에 TCP를 버리고 UDP 기반의 QUIC 프로토콜을 제안하였고 이것이 HTTP 3.0입니다.

빠른 연결

기존 HTTP 2에서는 TCP를 위한 핸드쉐이크와 TLS 연결을 위한 핸드쉐이크가 각각 발생하며 2번의 RTT가 소요되지만 QUIC은 내부에 TLS 인증서를 포함하여 최초 연결 설정에서 인증 정보를 함께 보내며 1번의 RTT로 연결을 맺도록 할 수 있습니다.

그리고 한번 연결에 성공했다면 이후 연결이 끊어지더라도 서버의 세션 키를 캐싱하여 다음 연결에 서버의 세션 키를 통해 바로 연결하여 추가적인 핸드쉐이크 없이 0번의 RTT로 바로 통신을 시작할 수 있어 통신이 끊어지거나 사용자 IP가 변경되어도 연결이 유지될 수 있습니다.

HOLB 문제 해결

HTTP는 TCP 연결 하나로 수백개의 스트림 데이터를 병렬 전송하게 되는데 이 과정에서 하나의 패킷이 누락된다면 해당 패킷을 재전송하고, 재전송하는 기간 동안 모든패킷 전송이 지연되게 됩니다.

QUIC은 TCP를 사용하지 않고, 스트림을 독립적으로 나누어 독립 스트림으로 처리하도록 하여 한 스트림의 지연이 다른 스트림에 영향을 주지 않도록 하였습니다.

패킷 손실 감지

QUIC이 UDP 기반으로 동작한다고 해서 신뢰성이 없는 것이 아니라, UDP는 탑재를 하지 않았을 뿐 커스터마이징이 가능합니다.
QUIC은 UDP를 커스터마이징하며 TCP보다 빠르게 패킷 손실을 감지하고 흐름을 제어할 수 있도록 하였습니다.

QUIC은 헤더에 패킷의 전송 순서를 나타내는 별도의 패킷 번호 공간을 부여하며 스트림 별로 손실된 패킷을 파악하며 패킷이 누락되면 해당 패킷만을 중단하도록 하며 손실을 감지합니다.

보안 강화

QUIC은 기본적으로 TLS 암호화를 사용하며 QUIC 내에 TLS를 포함시켜 헤더 영역도 암호화하며 보안을 강화합니다.

Q. SSL 인증에서 사용하는 암호화 방식과 사용하는 이유는 무엇인가요?

SSL 프로토콜에서는 최초 대칭키를 공유하기 위해서는 비대칭 암호화 방식을, 이후 대칭키를 공유한 이후에는 대칭 암호화 방식을 사용합니다.

비대칭 암호화 방식은 공개키를 통해 암호화한 데이터는 비공개키로, 비공개키를 통해 암호화한 데이터는 공개키로 복호화가 가능한 암호화 기법입니다.
대칭 암호화 방식은 동일한 키로 데이터를 암호화하고 복호화하는 기법입니다.

비대칭 암호화 방식은 공개 키를 안전하게 배포할 수 있다는 장점이 있지만 계속 복잡도가 높고 속도가 느립니다.
따라서 최초 키를 배포할때까지는 비대칭 암호화 방식을 사용하고, 배포 이후에는 빠른 대칭 암호화 방식을 사용합니다.

Q. HTTP 3의 0-RTT 핸드쉐이크는 무엇인가요?

0 RTT 핸드쉐이크는 이전에 통신한 적이 있는 서버와의 재연결 시 초기 핸드쉐이크 단계를 건너뛸 수 있도록 하여 연결 설정 시간을 단축할 수 있는 방법입니다.
HTTP 3은 Connection ID를 사용하여 서버와 연결을 생성하고, 이를 통해 연결을 식별하므로 클라이언트의 IP가 변경되더라도 기존과의 연결을 유지할 수 있도록 해주고, 새로운 핸드쉐이크 과정을 거치지 않도록 해줍니다.

Q. HTTP2에서와 HTTP3에서 TLS 인증은 어떻게 달라지나요?

HTTP2는 필수적으로 TLS 인증 과정을 진행하지는 않지만 대부분의 브라우저에서 HTTPS로만 HTTP2 요청이 가능하도록 하고 있습니다.
HTTP3에서는 프로토콜 내에 TLS 인증을 포함하고 있습니다.

따라서 HTTP2에서는 TCP 3 way handshake를 진행한 이후 TLS를 위한 RTT가 필요하지만 HTTP3는 최초 연결 설정 과정에서 TLS 인증을 위한 데이터의 전송을 함께 처리하여 별도의 RTT가 필요하지 않습니다.

Q. CA 인증서 발급 과정과 대칭키 교환 과정을 설명해주세요

최초에 클라이언트가 서버에 요청을 날리면 서버는 연결을 맺고 CA 인증서와 서버의 공개키를 전달받습니다.
CA를 통해 인증서와 공개키가 위조되지 않았음을 확인한 후 클라이언트는 자신의 세션 키를 생성하여 서버의 공개키로 암호화하여 서버에 전달합니다.
서버는 자신의 비공개키로 세션 키를 복호화하여 클라이언트와 서버 모두 동일한 세션 키를 보유할 수 있습니다.
이후 세션키를 대칭키로 사용하여 데이터를 주고받습니다.