요약

  • RFC 3450은 각 수신자가 충분한 FEC(전방 오류 정정) 심벌을 수집하면 객체를 재구성할 수 있게 했으며, 누락된 개별 패킷의 재전송을 발신자에게 요구하지 않았고 발신자 부하가 수신자 수에 좌우되지도 않았습니다.
  • 이 확장성은 핵심 프로토콜에서 수신 확인 채널을 제거했습니다. 세션 탐색, 완료 성공 보고, 객체 전체 무결성, 애플리케이션 사용은 서로 다른 메커니즘이자 서로 다른 주장으로 남았습니다.

호명 절차 없는 신뢰성

신뢰성 있는 멀티캐스트의 어려움은 단순히 동일한 패킷을 다수의 목적지로 보내는 일이 아니었습니다. 진짜 문제는 모든 분실 패킷이 요청을 만들고 수신자가 추가될 때마다 발신자의 복구 부담이 늘어나는 제어 체계를 피하는 것이었습니다. 2002년 12월에 발표된RFC 3450은 ALC(비동기 계층화 코딩, Asynchronous Layered Coding)를 세 가지 구성 요소로 구현했습니다: LCT(Layered Coding Transport) 빌딩 블록, 다중 전송률 혼잡 제어 빌딩 블록, 그리고 FEC 빌딩 블록입니다.

그 확장 가정은 의도적으로 매우 컸습니다. 하나의 세션은 수백만 명의 동시 수신자를 서비스할 수 있었고, 객체는 수백 킬로바이트에서 수백 기가바이트에 이를 수 있었으며, 수신자들은 서로 다른 시점에 합류하고 서로 다른 경로를 사용할 수 있었습니다. 각 수신자는 채널에 가입하거나 이탈하며 수신률을 조정했습니다. 발신자는 인코딩 심벌을 계속 내보냈습니다. 수신자가 충분한 심벌 집합을 확보하면 객체를 재구성하고 세션을 떠날 수 있었습니다.

이 절차는 누락된 패킷마다 요청을 보낼 필요가 없었고, 발신자에게 수신자 피드백을 보낼 필요도 없었습니다. 명세는 그 결과를 특유의 명확한 운영 언어로 서술했습니다: 발신자 관점에서 수신자 한 명과 백만 명은 서로 다른 부하나 전송률을 만들 필요가 없다는 것입니다.RFC 원문,RFC Editor 기록,Datatracker 파일,문서 연혁,참고문헌,이후 인용,정오표 검색이 그 설계 기록을 확립합니다. 이들 자료는 실제 어떤 배포가 몇 명의 수신자를 서비스했는지는 확립하지 않습니다.

충분한 심벌은 동일한 패킷이 아니었다

FEC는 복구의 단위를 바꿨습니다. 발신자는 객체에서 인코딩 심벌을 도출했습니다. 수신자는 다른 수신자와 동일한 패킷 이력을 가질 필요가 없었습니다. 선택한 코드에서 사용 가능한 심벌을 충분히 확보하면 그만이었습니다. 두 수신자가 서로 다른 패킷을 잃고 서로 다른 시점에 합류하더라도 동등한 바이트열을 재구성할 수 있었습니다.

이것은 패킷 전달과 객체 복구 사이의 심오한 분리였습니다. 패킷 손실은 여전히 실재했지만, 복구는 더 이상 각 결여를 하나하나 재생하는 데 의존하지 않았습니다.RFC 3452가 FEC 빌딩 블록 프레임워크를 정의했고,RFC 3453이 그 계열에서 사용 가능한 컴팩트 무코드 및 패리티 코드 방식을 서술했습니다. ALC는 FEC Payload ID를 LCT 자료 옆에 두어 수신자가 객체의 맥락에서 심벌을 해석할 수 있게 했습니다.

그럼에도 이 메커니즘에는 디코딩 좌표가 필요했습니다. FEC 객체 전송 정보(FEC 주체 Transmission Information)는 어떤 방식과 매개변수가 객체를 지배하는지 등을 수신자에게 알려야 했습니다. 그 일부는 대역 내(in-band)로, 일부는 대역 외(out-of-band)로 도착할 수 있었습니다. RFC 3450은 이 필요성을 명시했지만 통신 방법은 의도적으로 자신의 범위 밖에 두었습니다. 따라서 “충분함”은 충분한 심벌에 그 심벌을 이해하는 데 필요한 정보까지 더한 것을 뜻했으며, 메타데이터로부터의 마법 같은 독립이 아니었습니다.

신원은 범위가 정해졌지, 보편적이지 않았다

합류 전에 수신자는 세션 기술서(Session Description)를 확보해야 했습니다. 세션 기술서는 혼잡 제어 빌딩 블록, 발신자 주소, 채널, 포트, 전송 세션 식별자(TSI), 객체 다중성, 확장 형식, 관련 인증 정보를 명명했습니다. 기술서는 웹 페이지, 공지 프로토콜, 이메일 또는 다른 메커니즘을 통해 도착할 수 있었습니다. ALC는 그 획득 경로를 정의하지 않았습니다.

패킷 스트림 내부에서는 발신자 IP 주소와 TSI가 함께 세션을 식별했습니다. 전송 객체 식별자(TOI)가 그 세션 안에서 객체들을 구분했습니다. 이들은 라우팅 및 역다중화 좌표지, 전역 식별자가 아니었습니다. 동일한 객체가 다른 세션에서 다른 TOI를 가질 수 있었고, 발신자-세션 범위 밖에서 숫자가 일치하는 것 자체는 아무것도 증명하지 못했습니다.

