DCCP: 데이터그램 혼잡 제어 프로토콜

DCCP는 잘못된 계층에서 올바른 접근을 택했다.

인터넷의 전송 계층은 두 가지 선택지를 제공한다. TCP는 전달을 보장하지만 기다림을 요구하고, UDP는 즉시 전달하지만 패킷이 네트워크를 넘쳐나도 신경 쓰지 않는다. 스트리밍 비디오, 실시간 게임, 음성 통화처럼 늦게 도착한 데이터가 아무 가치 없는 애플리케이션에는 둘 다 맞지 않는다. TCP는 손실된 패킷을 재전송하겠다고 고집하며 끊김 지연을 만들어낸다. UDP는 혼잡을 아랑곳하지 않아, 이를 사용하는 애플리케이션을 민폐 덩어리로 만들어 네트워크를 제멋대로 가득 채워버린다.

DCCP는 세 번째 길이 될 예정이었다. 비신뢰적 전달에 기본 혼잡 제어를 결합하는 것이다. 확인 응답을 기다리지 않고 패킷을 보내되, 네트워크가 혼잡해지면 속도를 줄인다. 빠르고 예의 바른 프로토콜. IETF는 2006년에 이를 표준화했다. 그런데 아무도 쓰지 않았다.

DCCP가 해결하려 했던 문제

TCP에는 헤드-오브-라인 블로킹이라는 동작이 있다. 패킷이 손실되면, TCP는 그 패킷이 재전송되어 수신될 때까지 뒤에 오는 모든 것의 전달을 멈춘다. 파일 다운로드에서는 완벽하게 합리적이다. 완전한 파일을 원하니까. 영상 통화에서는 터무니없다. TCP가 이미 필요도 없는 데이터를 열심히 회수하는 동안, 2초 전에 멈춰버린 화면만 바라보고 있는 것이다.

UDP는 단순히 신경 쓰지 않는 방식으로 이 문제를 피한다. 패킷은 오면 오는 것이고, 손실된 패킷은 그냥 사라진다. 애플리케이션은 즉시 데이터를 받는다. 하지만 UDP는 혼잡 제어를 전혀 제공하지 않는다. 애플리케이션은 네트워크 상태에 관계없이 마음껏 패킷을 쏟아낼 수 있다. 모두가 이렇게 하면 네트워크는 무너진다.

책임 있는 해결책은 애플리케이션이 UDP 위에서 자체적인 혼잡 제어를 구현하는 것이었다. 대부분은 그렇게 하지 않았다. 그렇게 한 것들도 종종 틀렸다. 인터넷에는 기본적으로 혼잡 제어를 올바르게 처리하면서도, 스트리밍 애플리케이션이 필요로 하는 낮은 지연과 비신뢰적 전달을 제공하는 프로토콜이 필요했다.

DCCP가 실제로 하는 일

DCCP는 TCP처럼 연결 지향 프로토콜이지만, 보장하는 내용이 근본적으로 다르다. 연결을 수립하고, 순서 번호를 추적하며, 확인 응답을 보낸다. 하지만 그 확인 응답은 재전송을 유발하지 않는다. 네트워크 상태를 측정한다. DCCP가 패킷이 사라지는 것을 감지하면, 이를 혼잡의 신호로 보고 전송 속도를 줄인다.

이 프로토콜은 CCID(혼잡 제어 식별자)라 불리는 교체 가능한 혼잡 제어 알고리즘을 제공한다. 애플리케이션은 필요에 따라 TCP와 유사한 동작, TCP 친화적 전송률 제어, 또는 다른 메커니즘을 선택할 수 있다. 이 유연성이 DCCP의 매력이었다. 스트리밍 애플리케이션은 TCP의 획일적인 방식을 받아들이는 대신, 자신의 트래픽 패턴에 맞게 조정된 혼잡 제어를 선택할 수 있었다.

애플리케이션은 전달된 데이터를 즉시 받아 처리한다. 손실된 패킷은 애플리케이션이 알아서 처리해야 한다. 비디오 프레임을 보간하거나 오디오 공백을 숨기는 식으로. 프로토콜의 역할은 애플리케이션이 네트워크를 과부하시키지 않도록 하는 것이지, 완벽한 전달을 보장하는 것이 아니다.

DCCP가 실패한 이유

첫 번째 문제는 미들박스였다. 방화벽, NAT 장치, 로드 밸런서는 수년에 걸쳐 TCP와 UDP를 처리하는 법을 익혔다. DCCP는 낯선 존재였다. 많은 장치가 DCCP를 완전히 차단했다. 다른 것들은 패킷을 망가뜨렸다. 새로운 전송 프로토콜을 배포한다는 것은 송신자와 수신자 사이의 모든 네트워크 장비가 통과시켜 주도록 설득해야 한다는 뜻이었다. 조율할 주체가 없는 조율의 문제였다.

두 번째 문제는 운영 체제 지원이었다. 리눅스는 커널에 DCCP를 포함하고 있었지만, 기본으로 로드되지 않는 선택적 모듈로서였다. 윈도우 지원은 미미했다. macOS 지원은 사실상 없었다. 애플리케이션 개발자는 사용자의 기기에 DCCP가 사용 가능하다고 가정할 수 없었다.

