為什麼要使用 HTTPS？

HTTP 和 HTTPS 有什麼區別？

HTTPS 是使用 TLS 加密的 HTTP。HTTPS 使用 TLS (SSL) 對正常的 HTTP 請求和回應進行加密，使其更加安全可靠。使用 HTTPS 的網站在其 URL 的開頭使用 https:// 而不是 http://，例如 https://www.cloudflare.com。

那麼，為什麼網站應該使用 HTTPS？

原因 1：使用 HTTPS 的網站對使用者來說更加值得信賴。

網站使用 HTTPS 就如餐館展示「通過」本地食品安全檢查的標識一般：潛在的顧客可以放心，他們光顧這家店不會遭受巨大的負面影響。現如今，使用 HTTP 本質上就像展示自己「未通過」食品安全檢查一樣：無法保證顧客不會有可怕的遭遇。

HTTPS 使用 SSL/TLS 通訊協定對通訊進行加密，使攻擊者無法竊取資料。SSL/TLS 還可確認網站伺服器是其所聲稱的身分，從而防止假冒。這可以阻止多種網路攻擊（就像食品安全可以預防疾病一樣）。

儘管有些使用者可能不知道 SSL/TLS 的好處，但現代瀏覽器確保他們無論如何都知道網站的可信度。

Chrome 和其他瀏覽器將所有 HTTP 網站標記為「不安全」。

多年來，Google 逐步採取措施使網站逐漸整合 HTTPS。Google 還在傳回搜尋結果時將 HTTPS 用作一個品質因素；網站越安全，訪客因點擊 Google 提供的連結而犯錯的可能性就越小。

從 2018 年 7 月發佈的 Chrome 68 開始，所有不安全的 HTTP 流量在 URL 欄中都會標記為「不安全」。對於沒有有效 SSL 憑證的網站，也都會顯示此通知。其他瀏覽器也紛紛效仿。

原因 2：HTTPS 對於使用者和網站擁有者來說都更安全。

使用 HTTPS 時，資料在傳輸的兩個方向上都會得到加密，不論是傳到來源伺服器還是從中傳出。通訊協定確保通訊安全，使惡意方無法觀察到正在傳送的資料。因此，使用者在表單中輸入的使用者名稱和密碼不會在傳輸過程中被盜取。如果網站或 Web 應用程式必須向使用者傳送敏感性資料或個人資料（例如，銀行帳號資訊），加密也可以保護這些資料。

原因 3：HTTPS 對網站進行驗證。

Uber 和 Lyft 等拼車應用程式的使用者不會僅僅是因為司機說可以來接他們，就毫不懷疑地坐進陌生的汽車。相反，應用程式會告訴他們司機的相關資訊，如姓名和外貌、駕駛的車型和車牌號等。使用者可以檢查這些資訊，並確定他們將會進入正確的汽車，儘管每輛共乘用車都各不相同，而且他們從未見過司機。

同樣，當使用者導覽到網站時，他們實際上在做的事情就是連接他們不認識的、由未見過的人維護的遠端電腦。啟用 HTTPS 的 SSL 憑證就與拼車應用程式中的司機資訊類似。它代表由可信賴的第三方進行了外部驗證，證明 Web 伺服器是其聲稱的身分。

這可以防止這樣的攻擊：攻擊者冒充或模仿網站，使用者以為自己在想要存取的網站上，而實際上他們在一個虛假網站上。HTTPS 驗證還可以幫助公司網站看起來合法，這會影響使用者對公司本身的態度。

HTTPS 謬論

許多網站採用 HTTPS 的速度都很慢。若要探究其原因，我們必須回顧一下歷史。

當 HTTPS 最初開始推廣時，正確實作不僅困難、緩慢，而且十分昂貴；由於需要昂貴的憑證服務，因此難以正確實作，而且會減慢網際網路請求並增加成本。這些障礙如今都已不復存在，但對於許多網站擁有者而言，仍有揮之不去的擔憂，這阻礙了一些人跨步邁向更好的安全性。我們來探索一些 HTTPS 的謬論。

