mod_http2

摘要

此模块为 Apache HTTP Server 提供 HTTP/2(RFC 7540)支持。

该模块依赖于libnghttp2来提供核心 http/2 引擎。

您必须在 order 中通过协议启用 HTTP/2 才能使用本文档中描述的功能。 HTTP/2 协议不需要使用加密，因此有两种方案可用：h2(HTTP/2 over TLS)和h2c(HTTP/2 over TCP)。

两个有用的 configuration 方案是：

VirtualHost context 中的 HTTP/2(仅限 TLS)

Protocols h2 http/1.1

允许通过 TLS ALPN 在安全的<VirtualHost>中进行 HTTP/2 negotiation(h2)。 HTTP/2 前导码检查(直接模式，请参阅H2Direct)默认为h2禁用。

服务器 context 中的 HTTP/2(TLS 和 cleartext)

Protocols h2 h2c http/1.1

允许 HTTP/2 negotiation(h2)通过 TLS ALPN 进行安全<VirtualHost>。允许 HTTP/2 cleartext negotiation(h2c)从初始 HTTP/1.1 连接升级或通过 HTTP/2 前导码检查(直接模式，见H2Direct)。

有关协议的任何疑问，请参阅官方HTTP/2 常见问题。

它是如何工作

HTTP/2 尺寸标注

在 Apache 服务器上启用 HTTP/2 会对资源消耗产生影响，如果您有繁忙的站点，则可能需要仔细考虑其影响。

启用 HTTP/2 后，第一个值得注意的事情是服务器进程将启动其他线程。这样做的原因是 HTTP/2 将它收到的所有请求都提供给它自己的 Worker 线程进行处理，收集结果并将它们流式传输到 client。

在当前的 implementation 中，这些 workers 使用您可能熟悉的 MPM workers 中的单独线程池。这就是现在的事情，而不是永远这样。(它可能永远是 2.4.x 发布 line，though.)所以，HTTP/2 workers 或更短的 H2Workers，不会出现在mod_status中。它们也不计入ThreadsPerChild等指令。但是如果你没有配置它们会将ThreadsPerChild视为默认值通过H2MinWorkers和H2MaxWorkers的其他东西。

另一件要注意的是 memory 消费。由于 HTTP/2 在服务器上保留更多 state 来管理它们之间的所有打开请求，优先级和依赖关系，因此它总是需要比 HTTP/1.1 处理更多 memory。有三个指令可以控制 HTTP/2 连接的 memory 足迹：H2MaxSessionStreams，H2WindowSize和H2StreamMaxMemSize。

H2MaxSessionStreams限制了 client 可以在 HTTP/2 连接上进行的 parallel 请求的数量。这取决于您的网站应该允许多少。默认值是 100 这是很多，除非你运行 memory 问题，我会保持这种方式。浏览器发送的大多数请求都是没有正文的 GET，因此在实际处理开始之前它们只会占用一些 memory。

H2WindowSize控制 client 在等待服务器鼓励更多之前允许作为请求的主体发送多少。或者，反过来说，它是服务器需要能够缓冲的请求主体数据量。这是按要求。

最后，但并非最不重要的是，H2StreamMaxMemSize控制缓冲响应数据的数量。请求位于 H2Worker 线程中并且是 producing 数据，HTTP/2 连接尝试将此发送到 client。如果 client 读取速度不够快，则连接将缓冲此数据量，然后暂停 H2Worker。

多个主机和错误请求

许多站点对多个虚拟主机使用相同的 TLS 证书。证书要么具有通配符 name，例如'*.example.org'，要么带有几个备用名称。使用 HTTP/2 的浏览器将识别出这些主机并重新使用已打开的连接。

虽然这对于 performance 非常有用，但它需要付出代价：这样的 vhosts 在其 configuration 中需要更多关注。问题是您将在同一 TLS 连接上对多个主机发出多个请求。这使得重新谈判变得不可能，面对 HTTP/2 标准禁止它。