세 번째 문제는 전형적인 닭과 달걀이었다. DCCP가 널리 지원되지 않으니 애플리케이션이 사용하지 않고, 애플리케이션이 사용하지 않으니 벤더가 지원하지 않았다.

누군가 이 악순환을 끊으려 할 때쯤, 때는 이미 늦어 있었다. 스트리밍 서비스들은 이미 평범한 UDP 위에서 실행되는 정교한 혼잡 제어를 애플리케이션 안에 직접 구축해버렸다. DCCP가 해결하려 했던 문제는 여전히 실재했지만, 해결책은 다른 곳으로 옮겨갔다.

승리한 것들

이제 HTTP/3의 기반이 된 QUIC은 DCCP가 다뤘던 많은 문제를 해결했고, DCCP가 실패한 곳에서 성공했다. 핵심 차이점은 QUIC가 UDP와 나란히 실행되는 것이 아니라 UDP 위에서 실행된다는 것이다.

이 아키텍처 선택이 결정적이었다. 모든 방화벽, NAT 장치, 로드 밸런서는 이미 UDP를 처리하는 방법을 알고 있었다. 네트워크 장비 입장에서 QUIC 패킷은 평범한 UDP 트래픽처럼 보였고, DCCP를 차단했을 인프라를 그대로 통과했다. 네트워크에 새로운 프로토콜을 배우라고 요청하는 대신, QUIC는 기존 제약 안에서 작동했다.

QUIC는 혼잡 제어를 구현하고, 다중 스트림을 통해 헤드-오브-라인 블로킹을 피하며, 기본적으로 암호화를 포함한다. 혼잡을 인식하는 낮은 지연 전달이라는 점에서 DCCP와 유사한 이점을 제공한다. 다만 이상적인 인터넷이 아닌, 실제 인터넷에 배포할 수 있는 방식으로.

WebRTC는 실시간 통신에 비슷한 접근 방식을 취했다. 브라우저에서 실행되는 JavaScript로 혼잡 제어를 구현했다. 이런 해결책들은 깔끔한 전송 프로토콜보다 지저분했다. 전송 계층에 있어야 할 기능을 위로 끌어올려 중복 구현한 것이었다. 하지만 그것들은 작동했고, DCCP는 그러지 못했다.

교훈

DCCP는 기술적으로 건실했다. 잘 설계된 해결책으로 실제 문제를 다뤘다. IETF는 제대로 표준화했다. 구현체도 존재했다. 하지만 그 어느 것도 중요하지 않았다.

인터넷은 백지가 아니다. 새로운 프로토콜은 수십 년간 쌓인 인프라를 헤쳐나가야 하며, 각 부분마다 자체적인 가정과 한계를 지니고 있다. DCCP는 네트워크에 변화를 요구했다. QUIC는 네트워크를 있는 그대로 받아들이고 그것을 우회했다.

이것이 문제를 올바르게 해결하는 것과 성공적으로 해결하는 것의 차이다. DCCP는 인터넷이 받아들일 수 없었던 방식으로 옳았던 프로토콜의 범주에 속한다. 결함이 있어서가 아니라, 인터넷이 이미 선택을 마쳤고 더 이상 다른 의견을 받을 생각이 없었기 때문이다.

DCCP에 관한 자주 묻는 질문

DCCP가 아직 어딘가에서 사용되고 있나요?

DCCP는 네트워크 인프라가 통제되고 미들박스 호환성이 문제가 되지 않는 특수한 환경에서 제한적으로 사용된다. 일부 연구 네트워크와 통제된 배포 환경에서 활용된다. 일반적인 인터넷 애플리케이션에서는 사실상 사용되지 않는다.

DCCP와 애플리케이션 계층 혼잡 제어를 갖춘 UDP의 차이점은 무엇인가요?

기능적으로는 비슷한 결과를 낸다. DCCP는 전송 계층에서 혼잡 제어를 구현하는데, 이는 더 효율적이고 표준화되어 있다. UDP 위의 애플리케이션 계층 혼잡 제어는 이 작업을 사용자 공간에서 중복으로 수행하며, 오버헤드가 더 많고 구현 간 일관성도 떨어진다. DCCP가 더 깔끔하지만, UDP 기반 해결책이 더 배포하기 쉽다.

DCCP가 다시 부활할 수 있을까요?

가능성은 낮다. QUIC가 DCCP가 목표로 했던 사용 사례를 이미 차지했고, 더 나은 배포 특성과 활발한 개발이 뒷받침하고 있다. 생태계는 이미 앞으로 나아갔다. DCCP가 배포에 필요한 인프라 변화를 정당화하려면 QUIC에 비해 설득력 있는 장점이 있어야 하는데, 그런 장점은 없다.

IETF는 왜 미들박스 문제를 예상하지 못했나요?

어느 정도는 예상했다. 하지만 TCP/UDP가 아닌 트래픽에 대한 미들박스의 방해가 어느 정도인지는 실제 배포 시도를 통해 밝혀지기 전까지 충분히 이해되지 않았다. 인터넷이 TCP와 UDP를 중심으로 굳어지는 것은 서서히 일어났고, DCCP는 그 굳어짐이 얼마나 철저했는지 직접 경험한 프로토콜 중 하나였다.