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

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

• 靜態(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代碼
    2.  
    3.  
    4. <script src=a.js></script>
    5. 
    6. 
    7.  
    8.  
    9. 
       瀏覽器是邊下載邊解析的，文檔解析器首先遇到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