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

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

Domenic Denicola

Origin-Agent-Cluster는 새 HTTP 응답 헤더로, 브라우저에 동기 스크립팅 액세스(예: 동일 사이트 교차 출처 페이지 간) 또한 브라우저에서 Origin-Agent-Cluster를 출처가 다음과 같은 별도의 자체 리소스를 가져야 함을 나타내는 힌트입니다. 전용 프로세스입니다

브라우저 호환성

현재 Origin-Agent-Cluster 헤더는 Chrome 88 이상에서만 구현됩니다. Kubernetes는 Mozilla Firefox의 담당자들과 긴밀히 협력하여 프로토타입을 제작하고 예비 양성 리셉션 Safari에서 사용하는 브라우저 엔진인 WebKit의 대표자입니다.

그때까지는 Origin-Agent-Cluster 헤더를 모든 클러스터에 배포해도 아무런 문제가 없습니다. 있습니다. 이해하지 못하는 브라우저에서는 무시하게 됩니다. 그리고 출처 관련 에이전트 클러스터는 사이트 관련 에이전트 클러스터 ( 기본값)를 사용하는 경우 걱정할 상호 운용성 문제가 없습니다.

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

웹은 동일한 출처의 정책인 동일 출처 정책을 기반으로 빌드되었으며, 이는 동일한 출처의 문서 및 스크립트가 다른 리소스의 리소스와 상호작용하는 방법을 제한합니다. origin에서 확인하세요. 예를 들어 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을 사용하지만 출처 관련 에이전트 클러스터에서는 사용 중지됩니다.

• 더 이상 보낼 수 없습니다. WebAssembly.Module 드림 객체를 postMessage()를 통해 다른 동일 사이트 교차 출처 페이지에 전달합니다.

• (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 그렇지 않았을 때 및 undefined는 Origin-Agent-Cluster 헤더를 구현하지 않는 브라우저에서 지원됩니다. 이 데이터를 분석 플랫폼에 기록하면 이전에 구성한 중요한 점검 사항을 확인할 수 있습니다. 확인합니다.

마지막으로 Origin-Agent-Cluster 헤더는 보안 환경에서만 작동합니다. 컨텍스트(예: HTTPS) 페이지 또는 http://localhost에서 볼 수 있습니다. localhost가 아닌 HTTP 페이지는 출처 관련 에이전트를 지원하지 않습니다. kube-APIserver로 전송합니다

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

출처 관련 에이전트 클러스터를 사용하면 Google Cloud 콘솔에서 소스를 동기 액세스로부터 동일한 사이트 교차 출처 페이지의 경우, 보안 관련 헤더와 같은 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 헤더를 클릭하세요. 공익과 후원은 YouTube가 기능의 우선순위를 정하고 얼마나 중요한지 알 수 있습니다. @ChromiumDev에서 트윗하기 Chrome DevRel에 여러분의 생각과 경험을 알려주세요.

사양 또는 기능의 작동 방식에 대해 더 궁금한 점이 있으면 HTML 표준 GitHub 저장소에서 문제를 제출하세요. 만약 버그를 신고하실 수 있습니다. new.crbug.com 구성요소 필드가 Internals>Sandbox>SiteIsolation로 설정되어 있습니다.

자세히 알아보기

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

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