1.HTTP協議簡介
- HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
- HTTP是一個基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
- HTTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分佈式超媒體信息系統。
- HTTP協議工作於客戶端-服務端架構爲上。如下圖：
2.HTTP主要特點
- 支持客戶/服務器模式。
- 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。
- 靈活：HTTP允許傳輸任意類型的數據對象,正在傳輸的類型由Content-Type加以標記。
- 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。
- 無狀態：HTTP協議是是無狀態協議，無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
3.URL介紹
3.1URL格式
大多數URL協的語法都建立在下面9個部分構成的通用格式上：
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
其中比較重要的是：方案（scheme）、主機（host）和路徑（path）
3.2URL組成部分介紹- 支持客戶/服務器模式。
- 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。
- 靈活：HTTP允許傳輸任意類型的數據對象,正在傳輸的類型由Content-Type加以標記。
- 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。
- 無狀態：HTTP協議是是無狀態協議，無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
組件 | 描述 |
|---|---|
方案<scheme> | 訪問服務器以獲取資源時要使用哪種協議 |
用戶<user> | 某些方案訪問資源時需要的用戶名 |
密碼<password> | 用戶名後面可能要包含的密碼，中間由冒號分隔 |
主機<host> | 資源宿主服務器的主機名或點分IP地址 |
端口<port> | 資源宿主服務器正在監聽的端口號。很多方案都有默認端口號 |
路徑<path> | 服務器上資源的本定名，由斜槓將其與前面的URL組件分隔開來。路徑組件的語法是與服務器和方案有關。 |
參數<params> | 某些方案會用這個組件來指定輸入參數。參數爲名/值對。URL中可以包含多個參數字段，它們相互之間以與路徑的其餘部分之間用分號（;）分隔。 |
查詢<query> | 某些方案會用這個組件傳遞參數以激活因公程序。查詢組件的內容沒有通用格式。用字符”?”將其與URL的其餘部分分隔開來。 |
片段<frag> | 一小片或者一部分資源的名字。引用對象時，不會將frag字段傳送給服務器。這個字段是在客戶端內部使用的。通過字符”#”將其與URL的其餘部分分隔開來。 |
4.HTTP請求協議
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：
請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。
Get請求例子：
GET /123.png HTTP/1.1 Host: img.test.com content-length: 1500 content-type: image/png date: Sat, 22 Sep 2018 08:36:13 GMT Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-CN,zh;q=0.8
POST請求例子
POST / HTTP1.1 Host: img.test.com content-length: 1500 content-type: image/png date: Sat, 22 Sep 2018 08:36:13 GMT Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-CN,zh;q=0.8 name=aa&score=90
響應例子
HTTP/1.1 200 OK
Date: Sat, 22 Sep 2018 08:36:16 GMT
Content-Type: text/html; charset=UTF-8
<html>
<head></head>
<body>
<!--body goes here-->
</body>
</html>請求 | 響應 | |
|---|---|---|
請求行（request line） | 用來說明請求類型,要訪問的資源以及所使用的HTTP版本. | 狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。 |
頭部（header） | 用來說明服務器要使用的附加信息 | 消息報頭，用來說明客戶端要使用的一些附加信息 |
空行 | 空行，消息報頭後面的空行是必須的 | 空行，消息報頭後面的空行是必須的 |
數據 | 請求數據也叫主體，可以添加任意的其他數據 | 響應正文，服務器返回給客戶端的文本信息。 |
5.HTTP請求方法
- HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
- HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
請求方法 | 描述 |
|---|---|
GET | 請求指定的頁面信息，並返回實體主體。 |
HEAD | 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 |
POST | 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 |
PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
DELETE | 請求服務器刪除指定的頁面。 |
CONNECT | HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。 |
OPTIONS | 允許客戶端查看服務器的性能。 |
TRACE | 回顯服務器收到的請求，主要用於測試或診斷。 |
6.HTTP請求整個過程（常用於面試）
序號 | 步驟 | 描述 |
|---|---|---|
1 | DNS解析 | 瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址; |
2 | 建立TCP連接 | 解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器建立TCP連接 |
3 | 發送HTTP請求 | 通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。 |
4 | 服務器接受請求 | 服務器解析請求，進行適當的處理 |
5 | 響應 | 服務器將響應內容寫到TCP套接字（第），由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。 |
6 | 釋放TCP連接 | 若connection 模式爲close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式爲keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求; |
7 | 接收內容 | 瀏覽器將該 html 文本並顯示內容 |
7.GET和POST請求的區別
GET | POST | |
|---|---|---|
對數據長度的限制 | 當發送數據時，GET 方法向 URL 添加數據；URL 的長度是受限制的（URL 的最大長度是 2048 個字符） | 無限制。 |
對數據類型的限制 | 只允許 ASCII 字符。 | 沒有限制。也允許二進制數據。 |
安全性 | 與 POST 相比，GET 的安全性較差，因爲所發送的數據是 URL 的一部分,在發送密碼或其他敏感信息時絕不要使用 GET ！ | POST 比 GET 更安全，因爲參數不會被保存在瀏覽器歷史或 web 服務器日誌中。 |
可見性 | 數據在 URL 中對所有人都是可見的。 | 數據不會顯示在 URL 中。 |
點擊返回/刷新按鈕 | 沒有影響 | 數據會重新發送 |