計算機網路複習筆記-Http 1.0/1.1/2.0 區別

什麼是Http？

Http （超文字傳輸協議，HyperText Transfer Protocol）是一個簡單的請求-響應協議，它通常基於TCP進行連線。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議。預設使用80埠，HTTP客戶端發起一個請求，建立一個到伺服器指定埠（預設是80埠）的TCP連線。請求和響應訊息的頭以ASCII碼形式給出；而訊息內容則具有一個類似MIME的格式。

為什麼Http是基於TCP連線？

HTTP使用TCP而不是UDP的原因在於（開啟）一個網頁必須傳送很多資料，而TCP協議提供傳輸控制，按順序組織資料，和錯誤糾正。HTTP協議的瓶頸及其優化技巧都是基於TCP協議本身的特性。如TCP建立連線時三次握手有1.5個RTT（round-trip time）的延遲，為了避免每次請求的都經歷握手帶來的延遲，應用層會選擇不同策略的http長連結方案。又如TCP在建立連線的初期有慢啟動（slow start）的特性，所以連線的重用總是比新建連線效能要好。

Http標準現狀

HTTP連線使用的是“請求—響應”的方式，不僅在請求時需要先建立連線，而且需要客戶端向伺服器發出請求後，伺服器端才能回覆資料。

• HTTP 1.0是第一個在通訊中指定版本號的HTTP 協議版本，至今仍被廣泛採用，特別是在代理伺服器中。
• HTTP/1.1是當前版本，持久連線（Connection ： Keep-Alive）被預設採用，並能很好地配合代理伺服器工作，還支援以管道方式同時傳送多個請求，以便降低線路負載，提高傳輸速度。
• HTTP／2.0在HTTP 1.x的基礎上，大幅度的提高了web效能，減少了網路延遲。HTTP1.0和1.1在之後很長的一段時間內會一直並存，這是由於網路基礎設施更新緩慢所決定的。

Http 1.0

HTTP 協議老的標準是HTTP/1.0，為了提高系統的效率，HTTP 1.0規定瀏覽器與伺服器只保持短暫的連線，瀏覽器的每次請求都需要與伺服器建立一個TCP連線，伺服器完成請求處理後立即斷開TCP連線，伺服器不跟蹤每個客戶也不記錄過去的請求。
這樣做的缺點是由於每次客戶端向伺服器請求時都要重新建立TCP連線，當網頁中包含有外部的靜態資源的載入，如：圖片，css和JS檔案等，客戶端還要根據這些資源的URL重新與伺服器進行TCP的連線，即使影像檔案都很小，但是客戶端和伺服器端每次建立和關閉連線卻是一個相對比較費時的過程，並且會嚴重影響客戶機和伺服器的效能。
因此，Http1.0最明顯的缺點之一就是連線無法複用，客戶端是依據域名來向伺服器建立連線，一般PC端瀏覽器會針對單個域名的伺服器同時建立6～8個連線，手機端的連線數則一般控制在4～6個。顯然連線數並不是越多越好，資源開銷和整體延遲都會隨之增大。連線無法複用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對檔案類大請求影響較大。
Http1.0的另外一個問題則是 head of line blocking: 會導致頻寬無法被充分利用，以及後續健康請求被阻塞。假設有5個請求同時發出,對於HTTP1.0的實現, 在第一個請求沒有收到回覆之前，後續從應用層發出的請求只能排隊，請求2，3，4，5只能等請求1的響應回來之後才能逐個發出。網路通暢的時候影響不大，一旦請求1的request因為什麼原因沒有抵達伺服器，或者伺服器響應因為網路阻塞沒有及時返回，影響的就是所有後續請求，問題就變得比較嚴重了。

所以Http 1.1 和 Http 2.0 主要就是針對這兩個問題提出瞭解決方案和辦法：

解決辦法
解決連線無法複用問題 ：

