요약

  • RFC 8085는 UDP를 선택하는 애플리케이션이 워커나 소켓이 개별적으로 트래픽을 생성하더라도 특정 목적지로 보내는 모든 UDP 트래픽을 통제해야 한다고 규정합니다. 소켓 수는 책임의 이전이 아닙니다.
  • 용량이 예약된 제한된 환경은 실질적인 격리 경계와 책임 있는 운영 결정이 있을 때에만 비적응 모드를 정당화할 수 있습니다. 그것이 기본값이 되어서는 안 되며, 일반 인터넷 경로로 새어 나가서도 안 됩니다.

빈 소켓이라는 편리한 허구

엔지니어는 UDP 소켓을 열고, 워커에 넘기고, 연결 설정이나 내장된 혼잡 윈도우 없이 데이터그램을 보낼 수 있습니다. 이 단순성은 가치가 있습니다. 실시간 미디어, 탐색(discovery), 터널링, 게임, 측정, 그리고 UDP 위에서 서로 다른 트레이드오프를 구현하는 전송 프로토콜에 자리를 마련해 줍니다.

그러나 이는 잘못된 결론으로 유인하기도 합니다. 운영체제가 연결 상태를 만들지 않았기 때문에 각 송신자는 작고 독립적으로 보일 수 있습니다. 열여섯 개의 워커, 여러 컨테이너, 변하는 소스 포트 범위를 가진 서비스는 마치 무해한 발신자가 열여섯, 혹은 수백 개 있는 것처럼 보일 수 있습니다. 경로는 조직도를 보지 않습니다. 유한한 용량을 두고 경쟁하는 패킷을 볼 뿐입니다.

RFC 8085는 이 물리적 경계에서 시작합니다. UDP는 내재된 혼잡 제어 메커니즘이 없는 최선형(best-effort) 메시지 전달 전송입니다. 많은 플랫폼에서 애플리케이션은 종단 간 경로가 감당할 수 없는 속도로도 자신의 링크 속도까지 전송할 수 있습니다. 이 차이는 회계상 세부사항이 아닙니다. 큐잉, 손실, 지연, 그리고 다른 플로우에서 밀려난 작업으로 나타납니다.

이 문서는 그러한 행동을 통제해야 하는 두 가지 이유를 제시합니다. 부하가 늘어날수록 유용한 작업이 줄어드는 혼잡 붕괴를 피하는 것과, 경로를 공유하는 트래픽에 어느 정도의 공정성을 확보하는 것입니다. 어느 이유도 포트가 세션이라고 불리거나 프로세스가 별개의 애플리케이션이라고 불리는 것에 좌우되지 않습니다.

집계 규칙이 어려운 부분이다

Lars Eggert, Gorry Fairhurst, Greg Shepherd는 이 지침에 특히 실무적인 문장을 부여했습니다. 혼잡 제어 전송을 사용하지 않기로 선택한 애플리케이션은 목적지로 UDP를 보내는 속도를 통제해야 하며, 더 중요하게는 그 트래픽이 어떻게 생성되든 상관없이그곳으로 보내는 모든UDP 트래픽에 걸쳐 통제해야 합니다. 워커를 포크하거나 여러 소켓을 할당한다고 책임이 분할되지 않습니다.

이 문장은 하나의 보편적 집계 키를 강제하지 않습니다. 서비스는 목적지 주소, 경로 집합, 터널, 테넌트, 미디어 세션 또는 기술적으로 정당화되는 다른 단위로 집계할 수 있습니다. RFC는 패킷 손실이 항상 하나의 원인을 갖거나 애플리케이션이 가용 용량을 완벽하게 추론할 수 있다고 약속하지 않습니다. 다만 책임의 방향을 정합니다. 회계를 편리하게 만드는 프로세스 경계가 아니라, 자신의 설계가 만들 수 있는 경합을 반영하는 집계를 선택하라는 것입니다.

