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

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

Domenic Denicola

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

브라우저 호환성

현재 Origin-Agent-Cluster 헤더는 Chrome 88 이상에서만 구현됩니다. 이 API는 프로토타입 제작 가치가 있음으로 표시한 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를 사용하는지도 확인해야 합니다.

하지만 결국 이는 가이드라인에 불과합니다. 출처 기반 에이전트 클러스터가 사이트에 도움이 되는지 여부는 결국 측정을 통해 가장 잘 판단할 수 있습니다. 특히 웹 Vitals 및 메모리 사용량을 측정하여 출처 키잉의 영향을 확인하는 것이 좋습니다. (특히 메모리 사용량은 진행 중인 프로세스 수를 늘리면 프로세스당 메모리 오버헤드를 더 많이 유발할 수 있기 때문에 잠재적인 문제가 됩니다.) 출처 키를 배포하고 최선을 다하기만 하면 되는 것은 아닙니다.

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

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와 같은 보안 관련 헤더의 보호는 제공하지 않습니다. 특히 Spectre와 같은 사이드 채널 공격에 대한 신뢰할 수 있는 보호 수단이 아닙니다.

이는 약간 놀라울 수 있습니다. 출처 키를 사용하면 출처가 자체 프로세스를 가져올 수 있으며 별도의 프로세스는 측면 채널 공격에 대한 중요한 방어 수단이기 때문입니다. 하지만 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 구현과 관련하여 문제가 발생하면 new.crbug.com에서 구성요소 필드를 Internals>Sandbox>SiteIsolation로 설정하여 버그를 신고할 수 있습니다.

자세히 알아보기

출처 키가 지정된 상담사 클러스터에 대해 자세히 알아보려면 다음 링크를 참고하세요.

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