現(xiàn)在瀏覽器里面很大一部分網(wǎng)頁(yè)還在使用HTTP1.1作為主要的網(wǎng)絡(luò)通信協(xié)議。 但,這傻逼協(xié)議是1999年弄出來(lái)的. 距今已經(jīng)有xx年了, 這些年里,美國(guó)的IETF 覺(jué)得這樣不行.我得出來(lái)拯救世界了, 在Chrome的倡導(dǎo)下, 借用Chrome的SPDY 來(lái)做為HTTP2的前身,即, HTTP2 是SPDY/3 draft的優(yōu)優(yōu)化版.
那,HTTP2 為什么要出現(xiàn),又解決了HTTP1.1不能解決的什么事情呢?
簡(jiǎn)而言之就是
H2是一個(gè)二進(jìn)制協(xié)議而,H1是超文本協(xié)議.傳輸?shù)膬?nèi)容都不是一樣的
H2遵循多路復(fù)用即,代替同一host下的內(nèi)容,只建立一次連接. H1不是(傻逼)
H2可以使用HPACK進(jìn)行頭部的壓縮,H1則不論什么請(qǐng)求都會(huì)發(fā)送
H2允許服務(wù)器,預(yù)先將網(wǎng)頁(yè)所需要的資源PUSH到瀏覽器的內(nèi)存當(dāng)中.
接下來(lái),我們來(lái)看看,H2到底有哪些具體的feature
HTTP2的features首先介紹一下,HTTP2為什么是一種二進(jìn)制的協(xié)議.
HTTP2 binary說(shuō)道H2的二進(jìn)制,首先得介紹一下H1的超文本協(xié)議.HTTP1.1每次在發(fā)送請(qǐng)求時(shí),都需要找出 開(kāi)頭和結(jié)尾的每一幀的位置, 并且,在寫(xiě)入的時(shí)候,還需要?jiǎng)h除多余的空格,以及選擇最優(yōu)的方式寫(xiě)入, 并且如果是HTTP+TLS的話,那性能損耗就比較呵呵了,因?yàn)門(mén)LS本身的握手協(xié)議,以及加密的方式,在一定程度上會(huì)對(duì)文本信息的內(nèi)容進(jìn)行處理等等. 這些無(wú)疑都給HTTP1.1的速度造成了極大的影響.所以,HTTP2 不采用這種方式來(lái),而,干脆直接使用二進(jìn)制. 那,H2是怎樣實(shí)現(xiàn),二進(jìn)制傳輸呢?
這里,借Grigorik在velocity 會(huì)議上的PPT,來(lái)看一看.
沒(méi)錯(cuò),H2是安放在應(yīng)用層的協(xié)議,在接受服務(wù)器發(fā)送的來(lái)的請(qǐng)求時(shí),自動(dòng)將Header 和 Body部分區(qū)分開(kāi).
HTTP2 多路復(fù)用在H1中,當(dāng)發(fā)送多個(gè)請(qǐng)求時(shí), 會(huì)有一種head-of-line blocking現(xiàn)象. 也就是我們經(jīng)??匆?jiàn)的瀑布流式的加載方式,這樣的加載方式,只能讓資源按照順序一個(gè)一個(gè)的加載。 有可能造成如下圖的現(xiàn)象:
前面一個(gè)資源內(nèi)容超級(jí)多,并且都是一次性加載完,即使后面有更重要的資源,也需要進(jìn)行等待.
但在,H2中就沒(méi)有這樣的限制了. 他直接會(huì)將不同的資源,分拆為細(xì)小的二進(jìn)制幀來(lái)進(jìn)行傳輸.
當(dāng)然,你也沒(méi)必要擔(dān)心,每一次是否會(huì)傳輸錯(cuò)誤,因?yàn)閷?shí)際上每一幀里面的格式為:
在傳輸?shù)拿恳粠锩?會(huì)有如下屬性來(lái)進(jìn)行表示Length, Type, Flags, Stream Identifier, and frame payload.
only one Tcp connection這個(gè)特性是建立在二進(jìn)制傳輸?shù)亩嗦窂?fù)用(multiplexed)的機(jī)制上的. 簡(jiǎn)而言之就是一句話:
一個(gè)域只需要一個(gè)TCP連接
因?yàn)樵贖1的時(shí)候,雖然有Connection:keep-alive的特性可以讓你的TCP斷開(kāi)的稍微晚一點(diǎn). 但這并沒(méi)有什么x用,因?yàn)?H1天生自帶max-connections數(shù), 沒(méi)辦法, 為了加快更多的資源,你只有多開(kāi)幾個(gè)域名來(lái)進(jìn)行連接,這樣一方面是域名成本的花銷(xiāo),還有一方面是維護(hù)量太大。這就是著名的 Domain Sharding. 不過(guò),這一切在H2中,都變得特別的SB。。。以為,H2本身就可以實(shí)現(xiàn),一個(gè)TCP, 資源無(wú)上限的特點(diǎn).
最顯而易見(jiàn)的特性就是: akamai HTTP2的demo.
前面那一坨綠色的就是HTTP1.1寫(xiě)一下的資源請(qǐng)求,可以看到最多有8個(gè),在紅線后面是HTTP2請(qǐng)求的資源數(shù).最多(沒(méi)有最多) 就一個(gè)... 這足以體現(xiàn)HTTP1.1的傻逼特性了。。。
那他實(shí)際上,是怎么做到在一次TCP中,進(jìn)行多個(gè)資源的請(qǐng)求呢?
參考NewCircle Training 講解的multiplexed video.
我們以前發(fā)送HTTP1.1的情況是:
在HTTP2中,我們請(qǐng)求的方式改變?yōu)?
有同學(xué)可能會(huì)問(wèn): 他這樣將多個(gè)內(nèi)容放在一個(gè)stream里面進(jìn)行傳輸,是怎樣保證資源的有序性呢?
問(wèn)得好!
HTTP2這個(gè)特性確實(shí)是建立在stream基礎(chǔ)上的, 上面已經(jīng)提到過(guò),HTTP2將資源劃分為最小的frame進(jìn)行傳輸,這樣可以達(dá)到interleave和priority的效果. 每一個(gè)frame里面如下圖所示:
為了保證order和priority的feature, 所以,HTTP2在每次發(fā)送時(shí),需要額外附帶上一些信息:
a unique stream ID
different priority
當(dāng)然除了這些基本的優(yōu)化外,HTTP2在HEADER方面的優(yōu)化也是下血本的.
HEADER CompressionHEADER的優(yōu)化,主要還是由于HTTP1.1的頭部機(jī)制--在每次請(qǐng)求時(shí),都需要將一大堆頭部帶上,甚至帶上cookie這灰常大的內(nèi)容. 所以,SPDY 覺(jué)得這樣不行,然后就是用了GZIP的壓縮方式,但這樣很容易的就被破解并且劫持,導(dǎo)致安全性問(wèn)題. HTTP2吸取了這次教訓(xùn),決定自己開(kāi)發(fā)一套優(yōu)化方案,即,因?yàn)轭^部的更替不是很頻繁,那我就在Server端做個(gè)緩存唄,在你這次連接有效的時(shí)間里面, client就用重復(fù)的發(fā)送請(qǐng)求頭了. 這就是HTTP2的HPACK壓縮方式.
HPACK壓縮會(huì)經(jīng)過(guò)兩步:
傳輸?shù)膙alue,會(huì)經(jīng)過(guò)Huffman coding. 一遍來(lái)節(jié)省資源.
為了server和client同步, 兩邊都需要保留一份Header list, 并且,每次發(fā)送請(qǐng)求時(shí),都會(huì)檢查更新
ok, 那這樣就有一個(gè)問(wèn)題, 第一次的請(qǐng)求,肯定是最慢的.因?yàn)樗械膌ist都需要進(jìn)行一份初始化操作. 但這是真沒(méi)辦法。。。 如果你靠猜Header的方式進(jìn)行發(fā)送的話,就有可能造成相應(yīng)錯(cuò)誤的情況. 我們?cè)诰唧w細(xì)分一下list, 實(shí)際上,每一個(gè)list里面還分為static list 和 dynamic list. 兩者的區(qū)別具體就是:
static: 主要用來(lái)存儲(chǔ)common header. 比如 method,path等
dynamic: 主要用來(lái)存儲(chǔ)自定義的協(xié)議頭. 比如: custom-name,custom-method等
整個(gè)流程,就可以用下圖來(lái)進(jìn)行表述:
可以看到,req/res的Header都會(huì)存在同一份表里面,這樣做可能有點(diǎn)傷內(nèi)存,不過(guò),速度上還是非常棒的。
這里,還有幾個(gè)額外的點(diǎn)需要提及一下:
所有頭的協(xié)議在HTTP2中都沒(méi)有發(fā)生改變, 緩存還是 cache-control, etag,last-modifier
response Header 全部是小寫(xiě).比如 server,status.
request Header 也是全部是小寫(xiě),不過(guò)有幾個(gè)特殊情況. :method, :scheme, :authority, and :path這幾個(gè)基本的頭前面需要:作為pseudo-header fields.
HTTP2 priority前面說(shuō)過(guò)了,HTTP2的每一幀上帶有一定的相關(guān)信息,比如說(shuō)權(quán)重--priority. 另外還有一個(gè)叫做依賴--dependence. 即, 假如某個(gè)client想要請(qǐng)求 index.html的資源,那么server會(huì)一并返回index.js和index.css的資源回去. 減少client發(fā)送更多的請(qǐng)求,相當(dāng)于一種Server Push的技術(shù),和現(xiàn)在的SSE挺像的.
想要實(shí)現(xiàn)這個(gè)feature,有兩個(gè)基本的標(biāo)準(zhǔn):
每個(gè)stream需要有一個(gè)1~256的數(shù)字來(lái)表示權(quán)重
每個(gè)stream都應(yīng)該清晰的標(biāo)明他的依賴有哪些
實(shí)際的一個(gè)圖就是這樣:
我們就按照上圖的情況來(lái)說(shuō)明吧. 如果一個(gè)C資源依賴于D資源,那么D則作為C的父節(jié)點(diǎn). 然后按照這樣的順序繼續(xù)排下去.
如果存在在一個(gè)根節(jié)點(diǎn)下面存在兩個(gè)節(jié)點(diǎn),比如第一個(gè)A,B。 那應(yīng)該怎么分呢? 這時(shí)候,就用到上文提到的priority. 主要A和B上面的數(shù)字. A-12,B-4. 將網(wǎng)絡(luò)資源--實(shí)際上就是帶寬和CPU,化成一塊蛋糕,那么,在此時(shí),A可以分到3/4的資源,而B(niǎo)只能分到1/4的資源. 分配 ( allocation ) 好了之后,則便返回?cái)?shù)據(jù).( Ps: 在HTTP2中,分?jǐn)?shù)不分?jǐn)?shù)這并不重要,因?yàn)镠TTP2傳的是二進(jìn)制,所以,資源不完整是肯定的.只是說(shuō),那些文件傳的快一些.)
我們這里就按照第三個(gè)圖來(lái)進(jìn)行解釋一下吧:
首先D占用100%的資源進(jìn)行發(fā)送
D發(fā)送完了C同樣占用100%的資源進(jìn)行發(fā)送
這里,由于A占3/4而B(niǎo)只占1/4所以,資源按照權(quán)重進(jìn)行分配,然后繼續(xù)發(fā)送文件直到結(jié)束
HTTP2 Server PUSH這個(gè)機(jī)制算是 HTTP2 第二大 feature , 即, one-to-many 的機(jī)制去請(qǐng)求資源.因?yàn)榭紤]到以前,前端請(qǐng)求資源是通過(guò) document 的解析來(lái)實(shí)現(xiàn)資源的 fetch . 這種方式有點(diǎn)傻逼... 就是,我知道這個(gè)資源是需要加載的,但是我不能一開(kāi)始在一次請(qǐng)求中發(fā)給你,我需要等你要,我才給. 這樣,就造成了一種溝通上的麻煩.所以, HTTP2 為了解決這個(gè) bug , 決定開(kāi)發(fā)出一套,可以實(shí)現(xiàn) Server Push 資源的機(jī)制.
這里,我們之請(qǐng)求了 page.html ,但實(shí)際上通過(guò) push promise. server 自動(dòng) push 給我們了 script.js 和 style.css 兩個(gè)文件. 這樣就省去的兩個(gè) request 的開(kāi)銷(xiāo).
這種方式,也就是我們經(jīng)??吹降?inlining css 和 inlining script. 不過(guò), 使用 HTTP2 這種機(jī)制的話,有一下幾個(gè)優(yōu)于 inlining 的特點(diǎn):
push 的資源能夠緩存在瀏覽器中
不同的網(wǎng)頁(yè)能夠使用該緩存,而不用重新發(fā)起
push 的資源是通過(guò) multiplexed 進(jìn)行傳輸?shù)?/p>
push 的資源能夠進(jìn)行 priority 標(biāo)識(shí)
client 有權(quán)取消push 資源的加載
push 的資源必須同域
上面具體的介紹了,關(guān)于HTTP2具體的feature. 可以說(shuō),上面都是一些理論上的東西,沒(méi)有涉及到一些具體的實(shí)操. 不過(guò),一旦你深入過(guò)后,你就會(huì)發(fā)現(xiàn),實(shí)操都是在理論相對(duì)完善的時(shí)候才做的. 都是一些工程化上的內(nèi)容, 記一下就ok了. 所以,這里,我們繼續(xù)深入的看一下具體的HTTP2的協(xié)議--frame的內(nèi)容
HTTP2 frame 內(nèi)容先看一張圖吧:
這和上面那張圖的內(nèi)容一樣,只是更加清楚了。HTTP2 就是憑借他來(lái)進(jìn)行所有的信息交流的,地位差不多和TCP的 frame內(nèi)容一樣的. HTTP2通過(guò)設(shè)定了length,type,Flags,R,Stream Identifier來(lái)標(biāo)識(shí)一個(gè)frame. 這些一共占用了9B的大小. 具體的為:
用24-bit 的大小來(lái)表示 Length --該 frame 承載數(shù)據(jù)量的多少, 最多可以放2^24B (~16MB) 大小. 但在具體實(shí)踐中,一般的上線設(shè)置為 16KB。 當(dāng)然,你也可以手動(dòng)進(jìn)行修改.不過(guò),這樣就不能體現(xiàn)小文件,流式傳輸?shù)奶攸c(diǎn)
8-bit 的 type字段 用來(lái)表示該frame的類(lèi)型
8-bit 的 Flags 字段用來(lái)表明,該次 frame 包括哪些 type
1-bit 的 R 就是個(gè)保留字段,永遠(yuǎn)設(shè)置為0. 實(shí)際 沒(méi)啥用
31-bit 的 identifier 來(lái)表明該stream的unique ID.很有用,該 flag 就是用來(lái)確保有序性的 flag.
根據(jù) HTTP2 官方的解釋說(shuō), 俺這樣的安排其實(shí)很有深意的,你知道我為什么會(huì)把Length放在開(kāi)頭嗎? 就是為了讓 parser 解析的更快, 因?yàn)楫?dāng) parser 開(kāi)始解析時(shí), 首先就知道了,你這次會(huì)傳多大的 frame, 并且也知道了你的 type , 那么其他的我就把該 frame 分給特定的引擎進(jìn)行解析就可以了. 然后我就 skip 一下,調(diào)到一下一個(gè) frame 繼續(xù)解析. 然后, 完成最終的數(shù)據(jù)接受.
既然, 不同的 type 能夠被不同的引擎所解析,那么 type一共有多少種呢?
懶得數(shù)了...就直接說(shuō)吧.(從上到下 重要性降低哈~)
DATA: 相當(dāng)于 message body內(nèi)容. 即, 返回的響應(yīng)體內(nèi)容
HEADERS: 就是 相應(yīng)頭唄...
PRIORITY: 和前面內(nèi)容提到的 priority 一樣, 用來(lái)標(biāo)識(shí)該次 frame 的優(yōu)先順序.
RST_STREAM: 用來(lái)結(jié)束該資源的 signal
PUSH_PROMISE: 這個(gè)就比較重要了. 這個(gè)上文所說(shuō)的 server PUSH 有很大的關(guān)系. 該是用來(lái)設(shè)置 server 自己發(fā)送的相關(guān)資源的 flag.
SETTINGS: 用來(lái)設(shè)置 client 和 server 之間 connection 的 相關(guān)配置
GOAWAY : 用來(lái)告訴 server , 停止發(fā)送相關(guān)資源
CONTINUATION: 和 GOWAY 相反,繼續(xù)發(fā)送相關(guān)資源
WINDOW_UPDATE: 使用 flow control 對(duì)流進(jìn)行控制.
HTTP2 傳輸過(guò)程HTTP2 同樣是建立在 TCP 連接上的, 他同樣也需要發(fā)送請(qǐng)求,并且獲得響應(yīng). 那他第一次發(fā)送的內(nèi)容到底是什么呢?
是資源請(qǐng)求嗎? HTML? JS ? CSS ?
actually, No~
HTTP2 在第一次請(qǐng)求的過(guò)程當(dāng)中,發(fā)送的內(nèi)容實(shí)際是 HEADERS,因?yàn)樾枰趦啥私⒁粋€(gè) virtually list 來(lái)存儲(chǔ)頭部,進(jìn)行HPACK 壓縮. 如下圖:
請(qǐng)仔細(xì)查看他的 Type 可以發(fā)現(xiàn),就是一個(gè) HEADERS。 這也就是上面所說(shuō)的存儲(chǔ)兩個(gè)不同的 header table -- static table && dynamic table.
另外, 還有一個(gè)點(diǎn)需要補(bǔ)充一下,就是, client 和 server 為了防止 stream ID 的重復(fù), 做了一個(gè)規(guī)定: client-initiated stream 只能為奇數(shù) stream-ID, 而 server-initiated stream 只能為偶數(shù)的 stream-ID.
HTTP2 實(shí)踐過(guò)程首先一個(gè)協(xié)議的出現(xiàn), 必定是 >=2 之間的溝通. 那針對(duì)于 HTTP2 就是 server 和 browser 之間的通信協(xié)議. 所以, 這就要求, HTTP2 的成功實(shí)踐, 不僅僅 server 支持, 你的瀏覽器也必須支持才行. 不過(guò),就目前來(lái)說(shuō), 已經(jīng)很不錯(cuò)了: can i use
在 Server 端, 支持 http2 其實(shí),要求也很簡(jiǎn)單:
nginx 版本 >1.10
openssl >1.0.2h 即可.
有一個(gè)自己的CA證書(shū).
so, 我們先從 CA 證書(shū)說(shuō)起, 這里,先安利一下各大云平臺(tái), 只要你在他那買(mǎi)了一臺(tái)服務(wù)器, 他那自動(dòng)回給你提供免費(fèi)而且正規(guī)的 CA 證書(shū), 我的證書(shū)就是在騰訊云送的. 一年換一次即可. 這里,我就按 TX(騰訊) 上來(lái)說(shuō). 當(dāng)你申請(qǐng)成功時(shí), 他會(huì)給你一個(gè) zip 文件. 解壓之后,會(huì)得到兩個(gè)文件:
證書(shū)文件: 1_www.domain.com_cert.crt
私鑰文件: 2_www.domain.com.key
這個(gè)兩個(gè)文件先放著, 后面有用.
對(duì)于, nginx 和 openssl 來(lái)說(shuō). 一般 server 自帶的版本都是比較低的, 所以, 這里我們采取手動(dòng)編譯的方式.
# 假設(shè)當(dāng)前目錄在 /usr/local/src // 下載 1.1.0 openssl wget -O openssl.tar.gz -c https://www.openssl.org/source/openssl-1.1.0.tar.gz // 解壓 tar zxf openssl.tar.gz // 改名 mv openssl-1.1.0/ openssl // 下載 nginx 1.11.4的源碼 wget -c https://nginx.org/download/nginx-1.11.4.tar.gz tar zxf nginx-1.11.4.tar.gz cd nginx-1.11.4/ // 設(shè)置編譯過(guò)后文件的路徑和啟用的模塊 ./configure --prefix=/usr/local/nginx --conf-path=/etc/nginx/nginx.conf --with-openssl=../openssl --with-http_v2_module --with-http_ssl_module --with-http_gzip_static_module // 開(kāi)始編譯 make && sudo make install
這里, 我直接整理到 gist 里. 可以直接下載下來(lái), 使用 . ./http2.sh 執(zhí)行即可.
設(shè)置環(huán)境變量等 nginx 編譯完, 我們進(jìn)入 /usr/local/nginx/sbin 里面. 將 nginx 軟連接到 /usr/sbin里面.
ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx
現(xiàn)在, 我們就可以在全局當(dāng)中使用 nginx 命令了.
配置 nginx conf通過(guò)上面的配置, 我們接著進(jìn)到 /etc/nginx/nginx.conf 中. 我直接 paste 配置代碼吧:
# 整體的 nginx 配置 user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; events { worker_connections 1024; } http { log_format main "$remote_addr - $remote_user [$time_local] "$request" " "$status $body_bytes_sent "$http_referer" " ""$http_user_agent" "$http_x_forwarded_for""; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_comp_level 5; gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php; include /etc/nginx/sites-available/*.conf; }
上面的不多說(shuō), 主要內(nèi)容還在 server 里面. 我這里使用的是 nginx + nodeJS. 所以, 后面有一層 proxy.
server { listen 80; # 重定向以前的 http協(xié)議 server_name villainhr.com www.villainhr.com; return 301 https://www.villainhr.com$request_uri; } server { listen 443 ssl http2; server_name www.villainhr.com; root /var/www/myblog/app; ssl on; # 設(shè)置上面給出的證書(shū)文件 ssl_certificate /etc/nginx/private/1 _www.villainhr.com_cert.crt; ssl_certificate_key /etc/nginx/private/2 _www.villainhr.com.key; # 設(shè)置 ssl 連接屬性 ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 設(shè)置 ciphers 套件 ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; add_header Strict-Transport-Security max-age=15768000; ssl_stapling on; ssl_stapling_verify on; location / { proxy_pass http://localhost:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~.(js|css|gif|jpg|jpeg|ico|png|bmp|swf|GIF|JPG|JPEG|ICO|PNG|BMP|SWF) $ { root / root /var/www/myblog/app/public; expires 2d; add_header Cache-Control "no-cache"; add_header Pragma no-cache; log_not_found off; } }
然后, 使用 nginx 直接運(yùn)行. 如果上面順利的話, 你的 http2 server 也就大功告成了.
如果, 上面有配置錯(cuò)誤神馬的. 不放心,可以直接去 mozilla 上面套一個(gè).
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/39340.html
摘要:通過(guò)或者協(xié)議請(qǐng)求的資源由統(tǒng)一資源標(biāo)識(shí)符,來(lái)標(biāo)識(shí)。標(biāo)準(zhǔn)于年月以正式發(fā)表,替換成為的實(shí)現(xiàn)標(biāo)準(zhǔn)。該系列協(xié)議由谷歌開(kāi)發(fā),于年公開(kāi)。主流的瀏覽器谷歌火狐也都早已經(jīng)支持,它已經(jīng)成為了工業(yè)標(biāo)準(zhǔn)。配合負(fù)載均衡有層和層協(xié)議負(fù)載。 HTTP/2 is the future of the Web, and it is here! 使用 HTTP/1.1 和 HTTP/2 在相同環(huán)境各加載 300 多張小圖片...
摘要:本文通過(guò)一個(gè)小例子串一遍處理的流程。主要涉及到的協(xié)議以及的處理流程。所以對(duì)協(xié)議的服務(wù)發(fā)起請(qǐng)求時(shí),一般瀏覽器會(huì)建立條連接,并行的去請(qǐng)求不同的資源。表明該字段是否使用了編碼。 本文通過(guò)一個(gè)小例子串一遍nginx處理http2的流程。主要涉及到http2的協(xié)議以及nginx的處理流程。 http2簡(jiǎn)介 http2比較http1.1主要有如下五個(gè)方面的不同: 二進(jìn)制協(xié)議 http1.1請(qǐng)求行...
摘要:主要涉及到的協(xié)議以及的處理流程。并且中必須建立在協(xié)議之上。所以對(duì)協(xié)議的服務(wù)發(fā)起請(qǐng)求時(shí),一般瀏覽器會(huì)建立條連接,并行的去請(qǐng)求不同的資源。表明該字段是否使用了編碼。 運(yùn)營(yíng)研發(fā) 張仕華 本文通過(guò)一個(gè)小例子串一遍nginx處理http2的流程。主要涉及到http2的協(xié)議以及nginx的處理流程。 http2簡(jiǎn)介 http2比較http1.1主要有如下五個(gè)方面的不同: 二進(jìn)制協(xié)議 http1....
閱讀 605·2023-04-26 01:39
閱讀 4726·2021-11-16 11:45
閱讀 2684·2021-09-27 13:37
閱讀 963·2021-09-01 10:50
閱讀 3705·2021-08-16 10:50
閱讀 2284·2019-08-30 15:55
閱讀 3068·2019-08-30 15:55
閱讀 2320·2019-08-30 14:07