SEO方式之HTTPS 訪問優化詳解

SEO到底要不要作HTTPS？HTTPS對SEO的重要性

正方觀點

一、HTTPS具備更好的加密性能，避免用戶信息泄露；

二、HTTPS複雜的傳輸方式，下降網站被劫持的風險；

三、搜索引擎已經全面支持HTTPS抓取、收錄，而且會優先展現HTTPS結果；

四、從安全角度來講我的以爲要作HTTPS，不過HTTPS能夠採用登陸後展現；

五、HTTPS綠鎖表示能夠提高用戶對網站信任程度；

六、基礎成本可控，證書及服務器已經有了成型的支持方案；

七、網站加載速度能夠經過cdn等方式進行彌補，可是安全不能忽略；

八、HTTPS是網絡的發展趨勢，遲早都要作；

九、能夠有效防止山寨、鏡像網站；

 

反方觀點

一、HTTPS會下降用戶訪問速度，增長網站服務器的計算資源消耗；

二、目前搜索引擎只是收錄了小部分HTTPS內容；

三、HTTPS須要申請加密協議，增長了運營成本；

四、百度目前對HTTPS的優先展示效果不明顯，谷歌較爲明顯；

五、技術門檻較高，無從下手；

六、目前站點不涉及私密信息，無需HTTPS；

七、兼容性有待提高，如robots不支持/聯盟廣告不支持等；

八、HTTPS網站的安全程度有限，該被黑仍是被黑；

九、HTTPS維護比較麻煩，在搜索引擎支持HTTP的狀況，不必作HTTPS；

HTTPS的優勢：

安全性方面

在目前的技術背景下，HTTPS是現行架構下最安全的解決方案，主要有如下幾個好處：

一、使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；

二、HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。

三、HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

HTTPS的缺點：

技術方面

一、相同網絡環境下，HTTPS協議會使頁面的加載時間延長近50%，增長10%到20%的耗電。此外，HTTPS協議還會影響緩存，增長數據開銷和功耗。

二、HTTPS協議的安全是有範圍的，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。

三、最關鍵的，SSL 證書的信用鏈體系並不安全。特別是在某些國家能夠控制 CA 根證書的狀況下，中間人攻擊同樣可行。

 

成本方面

一、SSL的專業證書須要購買，功能越強大的證書費用越高。我的網站、小網站能夠選擇入門級免費證書。

二、SSL 證書一般須要綁定 固定IP，爲服務器增長固定IP會增長必定費用；

三、HTTPS 鏈接服務器端資源佔用高較高多，相同負載下會增長帶寬和服務器投入成本；

問：SEO到底要不要作HTTPS？

答：必須作HTTPS

既然HTTPS有這麼多缺點，那是否是就不應作呢，固然不是的，隨着技術的發展不少缺點是能夠優化和彌補的。好比：打開速度問題徹底能夠經過CDN加速解決，不少IDC也在着手推出免費證書和一站式HTTPS搭建服務，HTTPS成本在將來將會大大縮小！

經過上面大多數人的觀點，我相信你也有一個你本身的答案，博主的答案是必定要作HTTPS,有人說，HTTPS是收費的，博主的網站HTTPS就是免費的，不是照樣能夠用嗎？

關於HTTPS搜索引擎收錄的問題，博主也認可百度目前蜘蛛抓取HTTPS是有一些困難，可是這個缺點咱們能夠直接去百度站長平臺，直接告訴百度個人網站支持https協議：（個人網站-站點管理-站點屬性：
站點協議Beta:若站點支持https協議，請點擊設置，若不支持可忽略此項）；以下圖：

 

雖說：百度公告說的是：已經支持HTTPS抓取，推送也支持HTTPS了，可是畢竟支持HTTPS程序出來較晚，確定它還有不成熟的地方，不夠完善的地方，這些都須要去人爲的彌補的；目前最佳的方法是:咱們能夠站長平臺工具設置網站HTTPS協議，並且百度搜索引擎算法是優先展現HTTPS網頁的，像好搜，搜狗，神馬這些搜索引擎，目前技術還不成熟，所以，必須保證咱們的網站HTTP也能訪問。例如：博主的網站：任何一個頁面，HTTP和HTTPS均可以訪問，並且不存在任何的跳轉，也未作重定向，可是權重依然不分散；依然是以HTTPS爲主。

概念詳解:

HTTPS 協議就是 HTTP+SSL/TLS，即在 HTTP 基礎上加入 SSL /TLS 層，提供了內容加密、身份認證和數據完整性3大功能，目的就是爲了加密數據，用於安全的數據傳輸。

HTTPS 經過3大功能增長了數據傳輸安全，但同時也給Web性能優化帶來了新的挑戰。

• HTTPS下降用戶訪問速度（需屢次握手）
• 網站改用 HTTPS 之後，由 HTTP 跳轉到 HTTPS 的方式增長了用戶訪問耗時（多數網站採用 30一、302 跳轉）
• HTTPS 涉及到的安全算法會消耗 CPU 資源，須要增長服務器資源（https 訪問過程須要加解密）

