APP使用HTTP2协议的一点小收获

前几天提到网络连接和ssl握手延迟，想到SLB已经配置支持HTTP/2了，就想确认下：

• curl —http2  -I https://api.test.com

• 启用了阿里云的日志服务-SLB，protorl参数返回了HTTP/2

阿里云日志服务也是一个好东西，有点类似于ELK，本来高峰期间发现峰值流量比较大，原来有个接口size比较大，直接占了30%的流量，优化后一下清净了。

对于优化来说，应该挑大头来解决，同时也要关注细节。

HTTP/2好处：

• 多路复用，真正的并行请求

• 支持服务器端push

• 更小的header头，减少网络延迟

想证实客户端调用接口有没有走HTTP/2多路复用，由于服务器在SLB后面，走的是80端口，从服务器上抓包是看不出来了。

从前台选择使用wireshark抓取app HTTPS流量，遇到一个问题。

让同事在电脑装了个andriod模拟器（夜神多开器），可惜还是不能破解HTTPS流量，顺带温习了相关知识。

如果是RSA密钥交换，及时配置了私钥文件也不能解密；如果是DH密钥交换，模拟器不像浏览器支持SSLKEYLOGFILE变量，所以没法支持pre-master secret key解密方式。

总之目前没法看到具体的HTTP/2流量，具体参考https://www.comparitech.com/net-admin/decrypt-ssl-with-wireshark/。

不管是IOS还是Andriod都有网络框架，比如okhttp，原来那么强大：

• HTTP/2 support allows all requests to the same host to share a socket.

• Connection pooling reduces request latency (if HTTP/2 isn’t available).

• Transparent GZIP shrinks download sizes.

• Response caching avoids the network completely for repeat requests.

也就是说至少会维护连接池功能，这样对服务器的压力就减少了很多，网络层的消耗就可以忽略不计了，用户体验也提高了不少，如果能用到多路复用，那就更棒了。

关于重复请求的cache功能感觉也很有意思，后续可以研究研究。

和后端开发相比，APP开发模式是完全不一样的。

以前也写过一篇Fiddler解密HTTPS流量的文章，后面尝试看看，个人觉得能破解，但不能使用HTTP/2包，会降级为HTTP/1.1。

虽然不会开发APP，但还是希望有一种方式能够看到网络层的调用。