SXG는 전달 방식과는 별개로 리소스의 출처를 인증할 수 있는 전송 메커니즘입니다.
서명된 교환 (SXG)은 리소스 전송 방법과는 별개로 리소스의 출처를 인증할 수 있는 전송 메커니즘입니다. SXG를 구현하면 개인 정보를 보호하는 교차 출처 미리 가져오기를 사용 설정하여 최대 콘텐츠 렌더링 시간 (LCP)을 개선할 수 있습니다. 또한 이러한 분리는 오프라인 인터넷 경험, 서드 파티 캐시 제공과 같은 다양한 사용 사례를 개선합니다.
이 도움말에서는 SXG의 작동 방식, 사용 사례, 도구 등 SXG의 포괄적인 개요를 제공합니다.
브라우저 호환성
SXG는 Chromium 기반 브라우저(Chrome 73, Edge 79, Opera 64 버전부터)에서 지원됩니다.
개요
SXG는 주요 사용 사례로 캐시를 사용하여 출처에서 암호화 방식으로 서명된 콘텐츠를 미리 가져오고 제공합니다. 이렇게 하면 리퍼러 사이트에서의 교차 출처 탐색의 속도를 높이는 동시에 페이지가 변경되지 않고 출처에 올바르게 저작자를 표시할 수 있습니다. 식별 가능성이 있는 정보는 사용자가 사이트로 이동하여 사용자의 개인 정보를 보호할 때까지 숨겨집니다. Google 검색은 SXG 미리 가져오기 기능을 얼리 어답터로 제공하며, Google 검색에서 많은 양의 트래픽을 수신하는 사이트의 경우 SXG는 사용자에게 더 빠른 페이지 로드를 제공하는 중요한 도구가 될 수 있습니다. 앞으로 더 많은 리퍼러에게 이러한 영향이 확대되기를 기대합니다.
작동 방식
사이트에서는 브라우저가 콘텐츠 배포 방식과 관계없이 콘텐츠의 출처와 무결성을 확인할 수 있는 방식으로 요청/응답 쌍('HTTP 교환')에 서명합니다. 따라서 브라우저는 콘텐츠를 제공한 서버의 URL이 아닌 원래 사이트의 URL을 주소 표시줄에 표시할 수 있습니다.
지금까지는 사이트에서 서드 파티를 통해 콘텐츠를 배포하고 기여 분석을 유지하는 유일한 방법은 사이트에서 SSL 인증서를 배급사와 공유하는 것이었습니다. 이는 보안 단점도 있습니다. 게다가 콘텐츠를 진정한 이식성으로 만들기는 한계가 있습니다.
SXG 형식
SXG는 HTTP 교환과 교환을 포괄하는 서명이라는 두 가지 기본 구성요소를 갖는 바이너리 인코딩 파일로 캡슐화됩니다. HTTP 교환은 요청 URL, 콘텐츠 협상 정보, HTTP 응답으로 구성됩니다.
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="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE";
date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>;
validity-url="https://example.org/webpkg/validity"
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p>
<p>The exchange has a valid signature.
payload [1256 bytes]:</p>
<pre class="prettyprint"><code><title>SXG example</title>
<meta charset="utf-8">
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
}
</style>
</code></pre>
<div>
<h1>Hello</h1>
</div>
<p>
서명의 expires 매개변수는 SXG의 만료일을 나타냅니다. SXG는 최대 7일 동안 유효할 수 있습니다. 서명 헤더에 대한 자세한 내용은 서명된 HTTP 교환 사양을 참조하세요.
서버 측 맞춤설정 지원
Vary: Cookie 헤더가 포함된 SXG는 서명된 요청 URL의 쿠키가 없는 사용자에게만 표시됩니다. 사이트에서 로그인한 사용자에게 다른 HTML을 제공하는 경우 이 기능을 사용하여 환경을 변경하지 않고 SXG를 활용할 수 있습니다. 자세한 내용은 Dynamic SXG를 사용한 서버 측 맞춤설정을 참고하세요.
웹 패키징
SXG는 더 광범위한 웹 패키징 사양 제안서 제품군의 일부입니다. SXG 외에도 웹 패키징 사양의 다른 주요 구성요소는 웹 번들('번들 HTTP 교환')입니다. 웹 번들은 HTTP 리소스 및 번들을 해석하는 데 필요한 메타데이터의 모음입니다.
SXG와 웹 번들 간의 관계는 자주 혼동되는 요소입니다. SXG와 웹 번들은 서로 종속되지 않는 서로 다른 두 가지 기술입니다. 웹 번들은 서명된 교환과 서명되지 않은 교환 모두에서 사용할 수 있습니다. SXG와 웹 번들에서 모두 추진하는 일반적인 목표는 오프라인 사용을 위해 사이트를 전체적으로 공유할 수 있는 '웹 패키징' 형식을 만드는 것입니다.
서명된 교환으로 페이지 로드 속도 향상
서명된 교환을 사용 설정하면 웹페이지 성능이 향상되어 사이트의 핵심 웹 바이탈인 특정 최대 콘텐츠 페인트 (LCP)에 영향을 줄 수 있습니다. 얼리 어답터로서 Google 검색에서는 SXG를 사용하여 사용자에게 검색결과 페이지에서 로드된 페이지에 더 빠른 페이지 로드 환경을 제공합니다.
Google 검색은 가능한 경우 SXG를 크롤링 및 캐시하고 사용자가 방문할 가능성이 있는 SXG(예: 첫 번째 검색결과에 해당하는 페이지)를 미리 가져옵니다.
SXG는 CDN 사용 및 렌더링 차단 하위 리소스 감소와 같은 다른 성능 최적화와 함께 사용할 때 가장 잘 작동합니다. 구현 후에는 이 권장사항에 따라 SXG를 미리 가져올 때 LCP 이점을 극대화하세요. 대부분의 경우 이렇게 최적화하면 Google 검색에서 거의 즉각적으로 페이지 로드가 발생할 수 있습니다.
서명된 교환의 영향
과거 실험을 통해 SXG 지원 미리 가져오기에서 LCP가 평균 300~400밀리초 감소하는 것으로 나타났습니다. 이렇게 하면 사이트가 사용자에게 더 좋은 첫인상을 줄 수 있으며 비즈니스 측정항목에 긍정적인 영향을 미치는 경우가 많습니다.
이미 여러 글로벌 브랜드와 사이트에서 Signed Exchanges의 혜택을 누리고 있습니다. 우수사례로, 서명된 교환을 구현하여 저명한 콘텐츠 관리 시스템 (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을 찾아 서명된 교환을 식별할 수 있습니다.
Preview 탭에서는 SXG의 콘텐츠에 대한 자세한 정보를 제공합니다.
도구
SXG를 구현하려면 지정된 URL에 해당하는 SXG를 생성한 다음 해당 SXG를 요청자 (일반적으로 크롤러)에 제공해야 합니다.
인증서
SXG를 생성하려면 SXG에 서명할 수 있는 인증서가 필요하지만 일부 도구는 이를 자동으로 얻습니다. 이 페이지에는 이러한 유형의 인증서를 발급할 수 있는 인증기관이 표시됩니다. 인증서는 ACME 클라이언트를 사용하여 Google 인증 기관에서 자동으로 가져올 수 있습니다. 웹 패키지 도구 서버에는 ACME 클라이언트가 내장되어 있으며 sxg-rs도 곧 지원될 예정입니다.
플랫폼별 SXG 도구
이러한 툴은 특정 기술 스택을 지원합니다. 이러한 도구 중 하나에서 지원하는 플랫폼을 이미 사용하고 있다면 범용 도구보다 설정이 더 쉬울 수 있습니다.
sxg-rs/cloudflare_worker는 Cloudflare Workers에서 실행됩니다.sxg-rs/fastly_compute는 Fastly Compute@Edge에서 실행됩니다.자동 서명된 교환은 인증서를 자동으로 가져오고 서명된 교환을 생성하는 Cloudflare 기능입니다.
NGINX SXG 모듈은 nginx를 사용하는 사이트에 SXG를 생성하고 제공합니다. 설정 안내는 여기에서 확인할 수 있습니다.
Envoy SXG 필터는 Envoy를 사용하는 사이트에 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 생성의 참조 구현으로 webpackage 사양에서 제공하는 최소 Go 라이브러리입니다. 이 도구는 참조 CLI 도구인gen-signedexchange와 더 많은 기능을 제공하는 웹 패키지 도구 도구의 기반으로 사용됩니다.
콘텐츠 협상
Accept 헤더에 애플리케이션/서명된 교환의 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헤더를 사용하여 지정된 경우 자바스크립트, CSS, 글꼴, 이미지와 같은 페이지의 하위 리소스를 미리 가져옵니다. - 조만간 Google 검색의 SXG 미리 가져오기를 더 많은 검색결과 유형에서 사용할 수 있습니다.
결론
서명된 교환은 리소스가 전송된 방법과 관계없이 리소스의 출처와 유효성을 확인할 수 있는 전송 메커니즘입니다. 따라서 SXG는 전체 게시자 기여 분석을 유지하면서 서드 파티에 의해 배포될 수 있습니다.