因此，如果您有多个使用相同证书的虚拟主机并且想要使用 HTTP/2，则需要确保所有 vhost 具有完全相同的 SSL configuration。您需要与 client 验证相同的协议，密码和设置。

如果你混合了东西，Apache httpd 将检测它并_return 特殊响应 code，421 Misdirected Request，client。

环境变量

可以将此模块配置为向 SSI 和 CGI 命名空间以及自定义 log 配置中提供 HTTP/2 相关信息作为附加环境变量(请参阅%{VAR_NAME}e)。

H2CopyFiles 指令

该指令影响响应中文件内容的处理方式。当off(默认情况下)文件句柄从请求处理传递到主连接时，使用通常的 Apache setaside 处理来管理文件的生命周期。

设置为on时，将在处理请求时复制文件内容，并将缓冲的数据传递给主连接。如果第三方模块将具有不同生命周期的 files 注入响应，则会更好。

这样一个模块的 example 是mod_wsgi，它可以将 Python 文件句柄放入响应中。当 Python 认为处理完成时，那些 files 会关闭。这可能在mod_http2完成之前就已经存在了。

H2Direct 指令

该指令切换 HTTP/2 直接模式的用法。这应该在<VirtualHost>部分内使用，以便为该虚拟 host 启用直接 HTTP/2 通信。

直接通信意味着如果服务器在连接上接收的第一个字节匹配 HTTP/2 前导码，则 HTTP/2 协议立即切换到没有进一步的 negotiation。对于明文(h2c)情况，此模式在 RFC 7540 中定义。它在 TLS 连接上的使用不是标准规定的。

当 server/vhost 没有通过协议启用 h2 或 h2c 时，永远不会检查 HTTP/2 前同步码的连接。H2Direct然后没关系。这对于使用初始读取可能无限期挂起的协议的连接很重要，例如 NNTP。

对于拥有关于支持 h2c 的服务器的 out-of-band 知识的客户端，直接 HTTP/2 使 client 不必执行 HTTP/1.1 升级，从而产生更好的 performance 并避免对请求主体的升级限制。

这使得直接 h2c 对于服务器到服务器通信也是有吸引力的，当连接可以被信任或通过其他方式保护时。

例

H2Direct on

H2EarlyHints 指令

此设置控制 HTTP 状态 103 临时响应是否转发到 client。默认情况下，目前情况并非如此，因为一系列客户端仍然遇到意外的临时响应问题。

当设置为on时，使用H2PushResource宣布的 PUSH 资源将在最终响应之前触发临时 103 响应。 103 响应将带有Link headers，为这些资源提供建议。

H2MaxSessionStreams 指令

该指令设置服务器允许的每 HTTP/2 session(e.g.连接)的最大 active 流数。如果根据 RFC 7540 不是idle或closed，则流是 active。

例

H2MaxSessionStreams 20

H2MaxWorkerIdleSeconds 指令

该指令设置 h2 worker 可以自动关闭的最大秒数。仅当 h2 workers 的数量超过H2MinWorkers时才会发生这种情况。

例

H2MaxWorkerIdleSeconds 20

H2MaxWorkers 指令

此指令设置为每个子进程生成的 worker 线程的最大数量 process 以进行 HTTP/2 处理。如果未使用此伪指令，mod_http2将选择适合加载的mpm模块的 value。

例

H2MaxWorkers 20

H2MinWorkers 指令

此指令设置为每个子进程生成的 worker 线程的最小数量 process 用于 HTTP/2 处理。如果未使用此伪指令，mod_http2将选择适合加载的mpm模块的 value。

例

H2MinWorkers 10

H2ModernTLSOnly 指令

该指令在 TLS 模式下切换 HTTP/2 连接上的安全检查(https:)。这可以在服务器范围内使用，也可以在特定的<VirtualHost>上使用。

安全检查要求 TSL 协议至少为 TLSv1.2，并且使用附录 A 中 RFC 7540 中列出的密码。一旦新的安全要求到位，这些检查将得到延长。

