-
最近在網(wǎng)上巢菽龋看到這些詞匯：Head of line blocking陪踩、Multiplexing咐低。今天借用一張圖揽思，稍微理解一下。
http請求 - 圖中第一種請求方式见擦，就是單次發(fā)送request請求钉汗，收到response后再進(jìn)行下一次請求羹令，顯示是很低效的。
- 于是http1.1提出了管線化(pipelining)技術(shù)损痰，就是如圖中第二中請求方式特恬，一次性發(fā)送多個request請求。
- 然而pipelining在接收response返回時徐钠，也必須依順序接收，如果前一個請求遇到了阻塞役首，后面的請求即使已經(jīng)處理完畢了尝丐，仍然需要等待阻塞的請求處理完畢。這種情況就如圖中第三種衡奥，第一個請求阻塞后爹袁，后面的請求都需要等待，這也就是隊(duì)頭阻塞(Head of line blocking)矮固。
- 為了解決上述阻塞問題失息，http2中提出了多路復(fù)用(Multiplexing)技術(shù)，Multiplexing是通信和計算機(jī)網(wǎng)絡(luò)領(lǐng)域的專業(yè)名詞档址。http2中將多個請求復(fù)用同一個tcp鏈接中盹兢，將一個TCP連接分為若干個流（Stream），每個流中可以傳輸若干消息（Message）守伸，每個消息由若干最小的二進(jìn)制幀（Frame）組成绎秒。也就是將每個request-response拆分為了細(xì)小的二進(jìn)制幀F(xiàn)rame，這樣即使一個請求被阻塞了尼摹，也不會影響其他請求见芹，如圖中第四種情況所示。
QUIC
- 上面說的情況都是基于TCP蠢涝，因?yàn)門CP是可靠的傳輸協(xié)議玄呛，如果一個TCP連接中的多個請求有一個請求丟包了，那么就會進(jìn)行重傳和二。而谷歌提出的QUIC(Quick UDP Internet Connections)徘铝，則是基于UDP+Http2的一個實(shí)驗(yàn)性的快速傳輸協(xié)議，UDP是面向數(shù)據(jù)報文的儿咱，所以遇到丟包的情況也不會進(jìn)行重傳庭砍，從而進(jìn)一步減少網(wǎng)絡(luò)延遲、解決隊(duì)頭阻塞問題混埠。
