如果有一項技術可以讓網站的訪問速度更快、更安全、並且seo權重提升（百度除外），而且程序員不需要改代碼就可以全站使用，最重要的是，不需要額外花錢，那有這麼好的事情嗎？
HTTP通信協議是全球萬維網www的基礎，是瀏覽器和網站服務器之間的通信協議，而https是http從1999年發佈以來，十六年來的最重要的一次版本升級，這次升級的主要目的就是爲了改善瀏覽器的網頁下載速度（Page Load Time）。
耳聽爲虛眼見爲實，以下是測試網站網址：www.proginn.com/robots.txt（默認訪問不帶https），比較http和https的速度差異，下圖來自站長工具的檢測：
說起https的歷史，就必須要提到SPDY通信協議，隨着谷歌的Chrome瀏覽器佔領了龐大的市場，並且在2009-2016年驚醒的大規模網絡實驗獲得了顯著的成功，進一步規範了SPDY標準，終於在2015年5月正是發佈。目前Chrome、Safari、Firefox、IE等瀏覽器都已經支持，一些一線大廠網站如Yahoo、Facebook、Google都已經支持https，不知不覺https彷彿就在我們身邊。當https正在全面普及的時候，身爲一個網站管理員可千萬不能別淘汰了。
HTTPS有哪些變動？
https在各種語言基礎之下都可以完全兼容，它改進的是底層通信封裝操作。Web開發者熟悉的http操作如Get/Post操作、HTTP Status Code和各種HTTP Header都沒有改變，完全與http兼容。因此服務器端要使用https，完全不需要修改HTML/CSS/JavaScript網頁以及後端程序，只要升級和設定Web服務器軟件，加上支持HTTPS的瀏覽器，就可以使用這個超快的通信協定。
想要知道HTTPS到底有哪些重要的改變，我們先來回顧一下當下網頁價值速度的挑戰是什麼？隨着網頁內容越來越複雜，造成了要完成一個網頁加載（Page Load）的動作，除了要下載HTML之外，還需要下載CSS檔案、JavaScript檔案、各種圖片檔案，零零總總加起來需要已經多達上百個對伺服器的Request請求資源，大大影響了網頁加載的速度。
據統計，在這一秒鐘幾十萬上下的時代，Amazon的網頁加載時間每多一秒，該公司的年度營收就減少16億美元、Google的搜尋時間每多0.4秒，每天的搜尋次數就會減少8百萬網頁、KISSmetric分析報告指出等待時間超過4秒，Bounce Rate就會增加25%。人的思緒在等1秒後就開始飄移，如果需要等10秒，就會感覺這東西是不是壞了。
這個問題的最大原因在於，HTTP有一個非常大的缺陷是每個對服務器的Request資源請求，都必須佔用一個網路連線（TCP connection），傳完一個檔案才能再傳下一個，瀏覽器無法同時下載。因此在HTTP時代，瀏覽器爲了加速下載的時間，只好同時允許六個網路連線（TCP connection）併發去連接服務器，好可以達成同時下載六個資源。但是極限也是如此了，並不是說無限制增加網路連線就可以解決這個瓶頸，因爲每一次的網路連線，都必須經過三次握手的初始網路連線程序，而且每次初始鏈接因爲流量控制的關係，一開始的網絡封包會傳輸比較慢，後來才逐漸加快。
也因爲HTTP的這個限制，當今Web開發者針對網站性能優化時，發展出了各種奇技怪招來加快網頁下載速度，稍候我們會提到這些在新的HTTPS技術下，完全是多餘的。
那麼，HTTPS是如何改良的呢？它採用的方法包括：
1，只需要單一網路連線（Single TCP connection），就可以連接網站服務器，下載所有需要的資源。大大節省HTTP需要一直建立多個網路連線時的啓動時間浪費。
2，鏈接多工（Multiplexing），在單一網路連線上，就可以同時傳輸多個HTTP Request和Response，併發請求CSS/JS/Images等等資源。它的原理是將Requests/Responses都拆碎成小frames進行傳輸，而這些frames是可以交錯的，因此檔案再多也不怕，不會發生佔用網絡連線（TCP connection）的情況。這就是爲什麼在圖片很多的情況下，HTTPS特別有優勢。
3，優先權設計（Prioritization），服務器可以決定例如CSS或JavaScript檔案，哪些要優先傳送。
4，Header壓縮，在HTTP的Headers其實是沒有壓縮的，大小佔了約200 bytes到2KB不等，而且同一瀏覽器的每個Requests其實絕大部份的Headers都是重複的。HTTPS用了HPACK壓縮技術，大大減少每次都要重複傳輸一樣的Headers。
5，Binary二進位的封包結構設計，對服務器和瀏覽器來說，可以更快的解析這些數據。PS：在HTTP定義了四種解析信息的方式，在HTTPS只需要一種。
6，服務器主動推送資源（Server Push），允許服務器除了HTML之外，連同需要的CSS/JavaScript/Images檔案，主動推到瀏覽器的緩存之中。不過，這個功能比較有爭議，一來他需要Web開發者額外描述有哪些檔案需要隨着HTML一起推送給瀏覽器，不是Web服務器升級HTTPS就自動會有。二來它不管瀏覽器是不是已經有緩存這個資源，都會推送而造成頻寬浪費。因此綜上所述個人認爲可以改用瀏覽器的Prefetch功能，讓客戶端的瀏覽器自己處理即可。
透過這些技術，讓瀏覽器的網頁下載時間大大降低。而我們網站主需要做的，就是升級Web服務器到支持HTTPS。
對網站開發者會有什麼影響嗎？
剛纔提到Web開發者在HTTP限制下，爲了改善網頁下載速度發展出了各種招數，其中因爲HTTP一個Requests請求，就會佔用一個網絡連線，所以有很多方法都是想減少Requests的數量，讓我們來看看有哪些：
1，合併圖片（Image Sprites），爲了減少瀏覽器發送Requests的數量，就把很多小圖（例如Icon）合併成一張大圖下載，然後透過CSS樣式去切出其中一個小圖。這一招用起來其實很麻煩，因爲每次新增小圖或修改，整張大圖都要重新產生過。
2，合併CSS和JavaScript檔案，也是爲了減少瀏覽器發送Requests的數量。但是開發的時候一定會拆成不同檔案才比較好維護，而最後佈署到服務器時，需要額外去進行把檔案合併的動作。
3，內插CSS、JavaScript或圖片，也是爲了減少瀏覽器發送Requests的數量，就把原本應該獨立的檔案，直接內插到HTML裏面。圖片會用Base64編碼成純文字後置入。但這招會破壞瀏覽器緩存機制，本來是可以單獨緩存這些靜態資源的，內插後反而沒有緩存了，而且圖片實際大小會變大浪費頻寬。
4，Domain切分（Domain Sharding），瀏覽器針對同一個網址只能開六個網路連線，爲了突破這個限制，網站者可能會拆多個子網域，用不同網址來下載圖片。另外也因爲拆分不同Domain的關係，可以讓瀏覽器的Cookie不會送到這些次要網域，減少一點頻寬浪費。
以上這些技巧，都會讓網站開發和佈署增加不少額外的麻煩，而在HTTPS通信協定下，都已經變得不需要了。
你的網站需要HTTPS
爲了能夠順利讓瀏覽器能兼容現存的HTTP網站（使用通信端口Port 80），所以HTTPS選擇佈署在HTTPS（使用通信端口Port 443）上，因此在安裝HTTPS的步驟中，要先擁有TLS/SSL安全性憑證。另一方面，這也是全面推廣網站安全的契機，除了有更快速度，同時也要求了更好的網絡安全。
使用HTTPS的好處有：
保護瀏覽器和服務器之間的傳輸，不會被別人修改。這不一定指惡意的黑客攻擊，也可能只是想插入廣告。例如有些咖啡店的免費Wifi會在網頁上面插入廣告。但是如果是HTTPS網站就沒辦法了。
保護了使用者的隱私安全，不會被人知道。特別是需要登入的網站，沒有HTTPS加密，非常容易就可以被人竊取帳號密碼。
Google把HTTPS的網站當作SEO加分
很多新的瀏覽器功能也開始把HTTPS當作必要條件，例如Geolocation定位、ServiceWorker等等功能
Apple宣佈2016年底，所有iOS app的網路連線都必須用加密鏈接HTTPS，不可以用HTTP了。
綜合以上，HTTPS加密可說是當今應用程序網站必備的基本安全需求。
如何安裝HTTPS？
第一步：取得TLS/SSL安全性憑證
首先要取得TLS/SSL安全性憑證檔案。這個憑證是不能自己簽發的，這樣瀏覽器會有警告畫面：
之前TLS/SSL安全性憑證一定是向憑證機構購買，這樣瀏覽器纔會認得你是合法的憑證（這些瀏覽器在出廠時就已經設定好要相信哪些憑證機構），例如www.proginn.com是在letsencrypt免費獲得證書。爲了推廣HTTPS，去年由許多大公司以及各大非營利團體共同贊助推出Let’s Encrypt這個服務，免費發佈TLS/SSL憑證。詳細使用說明可以參考https://letsencrypt.org/，或是用certbot這個工具。不過因爲它的使用方式，跟一般我們在憑證機構網站上購買的步驟不太一樣，需要在主機上下指令來取得憑證，所以也有人設計了一個在線工具SSL For Free可以在線上就完成憑證申請。
第二步：設定Web服務器
接着設定Web服務器。Apache可以使用mod_https，而Nginx在1.10 stable後就內置支持了。設定SSL的設定檔可以參考Mozilla SSL Configuration Generator的建議，其中除了設定你憑證的檔案位置之外，還可以讓服務器打開HSTS這個HTTP Header，告訴瀏覽器這個網站只用HTTPS加密鏈接，不要用HTTP，這樣使用者就不會不小心用到HTTP不安全的鏈接了。但是要注意一旦啓用，期限內就沒有辦法讓使用者改回用HTTP，建議可以在最後全站檢查沒問題後再啓用。另外還有一點要注意，就是服務器上的OpenSSL函式庫需要升級到1.0.2g，你可以在編譯Nginx時特別搭配這個版本，或是乾脆使用較新的Ubuntu Linux 16.04服務器操作系統。
如果上述的兩個步驟還是太麻煩，或是你沒有管理服務器的經驗，推薦可以使用CloudFlare這個網站加速服務（CDN），它有免費方案提供TLS/SSL憑證以及HTTPS鏈接。也就是說你的網站服務器可以什麼都不用改，只需要修改DNS讓使用者的鏈接會先經過CloudFlare服務器即可。使用者到CloudFlare的這一段傳輸，就會是有加密的HTTPS鏈接。CloudFlare在全球各地都有節點，所以網絡速度非常好。
第三步：替換HTTP網址爲HTTPS
我們需要將所有HTTP網址都換成HTTPS網址。網頁上所有連到自己網站的超鏈接、圖片、JavaScript和CSS等等網址，都必須修改成https://開頭。而所有外部系統中你的網址，例如Facebook廣告、Google Analytics和其他網站分析追蹤工具，都必須把網址改成https://開頭。
第四步：最後檢查
先檢查TLS/SSL安全性憑證安裝正確，可以使用SSL Server Test這個在線工具。接着檢查HTTPS有啓用，使用Chrome瀏覽器在網址輸入chrome://net-internals/#https觀察有哪些網站在使用HTTPS，或是你可以安裝HTTPS and SPDY Indicator。在線測試工具則可以用HTTPS Test。更多工具可以參考Tools for debugging，testing and using HTTPS。
第五步：全面啓用
檢查沒有問題後，我們可以設定Web服務器只允許HTTPS鏈接，所有鏈接到HTTP的情求，全部轉址（301 Redirect）到HTTPS鏈接，並且打開HSTS這個HTTP Header強制使用者瀏覽器只能用HTTPS鏈接。
最後的成果就是會有一個綠色的Icon出現在地址欄：
導入的困難點是？
看起來好像很簡單，就是設定就可以了，有沒有什麼困難點呢？個人認爲處理TLS/SSL安全性憑證只是小麻煩而已，更何況如果用CloudFlare連申請憑證的步驟都不需要。真正麻煩的地方，恐怕還是從HTTP改成HTTPS的這個過程會比較辛苦。如果你本來就不是全站支持HTTPS通信協議，一旦從HTTP換成HTTPS，就很容易碰到Mixed content混合內容的瀏覽器警告，意思是說你在加密的HTTPS的網頁之中，使用到非加密的HTTP的資源，這個資源可能是JavaScript、CSS、圖片或是iframe（不包括超鏈接）。
如果只是圖片和視頻用到非加密的HTTP網址，那麼瀏覽器的綠色安全鑰匙Icon就會不見：
但如果是CSS或JavaScript的話，那瀏覽器就根本不加載了，你的網頁就會破版無法正常運作。
因此，爲了不要讓瀏覽器出現這個警告，讓所有平臺下的瀏覽器下都可以正常運作，你得將HTTPS網頁中的所有資源，都一一檢查將HTTP替換成HTTPS。如果當初是用相對網址就沒事，但是如果有用到絕對網址http://開頭的，例如直接連接使用其他網站的資源，那改起來可能就會很麻煩費事，而且容易百密一疏。另外，也要提醒一下相關編輯的同行，不然一不小心綠色安全鑰匙Icon又不見了。
如果是很多年的老站，這樣升級可能是真的改不完，一個過度的方案是使用upgrade-insecure-requests幫忙，透過在Web服務器上設定這個HTTP header，瀏覽器就會自動將網頁上的HTTP資源自動替換成HTTPS網址、站內的超鏈接也會自動替換成HTTPS。
以上一些HTTPS通信協議的簡單介紹，希望有越來越多的網站都開始使用HTTPS，讓我們的網絡環境更快更安全。