Origin-Agent-Cluster: 헤더로 성능 격리 요청

도메인 전체 스크립팅을 제한하고 브라우저에서 전용 리소스를 요청하는 새 HTTP 응답 헤더입니다.

Domenic Denicola

Origin-Agent-Cluster는 동일 사이트 교차 출처 페이지 간의 동기식 스크립팅 액세스를 방지하도록 브라우저에 지시하는 새로운 HTTP 응답 헤더입니다. 브라우저는 출처가 전용 프로세스와 같은 별도의 자체 리소스를 가져야 한다는 힌트로 Origin-Agent-Cluster를 사용할 수도 있습니다.

브라우저 호환성

현재 Origin-Agent-Cluster 헤더는 Chrome 88 이상에서만 구현됩니다. 이 도구는 프로토타입 제작의 가치가 있는 것으로 표시한 Mozilla Firefox 담당자와의 긴밀한 협력을 통해 설계되었으며 Safari에서 사용하는 브라우저 엔진인 WebKit의 담당자로부터 예비 긍정적 반응을 받았습니다.

그때까지는 오늘 모든 사용자에게 Origin-Agent-Cluster 헤더를 배포해도 아무런 문제가 없습니다. 이해하지 못하는 브라우저에서는 무시하게 됩니다. 또한 출처 기반 에이전트 클러스터의 페이지는 사이트 관련 에이전트 클러스터 (기본값)보다 실제로 작업이 더 적으므로 상호 운용성 문제를 걱정할 필요가 없습니다.

브라우저가 동일 사이트 출처를 자동으로 분리할 수 없는 이유

웹은 문서 및 스크립트가 다른 원본의 리소스와 상호작용하는 방법을 제한하는 보안 기능인 동일 출처 정책을 기반으로 합니다. 예를 들어 https://a.example에 호스팅된 페이지가 https://b.example 또는 https://sub.a.example에 있는 페이지와 다른 출처에 있습니다.

백그라운드에서 브라우저는 출처가 제공하는 분리를 다양한 방식으로 사용합니다. 예전에는 별도의 출처에서 서로의 데이터에 액세스할 수 없었지만 운영체제 스레드, 프로세스, 메모리 할당과 같은 리소스를 계속 공유했습니다. 즉, 한 탭의 속도가 느려지면 다른 탭의 속도가 모두 느려집니다. 탭 하나가 메모리를 너무 많이 사용하면 브라우저 전체가 다운됩니다

요즘의 브라우저는 더욱 정교하며 서로 다른 출처를 여러 프로세스로 분리하려고 합니다. 이 기능의 작동 원리는 브라우저에 따라 다릅니다. 대부분의 브라우저는 탭 간에 어느 정도 분리되어 있지만, 단일 탭 내부에 있는 서로 다른 iframe은 프로세스를 공유할 수 있습니다. 또한 프로세스에는 약간의 메모리 오버헤드가 발생하므로 휴리스틱을 사용하여 너무 많은 생성을 방지합니다. 예를 들어 Firefox에는 사용자가 구성할 수 있는 프로세스 제한이 있고 Chrome은 데스크톱 (메모리가 더 많은 경우)과 모바일 (메모리가 부족한 경우) 간에 동작을 다양하게 합니다.

이러한 휴리스틱은 완벽하지 않습니다. 또한 https://sub.a.example 및 https://a.example와 같은 하위 도메인이 서로 통신할 수 있도록 하는 동일 출처 정책에는 예외가 있으므로 브라우저는 자동으로 하위 도메인을 서로 분리할 수 없다는 중요한 한계를 겪고 있습니다.

이러한 기본 동작을 '사이트 관련 에이전트 클러스터'라고 합니다. 즉, 브라우저는 사이트를 기반으로 페이지를 그룹화합니다. 새로운 Origin-Agent-Cluster 헤더는 브라우저에 특정 페이지의 이 기본 동작을 변경하여 출처 기반 에이전트 클러스터에 배치하도록 요청합니다. 그러면 똑같은 출처가 있는 다른 페이지로만 그룹화됩니다. 특히 동일 사이트 교차 출처 페이지는 에이전트 클러스터에서 제외됩니다.

이러한 선택적인 구분을 통해 브라우저에서는 이러한 새로운 출처 관련 에이전트 클러스터에 다른 출처의 리소스와 결합되지 않은 자체 전용 리소스를 제공할 수 있습니다. 예를 들어 이러한 페이지는 자체 프로세스를 가져오거나 별도의 스레드에 예약될 수 있습니다. 페이지에 Origin-Agent-Cluster 헤더를 추가하면 페이지에 이러한 전용 리소스가 유용할 것이라고 브라우저에 알리는 것입니다.

그러나 분리를 실행하고 이러한 이점을 누리려면 브라우저에서 일부 기존 기능을 사용 중지해야 합니다.

