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

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

도메닉 데니콜라

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를 사용하는지 확인해야 합니다.

그러나 결국 이는 가이드라인에 불과합니다. 출처 관련 에이전트 클러스터가 사이트에 도움이 되는지 여부는 최종적으로 측정을 통해 결정됩니다. 특히 웹 바이탈을 측정하고 잠재적으로 메모리 사용량을 측정하여 출처 키 지정이 미치는 영향을 확인하는 것이 좋습니다. 사용 중인 프로세스 수를 늘리면 프로세스당 메모리 오버헤드가 커질 수 있으므로 특히 메모리 사용량은 잠재적인 우려사항입니다. 오리진 키잉을 출시하고 최상의 결과를 기대해서는 안 됩니다.

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

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팀에 문의해 주시기 바랍니다. 공익과 지원을 통해 기능의 우선순위를 정하고 다른 브라우저 공급업체에 기능의 중요도를 표시할 수 있습니다. @ChromiumDev로 트윗을 보내 Chrome DevRel에 여러분의 생각과 경험을 알려주세요.

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

자세히 알아보기

출처 관련 에이전트 클러스터에 대해 자세히 알아보려면 다음 링크에서 세부정보를 살펴보세요.

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