设置 http 代理以使用 Web 界面？

Question

Xowap

Asked: 2024-02-07 19:14:06 +0800 CST2024-02-07 19:14:06 +0800 CST 2024-02-07 19:14:06 +0800 CST

基于 ETag 的内容重新验证

772

我的 CMS 生成相当复杂的页面，因此需要一些时间（大约 2 秒），这远远超出了我向客户端提供页面的时间预算。

然而，对我来说，了解给定页面的当前版本非常便宜，因此我很容易判断给定版本是否仍然是最新的。因此，我希望能够采用基于 ETag 的策略，其中对页面的每个请求都需要重新验证，但如果内容没有更改，服务器将在 10 毫秒内回复。

为了使其有效，我需要在所有客户端之间共享此缓存。只要 ETag 重新验证，我的所有页面对于所有用户都将保持相同，因此我可以安全地共享他们的内容。

为此，我的页面会发出：

Cache-Control: public, no-cache, must-revalidate
ETag: W/"xxx"

当从浏览器进行测试时，效果很好：页面保留在缓存中，每次刷新页面时都会根据服务器重新验证，大多数情况下会得到 304，或者当我更改内容版本时得到 200。

我现在需要的就是在客户端之间共享此缓存。本质上：

A相
1. 客户端A向代理发送请求
2. 代理没有缓存，因此询问后端
3. 后端使用 ETag 回复 200
4. 代理使用 ETag 回复 200
B期
1. 客户端B向代理发送相同的请求
2. 代理已在缓存中，但必须重新验证（因为无缓存且必须重新验证和 ETag）
3. 后端回复 304（因为重新验证请求包含带有缓存的 ETag 的 If-None-Match 标头）
4. 代理使用 Etag 回复 200
C期
1. 客户端 A 再次发送相同的请求，这次使用 If-None-Match
2. 代理使用提供的 If-None-Match 标头（不是缓存的标头）询问后端
3. 后端服务器回复304
4. 代理回复304

我尝试过 nginx，但它需要大量调整才能使其远程工作。然后我尝试了Traefik，才意识到缓存中间件是企业版的一部分。然后我发现 Varnish似乎实现了我想要的。

所以这里我使用我的 Varnish 配置：

vcl 4.0;

backend default {
    .host = "localhost";
    .port = "3000";
}

backend api {
    .host = "localhost";
    .port = "8000";
}

sub vcl_recv {
    if (req.url ~ "^/back/" || req.url ~ "^/_/") {
        set req.backend_hint = api;
    } else {
        set req.backend_hint = default;
    }
}

当然……这没有用。

当改变Cache-Control标头时，我要么从共享缓存中获取结果，但该结果没有重新验证，要么只是传递给客户端，但它似乎从未像我希望的那样将内容保留在缓存中。

为了让这个共享缓存/ETag 重新验证逻辑到位，我缺少什么？我想我错过了一些明显的东西，但无法弄清楚是什么。

1 个回答

Voted

Thijs Feryn · Answer 1 · 2024-02-07T20:17:23+08:00

设置TTL

正如内置 VCL中所述：Varnish 对待指令的方式与&no-cache相同：内容不会最终出现在缓存中。privateno-store

对于基于 ETag 的重新验证会带来问题，因为没有什么可比较的。

我的建议是设置一个较低的 TTL 以确保它最终出现在缓存中。我建议使用以下Cache-Control标头：

Cache-Control: public, s-maxage=3, must-revalidate

让 Varnish 明白必须重新验证

另一个问题是 Varnish 不理解该must-revalidate指令，但它支持该stale-while-revalidate指令。

添加must-revalidate具有相同的效果stale-while-revalidate=0：当对象过期并需要立即同步验证时，我们无法提供过时的内容。

这会将内部grace计时器设置为零。

但是，使用以下 VCL 代码，您可以使 Varnish 遵循该must-revalidate指令：

sub vcl_backend_response {
    if(beresp.http.Cache-Control ~ "must-revalidate") {
        set beresp.grace = 0s;
    }
}

增加保留时间

通过将宽限值设置为零并分配较低的 TTL，对象将很快过期，并且不会存在足够长的时间来重新验证。

正如https://stackoverflow.com/questions/68177623/varnish-default-grace-behavior/68207764#68207764中所述，Varnish 有一组计时器用于决定过期、重新验证和容忍的过时性。

我的建议是增加keepVCL 中的计时器。此计时器可确保保留过期和不合格的对象，而不会冒提供过时内容的风险。

计时器存在的唯一原因keep是为了 ETag 重新验证，所以这正是您所需要的。

我建议使用以下VCL来支持must-revalidate和增加keep计时器：

sub vcl_backend_response {
    set beresp.keep = 1d;
    if(beresp.http.Cache-Control ~ "must-revalidate") {
        set beresp.grace = 0s;
    }
}

此代码段将keep计时器增加到一天，允许过期内容在重新验证时在缓存中保留一天。

注意 cookie（和授权标头）

尽管已准备好支持 ETag 重新验证并将对象存储在缓存中的所有细节，但重要的是相关请求不会绕过缓存。这与标头无关Cache-Control，但与请求标头有关。

