인터넷 표준으로 사용돼 온 통신 프로토콜(규약)이 대체될 가능성이 제기되고 있다. 인터넷 기술 표준화단체 ‘IETF’가 지난 5월 27일 새로운 프로토콜 ‘퀵(QUIC)’을 기술 사양 RFC9000으로 권고함에 따라, QUIC가 오랫동안 사용돼 온 ‘TCP’를 대체할 지에 관심이 쏠리고 있는 것이다.
IETF가 표준화한 QUIC는 2013년에 미국 구글이 발표한 대량의 액세스를 고속으로 처리하는 프로토콜 ‘QUIC’을 발전시킨 것이다. 구글의 QUIC는 웹 전용으로 ‘UDP’라는 통신 프로토콜을 이용해 독자의 암호화 기술을 구축했다.
구글은 2015년에 차세대 웹 통신 프로토콜로 IETF에 제출했다. IETF에서 논의를 거듭한 결과, 통신을 암호화하는 ‘TLS’를 기반 기술로 사용하는 것, 웹 브라우저 등에서 사용하는 HTTP 이외의 프로토콜을 사용할 수 있도록 하는 것 등이 포함돼, 이번에 QUIC로 표준화됐다. 또한 QUIC를 사용한 차세대 웹 통신 프로토콜을 ‘HTTP/3’라고 부른다.
QUIC의 특징은 크게 4 가지. 1)TCP에 해당하는 재전송 제어 장치 2)통신 개시 시의 결정사항(핸드 쉐이크)의 감소에 따른 통신 효율화 3)다중 통신 경로(스트림) 이용에 의한 통신의 효율화 4)TLS 암호화이다.
기존의 웹 통신은 TCP와 TLS를 사용했다. QUIC는 UDP를 이용하기 때문에 TCP와 동등한 재전송 제어를 장착했다. TLS를 QUIC의 일부로 끌어들여 암호화도 실시한다. 그 결과, 종래는 TCP와 TLS에서 각각 필요했던 핸드 쉐이크를 TLS 한 번으로 줄일 수 있다.
또한 QUIC에서는 ‘헤드 오브 라인 블록’의 문제를 피할 수 있다. 헤드 오브 라인 블록은 선행하는 패킷이 도착하지 않는 경우 재전송이 완료될 때까지 후속 패킷을 처리할 수 없다는 문제이다. 기존의 웹 통신에서는 단일 통신 경로를 사용하고 있기 때문에, 선행하는 패킷이 손실되면 후속 패킷을 처리할 수 없다.
QUIC을 사용한 통신은 복수의 스트림을 구축하고 동시에 데이터를 주고받는다. 이에 따라 어떤 스트림에서 오류가 발생해 재전송 처리가 필요해도 다른 스트림에서 동시에 데이터를 전송할 수 있다. 비록 선행 패킷에 손실이 발생해도 패킷 단위로 개별적으로 재전송할 수 있으므로 헤드 오브 라인 블록 문제를 피할 수 있다.
이 밖에 QUIC은 통신 환경이 무선 LAN에서 LTE 등의 모바일 통신으로 전환하는 것과 같은 커넥션 마이그레이션에 강한 것으로 돼 있다. 클라이언트 고유의 커넥션 ID를 기반으로 연결 상태를 관리하기 위해서다. 따라서 통신 환경이 바뀌어 IP 주소나 포트 번호가 변경돼도 통신을 유지할 수 있다.
오스트리아 Q-Success의 조사자료에 따르면 2021년 6월 7일 현재, HTTP/3(QUIC을 사용하는 HTTP)을 사용한 웹 통신은 전체의 20%에도 미치지 못한다. 하지만 주요 웹 브라우저는 QUIC이 지원된다. PC에서 QUIC을 사용하려면 웹 브라우저를 최신 버전으로 하고 해당 기능을 사용하기만 하면 된다.
한편, 웹 어플리케이션을 제공하는 서버 측의 대응은 앞으로의 일이다. 구글이 제공하는 웹 서비스를 비롯해, 이미 QUIC를 사용한 통신을 지원하는 웹 서비스나 어플리케이션은 존재한다. 그러나 ‘Apache(아파치) HTTP Server’나 ‘nginx(엔진 X)’ 등의 주요 웹 서버 소프트웨어는 아직 시험 단계에 있다.
또 웹 브라우저 이외의 어플리케이션을 QUIC에 대응시키려면 어플리케이션 내에 QUIC의 처리를 장착해야 한다. 몇몇 업체에서 QUIC용 소프트웨어 부품을 공개하고 있지만, 어플리케이션의 실행 환경에 따라 사용할 수 있는 버전이나 제조원이 다르면 어플리케이션의 보수가 복잡해질 우려도 있다.
QUIC이 TCP 대타로 사용되려면 아직 시간이 걸릴 것이다.