對自己無知這件事本身的無知真的挺可怕
認知偏差現象一直存在于我們每個人身上，誰也避免不掉，不過是有的人了解這件事兒，有的人不怎么知道而已，這就產生了「無知而不自知」的認知偏差。當然，這時候你自己忽悠自己倒沒什么，頂多讓自己每天感覺自己挺厲害的，沉浸于虛幻的優越感中，以為自己比大多數人都優秀，這倒不是一件什么壞事情，但是，如果你和別人溝通交流中展現出來，那挺可怕的，況且有時候你自己并不知道，達克效應(Dunning-Kruger Effect)描述的就是這種現象。避免這種現象在自己身上的存在，沒什么特殊方法，多學習那些本身就極其優秀的人是怎么思考和生存的，表現出謙遜算其中一種，還有就是多讀書。就這樣...
全站 HTTPS 必要準備工作
做任何一件事情最好的情況就是你剛好做過，這倒沒什么可說的，因為第二次總是要比第一次好。如果你沒做過這件事怎么辦？沒事，去看看別人怎么做的。
升級全站 HTTPS 工作在兩年前左右應該是討論最火的了，在2014年底，google Chromium 安全團隊提議將所有的 HTTP 協議網站標注為不安全，市場占有率較高的 Chrome 瀏覽器也是這么做的，所以在接下來一段時間內，各個大廠、大公司都逐步升級了 HTTPS 協議，當然，去年 Apple 也宣布所有應用開發者必須在 2017 年 1 月 1 日之前實現所有的 App 接入安全地服務器，即網絡傳輸協議使用 HTTPS。所以呢，我們就簡單的看一下國內這些頂尖互聯網企業如何實現全站 HTTPS 的：
- 淘寶啟用全站HTTPS后不僅更安全而且更快 看淘寶是如何做到的
- 百度大型網站的HTTPS實踐一：HTTPS協議和原理HTTPS對網站性能seo有哪些影響？大型網站HTTPS實踐三：基于協議和配置的優化大型網站的HTTPS實踐四：協議層以外的實踐
看完這些文章后，估計你就可以知道要買 SSL 證書了，也可以去買 SSL 證書了，具體是使用各個云服務商家的免費單域名證書，還是業務需要更強大的泛域名證書、OV 證書等等，你就需要看看我寫的這兩篇文章了（好不要臉吖..）：
- 讓你的網站免費支持 HTTPS 及 Nginx 平滑升級
- 一篇文章讓你搞懂 SSL 證書
分析整個系統制定計劃
有計劃才能沒變化。其實也沒什么要做的，只有一件事，你接下來要做的唯一一件事就是了解整個系統。統計出所有已用到的域名，需要購買什么類型域名證書，是二級域名、三級域名還是各種亂七八糟的域名，自己分析；再然后，了解每個域名背后的服務是如何運作的，這里邊會涉及到前端頁面、一些資源文件的固定協議引用，后端代碼中關于協議獲取是寫死的還是動態的，數據庫中存儲的網址鏈接等等，這些統統要考慮到。
分析完系統后，其中肯定會存在混合協議訪問請求，HTTPS 下瀏覽器會攔截掉所有 HTTP 請求的，不同頁面間跳轉、不同服務域名間跳轉如果是以固定的 HTTP 協議寫死的，要支持全站 HTTPS 協議，首要解決的是以當前協議來靈活的區分不同域名服務間的跳轉。其次，HTTPS 協議首次請求存在多次握手，因此網絡耗時變長問題，可能會影響系統訪問速度。所以，我是建議計劃分為兩個階段來進行全站 HTTPS 升級：
- 一階段：將目前所有域名配置為支持 HTTP 和 HTTPS 兩種協議，不做 HTTP 請求強制 HTTPS 跳轉。在驗證及測試完成 HTTPS 下，系統所有服務以及訪問速度均無問題后，進行實施二階段計劃。
- 二階段：在上階段不強制 HTTPS 訪問驗證通過后，域名做強制 HTTPS 協議。即當用戶以 HTTP 協議訪問系統時， 如用 Nginx 做強制 301 跳轉到 HTTPS 協議，做到全站 HTTPS 安全訪問協議。
不出意外，按照這兩步計劃，應該可以穩妥是進行全站 HTTPS 升級工作，當然，期間不可避免的會踩一些坑，因為每個公司業務不同、系統環境不同等原因，都會遇到不可預估的問題，一個個解決就行了。我下面會寫一下升級期間共性的、也就是每個人都必須要踩的坑和如何解決這些問題。
十條注意事項
1.瀏覽器攔截混合訪問請求由于瀏覽器安全規則，在 HTTPS 請求下通過 JAVAScript 請求 HTTP 請求或引入 HTTP 協議資源文件，會報“Mixed Content”錯誤，導致請求無法繼續。
Mixed Content: The page at 'https://domain.com/' was loaded over HTTPS, but requested an insecure script 'http://domain.com/'. This request has been blocked; the content must be served over HTTPS.
2.前端 html、JS 資源引用存在 HTTP前端頁面及 js 文件中，寫死的 http:// 協議資源及跳轉改為根據當前協議切換(//)。使用相對協議，如：
<script src="//domain.com/jquery.js</script>
<img src="//domain.com/img/logo.png">
或者代碼自行判斷都可以。如果一個頁面內包含多個域名請求，需所有域名均支持https，否則部分瀏覽器會有警告提醒或打不開。
3.移動端適配 HTTPS如果你們存在移動客戶端（APP）也需要適配 HTTPS，所以必須做調用接口的相應修改，當然，要注意運營商 DNS 劫持（尤其是移動）也會對 HTTPS 請求成功率造成很大影響，其實可以做好 HTTP/HTTPS 兩種協議都支持，做好出問題隨時動態降級切換準備。
4.項目中存在的配置問題項目中用到的配置文件中存在 HTTP 鏈接，要充分了解其用途。如果不是可以統一動態更新的配置文件，都要考慮更改后做服務的發布，這時候要來考慮對生成環境業務的影響以及測試、開發環境的影響等問題。如頁面間跳轉、權限、登錄驗證、第三方服務（支付、推送）回調這些配置等。
5.關于 request.getScheme() 這個坑如果你的架構上使用了 Nginx + Tomcat 集群, 且 Nginx 下配置了 SSL ，Tomcat 沒有配置 SSL ，這時候其實客戶端已經是使用 HTTPS 協議了，但你的 Tomcat 中用 request.getScheme()、request.getRequestURL() 會獲取到的是 HTTP，并不是 HTTPS 。當然可以代碼中避免，或者通過配置 Nginx 和 Tomcat 解決，看這篇文章：http://www.cnblogs.com/interdrp/p/4881785.html
6. SSL 證書類型在之前說選購 SSL 證書的時候，你就要充分考慮業務上域名需要的證書類型，避免需要泛域名證書而你買了單域名證書，當然泛域名證書還是分為支持級別的，如購買 *.example.com 證書，那么該證書支持 a.example.com, a1.example.com, a2.example.com 以此類推域名，但是不支持 b.a.example.com（另一級）, b1.a.example.com 類域名，如需支持，需另外再購買一張 *.a.example.com 證書。
7.Nginx 配置同一個 server 段不支持配置多個證書8.Nginx 配置 HTTP 強制跳轉 HTTPS通過配置 Nginx 域名 HTTP 請求 302 跳轉實現全站 HTTPS。千萬不能有 POST 請求，這時候瀏覽器會先做 302 跳轉，在以 Get 方法請求會導致 Post Body 丟失。具體配置如下：
server {
listen 80;
listen 443 ssl;
server_name www.domain.com;
ssl on;
ssl_certificate 1_www.domain.com_bundle.crt;
ssl_certificate_key 2_www.domain.com.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
ssl_prefer_server_ciphers on;
if ($scheme != 'https') {
rewrite ^(.*)$ https://$server_name$1 permanent;
}
location / {
root html;
index index.html index.htm;
}
}
9.所有環境均要進行升級不僅僅要考慮生成環境進行全站 HTTPS 升級問題，包括開發、測試、預發布等多種不同環境均要進行升級，來保持與生產環境的一致性，減小不可預估因素的發生。如果你沒有完善的運維系統，一個個配置文件改的可是真的很痛苦，你試試想想看上百個配置，淚...
10.打死你都想不到的地方太多了，自由發揮吧。做到兵來將擋水來土掩，佛來斬佛，魔來斬魔就行了。
注意事項寫完了，現在插播一條硬廣，我們團隊目前正需要對技術有追求的小伙伴一起來共同學習進步，看到這篇文章有想換個工作環境的，當然你要基本了解使用過分布式架構，快快聯系我。
總結一下
不知道這一篇算不算所謂的「干貨」了，現在好多人都喊著要所謂的干貨，其實哪有那么多干貨阿。這一篇主要寫了一下在全站升級 HTTPS 的過程與注意點，幾乎都是在實際工作中步驟的重現了，當然，升級完成我們還是需要對整個系統進行性能、速度的測試，以及如何更好的利用 HTTPS ，比如上 HTTP 2.0 ，據說提升很大的。
