후보 권고안으로 발행되었다고 해서 W3C와 그 회원들의 승인을 의미하지는 않습니다. 후보 권고안 초안은 이전
후보 권고안에서 작업 그룹이 이후 후보 권고안 스냅샷에 포함하려는 변경 사항을 통합합니다.
이 문서는 초안 문서로, 언제든지 다른 문서로 업데이트되거나 대체되거나 폐기될 수 있습니다. 진행 중인 작업 외의 목적으로 이 문서를 인용하는 것은 부적절합니다.
이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성되었습니다.
W3C는
이 그룹의 결과물과 관련하여 이루어진 공개된 특허 목록을 유지
관리합니다.
해당 페이지에는 특허를 공개하는 방법에 대한 지침도 포함되어 있습니다.
특정 개인이 본인이 알고 있는 특허가 필수 청구항을 포함한다고
믿는 경우,
W3C 특허 정책 섹션 6에 따라 정보를 공개해야 합니다.
웹 애플리케이션은 종종 이벤트, 상태 업데이트 및 분석 데이터를 하나 이상의 서버에 보고하는 요청을 보내야 합니다. 이러한 요청은 일반적으로 클라이언트에서 응답 처리를 요구하지 않으며(예: 204
또는 200 HTTP 응답 코드와 빈 응답 본문), 중요한 리소스 가져오기, 입력 반응, 애니메이션 실행 등과 같은 다른 고우선순위 작업과 네트워크 및 계산 리소스를 경쟁하지 않아야 합니다.
그러나 이러한 단방향 요청(비콘)은 중요한 애플리케이션 및 측정 데이터를 전달하는 역할도 하므로 개발자는 다음과 같은 비용이 많이 드는 방법을 사용하여 이를 보장해야 합니다:
개발자는 비콘을 결합하여 지연시키는 대신 즉각적으로 전달하는 옵션을 선택합니다. 이는 전달률을 개선하지만, 전달을 지연하면 비콘 요청이 성공적으로 완료될 시간이 충분하지 않을 수 있으며,
이로 인해 중요한 애플리케이션 데이터가 손실될 수 있습니다.
개발자는 동기 XMLHttpRequest를 통한 차단 요청 발행, 빈 작업 루프 삽입, 또는 기타 기술을 사용하여 사용자 에이전트가 중요한 시간 작업을 실행하지 못하게 합니다(예: 클릭,
언로드 및 기타 핸들러). 이러한 차단 동작은 페이지가 언로드되거나, 중단되거나, 시스템에 의해 종료될 경우 사용자 에이전트 및 운영 체제가 요청을 취소하지 못하게 하여 전달률을
개선합니다.
위의 전달 및 처리 요구사항 간의 불일치는 대부분의 개발자들에게 어려운 선택을 강요하며, 사용자 경험을 해치는 차단 기술의 광범위한 채택으로 이어집니다. 이 명세서는 웹 개발자가 비동기 및 비차단
데이터 전달을 예약할 수 있는 인터페이스를 정의하며, 다른 시간에 민감한 작업들과의 리소스 경합을 최소화하면서도 이러한 요청이 여전히 처리되고 목적지로 전달되도록 보장합니다:
비콘 요청은 시간에 민감한 작업 및 더 높은 우선순위의 네트워크 요청과 경쟁하지 않도록 우선순위가 매겨집니다.
비콘 요청은 모바일 장치에서 에너지 사용을 최적화하기 위해 사용자 에이전트에 의해 효율적으로 결합될 수 있습니다.
비콘 요청은 페이지가 언로드되기 전에 시작되며, 사용자 상호작용 이벤트 처리를 차단하는 요청이나 기타 기술을 요구하지 않고 완료되도록 허용됩니다.
다음 예는 sendBeacon() 메서드를 사용하여 이벤트, 클릭 및 분석 데이터를 전달하는
방법을 보여줍니다:
<html><script>// 클라이언트 측 이벤트를 기록하는 비차단 비콘 전송functionreportEvent(event) {
var data = JSON.stringify({
event: event,
time: performance.now()
});
navigator.sendBeacon('/collector', data);
}
// 페이지가 백그라운드 상태로 전환될 때 (Page Visibility API)// 세션 분석 데이터를 포함한 비차단 비콘 전송document.addEventListener('visibilitychange', function() {
if (document.visibilityState === 'hidden') {
var sessionData = buildSessionReport();
navigator.sendBeacon('/collector', sessionData);
}
});
</script><body><ahref='http://www.w3.org/'onclick='reportEvent(this)'><buttononclick="reportEvent('some event')">Click me</button></body></html>
참고
위의 예는 [PAGE-VISIBILITY-2]에서 정의된 visibilitychange
이벤트를 사용하여 세션 데이터를 전달합니다.
이 이벤트는 사용자가 다른 애플리케이션으로 전환하거나, 홈 화면으로 이동하거나 하는 등 페이지가 백그라운드 상태로 전환될 때(또는 언로드될 때) 모바일 장치에서 발생이 보장된 유일한
이벤트입니다.
개발자는 페이지가 백그라운드 상태에 있을 때(즉, visibilityState
가 hidden
과 같고, 모바일 OS에 의해 프로세스가 종료된 경우)
발생하지 않는 unload 이벤트에 의존하지 않는 것이
좋습니다.
sendBeacon() 메서드를 통해 시작된 요청은 시간에 민감한 작업과 경쟁하지
않으며, 사용자 에이전트에 의해 네트워크 효율성을 개선하기 위해 우선순위가 매겨질 수 있으며, 비콘 데이터를 보장하기 위해 차단 작업을 사용할 필요가 없어집니다.
sendBeacon() 메서드는 오프라인 저장이나 전송에 대한 특별 처리를
제공하지 않습니다. 비콘 요청은 다른 요청과 같으며, 필요한 경우 [SERVICE-WORKERS]와 결합하여 오프라인 기능을
제공할 수 있습니다.
sendBeacon() 메서드는 백그라운드 동기화나 전송 기능을 제공할
목적으로 설계되지 않았습니다. 사용자 에이전트는 비콘 요청이 빠르고 적시에 완료될 수 있도록 최대 허용 페이로드 크기를 제한합니다.
sendBeacon() 메서드는 요청 메서드를 사용자 정의하거나, 사용자 정의
요청 헤더를 제공하거나, 요청 및 응답의 처리 속성을 변경하는 기능을 제공하지 않습니다. 이러한 요청에 대해 기본 설정이
아닌 설정이 필요한 애플리케이션은 keepalive를 true로 설정하여
[FETCH] API를 사용해야 합니다.
2. 적합성
비규범적으로 표시된 섹션뿐만 아니라, 이 명세서에 있는 모든 저작 지침, 다이어그램, 예제 및 주석은 비규범적입니다. 이 명세서의 다른 모든 내용은 규범적입니다.
이 문서의 MAY, MUST, SHOULD 및 SHOULD NOT와 같은 주요 용어는
BCP 14
[RFC2119] [RFC8174]에 설명된 대로 해석되어야
합니다. 단, 이러한 용어가 여기에서 보여지는 것처럼 모두 대문자로 나타날 때만 해당됩니다.
가독성을 위해 이 명세서에서는 이러한 단어들이 모두 대문자로 나타나지 않습니다.
알고리즘의 일부로 명령형으로 표현된 요구사항(예: "모든 선행 공백 문자를 제거하십시오" 또는 "false를 반환하고 이러한 단계를 중단하십시오")은 알고리즘을 도입할 때 사용된 주요
단어("must", "should", "may" 등)의 의미로 해석되어야 합니다.
일부 적합성 요구사항은 속성, 메서드 또는 객체에 대한 요구사항으로 표현됩니다. 이러한 요구사항은 사용자 에이전트에 대한 요구사항으로 해석되어야 합니다.
알고리즘이나 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등하기만 하면 어떤 방식으로든 구현될 수 있습니다. (특히, 이 명세서에서 정의된 알고리즘은 이해하기 쉽게 설계되었으며 성능을
목표로 하지 않습니다.)
사용자 에이전트는 MUSTkeepalive
플래그가 설정된 fetch를 시작해야 하며, 이를 통해 비콘 요청이 빠르고 적시에 완료될 수 있도록 이러한 요청에 의해 대기열에 추가될 수 있는 데이터의 양을 제한해야 합니다.
사용자 에이전트는 MUST 문서의
visibilityState가
hidden으로
전환될 때 모든 비콘 요청의 즉각적인 전송을 예약해야 하며, 이러한 모든 요청이 시간에 민감하고 고우선순위 작업을 차단하지 않고 완료될 수 있도록 허용해야 합니다.
사용자 에이전트는 SHOULD 제공된 데이터를 전송하도록 예약하여 시간에 민감하고 고우선순위 작업과의 리소스(CPU 및 네트워크)
경합을 최소화해야 합니다.
사용자 에이전트는 MAY 네트워크 및 에너지 효율성을 최적화하기 위해 제공된 데이터의 전송을 지연시킬 수 있습니다. (예: 네트워크가
활성 상태일 때 즉시 전송하거나, 네트워크 인터페이스가 활성 상태일 때까지 대기) 그러나 사용자 에이전트는 SHOULD NOT 전송을
무기한 지연시키지 말아야 하며, 다른 네트워크 활동이 없더라도 보류 중인 전송이 주기적으로 플러시되도록 보장해야 합니다.
참고
Beacon API는 응답 콜백을 제공하지 않습니다. 서버는 이러한 요청에 대해 응답 본문을 생략하는 것이 좋습니다 (예: 204 No Content로
응답).
sendBeacon() 메서드는 사용자 에이전트가 데이터를 전송을 위해
성공적으로 대기열에 추가할 수 있는 경우 true를 반환합니다. 그렇지 않으면 false를 반환합니다.
참고
사용자 에이전트는 이 API를 통해 전송할 수 있는 데이터 양에 제한을 둡니다. 이는 요청이 성공적으로 전달되고 다른 사용자 및 브라우저 활동에 미치는 영향을
최소화하기 위함입니다. 대기열에 추가될 데이터의 양이 사용자 에이전트의 제한을 초과하면(HTTP-network-or-cache
fetch에서 정의된 대로), 이 메서드는 false를 반환합니다. true 반환 값은 브라우저가 데이터를 전송
대기열에 추가했음을 의미합니다. 그러나 실제 데이터 전송은 비동기적으로 이루어지므로 이 메서드는 데이터 전송이 성공했는지 여부에 대한 정보를 제공하지 않습니다.
3.2 처리 모델
sendBeacon() 메서드가 url 및 선택적
data 매개변수를 사용하여 호출될 때, 다음 단계를 실행해야 합니다:
Beacon API를 통해 시작된 요청은 자동으로
keepalive 플래그를
설정하며, 개발자는 Fetch API를 사용할 때 동일한 플래그를 수동으로 설정할 수 있습니다. 이 플래그가 설정된 모든 요청은 Fetch API
내에서 강제되는 동일한 전송 제한을 공유합니다.
contentType이 null이 아닌 경우:
corsMode를 "cors"로 설정합니다.
contentType 값이 CORS-허용된
요청 헤더 값인 경우, Content-Type 헤더에 대해 corsMode를
"no-cors"로 설정합니다.
headerList에 Content-Type 헤더와 contentType 값을
추가합니다.
반환 값을 true로 설정하고, sendBeacon() 호출을
반환하고, 다음 단계를 병렬로 계속 실행합니다:
sendBeacon() 인터페이스는 비동기 및 비차단 데이터 전달 메커니즘을
제공합니다. 이 API는 다음과 같은 용도로 사용할 수 있습니다:
클라이언트 측 이벤트를 서버에 보고합니다. 전달은 사용자 에이전트에 의해 우선순위가 지정되고 예약되며, 다른 상호작용 작업을 차단하지 않고 시스템 리소스를 효율적으로 사용합니다.
페이지가 백그라운드 상태로 전환되거나 언로드될 때 세션 데이터를 차단 없이 보고합니다.
작은 페이로드를 전달하며 응답 콜백을 기대하지 않는 기타 사용 사례.
전달된 데이터는 잠재적으로 사용자의 웹 페이지 활동에 대한 데이터와 같은 민감한 정보를 포함할 수 있습니다. 이는 사용자에게 개인정보 관련 영향을 미칠 수 있지만, 기존의 방법(예: 스크립트된 폼
제출, 이미지 비콘, XHR/페치 요청)은 유사한 기능을 제공하면서도 성능 비용이 많이 드는 트레이드오프를 수반합니다: 요청은 사용자 에이전트에 의해 중단될 수 있으며, 개발자가 사용자
에이전트가 다른 이벤트를 처리하지 못하도록 차단하지 않는 한(예: 동기 요청 호출 또는 빈 루프 실행), 사용자 에이전트는 이러한 요청을 우선순위화하거나 결합하여 시스템 리소스 사용을 최적화할
수 없습니다.
따라서, 보안 관점에서 Beacon API는 개발자가 사용하는 기존 방법과 동일한 보안 정책을 따릅니다. 마찬가지로, 개인정보 관점에서 결과 요청은 API가 호출될 때 또는 페이지 가시성이 변경될
때 즉시 시작되며, 이는 개발자가 접근할 수 있는 기존 라이프사이클 이벤트에만 노출된 정보를 제한합니다(예: 사용자의 IP 주소). 하지만 사용자 에이전트는 사용자의 투명성을 제공하기 위해
이러한 요청을 표시하는 대체 방법을 고려할 수 있습니다.
대안과 비교할 때, sendBeacon() API는 두 가지 제한을 적용합니다: 콜백 메서드가 없으며,
페이로드 크기는 사용자 에이전트에 의해 제한될 수 있습니다. 그러나 그 외에는 sendBeacon() API는 추가적인
제한을 받지 않습니다. 사용자 에이전트는 sendBeacon() 호출의 처리를 건너뛰거나 제한해서는 안 됩니다. 이 호출에는
중요한 애플리케이션 상태, 이벤트 및 분석 데이터가 포함될 수 있기 때문입니다. 마찬가지로, 사용자 에이전트는 애플리케이션이 중단되는 것을 방지하고 사용자가 그러한 모드에 있음을 누설하지 않기
위해 "프라이빗 브라우징" 또는 이에 상응하는 모드에서 sendBeacon()을 비활성화해서는 안 됩니다.
A. 감사의 말
Alois Reitbauer, Arvind Jain, Anne van Kesteren, Boris
Zbarsky, Chase Douglas, Daniel Austin, Jatinder Mann, James Simonsen, Jason
Weber, Jonas Sicking, Nick Doty, Philippe Le Hegaret, Todd Reifsteck, Tony
Gentilcore, William Chan, 그리고 Yoav Weiss에게 이 작업에 대한 기여에 감사드립니다.