seo優(yōu)化排名方法、東莞seo優(yōu)化、企業(yè)網(wǎng)站

大型網(wǎng)站的 HTTPS 實(shí)踐：基于協(xié)議和配置的優(yōu)化

　百度在2015年即完成HTTPS改造，那大型網(wǎng)站的HTTPS改造中都有哪些實(shí)踐經(jīng)驗，學(xué)院君特分析這篇干貨滿滿系列內(nèi)容，轉(zhuǎn)自百度運(yùn)維博客。

　　1 前言

　　上文講到 HTTPS 對用戶訪問速度的影響。

　　本文就為大家介紹 HTTPS 在訪問速度，計算性能，安全等方面基于協(xié)議和配置的優(yōu)化。

　　2 HTTPS 訪問速度優(yōu)化

　　2.1 Tcp fast open

　　HTTPS 和 HTTP 使用 TCP 協(xié)議進(jìn)行傳輸，也就意味著必須通過三次握手建立 TCP 連接，但一個 RTT 的時間內(nèi)只傳輸一個 syn 包是不是太浪費(fèi)？能不能在 syn 包發(fā)出的同時捎上應(yīng)用層的數(shù)據(jù)？其實(shí)是可以的，這也是 tcp fast open 的思路，東莞seo優(yōu)化，簡稱 TFO。具體原理可以參考 rfc7413。

　　遺憾的是 TFO 需要高版本內(nèi)核的支持，linux 從 3.7 以后支持 TFO，但是目前的 windows 系統(tǒng)還不支持 TFO，所以只能在公司內(nèi)部服務(wù)器之間發(fā)揮作用。

　　2.2 HSTS

　　前面提到過將用戶 HTTP 請求 302 跳轉(zhuǎn)到 HTTPS，這會有兩個影響：

　　1，seo優(yōu)化， 不安全，302 跳轉(zhuǎn)不僅暴露了用戶的訪問站點(diǎn)，也很容易被中間者支持。

　　2， 降低訪問速度，302 跳轉(zhuǎn)不僅需要一個 RTT，瀏覽器執(zhí)行跳轉(zhuǎn)也需要執(zhí)行時間。

　　由于 302 跳轉(zhuǎn)事實(shí)上是由瀏覽器觸發(fā)的，服務(wù)器無法完全控制，這個需求導(dǎo)致了 HSTS 的誕生：

　　Chrome， firefox， ie 都支持了 HSTS。

　　2.3 Session resume

　　Session resume 顧名思義就是復(fù)用 session，實(shí)現(xiàn)簡化握手。復(fù)用 session 的好處有兩個：

　　1， 減少了 CPU 消耗，因為不需要進(jìn)行非對稱密鑰交換的計算。

　　2， 提升訪問速度，不需要進(jìn)行完全握手階段二，節(jié)省了一個 RTT 和計算耗時。

　　TLS 協(xié)議目前提供兩種機(jī)制實(shí)現(xiàn) session resume，分別介紹一下。

　　2.3.1 Session cache

　　Session cache 的原理是使用 client hello 中的 session id 查詢服務(wù)端的 session cache， 如果服務(wù)端有對應(yīng)的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。

　　Session cache 有兩個缺點(diǎn)：

　　1， 需要消耗服務(wù)端內(nèi)存來存儲 session 內(nèi)容。

　　2， 目前的開源軟件包括 nginx，apache 只支持單機(jī)多進(jìn)程間共享緩存，不支持多機(jī)間分布式緩存，對于百度或者其他大型互聯(lián)網(wǎng)公司而言，單機(jī) session cache 幾乎沒有作用。

　　Session cache 也有一個非常大的優(yōu)點(diǎn)：

　　1， session id 是 TLS 協(xié)議的標(biāo)準(zhǔn)字段，市面上的瀏覽器全部都支持 session cache。

　　百度通過對 TLS 握手協(xié)議及服務(wù)器端實(shí)現(xiàn)的優(yōu)化，已經(jīng)支持全局的 session cache，能夠明顯提升用戶的訪問速度，節(jié)省服務(wù)器計算資源。

