漫畫：HTTP 協議極簡教程，傻瓜都能看懂！

做者：浪裏行舟
https://segmentfault.com/a/11...

引言

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。HTTP 是基於 TCP/IP 協議通訊協議來傳遞數據（HTML 文件、圖片文件、查詢結果等）。它不涉及數據包（packet）傳輸，主要規定了客戶端和服務器之間的通訊格式，默認使用80端口。

1、Http的特色

一、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、PUT、DELETE、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

二、靈活：HTTP容許傳輸任意類型的數據對象。

三、無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

四、無狀態：HTTP協議是無狀態的，HTTP 協議自身不對請求和響應之間的通訊狀態進行保存。任何兩次請求之間都沒有依賴關係。直觀地說，就是每一個請求都是獨立的，與前面的請求和後面的請求都是沒有直接聯繫的。協議自己並不保留以前一切的請求或 響應報文的信息。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。

2、Http報文

Http報文包括請求報文和響應報文兩大部分，其中請求報文由請求行（request line）、請求頭（header）、空行和請求體四個部分組成。而響應報文由狀態行、響應頭部、空行和響應體四個部分組成。接下來咱們詳細介紹下請求報文的各個部分及其做用。

一、請求行

用來講明請求類型、要訪問的資源以及所使用的HTTP版本。

POST  /chapter17/user.html HTTP/1.1

以上代碼中 POST 表明請求方法， /chapter17/user.html 表示URI， HTTP/1.1 表明協議和協議的版本。如今比較流行的是Http1.1版本。你們也能夠了解下 2.0 ：《讓面試官顫抖的 HTTP 2.0 協議面試題》。

二、請求頭

由關鍵字 / 值對組成，每行一對，關鍵字和值用英文冒號「:」分隔。

請求頭部通知服務器有關於客戶端請求的信息。它包含許多有關的客戶端環境和請求正文的有用信息。其中好比：

• Host：表示主機名，虛擬主機。
• Connection：HTTP/1.1增長的，使用keepalive，即持久鏈接，一個鏈接能夠發多個請求。
• User-Agent：請求發出者，兼容性以及定製化需求。

三、空行

最後一個請求頭以後是一個空行，這個行很是重要，它表示請求頭已經結束，接下來的是請求正文。

四、請求體

能夠承載多個請求參數的數據。

name=tom&password=1234&realName=tomson

上面代碼，承載着name、password、realName三個請求參數。

3、HTTP請求方法

• GET：請求指定的頁面信息，並返回實體主體。
• HEAD：相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭。
• POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。
• PUT：從客戶端向服務器傳送的數據取代指定的文檔的內容。
• DELETE：請求服務器刪除指定的頁面。

4、GET與POST區別

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。
• GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置。
• GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。
• GET請求在URL中傳送的參數是有長度限制的，而POST沒有限制。
• GET參數經過URL傳遞，POST放在Request body中。

5、Http狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別：

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

好比咱們平時常見兩種出錯的狀態碼：

403 Forbidden                 //對被請求頁面的訪問被禁止404 Not Found                 //請求資源不存在，好比：輸入了錯誤的URL

更多看下這篇文章《兩張趣圖助你理解 HTTP 狀態碼》

6、持久鏈接

一、爲何須要持久鏈接

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。以當年的通訊狀況來講，由於都是些容量很小的文本傳輸，因此即便這樣也沒有多大問題。可隨着 HTTP 的 普及，文檔中包含大量圖片的狀況多了起來。好比，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請 求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無謂的 TCP 鏈接創建和斷開，增長通訊量的 開銷。

二、持久鏈接的特色

爲解決上述 TCP 鏈接的問題， HTTP/1.1 和一部分的 HTTP/1.0 想出了持久鏈接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或 HTTP connection reuse）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

持久鏈接的好處在於減小了 TCP 鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外， 減小開銷的那部分時間，使 HTTP 請求和響應可以更早地結束，這樣 Web 頁面的顯示速度也就相應提升了。

在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接，但在 HTTP/1.0 內並未標準化。雖然有一部分服務器經過非 標準的手段實現了持久鏈接，但服務器端不必定可以支持持久鏈接。毫無疑問，除了服務器端，客戶端也需 要支持持久鏈接。

7、管線化

持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能 發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。

這樣就可以作到同時並行發送多個請求，而不須要一個接一個地等待響應了。通俗地講，請求打包一次傳輸過去，響應打包一次傳遞回來。管線化的前提是在持久鏈接下。

假如當請求一個包含 10 張圖片的 HTML Web 頁面，與挨個鏈接相比，用持久鏈接可讓請求更快結束。 而管線化技術則比持久鏈接還要快。請求數越多，時間差就越明顯。客戶端須要請求這十個資源。之前的作法是，在同一個TCP鏈接裏面，先發送A請求，而後等待服務器作出迴應，收到後再發出B請求，以此類推，而管道機制則是容許瀏覽器同時發出這十個請求，可是服務器仍是按照順序，先回應A請求，完成後再回應B請求。

因而在使用持久鏈接的狀況下，某個鏈接上消息的傳遞相似於：

請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3

管線化方式發送變成了相似這樣：

請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3

參考

《圖解HTTP》[日] 上野宣 著

推薦去個人博客閱讀更多：

1.Java JVM、集合、多線程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、後端、架構、阿里巴巴等大廠最新面試題

以爲不錯，別忘了點贊+轉發哦！