리눅스 커널을 위한 QUIC

• QUIC 프로토콜이 리눅스 커널에 공식적으로 통합되는 첫 패치가 제출됨
• 기존 TCP가 가진 한계점(지연, head-of-line blocking, 중간 장치로 인한 프로토콜 고착화 등)들을 개선하려는 목적
• QUIC은 UDP 기반으로 멀티스트림 지원과 End-to-End 암호화 기능을 제공하며, 커널 도입 시 더 넓은 플랫폼 및 하드웨어 활용 가능성 높음
• 초기 커널 구현의 성능은 기존 TCP 및 커널 TLS에 비해 낮게 측정되었지만, 향후 하드웨어 오프로딩과 최적화를 통해 성능 개선 기대 가능함
• 현재 Samba, 커널 기반 SMB/NFS, curl 등에서 지원 논의가 활발하게 이루어지고 있지만, 메인라인 합병까지는 시간이 더 소요될 전망임

QUIC 프로토콜의 등장 배경 및 TCP의 한계점

• QUIC은 기존 인터넷에서 TCP가 가진 다양한 문제점을 해결하려는 목적으로 만들어짐
• TCP의 연결 과정에서 발생하는 3-way 핸드셰이크로 인한 지연, 멀티스트림 지원 미흡, 패킷 손실에 따른 head-of-line blocking 현상 등으로 웹 사용 경험이 저하됨
• TCP의 메타데이터가 암호화되지 않은 채 전송되어 정보 유출 위험이 존재하고, 인터넷의 미들박스(중간 장치) 들이 연결 정보를 바탕으로 트래픽을 필터링, 그 결과 프로토콜의 고착화(ossification) 로 발전함
• TCP 개선 시도(예: Multipath TCP 등)도 기존 TCP로 위장하지 않으면 정상적으로 작동하지 못하는 상황임

QUIC의 특징 및 기술적 장점

• QUIC은 UDP 위에서 동작하며, 연결 과정에서 별도의 3-way 핸드셰이크 없이 빠르게 연결 설정 가능함
• 패킷 손실이 전체 스트림에 영향을 주지 않도록 멀티스트림 전송 설계가 반영됨
• QUIC 관련 전송 데이터는 항상 종단 간 암호화(TLS 기반) 되어, 중간 장치가 내부 메시지에 접근할 수 없게 됨
• UDP 패킷이 통과할 수 있는 네트워크 환경이라면 QUIC 역시 정상적으로 동작 가능함

리눅스 커널 내 QUIC 통합 패치 개요

• 제출된 패치에서는 IPPROTO_QUIC라는 새로운 프로토콜 타입이 도입되어, 기존 socket() 시스템 콜을 활용 가능함
• TCP와 유사하게 bind() , connect() , listen() , accept() 등의 콜을 사용할 수 있지만, 이후 처리 방식에는 차별점이 존재함
• TLS 세션 관리 및 인증/암호화 과정은 사용자 공간에서 처리되며, 연결 후에 각 단에서 TLS 핸드셰이크가 완료되어야 데이터 송수신이 가능함
• 초기 연결 이후에는 TLS 협상 결과를 캐싱하여, 두 시스템간 재연결 시 속도를 크게 높일 수 있음

성능 측면의 과제 및 전망

• 제출된 커널 내부 QUIC 구현은 아직 성능 면에서 기존 커널 TLS 및 TCP 대비 열세를 보임
  • 인커널 TLS 대비 3배 이하 처리량, 암호화 비활성화 시에도 TCP에 비해 최대 4배까지 처리량 저조
• 원인으로는 세그멘테이션 오프로딩 미지원, 송신 경로 내 추가 데이터 복사, 헤더 암호화 과정 등이 지적됨
• 향후 하드웨어 오프로딩 지원이 추가되고, 인커널 구현이 최적화되면 성능이 향상될 것으로 기대됨

채택 현황과 향후 전망

• Samba 서버/클라이언트, 커널 SMB 및 NFS 파일시스템, curl 등 다양한 프로젝트에서 인커널 QUIC 지원 논의가 활발함
• 패치는 약 9,000 라인 규모이며, 현재 저수준 지원 코드만 포함되어 있음. 전체 구현은 추가 패치로 예고된 상태임
• 코드 리뷰 및 병합 논의가 이제 막 시작된 단계로, 실사용까지는 시간이 더 소요될 전망임
  • 최근 Homa 프로토콜의 커널 병합이 9개월간 11회 제출이 필요했던 전례를 볼 때, QUIC 역시 2026년 이후 메인라인 진입이 예상됨