SCTP: 스트림 제어 전송 프로토콜

TCP에는 아무도 이야기하지 않다가 막상 당하면 하루를 망치게 되는 문제가 있다. 패킷 하나가 손실되면, 그 뒤에 있는 모든 것이 멈춘다. 손실된 패킷과 전혀 관계없는 데이터도, 완전히 독립적인 논리적 스트림을 타고 오는 데이터도 전부 기다려야 한다.

이것이 바로 헤드-오브-라인 블로킹이다. 대부분의 애플리케이션에서는 크게 문제가 되지 않는다. 하지만 전화 신호 전송(telephony signaling) 환경에서는 재앙이나 다름없다. 수천 개의 독립적인 통화 설정 메시지가 단일 연결 위를 흐르는 환경에서, 패킷 하나의 손실이 서로 무관한 수천 통의 전화를 지연시켜서는 안 된다.

SCTP(Stream Control Transmission Protocol)는 바로 이 문제를 해결하기 위해 만들어졌다. 그리고 실제로 해결한다. 아주 우아하게.

핵심 개념: 연결 안의 스트림

TCP는 바이트의 순서가 보장된 단일 시퀀스를 제공한다. 전송한 모든 것이 같은 큐에 들어가고, 같은 순서로 전달된다. 실제로는 서로 독립적인 여러 데이터를 보내고 있다는 걸 깨닫기 전까지는 잘 작동한다. TCP는 그 모든 것을 서로 기다리게 만든다.

SCTP는 단일 연결(SCTP에서는 이를 '연관'이라 부른다) 안에 스트림을 도입한다. 각 스트림은 자체적인 순서를 유지한다. 스트림 2에서 패킷이 손실되더라도, 스트림 5는 계속 데이터를 전달한다. 애플리케이션은 데이터가 준비되는 즉시 받을 수 있다. 앞선 모든 것이 도착할 때까지 기다릴 필요가 없다.

웹페이지를 다운로드하는 상황을 상상해 보자. HTML, CSS, JavaScript, 이미지는 각각 독립적이다. JavaScript를 파싱하는 데 이미지가 필요하지 않다. 하지만 TCP는 이 모두를 하나의 큐로 다룬다. SCTP를 사용하면 각각을 별도의 스트림에 할당할 수 있다. 한 스트림에서 손실이 발생해도 다른 스트림은 영향을 받지 않는다.

하나의 연관당 최대 65,535개의 스트림을 만들 수 있다. 이론상으로나 존재하는 한계가 아니다. 실제 데이터 관계를 그대로 모델링할 수 있는 충분한 공간이다.

멀티호밍: 조용한 장애 복구

SCTP 엔드포인트는 여러 IP 주소를 가질 수 있다. 별도의 연결이 아니라, 동일한 연관의 일부로서.

SCTP 연결을 맺을 때, 자신에게 도달할 수 있는 주소 목록을 건넨다. 그중 하나가 기본 경로가 되고, 나머지는 대기한다. 기본 경로가 끊어지면—케이블 단절, 라우터 장애, 네트워크 분리 등—SCTP는 자동으로 백업 주소로 전환한다. 연관은 유지된다. 애플리케이션은 아무것도 눈치채지 못한다.

이 모든 것이 전송 계층에서 일어난다. 애플리케이션 코드도, 로드 밸런서도, 장애 복구 스크립트도 필요 없다. 프로토콜이 알아서 처리한다.

여러 통신 사업자와 연결된 통신 인프라에서 이것은 필수적이다. 광케이블이 끊어진다고 해서 수천 건의 활성 통화가 중단되어서는 안 된다. SCTP는 아직 살아있는 경로를 통해 신호 흐름을 유지한다.

메시지 경계는 실재한다

TCP는 바이트 스트림이다. 500바이트를 보내고, 그다음 300바이트를 보낸다. 수신 측은 200바이트, 그다음 400바이트, 또 200바이트를 받을 수도 있다. 메시지의 시작과 끝을 파악하려면 직접 프레이밍을 구현해야 한다—길이 접두사나 구분자 같은 것들을.

SCTP는 메시지 경계를 보존한다. 500바이트 메시지를 보내면, 500바이트 메시지로 받는다. 별도의 프레이밍 프로토콜도, 재조립 로직도 필요 없다. 이 추상화는 애플리케이션이 실제로 생각하는 방식과 일치한다.

오류 처리도 단순해진다. 완전한 메시지가 도착하거나, 아니면 도착하지 않거나 둘 중 하나다. 부분 메시지도 없고, 절반만 수신된 상태를 복구해야 할 일도 없다.

SCTP가 실제로 쓰이는 곳

SCTP는 전화 신호 전송을 위해 설계되었고, 여전히 그것이 주된 활용처다. 전화 통화가 IP 네트워크 위에서 설정될 때, 신호 트래픽("이 전화를 울려라", "상대방이 받았다"는 메시지들)은 흔히 SCTP를 통해 전달된다. 멀티스트리밍은 수천 개의 독립적인 통화 흐름을 처리하고, 멀티호밍은 통신 사업자 수준의 안정성을 제공한다.