「我的網站上不處理敏感性資訊，所以不需要 HTTPS」

網站不實作安全性的一個常見原因是，他們認為這樣做是大材小用。畢竟，如果不涉及敏感性資料，有誰會在乎有沒有人窺探？出於某些原因，這是將 Web 安全性過於簡單化的看法。例如，某些網際網路服務提供者實際上會將廣告插入到由 HTTP 服務的網站中。這些廣告或許與網站內容相稱，也可能並不適配，除了網站提供者無法獲得創造性投入或收益分成外，還可能令人反感。一旦網站設有安全保護，這些插入的廣告將不再可行。

如今，現代 Web 瀏覽器限制了不安全網站的功能。提高網站品質的重要功能需要 HTTPS。地理位置、推播通知以及執行漸進式 Web 應用程式 (PWA) 所需的 Service Workers 都需要更高的安全性。這很有道理；使用者位置等資料屬於敏感性資料，可被用於惡意目的。

「我不想增加頁面載入時間，讓網站的效能受損」

效能是使用者體驗以及 Google 如何傳回搜尋結果的重要因素。可以理解，增加延遲值得認真考慮。幸運的是，隨著時間推移，HTTPS 已有改進，降低了建立加密連線所需的效能開銷。

發生 HTTP 連線時，請求網頁的用戶端與伺服器建立連線需要進行多次往返。除了與 TCP 交握相關聯的普通延遲（下方以藍色顯示）之外，還必須進行其他 TLS/SSL 交握（以黃色顯示）以便使用 HTTPS。

TLS 中已實施改進以減少建立連線的總延遲，包括 TLS 工作階段繼續執行和 TLS 錯誤啟動。

使用工作階段繼續執行，伺服器可以透過為其他請求繼續執行同一工作階段來使連線保持更長的生存期。當用戶端需要未快取的原點擷取時，使連線保持運作可節省重新交涉連線所花費的時間，從而將總 RTT 縮短 50％。

加密通道建立速度上的另一改進是實施一個稱為 TLS 錯誤啟動的過程，透過在用戶端完成驗證之前傳送加密資料來縮短等待時間。如需更多資訊，您可以探索 TLS/SSL 在 CDN 上如何運作。

最後，TLS 1.3 提供了更顯著的效能改進。TLS 1.3 中的 TLS 交握只需要一次往返——如果用戶端之前已經連接，則往返次數為零。註冊 Cloudflare 可以輕鬆地為 Web 內容啟用激活 TLS 1.3。

「實施 HTTPS 對我而言代價太高」

這一度是真的，但現在成本不再是問題；Cloudflare 讓網站能夠免費獲得加密傳輸。我們是第一家免費提供 SSL 的公司，並且也會繼續下去。透過提高整個網際網路的安全性，我們能夠協助使網際網路變得更加安全、更加快速。

「將網站遷移到 HTTPS 後，我會失去搜尋排名」

網站遷移有相關的風險，而且實施不當可能會對 SEO 造成負面影響。潛在的隱患包括網站停機、網頁未編目，以及因為同時存在兩個網站複本而受到內容重複懲罰。即便如此，按照最佳做法操作可以將網站安全地遷移到 HTTPS。

兩個最重要的遷移做法是：

1) 使用 301 重新導向；2) 正確放置權威性標籤。透過在 HTTP 網站上使用伺服器 301 重新導向來指向 HTTPS 版本，網站可以告訴 Google 轉到新位置來達成所有搜尋和索引目的。透過僅在 HTTPS 網站上放置權威性標籤，Googlebot 等網路爬蟲將知道新的安全內容此後應被視為權威性內容。

如果您的網頁數量很多，並且擔心重新編目的時間太長，請與 Google 聯絡，並告訴他們您願意讓自己的網站經受多少流量。然後，網路工程師可提高編目速度，從而協助快速解析您的網站並將其編入索引。