HTTP是什么？

HTTP: HTTP 是超?本傳輸協議，也就是HyperText Transfer Protocol。是一個基于請求與響應，無狀態的，Web服務的應用層的協議，常基于TCP傳輸數據，互聯網上應用最為廣泛的一種網絡協議,所有的WWW文件都必須遵守這個標準。

HTTP超?本協議傳輸，它可以拆成三個部分：超文本、傳輸、協議。

協議：HTTP 是?個?在計算機世界?的協議。它使?計算機能夠理解的語?確?了?種計算機之間交流通信的規范（兩個以上的參與者），以及相關的各種控制和錯誤處理?式（?為約定和規范）。

傳輸：就是把?堆東?從 A 點搬到 B 點，或者從 B 點搬到 A 點。別輕視了這個簡單的動作，它?少包含兩項重要的信息。HTTP 協議是?個雙向協議。

超文本：HTTP傳輸的內容是超?本，它就是超越了普通?本的?本，它是?字、圖?、視頻等的混合體，最關鍵有超鏈接，能從?個超?本跳轉到另外?個超?本。

HTTP的優缺點

HTTP優點

HTTP的主要優點是簡單、靈活、易于拓展、應該廣泛以及跨平臺。

1. 簡單

HTTP 基本的報文格式就是 header + body ，頭部信息也是 key-value 簡單?本的形式。

2. 靈活和易于擴展

HTTP協議?的各類請求?法、URI/URL、狀態碼、頭字段等每個組成要求都沒有被固定死，都允許開發?員?定義和擴充。同時 HTTP 由于是?作在應?層（ OSI 第七層），則它下層可以隨意變化。

HTTPS 也就是在 HTTP所在的應用層與TCP所在的傳輸層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚?把 TCP 層換成了基于 UDP 的QUIC。

3. 應用?泛和跨平臺

互聯?發展?今，HTTP 的應?范圍?常的?泛，HTTP 的應?遍地開花，同時天然具有跨平臺的優越性。

HTTP缺點

由于HTTP是無狀態、明文傳輸的因此數據不安全。

無狀態的優缺點

?狀態的好處，因為服務器不會去記憶 HTTP 的狀態，因此不需要額外的資源來記錄狀態信息，這能減輕服務器的負擔，能夠把更多的 CPU 和內存用來對外提供服務。

?狀態的壞處，既然服務器沒有記憶能?，它在完成有關聯性的操作時會?常麻煩

HTTP 的安全問題，可以用HTTPS 的方式解決，也就是通過引? SSL/TLS 層，使得在安全上達到了極致。

HTTP屬于客戶/服務器模式

客戶: 請求、接收和顯示Web對象的瀏覽器；

服務器: 對請求進行響應，發送對象的Web服務器。

超詳細全方位介紹 HTTP

基于TCP連接的HTTP

1.客戶發起一個與服務器的 TCP連接 (建立套接字) ， 端口號為 80

2.服務器接受客戶的TCP連接

3.在瀏覽器(HTTP客戶端)? 與 Web服務器(HTTP服務器 server)交換HTTP報文 (應用層協議報文)

4.TCP連接關閉

HTTP是無狀態的，即服務器并不維護關于客戶的任何信息。

維護狀態的協議很復雜：

1.必須維護歷史信息(狀態)

2.如果服務器/客戶端死機，它們的狀態信息可能不一致，但二者的信息必須是一致，因此會需要重新連接

3.無狀態的服務器能夠支持更多的客戶端

非持久與持久HTTP

非持久HTTP

非持久HTTP，最多只有一個對象在，TCP連接上發送，下載多個對象需要多個TCP連接。HTTP/1.0使用非持久連接。

非持久鏈接：

超詳細全方位介紹 HTTP

響應時間模型

往返時間RTT（round-trip? time）：一個小的分組從客戶端到服務器，在回到客戶端的時間（傳輸時間忽略）。

響應時間：一個RTT用來發起TCP連接，一個 RTT用來HTTP請求并等待HTTP響應

文件傳輸時間共：2RTT+傳輸時間

超詳細全方位介紹 HTTP

非持久HTTP的缺點

時間長，每個對象要2個RTT；操作系統必須為每個TCP連接分配資源，但瀏覽器通常打開并行TCP連接，以獲取引用對象。

持久HTTP

持久HTTP，多個對象可以在一個（在客戶端和服務器之間的）TCP連接上傳輸。服務器在發送響應后，仍保持TCP連接。在相同客戶端和服務器之間的后續請求和響應報文通過相同的連接進行傳送，客戶端在遇到一個引用對象的時候，就可以盡快發送該對象的請求。HTTP/1.1 默認使用持久連接。

持久分為流水線和非流水線。

非流水方式的持久HTTP：客戶端只能在收到前一個響應后才能發出新的請求，每個引用對象花費一個RTT。

流水方式的持久HTTP：HTTP/1.1的默認模式，客戶端遇到一個引用對象就立即產生一個請求，所有引用（小）對象只花費一個RTT是可能的。

HTTP的版本

HTTP/0.9

只接受GET一種請求方法，沒有在通信中指定版本號，且不支持請求頭。由于該版本不支持POST方法，因此客戶端無法向服務器傳遞太多信息。

HTTP/1.0

第一個在通信中指定的版本號，至今被廣泛采用，特別是在代理服務器中。

HTTP/1.1

當前版本號，持久連接被默認采用，并能很好地配合代理服務器工作。還支持以管道方式在同時發送多個請求，以便降低線路負載，提高傳輸速度。

但是HTTP/1.1仍有性能瓶頸，如

請求 / 響應頭部（Header）未經壓縮就發送，?部信息越多延遲越?。只能壓縮 Body 的部分；

