서명된 교환 (SXG)

SXG는 리소스가 전송된 방식과 관계없이 리소스의 출처를 인증할 수 있는 전송 메커니즘입니다.

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

서명된 교환 (SXG)은 리소스가 전송된 방식과 관계없이 리소스의 출처를 인증할 수 있는 전송 메커니즘입니다. SXG를 구현하면 개인 정보 보호 교차 출처 미리 가져오기를 사용 설정하여 최대 콘텐츠 페인트 (LCP)를 개선할 수 있습니다. 또한 이러한 분리는 오프라인 인터넷 환경 및 서드 파티 캐시에서 제공하는 것과 같은 다양한 사용 사례를 발전시킵니다.

이 도움말에서는 SXG의 작동 방식, 사용 사례, 도구에 대한 포괄적인 개요를 제공합니다.

브라우저 호환성

SXG는 Chromium 기반 브라우저(Chrome 73, Edge 79, Opera 64 버전부터)에서 지원됩니다.

개요

SXG는 주요 사용 사례로 캐시를 사용하여 원본에서 암호화 서명한 콘텐츠를 미리 가져오고 제공합니다. 이렇게 하면 리퍼러 사이트에서 교차 출처 탐색 속도를 높이는 동시에 페이지가 변경되지 않고 출처가 올바르게 표시됩니다. 사용자가 사이트로 이동할 때까지 식별 정보는 숨겨지므로 사용자의 개인 정보가 보호됩니다. Google 검색은 SXG 미리 가져오기 기능을 조기에 도입한 얼리 어답터이며, Google 검색에서 트래픽의 상당 부분을 수신하는 사이트의 경우 SXG는 사용자에게 더 빠른 페이지 로드를 제공하는 중요한 도구가 될 수 있습니다. 앞으로 이러한 영향이 다른 리퍼러로 확대되기를 바랍니다.

작동 방식

사이트는 콘텐츠가 배포된 방식과 관계없이 브라우저가 콘텐츠의 출처와 무결성을 확인할 수 있는 방식으로 요청/응답 쌍('HTTP 교환')에 서명합니다. 그 결과 브라우저는 콘텐츠를 전송한 서버의 URL이 아닌 원본 사이트의 URL을 주소 표시줄에 표시할 수 있습니다.

서명된 교환의 작동 방식을 설명하는 다이어그램 브라우저가 캐시와 통신하고 캐시가 도착 페이지와 통신함

지금까지 사이트에서 저작자 표시를 유지하면서 서드 파티를 사용하여 콘텐츠를 배포하는 유일한 방법은 사이트에서 SSL 인증서를 배포자와 공유하는 것이었습니다. 이는 보안상의 단점이 있으며, 콘텐츠를 진정으로 이식 가능하게 만드는 것과는 거리가 멉니다.

SXG 형식

SXG는 바이너리 인코딩 파일에 캡슐화되며, 이 파일에는 HTTP 교환과 교환을 포함하는 서명이라는 두 가지 기본 구성요소가 있습니다. HTTP 교환은 요청 URL, 콘텐츠 협상 정보, HTTP 응답으로 구성됩니다.

다음은 디코딩된 SXG 파일의 예입니다.

format version: 1b3
request:
  method: GET
  uri: https://example.org/
  headers:
response:
  status: 200
  headers:
    Cache-Control: max-age=604800
    Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=
    Expires: Mon, 24 Aug 2020 16:08:24 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Encoding: mi-sha256-03
    Date: Mon, 17 Aug 2020 16:08:24 GMT
    Vary: Accept-Encoding
signature:
    label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>;
    cert-url=&quot;https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE&quot;;
    date=1597680503;expires=1598285303;integrity=&quot;digest/mi-sha256-03&quot;;sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>;
    validity-url=&quot;https://example.org/webpkg/validity&quot;
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p>

