前幾天提到網(wǎng)絡(luò)連接和ssl握手延遲遣总,想到SLB已經(jīng)配置支持HTTP/2了,就想確認下:
curl —http2? -I https://api.test.com
啟用了阿里云的日志服務(wù)-SLB,protorl參數(shù)返回了HTTP/2
阿里云日志服務(wù)也是一個好東西,有點類似于ELK,本來高峰期間發(fā)現(xiàn)峰值流量比較大塞琼,原來有個接口size比較大,直接占了30%的流量禁舷,優(yōu)化后一下清凈了彪杉。
對于優(yōu)化來說,應(yīng)該挑大頭來解決榛了,同時也要關(guān)注細節(jié)在讶。
HTTP/2好處:
多路復(fù)用,真正的并行請求
支持服務(wù)器端push
更小的header頭霜大,減少網(wǎng)絡(luò)延遲
想證實客戶端調(diào)用接口有沒有走HTTP/2多路復(fù)用构哺,由于服務(wù)器在SLB后面,走的是80端口,從服務(wù)器上抓包是看不出來了曙强。
從前臺選擇使用wireshark抓取app HTTPS流量残拐,遇到一個問題。
讓同事在電腦裝了個andriod模擬器(夜神多開器)碟嘴,可惜還是不能破解HTTPS流量溪食,順帶溫習了相關(guān)知識。
如果是RSA密鑰交換娜扇,及時配置了私鑰文件也不能解密错沃;如果是DH密鑰交換,模擬器不像瀏覽器支持SSLKEYLOGFILE變量雀瓢,所以沒法支持pre-master secret key解密方式枢析。
總之目前沒法看到具體的HTTP/2流量,具體參考https://www.comparitech.com/net-admin/decrypt-ssl-with-wireshark/刃麸。
不管是IOS還是Andriod都有網(wǎng)絡(luò)框架醒叁,比如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.
也就是說至少會維護連接池功能泊业,這樣對服務(wù)器的壓力就減少了很多把沼,網(wǎng)絡(luò)層的消耗就可以忽略不計了,用戶體驗也提高了不少吁伺,如果能用到多路復(fù)用饮睬,那就更棒了。
關(guān)于重復(fù)請求的cache功能感覺也很有意思篮奄,后續(xù)可以研究研究续捂。
和后端開發(fā)相比,APP開發(fā)模式是完全不一樣的宦搬。
以前也寫過一篇Fiddler解密HTTPS流量的文章,后面嘗試看看劫拗,個人覺得能破解间校,但不能使用HTTP/2包,會降級為HTTP/1.1页慷。
雖然不會開發(fā)APP憔足,但還是希望有一種方式能夠看到網(wǎng)絡(luò)層的調(diào)用。