출처 관련 페이지에서 할 수 없는 작업

페이지가 출처 관련 에이전트 클러스터에 있으면 이전에 사용할 수 있었던 동일 사이트 교차 출처 페이지와 통신하는 일부 기능을 포기하게 됩니다. 구체적인 방법은 다음과 같습니다.

• 더 이상 document.domain를 설정할 수 없습니다. 이 기능은 일반적으로 동일한 사이트 교차 출처 페이지에서 서로의 DOM에 동기식으로 액세스할 수 있는 기존 기능이지만, 출처 관련 에이전트 클러스터에서는 사용 중지되어 있습니다.

• 더 이상 postMessage()를 통해 WebAssembly.Module 객체를 다른 동일 사이트 교차 출처 페이지로 전송할 수 없습니다.

• (Chrome만 해당) 더 이상 동일한 사이트의 다른 교차 출처 페이지에 SharedArrayBuffer 또는 WebAssembly.Memory 객체를 전송할 수 없습니다.

출처 관련 에이전트 클러스터를 사용하는 경우

Origin-Agent-Cluster 헤더의 이점을 가장 많이 얻는 출처는 다음과 같습니다.

• 가능한 경우 전용 리소스를 사용할 때 최고의 성능을 발휘합니다. 성능 집약적인 게임, 화상 회의 사이트 또는 멀티미디어 제작 앱을 예로 들 수 있습니다.

• 출처는 다르지만 동일한 사이트인 리소스 집약적인 iframe이 포함되어 있습니다. 예를 들어 https://mail.example.com에 https://chat.example.com iframe이 삽입되어 있는 경우 출처 키 지정 https://mail.example.com/를 사용하면 채팅팀에서 작성한 코드가 메일팀에서 작성한 코드에 실수로 방해가 되지 않으며 브라우저에 별도의 프로세스를 제공하여 독립적으로 일정을 예약하고 서로에 미치는 성능 영향을 줄일 수 있습니다.

• 다른 출처의 동일한 사이트 페이지에 삽입될 것으로 예상되지만 리소스를 많이 사용합니다. 예를 들어 https://customerservicewidget.example.com가 영상 채팅에 많은 리소스를 사용할 것으로 예상되고 https://*.example.com 전체의 다양한 출처에 삽입될 예정이라면 이 위젯을 유지관리하는 팀은 Origin-Agent-Cluster 헤더를 사용하여 삽입에 미치는 성능 영향을 줄이려고 시도할 수 있습니다.

또한 위에서 설명한 거의 사용되지 않는 교차 출처 통신 기능을 사용 중지할지, 사이트에서 HTTPS를 사용하는지를 확인해야 합니다.

그러나 이는 결국 가이드라인에 불과합니다. 출처 기반 에이전트 클러스터가 사이트에 도움이 될지 여부는 궁극적으로 측정을 통해 가장 잘 결정됩니다. 특히 웹 바이탈 및 잠재적으로 메모리 사용량을 측정하여 출처 키 지정이 미치는 영향을 확인하는 것이 좋습니다. (특히 메모리 사용량은 진행 중인 프로세스 수를 늘리면 프로세스당 메모리 오버헤드를 더 많이 유발할 수 있기 때문에 잠재적인 문제가 됩니다.) 단순히 출발점 파악을 목표로 하면서 최상의 결과를 기대해서는 안 됩니다.

교차 출처 분리와 어떤 관련이 있나요?

Origin-Agent-Cluster 헤더를 통한 에이전트 클러스터의 출처 입력은 Cross-Origin-Opener-Policy 및 Cross-Origin-Embedder-Policy 헤더를 통한 교차 출처 격리와 관련이 있지만 이와는 별개입니다.

교차 출처 분리로 설정하는 모든 사이트는 Origin-Agent-Cluster 헤더를 사용할 때와 동일한 동일 사이트 교차 출처 통신 기능도 사용 중지합니다. 그러나 Origin-Agent-Cluster 헤더는 교차 출처 격리 외에도 브라우저에 리소스 할당 휴리스틱을 수정하라는 추가 힌트로 여전히 유용할 수 있습니다. 따라서 이미 교차 출처로 격리된 페이지에서도 Origin-Agent-Cluster 헤더를 적용하고 결과를 측정하는 것이 좋습니다.

Origin-Agent-Cluster 헤더 사용 방법

Origin-Agent-Cluster 헤더를 사용하려면 다음 HTTP 응답 헤더를 보내도록 웹 서버를 구성합니다.

Origin-Agent-Cluster: ?1

?1 값은 불리언 true 값의 구조화된 헤더 구문입니다.

