Varnish 6.3中的更改¶
有关将当前Varnish部署更新到新版本的信息，请参见 升级到Varnish 6.3 。
有关Varnish更改的更详细的技术说明，以及指向已修复的问题和已合并的拉入请求的链接，请参阅 change log 。
华而不实¶
参数¶
一种新的 pipe_sess_max 参数允许限制并发管道事务的数量。默认值为零，表示无限制，以实现向后兼容。
Varnish的其他变化¶
考虑到HTTP/2会话的传输字节数更准确： ReqAcct 如果流未完成，日志记录不再报告完全传递。
VCL温度的含义更改为 auto 状态：它用于自动冷却从活动到可用的VCL，但该VCL将保持不变 cold 。它现在是双向工作的，这样一个冷的VCL使 auto 状态，并可立即使用或标记，而无需将状态明确更改为 warm 。
因此，具有 cold 状态将不再自动预热。
计数器的管理，特别是动态计数器(例如，在加载或丢弃VCL时出现或消失)的性能有了显著的改进，涉及大量后端的设置应该响应更快。
对VCL的更改¶
VCL变量¶
这个 timeout_idle 参数可以在VCL中使用 sess.timeout_idle 变量。
VCL的其他更改¶
一种新的 error 过渡到 vcl_backend_error 允许故意移动到该子例程。它类似于 synth 转换，并且可以有选择地接受参数。以下三种说法等同：
return (error);
return (error(503));
return (error(503, "Service Unavailable"));
这个 error 过渡在以下位置可用 vcl_backend_fetch 和 vcl_backend_response 。使用显式 error 过渡到 vcl_backend_fetch 不会递增 MAIN.fetch_failed 柜台。
可以两次导入同一个VMOD，只要这两个导入是相同的并且不会发生冲突。例如，这允许包含的VCL文件导入它们需要的VMOD，而不会阻止包含的VCL也执行相同的导入。
同样，现在可以在不同的名称下包括VMOD：：
import directors as dir;
sub vcl_init {
new rr = dir.round_robin();
}
这对于具有长名称的VMOD或可以在VCL代码中使用更具表现力的名称的VMOD很有用。
内置的VCL将 Host 标题中的小写字母 vcl_recv 要在以后改进其散列 vcl_hash 因为域名不区分大小写。
VMODs¶
std.ip() 现在使用可选的 STRING 参数来指定端口号或服务名称。
请参见： IP IP(字符串S， [IP fallback] ，BOOL Resolve=1， [STRING p] )
VSL-查询(7)¶
VSL查询的语法，主要通过 -q 选项，带 Varnishlog 和类似的工具，略有变化。查询中的前面和行尾将被视为简单的标记分隔符，因此在脚本中，例如您可以编写以下内容：：
varnishlog -q '
tag operator operand or
tag operator operand or
tag operator operand
' -g request ...
从现在开始，查询在行尾结束，但可以指定多个查询，在这种情况下，它的行为就像 or 运算符用于连接所有查询。
使用此语法更改后，将执行以下查询：
varnishlog -q '
query1
query2
'
相当于：
varnishlog -q '(query1) or (query2)'
换句话说，如果出于几个独立的原因使用Varnish实用程序来处理事务，则可以将复杂的查询分解为更简单的查询，方法是将它们分解为单独的行，对于可能在单个查询中需要的最复杂的查询，可以去掉括号。
如果您的查询既复杂又长，但不能适当地分解为多个查询，则仍可以使用反斜杠-换行符序列将其分解为多行：
tag operator operand and \
tag operator operand and \
tag operator operand
看见 VSL-查询 以获取有关此更改的更多信息。
有了这个查询行尾的新含义，现在就可以在查询中添加注释了。如果您由于多种原因再次遇到需要捕获事务的情况，您可以直接在查询中记录它：：
varnishlog -q '
# catch varnish errors
*Error
# catch client errors
BerespStatus >= 400 and BerespStatus < 500
# catch backend errors
BerespStatus >= 500
' -g request
这样，当您以后重新访问复杂查询时，注释可能会帮助您保持对每个单独查询的理解。当查询存储在文件中时，这会变得更加方便。
Varnishlog(1)、varnishncsa(1)等¶
我们的日志处理工具集合能够指定多个 -q 选择。虽然以前只有最后一个 -q 选项将占上风，您现在可以传递多个单独的查询，并且筛选将作为 or 运算符用于连接所有查询。
一种新的 -Q 选项允许您改为从文件中读取查询。它还可以多次使用，加起来可以是任何 -q 已指定选项。
类似于 -c 或 -b 对于客户端或后端事务， varnishncsa(1) 可以接受一次 -E 包括ESI交易记录的选项。
BackendStart 不再使用日志记录，但较新版本的日志实用程序应该仍然可以识别不推荐使用的记录。仍然可以使用较旧版本的读取写入文件的日志 varnishlog(1) ，而且向后兼容性正式达到了Varnish 6.0.0，尽管它 may 可以读取从旧版本保存的日志。
Debug 默认情况下，不再记录记录，并且可以从 vsl_mask 参数显示在日志中。由于此类记录不用于生产，因此它们只能通过以下方式自动启用 varnishtest(1) 。
Varnish状态¶
一种新的 MAIN.n_pipe Gauge跟踪正在进行的管道交易的数量。
一种新的 MAIN.pipe_limited 计数器跟踪事务由于 pipe_sess_max 参数。
Varnish测试¶
A client 现在可以使用 -method 针对以下方面的诉讼 txreq 指定请求方法的命令。这件事过去是用 -req 它仍然是兼容性的别名。
A client 或 server 可以使用 -bodyfrom 分别针对 txreq 或 txresp 从文件发送正文的命令。
A HTTP/2 client 或 server 可以使用GZIP内容编码，并可以访问 -gzipbody 和 -gziplen 。