1、HTTP 1.0
-
是一種無狀態(tài),無連接的應用層協(xié)議
- 規(guī)定瀏覽器和服務器保持短暫的鏈接。
- 瀏覽器每次請求都需要與服務器建立一個TCP連接,服務器處理完成以后立即斷開TCP連接(短連接),服務器不跟蹤也每個客戶單,也不記錄過去的請求(無狀態(tài))。
- 這種無狀態(tài)性可以借助cookie/session機制來做身份認證和狀態(tài)記錄。
- 存在的問題:
- 無法復用連接:每次發(fā)送請求/返回響應,都需要進行一次TCP連接,而TCP的連接釋放過程又是比較費事的。這種無連接的特性會使得網(wǎng)絡的利用率變低。
- 隊頭阻塞(head of line blocking):由于HTTP1.0規(guī)定下一個請求必須在前一個請求響應到達之后才能發(fā)送,假設前一個請求響應一直不到達,那么下一個請求就不發(fā)送,后面的請求就阻塞了。
Http 1.0
的致命缺點:
無法復用
TCP
連接和并行發(fā)送請求,這樣每次一個請求都需要三次握手,而且其實建立連接和釋放連接的這個過程是最耗時的,傳輸數(shù)據(jù)相反卻不那么耗時。不支持文件斷點續(xù)傳。
本地時間被修改導致響應頭
expires
的緩存機制失效的問題。
2、HTTP1.1
HTTP1.1繼承了HTTP1.0的簡單,克服了HTTP1.0性能上的問題。
HTTP1.1也是當前使用最為廣泛的HTTP協(xié)議
- 1. 長連接:HTTP1.1增加Connection字段,通過設置Keep-Alive保持HTTP連接不斷開,直到連接的某一段主動提出斷開連接的請求(Connection:Close)。避免每次客戶端與服務器請求都要重復建立釋放建立TCP連接。提高了網(wǎng)絡的利用率。如果客戶端想關閉HTTP連接,可以在請求頭中攜帶Connection:Close來告知服務器關閉請求。
-
2. 管道化:HTTP1.1支持請求管道化(pipelining)?;贖TTP1.1的長連接,使得請求管線化成為可能。 管線化使得請求能夠“并行”傳輸。但需要注意的是:服務器必須按照客戶端請求的先后順序依次回送相應的結果,以保證客戶端能夠區(qū)分出每次請求的響應內(nèi)容。
- 也就是說,HTTP管道化可以讓我們把先進先出隊列從客戶端(請求隊列)遷移到服務端(響應隊列),如果,客戶端同時發(fā)了兩個請求分別獲取html和css,假如說服務器的css資源先準備就緒,服務器也會先發(fā)送html,再發(fā)送css。 換句話來說,只有等到html響應的資源完全傳輸完畢后,css響應的資源才開始傳輸,不允許同時存在兩個并行的響應。
- 可見,HTTP1.1還是無法解決隊頭阻塞(head of line blocking)的問題,只是把先進先出隊列從客戶端(請求隊列)遷移到服務端(響應隊列)。
- 3. RANGE:bytes字段: 是HTTP/1.1新增內(nèi)容,斷點續(xù)傳,表示要求服務器從文件XXXX字節(jié)處開始傳送。
-
4. 真并行傳輸 — 瀏覽器優(yōu)化策略
- HTTP1.1支持管道化,但是服務器也必須進行逐個響應的送回,這個是很大的一個缺陷。實際上,現(xiàn)階段的瀏覽器廠商采取了另外一種做法,它允許我們打開多個TCP的會話,也就是說,其實是不同的TCP連接上的HTTP請求和相應,這也就是我們所熟悉的瀏覽器對同域下并行加載6~8個資源的限制。
-
5. 緩存處理 — 強緩存、協(xié)商緩存,啟發(fā)式緩存(新增)
- 此外,HTTP1.1還加入了緩存處理(強緩存和協(xié)商緩存),新的字段如cache-control,支持斷點傳輸,以及增加了Host字段(使得一個服務器能夠用來創(chuàng)建多個Web站點)
Http 1.1的致命缺點:
- 1.明文傳輸。
- 2.其實還是沒有解決無狀態(tài)連接的。
- 3.當有多個請求同時被掛起的時候 就會擁塞請求通道,導致后面請求無法發(fā)送(沒有真正的解決隊頭阻塞)。
- 4.臃腫的消息首部:HTTP/1.1能壓縮請求內(nèi)容,但是消息首部不能壓縮;在現(xiàn)今請求中,**消息首部占請求絕大部分(**甚至是全部)也較為常見。
我們也可以用
dns-prefetch和 preconnect tcp
來優(yōu)化~
<link rel="preconnect" href="//example.com" crossorigin>
<link rel="dns=prefetch" href="//example.com">
-
Tip
:webpack
可以做任何事情,這些都可以用插件實現(xiàn)
3、HTTP2.0
相較于HTTP1.1,HTTP2.0的主要優(yōu)點有:
- 采用二進制幀封裝
- 傳輸變成多路復用
- 流量控制算法優(yōu)化
- 服務器端推送
- 首部壓縮
- 優(yōu)先級
1、 二進制幀封裝 / 二進制分幀
HTTP1.x的解析是基于文本的,基于文本協(xié)議的格式解析存在天然缺陷,文本的表現(xiàn)形式有多樣性,要做到健壯性考慮的場景必然很多。
而HTTP2.0會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶?/strong>,然后采用二進制的格式進行編碼,HTTP1.x的頭部信息會被封裝到HEADER frame(單獨成幀,不再在后續(xù)數(shù)據(jù)傳輸中攜帶),而相應的RequestBody則封裝到DATAframe里面。
不改動HTTP的語義,使用二進制編碼,實現(xiàn)方便且健壯。
2、 多路復用 && 優(yōu)先級
所有的請求都是通過一個 TCP 連接并發(fā)完成。
HTTP/1.x 雖然通過 pipeline 也能并發(fā)請求,但是多個請求之間的響應會被阻塞的,所以 pipeline 至今也沒有被普及應用,而 HTTP/2 做到了真正的并發(fā)請求。
同時,流還支持優(yōu)先級和流量控制。當流并發(fā)時,就會涉及到流的優(yōu)先級和依賴。
即:HTTP2.0對于同一域名下所有請求都是基于流的,不管對于同一域名訪問多少文件,也只建立一路連接。優(yōu)先級高的流會被優(yōu)先發(fā)送和響應。圖片請求的優(yōu)先級要低于 CSS 和 SCRIPT,這個設計可以確保重要的東西可以被優(yōu)先加載完(相較HTTP1.1,響應不再死板的按照請求順序返回,而是根據(jù)流中請求數(shù)據(jù)的優(yōu)先級響應)。
3、 流量控制
TCP協(xié)議通過sliding window(滑動窗口)的算法來做流量控制。
發(fā)送方有個sending window,接收方有receive window。http2.0的flow control是類似receive window的做法,數(shù)據(jù)的接收方通過告知對方自己的flow window大小表明自己還能接收多少數(shù)據(jù)。
只有Data類型的frame才有flow control的功能。對于flow control,如果接收方在flow window為零的情況下依然更多的frame,則會返回block類型的frame,這種場景一般表明http2.0的部署出了問題。
4、 服務器端推送
服務端推送是一種在客戶端請求之前發(fā)送數(shù)據(jù)的機制??梢宰龅剑蛻舳说模┚彺妗?/p>
服務器端的推送,就是服務器可以對一個客戶端請求發(fā)送多個響應。
除了對最初請求的響應外,服務器還可以額外向客戶端推送資源,而無需客戶端明確地請求。 當瀏覽器請求一個html,服務器其實大概知道你是接下來要請求資源了,而不需要等待瀏覽器得到html后解析頁面再發(fā)送資源請求。
5、 首部壓縮
-
HTTP 2.0 在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發(fā)送的鍵-值對,對于相同的數(shù)據(jù),不再通過每次請求和響應發(fā)送;
通信期間幾乎不會改變的通用鍵-值對(用戶代理、可接受的媒體類型,等等)只需發(fā)送一次。事實上,如果請求中不包含首部(例如對同一資源的輪詢請求),那么 首部開銷就是零字節(jié)。此時所有首部都自動使用之前請求發(fā)送的首部。
-
如果首部發(fā)生變化了,那么只需要發(fā)送變化了數(shù)據(jù)在Headers幀里面,新增或修改的首部幀會被追加到“首部表”。首部表在 HTTP 2.0 的連接存續(xù)期內(nèi)始終存在,由客戶端和服務器共同漸進地更新 。
-
本質上是為了減少請求,通過多個js或css合并成一個文件,多張小圖片拼合成Sprite圖,可以讓多個HTTP請求減少為一個,減少額外的協(xié)議開銷,而提升性能。
當然,一個HTTP的請求的body太大也是不合理的,有個度。文件的合并也會犧牲模塊化和緩存粒度,可以把“穩(wěn)定”的代碼or 小圖 合并為一個文件or一張Sprite,讓其充分地緩存起來,從而區(qū)分開迭代快的文件。文章來源:http://www.zghlxwxcb.cn/news/detail-402129.html
HTTP/1.1并不支持 HTTP 首部壓縮,為此 SPDY 和 HTTP/2 應運而生, SPDY 使用的是通用的DEFLATE 算法,而 HTTP/2 則使用了專門為首部壓縮而設計的 HPACK 算法。文章來源地址http://www.zghlxwxcb.cn/news/detail-402129.html
到了這里,關于詳解HTTP1.0、1.1、2.0版本區(qū)別/優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章,希望大家以后多多支持TOY模板網(wǎng)!