国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
Web性能優(yōu)化與Http2

如今,互聯(lián)網(wǎng)上的內(nèi)容越來越豐富,過去幾年時間,一個頁面產(chǎn)生請求和整個大小都一直增長,這個趨勢還會一直保持,對頁面性能優(yōu)化也要馬不停蹄。



一個頁面,會經(jīng)歷過加載資源,執(zhí)行腳本,渲染界面的過程。我們知道,100ms對于計算機來說,可以干很多事情了,但是對于網(wǎng)絡請求,可能一次RTT就沒了。因此,頁面加載對于Web性能是重中之重。

加載的快慢可以總結成受兩個因素影響:阻塞與延遲。
1、阻塞。瀏覽器在解析到腳本時,會阻塞頁面,等到腳本下載執(zhí)行完才繼續(xù)解析文檔。此外,瀏覽器還會限制同域下的并行請求數(shù),超過這個限制后的請求就會被阻塞住。
2、延遲。網(wǎng)絡請求都不可避免會有延遲,網(wǎng)頁上的延遲有兩種,一是DNS查詢,二是TCP連接。
克服這些缺點,我們有一些約定俗成的方案:

  • 靜態(tài)資源要支持304,開啟HTTP緩存控制
  • 開啟gzip,壓縮HTTP body
  • css放在html的head里,js在body底部
  • 合并請求
  • 使用雪碧圖
  • 域名分區(qū)(突破并行限制,也避免傳輸過多cookie)
  • 使用cdn
    這些方案基本都能立竿見影。但是,對于追求極致(KPI)的我們,這些還是遠遠不夠的。我們從頁面開始加載時說起。



    避免重定向

    重定向意味著要重新發(fā)起請求,當然我們沒事也不會亂跳。這里要說的一種重定向是,訪問HTTP站點,跳轉到HTTPS。

    避免這種跳轉,我們可以用HSTS策略,就是告訴瀏覽器,以后訪問我這個站點,必須用HTTPS協(xié)議來訪問,讓瀏覽器幫忙做轉換,而不是請求到了服務器后,才知道要轉換。只需要在響應頭部加上 Strict-Transport-Security: max-age=31536000 即可。

    預加載

    DNS查詢需要個RTT時間,在瀏覽器級別,系統(tǒng)級別都會有層DNS緩存,之前解析過的可以直接從本機緩存獲取,以減少延遲。

    Web標準提供了一種DNS預解析技術,因為服務器是知道頁面即將會發(fā)生哪些請求的,那我們可以在頁面頂部,插入 ,讓瀏覽器先解析一下這個域名。那么,后續(xù)掃到同域的請求,就可以直接從DNS緩存獲取了。

    此外,Web標準也提供prefetch,prerender的預加載技術。prefectch會在瀏覽器空閑的時候,向所提供的鏈接發(fā)起請求,而prerender不僅會請求,還會幫你在后臺渲染頁面。如果在一個頁面中,你知道用戶有很大概率去點某個鏈接,可以嘗試把這個鏈接加到prefetch或prerender,那么用戶就會秒開這個頁面了。

    使用TCP、TLS最佳實踐

    HTTP請求要經(jīng)過建立TCP連接這一步,而TCP為了可靠傳輸,建立連接需要三次握手。如果網(wǎng)站又接入了HTTPS,那還要額外多兩次RTT時間以建立安全通道,這樣耗費了很多時間。HTTP是建立在TCP、TLS之上,那么TCP的最佳實踐,SSL的優(yōu)化都是適用于HTTP的優(yōu)化。

    比如TCP慢啟動過程非常影響性能的,我們可以把初始窗口調大,讓慢啟動更快。對于TLS可用緩存session_ticket之類的優(yōu)化可以減少一次RTT。

    內(nèi)聯(lián)

    對于一些簡單的頁面,CSS樣式和JavaScript腳本甚至圖片,可以不必使用外聯(lián)的方式引入,直接把子資源內(nèi)嵌到HTML里,圖片可以用base64編碼內(nèi)嵌,這相當于請求頁面時,服務器順便把子資源給一共推送過去了。傳輸?shù)膬?nèi)容都一樣,但減少好多請求了,自然節(jié)省不少時間。

    不過這樣做的缺點是瀏覽器無法緩存這些子資源,這種做法只能降低首次加載時間,所以需要看取舍了??赡鼙容^適用于一次性的頁面,類似活動之類的。

    手動管理緩存

    為了代碼架構清晰,便于維護,我們都會用模塊化的方式去編碼,每個模塊一個文件,這樣帶來的問題是一個頁面需要很多文件,要很多請求,這對頁面性能是不利的。合并是解決這個問題的好方法,但又因為HTTP緩存機制是基于URL的,只要某個模塊一改動,整個合并資源都要重新下載。

    在對性能要求較高,比如在移動設備環(huán)境上,我們可以利用HTML5中的localStorage特性,來實現(xiàn)手動控制緩存。大概的思路是,在定義模塊時,同時將模塊的代碼和版本號分別儲存到localStorage,在下一次打算請求模塊之前,我們先判斷模塊的最新版本是不是在localStorage中,將不存在的模塊組合在一起,請求動態(tài)合并的資源。

    不過,這種方案可能會引發(fā)安全問題。假如同域下的其他頁面被XSS攻擊,壞人就可以篡改localStorage的內(nèi)容,可能導致原來的頁面代碼被植入惡意程序。解決的方法是,在執(zhí)行模塊之前,算一下代碼摘要,對比下服務器給的該模塊的摘要,再決定是否使用。也可以使用SRI策略,由瀏覽器幫你做校驗。


    HTTP持久連接

    HTTP持久連接可以重用已建立的TCP連接,減少三次握手的RTT延遲。瀏覽器在請求時帶上 connection: keep-alive 的頭部,服務器收到后就要發(fā)送完響應后保持連接一段時間,瀏覽器在下一次對該服務器的請求時,就可以直接拿來用。

    以往,瀏覽器判斷響應數(shù)據(jù)是否接收完畢,是看連接是否關閉。在使用持久連接后,就不能這樣了,這就要求服務器對持久連接的響應頭部一定要返回content-length標識body的長度,供瀏覽器判斷界限。有時,content-length的方法并不是太準確,也可以使用 Transfer-Encoding: chunked 頭部發(fā)送一串一串的數(shù)據(jù),最后由長度為0的chunked標識結束。



    HTTP管線化

    HTTP管線化可以克服同域并行請求限制帶來的阻塞,它是建立在持久連接之上,是把所有請求一并發(fā)給服務器,但是服務器需要按照順序一個一個響應,而不是等到一個響應回來才能發(fā)下一個請求,這樣就節(jié)省了很多請求到服務器的時間。不過,HTTP管線化仍舊有阻塞的問題,若上一響應遲遲不回,后面的響應都會被阻塞到。



    bigpipe

    目前大部分模型都是,服務器把邏輯處理完之后,一次性把整個響應輸出。這里存在一個阻塞的過程,邏輯處理一般都涉及IO操作的都比較慢,而現(xiàn)代瀏覽器都支持邊接收數(shù)據(jù)邊渲染,所以其實服務器可以接收到請求時就把頁面框架flush出來,如果頁面包含多個較獨立部分,也可以每處理完一部分就馬上輸出,這樣可以縮短白屏。從用戶感受上可能會更好,頁面上一直有所反應,而不是一直白屏,完全不知道你在干嘛。

    各種各樣的優(yōu)化,都在填HTTP/1.x留下的坑,HTTP/2帶著填坑的使命,從根本上去解決這些問題。HTTP/1.x是一個文本協(xié)議,這注定它是非常冗余的協(xié)議,HTTP/2改變了這一點,在HTTP/1.x的語義上,將文本數(shù)據(jù)封裝在幀里,并采用二進制編碼。

    下圖中binary framing就是二進制分幀層,這里會將HTTP/1.x的header翻譯成headers類型的幀,將body翻譯成data類型的幀。



    HTTP/2的性能怎樣,akamai的這個demo(https://http2.akamai.com/demo)估計會讓你很興奮。

    下面詳細介紹下HTTP/2。

    多路復用

    在HTTP/2中,有兩個非常重要的概念:幀(frame)和流(stream)。

    1、幀(frame)

    HTTP/2中數(shù)據(jù)傳輸?shù)淖钚挝唬虼藥粌H要細分表達HTTP/1.x中的各個部份,也優(yōu)化了HTTP/1.x表達得不好的地方,同時還增加了HTTP/1.x表達不了的方式。

    每一幀都包含幾個字段,有l(wèi)ength、type、flags、stream identifier、frame playload等,其中type代表幀的類型,在HTTP/2的標準中定義了10種不同的類型,包括上面所說的HEADERS frame和 DATA frame。此外還有
    PRIORITY(設置流的優(yōu)先級)
    RST_STREAM(終止流)
    SETTINGS(設置此連接的參數(shù))
    PUSH_PROMISE(服務器推送)
    PING(測量RTT)
    GOAWAY(終止連接)
    WINDOW_UPDATE(流量控制)
    CONTINUATION(繼續(xù)傳輸頭部數(shù)據(jù))

    2、流(stream)

    “流”在HTTP/2中是一個邏輯上的概念,就是說在一個TCP連接上,我們可以向對方不斷發(fā)送一個個的消息,這里每一個消息看成是一幀,而每一幀有個stream identifier的字段標明這一幀屬于哪個“流”,然后在對方接收時,根據(jù)stream identifier拼接每個“流”的所有幀組成一整塊數(shù)據(jù)。我們把HTTP/1.x每個請求都當作一個“流”,那么請求化成多個流,請求響應數(shù)據(jù)切成多個幀,不同流中的幀交錯地發(fā)送給對方,這就是HTTP/2中的多路復用。



    從上圖我們可以留意到:
    • 不同的流在交錯發(fā)送;
    • HEADERS 幀在 DATA 幀前面;
    • 流的ID都是奇數(shù),說明是由客戶端發(fā)起的,這是標準規(guī)定的,那么服務端發(fā)起的就是偶數(shù)了。

      多路復用讓HTTP連接變得很廉價,只需要創(chuàng)建一個新流即可,這不需要多少時間,而在HTTP/1.x時代卻要經(jīng)歷三次握手時間或者隊首阻塞等問題。而且創(chuàng)建新流默認是無限制的,也就是可以無限制的并行請求下載。不過,HTTP/2還是提供了 SETTINGS_MAX_CONCURRENT_STREAMS 字段在 SETTINGS 幀上設置,可以限制并發(fā)流數(shù)目,標準上建議不要低于100以保證性能。

      優(yōu)化Web性能有一個常用的技術,就是圖片延遲加載,目的是除了節(jié)省流量外,還能避免圖片資源與其他重要的腳本資源競爭下載。

      HTTP/2提供了流的優(yōu)先級與依賴性這種機制,可用 HEADERS 幀或 PRIORITY 幀設置,不過協(xié)議并沒有提供如何處理優(yōu)先級的具體算法,這可由服務器靈活應對。我用個例子來說明這個機制。
      Html代碼
      1.  
      2.  
      3. <script src=a.js></script>
      4.  
      5.  

      6. 瀏覽器是邊下載邊解析的,文檔解析器首先遇到a.js,它就會去下載并且阻塞頁面,同時,資源探測器會繼續(xù)向下掃描,發(fā)現(xiàn)/uploadfile/2015/1020/20151020033422244.jpg、/uploadfile/2015/1020/20151020033422106.jpg和style.css并服務器發(fā)起請求。在沒有優(yōu)先級機制時,/uploadfile/2015/1020/20151020033422244.jpg、/uploadfile/2015/1020/20151020033422106.jpg會跟重要的a.js、style.css競爭下載,但在HTTP/2中,瀏覽器可以給/uploadfile/2015/1020/20151020033422244.jpg、/uploadfile/2015/1020/20151020033422106.jpg設置較低的優(yōu)先級,另外依賴關系為



        這樣服務器根據(jù)優(yōu)先級信息,首先吐出a.js、style.css,再吐出圖片,因此頁面在沒有圖片的情況下提前進入可交互狀態(tài)。例子所說的是在瀏覽器層面上harcode的一個優(yōu)先級策略,再比如上文提到的prefetch就可以給一個更低的優(yōu)先級。在代碼層面上,也許之后會提供一些控制優(yōu)先級的特性,類似于目前只有IE支持的lazyload attribute。
        服務器推送

        作為HTTP/2的一個重磅新功能,我們不要簡單理解字面意思,其實不是你想推,想推就能推的,服務器要遵循請求-響應這個模型,只不過服務器對同一請求可以推送多個響應??蛻舳嗽诮粨Q SETTINGS 幀時,設置字段 SETTINGS_ENABLE_PUSH(0x2) 為1顯式允許服務器推送。

        在HTTP/1.x時代,其實我們已經(jīng)體驗過了“服務器推送”,就是資源內(nèi)嵌到HTML里。服務器在響應HTML時,就已經(jīng)知道瀏覽器會請求哪些子資源了,這時一并響應這些子資源,可以節(jié)省了服務器到瀏覽器以及瀏覽器解析再發(fā)請求的這段延遲。但是內(nèi)聯(lián)的問題是瀏覽器不會緩存這些數(shù)據(jù),這意味要浪費很多流量,而且有緩存時網(wǎng)頁性能還是很好的。

        服務器推送解決了這個問題。服務器在接受到請求時,分析出要推送的資源,先發(fā)個 PUSH_PROMISE 幀給瀏覽器。此幀包含一個新的流ID,還有header block fragment字段,內(nèi)容是請求的頭部信息,可理解為服務器模擬瀏覽器發(fā)起請求,然后再發(fā)送各個response header和response body。瀏覽器收到 PUSH_PROMISE 幀時,根據(jù)header block fragment字段里的url,可以知道當前有沒有緩存,從而判斷是否要接收。如果不要,瀏覽器就要發(fā)送個 RST_STREAM 來終止服務器推送。

        如果瀏覽器不要這個推送,就會出現(xiàn)浪費流量的現(xiàn)象,因為整個過程都是異步的,在服務器接收到RST_STREAM時,響應很有可能部份發(fā)出或者全部發(fā)出了。這種情況只能視場景而定,若是流量浪費不能容忍,我們可以使用prefetch來替代,讓瀏覽器盡早發(fā)現(xiàn)需要的資源,而HTTP/2中創(chuàng)建新的請求并不需要多少時間,所以大概多了個RTT的時間。

        首部壓縮

        服務器推送,此推送非彼推送,一開始以為,是不是以后可以拋棄輪詢這種技術了?并不是,該輪詢還是要輪詢。那么,在開啟keep-alive的情況下,輪詢在HTTP/2中的性能沒什么提升嗎?也并不是。

        在HTTP/1.x中首部是沒有壓縮的,gzip只會壓縮body,HTTP/2提供了首部壓縮方案。一般輪詢請求首部,特別是cookie占用很多大部份空間,首部壓縮使得整個HTTP數(shù)據(jù)包小了很多,傳輸也就會更快。

        剛開始spdy提出的首部壓縮方案比較簡單粗暴,直接像壓縮body那樣壓縮首部,這看起來好像沒什么不妥,但是有安全隱患,會有受到CRIME式攻擊的可能性。這種攻擊方法簡單說,就是不斷地利用已知數(shù)據(jù)去探測密文,達到破解的目的。無損壓縮算法會有個特性,數(shù)據(jù)越冗余,壓縮效率越好。而首部中的很多字段是已知的,我們只要構造個請求,請求中帶有首部的某個字段,經(jīng)壓縮再加密后的密文長度就會有所變化,然后不斷構造猜測該字段的值,同時觀察密文的長度,慢慢地確定首部字段的值。
        Java代碼
        1. GET /pwd=0 HTTP/1.1
        2. Cookie: pwd=123
        3.  
        4. GET /pwd=1 HTTP/1.1
        5. Cookie: pwd=123
          我們會發(fā)現(xiàn),前者的密文長度比后者長,這樣就確定了“d”,再慢慢的猜測,達到破解的目的。

          HTTP/2中拋棄了這種方案,用專門設計的HPACK。它是在服務器和客戶端各維護一個“首部表”,表中用索引代表首部名,或者首部鍵-值對,上一次發(fā)送兩端都會記住已發(fā)送過哪些首部,下一次發(fā)送只需要傳輸差異的數(shù)據(jù),相同的數(shù)據(jù)直接用索引表示即可,另外還可以選擇地對首部值壓縮后再傳輸。按照這樣的設計,兩次輪詢請求的首部基本是一樣的,那之后的請求基本只需要發(fā)送幾個索引就可以了。



          “首部表”有兩種,一種是靜態(tài)表,即HTTP/2協(xié)議內(nèi)置了常用的一些首部名和首部鍵值對。另一種是動態(tài)表,保存自定義的首部或五花八門的鍵值對等,動態(tài)表可以通過SETTINGS幀的SETTINGS_HEADER_TABLE_SIZE規(guī)定大小。

          一次完整的HTTP/2通信

          • 在尚未知道服務器是否支持HTTP/2時,http請求頭部加上upgrade: h2c,表明客戶端支持HTTP/2,詢問服務器要不要切換協(xié)議。
          • 瀏覽器同時發(fā)送HTTP2-Settings頭部,帶上base64編碼的SETTINGS frame。
          • 對于https請求,是在TLS握手時進行協(xié)商,瀏覽器發(fā)送ClientHello時,帶上h2標志,表明客戶端支持HTTP/2。
          • 若服務器不支持,則忽略upgrade頭部,正常響應。若支持,則發(fā)送101響應,以空行結束響應,并開始發(fā)送HTTP/2幀。
          • 服務器要先響應connection preface,帶上SETTINGS frame。
          • 服務器創(chuàng)建新流,推送a.js。然后繼續(xù)發(fā)送index.html和a.js的response header、response body。
          • 瀏覽器收到PUSH_PROMISE幀,發(fā)現(xiàn)服務器要推送的內(nèi)容已經(jīng)在瀏覽器緩存里了,遂發(fā)送RST_STREAM拒絕推送。
          • 服務器收到RST_STREAM后,不再推送a.js剩下的數(shù)據(jù)。
          • 服務器因為一些原因想要關閉連接,發(fā)送GOAWAY幀。也可以由瀏覽器關閉,只要瀏覽器覺得之后不再有請求了。
            后話

            HTTP/2才剛剛正式發(fā)布不久,支持程度并沒有那么好,以后應該有相當長的一段時間,HTTP/2要與HTTP/1.x共存。特別是,Win7快要成為下個XP的節(jié)奏,那么IE9就是下個IE6了。雙協(xié)議部署上,可能會有不少麻煩之處。HTTP/1.x時代的很多優(yōu)化,在HTTP/2是不必要的,也有沖突的,甚至是累贅。

            比如子資源的位置,可以用HTTP/2優(yōu)先級解決。
            比如域名分區(qū),在HTTP/2中本來可以用一個連接完成,卻要用多個連接,這樣就有性能損耗了。
            比如合并、雪碧圖,之前是為了減少請求,但在HTTP/2新起請求不費事,但拆分開來倒可以更好地利用瀏覽器緩存。還有類似的內(nèi)聯(lián)資源,可以用服務器推送,也同樣可以更好地利用緩存。
            更多具體的問題,需要在生產(chǎn)實踐中得出了。


來源:https://www.2cto.com/kf/201510/446824.html

本站僅提供存儲服務,所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權內(nèi)容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
徹底弄懂瀏覽器緩存策略
HTTP/2.0 簡單總結
萬字長文!搞定逃不脫的 DNS 面試題
xxxxHub 都用上了 HTTP/2 ,它牛逼在哪?
(超詳細)頁面性能利器:緩存
HTTP 2.0 ,有點炸 !
更多類似文章 >>
生活服務
分享 收藏 導長圖 關注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服