摘要:假如我們底層的連接得到重用,這時候的情況會是這樣子很明顯,在獲取的請求中,減少了一次握手往返。在使用持久連接后,避免了一次握手往返總延遲減少為。其代價往往是不能充分利用網絡連接,造成服務器緩沖開銷,有可能導致客戶端更大的延遲。
歡迎大家前往騰訊云+社區,獲取更多騰訊海量技術實踐干貨哦~
本文由騰訊IVWEB團隊發表于云+社區專欄
作者:yangchunwen
HTTP協議是前端性能乃至安全中一個非常重要的話題,最近在看《web性能權威指南(High Performance Browser Networking)》,把其中關于HTTP部分的內容拿出來分享一下,加了一點自己的想法,當然沒有《HTTP權威指南》講得詳細,但對于理解我們平常做的事情很有啟發。預計會有兩三篇文章,重點分別會涉及到HTTP 1.1、HTTPS、HTTP 2.0等內容,本篇主要涉及HTTP 1.1及其應用。
HTTP的第一個版本被官方稱為HTTP0.9,這是個只有一行的協議,例如:
GET /about/
(超文本響應……)
(連接關閉……)
HTTP 0.9有幾個要點:
這個版本的HTTP主要用來傳輸文本,并且沒有共用TCP連接。
一個典型的HTTP 1.0請求過程如下:
GET /rfc/rfc1945.txt HTTP/1.0
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Accept: */*
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 1 May 1996 12:45:26 GMT Server: Apache 0.84
(超文本響應……)
(連接關閉……)
相對前一個版本,HTTP 1.0主要有以下幾點變化:
這時候開始有了請求及返回首部的概念,開始傳輸不限于文本(其他二進制內容)
HTTP 1.1是當前大部分應用所使用的協議版本。相對前面的1.0版本,HTTP 1.1語義格式基本保持不變,但是它加入了很多重要的性能優化:持久連接、分塊編碼傳輸、字節范圍請求、增強的緩存機制、傳輸編碼及請求管道。
實際上,持久鏈接在后來被反向移植到了HTTP1.0上
HTTP 2.0 的主要目標是改進傳輸性能,實現低延遲和高吞吐量。HTTP 2.0作了很多性能角度的優化,另一方面,HTTP的高層協議語義并不會因為這次版本升級而受影響。所有HTTP首部、值,以及它們的使用場景都不會變。現有的任何網站和應用,無需做任何修改都可以在 HTTP 2.0 上跑起來。換句話說, 等以后我們的服務器、客戶端(如瀏覽器)都支持HTTP 2.0的時候,我們不用為了利用 HTTP 2.0 的好處而修改標記,作很多額外的編碼,卻能享受到它帶來的更低的延遲和更高的網絡連接利用率交付!
HTTP 2.0的內容將在下篇或下下篇放出,本文不對其做過多潤色
前面講到,HTTP 1.1這個版本引入了大量增強性能的重要特性,其中包括:
這里重點講一下持久化、管道在前端性能優化中的一些應用
所謂持久連接,就是重用 TCP連接,多個HTTP請求公用一個TCP連接。
HTTP 1.1 改變了 HTTP 協議的語義,默認使用持久連接。換句話說,除非明確告知(通過 Connection: close
首部),否則服務器默認會保持TCP連接打開。如果你使用的是 HTTP 1.1,從技術上說不需要 Connection: Keep-Alive
首部,但很多客戶端還是選擇加上它,比如我們的瀏覽器在發起請求的時候,一般會默認幫我們帶上 Connection: Keep-Alive
首部。
我們來看一下為什么持久連接對我們來說這么重要。
假設一個網頁僅包含一個HTML文檔及一個CSS樣式文件,服務器響應這兩個文件的時間分別為40ms及20ms,服務器和瀏覽者分別在哈爾濱和深圳,兩者之間單向光纖延遲為28ms(假設的理想狀態,實際會比這個要大)。
HTML下載完畢后,TCP連接關閉。
可以看到,兩個HTTP請求都分別需要經歷一次TCP的三次握手時間,另外,圖中沒有體現到的是,每一次TCP請求都有可能會經歷一次TCP慢啟動 過程,這是影響傳播性能的一個不可忽視的重要因素。
假如我們底層的TCP連接得到重用,這時候的情況會是這樣子:
很明顯,在獲取CSS的請求中,減少了一次握手往返。
一開始,每個請求要用兩個TCP連接,總延遲為284ms。在使用持久連接后,避免了一次握手往返,總延遲減少為228ms。這里面兩次請求節省了56ms(一個RTT,Round-Trip Time)的時間
上面的例子還只是只有一個HTML和一個CSS的簡單假設情況,而現實世界的web的HTTP請求數量比這個要多得多,在啟用持久連接的情況下,N次請求節省的總延遲時間就是(N-1)×RTT。
現實情況中,延遲更高、請求更多,性能提升效果比這里還要高得多。事實上,網絡延遲越高,請求越多,節省的時間就越多。實際應用中,這個節省的總時間可按秒來算了。如果每一個HTTP都重啟一個TCP連接,可想而知要浪費多少時間!
持久 HTTP 可以讓我們重用已有的連接來完成多次應用請求,但多次請求必須嚴格滿足先進先出(FIFO,first in first out)的隊列順序:發送請求,等待響應完成,再發送客戶端隊列中的下一個請求。
舉一下上一節持久連接的那個例子,首先,服務器處理完第一次請求后,會發生了一次完整的往返:先是響應回傳,接著是第二次請求,在第二次請求到達服務器之間的這段時間里,服務器空閑。
如果服務器能在處理完第一次請求后,立即開始處理第二次請求呢?甚至,如果服務器可以并行處理兩個請求呢?
這時候HTTP管道就派上用場了,HTTP管道是一個很小但對上述工作流非常重要的一次優化。
有了HTTP管道,我們的HTTP請求在一定程度上不用再一個一個地串行請求,而是可以多個并行了,看起來好像很理想:
如上圖,HTML和CSS的請求同時到達服務器,服務器同時處理,然后返回。
這一次,通過使用HTTP管道,又減少了兩次請求之間的一次往返,總延遲減少為 172 ms。從一開始沒有持久連接、沒有管道的284ms,到優化后的172ms,這40%的性能提升完全拜簡單的協議優化所賜。
等一下,剛剛那個例子好像哪里還不夠好:既然請求同時到達,同時處理,為什么后面要先返回HTML,然后再返回CSS?兩者不能同時返回嗎?
理想很豐滿,現實卻有點骨感,這就是HTTP 1.1管道的一個很大的局限性:HTTP請求無法很好地利用多路復用,不允許一個連接上的多個響應數據交錯返回(多路復用)。因而一個響應必須完全返回后,下一個響應才會開始傳輸。
這個管道只是讓我們把FIFO隊列從客戶端遷移到了服務器。也就是說,請求可以同時到達服務器,服務器也可以同時處理兩個文件,但是,兩個文件還是得按順序返回給用戶,如下圖:
可以看到,即使客戶端同時發送了兩個請求,而且CSS資源先準備就緒,但是服務器也會先發送 HTML 響應,然后再交付 CSS。
題外話 上面兩節舉的例子,說到了HTML和CSS請求同時到達,這是書中的例子,實際上,個人覺得這個例子舉得不是很恰當。 實際的web中,HTML及其包含的CSS一般不會同時到達服務器,正常的瀑布圖也不是這樣的,往往是要先獲取HTML內容后瀏覽器才能發起其中的CSS等資源請求。我想作者只是為了闡述原理吧,個人認為換成同一個HTML文檔中CSS和JS可能更加恰當。
這個問題的原理在于TCP層面的“隊首阻塞”,感興趣可以去復習下計算機網絡的課程。其代價往往是:不能充分利用網絡連接,造成服務器緩沖開銷,有可能導致客戶端更大的延遲。更嚴重的時,假如前面的請求無限期掛起,或者要花很長時間才能處理完,所有后續的請求都將被阻塞,等待它完成。
所以,在HTTP 1.1中,管道技術的應用非常有限,盡管其優點毋庸置疑。實際上,一些支持管道的瀏覽器,通常都將其作為一個高級配置選項,但大多數瀏覽器都會禁用它。換句話說,作為前端工程師,開發的應用是面向普通瀏覽器應用的話,還是不要過多的指望HTTP管道,看來還是期待一下HTTP 2.0中對管道的優化吧。
不過,實際上還是有很好地利用HTTP管道的一些應用,例如在WWDC 2012上,有蘋果的工程師分享了一個針對HTTP優化取得巨大成效的案例:通過使用HTTP的持久連接和管道,重用iTunes中既有的TCP連接,使得低網速用戶的性能提升到原來的3倍!
實際上假如你想充分利用管道的好處,必須要保證下面這幾點條件:
因為iTunes的服務器和客戶端都受開發者控制的應用,所以他們能滿足以上的條件。這也許能給開發hybrid應用或者開發瀏覽器之外的web應用的前端工程師們一些啟發,如果你開發的網站面向的用戶是使用五花八門的瀏覽器,你可能就沒轍了。
因為HTTP 1.1管道存在上面的缺點,所以利用率不高。那么問題來了:假設沒有使用HTTP管道,我們的所有HTTP請求都只能通過持久連接,一個接一個地串行返回,這得有多慢?
實際上,現階段的瀏覽器廠商采取了另外的辦法來解決HTTP 1.1管道的缺陷:允許我們并行打開多個TCP會話。至于是多少個,大家可能已經似曾相識:4到8個不等。這就是前端工程師非常熟悉的瀏覽器只允許從同一個服務器并行加載4到8個資源
這一認識的真正來歷。
HTTP持久連接雖然幫我們解決了TCP連接復用的問題,但是現階段的HTTP管道卻無法實現多個請求結果的交錯返回,所以瀏覽器只能開啟多個TCP連接,以達到并行地加載資源的目的。
只能說,這是作為繞過應用協議(HTTP)限制的一個權宜之計。可以這樣打一個比喻,一個水管無法同時運輸多種液體,那就只能給每一種液體開通一條運輸管了,至于這個水管什么時候可以智能化到同時運輸不同的液體,又能保證各自完整不受干擾到達目的地并在目的地自行分類?還是那一句,期待HTTP 2.0吧。
這里的連接數為什么是4到8個,是多方平衡的結果:這個數字越大,客戶端和服務器的資源占用越多(在高并發訪問的服務器中因為TCP連接造成的系統開銷不可忽視),每個主機4到8個連接只不過是大家都覺得比較安全的一個數字。
前面說到,瀏覽器和服務器之間只能并發4到8個TCP連接,也就是同時下載4到8個資源,夠嗎?
看看我們現在的大部分網站,動不動就幾十個JS、CSS,一次六個,會造成后面大量的資源排隊等待;另外,只下載6個資源,對帶寬的利用率也是很低的。
打個比喻,一個工廠裝了100根水管,每次卻只能用其中6根接水,既慢,又浪費水管!
所以,我們前端性能優化中有一個最佳實踐:使用域名分區!
對啊,何必把自己只限制在一個主機上呢?我們可以手工將所有資源分散到多個子域名,由于主機名稱不一樣了,就可以突破瀏覽器的連接限制,實現更高的并行能力。
通過這種方式“欺騙”瀏覽器,這樣瀏覽器和服務器之間的并行傳輸數量就變多了。
域名分區使用得越多,并行能力就越強!
但是,域名分區也是有代價的!
實踐中,域名分區經常會被濫用。
例如,假設你的應用面向的是2G網絡的手機用戶,你分配了好幾個域名,同時加載十幾二十多個CSS、JS,這里的問題在于:
所以在一些低帶寬高延時的場景,例如2G手機網絡,域名分區做過了的話,不光不會帶來前端性能的提升,反而會變成性能殺手。
域名分區是一種合理但又不完美的優化手段,最合適的辦法就是,從最小分區數目(不分區)開始,然后逐個增加分區并度量分區后對應用的影響,從而得到一個最優的域名數。
我們前端性能優化中有這么一個所謂的最佳實踐原則:合并打包JS、CSS文件,以及做CSS sprite。
現在我們應該知道為什么要這樣做了,實際上就是因為現在HTTP 1.1的管道太弱了,這兩種技術的效果就好像是隱式地啟用了HTTP 管道:來自多個響應的數據前后相繼地連接在一起,消除了額外的網絡延遲。
實際上,就是把管道提高了一層,置入了應用中,也許到了HTTP 2.0時代,前端工程師就不用干這樣的活了吧?(HTTP 2.0的內容下篇講)
當然,連接拼合技術同樣有代價的。
打包文件到底多大合適呢?可惜的是,沒有理想的大小。然而,谷歌PageSpeed團隊的測試表明,30~50 KB(壓縮后)是每個JavaScript 文件大小的合適范圍:既大到了能夠減少小文件帶來的網絡延遲,還能確保遞增及分層式的執行。具體的結果可能會由于應用類型和腳本數量而有所不同。
JavaScript 和CSS 代碼, 通過適當的script 和style 塊可以直接放在頁面中,而圖片甚至音頻或PDF 文件,都可以通過數據URI(data:[mediatype][;base64],data)的方式嵌入到頁面中。
上面的這種方式我們稱為資源內嵌。
嵌入資源是另一種非常流行的優化方法, 把資源嵌入文檔可以減少請求的次數。尤其在2G網絡等情況中,內嵌資源可以有效地減少多次請求帶來的時延。可以參考這篇文章在2G中的一些實踐。
當然,有缺點:
Google的磚家給出一些經驗:
本文介紹了HTTP 1.1在前端性能優化中的一些應用,有些是為了繞過HTTP 1.1局限性的一些不得不做的事情,比如資源合并、壓縮、內嵌等,這些都可以說是HTTP 2.0來臨前的一些解決問題的“黑魔法”。
HTTP 1.1及其利用當然遠遠沒有本文說得那么簡單,我只是濃縮了一部分內容,有興趣可以去研究《HTTP權威指南》。
問答
BDD框架的前端如何搭建?
相關閱讀
全面進階 H5 直播(上)
NodeJs內存管理
WebGL 紋理顏色原理
【每日課程推薦】機器學習實戰!快速入門在線廣告業務及CTR相應知識
此文已由作者授權騰訊云+社區發布,更多原文請點擊
搜索關注公眾號「云加社區」,第一時間獲取技術干貨,關注后回復1024 送你一份技術課程大禮包!
海量技術實踐經驗,盡在云加社區!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/1790.html
摘要:假如我們底層的連接得到重用,這時候的情況會是這樣子很明顯,在獲取的請求中,減少了一次握手往返。在使用持久連接后,避免了一次握手往返總延遲減少為。其代價往往是不能充分利用網絡連接,造成服務器緩沖開銷,有可能導致客戶端更大的延遲。 歡迎大家前往騰訊云+社區,獲取更多騰訊海量技術實踐干貨哦~ 本文由騰訊IVWEB團隊 發表于云+社區專欄作者:yangchunwen HTTP協議是前端性能乃...
摘要:所做的最重要的事情,就是對成千上萬的網頁進行排序,所以它存在的意義是基于網頁的。確實有很多非常成功的產品,比如,,,但是它們其實都是收購來的。為什么呢因為要做到極簡主義,需要深刻思考用戶需求以及產品價值。 摘要: Chrome改變世界。 《JavaScript深入淺出》系列: JavaScript深入淺出第1課:箭頭函數中的this究竟是什么鬼? JavaScript深入淺出第2課:...
摘要:發布應用市場的平臺搶紅包工具紅包精靈開源啦掘金紅包精靈,如果喜歡,點個開源不易。作者將原素材文章進行了新內容的添加和重新排列,但是因為文章高效的代碼編寫技巧總結前端掘金本文總結了代碼編寫技巧,來提升你的和代碼。 收藏安卓開發中非常實用優秀的庫! 有圖有真相! - Android - 掘金本來是打算收藏工具類的,但轉念一想,已經有這么多優秀的庫了,就沒必要再去重復造輪子了,便歸納工作中比...
摘要:前端邏輯搞定之后,思考一下這個聊天室的交互是怎么實現的。在前端監聽一個事件,這個事件的觸發條件是成功和服務端建立連接。攜帶一個參數,即用戶的輸入。別人發送的消息現在就需要在前端建立一個響應服務端有新消息的監聽事件了。 一些廢話:) 最近在學校比較閑,終于有這么一塊時間可以自由支配了,所以內心還是十分的酸爽舒暢的。當然了,罪惡的事情也是有的,比如已經連續一周沒有吃早飯了,其實現在回頭想想...
摘要:前端邏輯搞定之后,思考一下這個聊天室的交互是怎么實現的。在前端監聽一個事件,這個事件的觸發條件是成功和服務端建立連接。攜帶一個參數,即用戶的輸入。別人發送的消息現在就需要在前端建立一個響應服務端有新消息的監聽事件了。 一些廢話:) 最近在學校比較閑,終于有這么一塊時間可以自由支配了,所以內心還是十分的酸爽舒暢的。當然了,罪惡的事情也是有的,比如已經連續一周沒有吃早飯了,其實現在回頭想想...
閱讀 2227·2021-11-15 11:39
閱讀 982·2021-09-26 09:55
閱讀 925·2021-09-04 16:48
閱讀 2831·2021-08-12 13:23
閱讀 919·2021-07-30 15:30
閱讀 2455·2019-08-29 14:16
閱讀 886·2019-08-26 10:15
閱讀 525·2019-08-23 18:40