http優化1 · 前端工程化指南

[TOC] ## 前言相信有不止一個人給你推薦過web優化中藥減少并簡化請求，比如使用圖片精靈，合并壓縮文件，腳本文件寫在dom末尾，那么今天我們從http這個角度去分析，去做一些有意義的探索。 ## http瀑布圖入門如果說你想了解下http的請求情況或者想優化頁面初始化的效率，那么http瀑布圖是你不可缺少的一個分析工具。如下圖所示：下面分別展示了一個頁面打開的所有請求以及一個資源請求的詳細情況。從下面的圖中你既能看到不同請求的請求順序，請求時間，也能看到資源是同步加載的，腳本會阻塞加載，另外渲染和js執行屬于不同的引擎負責，等等。在后面的文章中，我會分別介紹如何去分析這些圖，并根據這些圖去優化對應的部分。 ![](https://box.kancloud.cn/ba24ba04e2088903b82474358ebe7e19_1125x675.png) ## http協議的類型科普內容： ![](https://box.kancloud.cn/564f9fe6070274d7457575b768ab4e08_690x515.png) >物理層：以太網 · 調制解調器 · 電力線通信(PLC) · SONET/SDH · G.709 · 光導纖維 · 同軸電纜 · 雙絞線等數據鏈路層：Wi-Fi(IEEE 802.11) · WiMAX(IEEE 802.16) ·ATM · DTM · 令牌環 · 以太網 ·FDDI · 幀中繼 · GPRS · EVDO ·HSPA · HDLC · PPP · L2TP ·PPTP · ISDN·STP 等網絡層協議：IP (IPv4 · IPv6) · ICMP· ICMPv6·IGMP ·IS-IS · IPsec · ARP · RARP等傳輸層協議：TCP · UDP · TLS · DCCP · SCTP · RSVP · OSPF 等應用層協議：DHCP ·DNS · FTP · Gopher · HTTP· IMAP4 · IRC · NNTP · XMPP ·POP3 · SIP · SMTP ·SNMP · SSH ·TELNET · RPC · RTCP · RTP ·RTSP· SDP · SOAP · GTP · STUN · NTP· SSDP · BGP · RIP 等 * http的通信流程： ![](https://box.kancloud.cn/505f7e66d76e9cca3a3fbaa3b0a554be_307x199.png) * http的消息結構： ![](https://box.kancloud.cn/ff5d37e40e0dca70d7e3e6c0dcdca1d0_466x165.png) * http連接注意事項 HTTP是無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。 HTTP是媒體獨立的：這意味著，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。 HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。 * http版本 0.9 只接受get，過時； 1.0 大多數網站使用； 1.1 當前版本。持久連接被默認采用，并能很好地配合代理服務器工作。還支持以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。 2.0 符合spdy協議，二進制格式在協議的解析和優化擴展上帶來了跟多的優勢，對消息頭采用Hpack進行壓縮傳輸，能夠節省消息頭占用的網絡流量，異步連接多路復用，Server Push，服務器端能夠更快的把資源推送到客戶端，保持了與HTTP 1.1語義的向后兼容性 * http種類： **HTTP**：是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。 **HTTPS**：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL(ssl用戶安全認證)。 **cdn請求**:為什么有的文件用cdn加速之后就沒有寫協議類型，因為當前協議類型有可能是http or https不確定的，寫//會自動識別當前的頁面請求類型。 **data:image/png;base64**：為什么沒有協議類型，本身屬于符合RFC2397的Data URI scheme，不需要加載文件，知識一部分內容直接用于輸出，圖片是2進制的，所以一般需要轉換為64進制。除了這個之外，還有其他類型：比如：data:text/plain,<文本數據> ，data:text/css,<css代碼> ,data:image/x-icon;base64,base64編碼的icon圖片數據等，詳細文檔請站內搜索“Data URI scheme”。 ## http2 詳解 ### 多路復用在HTTP/2中，有兩個非常重要的概念：幀（frame）和流（stream）。 **1、幀（frame）** HTTP/2中數據傳輸的最小單位，因此幀不僅要細分表達HTTP/1.x中的各個部份，也優化了HTTP/1.x表達得不好的地方，同時還增加了HTTP/1.x表達不了的方式。每一幀都包含幾個字段，有length、type、flags、stream identifier、frame playload等，其中type代表幀的類型，在HTTP/2的標準中定義了10種不同的類型，包括上面所說的HEADERS frame和 DATA frame。此外還有 > PRIORITY（設置流的優先級） > RST_STREAM（終止流） > SETTINGS（設置此連接的參數） > PUSH_PROMISE（服務器推送） > PING（測量RTT） > GOAWAY（終止連接） > WINDOW_UPDATE（流量控制） > CONTINUATION（繼續傳輸頭部數據） **2、流（stream）** > “流”在HTTP/2中是一個邏輯上的概念，就是說在一個TCP連接上，我們可以向對方不斷發送一個個的消息，這里每一個消息看成是一幀，而每一幀有個stream identifier的字段標明這一幀屬于哪個“流”，然后在對方接收時，根據stream identifier拼接每個“流”的所有幀組成一整塊數據。我們把HTTP/1.x每個請求都當作一個“流”，那么請求化成多個流，請求響應數據切成多個幀，不同流中的幀交錯地發送給對方，這就是HTTP/2中的多路復用。 ![](https://box.kancloud.cn/e8e6fd7fc875e287ba007a0d9acbe8ab_640x185.png) 從上圖我們可以留意到：不同的流在交錯發送； HEADERS 幀在 DATA 幀前面；流的ID都是奇數，說明是由客戶端發起的，這是標準規定的，那么服務端發起的就是偶數了。多路復用讓HTTP連接變得很廉價，只需要創建一個新流即可，這不需要多少時間，而在HTTP/1.x時代卻要經歷三次握手時間或者隊首阻塞等問題。而且創建新流默認是無限制的，也就是可以無限制的并行請求下載。不過，HTTP/2還是提供了`SETTINGS_MAX_CONCURRENT_STREAMS` 字段在 SETTINGS 幀上設置，可以限制并發流數目，標準上建議不要低于100以保證性能。優化Web性能有一個常用的技術，就是圖片延遲加載，目的是除了節省流量外，還能避免圖片資源與其他重要的腳本資源競爭下載。 HTTP/2提供了流的優先級與依賴性這種機制，可用 HEADERS 幀或 PRIORITY 幀設置，不過協議并沒有提供如何處理優先級的具體算法，這可由服務器靈活應對。我用個例子來說明這個機制。 ~~~  <html> <body> <script src="a.js"></script> <img src="a.jpg"> <img src="b.jpg"> <link rel="stylesheet" type="text/css" href="style.css"> </body> </html> ~~~ 瀏覽器是邊下載邊解析的，文檔解析器首先遇到a.js，它就會去下載并且阻塞頁面，同時，資源探測器會繼續向下掃描，發現a.jpg、b.jpg和style.css并服務器發起請求。在沒有優先級機制時，a.jpg、b.jpg會跟重要的a.js、style.css競爭下載，但在HTTP/2中，瀏覽器可以給a.jpg、b.jpg設置較低的優先級，另外依賴關系為 ![](https://box.kancloud.cn/6d30ee2f3392aa9ea6f86395459e930e_434x153.png) 這樣服務器根據優先級信息，首先吐出a.js、style.css，再吐出圖片，因此頁面在沒有圖片的情況下提前進入可交互狀態。例子所說的是在瀏覽器層面上harcode的一個優先級策略，再比如上文提到的prefetch就可以給一個更低的優先級。在代碼層面上，也許之后會提供一些控制優先級的特性，類似于目前只有IE支持的lazyload attribute。 ## http請求狀態碼 >HTTP狀態碼（HTTP Status Code）是用以表示網頁服務器HTTP響應狀態的3位數字代碼。它由 RFC 2616 規范定義的，并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等規范擴展。http常見的狀態碼以及代表含義作為前端要清楚，并且正確的運用。以下只提供了部分常見的，如果大家想了解更多可以參考以下在線文檔: [百度百科](http://baike.baidu.com/link?url=5Qa0aFGQ4ZFOS0Bzj4kXZ_p9xPMw8ZV55XUTbx0UhZxHz35wDHaTA2IEV4gXykzqLe5Iwo-m8_DDF_vQyG0PRQnniO06nQ2lySObfBWcbB891L-AIkoD8dvWM2_JvNm3) / [菜鳥教程](http://www.runoob.com/http/http-status-codes.html) ![](https://box.kancloud.cn/e1cbf9af1b069680db8ef452c2f52343_582x370.png) ### 1. 1xx 信息正在處理 ### 2. 2xx 請求成功 |狀態碼 | 描述 | | ------------- | ------------- | |200|ok 請求被成功處理 | |201|請求成功，并且服務器創建了新的資源 | |202|服務器已經接受請求，但還沒有處理 | |203|服務器已經處理了請求，但是信息來自于另一個來源 | |204|請求成功，但是服務器沒有響應體 | |205|處理了請求，但沒有返回內容，要求請求者重置內容再次請求 | |206|部分內容，該狀態碼表示客戶端進行了范圍請求，而服務器成功執行了這部分的GET請求 | ### 3. 3xx 重定向狀態碼 |狀態碼 | 描述 | |------------- |------------- | |301|永久性重定向 | |302|臨時性重定向 | |304|未被修改，不會返回新內容 | ### 4. 4xx 代表請求錯誤 |狀態碼 | 描述 | |------------- |------------- | |401|未被授權 | |403|服務器拒絕請求 | |404|頁面或者文件找不到 | |405|禁用請求中的指定方法 | |408|請求超時 | |414|請求uri過長 | |417|請求參數不符合標準 | ### 5. 5xx 服務器錯誤 | 狀態碼 | 描述 | | --- | --- | |500|服務器內部錯誤 | |501|服務器不具備響應此需要的功能 | |502|錯誤網關 | |503|服務不可用，比如系統維護或者升級等 | |504|網關超時 | |505|http協議版本不支持 | ## http請求類型共8種請求類型，常見的是get和post請求，所有的這些類型都參與js-restful的設計。根據HTTP標準，HTTP請求可以使用多種請求方法。 HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。 |狀態碼 | 描述 | |------------- |------------- | |GET|請求指定的頁面信息，并返回實體主體 | |HEAD|類似于get請求，只不過返回的響應中沒有具體的內容，用于獲取報頭 | |POST|向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改 | |DELETE|請求服務器刪除指定的頁面 | |CONNECT|HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器 | |OPTIONS|允許客戶端查看服務器的性能 | |TRACE|回顯服務器收到的請求，主要用于測試或診斷 | ## get與post方式區別首先要了解清楚的一點是：我們大多數的請求是get方式的，少數表單或者數據操作是post的，ajax異步多是post.選擇上：如果你希望url可見，可被分享抓取，可手動修改參數訪問，希望被緩存，參數較短，主要是受限于url長度，那么考慮用get。需要注意的一點是：需要上傳文件的要用post. >1.GET被瀏覽器強制支持（POST是可選的，不過一般都支持） 2.GET是冪等的，POST非冪等(冪等每次請求不會對系統造成影響，而post有可能會更新數據) 3.GET可以被瀏覽器緩存，POST不可以（比如訪問的歷史記錄，請求的歷史文件，比如樣式文件等） 4.GET請求是『安全』的，POST不安全(這里的安全還是指的不會更新數據) 5.POST相對來說比GET要『安全』一些(操作安全，參數等不可見) 6.參數大小（理想和現實）