이 헤더를 일부 페이지뿐만 아니라 원본의 모든 응답에 전송해야 합니다. 그렇지 않으면 일관되지 않은 결과가 나타날 수 있습니다. 즉, 브라우저에 출처 키 지정 요청이 '기억'되어 이를 요청하지 않은 페이지에서도 출처 키가 됩니다. 반대로 사용자가 방문하는 첫 페이지에 헤더가 없으면 브라우저는 출처가 출처로 연결되지 않는다는 것을 기억하고 이후 페이지에서는 헤더를 무시합니다.

Origin-Agent-Cluster 헤더가 적용되었는지 확인하려면 JavaScript window.originAgentCluster 속성을 사용합니다. 헤더 (또는 교차 출처 분리와 같은 기타 메커니즘)로 인해 출처 키잉이 발생한 경우에는 true, 발생하지 않은 경우 false, Origin-Agent-Cluster 헤더를 구현하지 않는 브라우저에서는 undefined이 됩니다. 이 데이터를 분석 플랫폼에 로깅하면 서버를 올바르게 구성했는지 확인할 수 있습니다.

마지막으로 Origin-Agent-Cluster 헤더는 보안 컨텍스트, 즉 HTTPS 페이지 또는 http://localhost에서만 작동합니다. localhost가 아닌 HTTP 페이지는 출처 관련 에이전트 클러스터를 지원하지 않습니다.

출처 키 입력은 보안 기능이 아님

출처 관련 에이전트 클러스터를 사용하면 출처가 동일 사이트 교차 출처 페이지의 동기식 액세스로부터 격리되지만, Cross-Origin-Resource-Policy 및 Cross-Origin-Opener-Policy와 같은 보안 관련 헤더의 보호 기능은 제공되지 않습니다. 특히 스펙터와 같은 부채널 공격에 대한 안정적인 보호 기능이 아닙니다.

조금 놀랄 수도 있습니다. 출처 키 지정으로 인해 출처에 자체 프로세스가 발생할 수 있고 별도의 프로세스는 부채널 공격에 대한 중요한 방어 역할을 하기 때문입니다. 그러나 Origin-Agent-Cluster 헤더는 이와 관련된 힌트일 뿐이라는 점을 기억하세요. 브라우저는 출처에 별도의 프로세스를 제공할 의무가 없으며 다음과 같은 여러 이유로 이를 제공하지 않을 수 있습니다.

• 브라우저에서 이 기능을 구현하는 기술을 구현하지 않을 수 있습니다. 예를 들어 현재 Safari와 Firefox는 별도의 프로세스에 별도의 탭을 배치할 수 있지만 iframe에서는 아직 그렇게 할 수 없습니다.

• 브라우저에서 별도의 프로세스의 오버헤드를 감당할 가치가 없다고 판단할 수 있습니다. 예를 들어 메모리가 부족한 Android 기기나 Android WebView에서 Chrome은 가능한 한 적은 프로세스를 사용합니다.

• 브라우저는 Origin-Agent-Cluster 헤더가 나타내는 요청을 존중할 수도 있지만, 프로세스와는 다른 격리 기술을 사용하여 이를 처리할 수도 있습니다. 예를 들어 Chrome은 이러한 종류의 성능 격리를 위해 프로세스 대신 스레드를 탐색하고 있습니다.

• 사용자 또는 다른 사이트에서 실행되는 코드가 이미 원본의 사이트 키 페이지로 이동했을 수 있으므로 일관성 보장이 시작되고 Origin-Agent-Cluster 헤더가 완전히 무시될 수 있습니다.

따라서 출처 기반 에이전트 클러스터를 보안 기능으로 생각하지 않는 것이 중요합니다. 대신 원본이 전용 리소스를 통해 이점을 얻을 수 있으며 그 대가로 특정 기능을 포기할 의향이 있음을 암시하여 브라우저가 리소스 할당의 우선순위를 정하도록 돕습니다.

의견

Origin-Agent-Cluster 헤더를 사용 중이거나 사용을 고려하고 있다면 Chrome팀에서 알려주시기 바랍니다. 공익과 지원은 Google에서 기능의 우선순위를 정하고 다른 브라우저 공급업체에 기능의 중요성을 보여주는 데 도움이 됩니다. @ChromiumDev로 트윗을 보내 Chrome DevRel에 여러분의 생각과 경험을 알려주세요.

사양 또는 기능 작동 방식에 관해 더 궁금한 점이 있으면 HTML 표준 GitHub 저장소에서 문제를 신고할 수 있습니다. Chrome의 구현에 문제가 발생하면 구성요소 필드를 Internals>Sandbox>SiteIsolation로 설정하여 new.crbug.com에서 버그를 신고할 수 있습니다.

자세히 알아보기

출처 관련 에이전트 클러스터에 대한 자세한 내용은 다음 링크에서 자세히 알아볼 수 있습니다.

• 데모 및 데모 소스
• 설명 자료
• 사양
• 버그 추적: Chrome, Firefox, Safari