發送冗?的?部。每次互相發送相同的?部造成的浪費較多；

沒有請求優先級控制，服務器是按請求的順序響應的，如果服務器響應慢，會招致客戶端?直請求不到數據，也就是隊頭阻塞；

HTTP/2.0

HTTP/2 協議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

HTTP/2的改進：

1.頭部壓縮

HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是?樣的或是相似的，那么，協議會幫你消除重復的部分。這就是所謂的 HPACK 算法：在客戶端和服務器同時維護?張頭信息表，所有字段都會存?這個表，?成?個索引號，以后就不發送同樣字段了，只發送索引號，這樣就提?速度了。

2.?進制格式

HTTP/2 不再像 HTTP/1.1 ?的純?本形式的報?，?是全?采?了?進制格式，頭信息和數據體都是?進制，并且統稱為幀（frame）：頭信息幀和數據幀。

3.數據流

HTTP/2 的數據包不是按順序發送的，同?個連接??連續的數據包，可能屬于不同的回應。因此，必須要對數據包做標記，指出它屬于哪個回應。每個請求或回應的所有數據包，稱為?個數據流（ Stream ）。每個數據流都標記著?個獨???的編號，其中規定客戶端發出的數據流編號為奇數，服務器發出的數據流編號為偶數。

客戶端還可以指定數據流的優先級。優先級?的請求，服務器就先響應該請求。

4.多路復?

HTTP/2 是可以在?個連接中并發多個請求或回應，?不?按照順序??對應。移除了 HTTP/1.1 中的串?請求，不需要排隊等待，也就不會再出現隊頭阻塞問題，降低了延遲，?幅度提?了連接的利?率。

5. 服務器推送

HTTP/2 還在?定程度上改善了傳統的「請求 - 應答」?作模式，服務不再是被動地響應，也可以主動向客戶端發送消息。

HTTP/1.1與HTTP/1.0的區別

1.persistent connection（持久連接）

HTTP/1.0：每對請求/ 響應都需要建立新的TCP連接。

HTTP/1.1：支持持久連接（默認），持久連接的特點是，只要任意?端沒有明確提出斷開連接，則保持 TCP 連接狀態。

2.Host域

HTTP/1.1在請求消息頭多一個Host域；HTTP/1.0? 則沒有這個域，建立TCP連接的時候已經指定了IP地址，而且默認一個IP地址只對應一個主機名，IP地址上只有一個host。

3.請求方法和狀態碼

HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方法。

HTTP/1.0中只定義了16個狀態響應碼，對錯誤或警告的提示不夠具體。HTTP/1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述。

在HTTP/1.1中新增了24個狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。

4.內容協商

為了滿足互聯網使用不同母語和字符集的用戶，一些網絡資源有不同的語言版本（如中文版、英文版）。

HTTP/1.0定義了內容協商（content negotiation）的概念，也就是說客戶端可以告訴服務器自己可以接收以何種語言（或字符集）表示的資源。例如如果服務器不能明確客戶端需要何種類型的資源，會返回300（Multiple Choices），并包含一個列表，用來聲明該資源的不同可用版本，然后客戶端在請求消息中包含Accept-Language和Accept- Charset頭域指定需要的版本。

5.帶寬優化

HTTP/1.1中在請求消息中引入了range頭域，它允許只請求資源的某個部分。在響應消息中Content-Range頭域聲明了返回的這部分對象的偏移值和長度。如果服務器相應地返回了對象所請求范圍的內容，則響應碼為206（Partial Content），它可以防止Cache將響應誤以為是完整的一個對象。請求消息中如果包含比較大的實體內容，但不確定服務器是否能夠接收該請求（如是否有權限），此時若貿然發出帶實體的請求，如果被拒絕也會浪費帶寬。 HTTP/1.1加入了一個新的狀態碼100（Continue）。客戶端事先發送一個只帶頭域的請求，如果服務器因為權限拒絕了請求，就回送響應碼 401（Unauthorized）；如果服務器接收此請求就回送響應碼100，客戶端就可以繼續發送帶實體的完整請求了。注意，HTTP/1.0的客戶端不支持100響應碼。

節省帶寬資源的一個非常有效的做法就是壓縮要傳送的數據。Content-Encoding是對消息進行端到端（end-to-end）的編碼，它可能是資源在服務器上保存的固有格式（如jpeg圖片格式）；在請求消息中加入Accept-Encoding頭域，它可以告訴服務器客戶端能夠解碼的編碼方式。而Transfer-Encoding是逐段式（hop-by-hop）的編碼，如Chunked編碼。在請求消息中加入TE頭??? 域用來告訴服務器能夠接收的transfer-coding方式。

HTTP/2有什么不足？

HTTP/2 主要的問題在于，多個 HTTP 請求在復??個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的。所以?旦發?了丟包現象，就會觸發 TCP 的重傳機制，這樣在?個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

HTTP/1.1 中的管道（ pipeline）傳輸中如果有?個請求阻塞了，那么隊列后請求也統統被阻塞住了。

HTTP/2 多個請求復??個TCP連接，?旦發?丟包，就會阻塞住所有的 HTTP 請求。

這都是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP。

HTTP常見字段

Host字段：客戶端發送請求時，?來指定服務器的域。

Connection：最常?于客戶端要求服務器使用TCP 持久連接，以便其他請求復?。

Content-Length：服務器在返回數據時，會有 Content-Length 字段，表明本次回應的數據長度。

Content-Type：字段?于服務器回應時，告訴客戶端本次的數據格式。

Content-Encoding ：說明數據的壓縮?法。表示服務器返回的數據使?了什么壓縮格式。

HTTP請求報文

HTTP報文有兩種類型：請求、響應。