如果您查看子例程的内置 VCLvcl_recvAuthorization ，您会注意到默认情况下 Varnish 会绕过包含header 或header的请求的缓存Cookie。

如果您的网站使用 cookie，请阅读以下教程，了解如何删除可能会影响您的点击率的跟踪 cookie： https: //www.varnish-software.com/developers/tutorials/removing-cookies-varnish/

Varnish 测试用例作为概念证明

存储以下 VTC 内容etag.vtc并运行varnishtest etag.vtc以验证测试用例：

varnishtest "Testing ETag & 304 status codes in Varnish"

server s1 {
    # First backend request is not a conditional one
    # Return 200 with the ETag
    rxreq
    expect req.method == "GET"
    expect req.http.If-None-Match == <undef>
    txresp -status 200 \
     -hdr "Cache-Control: public, s-maxage=3, must-revalidate" \
     -hdr "ETag: abc123" -bodylen 7


    # Second backend request is a conditional one with a matching ETag
    # Return a 304
    rxreq
    expect req.method == "GET"
    expect req.http.If-None-Match == "abc123"
    txresp -status 304 \
     -hdr "Cache-Control: public, s-maxage=3, must-revalidate" \
     -hdr "ETag: abc123"

    # Third backend request is a conditional where the Etag doesn't match
    # The content has been updated
    # Return a 200 with  the updated content and the new Etag
    rxreq
    expect req.method == "GET"
    expect req.http.If-None-Match == "abc123"
    txresp -status 200 \
     -hdr "Cache-Control: public, s-maxage=3, must-revalidate" \
     -hdr "ETag: xyz456" -bodylen 8

} -start

varnish v1 -vcl+backend {
    sub vcl_backend_response {
        set beresp.keep = 1d;
        if(beresp.http.Cache-Control ~ "must-revalidate") {
            set beresp.grace = 0s;
        }
    }
} -start

client c1 {
    # Send a regular request
    # Expect a cache miss
    # Trigger the first backend response
    # Return 200 with a response body
    txreq -url "/"
    rxresp
    expect resp.status == 200
    expect resp.http.Age == "0"
    expect resp.http.ETag == "abc123"
    expect resp.http.Cache-Control == "public, s-maxage=3, must-revalidate"
    expect resp.bodylen == 7

    # Wait for 1 second
    delay 1

    # Send a conditional request with an If-None-Match header
    # Should be a cache hit
    # Should return a 304 without a response body
    # Varnish is responsible for this 304
    txreq -url "/" -hdr "If-None-Match: abc123"
    rxresp
    expect resp.status == 304
    expect resp.http.Age != "0"
    expect resp.http.ETag == "abc123"
    expect resp.http.Cache-Control == "public, s-maxage=3, must-revalidate"
    expect resp.bodylen == 0

    # Wait for 3 seconds
    delay 3

    # Send a conditional request with an If-None-Match header
    # Should be a cache miss
    # Trigger the second backend response
    # Should return a 304 without a response body
    # The server is responsible for this 304
    txreq -url "/" -hdr "If-None-Match: abc123"
    rxresp
    expect resp.status == 304
    expect resp.http.Age == "0"
    expect resp.http.ETag == "abc123"
    expect resp.http.Cache-Control == "public, s-maxage=3, must-revalidate"
    expect resp.bodylen == 0

    # Wait for 4 seconds
    delay 4

    # Send a conditional request with an If-None-Match header
    # Should be a cache miss
    # Trigger the third backend response
    # Should return a 200 with a response body
    # Content has been updated: a new Etag is returned
    txreq -url "/" -hdr "If-None-Match: abc123"
    rxresp
    expect resp.status == 200
    expect resp.http.Age == "0"
    expect resp.http.ETag == "xyz456"
    expect resp.http.Cache-Control == "public, s-maxage=3, must-revalidate"
    expect resp.bodylen == 8

} -run

结论

如果您按照我描述的步骤操作，您的 Varnish 设置将通过两种方式支持 ETag 重新验证：

从客户端到 Varnish 中缓存的对象，同时对象仍然是新鲜的
当对象过期时从 Varnish 到源服务器，但由于keep计时器的原因它仍然保留在缓存中

如果您的内容允许，还请考虑增加缓存的 TTL。这一切都取决于页面/资源的变化量。

另请注意，将对象保留更长时间（由于keep值增加）会填满缓存。当缓存已满时，将应用 LRU 策略从缓存中删除最不受欢迎的对象。

如果set beresp.keep = 1d;太多并且 Varnish 开始从缓存中删除对象，因为缓存已满，请考虑降低该keep值。

基于 ETag 的内容重新验证

设置TTL

让 Varnish 明白必须重新验证

增加保留时间

注意 cookie（和授权标头）

Varnish 测试用例作为概念证明

结论

新安装后 postgres 的默认超级用户用户名/密码是什么？

SFTP 使用什么端口？

命令行列出 Windows Active Directory 组中的用户？

什么是 Pem 文件，它与其他 OpenSSL 生成的密钥文件格式有何不同？

如何确定bash变量是否为空？

基于 ETag 的内容重新验证

1 个回答

设置TTL

让 Varnish 明白必须重新验证

增加保留时间

注意 cookie（和授权标头）

Varnish 测试用例作为概念证明

结论

相关问题