Раздел 10. Apache modules Пункты: 85 86 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 163 164 165 166 167 168 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 203 204 205 206 207 208 209 210 211 212 213 RU EN Пункт 147. Apache Module mod_http2
SummaryThis module provides HTTP/2 (RFC 7540) support for the Apache HTTP Server. This module relies on libnghttp2 to provide the core http/2 engine. You must enable HTTP/2 via Two useful configuration schemes are: HTTP/2 in a VirtualHost context (TLS only)Protocols h2 http/1.1 Allows HTTP/2 negotiation (h2) via TLS ALPN in a secure
HTTP/2 in a Server context (TLS and cleartext)Protocols h2 h2c http/1.1 Allows HTTP/2 negotiation (h2) via TLS ALPN for secure
Refer to the official HTTP/2 FAQ for any doubt about the protocol. How it worksHTTP/2 DimensioningEnabling HTTP/2 on your Apache Server has impact on the resource consumption and if you have a busy site, you may need to consider carefully the implications. The first noticeable thing after enabling HTTP/2 is that your server processes will start additional threads. The reason for this is that HTTP/2 gives all requests that it receives to its own Worker threads for processing, collects the results and streams them out to the client.
In the current implementation, these workers use a separate thread
pool from the MPM workers that you might be familiar with. This is
just how things are right now and not intended to be like this forever.
(It might be forever for the 2.4.x release line, though.) So, HTTP/2
workers, or shorter H2Workers, will not show up in
Another thing to watch out for is is memory consumption. Since HTTP/2
keeps more state on the server to manage all the open request, priorities
for and dependencies between them, it will always need more memory
than HTTP/1.1 processing. There are three directives which steer the
memory footprint of a HTTP/2 connection:
And last, but not least, Multiple Hosts and Misdirected RequestsMany sites use the same TLS certificate for multiple virtual hosts. The certificate either has a wildcard name, such as '*.example.org' or carries several alternate names. Browsers using HTTP/2 will recognize that and reuse an already opened connection for such hosts. While this is great for performance, it comes at a price: such vhosts need more care in their configuration. The problem is that you will have multiple requests for multiple hosts on the same TLS connection. And that makes renegotiation impossible, in face the HTTP/2 standard forbids it. So, if you have several virtual hosts using the same certificate and want to use HTTP/2 for them, you need to make sure that all vhosts have exactly the same SSL configuration. You need the same protocol, ciphers and settings for client verification. If you mix things, Apache httpd will detect it and return a special response code, 421 Misdirected Request, to the client. Environment Variables
This module can be configured to provide HTTP/2 related information
as additional environment variables to the SSI and CGI namespace, as well
as in custom log configurations (see
H2CopyFiles Directive
This directive influences how file content is handled in
responses. When
When set to
An example for such a module is H2Direct Directive
This directive toggles the usage of the HTTP/2 Direct Mode. This
should be used inside a
Direct communication means that if the first bytes received by the server on a connection match the HTTP/2 preamble, the HTTP/2 protocol is switched to immediately without further negotiation. This mode is defined in RFC 7540 for the cleartext (h2c) case. Its use on TLS connections not mandated by the standard.
When a server/vhost does not have h2 or h2c enabled via
For clients that have out-of-band knowledge about a server supporting h2c, direct HTTP/2 saves the client from having to perform an HTTP/1.1 upgrade, resulting in better performance and avoiding the Upgrade restrictions on request bodies. This makes direct h2c attractive for server to server communication as well, when the connection can be trusted or is secured by other means. ExampleH2Direct on H2EarlyHints Directive
This setting controls if HTTP status 103 interim responses are forwarded to the client or not. By default, this is currently not the case since a range of clients still have trouble with unexpected interim responses.
When set to H2MaxSessionStreams Directive
This directive sets the maximum number of active streams per HTTP/2 session (e.g. connection)
that the server allows. A stream is active if it is not ExampleH2MaxSessionStreams 20 H2MaxWorkerIdleSeconds Directive
This directive sets the maximum number of seconds a h2 worker may
idle until it shuts itself down. This only happens while the number of
h2 workers exceeds ExampleH2MaxWorkerIdleSeconds 20 H2MaxWorkers Directive
This directive sets the maximum number of worker threads to spawn
per child process for HTTP/2 processing. If this directive is not used,
ExampleH2MaxWorkers 20 H2MinWorkers Directive
This directive sets the minimum number of worker threads to spawn
per child process for HTTP/2 processing. If this directive is not used,
ExampleH2MinWorkers 10 H2ModernTLSOnly Directive
This directive toggles the security checks on HTTP/2 connections
in TLS mode (https:). This can be used server wide or for specific
The security checks require that the TSL protocol is at least TLSv1.2 and that none of the ciphers listed in RFC 7540, Appendix A is used. These checks will be extended once new security requirements come into place. The name stems from the Security/Server Side TLS definitions at mozilla where "modern compatibility" is defined. Mozilla Firefox and other browsers require modern compatibility for HTTP/2 connections. As everything in OpSec, this is a moving target and can be expected to evolve in the future.
One purpose of having these checks in
Ultimately, the security of the TLS connection is determined by the
server configuration directives for ExampleH2ModernTLSOnly off H2Padding Directive
With the default 0, no padding bytes are added to any payload frames, e.g. HEADERS, DATA and PUSH_PROMISE. This is the behaviour of previous versions. It means that under certain conditions, an observer of network traffic can see the length of those frames in the TLS stream. When configuring numbits of 1-8, a random number in range [0, 2^numbits[ are added to each frame. The random value is chosen independantly for each frame that the module sends back to the client. While more padding bytes give better message length obfuscation, they are also additional traffic. The optimal number therefore depends on the kind of web traffic the server carries. The default of 0, e.g. no padding, was chosen for maximum backward compatibility. There might be deployments where padding bytes are unwanted or do harm. The most likely cause would be a client that has a faults implementation. H2Push Directive
This directive toggles the usage of the HTTP/2 server push protocol feature. The HTTP/2 protocol allows the server to push other resources to a client when it asked for a particular one. This is helpful if those resources are connected in some way and the client can be expected to ask for it anyway. The pushing then saves the time it takes the client to ask for the resources itself. On the other hand, pushing resources the client never needs or already has is a waste of bandwidth.
Server pushes are detected by inspecting the
Link headers in responses are either set by the application or
can be configured via mod_headers example<Location /index.html> Header add Link "</css/site.css>;rel=preload" Header add Link "</images/logo.jpg>;rel=preload" </Location> As the example shows, there can be several link headers added to a response, resulting in several pushes being triggered. There are no checks in the module to avoid pushing the same resource twice or more to one client. Use with care. HTTP/2 server pushes are enabled by default. On a server or virtual host, you may enable/disable this feature for any connection to the host. In addition, you may disable PUSH for a set of resources in a Directory/Location. This controls which resources may cause a PUSH, not which resources may be sent via PUSH. ExampleH2Push off Last but not least, pushes happen only when the client signals its willingness to accept those. Most browsers do, some, like Safari 9, do not. Also, pushes also only happen for resources from the same authority as the original response is for. H2PushDiarySize Directive
This directive toggles the maximum number of HTTP/2 server pushes
that are remembered per HTTP/2 connection. This can be used inside the
The push diary records a digest (currently using a 64 bit number) of pushed resources (their URL) to avoid duplicate pushes on the same connection. These value are not persisted, so clients opening a new connection will experience known pushes again. There is ongoing work to enable a client to disclose a digest of the resources it already has, so the diary maybe initialized by the client on each connection setup. If the maximum size is reached, newer entries replace the oldest ones. A diary entry uses 8 bytes, letting a default diary with 256 entries consume around 2 KB of memory. A size of 0 will effectively disable the push diary. H2PushPriority Directive
This directive defines the priority handling of pushed responses based on the content-type of the response. This is usually defined per server config, but may also appear in a virtual host. HTTP/2 server pushes are always related to a client request. Each such request/response pairs, or streams have a dependency and a weight, together defining the priority of a stream. When a stream depends on another, say X depends on Y, then Y gets all bandwidth before X gets any. Note that this does not mean that Y will block X. If Y has no data to send, all bandwidth allocated to Y can be used by X. When a stream has more than one dependant, say X1 and X2 both depend on Y, the weight determines the bandwidth allocation. If X1 and X2 have the same weight, they both get half of the available bandwidth. If the weight of X1 is twice as large as that for X2, X1 gets twice the bandwidth of X2. Ultimately, every stream depends on the root stream which gets all the bandwidth available, but never sends anything. So all its bandwidth is distributed by weight among its children. Which either have data to send or distribute the bandwidth to their own children. And so on. If none of the children have data to send, that bandwidth get distributed somewhere else according to the same rules. The purpose of this priority system is to always make use of available bandwidth while allowing precedence and weight to be given to specific streams. Since, normally, all streams are initiated by the client, it is also the one that sets these priorities. Only when such a stream results in a PUSH, gets the server to decide what the initial priority of such a pushed stream is. In the examples below, X is the client stream. It depends on Y and the server decides to PUSH streams P1 and P2 onto X. The default priority rule is: Default Priority RuleH2PushPriority * After 16 which reads as 'Send a pushed stream of any content-type depending on the client stream with weight 16'. And so P1 and P2 will be send after X and, as they have equal weight, share bandwidth equally among themselves. Interleaved Priority RuleH2PushPriority text/css Interleaved 256
which reads as 'Send any CSS resource on the same dependency and
weight as the client stream'. If P1 has content-type 'text/css',
it will depend on Y (as does X) and its effective weight will be
calculated as With Pw specified as 512, a pushed, interleaved stream would get double the weight of X. With 128 only half as much. Note that effective weights are always capped at 256. Before Priority RuleH2PushPriority application/json Before This says that any pushed stream of content type 'application/json' should be send out before X. This makes P1 dependent on Y and X dependent on P1. So, X will be stalled as long as P1 has data to send. The effective weight is inherited from the client stream. Specifying a weight is not allowed. Be aware that the effect of priority specifications is limited by the available server resources. If a server does not have workers available for pushed streams, the data for the stream may only ever arrive when other streams have been finished. Last, but not least, there are some specifics of the syntax to be used in this directive:
Shorter Priority RulesH2PushPriority application/json 32 # an After rule H2PushPriority image/jpeg before # weight inherited H2PushPriority text/css interleaved # weight 256 default H2PushResource Directive
When added to a directory/location HTTP/2 PUSHes will be attempted for all paths added via this directive. This directive can be used several times for the same location.
This directive pushes resources much earlier than adding
In contrast to setting
By adding H2SerializeHeaders Directive
This directive toggles if HTTP/2 requests shall be serialized in
HTTP/1.1 format for processing by Serialization will lower performance, but gives more backward compatibility in case custom filters/hooks need it. ExampleH2SerializeHeaders on H2StreamMaxMemSize Directive
This directive sets the maximum number of outgoing data bytes buffered in memory for an active streams. This memory is not allocated per stream as such. Allocations are counted against this limit when they are about to be done. Stream processing freezes when the limit has been reached and will only continue when buffered data has been sent out to the client. ExampleH2StreamMaxMemSize 128000 H2TLSCoolDownSecs Directive
This directive sets the number of seconds of idle time on a TLS
connection before the TLS write size falls back to small (~1300 bytes)
length.
This can be used server wide or for specific
See In deployments where connections can be considered reliable, this timer can be disabled by setting it to 0. The following example sets the seconds to zero, effectively disabling any cool down. Warmed up TLS connections stay on maximum record size. ExampleH2TLSCoolDownSecs 0 H2TLSWarmUpSize Directive
This directive sets the number of bytes to be sent in small
TLS records (~1300 bytes) until doing maximum sized writes (16k)
on https: HTTP/2 connections.
This can be used server wide or for specific
Measurements by google performance labs show that best performance on TLS connections is reached, if initial record sizes stay below the MTU level, to allow a complete record to fit into an IP packet. While TCP adjust its flow-control and window sizes, longer TLS records can get stuck in queues or get lost and need retransmission. This is of course true for all packets. TLS however needs the whole record in order to decrypt it. Any missing bytes at the end will stall usage of the received ones. After a sufficient number of bytes have been send successfully, the TCP state of the connection is stable and maximum TLS record sizes (16 KB) can be used for optimal performance. In deployments where servers are reached locally or over reliable connections only, the value might be decreased with 0 disabling any warmup phase altogether. The following example sets the size to zero, effectively disabling any warmup phase. ExampleH2TLSWarmUpSize 0 H2Upgrade Directive
This directive toggles the usage of the HTTP/1.1 Upgrade method
for switching to HTTP/2. This
should be used inside a
This method of switching protocols is defined in HTTP/1.1 and uses the "Upgrade" header (thus the name) to announce willingness to use another protocol. This may happen on any request of a HTTP/1.1 connection. This method of protocol switching is enabled by default on cleartext (potential h2c) connections and disabled on TLS (potential h2), as mandated by RFC 7540.
Please be aware that Upgrades are only accepted for requests
that carry no body. POSTs and PUTs with content will never
trigger an upgrade to HTTP/2.
See
This mode only has an effect when h2 or h2c is enabled via
the ExampleH2Upgrade on H2WindowSize Directive
This directive sets the size of the window that is used for flow control from client to server and limits the amount of data the server has to buffer. The client will stop sending on a stream once the limit has been reached until the server announces more available space (as it has processed some of the data). This limit affects only request bodies, not its meta data such as headers. Also, it has no effect on response bodies as the window size for those are managed by the clients. ExampleH2WindowSize 128000 Пункты: 85 86 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 163 164 165 166 167 168 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 203 204 205 206 207 208 209 210 211 212 213 |
 |