[네트워크]QUIC 프로토콜

1. 들어가며 (Introduction)

• 학습 계기: wireshark로 구글과 접속을 확인하던 도중 익숙하지 않은, QUIC라는 것을 발견했다. 해당 내용을 조금 더 찾아보니 새로운 통신 프로토콜 방법이라고 하여, 이번에는 위 내용을 조금 더 알아가보고자 한다. 

2. QUIC이란 무엇인가?

핸드셰이크 레이턴시 비교 / QUIC와 TCP 스트림 구조 차이

• 정의: Quick UDP Internet Connections의 약자로, 구글에서 개발한 범용 목적의 UDP 기반의 차세대 전송 계층(Transport Layer) 통신 프로토콜이며 IETF에서 표준화한 프로토콜입니다. 2021년 5월, RFC 9000으로 표준화되며 차세대 인터넷의 핵심 기술로 자리 잡았습니다.
• 핵심 특징:
  • UDP 기반: TCP의 3-Way Handshake 과정을 생략하거나 단축합니다.
  • 연결 전이(Connection Migration): 와이파이에서 LTE로 바뀌어도 연결이 끊기지 않습니다.
  • 멀티플렉싱: 하나의 연결에서 여러 스트림을 처리해도 홀오브라인 블로킹(HoL Blocking)이 발생하지 않습니다.

3. 핵심 메커니즘: TCP와의 차이점

① HoL(Head-of-Line) 블로킹 해제 (독립적 스트림)

• TCP의 한계: 모든 데이터를 하나의 순차적인 바이트 스트림으로 간주한다. 패킷이 딱 하나만 유실되어도 커널의 TCP 버퍼가 멈추고 모든 스트림이 대기하는 병목이 발생한다.
• QUIC의 해결: 전송 계층에서부터 여러 스트림을 독립적으로 관리함. 특정 스트림의 패킷이 소실되어도, 나머지 정상적인 스트림은 중단 없이 목적지에 도달함.

② 레이턴시 혁신 (Handshake & User Space)

• 0-RTT / 1-RTT 연결: TCP는 연결(1-RTT) 후 보안(1-2-RTT)이 순차적으로 발생하지만, QUIC은 연결과 보안 설정을 한 번에 처리하여 첫 연결은 1-RTT, 재연결은 0-RTT(대기 시간 없음)를 달성함.
• 사용자 공간(User Space) 혼잡 제어: 기존 TCP 혼잡 제어는 OS 커널에 박혀 있어 알고리즘 수정이 매우 어려움(커널 업데이트 필요). QUIC은 이를 어플리케이션(사용자) 공간으로 끌어올려, 서비스 특성에 맞는 최적의 알고리즘을 빠르게 적용할 수 있는 유연성을 확보함.

③ 전방 오류 정정 (FEC, Forward Error Correction)

• 메커니즘: 데이터 패킷과 함께 일종의 '에러 정정용 패킷'을 추가로 보냄.
• 효과: 일부 패킷이 유실되더라도 재전송 요청을 보내기 전에 수신 측에서 유실된 데이터를 스스로 복구함. 네트워크 환경이 불안정한 상황에서 재전송으로 인한 지연을 방지하는 핵심 기술임.

④연결 전이 (Connection Migration):

• 와이파이에서 LTE로 네트워크 환경이 바뀌어 IP 주소가 변경되어도, QUIC은 'Connection ID'를 사용하므로 연결을 끊지 않고 유지합니다.

4. 학습 중 마주친 질문 (Troubleshooting & Q&A)

Q: UDP 기반이면 DDoS 공격에 취약하지 않을까?

A: 맞습니다. 이를 QUIC Flood 공격이라고 합니다.

• 보안 리스크: 공격자가 가짜 소스 IP 주소로 대량의 QUIC 연결 요청(Hello 패킷)을 보내 서버 자원을 고갈시킬 수 있습니다.
• 대응 방안: 인프라 엔지니어는 QUIC 트래픽의 패턴을 분석하고, 암호화되지 않은 초기 패킷을 검사하거나, 비정상적인 연결 요청을 차단하는 전용 방화벽 설정이 필요합니다.

Q: 왜 굳이 UDP 위에서 구현했을까?

A: TCP는 OS 커널 깊숙이 구현되어 있어 수정과 배포가 매우 느립니다. 반면 UDP는 데이터만 실어 나르는 단순한 통로이기에, 그 위(사용자 공간)에서 프로토콜을 구현하면 OS 업데이트 없이도 새로운 기능을 빠르게 적용할 수 있기 때문입니다.

Q: UDP는 신뢰성이 없는데 어떻게 오류 정정을 할까? 

A: UDP는 단순히 데이터를 실어 나르는 바구니 역할만 할 뿐, 실제 오류 검출과 복구(FEC 등)는 그 위에서 동작하는 QUIC 엔진이 직접 수행합니다. 이를 통해 TCP 수준의 신뢰성을 확보하면서도 속도는 더 높였습니다.

패킷이 안 오면 QUIC이 서버에게 재전송을 요청합니다. 즉, 신뢰성 보장 로직을 커널(TCP)이 아닌 앱(QUIC)에서 구현한 것입니다. 이는 커널의 제약을 벗어나기 위함입니다.

• TCP: 오류 정정 로직이 윈도우나 리눅스 커널 깊숙이 박혀 있습니다. 이걸 수정하려면 OS를 업데이트해야 하는데, 전 세계 사람들의 OS를 동시에 바꿀 수는 없습니다. (이를 'Ossification' 즉, 골화 현상이라고 합니다.)
• QUIC: UDP는 아무 기능이 없어서, 그 위에 구글이나 IETF가 최신 오류 정정 알고리즘을 코드로 짜서 브라우저에 넣어버리면, OS 업데이트 없이도 즉시 더 빠르고 안전한 통신이 가능해집니다.

5. 결론 및 향후 과제

• 결론: QUIC은 단순한 속도 향상을 넘어, '커널의 제약'과 'TCP의 순차적 전송'이라는 해묵은 과제를 UDP라는 자유로운 도화지 위에 해결한 결과물임.
• Next Step: 실제 서비스 환경에서 TCP와 QUIC의 응답 속도 차이 데이터 측정해보기.