Signed HTTP Exchange（或“SXG”）是名为网页打包的新兴技术的一部分，可让发布商安全地确保内容可移植（即可供其他方重新分发），同时保留内容的完整性和出处。可携带的内容具有诸多优势，从更快地提交内容到促进用户之间共享内容，再到简化离线体验。
那么，Signed HTTP Exchange 如何运作？借助这项技术，发布商可以对单个 HTTP 交换（即请求/响应对）进行签名，以便从任何缓存服务器提供已签名交换。当浏览器加载此 Signed Exchange 时，它可以安全地在地址栏中显示发布商的网址，因为该广告交易中的签名足以证明内容最初来自发布商的来源。
这样可以将内容的来源与分发者分离开来。您可以将内容发布到网络上，而无需依赖特定服务器、连接或托管服务！我们对 SXG 的各种可能用途感到非常兴奋，例如：
可保护隐私的预加载：虽然为后续导航预加载资源（例如通过链接 rel=prefetch）可以让导航感觉更快，但也存在隐私方面的问题。例如，为跨源导航预提取资源会向目标网站透露用户可能对某项信息感兴趣，即使用户最终并未访问该网站也是如此。另一方面，SXG 允许从快速缓存预加载跨源资源，而无需与目标网站进行任何通信，从而仅在发生导航时传达用户兴趣。我们认为，这对目标是将用户引导至其他网站的网站而言非常有用。具体而言，Google 计划在 Google 搜索结果页上使用该功能来改进 AMP 网址，并加快搜索结果的点击速度。
在不交出证书私钥的情况下使用 CDN 的好处：突然走红的内容（例如从 reddit.com 首页链接的内容）通常会导致提供相应内容的网站过载，如果网站相对较小，则会导致其运行缓慢，甚至暂时无法访问。如果使用快速强大的缓存服务器共享内容，则可以避免这种情况，而 SXG 让您无需共享 TLS 密钥即可实现这一点。
试用 Signed Exchange
签名交换在 Chrome 73 及更高版本中提供，之前曾作为来源试用版提供。
创建 SXG
如需为您的来源（作为发布商）创建 SXG，您需要证书密钥来签署签名，并且证书必须具有特殊的 “CanSignHttpExchanges”扩展，才能作为有效的 SXG 进行处理。自 2018 年 11 月起，DigiCert 是唯一支持此扩展的 CA，您可以通过此页面请求适用于 SXG 的证书。
获得 SXG 证书后，您可以使用 GitHub 上发布的参考生成器工具创建自己的 SXG。
您还可以在 Chrome 的代码库中查看实际的 SXG 示例文件（例如，此示例是专为简单的文本文件创建的最简单的示例）。请注意，这些证书主要用于本地测试，请不要指望它们的签名中包含有效的证书和时间戳。
在本地测试该功能
如需出于测试目的创建 SXG，您可以创建自签名证书并启用 chrome://flags/#allow-sxg-certs-without-extension，以便 Chrome 处理使用该证书创建的 SXG，而无需使用特殊扩展程序。
如果您的服务器、证书和 SXG 设置正确，以下代码应该可以正常运行：
<!-- prefetch the sample.sxg -->
<link rel="prefetch" href="https://your-site.com/sample.sxg" />
<!-- clicking the link below should make Chrome navigate to the inner
response of sample.sxg (and the prefetched SXG is used) -->
<a href="https://your-site.com/sample.sxg">Sample</a>
请注意，Chrome 73 及更高版本中的锚点标记 (<a>) 和 link rel=prefetch 仅支持 SXG。另请注意，根据规范，签名的有效期上限为 7 天，因此签名内容的有效期相对较短。
提供反馈
我们非常期待您通过 webpackage-dev@chromium.org 提供对此实验的反馈。您还可以加入规范讨论，或向该团队报告 Chrome 错误。您的反馈将对标准化流程大有帮助，也有助于我们解决实现问题。