요약
- 선택 사항인 Complete 필터링 컬렉션에는 성공한 작업뿐 아니라 더 이상 새로운 갱신이 없을 processed 요청도 포함됩니다. 이 분류가 전반적 성공과 동일하지는 않습니다.
- 개별 complete 상태는 관련된 모든 작업이 성공해야 함을 요구하며, 영향을 받는 후속 CDN도 포함됩니다. 중개자는 하위 CDN의 processed를 확인된 성공으로 바꿀 수 없습니다.
- 예상 완료 시점은 계획 수립에 도움이 되지만 실행을 증명하지는 않습니다. 이 인터페이스는 상호 연결된 CDN 간의 시계 동기화를 요구하지 않습니다.
- 무효화, 퍼지, 사전 인출, 취소, 보고서 삭제는 서로 다른 효과를 갖습니다. 다음 결정은 실제로 필요한 결과가 무엇인지 식별해야 합니다.
- 아래의 교체 시나리오는 사양에 대한 분석이며, 관측된 사고나 상용 도입률에 대한 측정이 아닙니다.
큐가 너무 일찍 비워질 때
콘텐츠 운영자가 동일한 URL에서 자료를 교체하려 합니다. 먼저 배포 파트너에게 이전 버전을 퍼지하도록 요청합니다. 그 후에야 새 콘텐츠의 사전 인출을 원합니다. 이 순서에는 구체적인 이유가 있습니다. 오래된 퍼지가 새로 업로드된 자료에 영향을 주는 것을 막기 위함입니다.
파트너는 요청을 수락합니다. 이후 상태 리소스가 Complete 컬렉션에 나타납니다. 대시보드는 해당 요청을 더 이상 추적 중인 활동으로 표시하지 않습니다. 다음 단계를 진행하기 좋은 시점처럼 보입니다.
그러나 개별 상태는 processed일 수 있습니다. 요청은 수락되었지만 더 이상 새로운 갱신이 없을 것이며, 이 상태는 완료를 확인할 수 없을 때도 사용됩니다. 대시보드는 추적에 관한 질문을 닫았습니다. 교체를 책임지는 운영자는 여전히 효과에 관한 질문을 갖고 있습니다.
이 예는 가상의 것입니다.RFC 8007은 제한된 추적 능력을 솔직하게 응답하는 것을 허용합니다. 분석된 위험은 다른 참여자가 이 제한을 자신의 작업에 필요한 더 강한 보증으로 받아들일 때 발생합니다.
특정 CDN이 이 오류를 실제로 구현했다는 말이 아닙니다. 모든 네트워크가 이 인터페이스를 사용한다는 말도 아닙니다. 문제는 문서화된 의미에서 도출할 수 있는 결정의 한계입니다.
하나의 컬렉션이 두 종류의 종료를 모음
2016년 12월에 발표된 RFC 8007은 IETF Standards Track 문서이며,RFC Editor 정보 페이지는 이를 Proposed Standard로 소개합니다. CDNI 제어 인터페이스의 트리거 부분을 정의합니다.
요청 CDN은 자신을 대신해 콘텐츠를 배포하는 다른 CDN에 작업을 요청합니다. 메타데이터와 콘텐츠의 인출, 무효화, 퍼지를 요청할 수 있고 활동 상태를 조회할 수도 있습니다. 이것이 전체 상업적 관계, 초기 구성 또는 각 로컬 인증 메커니즘을 통일하지는 않습니다.
수신 네트워크는 요청자별로 상태 리소스의 컬렉션을 유지합니다. 필터링된 컬렉션을 제공할 수 있으며, 이를 구현하는 경우 전체 컬렉션에 해당 링크를 제공해야 합니다. 이러한 뷰는 모든 구현에 대한 보편적 의무가 아닙니다.
Complete는 성공적으로 완료된 작업과 새로운 상태가 더 이상 게시되지 않을 processed 요청을 함께 모읍니다. 이 이름은 추적을 정리합니다. 각 항목에 개별 상태가 담고 있지 않은 성공 약속을 추가하지는 않습니다.
개별 상태 complete는 성공적인 완료를 의미합니다. processed는 완료 확인이 불가능한 경우를 포함하여, 이후 갱신 없이 수락되었음을 의미합니다. 둘이 같은 컬렉션에 나타난다는 사실은 이 차이를 지우지 않습니다.
processed가 항상 실패는 아닙니다. 항상 성공이거나, 실행 부재, 중단된 작업, 향후 효과 부재를 의미하는 것도 아닙니다. 이 정보는 작업의 모든 속성이 아니라 보고의 한계를 밝힙니다.
따라서 어떤 보고서를 계속 추적할지 결정하는 쪽은, 결과를 입증해 행동해야 하는 쪽보다 먼저 자신의 작업을 끝낼 수 있습니다. 정리된 큐는 유용하지만 그것만으로 다음 작업의 의존성에 답하지는 않습니다.
수신 접수는 조회할 자리를 제공한다
트리거를 수락하면 수신 CDN은 상태 리소스를 생성하고 HTTP 201과 함께 그 위치를 반환합니다. 요청자는 진행 상황을 확인할 참조를 얻습니다. 이 응답은 요청된 모든 작업이 이미 수행되었음을 보여주지는 않습니다.
참조는 서비스가 반환한 것을 사용해야 합니다. 요청자는 URL 구조를 추측할 수 없으며 예시를 필수 형식으로 바꿔서는 안 됩니다. 상태 리소스 URI는 제거된 후 재사용되어서는 안 되며, 그래야 오래된 참조가 조용히 다른 작업을 가리키는 일이 없습니다.
진행 상황을 추적할 수 있는 구현은 대기 중, 진행 중, 최종적으로 성공 또는 실패를 알릴 수 있습니다. 추적을 제공할 수 없다면 processed로 한계를 밝히고 리소스를 Complete에 넣어야 합니다. 또한 계획에 적합한 예상 완료 시점을 제시해야 합니다.
새로운 활동 없이 정당한 경우도 있습니다. 퍼지는 네트워크가 아직 인출하지 않은 데이터를 대상으로 할 수 있습니다. 사전 인출은 이미 존재하고 유효한 데이터를 대상으로 할 수 있습니다. 사양은 이런 경우 processed나 complete를 허용합니다.
따라서 성공 결과가 자동으로 전송된 바이트 수나 비워진 장치 수를 측정하지는 않습니다. 요청, 그 범위, 결과가 의미하는 바를 함께 고려해야 합니다. 종료된 항목 수를 세는 것은 이 해석을 대신하지 못합니다.
체인은 없는 확인을 만들어낼 수 없다
수신 CDN은 배포를 다른 네트워크에 넘길 수 있습니다. 명령은 영향을 받을 수 있는 하위 CDN에도 전달되어야 합니다. 중개자의 로컬 부분 완료는 다른 네트워크에서 일어나는 일을 해결하지 못합니다.
RFC 8007은 명령이 모든 관련 하위 CDN에서 complete가 되기 전에 complete를 보고하는 것을 허용하지 않습니다. 하위 CDN이 processed를 보고하면 중개자도 processed를 보고해야 하며, 응답을 성공으로 끌어올릴 수 없습니다.
이는 각 실행 단계를 선택하는 중앙 조정을 요구하지 않습니다. 집계된 의미가 얻어진 근거와 계속 일치하도록 요구할 뿐입니다. 결정을 분배한다고 확신이 허구적으로 곱해지는 것은 아닙니다.
실패는 네트워크나 하위 CDN에서 발견되는 즉시 보고할 수 있습니다. 오류 목록은 요청된 URL이나 패턴을 식별합니다. 요청이 다른 부분에 대해 계속 진행 중인 동안 일부 부분에 이미 문제가 있을 수 있습니다.
오류에 포함된 참조는 요청과 정확히 동일하게 유지되어야 하며, 더 넓은 범위로 일반화되어서는 안 됩니다. 한 부분의 실패가 보편적 실패를 증명하지 않고, 오류가 보고되지 않은 다른 부분이 그로 인해 성공의 증거를 얻지도 않습니다.
이러한 세분성은 선택적 계속을 가능하게 합니다. 독립적인 작업은 충분한 결과를 가질 수 있고, 다른 작업은 아직 없는 확인에 의존할 수 있습니다. 모든 것을 멈추거나 모든 것을 승인하는 것은 실제 의존성을 무시할 수 있는 응답입니다.
RFC 7337의 CDNI 요구 사항, Informational 문서는 이미 연쇄를 포함하여 완료, 성공 또는 실패에 관한 적절한 정보를 요구했습니다. 트리거는 제한된 추적 능력까지 보존하는 구체적 방법을 제공합니다.
성공은 작업 종류에 따라 다르다
사전 인출은 메타데이터나 콘텐츠를 요청합니다. 무효화는 데이터를 지우지 않고 다시 사용하기 전 재검증을 요구합니다. 퍼지는 지정된 데이터가 처리 후 더 이상 유지되지 않아야 함을 요구하지만, 필요할 때 다시 인출될 수 있습니다.
현재 IANA 등록부는 이 구분을 유지합니다. 재사용에 대한 제약은 저장소에서 데이터를 제거하는 물리적 효과와 같지 않습니다.
사양은 영향을 받는 캐시 서버가 서비스 중이 아닌 경우에도, 서비스로 돌아올 때 재검증 없이 데이터를 재사용하지 않는다면 무효화를 complete로 허용합니다. 이 결과는 향후 사용 조건을 보장하지, 연결이 끊긴 각 장비가 이미 비워졌음을 보장하지 않습니다.
퍼지와 사전 인출은 작업이 캐시 서버 복귀 후 완료될 예정이라면 processed일 수 있습니다. 작업이 중단되면 오류가 보고되어야 합니다. 모든 최종 분류가 이미 입증된 삭제와 동일하지는 않습니다.
범위는 여전히 요청된 데이터와 배포입니다. 이 보고서들 중 어느 것도 인터넷의 모든 사본이 사라졌음을 증명하지 않습니다. 이후의 상태 변경도 이미 수신자에게 전달된 자료를 회수하지 않습니다.
순서대로 요청하는 것이 원격 순서를 통제하지는 않는다
활동의 시작과 속도는 수신 CDN의 통제에 있습니다. 퍼지와 무효화는 수락 이전에 인출된 데이터를 다뤄야 합니다. 이후 인출에는 적용되지 않아야 하지만, 요청자는 그러한 배제가 항상 실현 가능하다고 기대할 수 없습니다.
명령이 도착했을 때 이미 시작된 인출의 처리도 구현에 달려 있습니다. 순서대로 보낸 두 요청이 오래된 자료와 새 자료 사이의 정밀한 전역 경계를 만들지는 않습니다.
따라서 RFC 8007은 동일한 URL에서 대체 콘텐츠의 사전 인출을 시작하기 전에 퍼지 또는 무효화를 완료할 것을 권장합니다. 작업이 겹치면 새 자료가 인출된 뒤 아직 실행 중인 이전 명령의 영향을 받을 수 있습니다.
다이아몬드 형태의 구성은 서로 다른 정당한 경로를 통해 반복 명령을 추가할 수 있습니다. 수신 네트워크는 이들을 별도로 스케줄할 수 있습니다. 한 분기의 퍼지가 끝나고 인출을 요청하는 동안, 다른 퍼지가 여전히 새로 인출된 콘텐츠에 닿을 수 있습니다.
재인출은 가용성을 회복할 수 있습니다. 첫 작업 해제 시점에 모든 경쟁 작업이 끝났다는 즉각적인 증거가 있었다는 뜻은 아닙니다.
교체를 책임지는 쪽은 자신의 선행 조건을 식별해야 합니다. 특정 범위에 대해 확인된 성공이 필요한가? 예상과 그에 따른 불확실성을 로컬 합의로 수용하는가? 다음 작업이 불확실한 부분과 독립적인가? Complete 컬렉션은 이 중 어느 것도 대신 선택해 주지 않습니다.
예상은 기한이 지나도 증명서가 되지 않는다
선택 속성 etime은 CDN이 활동 완료를 기대하는 시점을 알려줍니다. 다음 업로드를 계획하는 데 도움이 됩니다. 그 시각이 되었다고 작업이 성공했음을 증명하지는 않습니다.
생성, 수정, 예상 종료 시각은 보고하는 네트워크가 결정합니다. 인터페이스는 상호 연결된 CDN 간의 시계 동기화를 요구하지 않습니다. 서로 다른 운영자의 숫자를 정렬하는 것만으로 인과성을 재구성할 수 없습니다.
로컬 합의는 시간 기준과 불확실성을 다룰 수 있습니다. 그 합의가 processed의 정의를 바꾸지는 않습니다. 시계가 잘 정렬되어 있어도 예상은 기대일 뿐, 수신된 결과가 아닙니다.
HTTP 조건부 요청은 관측 비용을 줄입니다. RFC 8007은 리소스와 컬렉션에 ETag 사용을 권장합니다.HTTP 의미론과캐시 규칙이 이 도구들을 설명합니다.
변화 없는 processed 리소스에 대한 304 응답은 표현이 그대로였음을 확인합니다. 더 이상 약속되지 않은 확인을 채워주지는 않습니다. 조회 빈도를 높인다고 파트너의 보고 능력이 넓어지지는 않습니다.
취소는 과거를 복원하지 않는다
서비스는 취소 명령에 적절히 응답해야 하지만, 실제로 취소를 수행하는 것은 선택 사항입니다. 비활성 작업 표시, 활동이 계속되는 가운데의 수락, 미구현을 나타낼 수 있습니다.
대기 중인 작업은 취소가 처리되기 전에 시작될 수 있습니다. 활성 작업은 즉시 멈추지 않을 수 있습니다. 이미 수행된 작업에 대한 일반적인 되돌리기는 없습니다. complete나 failed 작업이 소급하여 취소로 재분류되어서는 안 됩니다.
프로토콜 값의 철자도 주의가 필요합니다.검증된 기술 정오표 5053은 cancelling과 cancelled의 철자를,5054는 ecancelled를 바로잡습니다.편집 정오표 5064는 리소스 삭제와 구별되는 취소 예시를 명확히 합니다. 한국어 설명이 이 값들의 철자를 바꾸어서는 안 됩니다.
리소스를 삭제하면 조회 자리와 컬렉션 내 참조가 사라집니다. 효과는 취소를 연상시키지만 이후 보고를 유지하지는 않습니다. 삭제 후 실패하는 GET은 삭제 전에 어떤 결과가 있었는지 밝히지 않습니다.
자동 보존 기간도 관측을 한정합니다. 오래된 리소스가 제거된다면 해당 기간이 공지되어야 합니다. 최소 24시간 유지는 예외 없는 필수 최소치가 아니라 권장 사항입니다. 요청자는 자신의 조회 창이 닫히기 전에 필요한 결과를 회수해야 합니다.
보호된 채널은 정직한 한계를 전달할 수 있다
작업은 해당 요청자의 데이터로 제한되어야 합니다. 다이아몬드 사례는 정당한 인출 경로의 가능성을 인정할 뿐, 타인의 데이터에 개입할 일반적 권한이 아닙니다.
컬렉션은 요청자 전용이며 다른 CDN에 노출되어서는 안 됩니다. 대체 보호가 충분하지 않다면 TLS와 원격 인증이 요구됩니다. 구체적 접근 제어는 로컬이며, 상업적 신뢰는 프로토콜 정의 밖에 있습니다.
현재 TLS 권고는 원래 인용된 이전 지침을 대체합니다. 보호된 채널은 보고서의 출처 확립에 도움이 됩니다. 요청된 각 작업이 성공적으로 끝났음을 보장하지는 않습니다.
CDNI 모델,메타데이터,로그는 보완적 근거를 제공합니다. 한 지점의 정상 전달이나 올바른 로그가 연결이 끊긴 장비나 하위 CDN 전체의 상태를 증명하지는 않습니다.
출처
1차 문서들이 의미의 차이를 뒷받침합니다. 결정 제안은 저자의 분석이며 새로운 요구 사항이 아닙니다.
- RFC 8007: CDNI 제어 및 트리거
- RFC Editor: RFC 8007 상태
- 검증된 기술 정오표 5053
- 검증된 기술 정오표 5054
- 검증된 편집 정오표 5064
- RFC 7336: CDNI 모델
- RFC 7337: 정보성 요구 사항
- RFC 8006: CDNI 메타데이터
- RFC 7937: CDNI 로그
- RFC 9110: HTTP 의미론
- RFC 9111: HTTP 캐싱
- RFC 3986: URI 문법
- IANA: CDNI 파라미터
- RFC 9325: TLS 및 DTLS 권고
- Lu Heng: 최소 초기 규칙, 로컬 결정, 자발적 채택
- Lu Heng: 정책의 거울
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





