jdk1.7環境java代碼通路https(connection reset)

問題描述:

jdk1.8環境java代碼通路https服務(跳過證書)一切正常；

jdk1.7環境java代碼通路https服務(自家的服務)connection reset, 

堅信代碼沒有問題，于是測試别人家的https服務，jdk1.7環境同樣的代碼通路正常，

于是繼續測試代碼，本地配置nginx(https)服務和tomcat(https)服務，jdk1.7環境同樣

代碼再次運作正常，于是更加堅信代碼沒有問題,肯定是自家生産環境配置的問題，限制了

協定(本人對協定也是一知半解)；

生産環境配置排查:

産環境請求路徑: elb(彈性負載均衡[https])->nginx(http)->tomcat(http)

排查流程，确認問題出在哪個環節:

同樣的代碼打包三份([1]直接通路tomcat服務，[2]通路nginx->tomcat服務, [3]通路elb->nginx->tomcat);

環境準備: jdk1.7環境,jdk1.8環境;

測試驗證1(jdk1.7環境):

運作打包代碼1、2、3,結果隻有代碼3報錯，connection reset;

測試驗證2(jdk1.8環境)

運作打包代碼1、2、3,全部正常;

由此可推論出生産的配置不支援jdk1.7通路https，配置出在elb上面(https);

以上的環節隻是為了更加确認問題出在哪個環節，結論更加令人信服;

問題解決:

排查生産elb配置，排查方向當然是SSL協定配置，最後果然如此，elb配置的SSL協定是預設的(TLSv1.2),

于是修改成支援多協定(TLSv1.2 TLSv1.1 TLSv1)，問題解決(最後附上ssl配置的截圖);聽運維說jdk1.7對應的協定應該是TLSv1.1，

但是修改後還有TLSv1,無法驗證jdk1.7對應的哪個協定;

以上結果不重要，排查的問題的方法很重要，排查的思路一定要清晰，大概确定問題的環節，才能有針對性的去排查，

排查過程很心酸，但是收貨很大，也再次證明自己找bug的能力還是可以的！！！

注:本人對協定一知半解，甚至可以說不了解，但一樣能解決協定存在的問題，隻要相信自己，有毅力，什麼事情都能解決的 ！！