前言
后面會把之前做的MQTT、TCP/IP網絡編程基礎筆記都發出來，分享給同學們參考，指正，因為主要是方便自己出門在外查看哈哈。有空就補上一些標有的demo（大部分都是基於linux的）。
原文鏈接：李柱明博客：https://www.cnblogs.com/lizhuming/p/14992365.html
1. http 簡介
1.1 概念
HTTP協議是 Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。
用於從萬維網（WWW:World Wide Web）服務器傳輸超文本到本地瀏覽器的傳送協議。
1.2 原理
原理：
- HTTP是一個基於 TCP/IP通信協議 來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
- 是基於 客戶端-服務器 模型運作的。
- 是一個應用層協議。
通信過程：
- HTTP 客戶端（如瀏覽器）通過 URL 向 HTTP 服務端（如web服務器）發送請求。
- HTTP 服務端 接收到請求后，向客戶端發送響應信息。
web服務器：
- Apache服務器。
- IIS服務器（Internet Information Services）。
- etc。
1.3 特點
HTTP協議的特點：
- 簡單：客戶端向服務器請求服務時，只需要傳送請求方法和資源路徑即可獲得資源。
- 快捷：由於HTTP協議簡單，所以HTTP服務器程序規模小，通信快。
- 靈活：HTTP允許傳輸任意類型的數據對象，傳輸的類型由Content-Type加以標記。
- 無連接：服務器每處理客戶端的一個請求，響應並獲得客戶端的應答后，斷開連接。（斷開TCP連接）。
- 注意：HTTP1.1 后便有了持久連接的方法。即是任意一端只要沒有提出斷開連接，則保持TCP連接。
- 無狀態：HTTP協議對於事務處理沒有記憶能力，即無法根據之前的狀態進行本次的請求處理。如果后續處理需要前面的信息，它必須重傳數據。
- 解決：引入Cookie技術，讓服務器知道用戶上一次的操作，並且記錄存儲在客戶端之中。
2. URL 簡介
2.1 概念
URL 是 Uniform Resource Locator 的縮寫。統一資源定位器。
URL 是一個網頁地址：
- 可以由字母組成，如 baidu.com。
- 也可以是物聯網協議（IP）地址：180.76.76.76。
2.2 URL 通用格式
一個URL的組成有多個不同的組件，一個URL的通用格式如下：
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
說明：
| 組件 | 名稱 | 描述 |
|---|---|---|
| scheme | 方案 | 指定訪問服務器獲取資源時使用哪種協議，有HTTP、HTTPS、FTP、SMTP等協議。 |
| user | 用戶 | 某些訪問資源時候需要指定用戶名，才有權限獲取資源。 |
| password | 密碼 | 用戶名后面可能需要密碼進行驗證，用戶名與密碼直接使用“:”冒號分隔連接。 |
| host | 主機 | 資源宿主服務器的主機名或者IP地址（點分十進制）。 |
| port | 端口 | 資源宿主服務器正在監聽的端口號。 |
| path | 路徑 | 服務器本地資源的路徑。 |
| params | 參數 | 某些方案會使用這個組件來輸入參數，可以擁有多個參數，使用“;”符號 與路徑分隔開。 |
| query | 查詢 | 某些方案會使用這個組件傳遞參數以激活應用程序，查詢組件的內容沒有通 用的格式，用 ? 字符與其他組件分隔開 |
| frag | 片段 | 這個字段是在客戶端內部使用，不會發送到服務器，通過“#”字符與其他組件分隔開 。 |
注意：
- 以上組件不是全部都必須填上的，根據方案填寫需要的組件即可。
- 端口port：端口號，可以不用自己填寫，比如HTTP默認使用80端口，HTTPS默認使用443 端口。端口不是一個URL必須的部分。
2.3 網頁地址 實例說明
網頁地址：https://www.cnblogs.com/lizhuming/p/13834535.html
- https：方案scheme。安全超文本傳輸協議。
- www.cnblogs.com：主機host。博客園的域名。
- lizhuming/p/13834535.html：路徑path。博客園服務器上的路徑。
- 13834535.html：資源文件。html格式。
- 端口省略，即是默認使用https的默認端口 443。
在瀏覽器中按 F12 進入瀏覽器控制台，可以看到很多 URL。
3. HTTP 消息結構
3.1 客戶端請求消息
客戶端請求消息由四部分組成：
- 請求行（request line）。
- 請求頭部（header）。
- 空行。
- 請求數據。
如圖：
頭部信息參考：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
//請求報文
<method> <request-URL> <version>
<headers>
<entity-body>
3.2 服務器響應消息
服務器響應消息也是由四部分組成：
- 狀態行。
- 消息報頭。
- 空行。
- 響應正文。
如圖：
//響應報文
<version> <status> <reason-phrase>
<headers>
<entity-body>
響應狀態碼說明：
| 范圍 | 已定義范圍 | 描述 |
|---|---|---|
| 100 : 199 | 100 : 101 | 信息提示 |
| 200 : 299 | 200 : 206 | 成功 |
| 300 : 399 | 300 : 305 | 重定向 |
| 400 : 499 | 400 : 415 | 客戶端錯誤 |
| 500 : 599 | 500 : 505 | 服務器錯誤 |
tips：具體的狀態碼到參考鏈接了解。
3.3 實例
打開瀏覽器，F12 進入后台，點擊 network 查看。
4. HTTP 請求方法
HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
| 方法 | 描述 |
|---|---|
| GET | 請求指定的頁面信息，並返回實體主體。 |
| HEAD | 類似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭。 |
| POST | 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。 |
| PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
| DELETE | 請求服務器刪除指定的頁面。 |
| CONNECT | HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。 |
| OPTIONS | 允許客戶端查看服務器的性能。 |
| TRACE | 回顯服務器收到的請求，主要用於測試或診斷。 |
| PATCH | 是對 PUT 方法的補充，用來對已知資源進行局部更新 。 |
5. HTTP 響應頭信息
| 應答頭 | 描述 |
|---|---|
| Allow | 服務器支持哪些請求方法。 |
| Content-Encoding | 文檔的編碼（Encode）方法。 |
| Content-Length | 內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。 |
| Content-Type | 表示后面的文檔屬於什么MIME類型。 |
| Date | 當前的GMT時間。 |
| Expires | 文檔有效期截止時間。過期不緩存。 |
| Last-Modified | 文檔的最后改動時間。 |
| Location | 表示客戶應當到哪里去提取文檔。 |
| Refresh | 表示瀏覽器應該在多少時間之后刷新文檔。單位 秒。 |
| Server | 服務器名字。 |
| Set-Cookie | 設置和頁面關聯的Cookie。 |
| WWW-Authenticate | 客戶應該在Authorization頭中提供什么類型的授權信息。 |
tips：使用應答頭參數時，建議到參考鏈接了解其作用。