<p>The exchange has a valid signature.
payload [1256 bytes]:</p>
<pre class="prettyprint"><code>&lt;title&gt;SXG example&lt;/title&gt;
&lt;meta charset=&#34;utf-8&#34;&gt;
&lt;meta http-equiv=&#34;Content-type&#34; content=&#34;text/html; charset=utf-8&#34;&gt;
&lt;style type=&#34;text/css&#34;&gt;
body {
    background-color: #f0f0f2;
    margin: 0;
    padding: 0;
}
&lt;/style&gt;
</code></pre>
<div>
    <h1>Hello</h1>
</div>

<p>

서명의 expires 매개변수는 SXG의 만료일을 나타냅니다. SXG는 최대 7일 동안 유효할 수 있습니다. 서명된 HTTP 교환 사양에서 서명 헤더에 관한 자세한 내용을 확인하세요.

서버 측 맞춤설정 지원

Vary: Cookie 헤더가 포함된 SXG는 서명된 요청 URL에 대한 쿠키가 없는 사용자에게만 표시됩니다. 사이트에서 로그인한 사용자에게 다른 HTML을 표시하는 경우 이 기능을 사용하면 해당 환경을 변경하지 않고도 SXG를 활용할 수 있습니다. 동적 SXG를 사용한 서버 측 맞춤설정에 관한 세부정보를 참고하세요.

웹 패키징

SXG는 더 광범위한 웹 패키징 사양 제안 제품군의 일부입니다. SXG 외에도 웹 패키징 사양의 다른 주요 구성요소는 웹 번들('번들 HTTP 교환')입니다. 웹 번들은 HTTP 리소스와 번들을 해석하는 데 필요한 메타데이터의 모음입니다.

SXG와 웹 번들의 관계는 혼동을 일으키는 일반적인 지점입니다. SXG와 웹 번들은 서로 의존하지 않는 두 가지 별개의 기술입니다. 웹 번들은 서명된 교환과 서명되지 않은 교환 모두에 사용할 수 있습니다. SXG와 웹 번들 모두에서 추구하는 공통 목표는 오프라인 소비를 위해 사이트를 전체적으로 공유할 수 있는 '웹 패키징' 형식을 만드는 것입니다.

서명된 교환으로 페이지 로드 속도 높이기

서명된 교환을 사용 설정하면 웹페이지 성능을 높일 수 있으며, 이에 따라 사이트의 Core Web Vitals, 특히 최대 콘텐츠 페인트 (LCP)에 영향을 미칠 수 있습니다. 얼리 어답터인 Google 검색은 SXG를 사용하여 검색 결과 페이지에서 로드된 페이지의 페이지 로드 환경을 더 빠르게 제공합니다.

Google 검색은 가능한 경우 SXG를 크롤링하고 캐시하며, 사용자가 방문할 가능성이 높은 SXG(예: 첫 번째 검색 결과에 해당하는 페이지)를 미리 가져옵니다.

SXG는 CDN 사용, 렌더링 차단 하위 리소스 감소와 같은 다른 성능 최적화와 함께 사용할 때 가장 효과적입니다. 구현한 후에는 이 권장사항에 따라 SXG 미리 가져오기를 통해 LCP 이점을 극대화하세요. 이러한 최적화를 통해 Google 검색에서 페이지가 거의 즉시 로드되는 경우가 많습니다.

서명된 교환의 영향

과거 실험에서 SXG 지원 미리 가져오기로 인해 LCP가 평균 300ms~400ms 감소하는 것을 확인했습니다. 이렇게 하면 사이트가 사용자에게 더 나은 첫인상을 줄 수 있으며 비즈니스 측정항목에 긍정적인 영향을 미치는 경우가 많습니다.

여러 글로벌 브랜드와 사이트가 이미 서명된 교환의 이점을 누리고 있습니다. 사례 연구로, 서명된 교환을 구현하여 유명 콘텐츠 관리 시스템 (CMS)인 RebelMouse가 고객의 실적과 비즈니스 측정항목을 개선하는 데 어떻게 도움이 되었는지 살펴보겠습니다.

  • Narcity, LCP 41% 개선
  • Paper Magazine은 사용자당 세션수가 27% 증가했습니다.
  • MLT 블로그, 페이지 로드 시간 21% 단축

