1樓：鼓掌者
意義在於，pipeline是基於文字傳輸的HTTP協議實現的，而HTTP2是基於二進位制的協議。兩者交付到tcp層的方式有很大的區別。
首先，http pipeline主要目的允許是併發的處理多個請求。但是主要有兩個限制：
客戶端必須乙個請求完整交付到tcp緩衝區之後才能交付下乙個；服務端響應也是一樣。
服務端必須按請求的順序傳送響應。
這兩個限制是必須要遵循的，本質上是因為http協議是文字傳輸協議，所以不得不限制。如果不遵循這兩個限制，會導致這樣的問題：
如果不遵循限制1，假設客戶端現在併發兩個請求a、b。請求a交付一半的a1到tcp層，之後請求b交付一半的b1到tcp層，然後先後交付a2和b2。這時候服務端解析請求a時，解析完a1，到了解析b1的內容發現不符合http協議的格式，此時所有請求都會報錯。
因此，必須完整傳送乙個，再發下乙個如果不遵循限制2，假設客戶端傳送reqa、reqb請求，服務端先響應了resb再響應resa。這個時候客戶端會錯誤的把resb當成reqa的響應，造成錯亂的情況。
因此，因為http協議本質上是文字傳輸協議，就決定了它無法打破上面的兩個限制。即使pipeline允許併發請求，也會存在"線頭阻塞"的問題。這樣，pipeline只是實現了"虛假的併發"。
上面說到，http協議的定義(文字傳輸協議)，是限制它只能做到虛假的併發的本質原因。為了解決這個問題，最好的方法就是將文字協議變成二進位制協議。
所以，HTTP2引入了幀和流的概念。這樣，乙個請求或響應被分成多個幀，多個幀之間根據相同的id組成流。
客戶端併發多個請求的時候，會把請求分成乙個個幀，各個不同請求的幀可以交錯的交付到tcp層，這是因為有id進行區分是屬於哪個請求的。如此，客戶端就不用等乙個請求傳送完成再發下乙個，這樣就避免的"線頭阻塞"。響應同理。
因此，基於幀和流的HTTP2作為二進位制協議，就能夠實現"真正的併發"。
2樓：Link
不知道我理解的有沒有誤。
題主說的TCP亂序和和Http2允許亂序其實不是乙個層面上的。
http2是在報文層面允許亂序，是為了解決http1.1的報文阻塞導致已經可以響應的報文無法響應的問題，可以做到先處理完的報文先響應，這樣平均響應時間就降下來了。
而TCP分組亂序則是網路的問題，這個不是應用層能解決的問題，也不是http2解決的問題。
3樓：愛吃棉花糖
沒看什麼什麼資料，一直以為新的http協議，只是修改了http驅動，將原來乙個request打包成乙個http訊息修改成了N個request打包成乙個訊息，對端亦然，沒想到跟傳輸層有關
4樓：zhtz
計算機行業有句很有名的話
電腦科學中的每個問題都可以用一間接層解決每一層有每一層需要解決的問題。
TCP 解決的是因為網路問題導致的丟包和亂序問題。HTTP 的那些操作是為了讓上層更好的併發，而不是為了解決 TCP 的問題。你網路好不好，會不會丟包，會不會亂序，那是 TCP 的事，和我 HTTP 有什麼關係？
但它們確實有共同點，TCP 的資料片段可能會亂序，HTTP 的報文片段也有可能亂序。就這個共同點也有不同， TCP 的亂序是我所不想但卻無法避免的，而 HTTP 的亂序是故意的。這一差異是因為它們是為了解決不同問題而設計的。
5樓：
個人理解。
你說的沒錯，HTTP2的這個改進是用於應對HTTP本身阻塞導致的額外延遲，而不是應對TCP傳輸帶來的延遲。TCP的這個問題是它協議可靠性要求特性帶來的天然問題。它的問題不能也不應該由它承載的上層協議給出解決方案。
當然上層可以有額外的設計來Workaround（不知道該怎麼翻），但是本質上就是無法解決。要是能解決，計算機網路也不會一直把TCP和UDP的區別當成乙個經典面試題，經久不衰。
6樓：
假設現在瀏覽器只能建立了乙個TCP連線，上層有3個HTTP請求需要處理。3個請求和耗時（服務端處理時間，先忽略網路延遲）分別是:
GET /a ：2s
GET /b ：1s
GET /c ：3s
HTTP/1.0 : 傳送乙個請求並且得到響應後再發第二個。這時，瀏覽器處理這3個請求的時間線：
第0秒：傳送GET /a。
第1秒：等待。。。
第2秒末：得到a的響應，傳送GET /b。
第3秒末：得到b的響應，傳送GET /c。
第4秒：等待。。。
第5秒：等待。。。
第6秒末：得到c的響應，共計6秒。
HTTP/1.1 Pipeline ：可以一次性的傳送多個請求，但是伺服器響應時會嚴格按照接收到的請求順序依次的響應。這時，瀏覽器處理這三個請求的時間線（最佳狀態）：
第0秒：傳送GET /a，GET /b , GET /c。
第1秒：等待。。。
第2秒末：依次a，b的響應（b雖然再第1秒末的時候已經處理完，但是由於排在前面的a還未處理完成，故而伺服器是會等到a處理完後再響應b的）。
第3秒末：得到c的響應。共計3秒。
HTTP/2 Multiplexing：客戶端可以同時傳送多個請求（每個請求被拆分成多個被編號的Frame），服務端也可同時響應多個請求。這時，瀏覽器處理這3個請求的時間線：
第0秒：傳送GET /a，GET /b , GET /c。
第1秒末：得到b的響應。
第2秒末：得到a的響應。
第3秒末：得到c的響應。共計3秒。
總結：HTTP/1.0 ：客戶端的請求佇列被慢請求阻塞。總耗時6秒。
HTTP/1.1 Pipeline：把請求佇列一下子扔給服務端，客戶端不阻塞了，但是服務端響應的時候會嚴格按照請求的順序響應，還是會阻塞（阻塞服務端）。
總耗時3秒（因為我給的例子中Pipeline是把a，b，c三個一起傳送的最佳狀態，如果是先把a，b傳送了，然後再傳送c，那麼總耗時就是5s了）。
HTTP/2 Multiplexing ：解決了1.x中的隊頭阻塞（Head of line blocking）問題（1.
1的Pipeline依然存在這個問題）。充分利用TCP的雙向通訊的能力，同時提高頻寬的利用率（而不是像1.1時那樣一直處於等待中，使TCP連線處於空閒狀態）。
總耗時3秒。
HTTP/2 的缺陷：
由於更改了底層的資料報格式，那麼如果網路中有中介軟體不支援，那就歇菜了（HTTP/1.1 Pipeline也有這個問題），其實這個也是目前瀏覽器只實現了基於TLS的HTTP/2的原因之一。
底層的TCP有擁塞控制，Multiplexing 也有自己的流控，兩者疊加在一起使得問題變得更加複雜（這也是HTTP/3在底層拋棄了TCP，改用了UDP來做的原因之一）。我這有個簡單的效能測試 linianhui/http.benchmark ，在配置不同的concurrent stream數量時，實際效能差距是非常大的。
目前的應用大都是基於TLS的HTTP/2，缺乏基於TCP的明文版的HTTP/2。
7樓：A-yon
個人理解，HTTP2實現亂序傳輸的意義不是面向底層 TCP 的優化，也優化不了，而是面向上層多路復用的優化，這樣子在同時傳輸多個請求和響應內容時，它們就可以無序傳輸，而不需要等待上乙個請求-響應傳輸完成，而 HTTP1 是需要等待的。
長時間的單戀還是愛情嗎？是不是在本質上已經發生了變化
南瓜 硃砂痣那種感覺，當初愛的太用力了，愛已不在這裡我卻還沒走脫九年的話，已經知道怎麼生活了吧 在想要不要放棄的話 我覺得放棄是對自己和過去的背叛，他曾經是我的神袛，我狂熱的迷失了自己。所以我放不下，就算已經習慣沒有他的生活 烏辭 說嚴重點，這是一種心理依賴，情感的毒癮。重振自己的人生，必須多結交不...
燈泡和太陽的光本質上是一種光嗎？
QUBIC調調科技 太陽的光粒子和燈泡的光粒子一樣嗎？先回答第乙個問題，這兩者的光子肯定是不一樣的，兩種光子的光譜不同，頻率也不一樣。如果覺得彆扭的話，換乙個角度就是，你覺得紅光和紫光的光子一樣嗎？e hv h 是蒲朗克常數，v 是光子頻率，他們的能量就不一樣，所以不同。再回答第二個問題，本質相同嗎...
如何理解 人的一切痛苦，本質上都是對自己無能的憤怒 ？
清淨 承認痛苦的普遍性，看似悲觀消極，實則不然。如果你把痛苦純粹當作一種負面經歷，總在想方設法避免它，或者認為痛苦是一種失敗的表現，要是自己能力足夠，一切都擺得平，就不會有痛苦。如果你這樣想，毫無疑問，當問題 挫折出現時，你會感到分外壓抑 焦慮和不公平。這樣做也許能暫時緩解焦慮和恐懼，卻無法真正解決...