HTTP是應(yīng)用層協(xié)議,是基于TCP底層協(xié)議而來(lái)硕舆。
TCP的機(jī)制限定秽荞,每建立一個(gè)連接需要3次握手,斷開(kāi)連接則需要4次揮手抚官。
HTTP協(xié)議采用“請(qǐng)求-應(yīng)答”模式扬跋,HTTP1.0下,HTTP1.1非Keep-Alive模式下凌节,每個(gè)請(qǐng)求都要新建一個(gè)連接钦听,完成之后立即斷開(kāi)連接。如果有新的請(qǐng)求刊咳,則要重新創(chuàng)建請(qǐng)求連接(HTTP協(xié)議為無(wú)連接的協(xié)議)彪见。
這樣不免造成了網(wǎng)絡(luò)傳輸數(shù)據(jù)一定的延遲,1999年推出HTTP1.1娱挨,雖然可以通過(guò)設(shè)置延遲時(shí)間余指,讓連接延遲關(guān)閉。但仍然有線頭阻塞跷坝,max-connection最大連接限制了并行請(qǐng)求數(shù)量等痛點(diǎn)酵镜,難以應(yīng)對(duì)日益增長(zhǎng)的大數(shù)據(jù)實(shí)時(shí)傳輸。
新一代HTTP2.0協(xié)議應(yīng)運(yùn)而生柴钻,提高HTTP應(yīng)對(duì)高并發(fā)場(chǎng)景下的數(shù)據(jù)傳輸能力淮韭。
「 HTTP1.1」
Pipelining管道化
提出管道化方案解決連接延遲贴届,服務(wù)端可設(shè)置Keep-Alive來(lái)讓連接延遲關(guān)閉時(shí)間靠粪,但因?yàn)闉g覽器自身的Max-Connection最大連接限制蜡吧,同一個(gè)域名 (host) 下的請(qǐng)求連接限制(同域下谷歌瀏覽器是一次限制最多6個(gè)連接),只能通過(guò)多開(kāi)域名來(lái)實(shí)現(xiàn)占键,這也就是我們的靜態(tài)資源選擇放到CDN上或其它域名下昔善,來(lái)提高資源加載速度。
pipelining方案需要前后端支持畔乙,但絕大部分的HTTP代理器對(duì)pipelining的支持并不友好君仆。
只支持GET/HEAD
pipelining只支持GET/HEAD方式傳送數(shù)據(jù),不支持POST等其它方式傳輸牲距。
頭部信息冗余
HTTP是無(wú)狀態(tài)的返咱,客戶端/服務(wù)端只能通過(guò)HEAD的數(shù)據(jù)維護(hù)獲取狀態(tài)信息,這樣就造成每次連接請(qǐng)求時(shí)都會(huì)攜帶大量冗余的頭部信息牍鞠,頭部信息包括COOKIE信息等咖摹。
超文本協(xié)議
HTTP1.X是超文本協(xié)議傳輸。超文本協(xié)議傳輸难述,發(fā)送請(qǐng)求時(shí)會(huì)找出數(shù)據(jù)的開(kāi)頭和結(jié)尾幀的位置楞艾,并去除多余空格,選擇最優(yōu)方式傳輸龄广。如果使用了HTTPS,那么還會(huì)對(duì)數(shù)據(jù)進(jìn)行加密處理蕴侧,一定程度上會(huì)造成傳輸速度上的損耗择同。
線頭阻塞
pipelining通過(guò)延遲連接關(guān)閉的方案,雖然可同時(shí)發(fā)起對(duì)服務(wù)端的多個(gè)請(qǐng)求净宵,但服務(wù)端的response依舊遵循FIFO(first in first out)規(guī)則 依次返回敲才。
舉個(gè)例子客戶端發(fā)送了1、2择葡、3紧武、4四個(gè)請(qǐng)求,如果1沒(méi)返回給客戶端敏储,那么2阻星,3,4也不會(huì)返回已添。這就是所謂的線頭阻塞妥箕。高并發(fā)高延遲的場(chǎng)景下阻塞明顯。
HTTP1.X傳輸優(yōu)化方法
- 多個(gè)資源合并成一個(gè)請(qǐng)求連接更舞,如前端Spriting雪碧圖畦幢,JS/CSS壓縮成一個(gè)文件等
- Inlining內(nèi)聯(lián)的方式,采用inline css/inline js等并入html中缆蝉,減少對(duì)css/js文件的請(qǐng)求
- CDN資源多域名轉(zhuǎn)發(fā)宇葱,靜態(tài)資源分布存儲(chǔ)在多個(gè)域下瘦真。
以上三種三種方法雖然能使HTTP1.X協(xié)議傳輸速度提高,但也有對(duì)應(yīng)的不足黍瞧。
- 如雪碧圖诸尽,將多個(gè)小圖合并成一張大圖,降低多張小圖請(qǐng)求的高延遲雷逆,但是如果我只想要兩個(gè)icon小圖弦讽,卻需要加載一整張大圖,就會(huì)造成資源冗余膀哲。合并的JS/CSS文件也有類似的問(wèn)題往产。
- 內(nèi)聯(lián)的方式,會(huì)讓我們的代碼變得難以維護(hù)某宪,讓html文件變得更大仿村,代碼混合嚴(yán)重。
- 多域名下可緩解Max-Connection兴喂,但不同域會(huì)讓Cookie信息無(wú)法彼此共享蔼囊。
了解完HTTP1.1的痛點(diǎn),接下來(lái)就是我們新一代的HTTP協(xié)議HTTP2.0
「 HTTP2.0」
前身SPDY
SPDY是2012年谷歌推出的是基于SSL/TLS的傳輸協(xié)議衣迷,SPDY有降低延遲畏鼓,多路復(fù)用,頭部壓縮壶谒,服務(wù)端推送等特點(diǎn)云矫,這些特點(diǎn)也稱為了后續(xù)HTTP2.0的功能基石,HTTP2.0是SPDY/3 draft的優(yōu)化版汗菜。
HTTP2.0 與 SPDY的區(qū)別:
- HTTP2.0 頭部壓縮采用HPACK让禀, 而SPDY采用DELEFT。
- HTTP2.0 理論上支持明文HTTP傳輸陨界,而SPDY強(qiáng)制使用HTTPS巡揍。
多路復(fù)用
(一個(gè)域只要一個(gè)TCP連接)實(shí)現(xiàn)真正的并發(fā)請(qǐng)求,降低延時(shí)菌瘪,提高了帶寬的利用率腮敌。
頭部壓縮
客戶端/服務(wù)端進(jìn)行漸進(jìn)更新維護(hù),采用HPACK壓縮麻车,節(jié)省了報(bào)文頭占用流量缀皱。
- 相同的頭部信息不會(huì)通過(guò)請(qǐng)求發(fā)送,延用之前請(qǐng)求攜帶的頭部信息动猬。
- 新增/修改的頭部信息會(huì)被加入到HEAD中啤斗,兩端漸進(jìn)更新。
兩端會(huì)共同維護(hù)一個(gè)head list赁咙,每次請(qǐng)求時(shí)都會(huì)進(jìn)行檢查钮莲。
該list包括:
- static (既定的頭部信息)
- dynamic (自定義的頭部信息)
請(qǐng)求優(yōu)先級(jí)
每個(gè)流都有自己的優(yōu)先級(jí)別免钻,客戶端可指定優(yōu)先級(jí)。并可以做流量控制崔拥。因?yàn)镠TTP2.0的傳世允許請(qǐng)求并發(fā)极舔,但是應(yīng)用場(chǎng)景中我們要處理一些主要文件的優(yōu)先級(jí)權(quán)重,以及資源模塊依賴等链瓦。所以我們可通過(guò)設(shè)置優(yōu)先級(jí)來(lái)提高主要文件的權(quán)重拆魏,使其優(yōu)先加載請(qǐng)求。
服務(wù)端推送
請(qǐng)求不是來(lái)自客戶端“明確”的請(qǐng)求慈俯,是從服務(wù)端PUSH_PROMISE幀中提供渤刃。例如我們加載index.html, 我們可能還需要index.js, index.css等文件。傳統(tǒng)的請(qǐng)求只有當(dāng)拿到index.html贴膘,解析html中對(duì)index.js/index.css的引入才會(huì)再請(qǐng)求資源加載卖子,但是通過(guò)服務(wù)端數(shù)據(jù),可以提前將資源推送給客戶端刑峡,這樣客戶端要用到的時(shí)候直接調(diào)用即可洋闽,不用再發(fā)送請(qǐng)求。
- push的資源能緩存在瀏覽器中
- 不同的網(wǎng)頁(yè)能使用該緩存突梦,不用重新發(fā)起
- push的資源通過(guò)multiplexed進(jìn)行傳輸
- push的資源能夠進(jìn)行priority標(biāo)識(shí)
- client有權(quán)取消push資源的加載
- push的資源必須同域
二進(jìn)制協(xié)議
HTTP2.0 傳輸協(xié)議采用二進(jìn)制協(xié)議诫舅,區(qū)別與HTTP1.X的超文本協(xié)議。更易于幀宫患,數(shù)據(jù)包的發(fā)送接收骚勘。HTTP2.0是運(yùn)行在TCP連接上的應(yīng)用層協(xié)議,接受服務(wù)器或發(fā)送請(qǐng)求時(shí)撮奏,會(huì)自動(dòng)將頭部信息/request body分成HEAD幀和DATA幀。
客戶端/服務(wù)端發(fā)送/接收數(shù)據(jù)時(shí)当宴,會(huì)將數(shù)據(jù)打散亂序發(fā)送畜吊,接收數(shù)據(jù)時(shí)接收一端再通過(guò)streamID標(biāo)識(shí)來(lái)將數(shù)據(jù)合并。
HTTP2.0環(huán)境要求
HTTP2.0理論上支持明文HTTP傳輸户矢,但因?yàn)槠淝吧鞸PDY是在TLS上玲献,他們的主人Google 和 Firefox 都支持TLS架構(gòu),所以需要搭建HTTP2.0 + TLS成了標(biāo)準(zhǔn)梯浪。
- Nginx > 1.10
- OpenSSL > 1.0.2
- CA證書(shū)
參考文檔
- HTTP協(xié)議頭部與Keep-Alive模式詳解
- HTTP,HTTP2.0,SPDY,HTTPS你應(yīng)該知道的一些事
- 前端應(yīng)該了解的HTTP2
- 一文讀懂 HTTP/2 特性
作者:以樂(lè)之名
本文原創(chuàng)捌年,有不當(dāng)?shù)牡胤綒g迎指出。轉(zhuǎn)載請(qǐng)指明出處挂洛。