QUIC 프로토콜, 잘 아는 분들은 UDP 기반의 QUIC 효과가 무엇인지 잘 알 것입니다. 네트워크 연결 상태가 나빠도 안정적이고, 빠르게 트래픽을 처리하는 것이 아마 가장 큰 효과가 아닐까 싶네요. 참고로 QUIC는 구글 검색, 유튜브 등의 서비스에서 HTTPS 기반 암호화 통신을 할 때 사용됩니다. 더불어 크롬을 쓴다면 알게 모르게 QUIC의 효과를 누리고 있다고 봐도 됩니다.
이번에 소개할 내용은 구글 클라우드 플랫폼(GCP) 환경에서 로드밸런싱 설정을 사용할 때 QUIC를 활성화할 수 있게 되었다는 것에 대한 것입니다. 간단히 HTTPS 트래픽에 대한 로드밸런싱을 할 때 QUIC 프로토콜도 지원한다는 것입니다.
“HTTP/2와 QUIC 뭐가 달라?”
QUIC가 왜 빠르냐? QUIC는 멀티플렉싱을 기반으로 트래픽을 전송합니다. 이를 통해 트래픽 손실을 최소화하죠. 이는 HTTP/2와 다르지 않습니다. 차이가 있다면 HTTP/2는 TCP를 씁니다. 반면에 QUIC는 UDP를 기반으로 합니다. 이를 통해 TCP가 갖는 고질적인 문제인 HOLB(Head-of-line blocking)를 해결했습니다. TCP의 경우 패킷이 유실(loss)되면, 패킷을 재전송합니다. 패킷 전송 후 상대방에서 패킷을 잘 받았다는 신호인 ack를 보내지 않으면, 이후 내보낼 패킷을 전송하지 않고 대기 상태로 두고, 이전에 보낸 패킷을 다시 보냅니다. QUIC는 UDP의 특성을 활용해 이 문제를 해결합니다.
이런 특성으로 인해 레이턴시에 민감한 애플리케이션이나 서비스의 경우 QUIC의 이점을 톡톡히 볼 수 있죠. 특히 와이파이나 이동통신망을 경유하는 통신의 경우 안정적인 트래픽 전송의 효과가 꽤 큽니다. 그 이유 중 하나는 보안 연결을 사전에 맺어 두는 것 때문입니다. 만약 웹 클라이언트가 TCP나 TLS를 사용한다고 해보죠. 이 경우 웹 브라우저에서 연결 요청을 하기 전에 서버와 보안 연결을 위해 2~3번의 라운드 트립이 발생합니다. 이 작업은 매번 연결할 때마다 일어납니다.
QUIC는 다릅니다. 해당 서버와 보안 연결을 한번 맺었다면, 이후에는 바로 클라이언트의 요청에 따라 데이터를 전송합니다. 이런 효과를 제공하는 대표적인 서비스가 구글 검색입니다. 구글 검색은 QUIC를 통해 사용자가 체감하는 페이지 로딩 시간을 전 세계적으로 8%, 지역에 따라 최대 13%까지 끌어 놀렸습니다. 다른 예로 구글 클라우드 CDN이 있습니다. 다음 표에서 쓰루풋 차이를 보시죠. QUIC 적용하면 엄청나게 늘어납니다.
이 정도면 현재 구글 클라우드 플랫폼에서 사용하고 있는 로드밸런서에 QUIC 지원을 활성화할 이유가 충분할 것입니다. 설정은 GCP 콘솔에서 QUIC 네고시에이션 설정을 ‘Enable’로 하고 관련 IP와 포트를 정해주는 게 다입니다.
이렇게 설정하고 나면 뭐가 달라지나? 로드밸런서는 QUIC를 HTTP/1.1로 바꾸어 백엔드 서버에 전달합니다. 서버는 평소 받던 프로토콜과 다를 바 없으므로 따로 설정을 바꿀 필요가 없습니다. 서버 쪽에서 아무것도 건드리지 않지만, 사용자가 느끼는 차이는 큽니다. 구글 크롬이나 크로미움(Chromium)을 이용해 서버에 연결을 요청하는 클라이언트가 느끼는 체감 속도가 좋아집니다. 페이지 더 빨리 뜨고, 사진 등 무거운 파일도 더 빨리 올라옵니다. 만약 안드로이드 모바일 앱을 개발해 배포한다면 QUIC를 크로넷(Cronet)에 통합할 수 있습니다. 간단히 말해 QUIC를 기본으로 지원하는 앱을 만들기 쉽다는 것입니다.
더 자세한 내용은 관련 문서를 읽어보거나 메가존으로 문의 바랍니다.
