1. 程式人生 > >http 1.0 / 1.1 / 2.0的區別

http 1.0 / 1.1 / 2.0的區別

1. http 1.0

  1.1 連結無法複用,即不支援持久連結:

          http 1.0 規定瀏覽器與伺服器保持較短時間的連結,瀏覽器每次請求都和伺服器經過三次握手和慢啟動(基本思想是當TCP開始傳輸資料或發現數據丟失並開始重發時,首先慢慢的對網路實際容量進行試探,避免由於傳送了過量的資料而導致阻塞)建立一個TCP連結,伺服器完成請求處理後立即斷開TCP連結,而且不跟蹤每個瀏覽器的歷史請求。

        注意:由於http 1.0每次建立TCP連結對效能的影響實在是太大,http1.1實現持久化連結之後,又反向移植到http 1.0上,只是預設是沒有開啟持久連結的,通過http的header部分的 

Connection: KeepAlive 來啟用

1.2 線頭阻塞(Head of Line (HOL) Blocking)

               請求佇列的第一個請求因為伺服器正忙(或請求格式問題等其他原因),導致後面的請求被阻塞。

2. http 1.1

    2.1 支援持久連結(在request和response中的header中的connection是close或者Keep-Alive進行控制)

          一個TCP連結可以傳送多個http請求和相應,減少了TCP建立連結和關閉連結的消耗。另外http1.1允許客戶端不用等待上一次請求結果返回,就可以發出下一次請求,但伺服器端必須按照接收到客戶端請求的先後順序依次回送響應結果,以保證客戶端能      夠區分出每次請求的響應內容。

2.2 支援http管道

不使用管道的http請求,在使用持久連結時,必須嚴格滿足先進先出的佇列順序(FIFO),即傳送請求,等待響應完成,再發送客戶端佇列中的下一個請求。管道可以讓我們把 FIFO 佇列從客戶端(請求佇列)遷移到伺服器(響應佇列),即客戶端可以並行,服務端序列。客戶端可以不用等待前一個請求返回,傳送請求,但伺服器端必須順序的返回客戶端的請求響應結果。 缺點: a. 一個請求響應阻塞,就會阻塞後續所有請求 b. 並行處理請求時,伺服器必須緩衝管道中的響應,從而佔用伺服器資源,如果有個響應非常大,則很容易形成伺服器的受攻擊面; c. 響應失敗可能終止 TCP 連線,從頁強迫客戶端重新發送對所有後續資源的請求,導致重複處理; d. 由於可能存在中間代理,因此檢測管道相容性,確保可靠性很重要; e. 如果中間代理不支援管道,那它可能會中斷連線,也可能會把所有請求串聯起來。

2.3 使用多個TCP連結

http1.1 在客戶端排隊所有請求,讓後通過一個TCP持久連結,一個接一個的傳送請求(如果有http管道還必須順序等待服務端的順序返回結果)。但實際中,瀏覽器的開發時不會這麼笨,瀏覽器允許我們開啟N個TCP連結(大多說瀏覽器是6個TCP連結,這個數字越大,客戶端和伺服器的資源佔用越多,這個資料也只是感覺安全的數字而已)。 帶來的好處: 1. 客戶端可以並行傳送最多 N個請求; 2. 伺服器可以並行處理最多 N個請求; 3. 第一次往返可以傳送的累計分組數量(TCP cwnd)增長為原來的 N 倍。 代價: 1.更多的套接字會佔用客戶端、伺服器以及代理的資源,包括記憶體緩衝區和 CPU時鐘週期; 2.並行 TCP 流之間競爭共享的頻寬; 3.由於處理多個套接字,實現複雜性更高; 4.即使並行 TCP 流,應用的並行能力也受限制。 因此使用多個TCP連結只是權宜之計,後續的http 2.0支援多路複用,很好的解決了上述問題。