　　2.3.2 Session ticket

　　上節(jié)提到了 session cache 的兩個缺點(diǎn)，session ticket 能夠彌補(bǔ)這些不足。

　　Session ticket 的原理參考 RFC4507。簡述如下：

　　server 將 session 信息加密成 ticket 發(fā)送給瀏覽器，瀏覽器后續(xù)握手請求時會發(fā)送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。

　　顯然，session ticket 的優(yōu)點(diǎn)是不需要服務(wù)端消耗大量資源來存儲 session 內(nèi)容。

　　Session ticket 的缺點(diǎn)：

　　1， session ticket 只是 TLS 協(xié)議的一個擴(kuò)展特性，目前的支持率不是很廣泛，只有 60% 左右。

　　2， session ticket 需要維護(hù)一個全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。

　　總體來講，session ticket 的功能特性明顯優(yōu)于 session cache。希望客戶端實(shí)現(xiàn)優(yōu)先支持 session ticket。

　　2.4 Ocsp stapling

　　Ocsp 全稱在線狀態(tài)檢查協(xié)議 (rfc6960)，用來向 CA 站點(diǎn)查詢狀態(tài)，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請求，seo優(yōu)化排名方法，CA 返回狀態(tài)內(nèi)容，然后瀏覽器接受是否可信的狀態(tài)。

　　這個過程非常消耗時間，因為 CA 站點(diǎn)有可能在國外，網(wǎng)絡(luò)不穩(wěn)定，RTT 也比較大。那有沒有辦法不直接向 CA 站點(diǎn)請求 OCSP 內(nèi)容呢？ocsp stapling 就能實(shí)現(xiàn)這個功能。

　　詳細(xì)介紹參考 RFC6066 第 8 節(jié)。簡述原理就是瀏覽器發(fā)起 client hello 時會攜帶一個 certificate status request 的擴(kuò)展，服務(wù)端看到這個擴(kuò)展后將 OCSP 內(nèi)容直接返回給瀏覽器，完成狀態(tài)檢查。

　　由于瀏覽器不需要直接向 CA 站點(diǎn)查詢狀態(tài)，這個功能對訪問速度的提升非常明顯。

頁面長度過長，也會導(dǎo)致不收錄？

　　站點(diǎn)反饋：

　　網(wǎng)站主體內(nèi)容都是js生成，針對用戶訪問，沒有做優(yōu)化;但是網(wǎng)站特針對爬蟲抓取做了優(yōu)化，且將圖片也直接做了base64轉(zhuǎn)化;然而優(yōu)化后發(fā)現(xiàn)內(nèi)容卻不被百度收錄

　　頁面質(zhì)量很好，還特意針對爬蟲做了優(yōu)化，為什么內(nèi)容反而不收錄了呢?

　　工程師分析：

　　1、網(wǎng)站針對爬蟲爬取做的優(yōu)化，直接將圖片二進(jìn)制內(nèi)容放到了html中導(dǎo)致頁面長度過長，網(wǎng)站頁面長度達(dá)164k;

　　2、 站點(diǎn)優(yōu)化后將主體內(nèi)容放于最后，圖片卻放于前面;

　　3、爬蟲抓取內(nèi)容后，SEO搜索引擎排名，頁面內(nèi)容過長被截斷，已抓取部分無法識別到主體內(nèi)容，最終導(dǎo)致頁面被認(rèn)定為空短而不收錄。

　　工程師建議：

　　1、不建議站點(diǎn)使用js生成主體內(nèi)容，如js渲染出錯，很可能導(dǎo)致頁面內(nèi)容讀取錯誤，頁面無法抓取

　　2、 如站點(diǎn)針對爬蟲爬取做優(yōu)化，建議頁面長度在128k之內(nèi)，不要過長

　　3、針對爬蟲爬取做優(yōu)化，請將主題內(nèi)容放于前方，避免抓取截斷造成的內(nèi)容抓取不全