http2.0反向代理遇到的坑

使用域名指向nginx服務(wù)來代理https，nginx可以通過分析clienthello中的server_name字段得到訪問域名，然后通過解析域名地址來進(jìn)行代理。

這里有幾個(gè)問題，第一個(gè)是低版本的ie瀏覽器，使用的是低版本的tls，沒有這個(gè)字段，無法得到域名，不過現(xiàn)在使用低版本IE的越來越少了，可以忽略。
第二個(gè)是蘋果的某些系統(tǒng)應(yīng)用，填寫的域名不是真正的域名，不過有跡可循，可以通過字符串修改為真正的域名，進(jìn)行代理。

最近測試京東的時(shí)候發(fā)現(xiàn)訪問京東二級域名的時(shí)候偶爾會返回200，偶爾會301一個(gè)異常頁面。

而如果新開瀏覽器打開二級頁面，就沒有這種問題。
偶爾發(fā)現(xiàn)如果不使用域名直接代理，而是使用瀏覽器代理設(shè)置，訪問一切正常，非常奇怪。
通過對比發(fā)現(xiàn)，使用域名代理時(shí)使用的是HTTP2.0，而設(shè)置瀏覽器代理時(shí)使用的是HTTP1.1，于是在瀏覽器禁止http2.0（火狐設(shè)置 about：config network.http.spdy.enabled.http2為假/gg瀏覽器沒找到怎么設(shè)置），訪問京東一切正常。
客戶端在請求的時(shí)候會攜帶自己支持的http類型

于是想到在代理時(shí)篡改字段，把http2.0給關(guān)掉，只申請http1.1，但是連接會被中斷。
https://blog.csdn.net/mrpre/article/details/77868570
根據(jù)這個(gè)網(wǎng)頁可以知道，雖然hello是明文的，但是也有校驗(yàn)，篡改是走不通的。
繼續(xù)進(jìn)一步抓包，發(fā)現(xiàn)在訪問二級頁面時(shí)，瀏覽器發(fā)出了幾十個(gè)請求（不同域名），但是抓包只有一個(gè)鏈接，難道HTTP2.0會把不同域名同樣IP的請求放在一個(gè)鏈接里面復(fù)用嗎？所以導(dǎo)致了問題。
這里做了一些嘗試，使用jiadian.jd.com的url訪問www.jd.com 的ip地址。

我們發(fā)現(xiàn)剛好和瀏覽器出現(xiàn)的錯(cuò)誤一樣，都帶了一個(gè)cdn_nohost。
基本可以確定HTTP2.0對于多個(gè)域名解析到同一個(gè)ip上的情況下，會復(fù)用連接，那么在這種情況下，簡單的https代理就不開行了，只能針對一個(gè)域名給予一個(gè)ip的方法才能處理。