2.4 http 1.1 增加了請求頭和響應頭來擴充功能

    舉例:
         a. 支援Host請求:
         b. Connection: 請求頭的值為Connection時,客戶端通知伺服器返回本次請求結果後保持連線;Connection請求頭的值為close 時,客戶端通知伺服器返回本次請求結果後關閉連線
         c. 支援斷點續傳:
         d.身份認證:
         e.狀態管理:
         f. 快取處理:

2.5 域名分割槽

域名分割槽是思想是將原來集中到一個伺服器上的資源分佈到多個伺服器上,這樣就可以突破瀏覽器的連結限制(一般是6個),提高並行能力。 代價: 1. 每多一臺主機都要多一次的 DNS 查詢,每多一個套接字都會多消耗兩端的一些資源; 2.必須手工分離一臺主機上的資源到多臺;. 實際實踐中,效果並不是很明顯,反而導致被濫用。

2.6 http的header的優化

目前所有的header請求都是以沒有經過壓縮的純文字的形式傳送(通常會有600`1000位元組),而通常使用的http請求body卻很少(10~200位元組),和header相比,顯得很少,特別是在使用了cookie之後,這樣的矛盾就更加突出,因此要減少header的資料。

2.7 減少連線次數

即將需要多次才能獲取的檔案或資源組合併成一個,通過一次網路請求獲取。這樣減少了協議的開銷,間接地將伺服器端的管道思維移植到了客戶端。缺點:增加複雜性,更快取帶來負擔,頁面的分步顯示,改成一次顯示,在網路慢的時候影響使用者體驗。

2.8 嵌入小的檔案

即將資源嵌入文件(通過URI嵌入圖片,音訊或PDF),可以減少請求次數。嵌入資源作為頁面的返回一部分一次返回,即如果在多個頁面中都嵌入同樣的資源,那麼這個資源將會隨著每個頁面的載入而被載入,從而增大每個頁面的總體大小,如果嵌入資源被更新,客戶端只能重新獲取有效的資源。 實踐:一般只考慮嵌入1~2KB一下的資源 參照建議: 1. 如果檔案很小,而且只有個別頁面使用,可以考慮嵌入; 2.如果檔案很小,但需要在多個頁面中重用,應該考慮集中打包; 3. 如果小檔案經常需要更新,就不要嵌入了; 4. 通過減少 HTTP cookie 的大小將協議開銷最小化。

3. http 2.0

HTTP 2.0把解決效能問題的方案內建在了傳輸層,通過多路複用來減少延遲,通過壓縮 HTTP首部降低開銷,同時增加請求優先順序和伺服器端推送的功能。

  3.1 支援多路複用

         多路複用允許同時通過單一的 HTTP 2.0 連線發起多重的請求-響應訊息,即所有HTTP 2.0 連線都是持久化的,而且客戶端與伺服器之間也只需要一個連線即可,所有資料流共用同一個連線 ,減少了因http連結多而引起的網路擁塞(在 HTTP1.1 協議中,同一時間,瀏覽器會針對同一域名下的請求有一定數量限制),解決了慢啟動針對突發性和短時性的http連結低效的問題。

3.2 將通訊的基本單位縮小為幀

             即應用層(HTTP)和傳輸層(TCP or UDP)之間增加一個二進位制分幀層,因此在多向請求和響應時,客戶端和伺服器可以把HTTP訊息分解為互不依賴的幀,然後亂序傳送,最後再在另一端把它們重新組合起來,解決了http 1.*的對手阻塞問題。 

3.3 首部壓縮

              http 2.0支援DEFLATE和HPACK 演算法的壓縮。

3.4 服務端推送

          指客戶端請求之前傳送資料的機制,在 HTTP 2.0 中,伺服器可以對客戶端的一個請求傳送多個響應。

3.5 請求優先順序

   HTTP 2.0 使用一個31位元的優先值,0表示最高優先順序, 2(31)-1表示最低優先順序,伺服器端就可以根據優先順序,控制資源分配,優先處理和返回最高優先順序的請求幀給客戶端。