운영자에게 이는 보존할 가치가 있는 증거를 바꿉니다. 소켓 테이블은 프로세스의 존재를 보여줄 수 있습니다. 그러나 그것만으로 집계 전송률, 피드백, 손실 대응, RTT 추정치, 경로 범위, 형제 프로세스가 공유하는 속도 제어 상태를 보여주지 못합니다. 프로세스별 속도 제한기는 집계 역시 한정되어 있을 때에만 정당할 수 있습니다. 사후 합계 그래프는 패킷이 허용된 시점에 제어가 존재했다는 것을 증명할 수 없습니다.

같은 문제는 오토스케일링에서도 나타납니다. 워커를 추가하면 각 워커가 자체 로컬 예산 안에 머무는 동안 집계 속도는 올라갈 수 있습니다. 따라서 배포 기록은 스케일 이벤트, 목적지 또는 경로 그룹화, 피드백 출처, 속도 정책, 관측된 집계를 연결해야 합니다. 이는 보편적인 대시보드 요구가 아닙니다. 의도적 공유와 우발적 곱셈을 구별하기 위한 최소한의 영수증입니다.

로컬 선택이 무비용 선택을 의미하지는 않는다

RFC 8085는 UDP를 폐지하라는 명령이 아닙니다. 이 장비를 잘 구현하는 것이 어렵기 때문에 대부분의 애플리케이션에 기존의 혼잡 제어 IETF 전송을 권장합니다. TCP, SCTP, DCCP가 선택지로 언급되며, 이후의 전송 프로토콜은 다른 접근을 제공할 수 있습니다. 이 권고는 결정을 애플리케이션 설계자와 운영자에게 남겨 둡니다.

이 지역적 결정 표면은 Lu Heng의 최소 명세(minimum-specification) 교리와 일치합니다. 공통 요구사항은 중앙에서 선택된 구현이 아니라 인터넷 경로에서의 공유된 안전성입니다. 송신자는 전송 프로토콜, 피드백 방법, 페이싱 알고리즘, 터널 설계, 배포 프로필을 선택할 수 있습니다. 그러나 무한정인 로컬 선호를 다른 사람이 설명할 수 없는 큐로 만드는 것은 선택할 수 없습니다.

RFC는 인터넷을 향하는 애플리케이션이 고정된 경로 용량, 지연, 손실률, 메시지 크기, 재정렬 동작을 가정하지 않도록 요구합니다. 같은 경로에서도 조건은 변합니다. 방어 가능한 구현은 보수적으로 탐색하고, 피드백에 적응하며, 불확실성을 가시화합니다. RFC를 발행하는 것은 이러한 행동을 수행하지 않습니다. 그것을 수행하는 것은 실행되는 코드와 그것을 운영하는 사람들입니다.

이것이 바로 "커넥션리스(connectionless)"가 오해를 낳는 거버넌스 은유인 이유입니다. 그것은 전송 속성을 설명할 뿐, 송신자의 속도와 다른 플로우의 지연 사이의 인과 연결을 끊지 않습니다. 애플리케이션이 자신의 트래픽을 연결이라고 부르든 부르지 않든, 경로는 공유된 제약을 제공합니다.

예외는 그 자체의 증거를 가져야 한다

RFC 8085는 흔히 허점으로 오해되는 제한된 사례를 허용합니다. 대량 전송 애플리케이션은 제한된 환경에서 적응형 혼잡 제어 메커니즘 대신 예약된 경로 용량에 의존할 수 있습니다. 하나의 책임 있는 운영자가 관련 용량과 트래픽 경계를 통제하는 경우에는 합리적일 수 있습니다.

그러나 이 허용에는 조건이 있습니다. 통제되지 않거나 비적응 모드는 기본값이 아니어야 합니다. 사용자가 명시적으로 활성화해야 하고, 운영자는 충분한 용량이 예약되었음을 검증해야 합니다. 그 트래픽이 프로비저닝되지 않은 인터넷 경로로 빠져나가면 동시 트래픽을 저하시키고 혼잡 붕괴에 기여할 수 있습니다.