HTTP跳轉至HTTPS交互過程解析

 

1. 用戶在瀏覽器裏輸入 http://www.domain.com/1213.gif 點擊回車之後，瀏覽器與服務器發生三次握手；

2. 服務器收到用戶的請求，響應 301 狀態碼，讓用戶跳轉到 HTTPS ，從新請求 https://www.domain.com/1213.gif；

3. 用戶從新發起 HTTPS 請求，再次與服務器進行三次 TCP 握手；

4. TCP 握手成功後，瀏覽器開始與服務器進行 TLS 握手。HSTS重定向技術

又拍雲採用了 HSTS（HTTP Strict Transport Security）技術，啓用HSTS後，將保證瀏覽器始終鏈接到網站的 HTTPS 加密版本。

1. 用戶在瀏覽器裏輸入 HTTP 協議進行訪問時，瀏覽器會自動將 HTTP 轉換爲 HTTPS 進行訪問，確保用戶訪問安全；

2. 省去301跳轉的出現，縮短訪問時間；

3. 能阻止基於 SSL Strip 的中間人攻擊，萬一證書有錯誤，則顯示錯誤，用戶不能迴避警告，從而可以更加有效安全的保障用戶的訪問。

TLS握手優化

在傳輸應用數據以前，客戶端必須與服務端協商密鑰、加密算法等信息，服務端還要把本身的證書發給客戶端代表其身份，這些環節構成 TLS 握手過程。

TLS False Start 功能

又拍雲採用了 False Start （搶先開始）技術，瀏覽器在與服務器完成 TLS 握手前，就開始發送請求數據，服務器在收到這些數據後，完成 TLS 握手的同時，開始發送響應數據。

 

開啓 False Start 功能後，數據傳輸時間講進一步縮短。

Session Identifier（會話標識符）複用

若是用戶的一個業務請求包含了多條的加密流，客戶端與服務器將會反覆握手，一定會致使更多的時間損耗。或者某些特殊狀況致使了對話忽然中斷，雙方就須要從新握手，增長了用戶訪問時間。

所以又拍雲提供了 Session Identifier（會話標識符）複用功能

（1）服務器爲每一次的會話都生成並記錄一個 ID 號，而後發送給客戶端；

（2）若是客戶端發起從新鏈接，則只要向服務器發送該 ID 號；

（3）服務器收到客戶端發來的 ID 號，而後查找本身的會話記錄，匹配 ID 以後，雙方就能夠從新使用以前的對稱加密祕鑰進行數據加密傳輸，而沒必要從新生成，減小交互時間。

所以又能夠進一步下降客戶端的訪問時間，提高用戶的訪問體驗。又拍雲已默認開啓此功能，無需特殊配置，抓包以下圖所示：

 

開啓OSCP Stapling，提升TLS握手效率

採用OCSP Stapling ，提高 HTTPS 性能。服務端主動獲取 OCSP 查詢結果並隨着證書一塊兒發送給客戶端，從而客戶端可直接經過 Web Server 驗證證書，提升 TLS 握手效率。

由又拍雲服務器模擬瀏覽器向 CA 發起請求，並將帶有 CA 機構簽名的 OCSP 響應保存到本地，而後在與客戶端握手階段，將 OCSP 響應下發給瀏覽器，省去瀏覽器的在線驗證過程。因爲瀏覽器不須要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提高很是明顯。

徹底前向加密PFS，保護用戶數據，預防私鑰泄漏

非對稱加密算法 RSA，包含了公鑰、私鑰，其中私鑰是保密不對外公開的，因爲此算法既能夠用於加密也能夠用於簽名，因此用途甚廣，可是仍是會遇到一些問題：

（1） 假如我是一名黑客，雖然如今我不知道私鑰，可是我能夠先把客戶端與服務器以前的傳輸數據（已加密）所有保存下來

（2）若是某一天，服務器維護人員不當心把私鑰泄露了，或者服務器被我攻破獲取到了私鑰

（3）那我就能夠利用這個私鑰，破解掉以前已被我保存的數據，從中獲取有用的信息

因此爲了防止上述現象發生，咱們必須保護好本身的私鑰。

但若是私鑰確實被泄漏了，那咱們改如何補救呢？那就須要PFS（perfect forward secrecy）徹底前向保密功能，此功能用於客戶端與服務器交換對稱密鑰，起到前向保密的做用，也即就算私鑰被泄漏，黑客也沒法破解先前已加密的數據。

實現此功能須要服務器支持如下算法和簽名組合：

（1）ECDHE 密鑰交換、RSA 簽名；

（2）ECDHE 密鑰交換、ECDSA 簽名；

又拍雲已默認支持上述組合，無需特殊配置，抓包以下圖所示：

 

HTTP/2協議支持

HTTP/2 是在 HTTPS 協議的基礎上實現的，因此只要使用又拍雲 HTTPS 加速服務的域名，均可免費享受 HTTP/2 服務，無需作任何特殊配置。全平臺支持默認開啓 HTTP/2.0 , 無縫兼容各瀏覽器及服務器。

原文博客的連接地址：https://cnblogs.com/qzf/