Cloudflare는 SXG가 테스트한 사이트의 98% 에서 TTFB를 개선하고 사이트의 85% 에서 LCP를 개선했으며 SXG에 적합한 페이지 로드에서 중앙값이 20% 이상 개선되었다고 밝혔습니다.

색인 생성

페이지의 SXG 및 비SXG 표현은 Google 검색에서 다르게 순위가 지정되거나 색인이 생성되지 않습니다. SXG는 궁극적으로 전송 메커니즘이며 기본 콘텐츠를 변경하지 않습니다.

AMP

AMP 콘텐츠는 SXG를 사용하여 전송할 수 있습니다. SXG를 사용하면 AMP URL이 아닌 표준 URL을 사용하여 AMP 콘텐츠를 미리 가져오고 표시할 수 있습니다.AMP에는 SXG를 생성하기 위한 별도의 도구가 있습니다. amp.dev에서 서명된 교환을 사용하여 AMP를 제공하는 방법을 알아보세요.

Chrome DevTools로 SXG 디버깅

SXG를 직접 확인하려면 Chromium 브라우저를 사용하고 DevTools를 열고 Network 패널을 연 다음 이 검색 페이지 예를 방문하세요. 서명된 교환은 유형 열에서 signed-exchange을 찾아 식별할 수 있습니다.

DevTools의 'Network' 패널 내 SXG 요청을 보여주는 스크린샷
DevTools의 네트워크 패널

미리보기 탭에는 SXG의 콘텐츠에 관한 추가 정보가 표시됩니다.

SXG의 '미리보기' 탭 스크린샷
DevTools의 미리보기 탭

도구

SXG를 구현하려면 지정된 URL에 해당하는 SXG를 생성한 다음 해당 SXG를 요청자 (일반적으로 크롤러)에게 제공해야 합니다.

인증서

SXG를 생성하려면 SXG에 서명할 수 있는 인증서가 필요합니다. 일부 도구는 이러한 인증서를 자동으로 획득합니다. 이 페이지에는 이 유형의 인증서를 발급할 수 있는 인증 기관이 나와 있습니다. ACME 클라이언트를 사용하여 Google 인증 기관에서 인증서를 자동으로 가져올 수 있습니다. 웹 패키저 서버에는 ACME 클라이언트가 내장되어 있으며 sxg-rs도 곧 내장될 예정입니다.

플랫폼별 SXG 도구

이러한 도구는 특정 기술 스택을 지원합니다. 이러한 도구 중 하나에서 지원하는 플랫폼을 이미 사용 중인 경우 범용 도구보다 설정이 더 쉬울 수 있습니다.

범용 SXG 도구

sxg-rs HTTP 서버

sxg-rs http_server는 SXG를 제공하기 위한 리버스 프록시 역할을 합니다. SXG 크롤러의 요청의 경우 http_server가 백엔드의 응답에 서명하고 SXG로 응답합니다. 설치 안내는 리드미를 참조하세요.

웹 패키지 도구 서버

웹 패키지 도구 서버 webpkgserver는 Go로 작성된 sxg-rs http_server의 대안입니다. 웹 패키지 도구 서버를 설정하는 방법에 관한 안내는 웹 패키지 도구를 사용하여 서명된 교환을 설정하는 방법을 참고하세요.

웹 패키저 CLI

웹 패키지 도구 CLI는 지정된 URL에 해당하는 SXG를 생성합니다.

webpackager \
    --private\_key=private.key \
    --cert\_url=https://example.com/certificate.cbor \
    --url=https://example.com

SXG 파일이 생성되면 서버에 업로드하고 application/signed-exchange;v=b3 MIME 유형으로 제공합니다. 또한 SXG 인증서를 application/cert-chain+cbor로 제공해야 합니다.

SXG 라이브러리