중요한 단어는 "예약"만이 아니라 예약, 격리, 그리고 살아 있는 송신자 사이의 관계입니다. 구성 레이블은 이그레스가 변경되었는지, 터널이 연장되었는지, 경로가 누출되었는지, 스케일아웃이 속도 정책을 우회했는지 증명할 수 없습니다. 예외 기록에는 그것이 다루는 경로나 도메인, 용량 결정, 그 결정의 소유자, 포함되는 트래픽 클래스, 시간 한도, 그 경계 밖에서 적응형 동작을 복원하는 스위치가 필요합니다.

이것이 올바른 규모에서의 자발적 채택입니다. RFC는 권고하고, 운영자가 제한된 프로필이 실질적인지 판단하며, 네트워크와 애플리케이션 코드가 그 결정을 관측 가능하게 만들어야 합니다. BCP 안에 보편적 집행 기관이 숨어 있는 것은 아닙니다. 그러나 검증되지 않은 예외를 무해하다고 부를 정직한 근거도 없습니다.

차단기는 조향 휠이 아니다

RFC 8085와 함께 발표된 RFC 8084는 네트워크 전송 서킷 브레이커를 다룹니다. 차단기는 심각한 과부하에 대한 최후의 보호 장치이며, 정상 시스템이 안전 범위를 벗어난 것을 발견했을 때 플로우나 집계를 제한할 수 있습니다. 고장 난 제어기가 무한히 계속되도록 허용해서는 안 되기 때문에 가치가 있습니다.

그러나 그렇다고 차단기가 평범한 혼잡 제어가 되는 것은 아닙니다. 화재 경보기는 건물의 일일 점유율을 관리하지 않습니다. 서킷 브레이커는 위험한 조건이 명백해진 후 트래픽을 중단하거나 강하게 제한할 수 있지만, 정상 운영 중 건강한 애플리케이션이 필요로 하는 지속적인 적응, 측정, 공정성 동작을 공급할 수 없습니다. 차단기를 정책 전체라고 부르는 것은 그 목적을 거꾸로 만드는 일입니다.

기록은 인정하되 권한을 발명하지 않는다

RFC Editor는 RFC 8085를 Eggert, Fairhurst, Shepherd가 2017년 3월에 저술한 IETF Best Current Practice로 등재합니다. 이는 RFC 5405의 이전 유니캐스트 지침을 대체하였으며, 데이터그램 전송을 위한 패킷화 계층 경로 MTU 탐색을 명시한 RFC 8899에 의해 갱신되었습니다. Eggert의 공개 IETF 프로필은 RFC 저술뿐 아니라 기술 리더십과 봉사를 기록합니다.

이러한 기록은 문서화된 기여를 확립할 뿐, UDP에 대한 개인적 주권을 확립하지 않습니다. IETF 합의는 저자를 클라우드 서비스, 트랜짓 네트워크 또는 미래 프로토콜의 운영자로 만들지 않았습니다. 애플리케이션은 여전히 자신의 메커니즘을 선택하고, 운영자는 여전히 자신의 도메인과 용량을 정하며, 경로는 여전히 코드가 해석해야 하는 피드백을 전달합니다. 사람 중심 기사는 표준 저자를 가공의 집행 권위로 만드는 대신 그 분업을 보존할 때 유용합니다.

증거의 한계

인용된 출처는 어떤 UDP 프로토콜의 현재 트래픽량, 특정 벤더의 내부 속도 제어 설계, 또는 모든 집계를 그룹화하는 단일한 올바른 방법을 보여주지 않습니다. 모든 손실 이벤트가 혼잡이거나, 모든 UDP 배포가 불안전하거나, 서킷 브레이커가 공정성을 증명한다고 말하지도 않습니다. 여기서 제안된 운영 기록은 특정 사건의 보고가 아니라 RFC 8085가 명시한 책임 경계로부터의 추론입니다.

출처