이 구분이 중요한 이유는 식별자가 운영자에게 로그 내용을 과장할 유혹을 주기 때문입니다. TSI와 TOI를 보여주는 기록은 어떤 패킷이 프로토콜 좌표와 연관되어 있었음을 증명할 수 있습니다. 하지만 그것만으로 객체가 재구성되었거나, 그 바이트가 무결성 검사를 통과했거나, 특정 법적 수신자가 받았거나, 애플리케이션이 그것을 사용했다는 것을 증명할 수는 없습니다.

종료 플래그는 전송을 닫았지, 증거의 공백을 닫지 않았다

ALC는 LCT에서 Close Session 및 Close 주체 플래그를 계승했습니다. 이 플래그들은 발신자가 전송이 곧 끝날 것임을 표시할 수 있게 했습니다. 그러나 RFC 3450은 이들을 완전히 신뢰할 수 있는 메커니즘이 아니라 힌트로 규정했습니다. 플래그가 붙은 마지막 패킷들 자체가 분실될 수 있었고, 수신자가 너무 늦게 합류할 수 있었으며, 발신자가 전송을 멈출 때 수신자가 아직 충분한 심벌을 확보하지 못했을 수도 있었습니다.

푸시 서비스 예제는 이 경계를 명시적으로 만들었습니다. 재구성을 완료한 수신자는 성공을 보고할 수 있었고, 애플리케이션은 모든 의도된 수신자가 보고하거나 다른 정지 규칙이 충족될 때까지 발신자가 전송을 계속하도록 할 수 있었습니다. 그러나 그 보고는 애플리케이션에 속한 것이었습니다. ALC는 보고 메커니즘, 수신자 명부, 완료 장부를 정의하지 않았습니다.

따라서 성공적으로 재구성된 객체와 발신자 측 수신 확인은 서로 다른 사실이었습니다. 첫 번째는 두 번째 없이 존재할 수 있었습니다. 반대로 애플리케이션 보고는 잘못 생성되거나, 나중에 무결성 검사에서 실패하는 객체를 가리킬 수도 있었습니다. 완전한 시스템이 이 사실들을 연결할 수 있지만 그 책임성은 추가된 애플리케이션 프로토콜에서 나오는 것이지 ALC 단독에서 나오는 것이 아닙니다.

트랜스포트는 신뢰 앞에서도 멈췄다

수신자별 대화가 없다는 것은 위조된 멀티캐스트 트래픽을 특히 위험하게 만들었습니다. 하나의 손상된 심벌이 대규모 재구성을 오염시킬 수 있었고, 많은 수신자가 동일한 위조품을 수용할 수 있었습니다. RFC 3450은 패킷 인증과 객체 전체 무결성 검사를 권고했으며, 가능하면 검증 가능한 디지털 서명을 사용할 것을 권했습니다. 재구성 결과가 객체 수준 검사를 실패하면 수신자는 그것을 폐기해야 했습니다.

이것은 또 하나의 경계를 만들었습니다. FEC는 충분한 코딩된 자료가 바이트를 복구할 수 있는지에 답했습니다. 인증은 패킷이 어디에서 왔고 수용 가능한지에 답했습니다. 객체 서명은 재구성된 바이트가 서명된 객체와 일치하는지에 답했습니다. 그 어느 검사도 어떤 수신자가 결과를 수용했거나 사용했는지를 발신자에게 알려주지 않았습니다.

이 프로토콜은 혼잡 제어에도 의존했습니다.RFC 2357은 신뢰성 있는 멀티캐스트에 충분한 혼잡 제어를 요구했고, RFC 3450은 작업 그룹이 충분한 근거를 기다리는 동안 실험적(Experimental) 상태를 유지했습니다.RFC 3048이 빌딩 블록 아키텍처를 제공했고,RFC 3269가 작성자 지침을 제공했으며,RFC 3451이 LCT를 명세했습니다. 기반 멀티캐스트는RFC 1112의 계보에서 왔고, 소스별(source-specific) 운영은 이후RFC 4607에서 정식화되었습니다.RFC 5775는 축적된 경험을 바탕으로 하위 호환성을 유지하는 제안 표준(Proposed Standard)으로서 결국 RFC 3450을 대체했습니다. 이 진행은 프로토콜 개정을 증명할 뿐, 보편적 채택을 증명하지 않습니다.

확장은 주장을 좁게 유지하는 대가로 구매되었다

Lu Heng의현실 계층 훈련은 역사적 교훈을 선명하게 만듭니다. 수신된 심벌, 재구성된 객체, 검증된 무결성, 바이트를 수용한 애플리케이션, 성공을 보고한 수신자, 그 보고를 기록한 발신자는 여섯 가지 서로 다른 사건입니다. 이를 “전달됨”이라는 한 단어로 묶으면 대시보드는 편리해지지만 감사는 불가능해집니다.

구동 코드 우선주의는 여기서 주장이 관찰 가능한 메커니즘을 따라야 한다는 요구로 나타납니다. ALC는 자신의 수신자 구현이 무엇을 재구성했는지 증명할 수 있었지만, 부재하는 완료 장부에 대한 권위는 얻지 못했습니다.최소 초기 명세관점은 이 절제를 설명합니다: 먼저 확장 가능한 전송을 해결하고, 애플리케이션이 실제로 필요로 하는 보고를 추가하도록 두라는 것입니다. 이것은 편집자의 해석이지 RFC 저자들의 사적 의도에 대한 진술이 아닙니다.

따라서 RFC 3450의 내구성 있는 통찰은 양날의 검입니다. 확인 응답을 핵심에서 제거한 것이 거대한 청중을 가능하게 했습니다. 동시에 그것은 정직한 불확실성을 의무화했습니다. 신뢰성은 회복 가능한 콘텐츠를 의미할 수 있지만, 발신자가 모든 수신자, 모든 완료, 모든 사용을 알고 있었다는 의미는 아니었습니다.

출처