QUIC(Quick UDP Internet Connections)

방화벽을 들여다 보다보면 QUIC 란 프로토콜을 이용한 접속 사용자를 볼수 있는데 이게 무엇인지 알아 보겠습니다.

이미지 https://techrecipe.co.kr/posts/29744

QUIC(Quick UDP Internet Connections) 란?

연결 지향 Web App의 성능을 향상 시키기 위해 Google이 개발한 전송계충(Transport Layer) 네트워크 프로토콜이다.

QUIC의 핵심 사항

 1. 프로토콜(Protocol) 개요(Overview)

    QUIC는 TCP(전송 제어 프로토콜)가 아닌 UDP(사용자 데이터 그램 프로토콜)를 통해 작동하며,

    전송 계층과 애플리케이션 계층 프로토콜의 기능을 결합한다.

이미지 https://www.researchgate.net/figure/QUIC-placement-in-protocol-stack_fig1_332027418

 2. 성능 향상(Performance Enhancements)

   지연시간 단축(Reduced Latency) : 연결 설정 시간을 줄이고 전반적인 웹 성능을 향상 시키는 것을 목표로 한다.

                                                           연결 설정 중에 여러 번 왕복할 필요가 없다.

   멀티플렉싱(Multiplexing) : HOL(Head of Line)차단 문제가 발생할 수 있는 TCP를 통한 Http/2와 달리 QUIC는 이 문제를                                                방지하기 위해 여러 스트림을 독립적으로 멀티 플렉싱하는 것을 지원 한다.

  연결 마이그레이션(Connection Migration) : QUIC연결은 새로운 연결 없이도 네트워크 연결 변경에도 연결 유지 한다.

                                                                 예) wifi 연결 중 Hotspot으로 변경해도 네트워크 연결을 유지 한다.

https://medium.com/swlh/three-major-improvement-in-http-3-compared-to-http-2-39e8f5a5886c

 

 3. 보안(Security)

   QUIC는 전송 계층 보안(TLS1.3)을 통합하여 데이터의 기밀성, 무결성 및 신뢰성을 제공 한다.

   처음부터 암호화 기능이 내장되어 있어 기존 TCP/TLS에 비해 보안이 강화 되었다.

4. 오류 수정 및 흐름 제어(Error correction and Flow control)

   TCP와 유사 하지만 성능과 짧은 대기 시간을 최적화된 오류 수정 및 흐름 제어 메커니즘이 포함 되어 있다.

5. 배포(Deployment)

  처음에는 Google이 해당 서비스 및 제픔 Google 검색 , YouTube에 배포 했다.

6. 표준 및 채택(Standard and Adoption)

  QUIC는 IETF(Internet Engineering Task Force)에 의해 2021년 5월에 발표된 RFC 9000에서 표준화 되었다.

   성능상의 이점으로 다양한 웹 브라우져, 서버, 기타 인터넷 서비스에 채택되고 있다.

 

이 QUIC는 기존 TCP 기반 프로토콜의 많은 한계를 해결하면서 더 빠르고 안정적이며, 안전한 인터넷 연결을 제공하도록 설계되었다.

QUIC 단점과 앞으로의 과제

1.UDP 기반 제한 사항(UDP-Based Limitations)

   방화벽 및 네트워크 장치 호환성 문제 : 일부 방화벽 및 네트워크 장치는 UDP 트래픽을 차단하거나 속도를 제한하도록       구성되어 있으며, 이로 인해 QUIC성능이 저하 되거나 연결이 끊어 질 수 있다.

   NAT 통과 : NAT(네트워크 주소 변환)는 특히 장치가 IP 주소나 포트를 자주 변경하는 환경에서 QUIC 연결을 유지하는        데   문제를 일으킬 수 있다.

2. 복잡성(Complexity)

   구현의 복잡성 :  전송계층과 암호화 계층을 결합하므로 기존 TCP/IP 스택에 비해 올바르게 구현하는 것이 더 복잡하다

   디버깅 및 모니터링 : 암호화된 특성으로 인해 QUIC 트래픽을 디버그하고 모니터링 하는것이 어려우며, 전문 도구와 기      술이 필요 하다.

3. 리소스 소비(Resouce Consumption) 

   CPU 및 Memory 사용량 :  암호화 및 멀티 플렉싱 기능은 서버의 CPU와 메모리 사용량을 높여 잠재적으로 TCP에 비해     더 많은 리소스가 필요할 수 있다.

4. 배포과제(Deployment Challenges)

    점진적 채택 :  QUIC의 상당한 이점을 제공하지만 , 이를 지원하기 위해 기존 인프라를 전환하는 작업은 속도가 느릴 수      있으며, 서버/클라이언트 및 네트워크 인프라를 변경해야 한다.

     호환성 : QUIC를 지원하지 않는 레거시 시스템 및 네트워크와의 호환성을 보장하는 것이 어렵다.

5. 보안문제(Security Concerns)

     새로운 공격 벡터 :  다른 새로운 프로토콜과 마찬가지로 시간이 지남에 따라 식별하고 완화해야 하는 새로운 보안 취약        점이 발생할 수 있다.

6. 표준화 및 생태계 성숙도(Standardization and Ecosystem Maturity)

     초기단계 :  QUIC는 표준화 되었지만 TCP에 비해 여전히 상대적으로 새롭고 주변 생태계(도구, 사례, 광법위한 채택)         은 여전히 성장 중에 있다.

7. 미들박스에 미치는 영향(Impact on Middleboxes)

     검사 및 캐싱 :  로드밸런서 및 캐싱 프록시와 같은 미들박스는 최적화를 수행하기 위해 TCP 트래픽을 검사하는 경우가        많다. QUIC의 암호화를 사용하면 이러한 미들박스는 콘텐츠를 쉽게 검사하거나 캐시할 수 없음으로 잠재적으로 성능        최적화에 영향을 미칠 수 있다.

 

이러한 과제에도 불구하고 성능. 보안 및 안정성 측면에서 QUIC의 장점이 채택을 주도하고 있으며, 지속적인 개발 노력으로 단점을 해결하기 위해 계속 노력하고 있다고 한다.

 

  다음은 QUIC 프로토콜의 일반적인 레이아웃에  대해 알아 보도록 하겠습니다.:))