WebRTC는 SCTP의 두 번째 삶이다. 브라우저가 데이터 채널을 설정할 때—오디오/비디오가 아닌, 임의의 데이터를 위한 WebRTC의 영역—SCTP를 사용한다. NAT를 통과하기 위해 UDP 위의 DTLS로 캡슐화되지만, 실제 데이터 채널의 동작 방식은 SCTP에서 비롯된다. 각 WebRTC 데이터 채널은 SCTP 스트림이다. 독립적인 순서 보장. 메시지 경계. 이 기능들이 완벽하게 들어맞는다.

왜 아직도 낯선가

많은 사용 사례에서 SCTP는 TCP보다 기술적으로 우수하다. 그런데 왜 어디서나 쓰이지 않는 걸까?

인터넷이 굳어버렸다.

방화벽은 SCTP를 이해하지 못한다. IP 프로토콜 132를 보면 그냥 버린다. NAT 장치는 SCTP 연관을 추적하는 방법을 모른다. 당신과 나머지 세상 사이에 놓인 중간 장치들은 TCP와 UDP를 위해 만들어졌고, 그 외의 것은 의심스럽다고 취급한다.

운영 체제에는 SCTP 지원이 있지만, 기본적으로 비활성화되어 있거나 커널 모듈을 로드해야 하는 경우가 많다. 애플리케이션은 SCTP가 있을 거라고 믿을 수 없기 때문에 사용하지 않는다. SCTP가 없는 이유는 애플리케이션이 사용하지 않아서다. 이 순환은 끊어지지 않는다.

그동안 TCP는 HTTP/2 멀티플렉싱을 얻었다. 애플리케이션 계층에서 헤드-오브-라인 블로킹을 (어느 정도) 해결한 것이다. QUIC은 UDP로 이전하여 신뢰할 수 있는 전송을 재구현함으로써 이를 제대로 해결했다. SCTP가 해결했던 문제들이 다른 방식으로 해결된 것이다.

SCTP는 기술적으로 우수한 프로토콜이지만, 수십 년 전에 TCP를 선택하고 그 주위에 벽을 쌓아버린 세상에 갇혀 있다. 이 프로토콜이 살아남는 이유는 통제된 환경 덕분이다—SCTP가 내부적으로 운영되는 통신 네트워크, 그리고 인터넷의 중간 장치 문제가 적용되지 않는 UDP 캡슐화 방식의 WebRTC.

SCTP를 이해하면 중요한 사실을 깨닫게 된다. 최고의 프로토콜이 항상 이기는 것은 아니다. 때로는 기존 기반이 이긴다. 때로는 중간 장치가 이긴다. 때로는 '충분히 좋고 모든 곳에 배포된 것'이 '더 낫지만 패킷이 버려지는 것'을 이긴다.

SCTP에 관해 자주 묻는 질문

SCTP는 TCP와 무엇이 다른가요?

TCP는 순서가 보장된 단일 바이트 스트림을 제공한다. 보낸 모든 것이 앞선 것들 뒤에 줄을 서서 기다린다. SCTP는 하나의 연결 안에 독립적인 여러 스트림을 제공하고, 실제로 보낸 메시지 그대로의 경계를 유지하며, 여러 IP 주소 사이에서 자동으로 장애를 복구한다. TCP는 더 단순하고, SCTP는 더 강력하다.

공개 인터넷에서 SCTP를 사용할 수 있나요?

기술적으로는 가능하지만, 현실에서는 자주 그렇지 않다. 많은 방화벽과 NAT 장치가 프로토콜을 인식하지 못해 SCTP 패킷을 버린다. 통제된 네트워크(통신 인프라 등)에서나, SCTP가 UDP에 캡슐화된 경우(WebRTC 등)에는 잘 동작하지만, 공개 인터넷에서의 순수 SCTP는 중간 장치를 통과하지 못하는 경우가 많다.

헤드-오브-라인 블로킹이란 무엇인가요?

순서 보장 전달로 인해, 손실되거나 지연된 데이터가 그 뒤에 있는 모든 것을—관련 없는 데이터까지—막아버리는 현상이다. TCP는 모든 것이 하나의 시퀀스를 공유하기 때문에 이 문제가 있다. SCTP는 각 스트림에 자체 시퀀스를 부여하여 이를 해결한다. 한 스트림의 손실이 다른 스트림을 지연시키지 않는다.

WebRTC는 왜 SCTP를 사용하나요?

WebRTC 데이터 채널에는 메시지 경계(바이트 스트림이 아닌), 여러 개의 독립적인 채널, 그리고 유연한 신뢰성 옵션이 필요하다. SCTP는 이 모든 것을 기본으로 제공한다. NAT를 통과하기 위해 UDP 위의 DTLS로 캡슐화되지만, 실제 채널의 동작 방식은 SCTP에서 비롯된다.