一、http是什麼

通俗來講，http就是電腦通過網路進行通信的規則，是一個基於請求與響應，無狀態的，應用層協議。常用於TCP/IP協議傳輸數據。目前任何終端之間任何一種通信方式都必須按Http協議進行，否則無法連接。tcp(三次握手，四次揮手)。

• 請求與響應：客戶端請求、服務端響應數據。
• 無狀態：協議對於事務的處理是沒有記憶能力，客戶端第一次與伺服器建立連接發送請求時需要進行一系列的安全認證匹配操作，因此增加頁面等待時間，當客戶端向服務端發送請求，服務端響應完畢後，兩者斷開鏈接，也不保存連接狀態。
• TCP/IP:Http使用TCP作為它的支撐運輸協議。Http客戶機發起一個與伺服器的TCP連接，一旦連接建立，瀏覽器（客戶機）和伺服器進程就可以通過套接字介面（socket interface）訪問TCP。

二 http三個組成部分

http請求由三部分構成，分別是：請求頭、消息報頭、請求正文

• 請求方法：get、post、head、put、delete

• GET方法與POST方法的區別

區別一：
get重點在從伺服器上獲取資源，post重點在向伺服器發送數據；
區別二：
get傳輸數據是通過URL請求，以field（欄位）= value的形式，置於URL後，並用"?"連接，多個請求數據間用"&"連接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；
post傳輸數據通過Http的post機制，將欄位與對應值封存在請求實體中發送給伺服器，這個過程對用戶是不可見的；
區別三：
Get傳輸的數據量小，因為受URL長度限制，但效率較高；

Post可以傳輸大量數據，所以上傳文件時只能用Post方式；

區別四：
get是不安全的，因為URL是可見的，可能會泄露私密信息，如密碼等；
post較get安全性較高；
區別五：
get方式只能支持ASCII字元，向伺服器傳的中文字元可能會亂碼。
post支持標準字元集，可以正確傳遞中文字元。

• 常見的HTTP相應狀態碼

　　　　返回的狀態
　　　　1xx：指示信息--表示請求已接收，繼續處理
　　　　2xx：成功--表示請求已被成功接收、理解、接受
　　　　3xx：重定向--要完成請求必須進行更進一步的操作
　　　　4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
　　　　5xx：伺服器端錯誤--伺服器未能實現合法的請求

　　　　200：請求被正常處理
　　　　204：請求被受理但沒有資源可以返回
　　　　206：客戶端只是請求資源的一部分，伺服器只對請求的部分資源執行GET方法，相應報文中通過Content-Range指定範圍的資源。
　　　　301：永久性重定向
　　　　302：臨時重定向
　　　　303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
　　　　304：發送附帶條件的請求時，條件不滿足時返回，與重定向無關
　　　　307：臨時重定向，與302類似，只是強制要求使用POST方法
　　　　400：請求報文語法有誤，伺服器無法識別
　　　　401：請求需要認證
　　　　403：請求的對應資源禁止被訪問
　　　　404：伺服器無法找到對應資源
　　　　500：伺服器內部錯誤
　　　　503：伺服器正忙

• 請求URL：他與報文頭的host屬性組成完整的URL
• 3⃣️協議名稱以及版本號（http1.1）
• 4⃣️HTTP請求頭（報文頭）：包含Request與Response兩個部分

  HTTP請求頭提供了關於請求，響應或者其他的發送實體的信息。HTTP的頭信息包括通用頭、請求頭、響應頭和實體頭四個部分。每個頭域由一個功能變數名稱，冒號（:）和域值三部分組成（屬性名：屬性值）。 

1. 通用頭標：即可用於請求，也可用於響應，是作為一個整體而不是特定資源與事務相關聯。
2. 請求頭標：允許客戶端傳遞關於自身的信息和希望的響應形式。
3. 響應頭標：伺服器和於傳遞自身信息的響應。
4. 實體頭標：定義被傳送資源的信息。即可用於請求，也可用於響應。

• 5⃣️是報文體，它將一個頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體可以傳遞請求參數，請求URL也可以通過類似於“/chapter15/user.html? param1=value1&param2=value2”的方式傳遞請求參數。

三、HTTP發展史（HTTP1.1與HTTP2.0）

1. Http0.9：該協議誕生之初的作用是傳輸超文本內容HTML，並且只支持GET請求。

　　　　協議定義了客戶端發起請求、服務端響應請求的通信模式。所以當時的請求報文只有一行：

GET + 請求的文件路徑

2.  Http1.0：瀏覽器希望通過HTTP來傳輸腳本、樣式、圖片、音視頻等不同類型的文件　　

• 增加了HEAD、POST等新方法
• 增加了響應狀態碼，標記可能的錯誤原因
• 引入了協議版本號概念
• 引入了HTTP header的概念，讓HTTP處理請求和響應更加靈活
• 傳輸的數據不再局限於文本

http1.0缺點：

