從有到優:百度前端接入技術的升級之路
在1月16日,由 百度開發者中心 和InfoQ聯合主辦的“縱談前端接入技術、SEO和安全運維”主題沙龍活動中,來自百度開發者中心的資深運維工程師們熱情洋溢的分享了百度在前端技術、搜索速度優化和全站使用HTTPS技術的進展及成果,以及百度在這些方面有哪些寶貴經驗可供參考的。演講嘉賓分別為百度Golang委員會成員陶春華、專注于網頁搜索無線訪問速度的工程師許霞,和處理網頁搜索可達性、安全搜索等方向事務的主要技術負責人陳曦洋。
Go語言在Baidu Front-End方面的應用實踐
Go語言的廣泛流行取決于部署簡單、并發性好、良好的語言設計,以及執行性能好。這也是在重寫百度前端這一項目上為什么考慮選用Go語言的原因所在。陶春華老師介紹說,促使重寫Baidu Front-End的誘因主要基于以下三點:一是修改成本高。事件驅動的編程模型本身的編碼和調試難度都很大;C語言本身的難度和開發效率有很多限制。二是配置管理方式落后。為單產品線設計,無法支持平臺化要求;配置變更(修改、重載、驗證)能力差。三是變更和穩定性的矛盾。例如程序出core也是比較頭疼的事情。
在此前提之下,團隊決定使用Go語言來重寫前端,但是這里也遇到了一些問題,那就是GC(Gabage Collection)本身難以避免的時間延遲。BFE的需求是要在1ms以內,最大不超過10ms,一旦超過這個平均值,那么用戶體驗將大打折扣。而Go-BFE實測100萬連接,400ms GC 延遲。這就需要不斷的對GC進行優化。
在這里 陶老師 也介紹了兩種優化思路,第一個常見的方法就是將掃描的小對象合并成大對象,利用Array來合并一組對象。第二種方法精算性更高一點,可以把消耗內存較多的內容放到C里面,因為Go語言有一個CGO接口,直接通過Go調到C可以解決這個問題,只不過代價比較大。但是,問題和方案永遠是相生相伴的。用Array技術重寫網絡庫,所有的BFE將永遠用Array來寫,理論上可行。這里的問題又來了,第一風險太大,第二如果Go語言升級了,還能不能繼續使用下去。
陶老師在這里介紹的解決方法叫做車輪大戰。即,在一組工作進程中,進程和服務是等價的,某一個進程跟服務運作到一定時間之后關閉 GC ,讓它休息,第二個進程代替它服務,以此輪換,構成一個車輪大戰的局面。如果在不能直接解決 GC 問題的時候直接關掉服務,然后繞過它。這基本的方案思路也就是關閉繼承多進程的輪轉戰。(如上圖)
搜索速度優化的前進之路
在整個百度接入服務里,百度搜索一直秉承提供最基礎的三個保障,那就是安全、快速、可靠。許霞首先介紹說,在對速度進行度量之前,先要對數據檢測、收集。對客戶端數據監測的特點是:可以檢測任何對象,成本高,并且監測的指標很固定。JS埋點檢測數據的特點是:可以檢測任何指標,甚至可以檢測每一條結果的速度。第三方數據檢測的特點是:可以定制,并且有一定的海外監測能力,但成本高。
收集數據的意義在于可以很清晰的了解掌握用戶的搜索習慣,這對PV、UV以及變現收入有很大影響。那么如何貼切搜索引擎的特點做搜索速度的優化?通過三個方面:接入質量提升、后端處理優化和前端渲染優化。接入質量提升主要有兩個考察因素:延遲和帶寬,對應的也就是優化RTT和傳輸效率。
后端優化其實就是整個搜索引擎的優化了,分為緩存優化和檢索優化。緩存優化最基礎的方式就是進入、淘汰機制等等,保證淘汰機制是最合理的。檢索優化,則需要對硬件以及硬件方案的選擇做一些深入考慮。在前端渲染優化方面,除了考慮節省時間之外還要考慮怎樣讓它定性化。
對優化做決定性決策只是其中的一種方法,還有更聰明的創新方法,那就是關于無線技術。這里面所涉及的內容包括手機終端、機站以及IP網絡,傳輸速度當然是跟這三者有密不可分關系的。機站會根據自己能獲得多少收益來處理用戶的請求,盡量會縮小頭部信息,進行一定程度的數據壓縮。手機跟機站之間建立連接以維持這種連接關系。但電耗大是很關鍵的問題。百度搜索做了維持連接的一些機制,當用戶頁面空閑很長時間或者放在后臺,就可以減少電量的消耗。(如上圖)
全站HTTPS能否確保網站徹底安全?
2015年3月,百度搜索成為國內首家完成全站HTTPS改造的大型站點;且目前來看,全站HTTPS已經成為百度產品的首要標準;同時,統一接入平臺也大幅提升了HTTPS的接入效率和性能。陳曦洋老師在開講前是這樣介紹大背景的。全站HTTPS的原因是為了讓用戶保持良好的使用體驗,解決反饋較多的劫持和隱私泄露等問題。這些問題的具體case,包括頁面被加上URL參數,不停刷新;頁面被DNS劫持到其他網站;用戶手機號碼遭泄漏;白頁,搜索功能異常等等。正是出于對用戶數據的安全保密,維護網站正常運作的考量,百度專門成立了由百度搜索和運維部組成的HTTPS-SUPPORT團隊,對HTTPS進行深入研究,提供完整的服務,保障用戶正常訪問百度原始產品。
陳曦洋老師在這里詳細介紹了全站HTTPS改造的成本,這也是很多人都比較關心的焦點問題,這不僅涉及到證書的部署,還會涉及到激增的計算量,需要多次協商和握手,而用戶端搜索的延遲將會給HTTPS改造需要解決的問題。除此以外,對于一個大型網站而言,架構如何解決多業務部署 HTTPS 的問題,巨大的頁面和模板數量,以及如何解決實際部署中的各種問題,讓用戶無損/平滑的完成切換,其實是更具有挑戰性的工作。
計算性能涉及到密鑰(證書)的長度,1024和2048位在性能有什么差別呢?原來使用HTTP協議的時候,假設cps可以達到2w+,而轉換成HTTPS之后,cps只能達到2-3千;在訪問速度方面,使用了HTTPS之后,不做任何優化,訪問百度的速度可能會惡化250-500ms,一些設計比較差的頁面可能會惡化500-1200ms;在架構和產品成本方面,對于百度這樣的綜合性網站,牽一發而動全身,僅僅是在頁面形式上就要改大量的模板,成本相當大。
那么有沒有可選的優化方案呢?陳老師認為,性能優化上優先使用ECC。這里使用ECC密鑰長度大小要比RSA和DH密鑰長度短。在硬件的優化上則可以使用硬件加速卡,可以做TLS的遠程卸載(小型站點在不面對大量的惡意請求時 完全可以通過純軟件卸載,只需要保證連接復用率)。在訪問速度上的優化上,通過復用連接和協議優化可以盡量減少握手次數,就可以讓它接近于原始HTTP的性能。怎么去減少握手次數?比如Session cache和Session ticket可以極大的減少用戶在一定時間內再次訪問時的計算開銷,而HSTS能在瀏覽器內部完成HTTP到HTTPS的跳轉,不再經過一次網絡傳輸和瀏覽器開銷。另外還可以用SPDY-HTTP2方案,優點是基于單連接,能進一步提升連接復用比例,協議支持header壓縮,在無線網絡下有重要意義,這些都可以提高訪問速度。
除了對協議層進行優化之外,也可以在應用層做些優化,預連接就是一個很好的優化方案。比如在網頁端或者客戶端,用戶發起訪問請求之前提前把這個握手過程完成,減少延遲,這一點也很重要。另外陳老師建議站點在發展到一定規模時一定要做整體的接入規劃,控制域名數量,一些服務需要變成公共的,比如圖片,靜態資源的存儲和訪問。
在最后,陳老師也回答了大家普遍比較關心的問題,那就是使用HTTPS就代表著絕對安全嗎?事實上并沒有絕對地安全,代碼是人寫的,很多問題都是實際的實現上或者依賴的其他環境上出現了漏洞,OpenSSL HeartBlood就是最典型的案例,甚至連隨機數的生成和一些加密算法上也可能有人為埋下的漏洞,CDN回源這樣的路徑很多情況下也是使用的HTTP。百度使用HTTPS只能保護用戶在瀏覽百度產品的時候的安全,但是很多手機號的泄露是第三方站點導致的(它們會通過非法渠道購買識別用戶手機號的服務),這個問題并不能通過百度的HTTPS解決。但是相對于HTTP,HTTPS的安全防范性能更高,增加了壞人的做惡難度。
-------------------------------------------------------- -----------
百度開發者中心是百度為企業和個人開發者提供學習、交流、合作和服務的開放平臺,匯聚了百度所有對外開放的技術、平臺和服務,提供產品孵化、研發支持、運維托管、統計分析、分發推廣、換量變現等全方位服務和支持。通過百度的技術開放、搜索推廣和應用分發能力,助力開發者加速成功,實現開發者、消費者和百度三方共贏。
來自: http://www.infoq.com/cn/news/2016/01/baidu-frontend-optimization