一、HTTP簡介
1.http協議介紹
- HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是因特網上應用最爲廣泛的一種網絡傳輸協議，所有的WWW文件都必須遵守這個標準。
- HTTP是基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）
- HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如下圖
- HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。
- HTTP默認的端口號爲80，HTTPS的端口號爲443。
2.http協議工作流程
一次HTTP操作稱爲一個事務，其工作過程大概如下：
- 用戶在瀏覽器中鍵入需要訪問網頁的URL或者點擊某個網頁中鏈接；
- 瀏覽器根據URL中的域名，通過DNS解析出目標網頁的IP地址；
瀏覽器請求這個頁面：http://hackr.ip/index.html
在這一步，需要域名系統DNS解析域名hackr.ip,得主機的IP地址 20X.189.105.112。
然後將上面結合本機自己的信息，封裝成一個http請求數據包
- 在HTTP開始工作前，客戶端首先會通過TCP/IP協議來和服務端建立鏈接（TCP三次握手）
- 建立連接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可內容。
- 服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
- 一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，然後如果瀏覽器或者服務器在其頭信息加入了這行代碼：
Connection:keep-alive，TCP連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了爲每個請求建立新連接所需的時間，還節約了網絡帶寬。
2.1 短連接
短連接的操作步驟是： 建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接
如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費較多時間和帶寬。
2.2 長鏈接
長鏈接,指在一個連接上可以連續發送多個數據包，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。
長鏈接操作步驟： 建立連接——數據傳輸...（保持連接）...數據傳輸——關閉連接
長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間
長鏈接分爲 without pipelining 和 with pipelining，下圖中是without pipelining，客戶端只在收到前一個請求的響應後，才發出新的請求。
2.3 管線化
下圖是with pipelining，每次建立鏈接後無需等待請求回來就可以發送下一個請求
3. Http請求報文
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：
請求行（request line）、請求頭部（header）、請求體組成，下圖給出了請求報文的一般格式。
請求行:
方法:
GET 獲取資源
POST 向服務器端發送數據，傳輸實體主體
PUT 傳輸文件
HEAD 獲取報文首部
DELETE 刪除文件
OPTIONS 詢問支持的方法
TRACE 追蹤路徑
協議/版本號
URL
請求頭:
通用首部(General Header)
請求首部(Request Header)
響應首部(Response Header)
實體首部(Entity Header Fields)
請求體
請求報文拆解：
3.1 get請求
3.2 post請求
4. Http響應報文
HTTP響應組成：響應行、響應頭、響應體。
響應行
（HTTP/1.1）表明HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）
響應頭
Date:生成響應的日期和時間；
Content-Type:指定了MIME類型的HTML(text/html),編碼類型是ISO-8859-1
響應體
響應報文拆解：
5. Http狀態碼
| 類別 | 原因 |
|---|---|
| 1XX | Informational(信息性狀態碼) |
| 2XX | Success(成功狀態碼) |
| 3XX | Redirection(重定向) |
| 4XX | Client Error(客戶端錯誤狀態碼) |
| 5XX | Server Error(服務器錯誤狀態嗎) |
5.1 2XX 成功
200(OK 客戶端發過來的數據被正常處理
204(Not Content 正常響應，沒有實體
206(Partial Content 範圍請求，返回部分數據，響應報文中由Content-Range指定實體內容
5.2 3XX 重定向
301(Moved Permanently) 永久重定向
302(Found) 臨時重定向，規範要求，方法名不變，但是都會改變
303(See Other) 和302類似，但必須用GET方法
304(Not Modified) 狀態未改變， 配合(If-Match、If-Modified-Since、If-None_Match、If-Range、If-Unmodified-Since)
307(Temporary Redirect) 臨時重定向，不該改變請求方法
5.3 4XX 客戶端錯誤
400(Bad Request) 請求報文語法錯誤
401 (unauthorized) 需要認證
403(Forbidden) 服務器拒絕訪問對應的資源
404(Not Found) 服務器上無法找到資源
5.4 5XX 服務器端錯誤
500(Internal Server Error)服務器故障
503(Service Unavailable) 服務器處於超負載或正在停機維護
6. 首部
6.1 通用首部字段
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存行爲 |
| Connection | 鏈接的管理 |
| Date | 報文日期 |
| Pragma | 報文指令 |
| Trailer | 報文尾部的首部 |
| Trasfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級爲其他協議 |
| Via | 代理服務器信息 |
| Warning | 錯誤通知 |
6.2 請求首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優先的字符集 |
| Accept-Encoding | 優先的編碼 |
| Accept-Langulage | 優先的語言 |
| Authorization | Web認證信息 |
| Expect | 期待服務器的特定行爲 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在的服務器 |
| If-Match | 比較實體標記 |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記 |
| If-Range | 資源未更新時發送實體Byte的範圍請求 |
| If-Unmodified-Since | 比較資源的更新時間(和If-Modified-Since相反) |
| Max-Forwards | 最大傳輸跳數 |
| Proxy-Authorization | 代理服務器需要客戶端認證 |
| Range | 實體字節範圍請求 |
| Referer | 請求中的URI的原始獲取方 |
| TE | 傳輸編碼的優先級 |
| User-Agent | HTTP客戶端程序的信息 |
6.3 響應首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節範圍 |
| Age | 資源的創建時間 |
| ETag | 資源的匹配信息 |
| Location | 客戶端重定向至指定的URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 再次發送請求的時機 |
| Server | 服務器的信息 |
| Vary | 代理服務器緩存的管理信息 |
| www-Authenticate | 服務器對客戶端的認證 |
6.4 實體首部字段
| 首部字段名 | 說明 |
|---|---|
| Allow | 資源可支持的HTTP方法 |
| Content-Encoding | 實體的編碼方式 |
| Content-Language | 實體的自然語言 |
| Content-Length | 實體的內容大小(字節爲單位) |
| Content-Location | 替代對應資源的URI |
| Content-MD5 | 實體的報文摘要 |
| Content-Range | 實體的位置範圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體過期時間 |
| Last-Modified | 資源的最後修改時間 |