name 源于 mozilla 的Security/Server Side TLS定义，其中定义了“现代兼容性”。 Mozilla Firefox 和其他浏览器需要现代兼容 HTTP/2 连接。作为 OpSec 的一切，这是一个不断变化的目标，并且可以预期在未来发展。

在mod_http2中进行这些检查的一个目的是为所有连接强制执行此安全性 level，而不仅仅是来自浏览器的连接。另一个目的是在不满足要求的情况下防止 HTTP/2 作为协议进行协商。

最终，TLS 连接的安全性由mod_ssl的 server configuration 指令决定。

例

H2ModernTLSOnly off

H2Padding 指令

使用默认值 0 时，任何有效负载帧都不会添加填充字节 e.g. HEADERS，DATA 和 PUSH_PROMISE。这是以前版本的行为。这意味着在某些条件下，网络流量观察者可以看到 TLS 流中这些帧的长度。

当配置 1-8 的 numbits 时，范围[0,2 ^ numbits[中的随机数]被添加到每个帧。随机 value 是为模块发送回 client 的每个帧独立选择的。

虽然更多的填充字节可以提供更好的消息长度混淆，但它们也是额外的流量。因此，最佳数量取决于服务器承载的 web 流量的类型。

默认值为 0，e.g.没有填充，选择最大向后兼容性。可能存在填充字节不受欢迎或有害的部署。最可能的原因是具有故障 implementation 的客户端。

H2Push 指令

该指令切换 HTTP/2 服务器推送协议 feature 的用法。

HTTP/2 协议允许服务器在请求特定的资源时将其他资源推送到 client。如果这些资源以某种方式连接并且 client 无论如何都可以请求它，这将非常有用。然后推送会保存 time 来查询资源本身所需的时间。另一方面，推送 client 永远不需要或已经拥有的资源是浪费带宽。

通过检查响应的Link headers 来检测服务器推送(请参阅规范的 https://tools.ietf.org/html/rfc5988)。如此指定的链接具有rel=preload属性，则将其视为要推送的资源。

响应中的链接_header 由 application 设置，或者可以通过H2PushResource配置或使用modheaders配置为：

modheaders example

<Location /index.html>
    Header add Link "</css/site.css>;rel=preload"
    Header add Link "</images/logo.jpg>;rel=preload"
</Location>

如 example 所示，可能会有几个链接 headers 添加到响应中，从而导致多次推送被触发。模块中没有检查以避免将同一资源推送到一个 client 两次或更多次。小心使用。

默认情况下启用 HTTP/2 服务器推送。在服务器或虚拟 host 上，您可以 enable/disable 此 feature 用于与 host 的任何连接。此外，您可以为 Directory/Location 中的一组资源禁用 PUSH。这可以控制哪些资源可能导致 PUSH，而不是可以通过 PUSH 发送哪些资源。

例

H2Push off

最后但并非最不重要的是，只有当 client 表示愿意接受这些时，才会发生推送。大多数浏览器都有，有些像 Safari 9，没有。此外，推送也只发生在与原始响应相同的 authority 资源中。

H2PushDiarySize 指令

该指令切换每 HTTP/2 连接记住的最大 HTTP/2 服务器推送数。这可以在<VirtualHost>部分内使用，以影响到该虚拟 host 的所有连接的数量。

推送日记记录了推送资源(当前使用 64 位数字)的推送资源(其 URL)，以避免在同一连接上重复推送。这些 value 不会被持久化，因此打开新连接的 clients 将再次遇到已知的推送。正在进行的工作使客户能够披露其已有资源的摘要，因此日记可能由 client 在每个连接设置上初始化。

如果达到最大大小，则较新的条目将替换最旧的条目。日记条目使用 8 个字节，让具有 256 个条目的默认日记消耗大约 2 KB 的 memory。

大小为 0 将有效地禁用推送日记。

H2PushPriority 指令

该指令根据响应的 content-type 定义推送响应的优先级处理。这通常是根据服务器配置定义的，但也可能出现在虚拟 host 中。

HTTP/2 服务器推送始终与 client 请求相关。每个这样的 request/response 对或流具有依赖性和权重，一起定义流的优先级。

当流依赖于另一个流时，假设 X 取决于 Y，那么 Y 在 X 得到任何带宽之前获得所有带宽。注意，这并不意味着 Y 将阻止 X.如果 Y 没有要发送的数据，则 X 可以使用分配给 Y 的所有带宽。

当流具有多个从属，例如 X1 和 X2 都依赖于 Y 时，权重确定带宽分配。如果 X1 和 X2 具有相同的权重，它们都可以获得一半的可用带宽。如果 X1 的重量是 X2 的两倍，则 X1 的带宽是 X2 的两倍。

最终，每个流依赖于获得所有可用带宽的根流，但从不发送任何内容。所以它的所有带宽都按其子女的重量分配。哪个有数据要发送或分配给自己孩子的带宽。等等。如果 none 的孩子有数据要发送，那么根据相同的规则，该带宽将被分配到其他地方。

该优先级系统的目的是始终利用可用带宽，同时允许优先级和权重给予特定流。通常，所有流都由 client 启动，因此它也是设置这些优先级的流。

只有当这样的流导致 PUSH 时，才能让服务器决定这种推送流的初始优先级是什么。在下面的示例中，X 是 client 流。它取决于 Y，服务器决定将 PUSH 流 P1 和 P2 推送到 X.

默认优先级规则是：

默认优先级规则

H2PushPriority * After 16

其中读取为“发送任意 content-type 的推送流，具体取决于具有权重 16 的 client 流”。因此，P1 和 P2 将在 X 之后发送，并且由于它们具有相同的权重，因此它们之间平均分配带宽。

交错优先级规则

H2PushPriority text/css Interleaved 256

其内容为“在与 client 流相同的依赖关系和权重上发送任何 CSS 资源”。如果 P1 有 content-type'text/css'，它将取决于 Y(如同 X)，其有效权重将计算为P1ew = Xw *(P1w / 256)。当 P1w 为 256 时，这将使有效权重与 X 的权重相同。如果 X 和 P1 都有要发送的数据，则带宽将被均等地分配给两者。

当 Pw 指定为 512 时，推送的交错流将获得 X 的重量。只有 128 的一半。请注意，有效权重的上限始终为 256。

优先规则之前

H2PushPriority application/json Before

这表示任何推送的 content type'application/json'流应该在 X 之前发出。这使得 P1 依赖于 Y 而 X 依赖于 P1。因此，当 P1 有数据发送时，X 将被停止为 long。有效权重继承自 client 流。不允许指定重量。

请注意，优先级规范的影响受可用服务器资源的限制。如果服务器没有可用于推送流的 workers，则流的数据可能仅在其他流完成时才到达。

最后，但并非最不重要的是，此指令中使用的语法有一些细节：

• ''是与所有其他人匹配的唯一特殊 content-type。'image/'不起作用。
• 默认依赖项是“After”。
• 还有默认权重：对于'After'，它是 16，'interleaved'是 256。

更短的优先级规则

H2PushPriority application/json 32         # an After rule
H2PushPriority image/jpeg before           # weight inherited
H2PushPriority text/css   interleaved      # weight 256 default

H2PushResource 指令

当添加到 directory/location HTTP/2 时，将尝试通过此指令添加的所有_path。该指令可以多次用于同一位置。

该指令比通过modheaders添加Link headers 更早地推送资源。mod_http2在对 client 的103 Early Hints临时响应中宣布这些资源。这意味着不支持 PUSH 的客户端仍会获得早期预加载提示。

与通过modheaders设置Link response headers 相反，此指令仅对 HTTP/2 连接生效。

通过将critical添加到这样的资源，服务器将更优先处理它，并在主请求的数据之前发送其数据(一旦可用)。

H2SerializeHeaders 指令

如果 HTTP/2 请求应以 HTTP/1.1 格式序列化以便httpd核处理，或者接收到的二进制数据应直接传递给request_rec s，则该指令切换。

序列化将降低 performance，但在自定义 filters/hooks 需要它时提供更多向后兼容性。

例

H2SerializeHeaders on

H2StreamMaxMemSize 指令

此指令设置 memory 中为 active 流缓冲的最大传出数据字节数。这个 memory 不是按流分配的。当它们即将完成时，分配将计入此限制。当达到限制时，流处理会冻结，并且只有在缓冲数据发送到 client 时才会继续。

例

H2StreamMaxMemSize 128000

H2TLSCoolDownSecs 指令

此指令设置在 TLS 写入大小回落到小(~1300 字节)长度之前，在 TLS 连接上设置 idle time 的秒数。这可以在服务器范围内使用，也可以用于特定的<VirtualHost>。

有关 TLS 预热的说明，请参阅H2TLSWarmUpSize。H2TLSCoolDownSecs反映了 idle 连接的 time(和 TCP 流量调整)连接可能会恶化的事实。在没有数据发送的几秒钟后，整体性能回退到 pre-warmup 阶段是有益的。

在可以认为连接可靠的部署中，可以通过将其设置为 0 来禁用此计时器。

以下 example 将秒设置为零，有效地禁用任何冷却。预热 TLS 连接保持最大记录大小。

例

H2TLSCoolDownSecs 0

H2TLSWarmUpSize 指令

该指令设置要在小 TLS 记录(~1300 字节)中发送的字节数，直到在 https：HTTP/2 连接上执行最大大小写入(16k)。这可以在服务器范围内使用，也可以用于特定的<VirtualHost>。

如果初始 record 大小保持低于 MTU level，则谷歌 performance 实验室的测量表明达到了 TLS 连接上的最佳 performance，以允许完整的 record 适合 IP 数据包。

当 TCP 调整其 flow-control 和窗口大小时，较长的 TLS 记录可能会卡在队列中或丢失并需要重新传输。这当然是 true 所有数据包。然而，TLS 需要 order 中的整个 record 来解密它。最后丢失的字节将停止使用收到的字节。

在成功发送足够数量的字节后，连接的 TCP state 是稳定的，并且最大 TLS 记录大小(16 KB)可用于最佳 performance。

在本地或仅通过可靠连接到达服务器的部署中，value 可能会减少，0 会完全禁用任何预热阶段。

以下 example 将大小设置为零，有效地禁用任何预热阶段。

例

H2TLSWarmUpSize 0

H2 升级指令

该指令切换 HTTP/1.1 Upgrade 方法的用法以切换到 HTTP/2。这应该在<VirtualHost>部分内使用，以便为该虚拟 host 升级到 HTTP/2。

这种切换协议的方法在 HTTP/1.1 中定义，并使用“Upgrade”标题(因此为 name)来宣布使用其他协议的意愿。这可能发生在 HTTP/1.1 连接的任何请求上。

根据 RFC 7540 的要求，这种协议切换方法默认在明文(潜在的 h2c)连接上启用，在 TLS(潜在的 h2)上禁用。

请注意，升级仅适用于不带身体的请求。带有内容的 POST 和 PUT 永远不会触发升级到 HTTP/2。有关升级的替代方法，请参阅H2Direct。

仅当通过协议启用 h2 或 h2c 时，此模式才有效。

例

H2Upgrade on

H2WindowSize 指令

该指令设置用于从客户端到服务器的流控制的窗口大小，并限制服务器必须缓冲的数据量。一旦达到限制，client 将停止发送流，直到服务器宣布更多可用空间(因为它已经处理了一些数据)。

此限制仅影响请求正文，而不影响其元数据，如 headers。此外，它对响应主体没有影响，因为它们的窗口大小由 clients 管理。

例

H2WindowSize 128000