HTTP/1.0最主要的缺點還是跟HTTP/0.9一樣，每一個TCP連接只能發送一個HTTP請求，伺服器發送完響應，就關閉連接。如果後面需要請求新的數據，則需要再次建立TCP連接，但是TCP建立連接的三次握手成本比較高，並且TCP連接初始的時候發送數據的速度相對較慢，有一個慢啟動和擁塞避免的階段。極端情況，如果每次請求的數據很少，但是請求很頻繁，這樣每次請求很少的數據都需要建立連接然後斷開。

解決辦法：

為瞭解決這個問題，在1.0版本使用了一個非標準的Connection頭部欄位。當客戶端再請求頭部信息裡面帶上Connection：keep-alive的時候，伺服器在發送完響應數據之後，就不會斷開TCP連接了，從而達到復用同一個TCP連接的目的。但是由於不是標準欄位，不同的實現可能導致表現得不一致，因此不能從根本上解決這個問題。

HTTP/1.0最核心的改變是增加了頭部設定，頭部內容以鍵值對的形式設置。請求頭部通過 Accept 欄位來告訴服務端可以接收的文件類型，響應頭部再通過 Content-Type 欄位來告訴瀏覽器返迴文件的類型。頭部欄位不僅用於解決不同類型文件傳輸的問題，也可以實現其他很多功能如緩存、認證信息等。

 3.  Http1.1

• 長連接：引入了 TCP 連接復用，即一個 TCP 預設不關閉，可以被多個請求復用
• 併發連接：對一個功能變數名稱的請求允許分配多個長連接（緩解了長連接中的「隊頭阻塞」問題）
• 引入管道機制（pipelining），一個 TCP 連接，可以同時發送多個請求。（響應的順序必須和請求的順序一致，因此不常用）
• 增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法
• 新增了一些緩存的欄位（If-Modified-Since, If-None-Match）
• 請求頭中引入了 range 欄位，支持斷點續傳
• 允許響應數據分塊（chunked），利於傳輸大文件
• 強制要求 Host 頭，讓互聯網主機托管稱為可能

HTTP管道機制（pipelining）

它指的是在一個TCP連接內，多個HTTP請求可以並行，客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但伺服器端必須按照接收到客戶端請求的先後順序依次回送響應結果，以保證客戶端能 夠區分出每次請求的響應內容。

隨著網路的發展，HTTP 1.1 還是暴露出一些局限性:

• 雖然加入 keep-alive 可以復用一部分連接，但功能變數名稱分片等情況下仍然需要建立多個connection，耗費資源，給伺服器帶來性能壓力。
• pipeling 只部分解決了隊頭阻塞（ HOLB）。 HTTP 1.1 嘗試使用 pipeling 來解決隊頭阻塞問題，即瀏覽器可以一次性發出多個請求（同個功能變數名稱、同一條 TCP 鏈接）。 但 pipeling 要求返回是按序的，那麼前一個請求如果很耗時（比如處理大圖片），那麼後面的請求即使伺服器已經處理完，仍會等待前面的請求處理完才開始按序返回。
• 協議開銷大，沒有相應的壓縮傳輸優化方案。 HTTP/1.1 在使用時，header 里攜帶的內容過大，在一定程度上增加了傳輸的成本，並且每次請求 header 基本不怎麼變化，尤其在移動端增加用戶流量。

HTTP/1.1 通過長連接減少了大量創建/斷開連接造成的性能消耗，但是它的併發能力受到限制，表現在兩個方面：

HTTP/1.1 中使用持久連接時，一個連接中同一時刻只能處理一個請求。當前的請求沒有結束之前，其他的請求只能處於阻塞狀態，這種情況被稱為隊頭阻塞
瀏覽器為了減輕伺服器的壓力，限制了同一個功能變數名稱下的 HTTP 連接數，一般為 6 ~ 8 個。為瞭解決數量限制，出現了 功能變數名稱分片 技術，其實就是資源分域，將資源放在不同功能變數名稱下 (比如二級子功能變數名稱下)，這樣就可以針對不同功能變數名稱創建連接並請求，以一種討巧的方式突破限制，但是濫用此技術也會造成很多問題，比如每個 TCP 連接本身需要經過 DNS 查詢、三步握手、慢啟動等，還占用額外的 CPU 和記憶體，對於伺服器來說過多連接也容易造成網路擁擠、交通阻塞等。
SPDY：HTTP1.X的優化（改進版HTTP/1.1）
2012年google提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體如下：

• 降低延遲： 針對HTTP高延遲的問題，SPDY優雅的採取了多路復用（multiplexing）。多路復用通過多個請求stream共用一個tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時提高了帶寬的利用率。
• 請求優先順序（request prioritization）：多路復用帶來一個新的問題是，在連接共用的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先順序，這樣重要的請求就會優先得到響應。比如瀏覽器載入首頁，首頁的html內容應該優先展示，之後才是各種靜態資源文件，腳本文件等載入，這樣可以保證用戶能第一時間看到網頁內容。
• header壓縮：前面提到HTTP1.x的header很多時候都是重覆多餘的。選擇合適的壓縮演算法可以減小包的大小和數量。
• 基於HTTPS的加密協議傳輸：大大提高了傳輸數據的可靠性。
• 服務端推送（server push）：可以讓服務端主動把資源文件推送給客戶端。當然客戶端也有權利選擇是否接收。

 4.  Http2.0

