document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Translated sources/tech/20151020 how to h2 in apache.md

Browse Source
This commit is contained in:
ictlyh 2015-11-06 22:38:02 +08:00
parent 21946bb666
commit 020a91a930
2 changed files with 375 additions and 376 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

376
sources/tech/20151020 how to h2 in apache.md
View File

@ -1,376 +0,0 @@
ictlyh Translating
how to h2 in apache
================================================================================
Copyright (C) 2015 greenbytes GmbH
Support for HTTP/2 is finally being released with Apache httpd 2.4.17! This pages gives advice on how to build/deploy/configure it. The plan is to update this as people find out new things (read: bugs) or give recommendations on what works best for them.
Ultimately, this will then flow back into the official Apache documentation and this page will only contain a single link to it. But we are not quite there yet...
### Sources ###
You can get the Apache release from [here][1]. HTTP/2 support is included in Apache 2.4.17 and upwards. I will not repeat instructions on how to build the server in general. There is excellent material available in several places, for example [here][2].
(Any links to experimental packages? Drop me a note on twitter @icing.)
#### Building with HTTP/2 Support ####
Should you build from a release, you will need to **configure** first. There are tons of options. The ones specific for HTTP/2 are:
- **--enable-http2**
This enables the module 'http2' which does implement the protocol inside the Apache server.
- **--with-nghttp2=<dir>**
This specifies a non-standard location for the library libnghttp2 which is necessary for the http2 module. If nghttp2 is in a standard place, the configure process will pick it up automatically.
- **--enable-nghttp2-staticlib-deps**
Ultra-rarely needed option that you may use to static link the nghttp2 library to the server. On most platforms, this only has an effect when there is no shared nghttp2 library to be found.
In case you want to build nghttp2 for yourself, you find documentation at [nghttp2.org][3]. The library is also being shipped in the latest Fedora and other distros will follow.
#### TLS Support ####
Most people will want to use HTTP/2 with browsers and browser only support it on TLS connections (**https://** urls). You'll need proper configuration for that which I cover below. But foremost what you will need is an TLS library that supports the ALPN extension.
ALPN is neccessary to negotiate the protocol to use between server and client. If it is not implemented by the TLS lib on your server, the client will only ever talk HTTP/1.1. So, who does link with Apache and support it?
- **OpenSSL 1.0.2** and onward.
- ???
If you get your OpenSSL library from your Linux distro, the version number used there might be different from the official OpenSSL releases. Check with your distro in case of doubt.
### Configuration ###
One useful addition to your server is to set a good logging level for the http2 module. Add this:
# this needs to be somewhere
LoadModule http2_module modules/mod_http2.so
<IfModule http2_module>
LogLevel http2:info
</IfModule>
When you start your server and look in the error log, you should see one line like:
[timestamp] [http2:info] [pid XXXXX:tid numbers]
mod_http2 (v1.0.0, nghttp2 1.3.4), initializing...
#### Protocols ####
So, assume you have the server built and deployed, the TLS library is bleeding edge (sorry), your server starts, you open your browser and...how do you know it is working?
If you have not added more to your server config, it probably isn't.
You need to tell the server where to use the protocol. By default, the HTTP/2 protocol is not enabled anywhere in your server. Because that is the safe route and you might have an existing deployment should continue to work.
You enable the HTTP/2 protocol with the new **Protocols** directive:
# for a https server
Protocols h2 http/1.1
...
# for a http server
Protocols h2c http/1.1
You can add this for the server in general or for specific **vhosts**.
#### SSL Parameter ####
HTTP/2 has some special requirements regarding TLS (SSL). See the chapter about [https:// connections][4] for more information.
### http:// Connections (h2c) ###
Although no browser currently supports it, the HTTP/2 protocol also works for http:// urls and mod_h[ttp]2 supports this. The only thing you need to do in order to enable it is the Protocols configuration:
# for a http server
Protocols h2c http/1.1
inside your **httpd.conf**.
There are several client (and client libraries) that support **h2c**. I'll dicusss some specifics below:
#### curl ####
Of course, the command line client for network resources, maintained by Daniel Stenberg. If you have curl on your system, there is an easy way to check its http/2 support:
sh> curl -V
curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets
which is no good. There is no 'HTTP2' among the features. You'd want something like this:
sh> curl -V
url 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets
If you have a curl with the HTTP2 feature, you may check your server with some simple commands:
sh> curl -v --http2 http://<yourserver>/
...
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQAAP__
>
< HTTP/1.1 101 Switching Protocols
< Upgrade: h2c
< Connection: Upgrade
* Received 101
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
...
<the resource>
Congratulations, id you see the line with **...101 Switching...**, it's working!
There are cases, where the upgrade to HTTP/2 will not happen. When your first request does have content, for example you do a file upload, the Upgrade will not trigger. For a detailed explanation, see the section [h2c restrictions][5].
#### nghttp ####
nghttp2 has its own client and servers that can be build with it. If you have the client on your system, you can verify your installation by simply retrieving a resource:
sh> nghttp -uv http://<yourserver>/
[ 0.001] Connected
[ 0.001] HTTP Upgrade request
...
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: AAMAAABkAAQAAP__
...
[ 0.005] HTTP Upgrade response
HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade
[ 0.006] HTTP Upgrade success
...
which is very similar to the Upgrade dance we see in the **curl** example above.
There is another way to use **h2c** hidden in the command line arguments: **-u**. This instructs **nghttp** to perform the HTTP/1 Upgrade dance. But what if we leave this out?
sh> nghttp -v http://<yourserver>/
[ 0.002] Connected
[ 0.002] send SETTINGS frame
...
[ 0.002] send HEADERS frame
; END_STREAM | END_HEADERS | PRIORITY
(padlen=0, dep_stream_id=11, weight=16, exclusive=0)
; Open new stream
:method: GET
:path: /
:scheme: http
...
The connection immediately speaks HTTP/2! This is what the protocol calls the direct mode and it works by some magic 24 bytes that the client sends to the server right away:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
or in ASCII: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
A **h2c** capable server sees this on a new connection and can immediately switch its HTTP/2 processing on. A HTTP/1.1 server will see a funny request, answer it and close the connection.
Therefore **direct** mode is only good for clients if they can be resonably sure that the server supports this. For example, because a previous Upgrade dance was successful.
The charme of **direct** is the zero overhead and that it works for all requests, even those that carry a body (see [h2c restrictions][6]). The direct mode is enabled by default on any server that allows the h2c protocol. If you want to disable it, add the configuration directive:
注：下面这行打删除线
H2Direct off
注：下面这行打删除线
to your server.
For the 2.4.17 release, **H2Direct** is enabled by default on cleartext connection. However there are some modules with whom this is incompatible with. Therefore, in the next release, the default will change to **off** and if you want your server to support it, you need to set it to
H2Direct on
### https:// Connections (h2) ###
Once you get mod_h[ttp]2 working for h2c connections, it's time to get the **h2** sibling going, as browsers only do it with **https:** nowadays.
The HTTP/2 standard imposes some extra requirements on https: (TLS) connections. The ALPN extension has already been mentioned above. An additional requirement is that no cipher from a specified [black list][7] may be used.
While the current version of **mod_h[ttp]2** does not enforce these ciphers (but some day will), most clients will do so. If you point your browser at a **h2** server with inappropriate ciphers, you will get the obscure warning **INADEQUATE_SECURITY** and the browser will simply refuse to continue.
An acceptable Apache SSL configuration regarding this is:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
SSLProtocol All -SSLv2 -SSLv3
...
(Yes, it's that long.)
There are other SSL configuration parameters that should be tweaked, but do not have to: **SSLSessionCache**, **SSLUseStapling**, etc. but those are covered elsewhere. See the excellent [High Performance Browser Networking][8] by Ilya Grigorik, for example.
#### curl ####
Time to fire up a shell and use curl again (see the [h2c section about curl][9] for requirements). Using curl, you may check your server with some simple commands:
sh> curl -v --http2 https://<yourserver>/
...
* ALPN, offering h2
* ALPN, offering http/1.1
...
* ALPN, server accepted to use h2
...
<the resource>
Congratulations, it's working! If not, the reason might be:
- Your curl does not support HTTP/2, see [this check][10].
- Your openssl is old and does not support ALPN.
- Your certificate could not be verified or your cipher configuration is not accepted. Try adding the command line option -k to disable those checks in curl. If that works, review yor SSL configuration and certificate.
#### nghttp ####
**nghttp** we discussed already for **h2c**. If you use it for a **https:** connection, you will either see the resource or an error like this:
sh> nghttp https://<yourserver>/
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
There are two possiblities for this which you can check by adding -v. Either your get this:
sh> nghttp -v https://<yourserver>/
[ 0.034] Connected
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
This means that the TLS library your server uses does not implement ALPN. Getting this installtion correct is sometimes tricky. Use stackoverflow.
Or you get this:
sh> nghttp -v https://<yourserver>/
[ 0.034] Connected
The negotiated protocol: http/1.1
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
which means ALPN is working, only the h2 protocol was not selected. You need to check that Protocols is set as described above for yourserver. Try setting it in the general section, in case you do not get it working in a vhost at first.
#### Firefox ####
Update: Steffen Land from [Apache Lounge][11] pointed me to the [HTTP/2 indicator Add-on for Firefox][12]. Nice if you want to see in how many places you already talk h2 (Hint: Apache Lounge talks h2 for some time now...).
In Firefox you can to open the Developer Tools and there the Network tab to check for HTTP/2 connections. When you have those open and reload your html page, you see something like the following:
![](https://icing.github.io/mod_h2/images/firefox-h2.png)
Among the response headers, you see this strange **X-Firefox-Spdy** entry listing "h2". That is the indication that HTTP/2 is used on this **https:** connection.
#### Google Chrome ####
In Google Chrome, you will not see a HTTP/2 indicator in the developer tools. Instead, Chrome uses the special location **chrome://net-internals/#http2** to give information.
If you have opened a page on your server and look at that net-internals page, you will see something like this:
![](https://icing.github.io/mod_h2/images/chrome-h2.png)
If your server is among the ones listed here, it is working.
#### Microsoft Edge ####
HTTP/2 is supported in the Windows 10 successor to Internet Explorer: Edge. Here you can also see the protocol used in the Developer Tools in the Network tab:
![](https://icing.github.io/mod_h2/images/ie-h2.png)
#### Safari ####
In Apple's Safari, you open the Developer Tools and there the Network tab. Reload your server page and select the row in the Developer Tools that shows the load. If you enable the right side details view, look at the **Status**. It should show **HTTP/2.0 200** like here:
![](https://icing.github.io/mod_h2/images/safari-h2.png)
#### Renegotiations ####
Renegotiations on a https: connection means that certain TLS parameters are changed on the running connection. In Apache httpd you can change TLS parameters in directory configurations. If a request arrives for a resource in a certain location, configured TLS parameter are compared to the current TLS parameters. If they differ, renegotiation is triggered.
Most common use cases for this are cipher changes and client certificates. You can require clients to meet authentication only for special locations, or you might enable more secure, but CPU intensive ciphers for specific resources.
Whatever your good use cases are, renegotiation are a **MUST NOT** in HTTP/2. With 100s of requests ongoing on the same connection, which renegotiation would otherwise occur when?
The current **mod_h[ttp]2** does not protect you from such configuration. If you have a site which uses TLS renegotiation, DO NOT enable h2 on it!
Again, we will address that in future releases so that you can enable it safely.
### Restrictions ###
#### Non-HTTP Protocols ####
Modules implementing protocols other than HTTP may be incompatible with **mod_http2**. This will most certainly be the case when this other protocol requires the server to send data first.
**NNTP** is one example of such a protocol. If you have a **mod_nntp_like_ssl** configured in your server, do not even load mod_http2. Wait for the next release.
#### h2c Restrictions ####
There are some restrictions on the **h2c** implementation, you should be aware of:
#### Deny h2c on virtual host ####
You cannot deny **h2c direct** on specific virtual hosts. **direct** gets triggered at connection setup when there is not request to be seen yet. Which makes it impossible to foresee which virtual host Apache needs to look at.
#### Upgrade on request body ####
The **h2c** Upgrade dance will not work on requests that have a body. Those are PUT and POST requests (form submits and uploads). If you write a client, you may precede those requests with a simple GET or an OPTIONS * to trigger the upgrade.
The reason is quite technical in nature, but in case you want to know: during Upgrade, the connection is in a half insane state. The request is coming in HTTP/1.1 format and the response is being written in HTTP/2 frames. If the request carries a body, the server needs to read the whole body before it sends a response back. Because the response might need answers from the client for flow control among other things. But if the HTTP/1.1 request is still being sent, the client is unable to talk HTTP/2 yet.
In order to make behaviour predictable, several server implementors decided to not do an Upgrade in the presence of any request bodies, even small ones.
#### Upgrade on 302s ####
The h2c Upgrade dance also does currently not work when there is a general redirect in place. Seems that rewrite happens before the mod_http2 has a chance to act. Certainly not a deal breaker, but might be confusing when you test a site that has it.
#### h2 Restrictions ####
There are some restrictions on the h2 implementation you should be aware of:
#### Connection Reuse ####
The HTTP/2 protocol allows reuse of TLS connections under certain conditions: if you have a certiface with wildcards or several altSubject names, browsers will reuse any existing connection they might have. Example:
You have a certificate for **a.example.org** that has as additional name **b.example.org**. You open in your browser the url **https://a.example.org/**, open another tab and load **https://b.example.org/**.
Before opening a new connection, the browser sees that it still has the one to **a.example.org** open and that the certificate is also valid for **b.example.org**. So, it sends the request for second tab over the connection of the first one.
This connection reuse is intentional and makes it easier for sites that have invested in sharding for efficiency in HTTP/1 to also benefit from HTTP/2 without much change.
In Apache **mod_h[ttp]2** this is not fully implemented, yet. When **a.example.org** and **b.example.org** are separate virtual hosts, Apache will not allow such connection reuse and inform the browser with status code **421 Misdirected Request** about it. The browser will understand that it has to open a new connection to **b.example.org**. All will work, however some efficiency gets lost.
We expect to have the proper checks in place for the next release.
Münster, 12.10.2015,
Stefan Eissing, greenbytes GmbH
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without warranty of any kind. See LICENSE for details.
----------
This project is maintained by [icing][13]
--------------------------------------------------------------------------------
via: https://icing.github.io/mod_h2/howto.html
作者：[icing][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://github.com/icing
[1]:https://httpd.apache.org/download.cgi
[2]:https://httpd.apache.org/docs/2.4/install.html
[3]:https://nghttp2.org/
[4]:https://icing.github.io/mod_h2/howto.html#https
[5]:https://icing.github.io/mod_h2/howto.html#h2c-restrictions
[6]:https://icing.github.io/mod_h2/howto.html#h2c-restrictions
[7]:https://httpwg.github.io/specs/rfc7540.html#BadCipherSuites
[8]:http://chimera.labs.oreilly.com/books/1230000000545
[9]:https://icing.github.io/mod_h2/howto.html#curl
[10]:https://icing.github.io/mod_h2/howto.html#curl
[11]:https://www.apachelounge.com/
[12]:https://addons.mozilla.org/en-US/firefox/addon/spdy-indicator/
[13]:https://github.com/icing

375
translated/tech/20151020 how to h2 in apache.md Normal file
View File

@ -0,0 +1,375 @@
如何在 Apache 中启用 HTTP/2
================================================================================
Copyright (C) 2015 greenbytes GmbH
刚发布的 Apache httpd 2.4.17 终于支持 HTTP/2 了。这个页面给出了一些如何构建/部署/配置的建议。目的是为了大家发现 bugs 时能升级它，或者给一些能更好工作的建议。
最后，这会归并回到官方 Apache 文档，这里只会留下一个到那里的链接。暂时我们还没做到。
### 源码 ###
你可以从[这里][1]得到 Apache 发行版。Apache 2.4.17 及其更高版本都支持 HTTP/2。我不会再重复介绍如何构建服务器的指令。在很多地方有很好的指南，例如[这里][2]。
（有任何试验的链接？在 Twitter 上告诉我吧 @icing）
#### 编译支持 HTTP/2 ####
在你编译发行版之前，你要进行一些**配置**。这里有成千上万的选项。和 HTTP/2 相关的是：
- **--enable-http2**
启用在 Apache 服务器内部实现协议的 ‘http2’ 模块。
- **--with-nghttp2=<dir>**
指定 http2 模块需要的 libnghttp2 模块的非默认位置。如果 nghttp2 是在默认的位置，配置过程会自动采用。
- **--enable-nghttp2-staticlib-deps**
很少用到的选项，你可能用来静态链接 nghttp2 库到服务器。在大部分平台上，只有在找不到共享 nghttp2 库时才有效。
如果你想自己编译 nghttp2，你可以到 [nghttp2.org][3] 查看文档。最新的 Fedora 以及其它发行版已经附带了这个库。
#### TLS 支持 ####
大部分人想在浏览器上使用 HTTP/2， 而浏览器只在 TLS 连接（**https:// 开头的 url）时支持它。你需要一些我下面介绍的配置。但首先你需要的是支持 ALPN 扩展的 TLS 库。
ALPN 用来屏蔽服务器和客户端之间的协议。如果你服务器上 TLS 库还没有实现 ALPN，客户端只能通过 HTTP/1.1 通信。那么，和 Apache 连接的到底是什么？又是什么支持它呢？
- **OpenSSL 1.0.2** 即将到来。
- ???
如果你的 OpenSSL 库是 Linux 发行版自带的，这里使用的版本号可能和官方 OpenSSL 发行版的不同。如果不确定的话检查一下你的 Linux 发行版吧。
### 配置 ###
另一个给服务器的好建议是为 http2 模块设置合适的日志等级。添加下面的配置：
# 某个地方有这样一行
LoadModule http2_module modules/mod_http2.so
<IfModule http2_module>
LogLevel http2:info
</IfModule>
当你启动服务器的时候，你可以在错误日志中看来类似的一行：
[timestamp] [http2:info] [pid XXXXX:tid numbers]
mod_http2 (v1.0.0, nghttp2 1.3.4), initializing...
#### 协议 ####
那么，假设你已经编译部署好了服务器， TLS 库也是最新的，你启动了你的服务器，打开了浏览器。。。你怎么知道它在工作呢？
如果除此之外你没有添加其它到服务器配置，很可能它没有工作。
你需要告诉服务器在哪里使用协议。默认情况下，你的服务器并没有启动 HTTP/2 协议。因为这是安全路由，你可能要有一套部署了才能继续。
你用 **Protocols** 命令启用 HTTP/2 协议：
# for a https server
Protocols h2 http/1.1
...
# for a http server
Protocols h2c http/1.1
你可以给一般服务器或者指定的 **vhosts** 添加这个配置。
#### SSL 参数 ####
对于 TLS （SSL），HTTP/2 有一些特殊的要求。阅读 [https:// 连接][4]了解更详细的信息。
### http:// 连接 (h2c) ###
尽管现在还没有浏览器支持 HTTP/2 协议， http:// 这样的 url 也能正常工作， 因为有 mod_h[ttp]2 的支持。启用它你只需要做的一件事是在 **httpd.conf** 配置 Protocols ：
# for a http server
Protocols h2c http/1.1
这里有一些支持 **h2c** 的客户端（和客户端库）。我会在下面介绍：
#### curl ####
Daniel Stenberg 维护的网络资源命令行客户端 curl 当然支持。如果你的系统上有 curl，有一个简单的方法检查它是否支持 http/2：
sh> curl -V
curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets
不好了。这些功能中没有 'HTTP2'。你想要的是下面这样：
sh> curl -V
url 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets
如果你的 curl 支持 HTTP2 功能，你可以用一些简单的命令检查你的服务器：
sh> curl -v --http2 http://<yourserver>/
...
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQAAP__
>
< HTTP/1.1 101 Switching Protocols
< Upgrade: h2c
< Connection: Upgrade
* Received 101
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
...
<the resource>
恭喜，如果看到了有 **...101 Switching...** 的行就表示它正在工作！
有一些情况不会发生到 HTTP/2 的 Upgrade 。如果你的第一个请求没有内容，例如你上传一个文件，就不会触发 Upgrade。[h2c 限制][5]部分有详细的解释。
#### nghttp ####
nghttp2 有能一起编译的客户端和服务器。如果你的系统中有客户端，你可以简单地通过获取资源验证你的安装：
sh> nghttp -uv http://<yourserver>/
[ 0.001] Connected
[ 0.001] HTTP Upgrade request
...
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: AAMAAABkAAQAAP__
...
[ 0.005] HTTP Upgrade response
HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade
[ 0.006] HTTP Upgrade success
...
这和我们上面 **curl** 例子中看到的 Upgrade 输出很相似。
在命令行参数中隐藏着一种可以使用 **h2c**：的参数：**-u**。这会指示 **nghttp** 进行 HTTP/1 Upgrade 过程。但如果我们不使用呢？
sh> nghttp -v http://<yourserver>/
[ 0.002] Connected
[ 0.002] send SETTINGS frame
...
[ 0.002] send HEADERS frame
; END_STREAM | END_HEADERS | PRIORITY
(padlen=0, dep_stream_id=11, weight=16, exclusive=0)
; Open new stream
:method: GET
:path: /
:scheme: http
...
连接马上显示出了 HTTP/2！这就是协议中所谓的直接模式，当客户端发送一些特殊的 24 字节到服务器时就会发生：
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
or in ASCII: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
支持 **h2c** 的服务器在一个新的连接中看到这些信息就会马上切换到 HTTP/2。HTTP/1.1 服务器则认为是一个可笑的请求，响应并关闭连接。
因此 **直接** 模式只适合于那些确定服务器支持 HTTP/2 的客户端。例如，前一个 Upgrade 过程是成功的。
**直接** 模式的魅力是零开销，它支持所有请求，即使没有 body 部分（查看[h2c 限制][6]）。任何支持 h2c 协议的服务器默认启用了直接模式。如果你想停用它，可以添加下面的配置指令到你的服务器：
注：下面这行打删除线
H2Direct off
注：下面这行打删除线
对于 2.4.17 发行版，默认明文连接时启用 **H2Direct** 。但是有一些模块和这不兼容。因此，在下一发行版中，默认会设置为**off**，如果你希望你的服务器支持它，你需要设置它为：
H2Direct on
### https:// 连接 (h2) ###
一旦你的 mod_h[ttp]2 支持 h2c 连接，就是时候一同启用 **h2**，因为现在的浏览器支持它和 **https:** 一同使用。
HTTP/2 标准对 https:（TLS）连接增加了一些额外的要求。上面已经提到了 ALNP 扩展。另外的一个要求是不会使用特定[黑名单][7]中的密码。
尽管现在版本的 **mod_h[ttp]2** 不增强这些密码（以后可能会），大部分客户端会这么做。如果你用不切当的密码在浏览器中打开 **h2** 服务器，你会看到模糊警告**INADEQUATE_SECURITY**，浏览器会拒接连接。
一个可接受的 Apache SSL 配置类似：
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
SSLProtocol All -SSLv2 -SSLv3
...
（是的，这确实很长。）
这里还有一些应该调整的 SSL 配置参数，但不是必须：**SSLSessionCache**， **SSLUseStapling** 等，其它地方也有介绍这些。例如 Ilya Grigorik 写的一篇博客 [高性能浏览器网络][8]。
#### curl ####
再次回到 shell 并使用 curl（查看 [curl h2c 章节][9] 了解要求）你也可以通过 curl 用简单的命令检测你的服务器：
sh> curl -v --http2 https://<yourserver>/
...
* ALPN, offering h2
* ALPN, offering http/1.1
...
* ALPN, server accepted to use h2
...
<the resource>
恭喜你，能正常工作啦！如果还不能，可能原因是：
- 你的 curl 不支持 HTTP/2。查看[检测][10]。
- 你的 openssl 版本太低不支持 ALPN。
- 不能验证你的证书，或者不接受你的密码配置。尝试添加命令行选项 -k 停用 curl 中的检查。如果那能工作，还要重新配置你的 SSL 和证书。
#### nghttp ####
我们已经在 **h2c** 讨论过 **nghttp**。如果你用它来进行 **https:** 连接，你会看到类似下面的信息：
sh> nghttp https://<yourserver>/
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
这有两种可能，你可以通过添加 -v 来检查。如果是：
sh> nghttp -v https://<yourserver>/
[ 0.034] Connected
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
这意味着你服务器使用的 TLS 库没有实现 ALPN。有时候正确安装有点困难。多看看 Stackoverflow 吧。
你看到的也可能是：
sh> nghttp -v https://<yourserver>/
[ 0.034] Connected
The negotiated protocol: http/1.1
[ERROR] HTTP/2 protocol was not selected. (nghttp2 expects h2)
这表示 ALPN 能正常工作，但并没有用 h2 协议。你需要像上面介绍的那样在服务器上选中那个协议。如果一开始在 vhost 部分选中不能正常工作，试着在通用部分选中它。
#### Firefox ####
Update： [Apache Lounge][11] 的 Steffen Land 告诉我 [Firefox HTTP/2 指示插件][12]。你可以看到有多少地方用到了 h2（提示：Apache Lounge 用 h2 已经有一段时间了。。。）
你可以在 Firefox 浏览器中打开开发者工具，在那里的网络标签页查看 HTTP/2 连接。当你打开了 HTTP/2 并重新刷新 html 页面时，你会看到类似下面的东西：
![](https://icing.github.io/mod_h2/images/firefox-h2.png)
在响应头中，你可以看到奇怪的 **X-Firefox-Spdy** 条目中列出了 “h2”。这表示在这个 **https:** 连接中使用了 HTTP/2。
#### Google Chrome ####
在 Google Chrome 中，你在开发者工具中看不到 HTTP/2 指示器。相反，Chrome 用特殊的地址 **chrome://net-internals/#http2** 给出了相关信息。
如果你在服务器中打开了一个页面并在 Chrome 那个页面查看，你可以看到类似下面这样：
![](https://icing.github.io/mod_h2/images/chrome-h2.png)
如果你的服务器在上面的列表中，就表示它正在工作。
#### Microsoft Edge ####
Windows 10 中 Internet Explorer 的继任者 Edge 也支持 HTTP/2。你也可以在开发者工具的网络标签页看到 HTTP/2 协议。
![](https://icing.github.io/mod_h2/images/ie-h2.png)
#### Safari ####
在 Apple 的 Safari 中，打开开发者工具，那里有个网络标签页。重新加载你的服务器页面并在开发者工具中选择显示了加载的行。如果你启用了在右边显示详细试图，看 **状态** 部分。那里显示了 **HTTP/2.0 200**，类似：
![](https://icing.github.io/mod_h2/images/safari-h2.png)
#### 重新协商 ####
https： 连接重新协商是指正在运行的连接中特定的 TLS 参数会发生变化。在 Apache httpd 中，你可以通过目录中的配置文件修改 TLS 参数。如果一个要获取特定位置资源的请求到来，配置的 TLS 参数会和当前的 TLS 参数进行对比。如果它们不相同，就会触发重新协商。
这种最常见的情形是密码变化和客户端验证。你可以要求客户访问特定位置时需要通过验证，或者对于特定资源，你可以使用更安全的， CPU 敏感的密码。
不管你的想法有多么好，HTTP/2 中都**不可以**发生重新协商。如果有 100 多个请求到同一个地方，什么时候哪个会发生重新协商呢？
对于这种配置，现有的 **mod_h[ttp]2** 还不能保证你的安全。如果你有一个站点使用了 TLS 重新协商，别在上面启用 h2！
当然，我们会在后面的发行版中解决这个问题然后你就可以安全地启用了。
### 限制 ###
#### 非 HTTP 协议 ###
实现除 HTTP 之外协议的模块可能和 **mod_http2** 不兼容。这在其它协议要求服务器首先发送数据时无疑会发生。
**NNTP** 就是这种协议的一个例子。如果你在服务器中配置了 **mod_nntp_like_ssl**，甚至都不要加载 mod_http2。等待下一个发行版。
#### h2c 限制 ####
**h2c** 的实现还有一些限制，你应该注意：
#### 在虚拟主机中拒绝 h2c ####
你不能对指定的虚拟主机拒绝 **h2c 直连**。连接建立而没有看到请求时会触发**直连**，这使得不可能预先知道 Apache 需要查找哪个虚拟主机。
#### 升级请求体 ####
对于有 body 部分的请求，**h2c** 升级不能正常工作。那些是 PUT 和 POST 请求（用于提交和上传）。如果你写了一个客户端，你可能会用一个简单的 GET 去处理请求或者用选项 * 去触发升级。
原因从技术层面来看显而易见，但如果你想知道：升级过程中，连接处于半疯状态。请求按照 HTTP/1.1 的格式，而响应使用 HTTP/2。如果请求有一个 body 部分，服务器在发送响应之前需要读取整个 body。因为响应可能需要从客户端处得到应答用于流控制。但如果仍在发送 HTTP/1.1 请求，客户端就还不能处理 HTTP/2 连接。
为了使行为可预测，几个服务器实现商决定不要在任何请求体中进行升级，即使 body 很小。
#### 升级 302s ####
有重定向发生时当前 h2c 升级也不能工作。看起来 mod_http2 之前的重写有可能发生。这当然不会导致断路，但你测试这样的站点也许会让你迷惑。
#### h2 限制 ####
这里有一些你应该意识到的 h2 实现限制：
#### 连接重用 ####
HTTP/2 协议允许在特定条件下重用 TLS 连接：如果你有带通配符的证书或者多个 AltSubject 名称，浏览器可能会重用现有的连接。例如：
你有一个 **a.example.org** 的证书，它还有另外一个名称 **b.example.org**。你在浏览器中打开 url **https://a.example.org/**，用另一个标签页加载 **https://b.example.org/**。
在重新打开一个新的连接之前，浏览器看到它有一个到 **a.example.org** 的连接并且证书对于 **b.example.org** 也可用。因此，它在第一个连接上面向第二个标签页发送请求。
这种连接重用是刻意设计的，它使得致力于 HTTP/1 切分效率的站点能够不需要太多变化就能利用 HTTP/2。
Apache **mod_h[ttp]2** 还没有完全实现这点。如果 **a.example.org** 和 **b.example.org** 是不同的虚拟主机， Apache 不会允许这样的连接重用，并会告知浏览器状态码**421 错误请求**。浏览器会意识到它需要重新打开一个到 **b.example.org** 的连接。这仍然能工作，只是会降低一些效率。
我们期望下一次的发布中能有切当的检查。
Münster, 12.10.2015,
Stefan Eissing, greenbytes GmbH
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without warranty of any kind. See LICENSE for details.
----------
该项目由 [icing][13] 维护。
--------------------------------------------------------------------------------
via: https://icing.github.io/mod_h2/howto.html
作者：[icing][a]
译者：[ictlyh](http://mutouxiaogui.cn/blog/)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://github.com/icing
[1]:https://httpd.apache.org/download.cgi
[2]:https://httpd.apache.org/docs/2.4/install.html
[3]:https://nghttp2.org/
[4]:https://icing.github.io/mod_h2/howto.html#https
[5]:https://icing.github.io/mod_h2/howto.html#h2c-restrictions
[6]:https://icing.github.io/mod_h2/howto.html#h2c-restrictions
[7]:https://httpwg.github.io/specs/rfc7540.html#BadCipherSuites
[8]:http://chimera.labs.oreilly.com/books/1230000000545
[9]:https://icing.github.io/mod_h2/howto.html#curl
[10]:https://icing.github.io/mod_h2/howto.html#curl
[11]:https://www.apachelounge.com/
[12]:https://addons.mozilla.org/en-US/firefox/addon/spdy-indicator/
[13]:https://github.com/icing