• http1.0協議頭裡可以設定Connection:Keep-Alive 在Http首部裡設定Keep-Alive可以在一定時間內複用連線，具體複用時間的長短可以由伺服器控制，一般在15s左右。一段時間內的連線複用對PC端瀏覽器的體驗幫助很大，因為大部分的請求在集中在一小段時間以內。但對移動app來說，成效不大，app端的請求比較分散且時間跨度相對較大。所以移動端app一般會從應用層尋求其它解決方案。

• 在Http 1.1 和 Http 2.0 中： Connection的預設值就是Keep-Alive，如果要關閉連線複用需要顯式的設定Connection:Close 。如果client使用http1.1 / 2.0 協議，但又不希望使用長連結，則需要在header中指明connection的值為close；如果server方也不想支援長連結，則在response中也需要明確說明connection的值為close。不論request還是response的header中包含了值為close的connection，都表明當前正在使用的tcp連結在當天請求處理完畢後會被斷掉。以後client再進行新的請求時就必須建立新的tcp連結了。

解決head of line blocking問題 :
HTTP1.1和HTTP2.0的最大優勢就是對於頭部阻塞問題的解決.

• HTTP1.1的解決方案 - http pipelining： 和圖一相比最大的差別是，請求2，3不用等請求1的response返回之後才發出，而是幾乎在同一時間把request發向了伺服器。2，3及所有後續共用該連線的請求節約了等待的時間，極大的降低了整體延遲。

• 缺點: pipelining只能適用於http1.1，一般來說，支援http1.1的server都要求支援pipelining。 只有冪等的請求（GET，HEAD）能使用pipelining，非冪等請求比如POST不能使用，因為請求之間可能會存在先後依賴關係。head of line blocking並沒有完全得到解決，server的response還是要求依次返回，遵循FIFO(first in first out)原則。絕大部分的http代理伺服器不支援pipelining。和不支援pipelining的老伺服器協商有問題。可能會導致新的Front of queue blocking問題。正是因為有這麼多的問題，各大瀏覽器廠商要麼是根本就不支援pipelining，要麼就是預設關掉了pipelining機制，而且啟用的條件十分苛刻。

Http 2.0 的解決方案
多路複用（multiplexing）, 請求優先順序（request prioritization）, 首部壓縮（header packet）,伺服器推送（server push）

• 多路複用（multiplexing） multiplexing允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息。在 HTTP/1.1 協議中瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量限制，超過限制數目的請求會被阻塞。這也是為何一些站點會有多個靜態資源 CDN 域名的原因之一，拿 Twitter 為例，http://twimg.com，目的就是變相的解決瀏覽器針對同一域名的請求限制阻塞問題。 而 HTTP/2 的多路複用(Multiplexing) 則允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息。因此 HTTP/2 可以很容易的去實現多流並行而不用依賴建立多個 TCP 連線，HTTP/2 把 HTTP 協議通訊的基本單位縮小為一個一個的幀，這些幀對應著邏輯流中的訊息。並行地在同一個 TCP 連線上雙向交換訊息。
• 首部壓縮（Header Compression） HTTP/1.1並不支援 HTTP 首部壓縮，為此 SPDY 和 HTTP/2 應運而生， SPDY 使用的是通用的DEFLATE 演算法，而 HTTP/2 則使用了專門為首部壓縮而設計的 HPACK 演算法。
• 服務端推送（Server Push）：伺服器推送是一種在客戶端請求之前傳送資料的機制。在 HTTP/2 中，伺服器可以對客戶端的一個請求傳送多個響應。Server Push 讓 HTTP1.x 時代使用內嵌資源的優化手段變得沒有意義；如果一個請求是由你的主頁發起的，伺服器很可能會響應主頁內容、logo 以及樣式表，因為它知道客戶端會用到這些東西。這相當於在一個 HTML 文件內集合了所有的資源。不過與之相比，伺服器推送還有一個很大的優勢：可以快取，也讓在遵循同源的情況下，不同頁面之間可以共享快取資源成為可能。

參考文章https://baike.baidu.com/item/HTTP%202.0/12520156?fr=aladdin
https://blog.csdn.net/qq_39207948/article/details/80969968