2015 年正式發佈的 HTTP/2 預設不再使用 ASCII 編碼傳輸，而是改為二進位數據，來提升傳輸效率。

客戶端在發送請求時會將每個請求的內容封裝成不同的帶有編號的二進位幀（Frame），然後將這些幀同時發送給服務端。服務端接收到數據之後，會將相同編號的幀合併為完整的請求信息。同樣，服務端返回結果、客戶端接收結果也遵循這個幀的拆分與組合的過程。

有了二進位分幀後，對於同一個域，客戶端只需要與服務端建立一個連接即可完成通信需求，這種利用一個連接來發送多個請求的方式稱為多路復用。每一條路都被稱為一個stream（流）。

特點：

• 二進位協議： HTTP/1.1版本的頭部信息是文本，數據部分可以是文本也可以是二進位。HTTP/2版本的頭部和數據部分都是二進位，且統稱為‘幀’
• 多路復用： 廢棄了 HTTP/1.1 中的管道，同一個TCP連接裡面，客戶端和伺服器可以同時發送多個請求和多個響應，並且不用按照順序來。由於伺服器不用按順序來處理響應，所以避免了“對頭堵塞”的問題。
• 頭部信息壓縮： 使用專用演算法壓縮頭部，減少數據傳輸量，主要是通過服務端和客戶端同時維護一張頭部信息表，所有的頭部信息在表裡面都會有對應的記錄，並且會有一個索引號，這樣後面只需要發送索引號即可
• 服務端主動推送： 允許伺服器主動向客戶推送數據
• 數據流： 由於HTTP/2版本的數據包不是按照順序發送的，同一個TCP連接裡面相連的兩個數據包可能是屬於不同的響應，因此，必須要有一種方法來區分每一個數據包屬於哪個響應。HTTP/2版本中，每個請求或者響應的所有數據包，稱為一個數據流（stream），並且每一個數據流都有一個唯一的編號ID，請求數據流的編號ID為奇數，響應數據流的編號ID為偶數。每個數據包在發送的時候帶上對應數據流的編號ID，這樣伺服器和客戶端就能分區是屬於哪一個數據流。最後，客戶端還能指定數據流的優先順序，優先順序越高，伺服器會越快做出響應。

缺點：

HTTP/2雖然解決了許多問題，但在TCP協議級別上仍然存在類似的隊頭問題，而TCP仍然是Web的構建基礎。當 TCP 數據包在傳輸過程中丟失時，在伺服器重新發送丟失的數據包之前，接收方無法確認傳入的數據包。由於 TCP 在設計上不遵循 HTTP 之類的高級協議，因此單個丟失的數據包將阻塞所有進行中的 HTTP 請求的流，直到重新發送丟失的數據為止。這個問題在不可靠的連接上尤為突出，這在無處不在的移動設備時代並不罕見。

5.HTTP/3

• HTTP/2 由於採用二進位分幀進行多路復用，通常只使用一個 TCP 連接進行傳輸，在丟包或網路中斷的情況下後面的所有數據都被阻塞。
• HTTP/2 的問題不能僅靠應用程式層來解決，因此協議的新迭代必須更新傳輸層。但是，創建新的傳輸層協議並非易事。傳輸協議需要硬體供應商的支持，並且需要大多數網路運營商的部署才能普及。

幸運的是還有另一種選擇。UDP 協議與 TCP 一樣得到廣泛支持，但前者足夠簡單，可以作為在其之上運行的自定義協議的基礎。**UDP 數據包是一勞永逸的：沒有握手、持久連接或錯誤校正。**HTTP3 背後的主要思想是放棄 TCP，轉而使用基於 UDP 的 QUIC （快速UDP互聯網連接）協議。

與 HTTP2 在技術上允許未加密的通信不同，QUIC 嚴格要求加密後才能建立連接。此外，加密不僅適用於 HTTP 負載，還適用於流經連接的所有數據，從而避免了一大堆安全問題。建立持久連接、協商加密協議，甚至發送第一批數據都被合併到 QUIC 中的單個請求/響應周期中，從而大大減少了連接等待時間。如果客戶端具有本地緩存的密碼參數，則可以通過簡化的握手重新建立與已知主機的連接。

為瞭解決傳輸級別的線頭阻塞問題，通過 QUIC 連接傳輸的數據被分為一些流。流是持久性 QUIC 連接中短暫、獨立的“子連接”。每個流都處理自己的錯誤糾正和傳遞保證，但使用連接全局壓縮和加密屬性。每個客戶端發起的 HTTP 請求都在單獨的流上運行，因此丟失數據包不會影響其他流/請求的數據傳輸。

6.各版本對比

HTTP的三次握手