이러한 라이브러리를 사용하여 자체 SXG 생성기를 빌드할 수 있습니다.

  • sxg_rs는 SXG를 생성하기 위한 Rust 라이브러리입니다. 가장 기능이 풍부한 SXG 라이브러리이며 cloudflare_worker 및 fastly_compute 도구의 기반으로 사용됩니다.

  • libsxg는 SXG를 생성하기 위한 최소 C 라이브러리입니다. NGINX SXG 모듈 및 Envoy SXG 필터의 기반으로 사용됩니다.

  • go/signed-exchange는 SXG 생성의 참조 구현으로 웹 패키지 사양에서 제공하는 최소한의 Go 라이브러리입니다. 이는 참조 CLI 도구인 gen-signedexchange 및 더 많은 기능을 갖춘 웹 패키지 도구의 기반으로 사용됩니다.

콘텐츠 협상

Accept 헤더가 application/signed-exchange의 q-값이 text/html의 q-값보다 크거나 같음을 나타내는 경우 서버는 SXG를 제공해야 합니다. 실제로 이는 원본 서버가 브라우저가 아닌 크롤러에 SXG를 제공한다는 의미입니다. 위의 도구 중 상당수는 기본적으로 이 작업을 수행하지만, 다른 도구의 경우 다음 정규 표현식을 사용하여 SXG로 제공되어야 하는 요청의 Accept 헤더를 일치시킬 수 있습니다. http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

이 권장사항에는 Apache 및 nginx의 예시가 포함되어 있습니다.

캐시 업데이트 API

Google SXG 캐시에는 사이트 소유자가 Cache-Control: max-age로 인해 만료되기 전에 캐시에서 SXG를 삭제하는 데 사용할 수 있는 API가 있습니다. 자세한 내용은 캐시 업데이트 API 참조를 확인하세요.

SXG에 연결

모든 사이트는 및 태그를 사용하여 링크된 페이지의 SXG를 캐시, 제공, 미리 가져올 수 있습니다(가능한 경우). html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg"> 이 도움말에서는 nginx를 사용하여 SXG를 배포하는 방법을 설명합니다.

고유한 이점

SXG는 교차 출처 미리 가져오기를 사용 설정하는 여러 기술 중 하나입니다. 사용할 기술을 결정할 때 다양한 측면을 최적화하는 것 사이에서 절충해야 할 수 있습니다. 다음 섹션에서는 SXG가 가능한 솔루션 공간에서 제공하는 몇 가지 고유한 가치를 보여줍니다. 이러한 요소는 사용 가능한 솔루션의 범위가 발전함에 따라 시간이 지남에 따라 변경될 수 있습니다.

처리할 요청 수 감소

교차 사이트 미리 가져오기를 사용하면 서버에서 추가 요청을 처리해야 할 수 있습니다. 이는 페이지를 미리 가져왔지만 사용자가 페이지를 방문하지 않았거나 미리 가져온 바이트를 사용자에게 표시할 수 없는 경우에 해당합니다. SXG를 사용하면 이러한 사용되지 않는 추가 요청을 크게 줄일 수 있습니다.

  • SXG는 캐시되며 만료될 때까지 사용자에게 전송될 수 있습니다. 따라서 많은 프리패치를 캐시 서버에서만 처리할 수 있습니다.
  • SXG는 사이트에 쿠키가 있는 사용자와 없는 사용자 모두에게 표시될 수 있습니다. 따라서 탐색 후 페이지를 다시 가져와야 하는 횟수가 줄어듭니다.

페이지 속도 개선

현재 지원되는 미리 가져오기 표시 경로 및 기능으로 인해 페이지 속도가 추가로 개선될 수 있습니다.

  • SXG는 사이트 쿠키가 있는 사용자에게 표시될 수 있습니다.
  • 또한 SXG는 Link 헤더를 사용하여 지정된 경우 페이지의 하위 리소스(예: JavaScript, CSS, 글꼴, 이미지)를 미리 가져옵니다.
  • 가까운 시일 내에 Google 검색의 SXG 미리 가져오기가 더 많은 검색 결과 유형에서 지원될 예정입니다.

결론

서명된 교환은 리소스가 전달된 방식과 관계없이 리소스의 출처와 유효성을 확인할 수 있는 전송 메커니즘입니다. 따라서 SXG는 게시자 저작자 표시를 완전히 유지하면서 서드 파티에서 배포할 수 있습니다.

추가 자료