Http2服务调用排坑记

原文作者：陈友行
原文链接：https://www.nginx.org.cn/article/detail/89
转载来源：NGINX开源社区
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1.   了解HTTP2

时代在发展，使用http协议的人越来越多。http1.1的弊端慢慢都被显现出来。

1）   浏览器方式一些网站频繁发送请求，造成一家独大其他网站无法使用。或者所有网站都频发发送请求造成用户体验差等等问题。限制每个url同时并发数量。

2）   提高请求的响应速度。只有一个连接，只有一次tcp三次握手或者tls的7次握手。一个http1.1请求所用的时间，http2.0可以处理三到四个请求。

3）   提高服务端与客服端的性能（尤其是大型互联网公司流量很大，如果使用http2.0，可以减少一半的http服务器）。

http客服端不知道http服务端是否支持http2.0。反过来 http服务端也不知道http客服端是否支持http2.0。为什么出现这种现象，让所有的http服务端与http客服端直接从http1.1过度到http2.0是不可能的事情。甚至在大点的公司内部直接从http1.1直接过度到http2.0也是一件不现实的事情，那么出现一件麻烦的事情有http1客服端，也有http2客服端。有http2服务端，也有http1服务端。这种两个维度，四种情况的共存现象。

有人会问，只支持http1.1不好吗？ 已经支持http2,.0的client肯定不会放弃http2.0优秀的性能与特性，能使用使用http2.0，就要使用。

那么http2.0的设计者为了解决这种麻烦的东西。推出了解决方案：协商。

https1.1与https2.0的协商是基于ALPN机制。ALPNS是基于TLS实现。在建立TLS链接的时候，客服端会 在TLS协议里面加入自己支持的协议，服务端在客服端支持的协议里面选中一个自己最合适的。然后把选中的协议通知给客服端。如果客户端没有发送支持的http协议，服务端会默认使用http1.1。

http没有TLS协议，无法基于TLS传递协议。协议制定者使用了Upgrade机制。客户端发送一个空请求，请求里面包含该Upgrade,Connection,HTTP2-Settings请求头。服务端从Upgrade取出支持的协议然后响应请求，在响应的请求头里面包含Upgrade,Connection。这样协商就成功。

下面是http1.1与http2.0的协商流程，请求头示例：

GET / HTTP/1.1 Host: example.com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

如果服务端不支持 HTTP/2，它会忽略 Upgrade 字段，直接返回 HTTP/1.1 响应，例如：

HTTP/1.1 200 OK Content-Length: 243 Content-Type: text/html

如果服务端支持 HTTP/2，那就可以回应 101 状态码及对应头部：

HTTP/1.1 100 Switching Protocols Connection: Upgrade Upgrade: h2c

小结：

1）https 1.1 与https.2.0的协商 与 http1.1与http2.0的协商是两套设计方案。https 1.1 与https.2.0 TLS自动实现。http1.1与http2.0的协商需要自己实现。

2）现在的趋势，客服端与服务端都需要同时支持http1.1，http2.0，https1.1，https2.0，技术实现比较复杂。

2.   问题初现

1、项目的问题出在于通过JAVA端去调用华为提供的H2服务时，一直返回PROTOCOL_ERROR错误；但是同样的写法调用，自己写的H2服务是可以的，调用baidu,taobao,small都可以；也就是说明程序是可以用的，但为什么华为就是返回错误呢？ 以下是华为侧回复的内容：

意思是说客户端调用时使用的协议不对，服务端解析不了，要求我们在报文头加上协调参数。客户端按要求修改，但问题依旧；发现服务端并不支持协商的方式去调用，抓如下：

2、其它工具验证：

1)     浏览器调用不成功。

2)     POSTMAN调用不成功。

3)     CURL调用不成功。

3、Jdk版本支持H2说明：

原文链接：https://blog.csdn.net/taiyangdao/article/details/80883189

1)     Java 8

初始即支持TLS 1.2，并且客户端默认即使用TLS 1.2。

但是为了支持HTTP2，还要借助于Jetty的ALPN模块alpn-boot。

下载alpn-boot的jar，并且在启动JVM时加参数java -Xbootclasspath/p:<path_to_alpn_boot_jar> ...

2)     Java 9

初始即支持TLS 1.2，并且客户端默认即使用TLS 1.2。

通过JEP 244, TLS ALPN Extension支持ALPN，完整支持了HTTP2。

3)      Java 10

同Java 9。

4)     Java 11

同Java 9，并进而支持TLS 1.3。

3.   排查过程
到此时发现，根据第二部分所讲，JAVA端调用HTTP2的以下两种方式都走不通：

1)       调https方式，因为5G核心网为了提高效率，而且都是内部使用，规范中并不提供加密调用的方式，走不通。

2)       走http1.1协商的方式，需要服务端根据协调参数，自动选择；但现在也不支持。

3.1.  换jar包
在此过程上反复的尝试了多种方法：

1）升级到jdk11，通过原生的httpClient去调用，问题依旧：

HttpClient client = HttpClient.newBuilder()

.version(HttpClient.Version.HTTP_2)

.priority(0)

.sslContext(SSLContext.getInstance("TLSv1.2"))

.build();

2）  通过okHttpClient3.2去调用，问题依旧：

3）  通过netty去调用，问题依旧。

4）   协调了客户侧的网络专家帮忙分析，通过curl --http2调用，问题依旧。

3.2. 分析C++成功案例：
后台C++开发客户端是可以正常调用的，通过了解，C++指定了强制使用H2协议去调用，将包抓出来比对，发现在客户端发送请求时，确实存在差异：

问题定位：

java端是否有也类型的参数，可以指定强制使用H2方式去调用呢；

3.3. 尝试curl命令
首先通过curl进行反复的尝试：

Curl 只设置了--http2 参数时调用不成功 。

在https://curl.haxx.se/docs/http2.html 找到了参数--http2-prior-knowledge说明：

Curl 通过 --http2-prior-knowledge 强制使用H2协议去调用，验证成功。

3.4. 查找类prior-knowledge参数，解决问题
在https://www.jianshu.com/p/9530d58250c7 中找到解决办法：

动手尝试验证：

第一步，升级okHttpClient包到4.1.0：

第二步，编写测试程序：

第三步，抓包验证，成功：

4.   总结：java调用H2的方法
4.1.  加密调用
https1.1与https2.0的协商是基于ALPN机制。ALPNS是基于TLS实现。在建立TLS链接的时候，客服端会 在TLS协议里面加入自己支持的协议，服务端在客服端支持的协议里面选中一个自己最合适的。然后把选中的协议通知给客服端。如果客户端没有发送支持的http协议，服务端会默认使用http1.1

4.2. 协商调用
  开源地址：https://http2.github.io/http2-spec/#discover-http：

4.3. 强制指定H2方式调用